KI-Agenten im KMU: Warum Namen schwärzen noch keine Anonymisierung ist

Du willst einen KI-Agenten in deinem Betrieb ausprobieren, und die erste Frage aus dem Team lautet: „Dürfen wir da überhaupt Kundendaten reingeben?" Die ehrliche Antwort: Kommt darauf an, was du mit den Daten vorher machst. Und genau da liegt der häufigste Denkfehler. Viele glauben, mit dem Schwärzen von Namen sei der Datenschutz erledigt. Ist er nicht. In diesem Beitrag zeige ich dir am Beispiel eines Service-Ticket-Agenten, wo die Grenze zwischen Pseudonymisierung und Anonymisierung verläuft, warum sie über deine DSGVO-Pflichten entscheidet und wie ein vorgeschaltetes Datenschutz-Gateway den Pilot praktikabel macht.

Was einen guten ersten Agent-Piloten ausmacht

Ein tauglicher Einstieg hat fünf Eigenschaften: ein eng begrenzter Geschäftsprozess, verlässliche Unternehmensdaten, messbare Kennzahlen, geringe Anfangsautonomie und eine menschliche Freigabe, bevor irgendetwas finanziell, rechtlich oder personell wirksam wird.

Das ist keine Vorsichts-Folklore, sondern deckt sich mit dem, was Großunternehmen dokumentiert haben. PwC empfiehlt für den Mittelstand ausdrücklich fokussierte Piloten mit Kosten-Nutzen-Messung und einer anschließenden „Scale or Stop"-Entscheidung. SAPs Joule-Agenten konzentrieren sich ebenfalls auf konkrete Prozesse: Rechnungsklärung, Fallklassifikation, Wissenssuche, Serviceunterstützung. Kein autonomer Alleskönner, sondern ein Werkzeug pro Prozess.

Als erste Piloten eignen sich besonders:

• Interne Wissenssuche über freigegebene Dokumente, mit wenig oder keinem Personenbezug
• Service-Ticket-Klassifikation mit pseudonymisierten Eingaben
• Rechnungs- und Gutschriftenklärung, zunächst nur mit Handlungsempfehlungen
• Controlling-Kommentare auf aggregierten Daten
• Technische Dokumentation und Wartungsunterstützung

Nicht als ersten Piloten würde ich Bewerberauswahl, Mitarbeiterbewertung, Kündigungs-, Bonus- oder Bonitätsentscheidungen wählen. Hier treffen Artikel 22 DSGVO, Arbeitsrecht, Diskriminierungsrisiken und teilweise die Hochrisikovorgaben der europäischen KI-Verordnung aufeinander. Das ist kein Terrain für den Lernprozess.

Und noch ein Filter davor: Prüfe zuerst, ob du überhaupt einen Agenten brauchst. In den meisten KMU-Fällen reicht ein deterministischer Arbeitsablauf, in dem die KI nur einen klar umrissenen Schritt übernimmt. Autonomie ist etwas, das sich ein System verdienen muss.

Das Beispiel: Ein Agent für Service-Tickets

Nehmen wir einen Maschinenbau- oder Servicebetrieb mit 50 bis 500 Beschäftigten. Der Agent soll eingehende E-Mails lesen, Produkt und Fehlerbild erkennen, den Fall kategorisieren, eine Lösung aus der internen Wissensbasis suchen und einen Antwortentwurf erstellen. Freigeben tut ein Mensch. Der Ablauf: Ticket kommt rein -> Agent klassifiziert -> Agent sucht Lösung -> Entwurf entsteht -> Servicemitarbeiter prüft und versendet.

Ein echtes Ticket sieht so aus:

Anna Meier, anna.meier@beispiel.de, Kundennummer 18473, Müller Medizintechnik GmbH, meldet am 17.07. um 10:41 Uhr, dass Maschine MX-200 mit Seriennummer 87291 im Laborraum 3 ausfällt. Fehler E241. Ansprechpartner vor Ort ist Herr Schmidt. Im Anhang ein Foto des Typenschilds.

Da stecken deutlich mehr identifizierende Informationen drin als nur Name und E-Mail-Adresse: Kunden- und Seriennummer, exakter Zeitpunkt, Einsatzort, ein zweiter Ansprechpartner, die IP-Adresse aus dem Mail-Header, Metadaten im Foto. Und weil es um Medizintechnik im Labor geht, sind sogar Rückschlüsse auf einen sensiblen Einsatzkontext möglich.

Was der Agent stattdessen bekommt:

Kunde ORG-7F21, Kontakt PERSON-A12, Region Süddeutschland, Produkt MX-200, Fehler E241, Ausfall im laufenden Betrieb, Priorität hoch. Foto zeigt Typenschild, identifizierende Felder abgedeckt.

Die Zuordnung PERSON-A12 zu Anna Meier liegt in einem getrennten System. Nach der KI-Verarbeitung setzt das Ticketsystem den echten Namen wieder ein, damit die Antwort beim Kunden ankommt.

Pseudonymisierung ist nicht Anonymisierung

Das Beispiel oben ist Pseudonymisierung, keine Anonymisierung. Weil die Rückzuordnung beabsichtigt und möglich ist, bleiben die Daten personenbezogen, und die DSGVO gilt vollständig. Der Europäische Datenschutzausschuss stellt das in seinen Leitlinien zur Pseudonymisierung ausdrücklich klar.

Wichtig ist: Für den operativen Serviceprozess ist das auch richtig so. Du musst den Kunden ja wieder kontaktieren können. Eine echte Anonymisierung würde den Geschäftszweck zerstören. Pseudonymisierung senkt das Risiko und ist als Schutzmaßnahme genau das, was die Aufsichtsbehörden sehen wollen. Sie befreit dich nur nicht von den Pflichten.

Anders sieht es aus, wenn du aus den Fällen Statistik machen willst, etwa für die Qualitätsanalyse. Dann reichen generalisierte Angaben: Monat statt Zeitstempel, Region statt Adresse, Produktgruppe statt Seriennummer, Größenklassen statt exakter Werte. Dazu gehören Regeln wie Mindestgruppengrößen, das Zusammenfassen seltener Kombinationen und der Verzicht auf Freitext-Übernahme.

Die aktuell zur Konsultation gestellten Anonymisierungsleitlinien des EDSA prüfen dafür drei Fragen: Kann ein einzelner Datensatz herausgegriffen werden? Kann er mit anderen Informationen verknüpft werden? Können sensible Eigenschaften über eine Person abgeleitet werden? Erst wenn alle drei praktisch ausgeschlossen sind, sind Daten belastbar anonym. Und selbst dann ist Anonymität kein Dauerzustand: Neue externe Datenquellen können einen heute anonymen Datensatz morgen wieder identifizierbar machen.

Im go4ai-Wiki läuft das unter dem Merksatz „Anonymisieren zuerst, prompten danach", mit einer wichtigen Ergänzung: Namen weglassen reicht oft nicht. „Der Steuerberater aus Hagen mit acht Mitarbeitern" ist identifizierbar, auch ohne Namensnennung. Auch technisch gilt das: Ein gehashter Name lässt sich über Vergleichslisten häufig zurückrechnen, und selbst ein Verfahren mit geheimem Schlüssel bleibt Pseudonymisierung, solange die Zuordnung existiert.

Das Datenschutz-Gateway: sechs Stufen vor dem Modell

Damit das im Alltag nicht an Disziplin einzelner Mitarbeiter hängt, gehört die Bereinigung in die Architektur, nicht in die Schulungsunterlage. Ein vorgeschaltetes Datenschutz-Gateway arbeitet in sechs Stufen:

1. Zweck festlegen. Nicht „wir wollen KI einsetzen", sondern: „Der Agent ordnet Servicefälle einer von zwölf Kategorien zu und erstellt Antwortentwürfe aus freigegebenen Handbüchern." Dann pro Datenfeld fragen: Braucht die KI das wirklich? Für die Fehlerklassifikation braucht sie Fehlercode und Produktmodell, aber weder Name noch Kontonummer.
2. Direkte Identifikatoren tokenisieren. Namen, Kontaktdaten, Kunden- und Vertragsnummern, Bankverbindungen, IP-Adressen. Die Zuordnungstabelle liegt getrennt, verschlüsselt und nur für wenige Systeme zugänglich.
3. Indirekte Identifikatoren generalisieren. Geburtsdatum wird Altersgruppe, Zeitpunkt wird Kalenderwoche, Ort wird Region, seltene Kategorien werden zusammengefasst. Verfahren wie k-Anonymität (jede Merkmalskombination kommt mindestens k-mal vor) helfen, sind aber kein Freifahrtschein.
4. Freitext und Anhänge bereinigen. Der in der Praxis kritischste Teil: Namen im Fließtext, IBAN in der Signatur, Gesundheitsangaben im Beschreibungsfeld, Text auf Fotos, Metadaten in Dokumenten. Kein Filter erreicht hundert Prozent, deshalb gehören Stichproben-Kontrollen dazu.
5. Aggregieren für Statistik. Mindestgruppengrößen, Unterdrückung seltener Fälle, gegebenenfalls Differential Privacy (kontrolliertes statistisches Rauschen) für veröffentlichte Auswertungen. Auch synthetische Daten sind nicht automatisch anonym, ein Modell kann seltene Originalfälle reproduzieren.
6. Reidentifikationsprüfung dokumentieren. Welche Zusatzinformationen haben wir, unsere Dienstleister, die Öffentlichkeit? Lassen sich Einzelfälle isolieren oder verknüpfen? Das wird dokumentiert und regelmäßig wiederholt.

Was neben Namen gern übersehen wird

Es gibt keine Pflicht, „alle Daten zu anonymisieren". Die vorrangige Pflicht ist, nur erforderliche Daten zu verarbeiten, mit Rechtsgrundlage und Schutzmaßnahmen. Aber einige Nebenschauplätze verdienen einen zweiten Blick:

• Protokolle und Metadaten: Prompt- und Antwortlogs, Chatverläufe, Zeitstempel, Geräteinformationen, Dateipfade, Versionshistorien in Dokumenten.
• Die Wissensbasis selbst: Embeddings (mathematische Darstellungen von Text) in einer RAG-Datenbank gelten nicht automatisch als anonym. Wenn sich darüber ein Ursprungsdokument oder ein Personenbezug rekonstruieren lässt, bleiben sie datenschutzrelevant. Die Datenschutzkonferenz weist darauf hin, dass Personenbezug auch in Trainingsdaten, Ein- und Ausgaben und im Modell selbst verbleiben kann.
• Besondere Kategorien: Gesundheitsdaten, Religionszugehörigkeit oder Gewerkschaftsmitgliedschaft brauchen neben der Rechtsgrundlage zusätzlich eine Ausnahme nach Artikel 9 DSGVO. Aus einem allgemeinen Assistenten gehören sie herausgefiltert, wenn der Zweck sie nicht zwingend erfordert.
• Vertrauliches ohne Personenbezug: Kalkulationen, Quellcode, unveröffentlichte Produktinformationen und NDA-Material fallen nicht unter die DSGVO, dürfen aber trotzdem nicht unkontrolliert an einen KI-Anbieter fließen.

Die Mindestkontrollen vor dem Produktivstart

Bevor der Pilot echte Fälle bearbeitet, gehören auf die Liste: dokumentierter Zweck und Datenumfang, Rechtsgrundlage je Verarbeitungsschritt, Eintrag im Verarbeitungsverzeichnis, Auftragsverarbeitungsvertrag mit dem KI-Anbieter, deaktivierte Nutzung deiner Eingaben für das Anbietertraining, Löschfristen für Eingaben, Logs und Tokens, Datenschutzinformationen nach Artikel 13 und 14, bei voraussichtlich hohem Risiko eine Datenschutz-Folgenabschätzung, und die Beteiligung von Datenschutzbeauftragtem und Betriebsrat, wo vorhanden.

Und durchgehend: die menschliche Freigabe. Die DSK empfiehlt, dass Prozesse mit finanziellen, rechtlichen oder personellen Folgen technisch im Status „wartend" bleiben, bis ein Mensch geprüft und freigegeben hat. Wichtig dabei: Ein Mitarbeiter, der 500 KI-Vorschläge pro Stunde durchklickt, ist keine sinnvolle menschliche Beteiligung im Rechtssinn. Die Freigabe braucht Zeit, Zugang zu den Daten und die echte Befugnis, anders zu entscheiden.

Der Kern in einem Satz

Für die Bearbeitung eines konkreten Kunden-, Mitarbeiter- oder Lieferantenfalls ist Pseudonymisierung erforderlich und realistisch. Echte Anonymisierung eignet sich für Statistik, Benchmarking, Qualitätsanalyse und Systemtests. Wer nur Namen schwärzt, hat in aller Regel noch keine anonymen Daten, aber wer deshalb gar nicht anfängt, verschenkt die Prozesse, bei denen ein sauber gebauter Pilot heute schon trägt.