--- title: "Education Cloud: qué datos de admisión debe usar un agente de IA" description: "Salesforce Education Cloud separa identidad, interés de programa y consentimiento de los datos sensibles. Qué debe leer y escribir un agente de IA, y qué debe evitar." url: "https://www.skolbot.ai/es/blog/education-cloud-datos-admision-agente-ia" language: "es" dateModified: "2026-09-25" --- # Education Cloud: qué datos de admisión debe usar un agente de IA Actualizado el 25 de septiembre de 2026 Salesforce Education Cloud separa identidad, interés de programa y consentimiento de los datos sensibles. Qué debe leer y escribir un agente de IA, y qué debe evitar. ## Qué datos de admisión debe usar un agente de IA en Education Cloud Un agente de IA de admisiones necesita cuatro categorías de datos: identidad del candidato, interés de programa y etapa de solicitud, consentimiento y preferencia de marketing, e historial de interacción. No necesita —y por defecto no debería tocar— el expediente académico sensible ni el detalle de ayuda financiera del candidato. Esta distinción no es una opinión de producto. Es, en gran medida, cómo Salesforce ya organiza su propio modelo de datos para educación superior: separa la identidad y la relación (Contact, Affiliation) de la trayectoria académica (Program Enrollment, Course Connection) y de la capa específica de admisiones (Applicant, Application Decision). Un agente de IA bien diseñado respeta esas fronteras en lugar de leer el esquema completo. Este artículo explica qué contiene realmente el modelo de datos de Education Cloud, qué debe leer y escribir un agente conversacional, y por qué la minimización de datos —no la comodidad técnica— debería 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 personalizados 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 están enlazados de forma automática: guardar un registro de Program Enrollment en el Contact de un candidato crea —si no existe todavía— una Affiliation entre ese Contact y el programa académico, y ambos registros se mantienen sincronizados a partir de ahí ([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 mezclar ambas cosas en un único registro plano. Sobre esa base, la capa de Recruitment and Admissions de Education Cloud añade objetos pensados específicamente 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 gestionan el estado de una solicitud concreta —recibida, en revisión, admitida, matriculada— sin necesidad de tocar el expediente académico completo del candidato ni los datos de ayuda financiera que puedan existir en otras partes 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 candidato 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 credenciales previas | | Ciclo de admisión | Applicant, Application Decision, Application Review, Application Stage Definition, Application Timeline | El estado y la evolución de una solicitud concreta | | 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 un subconjunto reducido de este modelo. Ampliar su alcance más allá de eso no añade capacidad útil: añade superficie de riesgo, sin un beneficio claro para el candidato 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 solicitud —campos que ya existen en Program Enrollment y en los objetos de Recruitment and Admissions— permiten al agente responder con precisión sobre plazos, requisitos y siguientes pasos. El consentimiento y la preferencia de marketing determinan si el agente puede iniciar contacto de seguimiento o solo responder cuando el candidato escribe primero. El historial de interacción (qué preguntó antes, qué páginas visitó, si ya se registró en una jornada de puertas abiertas) evita que el candidato repita información ya facilitada. El expediente académico sensible —calificaciones detalladas, expedientes disciplinarios, informes de evaluación psicopedagógica— y el detalle de ayuda financiera —importes de becas, evaluaciones de necesidad económica, 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 uso indebido causa más daño al candidato. | 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 marketing | Contact (campos de consentimiento) | Sí | Sí (opt-in/opt-out) | Agente | | Historial de interacción | Case, Attendance Event | Sí | Sí (nueva interacción) | Agente | | Expediente académico sensible | Education History, Academic Certification (campos de detalle) | No por defecto | No | Equipo de admisiones | | Detalle de ayuda financiera | Objetos financieros fuera de EDA | No | No | Equipo de administración/finanzas | ## Por qué la minimización de datos no es opcional aquí El principio de minimización del RGPD (artículo 5.1.c) exige tratar solo los datos adecuados, pertinentes y limitados a lo necesario para la finalidad declarada. Un agente conversacional de admisiones tiene una finalidad concreta —informar, cualificar, dirigir hacia el siguiente paso del proceso— y esa finalidad no requiere acceso a expedientes disciplinarios ni a evaluaciones de ayuda financiera. La [Agencia Española de Protección de Datos (AEPD) publicó en 2026 unas orientaciones específicas sobre IA agéntica](https://www.aepd.es/prensa-y-comunicacion/notas-de-prensa/la-agencia-publica-unas-orientaciones-sobre-inteligencia) —sistemas de IA capaces de actuar de forma autónoma para conseguir un objetivo— que insisten precisamente en esto: gobernanza del acceso, minimización de datos y control de la memoria del agente, tanto a corto como a largo plazo. Para una escuela o universidad que evalúa conectar un agente de IA a Education Cloud, esas orientaciones son el punto de referencia antes de decidir qué objetos y qué campos expone. En la práctica, esto significa que un candidato que pregunta por la nota de corte de un grado, por los plazos de la Selectividad/EBAU o por si un título previo cuenta con verificación de ANECA puede recibir respuesta sin que el agente necesite ver su expediente académico si procede de otra institución, ni el estado de una beca del Ministerio en trámite. La conversación se resuelve con los objetos de interés de programa y etapa de solicitud; el expediente y la ayuda financiera siguen su circuito habitual, gestionado por personas con la formación y el mandato legal para tratarlos. ## Agentforce for Education: hacia dónde va Salesforce con los agentes de admisiones Salesforce comercializa ya 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 candidatos, 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 concretos 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 que evalúe 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 debería 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 escuela 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 candidato se enriquece de vuelta en el CRM: perfil, preguntas realizadas, programa de interés y puntuación de madurez del candidato (lead scoring). Este enfoque sigue la misma lógica que el modelo de datos de Education Cloud separa por diseño: el agente opera sobre identidad, interés de programa y consentimiento, y deja el expediente académico y la ayuda financiera en manos del equipo de admisiones. 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/blog/crm-escuelas-superiores-comparativa), y para ver cómo se traduce el interés de un candidato en una puntuación accionable, revise nuestra guía de [lead scoring para captación de estudiantes](https://www.skolbot.ai/es/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): añade 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 candidato a estudiante, no solo una relación comercial. ### ¿Puede un agente de IA acceder a las calificaciones o al expediente académico del candidato? No debería, por defecto. El expediente académico detallado (calificaciones, expedientes disciplinarios, evaluaciones) 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 expediente queda reservado al equipo de admisiones. ### ¿Qué base legal del RGPD cubre el uso de datos de admisión por un agente de IA? Depende de la finalidad: responder consultas informativas suele apoyarse en el interés legítimo o en la ejecución de medidas precontractuales, mientras que el envío de comunicaciones de marketing requiere consentimiento explícito conforme al RGPD y a la LOPDGDD. La AEPD recomienda documentar la base legal específica para cada tratamiento que realice el agente, no una base única para todo el sistema. ### ¿Los datos de ayuda financiera deben pasar por el agente de IA? No por defecto. Los importes de becas y las evaluaciones de necesidad económica suelen vivir fuera del alcance típico de EDA y requieren un tratamiento con controles propios, gestionado por el equipo de administración o finanzas de la institución, no por un agente conversacional de captación. ### ¿Este modelo de datos aplica también si mi escuela no usa Salesforce? El razonamiento aplica más allá de Salesforce: 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 independientemente del CRM subyacente.