Das Wichtigste in Kürze
- On-Premises hält Daten im eigenen Betrieb. Zweck, Zugriffsrechte und Löschfristen bleiben trotzdem notwendig.
- Der vollständige Kunden- oder Auftragsdatensatz gehört fast nie in eine Modellanfrage.
- Jeder Schritt erhält ein kleines Datenpaket mit klarer Aufgabe und kurzer Lebensdauer.
- Weniger Daten verbessern oft auch das Ergebnis — alte oder nebensächliche Angaben können die KI dann nicht ablenken.
Ein lokales Sprachmodell könnte technisch auf große Teile des Unternehmensnetzes zugreifen. Der Vorschlag kam im Projekt auch früh auf den Tisch: Man könne dem Modell doch das zentrale Netzlaufwerk geben, dann finde es sich schon zurecht. Auf dem Laufwerk lagen rund zwanzig Jahre Betriebsgeschichte, mehrere Generationen von Preislisten und ein Ordner namens „Sonstiges_alt“. Genau das haben wir nicht gebaut.
Denn beim Lesen einer Bestellung braucht die KI das Bestelldokument. Die Materialprüfung braucht Artikelnummer und Menge. Die Terminprüfung braucht Menge, Wunschdatum und verfügbare Kapazität. Der Text für die Auftragsbestätigung braucht am Ende nur die bereits geprüften Angaben. Keiner dieser Schritte braucht die gesamte Kundenhistorie, alle Preislisten oder jedes Dokument auf dem Server.
Datenschutzfreundliche KI beginnt nicht bei der Frage, wo das Modell läuft. Sie beginnt bei der Frage, welche Daten ein einzelner Schritt sehen darf.
Der Kontext ist eine Arbeitsmappe, keine Bibliothek
Das Datenpaket, das ein Sprachmodell für eine konkrete Aufgabe erhält, heißt Kontext — der Arbeitsauftrag, Dokumentauszüge und einige Angaben aus dem Betrieb. Wir behandeln diesen Kontext wie eine kleine Arbeitsmappe: Die Anwendung stellt sie für einen Schritt zusammen, nach dem Schritt wird sie verworfen. Das Modell sucht nicht selbstständig durch das Unternehmensnetz. Es bekommt gebracht, was es braucht.
Der Weg der Daten ist damit kurz. Das Fachsystem hält den vollständigen Bestand. Eine gezielte Abfrage holt daraus nur die nötigen Angaben. Das Modell bearbeitet seine begrenzte Aufgabe. Eine Prüfung kontrolliert und speichert das Ergebnis. Mehr Stationen gibt es nicht — und an keiner davon liegt mehr, als die Station braucht.
Für jeden Schritt gilt eine Datenregel
Bevor ein Schritt umgesetzt wird, halten wir fünf Punkte fest:
| Frage | Festlegung |
|---|---|
| Wozu werden die Daten gebraucht? | Eine klar benannte Aufgabe, etwa „Positionen aus der Bestellung lesen“. |
| Welche Angaben sind nötig? | Nur die Felder und Dokumentstellen, die für diese Aufgabe gebraucht werden. |
| Woher kommen sie? | Eine festgelegte und fachlich zuständige Quelle. |
| Wie lange bleiben sie erhalten? | Nur so lange, wie Bearbeitung und Nachweis es verlangen. |
| Was darf der Schritt ausgeben? | Eine feste Form mit erlaubten Feldern und klaren Grenzen. |
Wie die Begrenzung praktisch aussieht
Am Anfang steht eine Ordnung der Daten nach Schutzbedarf: öffentlich, intern, vertraulich, besonders geschützt. Personenbezogene Daten und Geschäftsgeheimnisse bekommen zusätzliche Regeln für Zugriff und Aufbewahrung. Parallel dazu wird der Prozess in kleine Aufgaben geteilt — ein Schritt liest das Dokument, ein anderer prüft Material, ein weiterer formuliert den Entwurf. So bekommt keiner von ihnen mehr Informationen, als seine Aufgabe verlangt.
Die Abfragen selbst sind eng gefasst. Der Materialschritt darf den Bestand einer bestimmten Artikelnummer lesen; freien Zugang zur gesamten Warenwirtschaft hat er nicht. Diese Begrenzung liegt in der Software, nicht in einer höflichen Bitte an das Modell. Zwischen den Schritten wandert nach Möglichkeit nur eine interne Vorgangsnummer — der nächste Teil der Anwendung lädt damit genau die Angaben, für die er berechtigt ist. Große Datensätze schleppen sich dadurch nicht durch jeden Schritt und jedes Protokoll.
Wo der Personenbezug keine Rolle spielt, wird er entfernt. Für die Frage, ob genug Material auf Lager liegt, ist es gleichgültig, wie die Ansprechpartnerin des Kunden heißt. Name und E-Mail-Adresse werden vor dem Modellaufruf durch eine interne Nummer ersetzt; für die spätere Korrespondenz setzt die Anwendung sie wieder ein. Ebenso technisch getrennt sind Vorgänge und Unternehmensbereiche — bei Dateien, Suche, Zwischenspeicher und Modellanfragen. Ein Vorgang darf keine Inhalte eines anderen sehen. Eine bloße Anweisung im Prompt wäre dafür zu schwach.
Und was nur vorübergehend entsteht, verschwindet auch wieder: Gerenderte PDF-Seiten, erkannte Zwischentexte und detaillierte Diagnose-Dateien erhalten feste Fristen. Erhalten bleibt, was der Vorgang, die Nachvollziehbarkeit oder rechtliche Pflichten verlangen — nicht, was sich angesammelt hat.
Was die KI im Projekt tatsächlich sah
| Schritt | Erhält | Erhält nicht |
|---|---|---|
| Bestellung lesen | Aktuelles Dokument und wenige Auftragsangaben | gesamte Kundenakte, Preise, Personal- oder Finanzdaten |
| Material prüfen | Artikelnummer, Menge und aktueller Bestand | Kundenname, Korrespondenz und andere Artikel |
| Kapazität prüfen | Menge, Arbeitsgang, Wunschdatum und verfügbare Zeiten | unnötige Kontaktdaten und vollständige Produktionshistorie |
| Text entwerfen | geprüfte Fakten und freigegebene Textbausteine | ungeprüfte Rohdaten und interne Notizen ohne Bezug |
| Freigabe anzeigen | Ergebnis, Quelle und Grund für offene Punkte | technische Details ohne Nutzen für die Entscheidung |
Diese Aufstellung hatte einen Nebeneffekt, mit dem wir nicht gerechnet hatten. Als die Datenschutzbeauftragte des Betriebs wissen wollte, welche Daten das Modell eigentlich sieht, passte die Antwort auf eine Seite. Solche Gespräche verlaufen deutlich zäher, wenn die ehrliche Antwort „im Prinzip alles“ lautet.
Weniger Daten helfen auch fachlich
Große Eingaben wirken gründlich. Sie machen die Aufgabe aber nicht automatisch besser. In einem frühen Test hatten wir einem Schritt versuchsweise die letzten Bestellungen desselben Kunden mitgegeben — mehr Zusammenhang, so die Idee. Das Modell bediente sich prompt daran und übernahm einen Wunschtermin aus dem Vorjahr in den aktuellen Entwurf. Der Zusammenhang flog wieder raus.
Ein kleiner Datenausschnitt macht dem Modell klar, worum es in diesem Schritt geht. Alte Preisstände, frühere Aufträge und nebensächliche Hinweise können nicht mit der aktuellen Bestellung verwechselt werden, und nebenbei sinken Rechenzeit und Speicherbedarf. Datenminimierung ist hier keine reine Pflichtübung. Sie ist Teil der Qualitätsarbeit.
Lokale Verarbeitung ist ein guter Anfang, kein Freibrief
Auch im eigenen Haus braucht die Verarbeitung einen klaren Zweck, eine tragfähige Rechtsgrundlage, passende Zugriffsrechte, Löschfristen und technische Schutzmaßnahmen. Je nach Einsatz kann zusätzlich eine Datenschutz-Folgenabschätzung nötig sein.
Prüffragen vor einem neuen Datenzugriff
- Ist diese Angabe für genau diesen Schritt nötig?
- Reicht eine interne Nummer statt des Klarwerts?
- Ist die Quelle aktuell und fachlich zuständig?
- Begrenzt die Software den Zugriff nach Rolle und Vorgang?
- Muss der Inhalt im Protokoll stehen oder genügt eine Vorgangsnummer?
- Wann wird die temporäre Kopie gelöscht?
- Kann der Schritt versehentlich Daten aus einem anderen Fall erhalten?
Fazit
Eine lokale KI sollte kein allwissender Zugang zum Unternehmensnetz sein. Jeder Schritt erhält einen kleinen, begründeten Datenraum — festgelegt in der Software, nicht im Vertrauen darauf, dass sich das Modell schon zurückhalten wird.
Dieser Aufbau erleichtert Datenschutz, Sicherheit und Tests. Häufig verbessert er zugleich die fachliche Genauigkeit. Das Modell sieht weniger. Dafür sieht es das Richtige.
Quellen und weiterführende Hinweise
Datenzugriff lässt sich sauber begrenzen
Eine gute Architektur beginnt mit der Frage, welche Angaben jeder einzelne Schritt wirklich braucht.
Anwendungsfall besprechen