Salesforce Education Cloud: Zulassungsdaten für KI-Agenten in AT

Ein KI-Agent braucht nur einen Ausschnitt Ihrer Education-Cloud-Daten

Ein KI-Agent für Zulassungsgespräche sollte in Salesforce Education Cloud vier Datenkategorien lesen und schreiben dürfen: Identität, Studieninteresse und Bewerbungsstatus, Einwilligung und Marketingpräferenz sowie Interaktionsverlauf. Notenspiegel, Prüfungsergebnisse und Details zur Studienbeihilfe gehören nicht in seinen Standard-Zugriffsbereich.

Diese Abgrenzung ist keine Vorsichtsmaßnahme aus Prinzip, sondern folgt aus dem, was Studieninteressierte tatsächlich fragen. An österreichischen Fachhochschulen und Privatuniversitäten gibt es kein zentrales Zulassungsportal wie in Deutschland – Bewerbungen laufen direkt bei der jeweiligen Hochschule, oft über ein eigenes Online-System, für Medizin zusätzlich über den zentralen Aufnahmetest MedAT. Die häufigsten Fragen drehen sich um Fristen, fehlende Unterlagen oder den nächsten Infotag, und all das lässt sich mit den vier genannten Datenkategorien beantworten.

Für Studiengangs- und Digitalisierungsleitungen, die Salesforce Education Cloud an einer FH oder Privatuniversität einsetzen oder evaluieren, ist diese Frage vor allem eine Architekturentscheidung: Welches Objektmodell hat Salesforce, und welcher Ausschnitt davon sollte über eine Agenten-Schnittstelle erreichbar sein? Der Rest dieses Artikels beantwortet beides.

Was Salesforce Education Cloud tatsächlich speichert: das EDA-Datenmodell

Salesforce Education Cloud baut auf der Education Data Architecture (EDA) auf – einem offenen Datenmodell, dessen Quellcode öffentlich auf GitHub liegt. EDA erweitert die Standardobjekte Account und Contact um bildungsspezifische Objekte, die eine Person und ihre Beziehungen zur Hochschule abbilden: Affiliation, Relationship, Program Enrollment, Course Connection, Academic Certification, Address, Attendance Event, Case, Course, Credential und Education History, wie Salesforce im EDA-Überblick dokumentiert.

Auf diesem Fundament setzt das spezifischere Recruitment-and-Admissions-Datenmodell auf. Es bringt Objekte mit, die ausschließlich für den Bewerbungsprozess existieren: Applicant, Application Decision, Application Review, Application Stage Definition und Application Timeline. Ein Bewerbungsstatus wie "Unterlagen unvollständig" oder "MedAT-Ergebnis ausstehend" lebt in genau diesen Objekten – getrennt von akademischen Leistungsdaten, die in Course Connection oder Academic Certification liegen.

Program Enrollment und Affiliation: ein Beispiel für die Verzahnung

Die Objekte in EDA sind eng miteinander verknüpft, und ein Beispiel macht das konkret: Speichert Salesforce einen Program-Enrollment-Datensatz für einen Contact, legt das System automatisch eine Affiliation zwischen diesem Contact und dem Studienprogramm an – sofern noch keine existiert – und hält beide Datensätze danach synchron, wie Salesforce zu Program Enrollment beschreibt.

Für die Frage nach dem KI-Agenten-Zugriff heißt das: Wer ein Objekt beschreibt, berührt oft automatisch verknüpfte Objekte mit. Ein Zugriffskonzept, das nur auf Objektebene ansetzt ("Applicant: Lesen und Schreiben erlaubt"), reicht deshalb nicht – es braucht auch eine Vorstellung davon, welche Folgeeffekte ein Schreibzugriff über verknüpfte Objekte auslöst.

Dieselbe Verzahnung gilt in die andere Richtung: Ein Contact, der über Affiliation mit mehreren Programmen verbunden ist – etwa weil er sich sowohl für ein FH-Bachelorstudium als auch für ein Programm an einer Privatuniversität informiert hat –, liefert einem Agenten, der nur auf Program Enrollment zugreift, bereits ein vollständiges Bild des Interesses, ohne dass er auch nur ein Feld aus Course Connection einsehen müsste. Die Scope-Frage lässt sich also nicht pauschal mit "mehr Zugriff bedeutet bessere Antworten" beantworten – oft liefert der schmalere Ausschnitt bereits das, was für ein Zulassungsgespräch nötig ist.

Vier Datenkategorien für Lesen und Schreiben – zwei für nie

Die folgende Einteilung orientiert sich am Recruitment-and-Admissions-Modell und trennt, was ein Zulassungs-Agent an einer FH oder Privatuniversität aktiv braucht, von dem, was in der Verantwortung menschlicher Teams bleiben sollte.

Die ersten vier Zeilen sind Daten, die ein Prospect selbst im Gespräch preisgibt oder die unmittelbar aus diesem Gespräch entstehen. Die letzten beiden Zeilen haben eine andere Verantwortungskette: akademische Bewertung liegt bei Lehrenden und Prüfungsreferat, Finanzierungsdetails bei der Studienbeihilfenbehörde. Ein KI-Agent, der hier lesend oder schreibend eingreift, verschiebt eine Entscheidung dorthin, wo sie nicht hingehört.

Warum Datenminimierung hier Architekturprinzip ist, nicht nur DSGVO-Pflicht

Die DSGVO gilt in Österreich unmittelbar und wird durch das österreichische Datenschutzgesetz (DSG) ergänzt. Artikel 5 DSGVO verlangt Datenminimierung als Grundsatz: Verarbeitung nur, soweit sie für den jeweiligen Zweck angemessen und erheblich ist. Zuständige Aufsichtsbehörde ist in Österreich die Datenschutzbehörde (DSB) mit Sitz in Wien – nicht der BfDI, der ausschließlich für Deutschland zuständig ist.

Für eine FH oder Privatuniversität, die durch AQ Austria akkreditiert ist, ist das kein abstraktes Prinzip – es ist der Maßstab, an dem eine API-Berechtigung im Streitfall gemessen wird. Der praktische Nutzen liegt aber woanders: Ein API-User, der ausschließlich die vier oben genannten Objektgruppen lesen und schreiben darf, begrenzt den Schaden im Fall eines kompromittierten Zugangs von vornherein und macht Audits einfacher, weil jede Schreibaktion des Agenten in einem klar abgegrenzten Datenraum stattfindet.

Ein zweiter Punkt betrifft automatisierte Entscheidungen. Artikel 22 DSGVO schränkt Entscheidungen ein, die ausschließlich auf automatisierter Verarbeitung beruhen und rechtliche oder ähnlich erhebliche Wirkung entfalten – eine Zulassungsentscheidung gehört in diese Kategorie. Ein KI-Agent kann Vorqualifizierung übernehmen und Informationen sammeln, die finale Application Decision sollte aber bei einem Menschen bleiben, der die gesammelten Daten einsieht und bestätigt.

Agentforce for Education: wohin Salesforce selbst steuert

Salesforce vermarktet mittlerweise eigene KI-Agenten für den Bildungsbereich unter dem Namen Agentforce for Education, aufgesetzt auf denselben Education-Cloud-Daten. Das Angebot umfasst vorgefertigte Agent-Skills für Recruitment, Zulassung, Studienerfolg und Advancement. Für die Zulassungsphase beschreibt Salesforces eigene Use-Case-Seite einen "Student Recruitment Agent", der Fragen von Studieninteressierten beantwortet, Campusführungen terminiert oder den Bewerbungsprozess erklärt.

Das ist relevant, weil es zeigt, wohin sich das Feld bewegt: Salesforce selbst grenzt seine Agenten-Skills entlang ähnlicher Kategorien ab – Recruitment-Funktionen greifen auf Bewerbungs- und Kontaktdaten zu, nicht pauschal auf das gesamte Schema. Ob eine Hochschule einen nativen Salesforce-Agenten, einen separaten Chatbot oder beides parallel betreibt, ändert an dieser Grundfrage nichts: Die Zugriffsgrenzen sollten sich am Zweck orientieren, nicht an dem, was technisch möglich wäre.

Wie das in der Praxis mit einem Chatbot wie Skolbot zusammenhängt

Skolbot ist als KI-Schicht über dem bestehenden CRM einer Hochschule konzipiert, nicht als dessen Ersatz. Über native Konnektoren, darunter Salesforce, wird jedes Gespräch mit einem Studieninteressierten ins CRM zurückgespielt: Profil, gestellte Fragen, Studienprogramm von Interesse und Lead-Score.

Die exakte Feldzuordnung zum EDA- beziehungsweise Recruitment-and-Admissions-Modell hängt von der individuellen Salesforce-Konfiguration jeder Hochschule ab – dieses Mapping wird im Rahmen der Einführung gemeinsam mit der IT-Abteilung abgestimmt, nicht pauschal vorausgesetzt. Genau deshalb lohnt sich die Kategorisierung aus diesem Artikel als Ausgangspunkt für das erste Gespräch mit der Digitalisierungsleitung: Sie legt fest, welche Objektgruppen für einen Agenten überhaupt zur Debatte stehen, bevor ein einziges Feld gemappt wird.

Mehr zur Auswahl und zum Vergleich von CRM-Systemen für Hochschulen, inklusive Salesforce, lesen Sie in unserem CRM-Vergleich für Hochschulen. Wie sich der Interaktionsverlauf eines Chatbots in einen belastbaren Lead-Score übersetzen lässt, beschreibt unser Leitfaden zu Lead-Scoring in der Studierendengewinnung.

Checkliste für IT- und Digitalisierungsverantwortliche

• Mapping-Workshop vor Freigabe: Objektgruppen aus der Tabelle oben gemeinsam mit IT, Datenschutzbeauftragtem und Fachbereich durchgehen, bevor ein Agent produktiv geschaltet wird.
• Zugriffsrechte auf Objektebene, nicht über einen pauschalen API-User mit vollem Schema-Zugriff.
• Consent-Feld vor jedem Schreibzugriff prüfen – ein Agent sollte keine Marketingpräferenz überschreiben, ohne die aktuelle Einwilligung zu kennen.
• Audit-Log für jede Schreibaktion des Agenten, getrennt nachvollziehbar von manuellen Änderungen durch Mitarbeitende.
• Menschliche Letztentscheidung bei der Application Decision beibehalten, auch wenn der Agent die Vorqualifizierung übernimmt.

Wer diese Fragen vor der Anbindung eines Chatbots klärt, spart sich eine nachträgliche Korrektur der Zugriffsrechte – und liefert der eigenen Datenschutzbeauftragten beziehungsweise dem DSB-Ansprechpartner eine dokumentierte Antwort, bevor sie danach fragt. Für die strategische Ebene dahinter – warum ein spezialisierter Chatbot überhaupt Teil der Recruiting-Strategie an einer FH oder Privatuniversität werden sollte – lohnt sich unser Leitfaden mehr Studierende gewinnen.