KI nutzen, ohne Kundendaten preiszugeben: Tokenisierung in der Praxis

Der häufigste Einwand gegen KI im Geschäftsalltag ist nicht "das funktioniert nicht". Er lautet: "Dann liegen unsere Kundendaten bei einem US-Anbieter." Der Einwand ist berechtigt. Sobald ein Sprachmodell deine Aufträge zusammenfassen, Rechnungen prüfen oder Kundenanfragen beantworten soll, braucht es Daten aus deinen Systemen. Und alles, was im Kontext des Modells landet, verlässt dein Haus.

Die gute Nachricht: Das Modell braucht deine Kundendaten gar nicht. Es braucht Struktur, nicht Identität. Genau darauf baut Tokenisierung.

Was tatsächlich zum Modellanbieter fliesst#

Wenn ein KI-Assistent mit deinem ERP, CRM oder Auftragssystem verbunden ist, läuft jede Anfrage so ab:

1. Der Assistent ruft Daten aus deinem System ab (Kunde, Auftrag, Rechnung).
2. Diese Daten werden als Kontext an das Sprachmodell geschickt.
3. Das Modell formuliert eine Antwort oder entscheidet über den nächsten Schritt.

Der kritische Punkt ist Schritt 2. Ohne Schutzschicht enthält der Kontext alles, was die API deines Systems liefert: Namen, E-Mail-Adressen, Telefonnummern, Lieferadressen, teilweise IBANs. Auch wenn seriöse Anbieter vertraglich zusichern, nicht auf diesen Daten zu trainieren: Die Übermittlung selbst ist eine Bekanntgabe von Personendaten und damit ein Datenschutz-Thema, in der Schweiz nach nDSG, in der EU nach DSGVO.

Der Ansatz: ein Gateway zwischen System und Modell#

Die Lösung ist eine Zwischenschicht, die jede Antwort aus deinem System filtert, bevor sie das Modell erreicht. Wir nennen sie Privacy-Gateway. Sie kennt vier Regeln, und jedes Datenfeld bekommt genau eine davon:

Konkret sieht das so aus. Das liefert dein System:

{
  "name": "Gerber & Söhne AG",
  "mail": "einkauf@gerber-soehne.ch",
  "phone": "+41 44 123 45 67",
  "city": "Zürich",
  "postcode": "8005",
  "total_net": 12480.00
}

Und das sieht das Sprachmodell:

{
  "name": "Kunde_8f31",
  "mail": "[REDACTED_EMAIL]",
  "phone": "[REDACTED_PHONE]",
  "city": "Zürich",
  "postcode": "80**",
  "total_net": 12480.00
}

Das Modell kann damit alles tun, was du von ihm willst: den Auftrag zusammenfassen, offene Posten prüfen, eine Antwort entwerfen. Es weiss nur nicht, wer Kunde_8f31 ist. Die Zuordnung zurück zum echten Kunden passiert bei dir, in deiner Infrastruktur.

Warum Tokens statt einfach alles schwärzen#

Man könnte alle Personendaten komplett entfernen. Das Problem: Dann kann das Modell nicht mehr sauber arbeiten. Wenn drei Aufträge von drei verschiedenen Kunden im Kontext liegen, muss das Modell sie auseinanderhalten können, sonst vermischt es Positionen und Beträge.

Tokens lösen das. Kunde_8f31 ist innerhalb einer Sitzung stabil: Derselbe Kunde bekommt immer dasselbe Kürzel. Das Modell kann sagen "die zweite Rechnung von Kunde_8f31 ist noch offen", und dein System übersetzt das Kürzel wieder in den echten Kunden, bevor der Sachbearbeiter die Antwort sieht. Struktur bleibt erhalten, Identität bleibt zu Hause.

Das zweite Netz: Freitext scannen#

Feldregeln allein reichen nicht. Personendaten verstecken sich gerne in Freitextfeldern: Die Lieferadresse eines Auftrags ist oft ein Textblock mit Name, Strasse und Ort. Ein Kundenname taucht im Betreff einer Offerte auf. Eine IBAN steht im Fusstext einer Rechnungsvorlage.

Deshalb braucht das Gateway eine zweite Stufe, die nicht auf Feldnamen schaut, sondern auf den Inhalt: Mustererkennung für E-Mail-Adressen, Telefonnummern, IBANs, Strassennamen mit Hausnummer und Firmennamen mit Rechtsform (AG, GmbH, Sàrl). Alles, was das Raster trifft, wird maskiert, egal in welchem Feld es steht.

Bei Geschäftsfeldern läuft der Scan konservativ (nur Muster mit praktisch null Fehlalarmen), bei unbekannten Feldern grosszügiger. Eine zu viel maskierte Ortsangabe kostet nichts. Eine durchgerutschte Kundenliste schon.

Das Audit-Log: belegen statt versprechen#

Jede einzelne Transformation wird protokolliert: welches Werkzeug aufgerufen wurde, welche Felder tokenisiert, welche geschwärzt, welche durchgelassen wurden, mit Zeitstempel. Das ist kein Nice-to-have. Art. 8 nDSG verlangt angemessene technische Massnahmen, und im Ernstfall (Auskunftsbegehren, Audit, Vorfall) willst du zeigen können, was das Modell gesehen hat, nicht vermuten.

Das Log enthält selbst keine Personendaten, nur Feldnamen und Entscheidungen. Es beantwortet die Frage, die dir dein IT-Verantwortlicher oder dein Datenschutzberater stellen wird: "Was genau geht da raus?"

Was das rechtlich bedeutet (und was nicht)#

Wichtig für die Einordnung, ohne Schönfärberei:

• Tokenisierte Daten sind pseudonymisiert, nicht anonymisiert. Solange bei dir eine Zuordnungstabelle existiert, bleiben es Personendaten im Sinne des Gesetzes. Ein AVV mit dem Modellanbieter bleibt sinnvoll.
• Der Unterschied liegt im Risiko: Der Anbieter erhält keine Namen, keine Kontaktdaten, keine Kontonummern. Selbst bei einem Vorfall auf Anbieterseite wäre nichts Identifizierendes betroffen.
• Der Ansatz ersetzt keine Datenschutzerklärung und keine sauberen Prozesse. Er ist die technische Massnahme, die den Rest glaubwürdig macht. Die organisatorischen Grundlagen haben wir in der nDSG-Checkliste für KMUs beschrieben.

Die Grenzen ehrlich benannt#

Drei Dinge, die Tokenisierung nicht löst:

1. Fragen, die Identität brauchen. "Formuliere eine persönliche Geburtstagskarte für Herrn Gerber" funktioniert nicht, wenn das Modell weder Name noch Geburtsdatum sieht. Für solche Fälle braucht es bewusste, dokumentierte Ausnahmen, keine stillschweigenden.
2. Schreibzugriffe. Wenn das Modell einen Auftrag anlegen soll, müssen Tokens vor dem Schreiben wieder in echte IDs übersetzt werden. Dieser Rückweg gehört in dieselbe kontrollierte Schicht, nicht ins Modell.
3. Hundertprozentige Garantie. Mustererkennung ist gut, aber kein Beweis. Ein exotisch formatiertes Datenfeld kann durchrutschen. Deshalb: Feldregeln als erste Stufe, Inhaltsscan als zweite, Audit-Log als Kontrolle. Verteidigung in Schichten, wie überall in der Sicherheit.

Unser Ansatz#

Wir bauen diese Gateway-Schicht zwischen deine Systeme und das Sprachmodell, unabhängig davon, welches ERP oder CRM du einsetzt und welches Modell dahinter arbeitet. Die Regeln werden pro Kunde und pro Rolle konfiguriert: Der Innendienst braucht andere Sichten als die Buchhaltung. Wie das live aussieht, zeigt unsere interaktive Demo zur Tokenisierung: links die Rohdaten, rechts das, was das Modell tatsächlich sieht.

KI und Datenschutz sind kein Widerspruch. Sie werden nur oft in der falschen Reihenfolge angegangen: erst das Werkzeug, dann die Bedenken. Wer die Schutzschicht von Anfang an mitbaut, kann beides haben, und zwar belegbar.