--- title: "Education Cloud: quais dados de admissão um agente de IA deve usar?" description: "Guia técnico sobre quais dados do Salesforce Education Cloud um agente de IA de admissões deve ler e escrever, e quais deve evitar por conformidade LGPD." url: "https://www.skolbot.ai/pt-BR/blog/education-cloud-dados-admissao-agente-ia" language: "pt" dateModified: "2026-09-25" --- # Education Cloud: quais dados de admissão um agente de IA deve usar? Atualizado em 25 de setembro de 2026 Guia técnico sobre quais dados do Salesforce Education Cloud um agente de IA de admissões deve ler e escrever, e quais deve evitar por conformidade LGPD. ## 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](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á 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](https://help.salesforce.com/s/articleView?id=sfdo.EDA_Program_Enrollment.htm)). 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](https://www.salesforce.com/agentforce/use-cases/education/recruitment-admissions/)). 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](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 a seguir resume a fronteira operacional recomendada, alinhada com os objetos que o próprio modelo Education Cloud já separa. | Categoria de dado | Objetos típicos do Education Cloud | O agente de IA deve... | |---|---|---| | Identidade do candidato | Contact, Account | Ler e atualizar dados de contato básicos | | Interesse de curso / etapa do processo seletivo | Affiliation, Program Enrollment, Application Stage Definition | Ler e escrever (registrar interesse, avançar etapa) | | Consentimento e preferência de marketing | Campos de opt-in no Contact, Consent (quando configurado) | Ler antes de qualquer contato; escrever quando o candidato atualiza a preferência | | Histórico de interação/engajamento | Case, Attendance Event, registros de atividade | Ler para personalizar; escrever novas interações | | Registros acadêmicos sensíveis | Application Review, Course Connection, Credential | Nunca ler nem escrever por padrão | | Detalhe de bolsas e financiamento estudantil | Objetos de student finance | Nunca ler nem escrever por padrão | 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)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm) 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)](https://www.gov.br/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](https://www.gov.br/mec) e o [INEP](https://www.gov.br/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](https://sisu.mec.gov.br/) 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 à 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](https://www.skolbot.ai/pt-BR/blog/crm-escolas-superiores-comparativo) 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](https://www.skolbot.ai/pt-BR/blog/lead-scoring-recrutamento-estudantil-escolas). E para o panorama mais amplo de estratégias de captação, consulte nosso guia sobre [como recrutar mais estudantes no ensino superior privado](https://www.skolbot.ai/pt-BR/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 open source 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 acessar as notas dos candidatos? Não, na maioria dos casos de uso de recrutamento e primeiro contato. Perguntas frequentes de um candidato — prazos de inscrição, documentos exigidos, forma de envio — não exigem acesso a Application Review nem a registros acadêmicos detalhados. Reservar esse acesso à equipe humana de admissões limita a exposição de dados sensíveis. ### Quais dados de consentimento o agente deve verificar antes de contatar um candidato? O agente deve ler o status de opt-in de marketing registrado no Contact antes de qualquer comunicação proativa, e deve poder escrever uma atualização sempre que o candidato mudar essa preferência durante a conversa. Isso está diretamente ligado à exigência de base legal para o tratamento prevista na LGPD. ### O Skolbot substitui o Salesforce Education Cloud? Não. O Skolbot é uma camada conversacional que se conecta ao CRM já existente da instituição por meio de conectores, incluindo Salesforce — não substitui o sistema de registro. A instituição mantém o Education Cloud (ou outro CRM) como sistema central; o agente conversacional lê e escreve em um subconjunto definido de dados. ### Como se decide, na prática, quais objetos do Education Cloud um agente pode acessar? Por meio de uma revisão conjunta entre a equipe de admissões, TI e o encarregado de proteção de dados (DPO), objeto a objeto — seguindo o mesmo raciocínio de minimização de uma avaliação de impacto: cada categoria de dado só entra no escopo do agente se houver uma finalidade concreta e documentada para seu uso naquela interação.