--- title: "Salesforce Education Cloud: Zulassungsdaten für KI-Agenten in AT" description: "Salesforce Education Cloud speichert weit mehr als Zulassungsdaten: Welche Datenkategorien ein KI-Agent an österreichischen Hochschulen lesen darf, und was tabu bleibt." url: "https://www.skolbot.ai/de-AT/blog/education-cloud-zulassungsdaten-ki-agent" language: "de" dateModified: "2026-09-25" --- # Salesforce Education Cloud: Zulassungsdaten für KI-Agenten in AT Aktualisiert am 25. September 2026 Salesforce Education Cloud speichert weit mehr als Zulassungsdaten: Welche Datenkategorien ein KI-Agent an österreichischen Hochschulen lesen darf, und was tabu bleibt. ## 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](https://github.com/SalesforceFoundation/EDA) 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](https://help.salesforce.com/s/articleView?id=sfdo.eda_explained.htm) dokumentiert. Auf diesem Fundament setzt das spezifischere [Recruitment-and-Admissions-Datenmodell](https://www.salesforce.com/agentforce/use-cases/education/recruitment-admissions/) 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](https://help.salesforce.com/s/articleView?id=sfdo.EDA_Program_Enrollment.htm) 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. | Datenkategorie | Typisches Salesforce-Objekt | Lesen | Schreiben | Beispiel | |---|---|---|---|---| | Identität | Contact, Account | Ja | Nur Kontaktaktualisierung | Name, E-Mail, Telefonnummer | | Studieninteresse / Bewerbungsstatus | Program Enrollment, Applicant, Application Stage Definition | Ja | Ja | "Interesse am Bachelor Wirtschaftsinformatik", Status "MedAT-Ergebnis ausstehend" | | Einwilligung / Marketingpräferenz | Contact (Consent-Felder), Individual | Ja | Ja | Opt-in für WhatsApp-Kontakt, Widerspruch gegen Werbe-E-Mails | | Interaktionsverlauf | Case, Activity, Custom Object | Ja | Ja (neue Einträge) | Chatverlauf, gestellte Fragen, besuchte Studiengangsseiten | | Sensible akademische Daten | Course Connection, Academic Certification, Education History | Nein (Standard) | Nein | Notenspiegel, Prüfungsergebnisse, Studienabbrüche | | Finanzierungsdetails | schulspezifische Custom Objects | Nein (Standard) | Nein | Studienbeihilfe-Bescheid, Selbsterhalterstipendium, Ratenzahlungsstatus | 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)](https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=10001597) 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)](https://www.dsb.gv.at/) 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](https://www.aq.ac.at/) 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](https://www.salesforce.com/education/artificial-intelligence/), 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](https://www.salesforce.com/agentforce/use-cases/education/recruitment-admissions/) 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 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](https://www.skolbot.ai/de-AT/blog/crm-hochschulen-vergleich). Wie sich der Interaktionsverlauf eines Chatbots in einen belastbaren Lead-Score übersetzen lässt, beschreibt unser Leitfaden zu [Lead-Scoring in der Studierendengewinnung](https://www.skolbot.ai/de-AT/blog/lead-scoring-studierendengewinnung-hochschulen). ## 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](https://www.skolbot.ai/de-AT/blog/mehr-studierende-gewinnen-hochschulen). Testen Sie Skolbot in 30 Sekunden für Ihre Hochschule ## FAQ ### Darf ein KI-Agent eine Zulassungsentscheidung direkt in Salesforce eintragen? Nein, nicht automatisiert und ohne menschliche Prüfung. Artikel 22 DSGVO schränkt Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung ein, wenn sie ausschließlich auf automatisierter Verarbeitung beruhen. Ein Agent kann die Application Decision vorbereiten und Unterlagen prüfen, die finale Eintragung sollte aber eine Mitarbeiterin oder ein Mitarbeiter bestätigen. ### Welche Salesforce-Objekte sollte ein Zulassungs-Chatbot niemals beschreiben? Course Connection, Academic Certification und Education History, weil sie akademische Leistungsdaten enthalten, sowie schulspezifische Finanzierungsobjekte mit Angaben zur Studienbeihilfe oder zu Ratenzahlungen. Diese Objekte liegen in der Verantwortung von Prüfungsreferat beziehungsweise Studienbeihilfenbehörde, nicht in der eines Recruiting-Agenten. ### Gilt für FH und Privatuniversitäten in Österreich dieselbe Datenschutzbehörde wie für öffentliche Universitäten? Ja. Die [Datenschutzbehörde (DSB)](https://www.dsb.gv.at/) ist für alle österreichischen Hochschulen zuständig, unabhängig davon, ob es sich um eine öffentliche Universität, eine durch AQ Austria akkreditierte Fachhochschule oder eine Privatuniversität handelt. ### Ist eine Salesforce-Feldzuordnung bei Skolbot bereits vollständig vorkonfiguriert? Nein. Skolbot bindet sich generisch als KI-Schicht an bestehende CRM-Systeme an, mit nativen Konnektoren unter anderem für Salesforce. Die genaue Feldzuordnung zum EDA- beziehungsweise Recruitment-and-Admissions-Datenmodell wird pro Hochschule im Rahmen der Einführung gemeinsam mit der IT-Abteilung festgelegt, nicht als fertiges Standardpaket vorausgesetzt. Der Mapping-Workshop aus der Checkliste oben ist genau der Schritt, in dem diese Zuordnung entsteht – bevor der Agent produktiv geht, nicht danach. ### Deckt Agentforce for Education die Datenminimierung automatisch ab? Nein, automatisch nicht. Agentforce liefert vorgefertigte Agent-Skills, die konfiguriert werden müssen – welche Objekte ein konkreter Skill lesen oder schreiben darf, entscheidet weiterhin die Hochschule beziehungsweise ihre IT-Abteilung bei der Einrichtung.