KI im Shop ohne Datenabfluss: Modelle im eigenen Betrieb

Ein Produktberater im Shop, ein Antwortentwurf für das Supportpostfach, eine automatische Einordnung eingehender Retouren: Solche KI-Funktionen sind in wenigen Tagen eingebaut, solange ein Modell über eine fremde Schnittstelle angesprochen wird. Der Einbau ist dabei die kleinere Frage. Die größere lautet, welche Bestell-, Konto- und Nachrichtendaten das Haus verlassen, wer sie danach verarbeitet und was davon in Verträgen, Verzeichnissen und Auskünften auftauchen muss. Dieser Beitrag zieht die Datengrenze auf: was ein Prompt tatsächlich enthält, welche Betriebsformen zur Wahl stehen, was der Europäische Datenschutzausschuss und das BSI vom einsetzenden Unternehmen erwarten, was auch auf eigener Hardware noch abfließen kann - und ab welcher Nutzung sich der eigene Betrieb trägt.

Was ein KI-Feature aus dem Shop heraustragen kann

Ein Prompt sieht aus wie ein Suchfeld und verhält sich wie ein Datenexport. Damit ein Produktberater eine brauchbare Antwort gibt, bekommt er in der Regel mehr als die Frage des Besuchers: den Warenkorb, die letzten Bestellungen, die Kundengruppe, manchmal den Namen aus dem Konto. Ein Entwurfsassistent für das Supportpostfach bekommt die vollständige Nachricht des Kunden samt Signatur, Bestellnummer und Beschwerdegrund. Eine Retourenklassifikation bekommt den Freitext, den jemand in das Rücksendeformular geschrieben hat. Jedes dieser Felder ist ein personenbezogenes Datum, sobald es an einer Kennung hängt - und die Kennung liefert die Anwendung meist gleich mit, damit die Antwort dem richtigen Vorgang zugeordnet werden kann.

Der Unterschied zur übrigen Schnittstellenlandschaft liegt in der Unschärfe. Ein Zahlungsdienst bekommt definierte Felder in einem festen Format; was er sieht, steht in der Dokumentation. Ein Sprachmodell bekommt Fließtext, und Fließtext trägt mit, was zufällig danebensteht: die Adresszeile aus der Signatur, die Kontonummer in der Beschwerde, den Gesundheitshinweis in der Retourenbegründung. Wer den Prompt nicht selbst zusammensetzt und begrenzt, weiß nicht, welche Kategorien personenbezogener Daten er übermittelt. Genau diese Angabe verlangt aber jedes Verzeichnis, jede Folgenabschätzung und jede Rückfrage einer Aufsichtsbehörde.

• Warenkorb und Bestellhistorie: Sie machen die Antwort erst brauchbar und sind zugleich die Felder mit der längsten Aufbewahrung im Shop.
• Freitext aus Formularen: Beschwerde, Retourenbegründung, Kommentar zur Lieferung - hier stehen erfahrungsgemäß die Angaben, die niemand eingeplant hat.
• Die Signatur einer E-Mail: Name, Anschrift, Rufnummer und Position reisen mit, wenn die Nachricht unverändert in den Prompt geht.
• Interne Regeln im Systemprompt: Rabattgrenzen, Kulanzstufen, Lieferantenkonditionen. Das BSI hält dazu fest, dass in Systemprompts keine sensiblen Daten integriert werden dürfen (BSI).
• Die Kennung selbst: Eine Kundennummer oder Sitzungskennung macht aus beliebigem Text ein personenbezogenes Datum, auch wenn kein Name darin vorkommt.

Drei Betriebsformen, drei Datenwege

Zwischen fremder Schnittstelle und eigener Hardware liegt eine Zwischenstufe, die in der Praxis am häufigsten gewählt wird: ein Modell, das ein Auftragsverarbeiter in einem Rechenzentrum innerhalb der Europäischen Union betreibt. Die Formen unterscheiden sich weniger im Funktionsumfang als im Vertragsaufwand und in der Zahl der Stellen, die eine Eingabe passiert. Das BSI beschreibt den lokalen Betrieb als den Betrieb eines KI-Modells in eigener Verantwortung auf eigener Hardware (BSI). Diese Beschreibung ist der Maßstab, an dem sich die übrigen Formen messen lassen - nicht die Frage, welches Modell verwendet wird, sondern die Frage, wo es rechnet.

Die dritte Zeile ist der Gegenstand dieses Beitrags, die vierte eine Sonderform für kleine Modelle, die im Gerät des Besuchers rechnen. Entscheidend an der Tabelle ist die zweite Spalte: Sie beschreibt nicht, was gespeichert wird, sondern was übertragen wird. Eine Zusicherung, Eingaben nicht für weiteres Training zu verwenden, ändert nichts daran, dass die Eingabe den Empfänger erreicht hat. Das BSI benennt genau diesen Punkt als Risiko: Neben dem ungewollten Abfluss während der Übertragung besteht die Möglichkeit, dass das betreibende Unternehmen auf die Daten zugreift und sie gegebenenfalls zum weiteren Training des Modells nutzt (BSI).

Was die Aufsicht vom einsetzenden Unternehmen erwartet

Der Europäische Datenschutzausschuss hat am 17. Dezember 2024 die Stellungnahme 28/2024 angenommen (EDSA) und darin drei Fragen beantwortet, die für den Einsatz im Shop unmittelbar zählen: wann ein Modell als anonym gelten kann, wann berechtigte Interessen als Rechtsgrundlage tragen und was gilt, wenn ein Modell mit rechtswidrig verarbeiteten Daten entwickelt wurde. Die erste Antwort fällt streng aus. Anonymität ist danach kein Zustand, den ein Anbieter erklären kann, sondern das Ergebnis einer Prüfung, die zwei Wahrscheinlichkeiten zugleich betrachtet.

Ein KI-Modell kann nur dann für anonym befunden werden, wenn zwei kumulative Voraussetzungen erfüllt sind: 1) Sowohl die Wahrscheinlichkeit direkter (einschließlich probabilistischer) Entnahmen personenbezogener Daten über die natürlichen Personen, deren personenbezogene Daten für die Modellentwicklung verwendet wurden, 2) als auch die Wahrscheinlichkeit, dass solche personenbezogenen Daten, ob vorsätzlich oder nicht vorsätzlich, durch Anfragen erlangt werden, sollte bei Berücksichtigung „alle[r] Mittel …, die von dem Verantwortlichen oder einer anderen Person nach allgemeinem Ermessen wahrscheinlich genutzt werden“ vernachlässigbar gering sein.

Europäischer Datenschutzausschuss, Stellungnahme 28/2024, Zusammenfassung

Für die Rechtsgrundlage verlangt die Stellungnahme eine dokumentierte dreistufige Prüfung: ein berechtigtes Interesse, die Erforderlichkeit der Verarbeitung für dieses Interesse und eine Abwägung, in der die Interessen und Grundrechte der betroffenen Personen nicht überwiegen (EDSA). Die drei Bedingungen müssen kumulativ erfüllt sein - und, das ist der Teil, der im Alltag untergeht, vorher geprüft und festgehalten. Eine Abwägung, die erst auf Nachfrage einer Aufsichtsbehörde entsteht, erfüllt die Rechenschaftspflicht aus Artikel 5 Absatz 2 DSGVO nicht, weil diese Vorschrift den Nachweis der Einhaltung verlangt (DSGVO).

Die dritte Antwort trifft den Betreiber am unmittelbarsten. Wer ein fremdes Modell einsetzt, muss sich in geeigneter Weise vergewissert haben, dass für dessen Entwicklung keine rechtswidrig verarbeiteten personenbezogenen Daten verwendet wurden (EDSA). Diese Pflicht lässt sich nicht an den Anbieter weiterreichen; sie gehört zur eigenen Rechenschaftspflicht. Praktisch heißt das: Herkunft der Trainingsdaten, Modellkarte und bekannte Verfahren gehören in die Akte, bevor die Funktion live geht - und zwar in einer Form, die ein Jahr später noch verständlich ist.

Der Papierstapel, den ein KI-Feature auslöst

Ein KI-Feature ist selten eine eigenständige Verarbeitungstätigkeit. Es hängt an einer bestehenden - Bestellabwicklung, Kundenkonto, Support - und verändert sie um einen Empfänger und einen Zweck. Genau diese beiden Angaben verlangt das Verzeichnis nach Artikel 30 Absatz 1 DSGVO, das unter anderem die Zwecke der Verarbeitung und die Kategorien von Empfängern führt, gegenüber denen die personenbezogenen Daten offengelegt worden sind (DSGVO). Ein Eintrag mit dem Namen der Funktion, aber ohne Empfänger und ohne Rechtsgrundlage, ist kein Eintrag, sondern eine Notiz.

• Verzeichnis der Verarbeitungstätigkeiten (Artikel 30 DSGVO): Zweck, Datenkategorien, Empfänger, Löschfristen - je Funktion geführt, nicht je Werkzeug.
• Auftragsverarbeitungsvertrag (Artikel 28 DSGVO): Er verpflichtet den Auftragsverarbeiter darauf, personenbezogene Daten nur auf dokumentierte Weisung des Verantwortlichen zu verarbeiten (DSGVO). Für ein selbst betriebenes Modell entfällt dieser Vertrag.
• Datenschutz-Folgenabschätzung (Artikel 35 DSGVO): fällig, wenn eine Form der Verarbeitung, insbesondere bei Verwendung neuer Technologien, voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat (DSGVO).
• Technische und organisatorische Maßnahmen (Artikel 32 DSGVO): Die Maßnahmen schließen unter anderem die Pseudonymisierung und Verschlüsselung personenbezogener Daten ein (DSGVO); dazu kommen Zugriffstrennung und Protokollierung - für die Modellschicht wie für jede andere Anwendung.
• Drittlandprüfung (Artikel 44 DSGVO): nur nötig, wenn Daten den Rechtsraum verlassen - jedwede Übermittlung personenbezogener Daten an ein Drittland oder eine internationale Organisation ist nur zulässig, wenn Verantwortlicher und Auftragsverarbeiter die Bedingungen dieses Kapitels einhalten (DSGVO). Im eigenen Betrieb entfällt die Frage, statt beantwortet zu werden.

Der Aufwand verschiebt sich also, er verschwindet nicht. Beim Fremdbezug liegt er in Verträgen, Prüfungen und wiederkehrenden Nachkontrollen; beim eigenen Betrieb liegt er in Hardware, Aktualisierung und Betriebssicherheit. Welche Seite angenehmer ist, hängt davon ab, was ein Unternehmen ohnehin betreibt. Wer bereits eigene Server für den Shop verantwortet, hat den zweiten Weg zur Hälfte gebaut: Netztrennung, Sicherungen, Überwachung und Zugriffskonzept sind vorhanden und müssen nur um einen weiteren Dienst erweitert werden.

Eigener Betrieb: was er technisch bedeutet

Eigener Betrieb heißt nicht, ein Modell selbst zu trainieren. Er heißt, ein vorhandenes, quelloffen verfügbares Modell auf eigener Hardware auszuführen und die Anwendungsschicht darum herum selbst zu bauen. Das BSI trennt die Fälle sauber: lokaler Betrieb ist der Betrieb in eigener Verantwortung auf eigener Hardware, extern bereitgestellt ist ein Modell, dessen Anbieter jemand anderes ist (BSI). Beide Fälle können dasselbe Modell betreffen. Der Unterschied liegt nicht am Modell, sondern am Ort der Berechnung - und damit an der Frage, wie viele Stellen eine Eingabe passiert.

Die Hardwarefrage ist berechenbar, wird aber oft zu spät gestellt. Das BSI führt sie in seinem Maßnahmenkatalog als eigenes Auswahlkriterium und fragt ausdrücklich, welche Rechen- und Speicherkapazitäten gegebenenfalls für einen Eigenbetrieb notwendig sind (BSI). Für die Funktionen, um die es im Shop typischerweise geht - Antwortentwürfe, Klassifikation, Zusammenfassung, Produkttexte -, reichen erfahrungsgemäß kleinere Modelle, die mit einer einzelnen Beschleunigerkarte auskommen. Für offene Beratungsdialoge in mehreren Sprachen steigt der Bedarf deutlich. Diese Unterscheidung entscheidet über die Wirtschaftlichkeit, nicht über die Grundsatzfrage.

# Grenzen der Anwendungsschicht: was den Betrieb verlassen darf
dienst:
  name: produktberater
  modell:
    ort: eigenes_rechenzentrum # kein Aufruf nach außen
    endpunkt: http://10.20.0.14:8080/v1/completions
  eingabe:
    felder_erlaubt: [artikelnummer, kategorie, frage_text]
    felder_gesperrt: [kundennummer, email, adresse, zahlungsart]
    max_zeichen: 4000
  protokoll:
    speichern: metadaten # Zeit, Dauer, Modellstand, Trefferzahl
    inhalt: nein # kein Prompt, keine Antwort im Log
    aufbewahrung_tage: 30
  netz:
    ausgehend: verweigern # Standardregel des Dienstkontos
    ausnahmen: [10.20.0.14]

Die Konfiguration oben ist der eigentliche Datenschutz an dieser Stelle. Nicht das Modell entscheidet, was es sieht, sondern die Anwendungsschicht davor: Sie setzt den Prompt aus erlaubten Feldern zusammen, weist gesperrte Felder ab, begrenzt die Länge und protokolliert Kennzahlen statt Inhalte. Eine Sperrliste an dieser Stelle ist nachweisbar; ein Hinweis in einer Bedienungsanleitung ist es nicht. Dieselbe Trennung wirkt nebenbei gegen manipulierte Eingaben - der Weg dorthin steht ausführlich im Beitrag zu Prompt Injection in Shop-Funktionen.

Was auch im eigenen Betrieb noch abfließen kann

Eigene Hardware ist eine Grenze, kein Deckel. Es gibt drei Wege, auf denen Daten den Betrieb dennoch verlassen, und alle drei sind in Projekten aufgetreten, die ansonsten sorgfältig gebaut waren. Der erste ist die Telemetrie einer Bibliothek, die beim Start eine Version abfragt und dabei Kennungen mitschickt. Der zweite ist ein Werkzeugaufruf: Sobald ein Modell eine Suche, eine Übersetzung oder einen Abruf auslösen darf, kann der Inhalt der Anfrage in diesem Aufruf stecken. Der dritte ist die Protokollkette aus Anwendung, vorgelagertem Server und Fehlerdienst, in der ein Prompt landet, obwohl der Modelldienst selbst nichts speichert.

• Ausgehende Verbindungen des Dienstkontos verweigern und die Ausnahmen einzeln benennen. Eine Regel, die allein den Modellserver erlaubt, ist in Minuten geschrieben und in einer Minute geprüft.
• Werkzeugaufrufe getrennt bewerten: Jede Funktion, die das Modell auslösen darf, ist ein eigener Empfänger im Verzeichnis - auch wenn sie im selben Haus liegt.
• Protokollstufen absenken, bevor die Funktion live geht. Ein Fehlersuchprotokoll mit vollständigen Anfragen ist die häufigste unbemerkte zweite Kopie.
• Absturzberichte prüfen: Ein solcher Bericht enthält häufig den letzten Eingabepuffer. Verlässt er das Haus, verlässt der Prompt es mit.
• Sicherungen mitdenken: Was in einer Sicherung liegt, unterliegt derselben Löschfrist wie das Original - die Systematik dazu steht im Beitrag zum Löschkonzept mit Aufbewahrungsfristen.

Diese drei Messungen dauern zusammen weniger als eine Minute und ersetzen eine Vermutung durch einen Befund: kein Weg nach außen, nur interne Verbindungen zum Modelldienst, keine Prompt-Inhalte im Protokoll. Wichtig ist die Reihenfolge - erst die Regel setzen, dann messen, dann die Messung in die Abnahme aufnehmen. Eine Sperre, die nach einem Systemwechsel niemand nachmisst, ist erfahrungsgemäß nach einigen Monaten still verschwunden. Wer die Prüfung an die Auslieferung hängt, bemerkt ihren Wegfall am selben Tag statt bei der nächsten Kontrolle.

Löschen und berichtigen: der Teil, der später weh tut

Solange Eingaben und Ausgaben nur verarbeitet und nicht weiterverwendet werden, ist Löschen eine gewöhnliche Aufgabe: Datensätze finden, Fristen anwenden, Protokolle mitnehmen. Schwierig wird es, sobald Eingaben in ein Nachtraining fließen. Die Konferenz der unabhängigen Datenschutzaufsichtsbehörden hält in ihrer Orientierungshilfe zu KI-Systemen fest, dass eine Löschung technisch vollumfänglich sein muss und auch das Modell erfasst, wenn dieses die zu löschende Information enthält (DSK). Der übliche Ausweg - ein Filter, der die Information nicht mehr ausgibt - genügt dafür ausdrücklich nicht.

Allerdings stellen solche mitigierenden Maßnahmen, insbesondere auch Filter, an sich keine Löschung dar.

Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder, Orientierungshilfe zu KI-Systemen, Version 1.0

Daraus folgt eine unspektakuläre, aber wirksame Entwurfsentscheidung: Eingaben aus dem Shop nicht für ein Nachtraining verwenden, solange kein belastbarer Löschpfad dafür steht. Die Funktion verliert dadurch wenig, denn der Gewinn eines Modells, das die eigenen Produkttexte kennt, entsteht in der Regel aus dem Abruf zur Laufzeit und nicht aus dem Gewicht im Modell. Wer beides trennt - Wissen im Abruf, Modell unverändert -, behält die Löschbarkeit, ohne bei der Antwortqualität nachzugeben. Für ein eventuell geplantes Nachtraining bevorzugt die Datenschutzkonferenz die lokale Verarbeitung auf dem genutzten Endgerät (DSK).

Wann sich der eigene Betrieb rechnet

Die Verbreitung von KI in europäischen Unternehmen wächst schnell und ungleich. Nach der Erhebung von Eurostat setzten 2025 19,95 Prozent der Unternehmen in der EU ab zehn Beschäftigten mindestens eine KI-Technik ein, ein Anstieg um 6,47 Prozentpunkte gegenüber dem Vorjahr (Eurostat). Die Spreizung nach Größe ist deutlich: 17 Prozent bei kleinen, 30,36 Prozent bei mittleren und 55,03 Prozent bei großen Unternehmen (Eurostat). Die Werte stammen aus einer Stichprobe von rund 157 000 der etwa 1,53 Millionen Unternehmen in der EU (Eurostat) und beschreiben damit den Markt, in dem ein Shop seine Entscheidung trifft, nicht den deutschen Markt allein.

Aufschlussreicher als die Nutzungsquote sind die Gründe dagegen. Unter den Unternehmen in der EU, die den Einsatz jemals erwogen haben, nannten 70,89 Prozent fehlendes Fachwissen, 52,52 Prozent Unklarheit über die rechtlichen Folgen und 48,83 Prozent Bedenken wegen Verletzung von Datenschutz und Privatsphäre (Eurostat). Zwei der drei häufigsten Hürden sind damit keine technischen, sondern Fragen der Zuständigkeit und des Nachweises. Genau hier setzt der eigene Betrieb an - nicht weil er einfacher wäre, sondern weil er die Zahl der beteiligten Stellen und damit den Prüfumfang verringert.

• Menge: Bei wenigen hundert Anfragen im Monat trägt eine eigene Beschleunigerkarte ihre Kosten nicht. Ab gleichmäßiger Dauerlast kehrt sich das Verhältnis typischerweise um; die Rechnung dazu steht im Beitrag zu KI-Kosten, Token-Budget und Zwischenspeicher.
• Datenkategorien: Sobald Gesundheits-, Finanz- oder Beschäftigtendaten im Freitext auftauchen können, verschiebt sich die Abwägung deutlich in Richtung eigener Betrieb.
• Vorhandene Infrastruktur: Wer eigene Server und ein Betriebsteam hat, trägt vor allem die Hardware. Wer bei null beginnt, trägt zusätzlich den Aufbau des Betriebs.
• Antwortzeit: Ein Modell im eigenen Netz spart den Weg nach außen. Bei kurzen Klassifikationen ist das spürbar, bei langen Texten fällt es kaum ins Gewicht.
• Nachweisbedarf: Wer regelmäßig Auskunft erteilt oder Geschäftskunden den Datenort belegen muss, spart im eigenen Betrieb wiederkehrende Prüfarbeit.

Die Reihenfolge einer Einführung

Die häufigste Ursache für eine gescheiterte Einführung ist nicht die Technik, sondern die Reihenfolge. Wer mit der Modellauswahl beginnt, entscheidet über die Datengrenze, bevor er sie kennt. Die tragfähige Reihenfolge beginnt beim Anwendungsfall und endet beim Modell - so gliedert es auch das BSI in seinem Kriterienkatalog, der Planung, Beschaffung, Anpassung, Integration, Einsatz und Beendigung als getrennte Phasen mit eigenen Anforderungen führt (BSI).

1. Anwendungsfall festlegen und begrenzen. Eine Funktion, ein Zweck, eine Nutzergruppe. Ein Assistent für alles lässt sich weder abgrenzen noch dokumentieren.
2. Felder festschreiben. Welche Datenfelder darf der Prompt enthalten, welche sind gesperrt? Diese Liste ist die Datengrenze und gehört vor die erste Zeile Code.
3. Betriebsform wählen. Erst jetzt entscheidet sich, ob eigene Hardware, ein Auftragsverarbeiter oder das Gerät des Besuchers die Rechenarbeit übernimmt.
4. Unterlagen schreiben, bevor die Funktion live geht. Verzeichniseintrag, Rechtsgrundlage samt Abwägung, gegebenenfalls Folgenabschätzung, Löschfristen.
5. Grenze messbar machen. Ausgehende Verbindungen sperren, Protokollstufen setzen, beides in die Abnahme aufnehmen.
6. Nachkontrolle terminieren. Modellstände, Bibliotheken und Protokollstufen ändern sich; eine jährliche Prüfung der erlaubten Anwendungsfälle ist der kleinste sinnvolle Takt.

Diese sechs Schritte kosten zusammen weniger Zeit als die erste Nachbesserung nach einem Auskunftsersuchen. Sie haben außerdem einen Nebeneffekt, der sich schwer messen und gut erklären lässt: Ein Betrieb, der auf die Frage nach dem Ort seiner Daten in zwei Sätzen antwortet, gewinnt Geschäftskunden schneller als einer, der erst nachsehen muss. Wir begleiten diesen Weg von der Aufnahme des Anwendungsfalls bis zum laufenden Betrieb auf eigener Hardware - die Bausteine dazu stehen unter KI-Lösungen und Cloud und Infrastruktur.