Education Cloud: que 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 programa e fase de candidatura, consentimento de marketing e histórico de interação. Não deve tocar, por padrão, em registos académicos sensíveis nem em detalhe de apoio financeiro. Esta separação não é uma escolha arbitrária — reflete a própria arquitetura de dados que a Salesforce definiu para o setor educativo.

Para um diretor de admissões ou responsável de TI que está a avaliar como ligar um agente conversacional ao Education Cloud, a pergunta certa não é "o agente tem acesso à CRM?" mas sim "a que objetos, exatamente, o agente tem acesso — e porquê apenas esses?". Este artigo explica o modelo de dados subjacente e onde traçar essa fronteira.

O que o Education Data Architecture realmente modela

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

Dois objetos merecem atenção especial para quem está a desenhar um agente de admissões. O Contact guarda a identidade da pessoa — nome, email, telefone. A Affiliation liga esse Contact a uma Account (por exemplo, um programa académico ou departamento) e descreve a natureza dessa relação. Segundo a documentação oficial, guardar um registo de Program Enrollment num 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).

Esta sincronização automática é relevante porque mostra que a própria Salesforce trata "quem é o candidato" e "que programa o interessa" como camadas distintas do modelo — não como um único blob de dados. Um agente de IA bem desenhado respeita essa mesma separação.

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

Sobre a EDA, o Education Cloud acrescenta 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).

Estes objetos capturam onde o candidato está no funil — candidatura submetida, em revisão, decisão pendente, decisão comunicada — sem misturar essa informação com o conteúdo da avaliação académica em si. Application Decision regista o resultado; não regista as notas subjacentes nem os critérios de avaliação detalhados usados pela comissão de seleção. Essa distinção entre "estado 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 este modelo, sob a marca Agentforce para Educação: competências pré-configuradas cobrem recrutamento, admissões, sucesso estudantil e desenvolvimento institucional, e a própria página de casos de uso descreve um "Student Recruitment Agent" capaz de responder a perguntas de candidatos, agendar visitas ao campus ou explicar o processo de candidatura (Agentforce for Education — Recruitment and Admissions; Salesforce Education AI).

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

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

A lógica por trás das duas últimas linhas não é apenas prudência — é minimização de dados. Um agente conversacional de admissões não precisa de saber a nota de um candidato numa unidade curricular anterior, nem o valor exato de uma bolsa em análise, para responder à pergunta "quando fecha a candidatura ao mestrado?" ou para agendar uma visita ao campus. Dar-lhe acesso de qualquer forma aumenta a superfície de risco sem aumentar a utilidade.

Minimização de dados: o que o RGPD e a CNPD exigem na prática

O princípio de minimização do RGPD (Regulamento 2016/679) obriga a que o tratamento de dados pessoais se limite ao que é adequado, pertinente e necessário para a finalidade em causa. Aplicado a um agente de admissões, isto significa desenhar o acesso a dados objeto a objeto, não conceder uma chave geral ao CRM completo.

A CNPD tem alertado repetidamente para a necessidade de realizar uma Avaliação de Impacto sobre a Proteção de Dados (AIPD) antes de implementar sistemas de IA que tratam dados pessoais em contexto de decisão — incluindo processos de admissão. Consoante o resultado dessa avaliação, a instituição deve prosseguir com o tratamento previsto, aplicar medidas adicionais de mitigação, consultar previamente a CNPD, ou repensar o desenho do sistema. Um agente que só acede às quatro categorias descritas acima — identidade, interesse de programa, consentimento, histórico de interação — reduz substancialmente o âmbito dessa avaliação, porque elimina à partida as categorias de dados mais sensíveis do escopo do tratamento.

Vale também recordar que a A3ES e a DGES não regulam o tratamento de dados pessoais em si — essa competência é da CNPD — mas os critérios de acreditação institucional pressupõem processos de admissão auditáveis. Um agente com âmbito de dados claramente definido e documentado facilita essa auditoria, porque a fronteira entre "o que o agente vê" e "o que fica reservado à equipa humana" está explícita desde o desenho, em vez de ser reconstruída a posteriori.

Como isto se liga a um chatbot como o Skolbot

O Skolbot é concebido como uma camada de IA sobre o CRM existente da escola, incluindo conectores nativos para plataformas como o Salesforce — não como um substituto do Education Cloud. Cada conversa com um prospect é reenviada para o CRM de forma estruturada: perfil do candidato, perguntas colocadas, programa de interesse e pontuação de maturidade do lead.

Na prática, isto aproxima-se do desenho de fronteira descrito acima: o agente lê e escreve nas camadas de identidade, interesse de programa e histórico de interação, e não intervém nos registos académicos ou financeiros que pertencem a outros fluxos de trabalho da instituição. Se está a comparar CRM antes de decidir sobre esta integração, o nosso comparativo de CRM para escolas superiores detalha os critérios de escolha, incluindo a abertura de API que este tipo de conexão exige. Para perceber 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 quadro mais amplo de estratégias de captação, consulte o nosso guia sobre como recrutar mais estudantes no ensino superior privado.