--- title: "Education Cloud: que dados de admissão um agente de IA deve usar?" description: "Guia técnico sobre que dados do Salesforce Education Cloud um agente de IA de admissões deve ler e escrever, e quais deve evitar por conformidade RGPD." url: "https://www.skolbot.ai/pt/blog/education-cloud-dados-admissao-agente-ia" language: "pt" dateModified: "2026-09-25" --- # Education Cloud: que dados de admissão um agente de IA deve usar? Atualizado em 25 de setembro de 2026 Guia técnico sobre que dados do Salesforce Education Cloud um agente de IA de admissões deve ler e escrever, e quais deve evitar por conformidade RGPD. ## 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](https://github.com/SalesforceFoundation/EDA); [explicação da EDA no Salesforce Help](https://help.salesforce.com/s/articleView?id=sfdo.eda_explained.htm)). 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](https://help.salesforce.com/s/articleView?id=sfdo.EDA_Program_Enrollment.htm)). 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](https://www.salesforce.com/agentforce/use-cases/education/recruitment-admissions/)). 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](https://www.salesforce.com/agentforce/use-cases/education/recruitment-admissions/); [Salesforce Education AI](https://www.salesforce.com/education/artificial-intelligence/)). ## 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. | Categoria de dados | Objetos Education Cloud típicos | Agente de IA deve... | |---|---|---| | Identidade do candidato | Contact, Account | Ler e atualizar dados de contacto básicos | | Interesse de programa / fase de candidatura | Affiliation, Program Enrollment, Application Stage Definition | Ler e escrever (registar interesse, avançar fase) | | Consentimento e preferência de marketing | Campos de opt-in no Contact, Consent (quando configurado) | Ler antes de qualquer contacto; escrever quando o candidato atualiza a preferência | | Histórico de interação/engagement | Case, Attendance Event, registos de atividade | Ler para personalizar; escrever novas interações | | Registos académicos sensíveis | Application Review, Course Connection, Credential | Nunca ler nem escrever por padrão | | Detalhe de apoio financeiro | Objetos de student finance | Nunca ler nem escrever por padrão | 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)](https://eur-lex.europa.eu/legal-content/PT/TXT/?uri=CELEX%3A32016R0679) 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](https://www.cnpd.pt) 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](https://www.a3es.pt) e a [DGES](https://www.dges.gov.pt) 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 à 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](https://www.skolbot.ai/pt/blog/crm-escolas-superiores-comparativo) 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](https://www.skolbot.ai/pt/blog/lead-scoring-recrutamento-estudantil-escolas). 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](https://www.skolbot.ai/pt/blog/recrutar-mais-estudantes-ensino-superior). --- Teste o Skolbot na sua escola em 30 segundos ## FAQ ### O que é a Education Data Architecture (EDA)? A EDA é o modelo de dados de código aberto que estende os objetos padrão Account e Contact do Salesforce com objetos específicos do ensino superior — Affiliation, Program Enrollment, Course Connection, entre outros. É a base sobre a qual o Education Cloud constrói os módulos de recrutamento, admissões e sucesso estudantil ([Salesforce Help — EDA](https://help.salesforce.com/s/articleView?id=sfdo.eda_explained.htm)). ### Um agente de IA de admissões precisa de acesso às notas dos candidatos? Não, na maioria dos casos de uso de recrutamento e primeiro contacto. Perguntas frequentes de um candidato — prazos, requisitos de candidatura, forma de submeter documentos — não requerem acesso a Application Review nem a registos académicos detalhados. Reservar esse acesso à equipa humana de admissões limita o âmbito de exposição de dados sensíveis. ### Que dados de consentimento o agente deve verificar antes de contactar um candidato? O agente deve ler o estado de opt-in de marketing registado no Contact antes de qualquer comunicação proativa, e deve poder escrever uma atualização sempre que o candidato altere essa preferência durante a conversa. Isto está diretamente ligado à obrigação de licitude do tratamento prevista no RGPD. ### O Skolbot substitui o Salesforce Education Cloud? Não. O Skolbot é uma camada conversacional que se liga ao CRM existente da escola através de conectores, incluindo Salesforce — não substitui o sistema de registo. A escola mantém o Education Cloud (ou outro CRM) como sistema central; o agente conversacional lê e escreve num subconjunto definido de dados. ### Como se decide, na prática, que objetos do Education Cloud um agente pode aceder? Através de uma revisão conjunta entre a equipa de admissões, TI e o responsável de proteção de dados, objeto a objeto — seguindo o mesmo raciocínio de minimização usado numa AIPD: cada categoria de dados só entra no âmbito do agente se houver uma finalidade concreta e documentada para a sua utilização nessa interação.