KI kann im Customer Relationship Management spürbare Vorteile schaffen. Gesprächsnotizen lassen sich schneller zusammenfassen, Serviceanfragen besser klassifizieren und Vertriebsaktivitäten gezielter vorbereiten. Gleichzeitig verarbeitet ein CRM besonders viele Informationen über Kunden, Ansprechpartner, Interessenten, Partner und Mitarbeiter.
Gerade in gewachsenen Organisationen mit zahlreichen Anwendern, Rollen, Integrationen und Datenquellen reicht es deshalb nicht aus, einzelne KI-Funktionen technisch zu aktivieren. Unternehmen müssen nachvollziehbar erklären können, welche Daten verarbeitet werden, wohin sie übertragen werden, wer die Verantwortung trägt und wie fehlerhafte Ergebnisse erkannt werden.
Diese Fragen kommen nicht nur von Datenschutzbehörden. Auch Kunden, Einkaufsabteilungen, Konzerne, Versicherungen, Wirtschaftsprüfer, Betriebsräte und interne Revisionen verlangen zunehmend belastbare Antworten.
Eine professionelle KI-Governance darf Innovation nicht blockieren. Sie muss aber verhindern, dass aus einem schnellen Test eine unkontrollierte Dauerlösung entsteht.
Der pragmatische Weg besteht deshalb nicht darin, Datenschutz und Governance zu umgehen. Er besteht darin, einen begrenzten, kontrollierten und messbaren Einstieg zu schaffen, aus dem schrittweise eine nachhaltige Governance-Struktur entwickelt werden kann.
Warum KI-Governance zu einem operativen Thema wird
KI ist in Unternehmen längst kein reines Innovationsthema mehr. Nach Angaben von Eurostat nutzten 2025 bereits 20 Prozent der Unternehmen in der Europäischen Union mit mindestens zehn Beschäftigten KI-Technologien. Im Jahr 2024 waren es noch 13,5 Prozent. Bei großen Unternehmen lag der Anteil 2025 bereits bei rund 55 Prozent. Besonders stark verbreiteten sich Anwendungen zur Analyse und Generierung von Sprache – also genau jene Funktionen, die auch bei CRM-, Vertriebs- und Serviceprozessen eingesetzt werden. (European Commission)
Statistik: KI-Einsatz in europäischen Unternehmen
| Kennzahl | Wert | Bedeutung für CRM-Verantwortliche |
|---|---|---|
| Unternehmen mit KI-Einsatz 2023 | 8,1 % | KI war häufig noch auf einzelne Tests oder Fachbereiche begrenzt. |
| Unternehmen mit KI-Einsatz 2024 | 13,5 % | Der Einsatz verbreitete sich deutlich über IT- und Innovationsteams hinaus. |
| Unternehmen mit KI-Einsatz 2025 | 20,0 % | KI wird zunehmend Bestandteil regulärer Geschäftsprozesse. |
| Große Unternehmen mit KI-Einsatz 2025 | 55,03 % | In größeren Organisationen wird KI zum Governance- und Skalierungsthema. |
| Unternehmen mit KI zur Analyse geschriebener Sprache 2025 | 11,8 % | Textanalyse betrifft unmittelbar E-Mails, Gesprächsnotizen und Serviceanfragen. |
| Unternehmen mit KI zur Erzeugung geschriebener oder gesprochener Sprache 2025 | 8,8 % | Generative KI wird zunehmend für Kommunikation und Dokumentation verwendet. |
Quelle: Eurostat. Die statistischen Unternehmensgrößen beziehen sich auf die Beschäftigtenzahl und nicht auf die Zahl der CRM-Anwender. (European Commission)
Mit der steigenden Verbreitung verändert sich die Erwartungshaltung. Ein informeller Test mit synthetischen Beispieldaten wird anders bewertet als ein dauerhaft in das CRM integrierter Assistent. Sobald reale Kundendaten verarbeitet, Ergebnisse gespeichert oder Empfehlungen für operative Entscheidungen verwendet werden, entsteht ein regulärer Unternehmensprozess.
Dieser Prozess muss nicht nur funktionieren. Er muss auch erklärbar, kontrollierbar und dokumentierbar sein.
DSGVO und EU AI Act müssen gemeinsam betrachtet werden
Die Datenschutz-Grundverordnung und der EU AI Act verfolgen unterschiedliche, aber miteinander verbundene Ziele. Die DSGVO regelt die Verarbeitung personenbezogener Daten unabhängig davon, welche Technologie dafür eingesetzt wird. Der AI Act verfolgt einen risikobasierten Ansatz für die Entwicklung und Nutzung bestimmter KI-Systeme.
Der AI Act trat am 1. August 2024 in Kraft. Verbote bestimmter KI-Praktiken und die Anforderungen an KI-Kompetenz gelten seit dem 2. Februar 2025. Governance-Regeln und Vorgaben für General-Purpose-AI-Modelle gelten seit dem 2. August 2025. Weitere Anforderungen treten gestaffelt in Kraft; nach der politischen Einigung zur Vereinfachung des AI Acts sollen bestimmte Hochrisikoanforderungen ab Dezember 2027 beziehungsweise August 2028 gelten. (Digitale Strategie Europa)
Für Unternehmen bedeutet diese Staffelung nicht, dass sie ihre Governance bis zum letzten regulatorischen Stichtag aufschieben können. Kundenfragebögen, Datenschutzprüfungen, Informationssicherheitsbewertungen und Vertragsverhandlungen finden bereits heute statt.
Das Unternehmen muss außerdem unabhängig vom AI Act die Anforderungen der DSGVO erfüllen. Dazu gehören unter anderem Zweckbindung, Datenminimierung, Transparenz, Rechtmäßigkeit, Speicherbegrenzung, Sicherheit und Rechenschaftspflicht. Personenbezogene Daten dürfen nicht allein deshalb an einen KI-Dienst übertragen werden, weil die entsprechende Funktion technisch verfügbar ist. (EUR-Lex)
Nicht jede KI-Funktion im CRM hat dasselbe Risiko
Das Risiko eines KI-Use-Cases hängt nicht allein von der verwendeten Technologie ab. Entscheidend sind der Zweck, die verarbeiteten Daten, der Automatisierungsgrad und die Auswirkungen des Ergebnisses.
Ein Assistent, der eine interne Gesprächsnotiz zusammenfasst, ist anders zu bewerten als ein System, das automatisch entscheidet, welche Kunden kein Angebot erhalten. Ein Vorschlag für die nächste Vertriebsaktivität ist anders einzuordnen als eine automatische Bonitäts- oder Risikobewertung. Eine Serviceklassifizierung nach Produktgruppe ist anders zu behandeln als eine Priorisierung auf Basis vermuteter persönlicher Eigenschaften.
Besondere Aufmerksamkeit ist erforderlich, wenn KI eine Entscheidung wesentlich beeinflusst, die rechtliche oder ähnlich erhebliche Auswirkungen auf eine Person haben kann. Artikel 22 DSGVO enthält hierfür besondere Vorgaben zu ausschließlich automatisierten Entscheidungen. Der Europäische Gerichtshof hat zudem klargestellt, dass auch ein automatisch erzeugter Wahrscheinlichkeitswert relevant sein kann, wenn eine nachfolgende Entscheidung maßgeblich auf diesem Wert beruht. (EUR-Lex)
Für die Governance ist deshalb eine risikobasierte Bewertung sinnvoll. Ein Textentwurf mit anschließender menschlicher Prüfung benötigt andere Kontrollen als eine automatisierte Priorisierung, die unmittelbar operative Konsequenzen auslöst.
Das erste Problem: Unternehmen kennen ihre gesamte KI-Nutzung nicht
KI gelangt selten ausschließlich über ein zentrales Einführungsprojekt in die Organisation. Neue Funktionen werden über CRM-Erweiterungen, Office-Anwendungen, Marketingplattformen, Meeting-Assistenten, Servicewerkzeuge oder individuelle Benutzerkonten verfügbar.
Dadurch entstehen parallele Nutzungsszenarien. Neben freigegebenen Anwendungen existieren persönliche Testkonten. Softwareanbieter aktivieren neue KI-Funktionen innerhalb bestehender Verträge. Mitarbeiter übertragen Gesprächsnotizen oder E-Mails an generative KI-Werkzeuge, weil sie dadurch schneller arbeiten können.
Eine Richtlinie allein löst dieses Problem nicht. Ein Verbot ohne praktikable Alternative führt häufig dazu, dass die Nutzung lediglich unsichtbar weitergeht.
Der erste Governance-Schritt ist deshalb Transparenz. Ein Unternehmen muss wissen, welche KI-Systeme genutzt werden, welchen Zweck sie erfüllen, welche Daten sie verarbeiten und wer dafür verantwortlich ist.
Datenminimierung muss vor der Pseudonymisierung stehen
Ein grundlegender Fehler besteht darin, zunächst einen vollständigen CRM-Datensatz an einen KI-Dienst zu übertragen und anschließend über Schutzmaßnahmen nachzudenken. Der bessere Weg beginnt mit der Frage, welche Informationen für den jeweiligen Use Case tatsächlich erforderlich sind.
Ein Assistent für die Formulierung einer Follow-up-E-Mail benötigt möglicherweise das Gesprächsthema, die vereinbarten nächsten Schritte und einige freigegebene Produktinformationen. Er benötigt aber nicht automatisch die private Mobilnummer des Kontakts, historische Rechnungsdaten, interne Bonitätsmerkmale oder sämtliche bisherigen Serviceeskalationen.
Datenminimierung bedeutet deshalb nicht nur, einzelne Felder auszublenden. Die gesamte Informationsmenge muss auf den konkreten Zweck zugeschnitten werden.
In der technischen Umsetzung haben sich Positivlisten bewährt. Sie definieren ausdrücklich, welche CRM-Felder an eine bestimmte KI-Funktion übergeben werden dürfen. Alle übrigen Daten bleiben standardmäßig gesperrt.
Die Leitfrage lautet nicht:
Welche Daten sollten wir besser entfernen?
Sondern:
Welche Daten benötigt die KI für diesen konkreten Zweck nachweislich?
Anonymisierung, Pseudonymisierung und Maskierung unterscheiden
Die Begriffe Anonymisierung, Pseudonymisierung und Maskierung werden im Unternehmensalltag häufig gleichgesetzt. Rechtlich und technisch bestehen jedoch erhebliche Unterschiede.
Die DSGVO definiert Pseudonymisierung als eine Verarbeitung, bei der personenbezogene Daten ohne zusätzliche, getrennt aufbewahrte Informationen nicht mehr einer bestimmten Person zugeordnet werden können. Pseudonymisierte Daten bleiben jedoch personenbezogene Daten. Sie unterliegen weiterhin der DSGVO. (EUR-Lex)
Nur tatsächlich anonymisierte Daten fallen aus dem Anwendungsbereich des europäischen Datenschutzrechts heraus. Dafür muss eine Identifizierung unter Berücksichtigung des konkreten Kontextes hinreichend ausgeschlossen sein. (Europäischer Datenschutzausschuss)
| Verfahren | Bedeutung | Gilt die DSGVO weiter? | Beispiel aus dem CRM |
|---|---|---|---|
| Datenminimierung | Es werden nur die für den Zweck erforderlichen Informationen verarbeitet. | Ja | Die KI erhält nur Gesprächsanlass und nächste Schritte, nicht die vollständige Kundenakte. |
| Maskierung | Einzelne Werte werden entfernt oder unkenntlich gemacht. | In der Regel ja | Eine E-Mail-Adresse wird durch [E-MAIL] ersetzt. |
| Pseudonymisierung | Direkte Identifikatoren werden ersetzt; eine getrennte Zuordnung bleibt möglich. | Ja | Aus „Max Mustermann“ wird „Kontakt-84721“. |
| Anonymisierung | Eine Identifizierung ist mit vernünftigerweise einsetzbaren Mitteln nicht mehr möglich. | Nein, wenn sie tatsächlich wirksam ist | Aggregierte Analyse von Bearbeitungszeiten ohne identifizierbare Einzelpersonen. |
| Synthetische Daten | Künstlich erzeugte Datensätze bilden Strukturen nach, ohne reale Personen abzubilden. | Nur wenn kein Bezug zu realen Personen besteht | Testdatensatz für die Entwicklung eines KI-Workflows. |
Warum eine echte Anonymisierung im operativen CRM schwierig ist
Das Entfernen von Namen, Telefonnummern und E-Mail-Adressen führt nicht automatisch zu anonymen Daten. Personen können auch indirekt anhand anderer Merkmale identifizierbar bleiben.
In CRM-Systemen gehören dazu beispielsweise das Unternehmen, die Funktion, der Standort, ein konkretes Projekt, Vertragsdetails, persönliche Beschwerden oder besondere Gesprächsinhalte. Je kleiner die relevante Kundengruppe ist, desto leichter kann eine Kombination solcher Informationen auf eine konkrete Person schließen lassen.
Besonders kritisch sind Freitextfelder. Eine Gesprächsnotiz kann eine Person eindeutig beschreiben, obwohl ihr Name bereits entfernt wurde. Auch die Kombination mehrerer scheinbar unkritischer Angaben kann eine Reidentifizierung ermöglichen.
Bei der Pseudonymisierung reicht es deshalb nicht aus, nur einen Namen durch eine Nummer zu ersetzen. Nach den Leitlinien des Europäischen Datenschutzausschusses müssen sämtliche Bestandteile des Datensatzes betrachtet werden. Die zusätzlichen Zuordnungsinformationen müssen getrennt gespeichert und durch technische sowie organisatorische Maßnahmen geschützt werden. Pseudonymisierung muss außerdem immer durch weitere Schutzmaßnahmen ergänzt werden.
Der Europäische Datenschutzausschuss betont auch bei KI-Modellen, dass eine behauptete Anonymität im konkreten Einzelfall geprüft werden muss. Ein Modell sollte nur dann als anonym angesehen werden, wenn eine direkte oder indirekte Identifizierung der betroffenen Personen und die Extraktion ihrer personenbezogenen Daten hinreichend unwahrscheinlich sind. (Europäischer Datenschutzausschuss)
Für operative CRM-Prozesse ist deshalb meist die Pseudonymisierung der realistischere Ansatz. Eine vollständige Anonymisierung eignet sich eher für aggregierte Analysen, Statistik oder die Untersuchung allgemeiner Prozessmuster.
Wie eine pseudonymisierte CRM-KI-Architektur aussehen kann
Für viele operative Anwendungsfälle bietet sich eine Architektur mit einer kontrollierenden Zwischenschicht an:
CRM → Datenschutz- und KI-Gateway → KI-Dienst → Gateway → CRM
Das Gateway kann Bestandteil der CRM-Integration, einer Middleware oder einer unternehmensweiten KI-Plattform sein. Es entscheidet, welche Informationen den kontrollierten Unternehmensbereich verlassen dürfen.
Vor der Übertragung werden nicht benötigte Felder entfernt. Direkte Identifikatoren werden durch zufällig erzeugte Pseudonyme ersetzt. Freitexte werden auf Namen, Kontaktdaten und sensible Inhalte geprüft. Nach der Verarbeitung wird das Ergebnis innerhalb des Unternehmens wieder dem richtigen CRM-Vorgang zugeordnet.
| Originalinformation im CRM | Übertragung an die KI |
|---|---|
| Max Mustermann | Kontakt-84721 |
| max.mustermann@beispiel.de | Nicht übertragen |
| +49 170 1234567 | Nicht übertragen |
| Beispiel GmbH | Kunde-315 oder freigegebener Branchenkontext |
| CRM-Datensatz-ID | Zufällig erzeugtes externes Pseudonym |
| Gesprächsnotiz | Auf den Zweck reduziert und bereinigt |
| Interne Bonitätsbewertung | Nicht übertragen |
| Produktinteresse | Übertragen, sofern für den Use Case erforderlich |
| Vereinbarter nächster Schritt | Übertragen |
| Zuordnungstabelle | Verbleibt im kontrollierten Unternehmensbereich |
Die Zuordnung zwischen „Kontakt-84721“ und dem tatsächlichen Kontakt darf dem KI-Dienst nicht zugänglich sein. Sie sollte getrennt gespeichert, technisch geschützt und nur für autorisierte Prozesse erreichbar sein.
Auch das Pseudonym selbst muss sinnvoll gewählt werden. Eine einfache fortlaufende Kundennummer, eine unveränderte CRM-ID oder eine vorhersehbare Kennung kann unerwünschte Verknüpfungen ermöglichen. Für externe Verarbeitungen sind zufällig erzeugte und auf den jeweiligen Use Case begrenzte Kennungen meist geeigneter.
Die Pseudonymisierung reduziert das Risiko. Sie ersetzt aber weder die Rechtsgrundlage noch die Anbieterprüfung, den Auftragsverarbeitungsvertrag oder die erforderlichen technischen und organisatorischen Maßnahmen.
Nicht nur der Prompt enthält möglicherweise personenbezogene Daten
Bei der Bewertung eines KI-Use-Cases darf nicht ausschließlich der Text betrachtet werden, den ein Anwender in ein Eingabefeld schreibt. Personenbezogene Daten können an mehreren Stellen entstehen oder gespeichert werden.
Dazu gehören die an das Modell übermittelten Eingaben, ergänzende CRM-Daten, automatisch erzeugte Metadaten, Protokolldateien, die KI-Ausgabe und mögliche Zwischenspeicher. Auch Embeddings, Vektordatenbanken und Retrieval-Systeme müssen in die Betrachtung einbezogen werden, wenn daraus Informationen über Personen abgeleitet oder mit CRM-Datensätzen verknüpft werden können.
Die Ausgabe eines KI-Systems kann ebenfalls personenbezogene Daten enthalten. Eine automatisch erstellte Gesprächszusammenfassung oder Kundenbewertung bleibt personenbezogen, wenn sie sich auf eine konkrete Person bezieht.
Unternehmen müssen deshalb den vollständigen Datenfluss dokumentieren. Es reicht nicht aus, lediglich zu erklären, welche Informationen ursprünglich aus dem CRM exportiert wurden.
Besondere Kategorien personenbezogener Daten gesondert behandeln
CRM-Systeme können unbeabsichtigt besonders geschützte Informationen enthalten. Dazu gehören beispielsweise Angaben zur Gesundheit, Religion, politischen Überzeugung oder Gewerkschaftszugehörigkeit.
Diese Informationen stehen häufig nicht in dafür vorgesehenen Feldern. Sie finden sich in Gesprächsnotizen, E-Mails, Beschwerden oder Servicebeschreibungen.
Pseudonymisierung hebt den besonderen Schutz dieser Daten nicht auf. Neben einer Rechtsgrundlage nach Artikel 6 DSGVO müssen bei besonderen Kategorien grundsätzlich zusätzlich die Anforderungen des Artikels 9 DSGVO berücksichtigt werden. (EUR-Lex)
Für normale CRM-KI-Prozesse sollten solche Inhalte deshalb möglichst ausgeschlossen werden. Technische Filter können bestimmte Begriffe und Muster erkennen. Bei uneindeutigen oder besonders sensiblen Vorgängen kann eine manuelle Prüfung oder ein vollständig getrennter Prozess erforderlich sein.
Ein KI-Anbieter muss mehr als gute Funktionen liefern
Bei der Auswahl einer KI-Lösung wird häufig zuerst auf Funktionsumfang, Benutzerfreundlichkeit und Kosten geschaut. Für eine belastbare Governance reichen diese Kriterien nicht aus.
Unternehmen müssen unter anderem wissen, ob der Anbieter Eingaben und Ausgaben speichert, für welche Zwecke er sie verwendet und ob Kundendaten zum Training oder zur Verbesserung allgemeiner Modelle genutzt werden. Ebenso relevant sind Speicherorte, Unterauftragnehmer, Löschfristen, Zugriffsmöglichkeiten und Drittlandtransfers.
Auch die technische Konfiguration muss zur vertraglichen Aussage passen. Eine vertraglich zugesagte kurze Speicherfrist hilft wenig, wenn Protokolle oder Konversationsverläufe innerhalb der Anwendung dauerhaft aktiviert bleiben.
Der Anbieter sollte zudem nachvollziehbar über Änderungen informieren. Modelle, Unterauftragnehmer, Datenflüsse und Produktfunktionen können sich verändern. Eine einmalige Prüfung vor der Einführung reicht deshalb nicht für einen unbegrenzten Betrieb.
Was bei einem Audit tatsächlich nachgewiesen werden muss
Das Unternehmen sollte beantworten können, welche Systeme eingesetzt werden, wer sie freigegeben hat, welche Daten sie verarbeiten und welche Risiken bewertet wurden. Ebenso wichtig sind die technischen Kontrollen, die menschliche Prüfung und der Umgang mit Fehlern oder Änderungen.
| Prüfbereich | Typischer Nachweis |
|---|---|
| KI-Systeme und Funktionen | Zentrales KI- und Use-Case-Register |
| Geschäftlicher Zweck | Dokumentierte Use-Case-Beschreibung |
| Verantwortlichkeit | Benannter Business Owner und technische Verantwortung |
| Verarbeitete Daten | Datenkategorien, Positivlisten und Datenfluss |
| Rechtsgrundlage | Datenschutzrechtliche Bewertung |
| Risiko | Einordnung nach DSGVO, AI Act und interner Methodik |
| Pseudonymisierung | Konzept, Pseudonymisierungsbereich und Schutz der Zuordnung |
| Anbieter | Vertrag, AVV, Speicherorte und Unterauftragnehmer |
| Zugriffsrechte | CRM-Rollen, technische Konten und Berechtigungen |
| Menschliche Kontrolle | Freigabe-, Korrektur- und Übersteuerungsprozess |
| Qualität | Testfälle, Stichproben und definierte Qualitätskriterien |
| Nachvollziehbarkeit | Protokolle, Versionen und dokumentierte Freigaben |
| Vorfälle | Meldeweg, Eskalation und Maßnahmen |
| Schulung | Nachweis über KI-Kompetenz und Nutzungsregeln |
| Regelmäßige Überprüfung | Review-Termine, Kennzahlen und Verantwortliche |
Die Dokumentation muss nicht möglichst umfangreich sein. Entscheidend ist ihre Konsistenz.
Der Anbieterfragebogen darf keine andere Datenverarbeitung beschreiben als das interne Verzeichnis. Die technische CRM-Konfiguration muss den dokumentierten Berechtigungen entsprechen. Die tatsächliche Nutzung darf nicht dauerhaft von der genehmigten Nutzung abweichen.
Zehn Bausteine für eine auditfähige KI-Governance
Eine funktionierende Governance verbindet Organisation, Technik, Datenschutz und Fachprozess. Eine reine KI-Richtlinie ist dafür nicht ausreichend. Ebenso wenig genügt eine technische Schnittstelle, wenn Verantwortlichkeiten und Freigaben ungeklärt bleiben.
Bestehende Datenschutz-, Informationssicherheits- und CRM-Prozesse sollten möglichst erweitert werden. Eine vollständig neue Parallelorganisation erzeugt häufig zusätzlichen Aufwand und unklare Zuständigkeiten.
Die folgenden Bausteine können schrittweise aufgebaut werden. Nicht jeder Baustein muss zum Start vollständig automatisiert sein. Die Grundstruktur sollte jedoch bereits beim ersten produktiven Pilot vorhanden sein.
| Nr. | Vorschlag | Beschreibung | Pragmatischer Einstieg | Nachhaltiger Ausbau |
|---|---|---|---|---|
| 1 | KI-Use-Case-Register | Zentrale Übersicht aller geplanten, getesteten und produktiven KI-Anwendungen | Tabelle mit Zweck, System, Owner und Datenarten | Integration in Architektur-, Datenschutz- und Risikomanagement |
| 2 | Risikoklassifizierung | Bewertung nach Daten, Wirkung und Automatisierungsgrad | Drei Klassen: niedrig, erhöht und kritisch | Detaillierte Methodik mit Freigabegrenzen |
| 3 | Daten-Positivlisten | Festlegung der für einen Use Case zulässigen CRM-Felder | Manuell gepflegte Feldliste | Technisch erzwungene Policies je KI-Funktion |
| 4 | Pseudonymisierungskonzept | Trennung identifizierender Angaben von fachlichen Inhalten | Zufällige Pseudonyme und getrennte Zuordnung | Zentrales Gateway und Schlüsselmanagement |
| 5 | Anbieterprüfung | Bewertung von Verträgen, Speicherung, Training und Unterauftragnehmern | Einheitlicher Anbieterfragebogen | Laufendes Third-Party-Risk-Management |
| 6 | Rollen- und Freigabemodell | Festlegung, wer beantragt, bewertet und freigibt | Business Owner, IT und Datenschutz | Festes Governance-Board mit Eskalationswegen |
| 7 | Menschliche Kontrolle | Definition, welche Ergebnisse geprüft werden müssen | Entwürfe statt automatischer Kommunikation | Risikobasierte Kontrollstufen |
| 8 | Tests und Monitoring | Prüfung von Qualität, Fehlern und unerwünschten Ergebnissen | Definierte Testfälle und Stichproben | Kontinuierliches Monitoring und Drift-Erkennung |
| 9 | KI-Kompetenz | Qualifizierung der Anwender zu Möglichkeiten und Grenzen | Kurze verpflichtende Basisschulung | Rollenbezogene Schulungen und Wiederholungen |
| 10 | Audit Pack | Zusammenführung der relevanten Nachweise | Strukturierter Projektordner | Integriertes Kontroll- und Nachweissystem |
Der pragmatische Weg: Minimum Viable Governance
Unternehmen müssen vor dem ersten kontrollierten Pilotprojekt nicht sofort ein vollständig ausgebautes KI-Managementsystem etablieren. Sie benötigen aber einen belastbaren Mindestrahmen.
Dieser Rahmen kann als Minimum Viable Governance verstanden werden. Er reduziert zunächst Komplexität und Umfang, lässt aber keine zentralen Verantwortungsfragen offen.
Ein Pilot braucht mindestens einen klaren Zweck, einen fachlichen Verantwortlichen, eine definierte Nutzergruppe und eine begrenzte Datenbasis. Zusätzlich müssen die zulässigen Datenfelder, der Anbieter, die menschliche Kontrolle und ein Abbruchmechanismus festgelegt sein.
Die Minimum Viable Governance ist keine dauerhafte Endlösung. Sie ist ein kontrollierter Einstieg, dessen Ergebnisse und Strukturen anschließend ausgebaut werden.
Phase 1: Sofortige Leitplanken schaffen
Der schnellste Einstieg ist eine vorläufige Nutzungsregel für KI im Kundenmanagement. Sie legt fest, welche Werkzeuge genutzt werden dürfen und welche Informationen nicht in öffentliche oder nicht freigegebene KI-Dienste eingegeben werden dürfen.
Parallel sollte eine praktikable freigegebene Alternative bereitgestellt werden. Reine Verbote verhindern die Nutzung oft nicht, sondern verlagern sie in nicht sichtbare Bereiche.
Für einen ersten Pilot werden die Daten bewusst begrenzt. Statt vollständiger Kundenakten können ausgewählte Gesprächsnotizen, freigegebene Produktinformationen oder standardisierte Serviceinhalte genutzt werden.
Besonders sensible Felder, interne Bewertungen und unstrukturierte historische Kommunikationsverläufe bleiben zunächst ausgeschlossen.
Phase 2: KI-Use-Cases inventarisieren und klassifizieren
Im zweiten Schritt werden alle bekannten KI-Anwendungen in einem gemeinsamen Register erfasst. Dazu gehören auch Funktionen, die innerhalb bestehender CRM-, Office-, Marketing- oder Serviceplattformen aktiviert wurden.
Jeder Use Case erhält einen Business Owner. Zusätzlich werden Zweck, Nutzergruppe, Datenkategorien, Anbieter, erwarteter Nutzen und potenzielle Auswirkungen dokumentiert.
Für die erste Einordnung kann ein einfaches Modell mit drei Risikoklassen ausreichen. Interne Formulierungshilfen mit menschlicher Prüfung können beispielsweise als niedriges Risiko bewertet werden. Kundenkommunikation, Priorisierung und personenbezogene Empfehlungen erfordern meist eine intensivere Prüfung. Entscheidungen mit erheblichen Auswirkungen oder besonders geschützten Daten gehören in eine kritische Klasse.
Phase 3: Einen pseudonymisierten Quick Win umsetzen
Ein geeigneter erster Use Case ist ein CRM-Assistent, der aus einer freigegebenen Gesprächsnotiz eine strukturierte Zusammenfassung und einen Vorschlag für die nächsten Schritte erstellt.
Vor der Übertragung entfernt eine technische Zwischenschicht direkte Identifikatoren und nicht benötigte CRM-Felder. Der KI-Dienst erhält ein zufälliges Pseudonym sowie den fachlich notwendigen Gesprächskontext. Die Zuordnung zum realen Kontakt verbleibt im CRM oder in einer kontrollierten Middleware.
Das Ergebnis wird nicht automatisch an den Kunden versendet. Der Anwender prüft und korrigiert den Entwurf, bevor er gespeichert oder weiterverwendet wird.
Für den Pilot werden Qualität, Bearbeitungszeit und Korrekturaufwand gemessen. Gleichzeitig werden ungeeignete Datenfelder, problematische Eingaben und typische Fehler dokumentiert.
Dieser Weg erzeugt Momentum, ohne die Governance zu umgehen. Er liefert einen sichtbaren Nutzen und erzeugt gleichzeitig wiederverwendbare Strukturen für weitere KI-Projekte.
Phase 4: Aus dem Pilot einen kontrollierten Betriebsprozess machen
Nach dem Pilot muss eine bewusste Entscheidung getroffen werden. Der Use Case wird eingestellt, angepasst oder kontrolliert skaliert.
Dafür werden Nutzen, Qualität, Risiken und tatsächliche Nutzung gemeinsam bewertet. Auch die Wirksamkeit der Pseudonymisierung und Datenfilterung muss überprüft werden.
Die Freigabe wird anschließend in die regulären CRM- und IT-Prozesse eingebunden. Neue Funktionen, Datenfelder oder Anbieteränderungen lösen eine erneute Prüfung aus.
Damit wird aus einem Innovationsprojekt ein dauerhaft steuerbarer Unternehmensprozess.
Technische Kontrollen sollten möglichst nah am CRM liegen
Das CRM kennt bereits Benutzer, Rollen, Kundendaten und Prozesse. Deshalb sollten viele Kontrollen möglichst nah an dieser Plattform umgesetzt werden.
Ein KI-Dienst sollte nicht automatisch auf sämtliche Informationen zugreifen dürfen, die ein Anwender theoretisch in der CRM-Oberfläche sehen kann. Für KI-Funktionen sind oft engere Berechtigungen sinnvoll.
Ein Service-Assistent benötigt möglicherweise Produkt-, Vertrags- und Ticketinformationen. Er braucht aber keine internen Vertriebsbewertungen. Ein Vertriebsassistent benötigt nicht automatisch sämtliche Beschwerden und Eskalationen aus dem Service.
Auch bei den Ergebnissen müssen unterschiedliche Automatisierungsstufen vorgesehen werden. Ein Vorschlag, ein gespeicherter Entwurf und eine automatisch ausgeführte Aktion sind nicht dasselbe.
Je höher die Wirkung eines Ergebnisses, desto stärker müssen Prüfung, Protokollierung und Freigabe ausgestaltet sein.
Der pragmatische Audit-Ordner
Relevante Informationen sind in vielen Unternehmen über Ticketsysteme, E-Mails, Vertragsordner und Datenschutzdokumentationen verteilt. Bei einer Kundenanfrage beginnt deshalb eine zeitaufwendige Suche.
Ein zentraler Audit-Ordner schafft schnell Abhilfe. Er enthält für jeden freigegebenen Use Case die aktuelle Beschreibung, den Datenfluss, die Risikoeinstufung, die Freigaben, Verträge, Testnachweise und Ansprechpartner.
Auch das Pseudonymisierungskonzept gehört in diesen Ordner. Dazu zählen die verwendeten Verfahren, der definierte Pseudonymisierungsbereich, der Schutz der Zuordnungsinformationen und die Prüfung möglicher Reidentifikationsrisiken.
Der Audit-Ordner muss nicht ausschließlich aus kopierten Dokumenten bestehen. Stabile Verweise auf das Datenschutzmanagement, das Ticketsystem, die Vertragsverwaltung und das CRM sind ausreichend.
Das Ziel ist eine schnelle und konsistente Antwortfähigkeit. Ein Unternehmen sollte innerhalb kurzer Zeit erklären können, was das System tut, welche Daten es verarbeitet, wie es kontrolliert wird und was bei einem Fehler geschieht.
Praxisbeispiel: Schrittweise Einführung mit messbarem Nutzen
Das folgende Beispiel ist aus mehreren typischen Projektsituationen verdichtet. Unternehmen, Branche und Kennzahlen wurden anonymisiert beziehungsweise zur Veranschaulichung gerundet.
Ein Industrieunternehmen mit rund 140 aktiven CRM-Anwendern wollte KI für Gesprächszusammenfassungen, E-Mail-Entwürfe, Serviceklassifizierung und Opportunity Scoring einsetzen. Ursprünglich war geplant, mehrere Funktionen nahezu gleichzeitig für große Benutzergruppen freizuschalten.
In einer vorgeschalteten Phase wurde zunächst ein KI-Register aufgebaut. Dabei stellte sich heraus, dass bereits fünf Fachbereiche unterschiedliche KI-Werkzeuge testeten. Teilweise wurden Kunden-E-Mails und Gesprächsprotokolle über persönliche Benutzerkonten verarbeitet.
Das Unternehmen entschied sich daher für einen kontrollierten Pilot mit 20 Vertriebsanwendern. Der Assistent erhielt ausschließlich freigegebene Gesprächsinhalte, Produktinformationen und nächste Schritte. Namen, E-Mail-Adressen, Telefonnummern und interne CRM-IDs wurden vor der Übertragung entfernt oder durch zufällige Pseudonyme ersetzt.
Die Zuordnung blieb innerhalb der unternehmenseigenen Integrationsschicht. Der externe KI-Dienst konnte die verarbeiteten Inhalte nicht ohne zusätzliche Informationen einem konkreten CRM-Kontakt zuordnen.
Nach acht Wochen sank der durchschnittliche Dokumentationsaufwand in der Pilotgruppe um rund 35 Prozent. Der Anteil vollständig dokumentierter Folgeschritte stieg von 62 auf 87 Prozent.
Gleichzeitig identifizierte das Projektteam mehrere ungeeignete Felder und Prompt-Vorlagen, bevor diese unternehmensweit verwendet wurden. Besonders interne Bewertungen und umfangreiche Freitexte wurden aus dem Datenfluss entfernt.
In einer zweiten Phase wurde die Serviceklassifizierung ergänzt. Durch iterative Tests stieg die korrekte Erstzuordnung der Tickets im Beispiel von rund 79 auf 91 Prozent.
Erst danach wurde ein Opportunity Scoring untersucht. Dieses wurde bewusst nicht als automatische Entscheidung umgesetzt. Die Bewertung erschien als erklärbarer Hinweis und musste durch den Vertriebsverantwortlichen bestätigt werden.
Nach sechs Monaten zeigte die Pilotgruppe eine um rund vier Prozentpunkte bessere Conversion Rate als eine vergleichbare Ausgangsgruppe. Der Effekt ließ sich nicht ausschließlich auf die KI zurückführen. Messbar war jedoch, dass Folgeschritte schneller durchgeführt, Informationen vollständiger gepflegt und Verkaufschancen strukturierter besprochen wurden.
Der nachhaltige Nutzen lag deshalb nicht nur in der Zeitersparnis. Das Unternehmen verfügte anschließend über ein wiederverwendbares Freigabeverfahren, ein KI-Register, standardisierte Anbieterfragen, ein Pseudonymisierungskonzept und belastbare Audit-Nachweise.
Checkliste für den Einstieg in eine KI-Governance im CRM
Eine Checkliste ersetzt keine individuelle rechtliche oder datenschutzrechtliche Bewertung. Sie macht jedoch zentrale Lücken früh sichtbar. Jede Antwort sollte mit der tatsächlichen technischen Umsetzung im CRM und in den angebundenen Systemen übereinstimmen. Bei erhöhtem Risiko müssen Datenschutz, Informationssicherheit, Rechtsberatung und gegebenenfalls der Betriebsrat frühzeitig eingebunden werden. Wichtig ist außerdem, die Prüfung nicht als einmalige Projektaufgabe zu behandeln, sondern regelmäßig zu wiederholen.
- Alle produktiven, geplanten und getesteten KI-Anwendungen sind in einem zentralen Register erfasst.
- Für jeden KI-Use-Case gibt es einen fachlich verantwortlichen Business Owner.
- Zweck, Nutzergruppe und erwarteter Nutzen sind eindeutig beschrieben.
- Die verarbeiteten CRM-Daten und vollständigen Datenflüsse sind dokumentiert.
- Für jeden Use Case existiert eine Positivliste zulässiger CRM-Felder.
- Nicht benötigte Daten werden vor der Übertragung entfernt.
- Direkte Identifikatoren werden soweit möglich nicht an den KI-Dienst übertragen.
- Für operative Use Cases wurde geprüft, ob eine Pseudonymisierung möglich ist.
- Die Zuordnungsinformationen werden getrennt gespeichert und besonders geschützt.
- Die verwendeten Pseudonyme sind nicht einfach vorhersehbar oder systemübergreifend wiederverwendbar.
- Freitexte werden auf identifizierende und sensible Inhalte geprüft.
- Die Verarbeitung besonderer Kategorien personenbezogener Daten wird verhindert oder gesondert freigegeben.
- Rechtsgrundlage und datenschutzrechtliche Bewertung sind dokumentiert.
- Die Notwendigkeit einer Datenschutz-Folgenabschätzung wurde geprüft.
- Die Einordnung nach dem EU AI Act wurde dokumentiert.
- Anbieter, Speicherorte, Unterauftragnehmer und Drittlandtransfers sind bekannt.
- Eine Vereinbarung zur Auftragsverarbeitung liegt vor, sofern erforderlich.
- Die Nutzung von Eingaben und Ausgaben für das Training des Anbieters ist geklärt.
- Speicher- und Löschfristen sind vertraglich und technisch festgelegt.
- Rollen und Rechte der KI-Anwendung sind im CRM begrenzt.
- Unterstützende Vorschläge und automatisierte Entscheidungen werden klar unterschieden.
- Für relevante Ergebnisse ist eine menschliche Prüfung vorgesehen.
- Testfälle, Qualitätskriterien und akzeptable Fehlergrenzen sind definiert.
- Fehlentscheidungen und problematische Ausgaben können gemeldet werden.
- Änderungen am Modell, Anbieter, Datenfluss oder Use Case lösen eine erneute Prüfung aus.
- Mitarbeiter wurden zu zulässiger Nutzung, Datenschutz und Grenzen der KI geschult.
- Verträge, Bewertungen, Freigaben und Tests sind in einem Audit Pack zusammengeführt.
- Nutzen, Qualität, Risiken und tatsächliche Nutzung werden regelmäßig überprüft.
Fazit: Schnell starten, aber kontrolliert skalieren
Unternehmen müssen nicht warten, bis jede regulatorische Detailfrage abschließend geklärt ist. Sie sollten aber auch nicht zulassen, dass unkontrollierte Einzelversuche dauerhafte Fakten schaffen.
Ein pragmatischer Einstieg beginnt mit einem klar begrenzten Use Case, einer reduzierten Datenbasis, einem verantwortlichen Owner und einer nachvollziehbaren Dokumentation. Wo eine spätere Zuordnung zum CRM-Vorgang erforderlich bleibt, ist eine wirksame Pseudonymisierung meist realistischer als die Behauptung einer vollständigen Anonymisierung.
Die fachlich belastbare Aussage lautet deshalb:
Wir übertragen nur die für den jeweiligen KI-Use-Case erforderlichen Daten. Wo eine Zuordnung zum CRM-Prozess notwendig bleibt, werden personenbezogene Informationen möglichst pseudonymisiert und direkte Identifikatoren entfernt. Eine Anonymisierung wird nur dort angenommen, wo eine Reidentifizierung anhand der Daten und des konkreten Verarbeitungskontexts hinreichend ausgeschlossen werden kann.
Der Quick Win darf nicht zum Ersatz für eine nachhaltige Governance werden. Er sollte vielmehr der erste kontrollierte Schritt auf diesem Weg sein.
Eine gute KI-Governance ist kein Bremsklotz. Sie sorgt dafür, dass erfolgreiche CRM-Use-Cases schneller freigegeben, sicher skaliert und gegenüber Kunden, Auditoren oder Aufsichtsstellen belastbar erklärt werden können.
Hinweis: Der Beitrag berücksichtigt den Informationsstand vom 13. Juli 2026 und ersetzt keine individuelle Rechts- oder Datenschutzberatung.
