Education Cloud: quais dados de admissão um agente de IA deve usar?

Um agente de IA não precisa de acesso a todo o Education Cloud

Um agente de IA de admissões deve ler apenas quatro categorias de dados: identidade do candidato, interesse de curso e etapa do processo seletivo, consentimento de marketing e histórico de interação. Não deve acessar, por padrão, registros acadêmicos sensíveis nem o detalhe de bolsas e financiamento estudantil. Essa separação não é uma escolha arbitrária — ela reflete a própria arquitetura de dados que a Salesforce definiu para o setor educacional.

Para um diretor de admissões, de TI ou de operações em uma IES que está avaliando como conectar um agente conversacional ao Education Cloud, a pergunta certa não é "o agente tem acesso ao CRM?", mas "a quais objetos, exatamente, o agente tem acesso — e por quê apenas esses?". Este artigo explica o modelo de dados por trás do Education Cloud e onde traçar essa fronteira.

O que a Education Data Architecture realmente modela

A Education Data Architecture (EDA) é o modelo de dados open source que a Salesforce publica no GitHub e que serve de base ao Education Cloud. Ela estende os objetos padrão Account e Contact do Salesforce com objetos específicos do setor educacional: Affiliation, Relationship, Program Enrollment, Course Connection, Academic Certification, Address, Attendance Event, Case, Course, Credential e Education History (documentação da EDA no GitHub; explicação da EDA no Salesforce Help).

Dois objetos merecem atenção especial para quem está desenhando um agente de admissões. O Contact guarda a identidade da pessoa — nome, e-mail, telefone. A Affiliation conecta esse Contact a uma Account (por exemplo, um curso ou departamento) e descreve a natureza dessa relação. De acordo com a documentação oficial, salvar um registro de Program Enrollment em um Contact cria automaticamente uma Affiliation entre esse Contact e o Academic Program correspondente, caso ainda não exista — e as duas permanecem sincronizadas a partir daí (Salesforce Help — Program Enrollment).

Essa sincronização automática importa porque mostra que a própria Salesforce trata "quem é o candidato" e "qual curso desperta interesse nele" como camadas distintas do modelo — não como um único bloco de dados. Um agente de IA bem desenhado respeita essa mesma separação.

O módulo de Recrutamento e Admissões adiciona a camada de processo

Sobre a EDA, o Education Cloud adiciona um conjunto de objetos específicos de recrutamento e admissões: Applicant, Application Decision, Application Review, Application Stage Definition e Application Timeline (Salesforce, "Recruitment & Admissions" — Agentforce for Education).

Esses objetos capturam em que ponto do funil o candidato está — inscrição enviada, em análise, decisão pendente, decisão comunicada — sem misturar essa informação com o conteúdo da avaliação acadêmica em si. Application Decision registra o resultado; não registra as notas subjacentes nem os critérios detalhados usados pela comissão de seleção. Essa distinção entre "status do processo" e "conteúdo da avaliação" é exatamente a linha que separa o que um agente de admissões deve ler do que deve ignorar.

A Salesforce já vende explicitamente agentes de IA construídos sobre esse modelo, sob a marca Agentforce for Education: habilidades pré-configuradas cobrem recrutamento, admissões, sucesso estudantil e relacionamento institucional, e a própria página de casos de uso descreve um "Student Recruitment Agent" capaz de responder dúvidas de candidatos, agendar visitas ao campus ou explicar o processo de inscrição (Agentforce for Education — Recruitment and Admissions; Salesforce Education AI).

O que um agente de IA deve ler, escrever e nunca tocar

A tabela a seguir resume a fronteira operacional recomendada, alinhada com os objetos que o próprio modelo Education Cloud já separa.

A lógica por trás das duas últimas linhas não é só prudência — é minimização de dados. Um agente conversacional de admissões não precisa saber a nota de um candidato em uma disciplina anterior, nem o valor exato de uma bolsa PROUNI ou FIES em análise, para responder "quando fecha a inscrição do vestibular?" ou para agendar uma visita ao campus. Dar acesso a esses dados amplia a superfície de risco sem ampliar a utilidade.

Minimização de dados: o que a LGPD e a ANPD exigem na prática

O princípio de minimização da LGPD (Lei 13.709/2018) determina que apenas os dados pessoais necessários para a finalidade específica sejam tratados. Aplicado a um agente de admissões, isso significa desenhar o acesso a dados objeto a objeto, não conceder uma chave geral ao CRM inteiro.

A Autoridade Nacional de Proteção de Dados (ANPD) publicou a Nota Técnica nº 12/2025 discutindo os impactos do tratamento automatizado de dados e do uso de inteligência artificial à luz da LGPD, com atenção específica a sistemas que classificam perfis, fazem recrutamento ou realizam análise comportamental sem mecanismos claros de contestação ou revisão humana. Um agente que só acessa as quatro categorias descritas acima — identidade, interesse de curso, consentimento, histórico de interação — reduz substancialmente o escopo dessa preocupação, porque elimina de saída as categorias de dados mais sensíveis do tratamento.

Vale lembrar que o MEC e o INEP não regulam o tratamento de dados pessoais em si — essa competência é da ANPD —, mas os processos de credenciamento e recredenciamento institucional (e-MEC) pressupõem processos de admissão auditáveis, especialmente quando envolvem candidatos ingressando via SISU com nota do ENEM. Um agente com escopo de dados claramente definido e documentado facilita essa auditoria, porque a fronteira entre "o que o agente vê" e "o que fica reservado à equipe humana" fica explícita desde o desenho, em vez de precisar ser reconstruída depois.

Como isso se conecta a um chatbot como o Skolbot

O Skolbot é desenhado como uma camada de IA sobre o CRM já existente da instituição, incluindo conectores nativos para plataformas como o Salesforce — não como um substituto do Education Cloud. Cada conversa com um candidato é registrada de volta no CRM de forma estruturada: perfil do prospect, perguntas feitas, curso de interesse e pontuação de maturidade do lead.

Na prática, isso se aproxima do desenho de fronteira descrito acima: o agente lê e escreve nas camadas de identidade, interesse de curso e histórico de interação, e não interfere nos registros acadêmicos ou financeiros que pertencem a outros fluxos de trabalho da instituição. Se você está comparando CRM antes de decidir sobre essa integração, o nosso comparativo de CRM para instituições de ensino superior detalha os critérios de escolha, incluindo a abertura de API que esse tipo de conexão exige. Para entender como o histórico de interação alimenta a priorização de candidatos, veja também o nosso guia de lead scoring no recrutamento estudantil. E para o panorama mais amplo de estratégias de captação, consulte nosso guia sobre como recrutar mais estudantes no ensino superior privado.