--- title: "Education Cloud: qué datos de admisión usa un agente de IA" description: "Salesforce Education Cloud separa identidad, interés académico y consentimiento del kardex y del financiamiento estudiantil. Qué debe usar un agente de IA de admisiones en México." url: "https://www.skolbot.ai/es-MX/blog/education-cloud-datos-admision-agente-ia" language: "es" dateModified: "2026-09-25" --- # Education Cloud: qué datos de admisión usa un agente de IA Actualizado el 25 de septiembre de 2026 Salesforce Education Cloud separa identidad, interés académico y consentimiento del kardex y del financiamiento estudiantil. Qué debe usar un agente de IA de admisiones en México. ## Qué datos de admisión debe usar un agente de IA en Education Cloud Un agente de IA de admisiones necesita cuatro tipos de datos: identidad del aspirante, interés de licenciatura o posgrado y etapa de su solicitud, consentimiento para recibir comunicación, e historial de interacción previa. No necesita, y por defecto no debe tocar, el kardex académico detallado ni el detalle del financiamiento estudiantil del aspirante. Esta separación no es una preferencia de diseño arbitraria. Es, en buena medida, cómo Salesforce ya organiza el modelo de datos de Education Cloud: distingue la identidad y la relación (Contact, Affiliation) de la trayectoria académica (Program Enrollment, Course Connection) y de la capa propia de admisiones (Applicant, Application Decision). Un agente de IA bien acotado respeta esas fronteras en lugar de leer el esquema completo del CRM. Este artículo explica qué contiene el modelo de datos de Education Cloud, qué debe leer y escribir un agente conversacional para universidades e instituciones privadas mexicanas, y por qué la proporcionalidad en el tratamiento de datos personales —no la facilidad técnica— debe marcar el límite. ## Qué contiene realmente el modelo de datos de Education Cloud Education Cloud se construye sobre Education Data Architecture (EDA), el modelo de datos de código abierto de Salesforce.org que extiende los objetos estándar Account y Contact con objetos propios del sector educativo: Affiliation, Relationship, Program Enrollment, Course Connection, Academic Certification, Address, Attendance Event, Case, Course, Credential y Education History ([Salesforce, "EDA Explained"](https://help.salesforce.com/s/articleView?id=sfdo.eda_explained.htm); [repositorio en GitHub](https://github.com/SalesforceFoundation/EDA)). Dos de esos objetos se mantienen sincronizados de forma automática: al guardar un registro de Program Enrollment en el Contact de un aspirante, Salesforce crea —si no existe todavía— una Affiliation entre ese Contact y el programa académico, y ambos registros quedan enlazados de ahí en adelante ([Salesforce, documentación de Program Enrollment](https://help.salesforce.com/s/articleView?id=sfdo.EDA_Program_Enrollment.htm)). Es un ejemplo concreto de cómo el propio modelo separa "quién es esta persona" de "en qué programa está inscrita", en lugar de mezclarlo todo en un solo registro. Sobre esa base, la capa de Recruitment and Admissions de Education Cloud agrega objetos específicos para el ciclo de captación: Applicant, Application Decision, Application Review, Application Stage Definition y Application Timeline ([Salesforce, "Recruitment & Admissions" — Agentforce for Education](https://www.salesforce.com/agentforce/use-cases/education/recruitment-admissions/)). Estos objetos controlan el estatus de una solicitud puntual —recibida, en revisión, aceptada, inscrita— sin necesidad de exponer el kardex completo del aspirante ni los datos de financiamiento que puedan existir en otras áreas del CRM. ### Los objetos, agrupados por función | Capa | Objetos típicos | Qué describe | |---|---|---| | Identidad y relación | Contact, Account, Affiliation, Relationship | Quién es el aspirante y con qué instituciones o personas se relaciona | | Trayectoria académica | Program Enrollment, Course Connection, Education History, Academic Certification | En qué programas está o ha estado inscrito, y sus estudios previos | | Ciclo de admisión | Applicant, Application Decision, Application Review, Application Stage Definition, Application Timeline | El estatus y avance de una solicitud puntual | | Interacción y soporte | Case, Attendance Event | Consultas, incidencias y asistencia a eventos de captación | ## Qué debe leer y escribir un agente — y qué nunca debe tocar por defecto Un agente de IA de admisiones cumple su función con una porción reducida de este modelo. Ampliar su alcance más allá de eso no agrega capacidad real: agrega superficie de riesgo, sin un beneficio claro para el aspirante ni para el equipo de admisiones. La identidad básica (nombre, correo, teléfono, programa de interés declarado) permite personalizar la conversación. El interés de programa y la etapa de la solicitud —campos que ya existen en Program Enrollment y en los objetos de Recruitment and Admissions— permiten al agente responder con precisión sobre fechas límite, requisitos de ingreso y siguientes pasos. El consentimiento y la preferencia de comunicación determinan si el agente puede dar seguimiento por cuenta propia o solo responder cuando el aspirante escribe primero. El historial de interacción (qué preguntó antes, qué páginas visitó, si ya se registró a un día de puertas abiertas) evita que el aspirante repita información que ya proporcionó. El kardex académico detallado —calificaciones por materia, expedientes disciplinarios, resultados de evaluaciones psicopedagógicas— y el detalle del financiamiento estudiantil —montos de becas, evaluaciones socioeconómicas, datos bancarios— quedan fuera del alcance por defecto. No porque el agente sea incapaz de procesarlos, sino porque no aportan valor a una conversación de captación y sí concentran el tipo de dato cuya fuga o mal uso causa más daño al aspirante. | Categoría de dato | Objeto EDA/Recruitment típico | Debe leer | Debe escribir | Acceso por defecto | |---|---|---|---|---| | Identidad básica | Contact, Applicant | Sí | Sí (actualización de perfil) | Agente | | Interés de programa / etapa de solicitud | Program Enrollment, Application Stage Definition | Sí | Sí (registro de interés, avance de etapa) | Agente | | Consentimiento y preferencia de comunicación | Contact (campos de consentimiento) | Sí | Sí (opt-in/opt-out) | Agente | | Historial de interacción | Case, Attendance Event | Sí | Sí (nueva interacción) | Agente | | Kardex académico detallado | Education History, Academic Certification (campos de detalle) | No por defecto | No | Equipo de admisiones/control escolar | | Detalle de financiamiento estudiantil | Objetos financieros fuera de EDA | No | No | Área de finanzas/becas | ## Por qué la proporcionalidad en el tratamiento de datos no es opcional La Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) obliga a toda institución privada a tratar los datos personales conforme a los principios de licitud, consentimiento, información, calidad, finalidad, lealtad, proporcionalidad y responsabilidad. Un agente conversacional de admisiones tiene una finalidad concreta —informar, orientar, dirigir hacia el siguiente paso del proceso— y esa finalidad, por sí sola, no justifica el acceso al kardex ni a las evaluaciones de becas del aspirante. El [Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales (INAI) publicó recomendaciones generales para el tratamiento de datos personales derivado del uso de la inteligencia artificial](https://inicio.inai.org.mx/nuevo/RIPD_Recomendaciones-generales-para-el-tratamiento-de-datos-en-la-ia.pdf), dirigidas a responsables y desarrolladores de plataformas de IA, con el fin de reducir riesgos y facilitar el cumplimiento del deber de seguridad de los datos personales. Para una institución que evalúa conectar un agente de IA a Education Cloud, esas recomendaciones son el punto de partida antes de decidir qué objetos y qué campos queda expuestos al agente. En la práctica, esto significa que un aspirante que pregunta por el puntaje mínimo de admisión, por las fechas del examen EXANI-II de CENEVAL o por si una licenciatura cuenta con Reconocimiento de Validez Oficial de Estudios (RVOE) de la SEP puede recibir respuesta sin que el agente necesite ver su kardex si viene de otra institución, ni el estatus de una beca institucional en trámite. La conversación se resuelve con los objetos de interés de programa y etapa de solicitud; el kardex y el financiamiento siguen su propio circuito, a cargo de personal con la formación y el aviso de privacidad correspondiente para tratarlos. ## Agentforce for Education: hacia dónde va Salesforce con los agentes de admisiones Salesforce ya comercializa agentes de IA preconfigurados para educación superior bajo el nombre Agentforce for Education, construidos sobre el modelo de datos de Education Cloud ([Salesforce, "Agentforce for Education"](https://www.salesforce.com/education/artificial-intelligence/)). Su página de caso de uso para captación y admisiones describe un agente capaz de responder preguntas de aspirantes, crear un registro de interés académico, registrar la inscripción a una visita de campus o iniciar una nueva solicitud —acciones acotadas a objetos puntuales del modelo de Recruitment and Admissions, no un acceso abierto a todo el CRM ([Salesforce, "Agentforce Use Cases: Recruitment & Admissions"](https://www.salesforce.com/agentforce/use-cases/education/recruitment-admissions/)). Es una señal relevante para cualquier director de admisiones o responsable de TI en México que evalúe este tipo de soluciones: el propio fabricante del CRM diseña sus agentes con un alcance de datos deliberadamente limitado a la captación, no como un asistente con acceso universal al esquema. La misma lógica debe aplicarse a cualquier agente de IA de terceros que se conecte a Education Cloud, sea nativo de Salesforce o no. ## Cómo encaja Skolbot en este modelo Skolbot está diseñado como una capa de IA sobre el CRM que la institución ya utiliza —incluidos conectores nativos con Salesforce—, no como un sustituto del CRM ni como un segundo sistema de registro. Cada conversación con un aspirante se enriquece de vuelta en el CRM: perfil, preguntas realizadas, programa de interés y puntuación de madurez del aspirante (lead scoring). Este enfoque sigue la misma lógica que el modelo de datos de Education Cloud ya separa por diseño: el agente opera sobre identidad, interés de programa y consentimiento, y deja el kardex y el financiamiento estudiantil en manos del equipo de admisiones o de becas. Para entender cómo se conecta esta capa de IA con distintos CRM del sector, consulte nuestra [comparativa de CRM para escuelas superiores](https://www.skolbot.ai/es-MX/blog/crm-escuelas-superiores-comparativa), y para ver cómo se traduce el interés de un aspirante en una puntuación accionable, revise nuestra guía de [lead scoring para captación de estudiantes](https://www.skolbot.ai/es-MX/blog/lead-scoring-captacion-estudiantes-escuelas). --- Pruebe Skolbot en su escuela en 30 segundos ## FAQ ### ¿Qué es Salesforce Education Cloud y en qué se diferencia del Salesforce estándar? Education Cloud es la edición de Salesforce para instituciones educativas, construida sobre Education Data Architecture (EDA): agrega objetos como Affiliation, Program Enrollment o Applicant a los objetos estándar Account y Contact del CRM genérico, para representar el ciclo completo de aspirante a estudiante inscrito, no solo una relación comercial. ### ¿Puede un agente de IA acceder al kardex o a las calificaciones del aspirante? No debería, por defecto. El kardex detallado (calificaciones, expedientes disciplinarios, evaluaciones psicopedagógicas) no aporta valor a una conversación de captación y concentra datos sensibles. El agente trabaja con los objetos de interés de programa y etapa de solicitud; el acceso al kardex queda reservado al equipo de control escolar o admisiones. ### ¿Qué obliga la LFPDPPP respecto al uso de datos de admisión por un agente de IA? La LFPDPPP obliga a informar al titular de los datos mediante un aviso de privacidad, obtener su consentimiento cuando la ley lo exija, y tratar solo los datos proporcionales a la finalidad declarada. Para un agente de admisiones, eso significa limitar su acceso a identidad, interés de programa y consentimiento de comunicación, no al expediente completo del aspirante. ### ¿Los datos de becas o financiamiento estudiantil deben pasar por el agente de IA? No por defecto. Los montos de becas y las evaluaciones socioeconómicas suelen quedar fuera del alcance típico de EDA y requieren un tratamiento con controles propios, a cargo del área de finanzas o becas de la institución, no de un agente conversacional de captación. ### ¿Este modelo de datos aplica si mi universidad no usa Salesforce ni sigue el calendario de ANUIES? El razonamiento aplica más allá de Salesforce y del calendario de una institución en particular: cualquier CRM educativo distingue, de una forma u otra, identidad, trayectoria académica y ciclo de admisión. El principio —limitar el acceso de un agente de IA a identidad, interés de programa, consentimiento e historial de interacción— es válido sin importar el CRM ni el proceso de admisión que siga la institución, esté o no afiliada a ANUIES.