Education Cloud: welke toelatingsgegevens gebruikt een AI-agent?

Een AI-toelatingsagent hoort maar een deel van Education Cloud te zien

Een AI-agent die prospects te woord staat, heeft contactgegevens, opleidingsinteresse en gespreksgeschiedenis nodig — niet het volledige Salesforce-schema. Education Cloud bevat ook cijferlijsten, financiële-steundossiers en interne beoordelingen die niets met een eerste gesprek te maken hebben. Wie die scheiding niet vooraf vastlegt, laat een taalmodel zelf bepalen welke velden relevant zijn, en dat is precies het scenario dat de AVG met dataminimalisatie wil voorkomen.

Dit artikel legt uit hoe Salesforce's eigen datamodel voor onderwijs is opgebouwd, welke categorieën data een AI-agent voor werving en toelating wél nodig heeft, welke categorieën principieel buiten bereik blijven, en hoe dit onderscheid in de praktijk aansluit op een chatbot zoals Skolbot.

Wat Education Cloud onder de motorkap bevat

Salesforce Education Cloud is geen apart product met een eigen databasestructuur — het is de standaard Salesforce-omgeving (Account, Contact) uitgebreid met de Education Data Architecture (EDA), een open-source datamodel dat instellingen wereldwijd gebruiken. EDA voegt onderwijsspecifieke objecten toe: Affiliation (de relatie tussen een persoon en een instelling), Relationship, Program Enrollment, Course Connection, Academic Certification, Address, Attendance Event, Case, Course, Credential en Education History. Salesforce beschrijft de volledige structuur in het EDA-overzicht.

Twee van die objecten zijn cruciaal om te begrijpen hoe strak Salesforce zelf al scheidt tussen "wie iemand is" en "wat iemand doet binnen de instelling". Program Enrollment en Affiliation blijven automatisch gesynchroniseerd: zodra een Program Enrollment-record voor een Contact wordt opgeslagen, maakt Salesforce — indien nodig — zelf een Affiliation aan tussen die persoon en het academische programma, en de twee objecten blijven daarna gekoppeld. Dat mechanisme staat gedocumenteerd in de Salesforce-handleiding voor Program Enrollment.

Bovenop EDA bouwt Salesforce's specifieke "Recruitment and Admissions"-datamodel nog een laag toelatingsobjecten: Applicant, Application Decision, Application Review, Application Stage Definition en Application Timeline. Deze objecten leggen precies vast in welke fase een aanvraag zich bevindt en wie welke beoordeling heeft gegeven — zie Salesforce's eigen "Recruitment & Admissions"-pagina over Agentforce for Education. Voor een IT-manager is het relevante punt niet de volledigheid van dit schema, maar dat Salesforce het al opdeelt in duidelijk afgebakende lagen. Die lagen zijn het startpunt om te bepalen wat een AI-agent mag zien.

Vier datacategorieën, vier verschillende toegangsniveaus

Vertaal de EDA-lagen naar een praktisch model met vier categorieën. Elke categorie heeft een ander toegangsniveau voor een AI-agent die met prospects en kandidaten praat.

Identiteit en contactgegevens komen overeen met het Contact-object: naam, e-mailadres, telefoonnummer, land van herkomst. Een agent heeft dit nodig om een gesprek te kunnen linken aan een bestaand dossier en een dubbele registratie te voorkomen.

Opleidingsinteresse en aanvraagstatus zitten in Program Enrollment, Affiliation en Application Stage Definition. Dit is de kern van waar een toelatingsagent op stuurt: welk programma trekt de aandacht, in welke fase zit de aanvraag, is er al een open dag bezocht. Zonder deze laag kan een agent geen relevant vervolgadvies geven.

Toestemming en marketingvoorkeur horen bij het Contact- of Lead-record maar verdienen een aparte categorie, omdat de AVG hier een expliciete grondslag eist. Een agent mag een prospect alleen via e-mail of WhatsApp opvolgen als die toestemming vastligt — niet omdat het CRM het veld toevallig bevat.

Interactiegeschiedenis (welke vragen zijn gesteld, welke pagina's bezocht, welke gesprekken gevoerd) wordt door de agent zelf gegenereerd en teruggeschreven, meestal als activiteit of aangepast veld op het Contact- of Lead-record.

Daar tegenover staan twee categorieën die Education Cloud wél bevat, maar die een AI-recruitment-agent niet als standaardtoegang hoort te krijgen. Gevoelige academische gegevens — cijferlijsten, tuchtdossiers, individuele beoordelingen in Application Review — vallen onder Course Connection, Academic Certification en Application Review, en zijn bedoeld voor toelatingscommissies, niet voor een chatgesprek met een prospect. Financiële-steundetails (beurzen, betalingsregelingen, individuele financiële situatie) vragen een aparte autorisatie en horen niet standaard in de context van een wervingsgesprek thuis.

Het onderscheid is geen esthetische keuze. Het is een direct gevolg van het AVG-beginsel van dataminimalisatie: een AI-agent mag alleen verwerken wat noodzakelijk is voor het doel van het gesprek, en "toegang tot het hele CRM" is zelden dat doel.

Overzichtstabel: wat een AI-agent leest, schrijft of nooit ziet

Waarom Salesforce zelf al richting AI-agents beweegt

Salesforce positioneert dit onderscheid inmiddels ook commercieel. Onder de noemer "Agentforce for Education" verkoopt het bedrijf voorgebouwde agent-vaardigheden voor werving, toelating, studentsucces en fondsenwerving, gebouwd bovenop de Education Cloud-datastructuur. Op de eigen use-case-pagina voor recruitment en admissions beschrijft Salesforce een "Student Recruitment Agent" die vragen van kandidaten beantwoordt, campusbezoeken inplant en het aanvraagproces uitlegt — met andere woorden, precies de opleidingsinteresse- en interactielaag uit de tabel hierboven, niet de academische of financiële laag. Zie ook de algemene AI-pagina van Salesforce voor onderwijs voor de bredere productlijn.

Dat Salesforce zelf deze scheiding aanhoudt, is een nuttig ijkpunt voor een instelling die een extern AI-systeem — zoals een chatbot van een derde partij — op Education Cloud wil aansluiten. Als de architect van het CRM een gelaagde toegang voorstelt, is een integratie die in plaats daarvan om volledige API-rechten op het hele schema vraagt een waarschuwingssignaal, niet een teken van efficiëntie.

Hoe dit in de praktijk landt op de AVG en de AP

De Autoriteit Persoonsgegevens toetst geautomatiseerde verwerking primair op doelbinding en dataminimalisatie: mag deze verwerking, met dit doel, op basis van deze gegevens. Voor een toelatingsagent betekent dat een heldere doelomschrijving — "prospects informeren en kwalificeren voor een programma" — die per definitie geen toegang tot cijferlijsten of financiële dossiers rechtvaardigt. Documenteer daarom, voordat een AI-agent wordt gekoppeld aan Education Cloud, welke objecten en velden de agent mag lezen en schrijven, wie dat besluit heeft goedgekeurd, en hoe lang gespreksdata wordt bewaard.

Voor Nederlandse hogescholen en universiteiten komt daar een tweede laag bovenop: gegevens die via Studielink binnenkomen, vallen onder een ander wettelijk kader dan gegevens die een prospect zelf via een chatgesprek deelt. NVAO-geaccrediteerde opleidingen moeten bovendien kunnen aantonen dat toelatingsbeslissingen navolgbaar zijn — een AI-agent die zelf toelatingsbeslissingen zou nemen op basis van Application Review-data zou die navolgbaarheid juist ondermijnen. Zolang de agent zich beperkt tot voorlichting, kwalificatie en het bijwerken van contact- en interessevelden, blijft die vraag grotendeels buiten beeld.

Hoe een chatbot als Skolbot dit in de praktijk toepast

Skolbot is opgezet als een AI-laag bovenop het CRM dat een instelling al gebruikt, inclusief native connectoren zoals Salesforce, niet als vervanging ervan. Elk gesprek met een prospect wordt teruggekoppeld naar het CRM: profiel, gestelde vragen, opleidingsinteresse en lead-score. Dat komt overeen met precies de categorieën "identiteit", "opleidingsinteresse" en "interactiegeschiedenis" uit de tabel hierboven — de lagen die een wervingsgesprek nodig heeft, niet de academische of financiële lagen die daarbuiten vallen.

Voor een vergelijking van CRM-opties voor hoger onderwijs, inclusief Salesforce, leest u ons artikel over CRM voor hoger onderwijs: vergelijking en AI-integratie. Hoe die interactiegegevens vervolgens gebruikt worden om kandidaten te prioriteren, staat beschreven in onze gids over lead scoring voor studentenwerving. Voor de bredere wervingsstrategie waar dataintegratie onderdeel van is, zie onze gids over meer studenten werven in het hoger onderwijs.