Education Cloud: qué datos de admisión debe usar un agente de IA

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"; repositorio en GitHub).

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). 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). 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

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.

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 —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"). 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").

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 un chatbot como 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 chatbot 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, 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.