Ihre Mitarbeiter verraten Ihre Geheimnisse längst an ChatGPT – ein Verbot macht alles nur schlimmer

Ich saß einem CISO eines großen Finanzdienstleisters gegenüber, als er etwas sagte, das mir wochenlang nachging. Er lehnte sich zurück, rieb sich die Schläfen und sagte: "Wir haben ChatGPT auf jedem Gerät, das wir verwalten, blockiert. Wir haben die Richtlinie zur akzeptablen Nutzung aktualisiert. Wir haben drei unternehmensweite E-Mails verschickt. Und letzten Dienstag habe ich herausgefunden, dass unser gesamtes M&A-Team in der Mittagspause Deal-Konditionen auf ihren privaten Handys in Claude einfügt."

Er war nicht wütend. Er war erschöpft. Er hatte alles getan, was ihm das Cybersecurity-Handbuch vorschrieb, und es hatte nicht funktioniert.

Dieses Gespräch brachte etwas auf den Punkt, das ich in jedem Enterprise-Projekt beobachtet hatte, das mein Team bei Veriprajna übernommen hatte: Das Verbot generativer KI hält die Menschen nicht davon ab, sie zu nutzen – es bringt sie nur dazu, es zu verheimlichen. Und verborgene Nutzung ist unendlich viel gefährlicher als sichtbare Nutzung. Die Daten erzählen dieselbe Geschichte. Sechsundvierzig Prozent der Beschäftigten sagen, dass sie KI-Tools weiter nutzen würden, selbst wenn ihr Unternehmen sie ausdrücklich verbieten würde. Achtunddreißig Prozent geben zu, dass sie bereits sensible Arbeitsdaten mit öffentlichen KI-Plattformen geteilt haben, ohne es jemandem zu sagen. Das Datenvolumen, das zu generativen KI-Apps fließt, hat sich im Jahresvergleich verdreißigfacht. Das ist kein Richtlinienproblem. Es ist ein architektonisches.

Die Nacht, in der Samsung alles veränderte

Im Mai 2023 taten drei Ingenieure in Samsungs Halbleitersparte etwas völlig Rationales. Sie debuggten proprietären Code zur Chipfertigung – komplexe, folgenreiche Arbeit, bei der eine zweite Meinung Tage an Aufwand sparen konnte. Also fügten sie ihren Code in ChatGPT ein.

Einer lud Quellcode für Halbleitermessdatenbanken hoch. Ein anderer teilte Programmlogik zur Identifizierung von Ausbeutefehlern – die Art von Daten, die sich direkt auf Samsungs Aktienkurs auswirkt. Ein Dritter lud eine interne Besprechungsaufnahme hoch, um ein Protokoll zu erstellen.

Keiner von ihnen versuchte, dem Unternehmen zu schaden. Sie versuchten, ihre Arbeit gut zu machen. Sie behandelten ChatGPT so, wie man einen Taschenrechner behandeln würde: etwas eingeben, etwas herausbekommen, weitermachen. Was sie nicht vollständig begriffen, war, dass OpenAIs Nutzungsbedingungen zu dieser Zeit erlaubten, Eingaben zu speichern – potenziell für das Modelltraining verwendet, definitiv auf Servern außerhalb von Samsungs Kontrolle gespeichert.

Ich erinnere mich, dass ich die Berichterstattung las und einen Knoten im Magen spürte. Nicht weil das Leck überraschend war – ich hatte Kunden genau vor diesem Szenario gewarnt –, sondern weil Samsungs Reaktion so vorhersehbar war. Sie verhängten ein unternehmensweites Verbot. Drohten mit Kündigung bei Verstößen. Riegelten das Netzwerk ab.

Und ich wusste mit absoluter Gewissheit, dass es nicht funktionieren würde.

Warum geht ein KI-Verbot immer nach hinten los?

Hier liegt der Fehler, den die meisten Sicherheitsteams machen: Sie modellieren die Bedrohung so, als wären die Beschäftigten Gegner. Baue eine höhere Mauer, und das Problem verschwindet. Aber die Leute, die Daten an ChatGPT weitergeben, sind keine Gegner. Sie sind Ihre Leistungsträger.

Denken Sie darüber nach, wer bei der Arbeit tatsächlich KI-Tools nutzt. Es ist nicht die Person, die sich durch ihren Tag treiben lässt. Es ist die Ingenieurin, die unter Druck steht, bis Freitag zu liefern. Der Analyst, der bis zum Morgen vierzig Seiten Due-Diligence-Material zusammenfassen muss. Die Entwicklerin, die weiß, dass die KI in Sekunden einen Fehler erkennen kann, für dessen manuelles Auffinden sie eine Stunde bräuchte.

Wenn Sie das Tool verbieten, sagen Sie Ihren produktivsten Leuten: "Sei langsamer. Sei weniger effektiv. Sieh zu, wie deine Konkurrenten dich überholen, und finde dich damit ab." Natürlich halten sie sich nicht daran. Sie wechseln einfach zu ihren privaten Handys. Sie nutzen 4G-Hotspots, um das Firmennetzwerk zu umgehen. Sie finden eine der über 317 unterschiedlichen generativen KI-Apps, die Netskope in Unternehmensumgebungen erfasst hat – denn selbst wenn Sie OpenAI, Google und Anthropic blockieren, warten Hunderte kleinerer, weniger sicherer Alternativen.

Wenn Sicherheit als Blockierer statt als Wegbereiter wahrgenommen wird, werden Ihre gewissenhaftesten Beschäftigten zu Ihren wichtigsten Richtlinienverletzern.

Ich begann, das in Gesprächen mit meinem Team die "Paste Gap" zu nennen. Daten verlassen das sichere Firmen-Laptop, wandern zu einem privaten Gerät und werden in einen öffentlichen Cloud-Dienst eingefügt. Keine Firewall fängt sie ab. Kein CASB protokolliert sie. Sie sind unsichtbar. Und es passiert gerade jetzt, in jeder Organisation, die versucht hat, dieses Problem mit einem Richtlinien-Memo zu lösen.

Die Zahlen sind erschütternd: eine Zunahme von 485 % beim Einfügen von proprietärem Quellcode in KI-Tools. Zweiundsiebzig Prozent der Enterprise-KI-Nutzung erfolgt über private Konten, vollständig außerhalb der Sichtbarkeit der IT. Das ist kein Rinnsal. Es ist eine Flut, und die Deiche sind aus Papier.

Was ich über "Enterprise"-KI-Stufen falsch verstanden habe

Ich will ehrlich sein – als OpenAI ChatGPT Enterprise vorstellte, dachte ich, es könnte ausreichen. Keine Datenspeicherung. Kein Training mit Geschäftsdaten. SOC-2-Konformität. Es hakte die Kästchen ab.

Dann begannen wir, für unsere Kunden gründlicher zu prüfen, und die Risse zeigten sich.

Selbst Enterprise-Vereinbarungen enthalten typischerweise ein kurzes Datenspeicherfenster – oft dreißig Tage – zur Missbrauchsüberwachung. Das sind dreißig Tage, in denen Ihre sensibelsten Prompts auf den Servern eines anderen liegen. Und "ein anderer" ist ein US-amerikanisches Unternehmen, was uns zu einem Problem bringt, das europäische CISOs nachts wachhält.

Der US CLOUD Act – der Clarifying Lawful Overseas Use of Data Act – erlaubt es US-Strafverfolgungsbehörden, amerikanische Technologieunternehmen zu zwingen, auf ihren Servern gespeicherte Daten herauszugeben, unabhängig davon, wo sich diese Server physisch befinden. Wenn eine deutsche Bank Azure OpenAI mit einem Rechenzentrum in Frankfurt nutzt, mögen die Daten in der EU "ruhen", aber die kontrollierende Rechtsträgerin unterliegt weiterhin US-Durchsuchungsbefehlen. Während der Inferenz – wenn das Modell Ihre Daten tatsächlich verarbeitet – kann es weiterhin über US-kontrollierte Infrastruktur geleitet werden.

Ich habe zugesehen, wie ein Raum voller Compliance-Verantwortlicher blass wurde, als ich sie durch dies führte. Sie hatten die Enterprise-Vereinbarung unterschrieben in dem Glauben, das Souveränitätsproblem gelöst zu haben. Sie hatten es nicht einmal angekratzt.

Ich habe über dieses Architekturproblem – und das vollständige Bedrohungsmodell – geschrieben in unserem interaktiven Whitepaper über Shadow AI und private Enterprise-LLMs. Es entstand aus genau diesen Gesprächen.

Die Wrapper-Falle

Etwa zur selben Zeit füllte sich mein Posteingang mit Angeboten von KI-Beratungsfirmen. "Wir bauen Ihnen eine maßgeschneiderte KI-Lösung!" Die meisten von ihnen waren Wrapper – eine nette Oberfläche, auf die OpenAI-API aufgeschraubt, vielleicht mit einem System-Prompt, der sagte: "Sie sind ein hilfreicher Rechtsassistent."

Ich saß eine Demo durch, in der der Anbieter stolz eine "proprietäre KI-Plattform" für die Vertragsanalyse präsentierte. Ich stellte eine Frage: "Wohin gehen die Daten, wenn ein Nutzer einen Vertrag hochlädt?" Schweigen. Dann: "Nun, sie gehen an die OpenAI-API, aber wir haben eine BAA abgeschlossen."

Das ist keine Lösung. Das ist ein Zwischenhändler, der Ihrem Datenleck Latenz hinzufügt.

Ein Wrapper löst das Problem der Datensouveränität nicht. Er verschönert nur die Oberfläche des Datenabflusses.

Wrapper versagen bei Unternehmen auf drei konkrete Weisen. Erstens sind sie trivial replizierbar – wenn Ihre "KI-Lösung" ein Prompt plus ein API-Schlüssel ist, kann Ihr Praktikant sie an einem Nachmittag nachbauen. Zweitens fehlt ihnen die tiefe Integration mit Ihren tatsächlichen Daten; sie kämpfen mit den Feinheiten unternehmensspezifischer Terminologie, veralteter Codebasen oder Zugriffskontrollen. Drittens – und das ist der entscheidende Punkt – senden sie Ihre Daten weiterhin über das öffentliche Internet an einen Drittanbieter. Das Sicherheitsrisiko hat sich nicht geändert. Sie haben ihm nur ein Logo hinzugefügt.

Was bedeutet "die Intelligenz besitzen" eigentlich?

Es gab einen bestimmten Moment, in dem sich unser Ansatz bei Veriprajna herauskristallisierte. Wir arbeiteten mit einem Kunden in einer regulierten Branche – ich kann nicht sagen, welche, aber denken Sie an "die Art von Daten, bei denen ein Leck in die Abendnachrichten kommt." Ihr Rechtsteam hatte gerade ein vielversprechendes KI-Pilotprojekt gekippt, weil es auf einer öffentlichen API beruhte. Das Engineering-Team war außer sich. Die Geschäftseinheit drohte, im Alleingang loszulegen und mit privaten Konten ihr eigenes Ding zu bauen.

Ich war in einem Anruf mit meinem leitenden Architekten, und er sagte etwas Einfaches: "Warum streiten wir darüber, welche API wir verwenden sollen? Wir sollten das Modell einfach selbst betreiben."

Da haben wir uns voll und ganz dem verschrieben, was ich heute Deep AI nenne – die Bereitstellung quelloffener großer Sprachmodelle direkt innerhalb der eigenen Infrastruktur des Kunden. Nicht das Modell eines anderen umhüllen. Nicht Intelligenz pro Token mieten. Sie tatsächlich besitzen.

So sieht das in der Praxis aus. Sie nehmen ein leistungsstarkes Open-Weights-Modell – zum Beispiel Llama 3 von Meta, wo die Version mit 70B Parametern in vielen Benchmarks mit GPT-4 mithält – und stellen es auf GPU-Instanzen innerhalb der Virtual Private Cloud des Kunden bereit. Die Modellgewichte liegen auf Hardware, die der Kunde kontrolliert. Die Inferenz-Engine läuft hinter der Firmen-Firewall. Wenn eine Entwicklerin das Modell mit proprietärem Code promptet, wandert dieser Code von ihrem Laptop zu einem internen Server, wird im Speicher verarbeitet und kommt zurück. Er berührt niemals das öffentliche Internet. Er landet niemals auf einem Server eines Drittanbieters.

Wir kombinieren dies mit dem, was wir Private RAG nennen – Retrieval-Augmented Generation aufgebaut auf Vektordatenbanken, die innerhalb derselben sicheren Umgebung bereitgestellt werden. Die Dokumente des Unternehmens werden lokal eingelesen, eingebettet und gespeichert. Und entscheidend ist: Das System respektiert bestehende Zugriffskontrollen. Wenn Sie keine Berechtigung haben, ein Dokument in SharePoint zu sehen, wird die KI es auch nicht abrufen, um Ihre Frage zu beantworten. Das Problem der "flachen Autorisierung" – bei dem ein Chatbot versehentlich vertrauliche Daten für jeden zutage fördert, der danach fragt – existiert in dieser Architektur schlicht nicht.

Wie macht man ein rohes Modell Enterprise-tauglich?

Eine der härtesten Lektionen, die wir früh gelernt haben: Ein Modell bereitzustellen ist vielleicht dreißig Prozent der Arbeit. Es sicher zu machen, damit Tausende von Beschäftigten es jeden Tag nutzen können – das sind die anderen siebzig.

Rohe Sprachmodelle sind unberechenbar. Sie diskutieren bereitwillig Themen, die sie nicht sollten, erzeugen Inhalte, die gegen Unternehmensrichtlinien verstoßen, oder reagieren auf raffinierte Prompt-Injektionen, die darauf ausgelegt sind, Sicherheitsprotokolle zu umgehen. Sie brauchen Guardrails – im Grunde eine Firewall für Prompts.

Wir implementieren NVIDIA NeMo Guardrails als programmierbare Schicht um das Modell. Bevor ein Prompt das Modell erreicht, wird er gescannt. Wenn jemand eine Sozialversicherungsnummer oder eine Kreditkartennummer eingibt, fängt der Guardrail sie ab. Wenn jemand einen HR-Bot nach Datenbankpasswörtern fragt, erkennt das System die Absichtsdiskrepanz und verweigert die Antwort. Wenn jemand einen Jailbreak-Angriff versucht – diese "ignoriere alle vorherigen Anweisungen"-Tricks –, fängt die Verteidigungsschicht ihn ab.

Ich erinnere mich an einen Penetrationstest, den wir bei einer unserer frühen Bereitstellungen durchführten. Unser Red Team versuchte zwei Tage lang, Trainingsdaten zu extrahieren oder Themenbeschränkungen zu umgehen. Sie wurden kreativ – verschachtelte Rollenspiel-Prompts, kodierte Anweisungen, alles Mögliche. Die Guardrails hielten stand. Mein Architekt schickte mir um 2 Uhr morgens einen Screenshot des Protokolls der blockierten Versuche mit einer einzigen Nachricht: "Die Mauer steht." Das war eine gute Nacht.

Für die vollständige technische Aufschlüsselung dieser Architektur – den Inferenz-Stack, die Vektordatenbank-Konfiguration, die Guardrail-Implementierung – siehe unsere technische Tiefenanalyse zur Enterprise-KI-Sicherheit.

"Aber GPUs sind teuer und APIs sind billig"

Das ist der Einwand, den ich am häufigsten von CFOs höre, und er ist auf eine Weise falsch, die es sich zu entwirren lohnt.

Ja, API-Preise sehen an der Oberfläche billig aus – Bruchteile eines Cents pro Token. Aber Enterprise-RAG-Anwendungen sind gierig token-hungrig. Um eine einzige Frage zu beantworten, ruft das System vielleicht zehn Seiten Kontext als Eingabe-Token ab. Multiplizieren Sie das über tausend Beschäftigte, die zehn Fragen pro Tag stellen, und Sie kommen auf 1.000 bis 3.000 Dollar pro Tag. Das ist potenziell eine Million Dollar pro Jahr, und es skaliert linear. Wenn sich die Nutzung verdoppelt, verdoppelt sich die Rechnung.

Selbst gehostete Modelle funktionieren anders. Sie zahlen für die Hardware – GPU-Miete oder -Kauf – und Strom. Ein einziger gut konfigurierter Knoten kann Tausende von Anfragen pro Sekunde bewältigen. Bis Sie diesen Knoten sättigen, sind die Grenzkosten des nächsten Tokens praktisch null. Bei einem mittelgroßen Unternehmen, das eine Milliarde Token pro Monat verarbeitet, haben wir gesehen, dass Selbst-Hosting 50 bis 70 Prozent günstiger ausfällt als vergleichbare API-Kosten, mit Datenschutz als kostenlosem Bonus.

Und es gibt versteckte Kosten bei APIs, die niemals auf der Rechnung auftauchen. Ratenbegrenzungen, die während unternehmensweiter Rollouts zu Ausfällen führen. Modell-Abkündigungen, die Sie zwingen, jeden Prompt und Workflow neu zu testen, wenn der Anbieter eine Version einstellt. Bei einem selbst gehosteten Modell ändert sich nichts, es sei denn, Sie entscheiden sich, es zu aktualisieren. Sie bekommen Stabilität. Sie bekommen Vorhersehbarkeit. Sie können aufhören, sich Sorgen zu machen, was OpenAIs Preisgremium im nächsten Quartal beschließt.

In Enterprise-Größenordnung ist Selbst-Hosting nicht die teure Option. Es ist diejenige, die Sie nicht in den Bankrott treibt, wenn die Nutzung Erfolg hat.

Warum macht das nicht bereits jeder?

Die Leute fragen mich das, und die ehrliche Antwort lautet: Es ist schwer. Nicht konzeptionell – die Logik ist einfach –, sondern operativ. Sie brauchen Leute, die GPU-Orchestrierung mit Kubernetes verstehen, die vLLM für optimalen Durchsatz konfigurieren können, die wissen, wie man RBAC-fähige Retrieval-Pipelines baut, die Guardrails implementieren können, die streng genug sind, um Missbrauch zu verhindern, aber flexibel genug, um Nutzer nicht zu frustrieren.

Die meisten Unternehmen haben dieses Team nicht. Die meisten KI-Beratungsfirmen auch nicht – sie wissen, wie man eine API aufruft, nicht wie man einen Inferenz-Stack bereitstellt. Das ist die Lücke, die wir bei Veriprajna füllen. Wir verkaufen keinen Zugang zu einem Modell. Wir bauen die Fähigkeit auf, Modelle eigenständig zu betreiben. Wenn wir gehen, besitzt der Kunde alles – die feinabgestimmten Modellgewichte, die Vektorindizes, die Orchestrierungsinfrastruktur. Es gehört ihm. Das ist der ganze Sinn.

Das andere, was die Einführung verlangsamt, ist Trägheit. Der CISO, der ChatGPT blockiert hat, hat das Gefühl, etwas getan zu haben. Zuzugeben, dass das Verbot nicht funktioniert hat, bedeutet zuzugeben, dass das letzte Jahr der Richtliniendurchsetzung Theater war. Das ist ein schwieriges Gespräch, das man mit einem Vorstand führen muss. Aber die Alternative – so zu tun, als existiere das Problem nicht, während Beschäftigte Quellcode in private KI-Konten einfügen – ist schlimmer. Es ist keine Frage, ob das nächste Leck im Samsung-Maßstab passiert. Es ist eine Frage des Wann, und ob es Ihnen passiert.

Das im Shadow AI verborgene Signal

Hier ist, was die meisten Menschen meiner Meinung nach an der Shadow-AI-Epidemie übersehen: Es ist nicht nur ein Sicherheitsproblem. Es ist ein Signal. Ein lautes, unmissverständliches Signal, dass Ihre Belegschaft verzweifelt nach besseren Werkzeugen sucht und bereit ist, ihre Jobs zu riskieren, um sie zu bekommen.

Sechsundvierzig Prozent der Beschäftigten sagen, dass sie sich einem ausdrücklichen Verbot widersetzen würden. Das ist kein Widerstand um seiner selbst willen. Das sind Menschen, die Ihnen durch ihr Handeln sagen, dass KI zu einem wesentlichen Bestandteil ihrer Arbeitsweise geworden ist. Die Frage ist nicht, ob Ihre Organisation generative KI nutzen wird. Diese Entscheidung ist bereits gefallen – von Ihren Beschäftigten, ohne Ihre Erlaubnis, auf ihren privaten Geräten, in der Mittagspause.

Die einzige verbleibende Frage ist, ob Sie einen sicheren Weg bereitstellen, das zu tun, was sie bereits unsicher tun.

Shadow AI ist Ihre Belegschaft, die mit ihren Tastenanschlägen abstimmt. Sie haben sich für KI entschieden. Jetzt entscheiden Sie: sichtbar und sicher oder unsichtbar und Daten ausblutend.

Wir haben die Ära hinter uns gelassen, in der "Nein" eine akzeptable KI-Strategie war. Die Open-Source-Modelle sind gut genug. Die Bereitstellungsinfrastruktur ist ausgereift genug. Die Wirtschaftlichkeit stimmt. Das Einzige, was zwischen den meisten Unternehmen und einer souveränen KI-Fähigkeit steht, ist die Bereitschaft, aufzuhören, so zu tun, als würde ein Verbot funktionieren.

Sie müssen KI nicht verbieten. Sie müssen sie besitzen.