Entwickler werden nicht mehr programmieren, das ist beschlossen. Plattform- und Produktszenarien werden entworfen, in User Stories heruntergebrochen, in Projektgremien validiert und gehen in den BUILD, in Iterationen, in mehrere Stufen von Staging, in mehr oder weniger gelungene Demos und in eine nicht kalkulierbare Menge an Arbeit, in den RUN, wenn das Produkt sich verkaufen lässt.

Doch wir, die wir es gewohnt waren, ganz nah an den funktionalen Eingeweiden dieser modernen Mechanismen zu arbeiten, werden in kürzester Zeit keinen Code mehr sehen.

Die Agenten übernehmen das, mehr oder weniger organisiert, je nach geforderter Qualifikation und den Anforderungen des Produkts.

Diese Frage, oder sagen wir dieses "agentische Thema", mag in ihren operativen Modalitäten und in der Wahl der beteiligten Akteure diskutabel sein, sie gehört jedoch nicht, und sollte niemals allein der Entwicklungsmannschaft überlassen bleiben. Deshalb gibt es CISOs, CIOs und andere Verantwortliche, deren Titel auf "IS" endet, und sie tragen dafür Verantwortung.

Denn wir wissen es: Wenn Regieren Vorausschauen bedeutet, dann bedeutet Entscheiden Wissen, und die unmittelbare Zukunft war noch nie so unsicher.

Um mehr Kontext zu geben und das Problem der "Schlüssel" voranzutreiben, stelle ich folgende Prämisse auf:

  • Jede Organisation im Markt für digitale Dienstleistungen muss KI in ihre Prozesse integrieren, um wettbewerbsfähig zu bleiben.
  • Dieser strukturelle Wandel kann nur skaliert über den Einsatz leistungsstarker Inferenz erfolgen.
  • Der einzige Zugang zu dieser Inferenz ist der Konsum ausgelagerter KI-Produktionsflüsse, deren Anbieter und Infrastrukturen selbst unter Wettbewerb, technologischer Beschleunigung und einem äußerst angespannten regulatorischen Umfeld stehen.

In diesem Mahlstrom stellen sich mit Nachdruck die beiden Fragen, die diese Notiz strukturieren:

  • Wie lässt sich garantieren, dass die Ketten der Geheimnisse erhalten bleiben?
  • Wie lässt sich sicherstellen, dass geistiges Eigentum nicht nach Gutdünken eines technischen Betreibers in die Hände eines Wettbewerbers oder eines böswilligen Agenten gelangt?

Das Wesentliche in fünf Punkten

  1. Die eigentliche Frage ist nicht die Wahl eines Modells, sondern die Kontrolle der Vertrauensgrenze zwischen dem Informationssystem und den Inferenzanbietern.
  2. Zwei verschiedene Bedrohungen müssen gemeinsam behandelt werden: der Kontrollverlust über die Ketten der Geheimnisse und der Abfluss des Informationsvermögens.
  3. Die technische Antwort liegt in einem einzigen Kontrollpunkt, dem AI Privacy Gateway: Klassifizierung, Geheimniserkennung, DLP, Policy, Tokenisierung, Audit.
  4. Die organisatorische Antwort liegt in der Trennung von fünf Verantwortlichkeiten und in der vertraglichen Qualifikation der Anbieter auf dem Niveau eines kritischen Unterauftragnehmers.
  5. Das Erfolgskriterium ist nicht die Erkennung, sondern die Nicht-Umgehbarkeit: Die externe KI verarbeitet eine kontrollierte Darstellung der Information, niemals die Fähigkeit, das echte Geheimnis selbst abzurufen.

Zwei Fragen, ein und derselbe Bruchpunkt

Die beiden Fragen haben nicht denselben Gegenstand. Die erste betrifft die Bewahrung einer Zugriffsmacht. Die zweite betrifft die Diskretion eines Vermögens. Doch beide entscheiden sich am selben Ort: an dem Punkt, an dem interne Werkzeuge Inhalte an einen externen Inferenzanbieter senden.

Die erste ist eine Frage der Bastion. Wer hält die Geheimnisse, wer kann sie rekonstruieren, nach welchen Regeln, mit welchen Rotationen und welchen Spuren. Die Kette bricht, sobald ein einziges Glied einen Wert ohne Kontrolle wiederherstellen kann: eine .env-Datei auf einem Arbeitsplatz, eine Klartext-Umgebungsvariable in einer Build-Kette, ein Passwort, das aus Zeitdruck in einen Prompt kopiert wird.

Die zweite ist eine Frage des Informationsumfangs. Proprietärer Code, Architekturen, Kundendaten, Methoden, Listen, Preisraster. Das Risiko besteht nicht im unrechtmäßigen Zugriff, sondern in der Wiederverwendung: bei einem Wettbewerber, im Training eines Modells oder durch einen Unterauftragnehmer, der in der Vertragskette nicht deklariert war.

Diese beiden Fragen treffen sich an einem Punkt: Generative KI-Werkzeuge, Agenten, Entwicklungsumgebungen und Pipelines sind zu Netzwerkausgängen geworden, die nach außen schreiben, oft mit stillschweigender Erlaubnis der technischen Teams. Der Entwicklerarbeitsplatz ist der neue Sicherheitsbereich, und der API-Schlüssel des Anbieters ist der neue Umgehungsvektor.

Für ein COMEX wird die Entscheidung zu einer Entscheidung über Vertrauensarchitektur.

Die Methode in vier Schritten

Eine glaubwürdige Antwort umfasst vier Schritte, jeder mit einem Ergebnis und einer expliziten Entscheidung. Ein System, das einen Schritt überspringt, erzeugt entweder ein wirkungsloses Dokument oder eine in drei Tagen umgangene Barriere.

  1. Kartieren. Werkzeuge und Agenten erfassen, die mit externen Modellen sprechen, die Aufrufpunkte, die Anbieter, die tatsächlich gesendeten Daten. Ergebnis: die KI-Flusskarte. Entscheidung: der Umfang der erlaubten Nutzungen.
  2. Klassifizieren. Die Werte benennen. Technische Geheimnisse, personenbezogene Daten, regulierte Daten, Code und Know-how. Festlegen, was nicht hinausgehen darf, was pseudonymisiert hinausgehen kann, was frei hinausgehen darf. Ergebnis: die Nomenklatur und die Liste der Daten, die nicht hinausgehen dürfen. Entscheidung: die Schwellenwerte und die durchsetzbaren Regeln.
  3. Zwischenschalten. Einen einzigen Kontrollpunkt zwischen Werkzeuge und Anbieter setzen, die Verantwortlichkeiten trennen, tokenisieren, was übertragen werden muss. Ergebnis: die Zielarchitektur und die Nutzungsrichtlinie. Entscheidung: die Wahl der Bausteine und ihr Hosting.
  4. Beweisen. Lecks adversarial testen, protokollieren, Anbieter qualifizieren, eine Audit-Akte aufbauen. Ergebnis: reproduzierbare Nachweise. Entscheidung: die Freigabe für die Produktion und die Bedingungen der Reversibilität.

Fünf Verantwortlichkeiten, die nicht verwechselt werden dürfen

Der erste Designfehler besteht darin, einen Tresor Polizeiarbeit machen zu lassen. Ein Secret Manager bewahrt und liefert Werte. Er inspiziert keine Flüsse, entscheidet nicht über eine Ausgabe und ersetzt kein System zur Verhinderung von Datenabfluss. Beides zu verwechseln schafft einen einzigen Bruchpunkt: an dem Tag, an dem der Tresor falsch konfiguriert oder kompromittiert wird, fällt die gesamte Kontrollkette mit ihm.

Daher sind fünf Funktionen zu trennen, mit fünf Verantwortlichen und fünf Budgets.

  • Aufbewahren: Secret Manager oder Vault. Die Funktion garantiert, dass echte Geheimnisse den Vertrauensbereich nie verlassen.
  • Erkennen: Secret Scanner und DLP. Die Funktion garantiert, dass kein sensibler Wert die Grenze ungesehen überquert.
  • Entscheiden: Policy Engine. Die Funktion garantiert, dass jeder Fluss eine klare Regel erhält: erlauben, tokenisieren, maskieren, blockieren, protokollieren.
  • Umwandeln: Tokenisierung oder Redaktion. Die Funktion garantiert, dass der Anbieter eine nützliche, aber nicht reale Darstellung erhält.
  • Nachverfolgen: Audit und SIEM. Die Funktion garantiert, dass jede Grenzüberschreitung protokolliert, zuordenbar und überprüfbar ist.

Abbildung 1 - Fünf Verantwortlichkeiten, fünf Komponenten, fünf Verantwortliche

Die daraus entstehende Pipeline ist linear und lesbar. Das Entwicklungswerkzeug oder die Build-Kette ruft den Kontrollpunkt auf. Die Erkennung qualifiziert. Die Policy entscheidet. Die Umwandlung wendet an. Der externe Aufruf geht mit einer kontrollierten Darstellung hinaus. Die Rückkehr wird kontrolliert. Alles wird protokolliert. Jedes Glied kann unabhängig von den anderen auditiert werden.

Das AI Privacy Gateway, der Kontrollpunkt

Die Referenzarchitektur schaltet ein Gateway, das AI Privacy Gateway, zwischen interne Werkzeuge (Entwicklungsumgebungen, Agenten, Skripte, Build-Pipelines) und KI-Anbieter. Es trägt sechs Fähigkeiten: Klassifizierung, Geheimniserkennung, Verhinderung von Datenabfluss, Policy Engine, Tokenisierung, Audit. Der Secret Manager bleibt der Tresor. Das SIEM erhält die Spuren. Das Leitprinzip ist einfach: Keine als verboten klassifizierte Information überquert die Vertrauensgrenze, und echte Geheimnisse bleiben im kontrollierten Informationssystem.

Abbildung 2 - Vertrauensgrenze: Das Gateway kontrolliert, was hinausgeht, der Tresor bewahrt, was nicht hinausgeht

In der Zielversion eines Entwicklerarbeitsplatzes spricht der Coding-Assistent nicht mehr direkt mit dem Anbieter. Er wendet sich an einen lokalen oder kontrollierten Aufrufpunkt, das Gateway entscheidet, und nur die erlaubte Darstellung geht hinaus. Die Produktion ergänzt eine Netzwerkregel: Der direkte Zugriff auf die Aufrufpunkte der Anbieter ist verboten, von den Arbeitsplätzen und aus der Build-Kette.

Eine Sicherheitsrichtlinie, die nur vom guten Willen des Entwicklers oder von der Konfiguration seines Werkzeugs abhängt, ist keine Richtlinie. Sie ist eine Empfehlung.

Pseudonymisieren statt verzichten

Die zentrale Technik ist die reversible Tokenisierung. Sensible Werte werden durch Token ersetzt, der Anbieter arbeitet mit den Token, und die Zuordnungstabelle bleibt im Vertrauensbereich. Die deterministische Variante ist besonders nützlich: Derselbe Wert erzeugt dasselbe Token, sodass das Modell die Konsistenz der Daten verstehen kann, ohne deren Inhalt je zu kennen.

Eine Konfigurationsdatei mit Host, Benutzer und Passwort reist daher in abstrakter Form:

  • DB_HOST=10.20.15.42 wird zu DB_HOST=<DB_HOST_001>
  • DB_USER=application_prod wird zu DB_USER=<DB_USER_002>
  • DB_PASSWORD=xxxxxxxxxxxxxxxx wird zu DB_PASSWORD=<DB_PASSWORD_003>

Die Zuordnung bleibt lokal: <DB_HOST_001> zum echten Wert, <DB_USER_002> zum echten Wert, <DB_PASSWORD_003> zum echten Wert. Die Re-Identifikation bleibt lokal und kontrolliert. Sie wird niemals an das Modell delegiert.

Skyflow dokumentiert diese Architektur: Erkennung, Ersetzung durch deterministische Token, Verarbeitung durch das Modell und anschließend kontrollierte Re-Identifikation. Protegrity dokumentiert ebenfalls Schutzmechanismen auf Basis von Tokenisierung für Nutzungen mit KI-Agenten. Diese Bausteine entbinden nicht von einer Realitätsprüfung. Die Tokenisierung von Geheimnissen macht den Geschäftskontext nicht anonym: Die Inhalte bleiben verwertbar, mitunter sensibel. Daher braucht es Verteidigung in der Tiefe, die Tresor, Tokenisierung, Abflussverhinderung, Policy, Netzkontrolle, Protokollierung und menschliche Überprüfung verbindet.

Vier Familien von Akteuren, keine einzige Lösung

Der Markt liefert die Bausteine bereits. Vier Familien genügen, um einen Vergleich zu strukturieren.

  • Skyflow: Privacy Vault, Tokenisierung sowie kontrollierte De-Identifikation und Re-Identifikation für LLM-Nutzungen.
  • Protegrity: industrieller Datenschutz und Tokenisierung über die gesamte Pipeline.
  • Nightfall AI: Verhinderung von Abfluss und Exfiltration, ausgerichtet auf KI-Agenten und Coding Agents.
  • Cloudflare AI Gateway: Vermittlung, Beobachtbarkeit, Flusskontrolle und Abflussverhinderung, mit ausdrücklicher Dokumentation der Integration von Coding Agents.

Abbildung 3 - Vier Familien von Bausteinen, vier Verantwortungsbereiche

Zwei Fallen sind zu kennen. Erstens: Ein Gateway als gehosteter Dienst ist nicht automatisch eine lokale Vertrauensgrenze. Für ein stark reguliertes System sind Datenverarbeitung, Gerichtsstand, Aufbewahrung und Unterauftragnehmerkette genau zu prüfen. Zweitens: Die Nationalität eines Anbieters sagt für sich genommen nichts über das Risikoniveau. Sie sagt nichts über die tatsächlich genutzten Infrastrukturen, die eingesetzten Unterauftragnehmer oder die technischen Flüsse. Ein französischer Anbieter bedeutet nicht automatisch ein beherrschtes Risiko.

Den Anbieter wie einen kritischen Unterauftragnehmer qualifizieren

Das technische System hält ohne vertragliches System nicht. Für jeden KI-Anbieter muss die Qualifikationsakte mindestens zwölf Punkte festhalten: Gerichtsstand, Verarbeitungsstandorte, Unterauftragnehmer, internationale Transfers, Aufbewahrung, Weiterverwendung von Prompts, Training mit Daten, Protokolle, menschlicher Zugriff, Löschung, Incident-Meldung und Reversibilität.

Abbildung 4 - Zwölf Punkte, die für jeden KI-Anbieter festzuhalten sind

Diese Punkte werden zu durchsetzbaren Klauseln und Prüfkriterien. Die Reversibilität verdient besondere Aufmerksamkeit: Ohne einen dokumentierten und getesteten Ausstiegsplan wird die Abhängigkeit von einem Anbieter zu einem Governance-Risiko und nicht mehr nur zu einem technischen Risiko. Die Qualifikation ist zudem kein einmal unterschriebenes Dokument. Sie wird bei jeder Änderung des Angebots, der Unterauftragnehmer oder des Rechtsrahmens überarbeitet.

Ein letzter Punkt im Kalender, und er erweitert die Tragweite all des Vorstehenden. Ab dem 9. Dezember 2026 nimmt die Richtlinie (EU) 2024/2853 über die Haftung für fehlerhafte Produkte Software ausdrücklich in die Definition des Produkts auf, unabhängig von der Form der Bereitstellung: installiert, über ein Netzwerk zugänglich, in der Cloud gehostet oder als SaaS angeboten. Der Anbieter eines KI-Systems im Sinne der europäischen Verordnung wird wie ein Hersteller behandelt, und nur freie und offene Software, die außerhalb jeglicher kommerzieller Tätigkeit entwickelt wird, bleibt ausgenommen.

Ein Produkt, das nach dem Inverkehrbringen lernt oder neue Funktionen erwirbt, kann wegen Verhaltensweisen nach der Kommerzialisierung als fehlerhaft eingestuft werden. Das Fehlen eines Sicherheitsupdates, das unter der Kontrolle des Herstellers blieb, kann einen Fehler darstellen. Eine Cybersicherheitslücke kann allein ausreichen, um die zivilrechtliche Haftung auszulösen. Der Hersteller haftet zudem für Drittkomponenten, die er integriert oder als Teil seines Produkts darstellt, und die Geschädigten können gleichzeitig den Hersteller, den Komponentenhersteller, den Importeur, den Bevollmächtigten oder den Fulfilment-Dienstleister in Anspruch nehmen.

Die französische Umsetzung war im Sommer 2026 noch nicht veröffentlicht, und das Regime von 1985 gilt weiter, doch die Richtung der Reform ist festgelegt: Die Franchise von 500 Euro entfällt, mit unter anderem einer Höchstfrist von 25 Jahren für bestimmte spät auftretende Körperschäden. Für die in dieser Notiz beschriebene Governance ist die Folge unmittelbar: Die Anbieterqualifikationsakte ist kein Compliance-Dokument mehr, sondern wird zu einem vertraglichen Verteidigungsmittel. Zwischen Unternehmen deckt die Richtlinie reine Vermögensschäden nicht ab: Der Vertrag wird das Risiko verteilen, und deshalb sind Sicherheitsgarantien, Pflichten zur Behebung von Schwachstellen, Support-Dauer, Incident-Meldung, Zugang zu technischen Informationen und Haftungsobergrenzen jetzt zu schreiben.

Durch Tests beweisen

Ein ungetestetes System ist eine Annahme, kein Schutz. Die minimale adversariale Batterie deckt zwölf Familien ab: API-Schlüssel, Passwort, privater Schlüssel, JWT-Token, .env-Datei, Cloud-Zugangsdaten, personenbezogene Daten, proprietärer Code, Exfiltrationsversuch über den Prompt, Re-Identifikationsversuch, im Modell-Response erzeugtes Geheimnis und in einem Tool Call vorhandenes Geheimnis.

Abbildung 5 - Minimale Batterie von zwölf adversarialen Tests, vom Staging bis zur Produktion

Das Staging erfolgt mit falschen Geheimnissen und echten Test-Repositories. Die Vorproduktion führt die endgültigen Umgebungen und Richtlinien ein, mit dokumentierter Überprüfung der False Positives. Die Produktion wendet die Netzwerkregel an. Zwei Kriterien bestimmen die Entscheidung über den Produktivgang. Erstes Kriterium: Zu keinem Zeitpunkt erhält der externe Anbieter als geheim eingestufte Daten.

Ein Entwickler darf das Gateway nicht allein deshalb umgehen können, weil er einen API-Schlüssel des Anbieters besitzt. Genau dieser zweite Punkt macht aus einer Sicherheitsbastellösung eine Sicherheitsarchitektur.

Weg und Entscheidungstore

Für ein KMU oder eine regulierte Organisation besteht der realistische Weg aus vier Etappen: POC, Staging, Vorproduktion, Produktion. Der POC erfordert keine vollständige Plattform. Ein Arbeitsplatz, ein lokales Gateway, ein Tresor, ein kompatibler Aufrufpunkt und eine Testbatterie genügen, um den Wert zu belegen. Dieser Nachweis umfasst die gesamte Kette: Erkennung, Entscheidung, Umwandlung, externer Aufruf, Kontrolle der Rückkehr, Audit.

Jede Etappe wird nach Kriterien passiert. Erkennung konform über die zwölf Testfamilien. Null Geheimnisse, die in der Testkonfiguration die Grenze überqueren. Nachgewiesene Nicht-Umgehbarkeit, auch mit einem gültigen API-Schlüssel. Nutzbare Protokolle. False Positives überprüft und dokumentiert. Unterzeichnete Qualifikationsakte. Vorhandener Ausstiegsplan. Eine ohne Nachweis passierte Etappe ist nicht passiert.

Was das COMEX entscheiden muss

Die technischen Entscheidungen sind gerahmt. Die verbleibenden Entscheidungen sind Managemententscheidungen:

  1. Umfang: Welche externen KI-Nutzungen sind erlaubt, für welche Geschäftsbereiche, mit welchen Werkzeugen.
  2. Architektur: ein verpflichtender einziger Kontrollpunkt und ein Verbot direkter Anbieteraufrufe von Arbeitsplätzen und Build-Kette aus.
  3. Daten und Geheimnisse: offizielle Klassifizierung, Liste der verbotenen Ausfuhren, Tokenisierung als Standard, ein einziger Referenztresor.
  4. Anbieter: verpflichtendes Qualifikationsraster, regelmäßige Überprüfung, Reversibilitätsklauseln.
  5. Nachweis: Protokollierung, wiederkehrende adversariale Tests, aktuell gehaltene Audit-Akte.
  6. Verantwortlichkeiten: ein Verantwortlicher pro Funktion, ein Prüfgremium, eine durchsetzbare Nutzungsrichtlinie.
  7. Budget und Weg: die Bausteine, den POC und den Ausstieg finanzieren, nicht nur das Modellabonnement.

Keine dieser Entscheidungen erfordert das Warten auf den nächsten Technologiezyklus. Alle sind mit den heute verfügbaren Bausteinen umsetzbar.

Antworten auf die beiden Fragen

Die Ketten der Geheimnisse erhalten. Indem die Bastion der Geheimnisse als Architektur behandelt wird, nicht als individuelle Disziplin. Ein einziger Referenztresor. Keine Klartext-Geheimnisse in Repositories, Konfigurationen oder Prompts. Tokenisierung von allem, was übertragen werden muss. Nachverfolgte Rotationen. Protokollierte Zugriffe. Die Kette bleibt erhalten, solange kein einzelnes Glied den echten Wert allein rekonstruieren kann.

Den Abfluss des Informationsvermögens verhindern. Indem die Ausgangsfläche auf eine kontrollierte Darstellung reduziert wird. Klassifizierung, Abflussverhinderung, Policy, Tokenisierung, vertragliche Qualifikation der Anbieter, adversariale Tests, Protokollierung und menschliche Überprüfung. Die externe KI erhält niemals die Fähigkeit, das echte Geheimnis selbst abzurufen, und die Umgehung wird durch Netzwerk und Policy unmöglich gemacht, nicht durch guten Willen allein. Der Abfluss wird damit zu einem erkennbaren, nachverfolgbaren und zuordenbaren Ereignis.

Die Frage ist nicht mehr, ob unsere Teams externe KI nutzen werden. Sie tun es bereits. Die Frage ist, ob die Organisation die Kontrolle über die Vertrauensgrenze zurückgewinnt oder die Grenze an ihrer Stelle entscheiden lässt.

Quellen und Referenzen