Unternehmens-Dashboard mit 317 genutzten GenAI-Apps, nur wenige davon genehmigt, ein privates LLM innerhalb eines Sicherheitsperimeters
Artificial IntelligenceCybersecurityData Privacy

Der Tag, an dem unsere private KI einem Mitarbeiter ein Gehalt zeigte, das er nie hätte sehen dürfen

Ashutosh SinghalAshutosh Singhal2. Mai 202612 min

Das Memo, das nicht funktioniert

Genau jetzt hat irgendwo in Ihrem Unternehmen jemand einen Kundenvertrag in einen Chatbot eingefügt, um ihn zusammenfassen zu lassen. Sie haben nicht gefragt. Sie sind nicht böswillig. Sie hatten eine Deadline und ein Tool, das funktionierte, und das Tool hat diesen Vertrag zufällig an einen Server gesendet, der einem Unternehmen auf einem anderen Kontinent gehört.

Ich weiß das, weil jeder CISO, mit dem ich gearbeitet habe, dasselbe Dashboard hat, und es erzählt dieselbe Geschichte. Einer von ihnen öffnete in einem Meeting Netskope und zeigte mir 317 verschiedene generative KI-Apps, die in seiner Organisation aktiv genutzt wurden. Er hatte eine Handvoll davon genehmigt. Der Rest waren seine Mitarbeiter, die ihre eigenen Probleme lösten, ein Einfügen nach dem anderen.

Diese Lücke – zwischen der KI, die Sie freigegeben haben, und der KI, die Ihre Leute tatsächlich nutzen – ist das Problem, zu dessen Lösung ich den jüngsten Abschnitt meiner Karriere dem Aufbau von Veriprajna gewidmet habe. Wir machen private LLM-Bereitstellung: Wir platzieren ein leistungsfähiges großes Sprachmodell innerhalb Ihrer eigenen Infrastruktur, unter Ihren eigenen Kontrollen, sodass die Arbeit, die Ihre Mitarbeiter bereits mit KI erledigen, nicht mehr seitlich aus dem Gebäude sickert. Souveräne KI ist kein philosophischer Pitch über nationale technologische Unabhängigkeit. Sie ist die praktische Antwort auf eine Frage, an der jede Sicherheitsverantwortliche bereits scheitert: Wohin gehen unsere Daten, und können wir es beweisen?

Der Instinkt, wenn man dieses Dashboard zum ersten Mal sieht, ist, ein Memo zu verschicken. Die Tools zu verbieten. Ich habe diesen Gedanken früh selbst ausprobiert, und ich möchte Ihnen genau sagen, warum er auseinanderfällt – denn dieses Scheitern ist der ganze Grund, warum es dieses Unternehmen gibt.

Ein Verbot von KI entfernt sie nicht aus Ihrem Unternehmen. Es entfernt lediglich Ihre Sicht darauf.

Die Zahlen belegen den Fall besser, als ich es kann. IBMs Bericht „Cost of a Data Breach" 2025 stellte fest, dass eines von fünf Unternehmen bereits eine Datenpanne erlitten hat, die mit Schatten-KI in Verbindung steht – nicht genehmigte Tools, die ohne Wissen der IT genutzt werden. Diese Pannen kosteten im Durchschnitt 670.000 $ mehr als herkömmliche Vorfälle, und ihre Erkennung dauerte 247 Tage gegenüber 241 für alles andere. Eine separate Umfrage brachte es unverblümt auf den Punkt: 43 % der Mitarbeiter geben zu, sensible Arbeitsinformationen mit KI-Tools zu teilen, die ihr Arbeitgeber nie genehmigt hat. Ein Verbot ändert dieses Verhalten nicht. Es garantiert nur, dass Sie der Letzte sind, der erfährt, wenn etwas schiefgeht.

Warum behebt ein privater Chatbot Schatten-KI nicht?

RBAC-bewusster RAG-Ablauf: Identitätsanbieter zur Synchronisierungsschicht zur Vektordatenbank mit Berechtigungsprüfung zur Abfragezeit und Termination-Webhook

Wenn man es also nicht verbieten kann, baut man die sichere Alternative. Man richtet einen internen Chatbot ein, verbindet ihn mit einem guten Modell und sagt allen, sie sollen stattdessen den nutzen. Hier habe ich meinen teuersten Fehler gemacht, und es lohnt sich, dabei zu verweilen, weil ihn fast jeder macht.

Die erste interne Bereitstellung, an der ich nah dran war, sah in der Demo großartig aus. Saubere Oberfläche, schnelle Antworten, ein Modell, das die Dokumente des Unternehmens kannte. Wir waren stolz darauf. Dann, während des Pilotprojekts, stellte jemand in einer Juniorposition ihm eine Frage zu einem Vergütungsplan – und es antwortete. Vollständig. Präzise. Mit Details, die aus einem Dokument stammten, das diese Person nichts anging.

Nichts war gehackt worden. Das Retrieval-System tat genau das, wofür wir es gebaut hatten: die relevantesten Dokumente finden und sie dem Modell zuführen. Wir hatten ihm nur nie beigebracht, dass Relevanz und Berechtigung unterschiedliche Dinge sind. Der Chatbot war ein treuer Bibliothekar, dem man den Generalschlüssel zu jedem verschlossenen Raum im Gebäude gegeben hatte.

Dieser Nachmittag hat das gesamte Problem für mich neu gerahmt. Das Modell war nie der schwierige Teil. Der schwierige Teil ist die Berechtigung.

Hier ist das, was Ihnen in den Anbieter-Demos niemand sagt: Die meisten Unternehmen tragen Jahre angesammelter Zugriffslogik mit sich, vergraben im Active Directory – verschachtelte Sicherheitsgruppen, vererbte Berechtigungen, Verteilerlisten, Organisationseinheiten, übereinandergeschichtet von Menschen, die vor Jahren gegangen sind. Wenn man ein Retrieval-System baut, ist der naive Schritt, jedes Textstück mit einer flachen Liste dessen zu versehen, wer es sehen darf. Das bricht in dem Moment zusammen, in dem man auf reale Gruppenverschachtelung trifft. Ein Dokument erbt Zugriff von einer Gruppe, die von einer anderen Gruppe erbt, zu der ein Auftragnehmer vor Jahren für ein einziges Projekt hinzugefügt wurde.

Dies richtig zu machen ist die eigentliche Arbeit. Wir haben eine Synchronisierungsschicht gebaut, die zwischen dem Identitätsanbieter – Active Directory, Okta, Azure AD – und der Vektordatenbank sitzt, in der die Dokumente liegen. Sie löst Gruppenmitgliedschaften rekursiv auf, glättet diese Vererbungsketten und aktualisiert die Zugriffsmetadaten in engem Takt. Bei den meisten Bereitstellungen synchronisieren wir alle 60 bis 90 Sekunden. Aber der Fall, der einen nachts wachhält, ist die Kündigung: Jemand wird um 9 Uhr hinausbegleitet, und man darf nicht haben, dass das System um 9:05 Uhr noch mit dessen Zugriff antwortet. Deshalb warten Widerrufe nicht auf die nächste Synchronisierung – ein Okta- oder Azure-AD-Webhook löst eine sofortige Löschung aus, in dem Moment, in dem das Konto deaktiviert wird.

Relevanz und Berechtigung sind nicht dasselbe, und ein Retrieval-System, das sie verwechselt, wird die richtige Antwort genau der falschen Person aushändigen. Keine große RAG-Plattform löst dies von Haus aus – ich habe danach gesucht.

Das ist keine Marketing-Zuversicht – es ist das, was ich bei der Suche gefunden habe. TrueFoundry, Databricks, die cloud-nativen Suchprodukte haben alle Teilantworten: schreibgeschützte Berechtigungsprüfungen, periodische Synchronisierungen. Keines von ihnen erbt das vollständige Bild von Gruppenrichtlinien und attributbasierten Regeln – zeitlich begrenzter Zugriff, „nur von einem verwalteten Gerät", Klassifizierungsstufen –, auf denen ein reguliertes Unternehmen tatsächlich läuft. Deshalb bauen wir diese Policy-Engine als individuelle Arbeit, weil es dafür keine Abkürzung gibt. Wenn Sie die vollständige Architektur wollen, wie diese Berechtigungsdurchsetzung durchgängig funktioniert, ist sie auf unserer Seite zur souveränen KI und privaten LLM-Bereitstellung dargelegt.

Macht ein Rechenzentrum in Frankfurt Ihre KI europäisch?

Es gibt eine zweite Falle, und sie ist subtiler, weil sie wie Compliance aussieht. Viele Unternehmen greifen zu einer verwalteten Option – Azure OpenAI, AWS Bedrock – und fühlen sich sicher. Die Daten bleiben in ihrem Cloud-Tenant. Es gibt VPC-Endpunkte, privates Networking, einen Stapel von Zertifizierungen. Für viele Unternehmen ist das tatsächlich die richtige Antwort, und ich sage einem Klienten das ins Gesicht, wenn es so ist.

Aber unter der technischen Tatsache liegt eine rechtliche, die ich ständig übersehen sehe. Ihre KI in einem Frankfurter Rechenzentrum zu hosten, macht sie nicht europäisch. Microsoft und Amazon sind Unternehmen mit Hauptsitz in den USA, und das macht sie dem US CLOUD Act unterworfen, der es amerikanischen Strafverfolgungsbehörden erlaubt, ein US-Unternehmen zu zwingen, Daten herauszugeben, die es irgendwo auf der Welt speichert. Artikel 48 der DSGVO besagt, dass eine ausländische Gerichtsanordnung hier nur mit einem internationalen Abkommen gültig ist. Diese beiden Gesetze weisen in entgegengesetzte Richtungen, und Ihre Daten sitzen in der Lücke.

Das hörte im März 2026 auf, theoretisch zu sein. Österreichs Datenschutzbehörde verhängte gegen ein Wiener Fintech eine Geldstrafe von 450.000 EUR, weil es Kreditbewertungen über eine in den USA ansässige KI-API durchführte – und wertete dies als unrechtmäßige Datenübermittlung nach DSGVO. Das Unternehmen hatte, wie es fast jeder tut, angenommen, dass Hosting in der europäischen Region ausreiche. Tat es nicht. Ich habe dieses Urteil mit einem Lesezeichen versehen, weil es die sauberste Veranschaulichung eines Risikos ist, die ich gefunden habe – eines Risikos, von dem die meisten Vorstände nicht wissen, dass sie es tragen.

Der Spiegelfall ist eine US-Krankenhauskette: Dort spielt der CLOUD Act kaum eine Rolle, aber die Business-Associate-Anforderungen von HIPAA und – sobald man Bundesaufträge berührt – das NIST AI Risk Management Framework und FedRAMP High werden stattdessen zur Linie, die man zieht. Die Zuständigkeitsfrage behält dieselbe Form; nur das Gesetz an der Wand ändert sich.

Für ein US-Finanzunternehmen ohne europäische Kunden spielt nichts davon eine Rolle, und Azure OpenAI ist oft genau richtig. Für eine europäische Bank, die die Daten ihrer eigenen Kunden verarbeitet, kehrt sich die Rechnung um – und die einzige Konfiguration, die die CLOUD-Act-Exposition vollständig beseitigt, ist eine selbst gehostete Bereitstellung auf Open-Weight-Modellen, die auf Infrastruktur läuft, deren Betreiber nicht der US-Gerichtsbarkeit unterliegt. Das ist die eigentliche Funktion der europäischen souveränen Cloud-Anbieter – OVHcloud, Scaleway, die neue Blackwell-Kapazität, die in Europa online geht. Nicht Patriotismus. Zuständigkeit.

Und die Deadline ist real. Die Transparenzpflichten aus Artikel 50 des EU AI Act werden ab dem 2. August 2026 durchsetzbar. Stapelt man die Strafen des AI Act auf die der DSGVO, erreicht die kombinierte Obergrenze 55 Millionen EUR oder 11 % des weltweiten Jahresumsatzes. Das ist keine Geldstrafe, die man verkraftet. Das ist eine Zahl, die Karrieren beendet.

„Nutzt einfach die API" – Das Gespräch, das ich jeden Monat führe

Break-even-Diagramm: API vs. selbst gehostetes LLM, Kosten kreuzen sich bei 2 Mio. Token pro Tag, mit Kosten pro Token und MLOps-Hinweis

Der Widerspruch, den ich am häufigsten höre, ist finanziell, und er ist berechtigt: Selbst-Hosting klingt teuer. Warum GPUs kaufen und ein Team einstellen, wenn eine API nur eine Kreditkartenabbuchung entfernt ist?

Weil die Rechnung kippt, und die Stelle, an der sie kippt, ist spezifischer, als die Leute erwarten. Für ein selbst gehostetes Modell mit 70 Milliarden Parametern kostet die Inferenz rund 0,013 $ pro tausend Token. Dieselbe Arbeit über eine gehostete API wie GPT-4o mini kostet 0,15 $ bis 0,60 $ pro tausend. Das ist kein Rundungsunterschied. Aber es zählt erst ab einem bestimmten Volumen, denn selbst gehostete GPUs kosten Geld, ob man sie nun nutzt oder sie im Leerlauf sind.

Der Break-even liegt bei rund zwei Millionen Token pro Tag. Unterhalb dieser Linie gewinnen APIs – man zahlt nicht für Hardware im Leerlauf, und ich rate einem Klienten ohne mit der Wimper zu zucken, bei APIs zu bleiben. Darüber spart Selbst-Hosting 60 bis 85 % bei der Inferenz. Ein Fintech, das ich kenne, senkte seine monatliche KI-Rechnung von 47.000 $ auf 8.000 $, indem es zu hybridem Selbst-Hosting wechselte.

Aber – und das ist der Teil, den die GPU-Preisschilder verbergen – die Hardware ist selten der größte Posten. Bei heutigen Preisen mietet man eine H100 für 2,50 $ bis 3,50 $ pro Stunde, und eine einzige, die ein Open-Weight-Modell wie Llama 3.3 70B ausführt, bedient 30 bis 50 gleichzeitige Nutzer bei einer Latenz von unter zwei Sekunden. Der teure Teil sind die Menschen. Man braucht MLOps-Ingenieure – mindestens zwei für Produktionszuverlässigkeit – zu je 200.000 $ bis 350.000 $, plus Monitoring, Evaluierungs-Pipelines, eine Rollback-Strategie. Für ein Team, das neu im Betrieb von Modellen ist, landen die Gesamtbetriebskosten im ersten Jahr bei etwa dem 3,2-Fachen der reinen API-Kosten. Für ein erfahrenes Team mit bestehendem Tooling sinkt es auf etwa das 1,8-Fache.

Dieses Fintech, das seine Rechnung so drastisch senkte? Es funktionierte, weil es bereits ein Kubernetes-Team und 18 Monate betrieblicher Narben hatte. Derselbe Schritt hätte ein Team, das während der Arbeit lernt, in den Bankrott getrieben.

Die GPU ist der günstigste Teil des Selbst-Hostings. Die zwei Ingenieure, die sie am Laufen halten, sind der Posten, der entscheidet, ob die Rechnung tatsächlich aufgeht – und jeder, der „sollten wir selbst hosten?" schneller beantwortet als mit „es kommt auf Ihr Volumen und Ihr Team an", verkauft Ihnen etwas.

Die gute Nachricht unter alldem ist, dass die Open-Weight-Modelle gut genug wurden, um die Frage überhaupt lohnenswert zu machen. Llama 3.3 70B erreicht 86 % im MMLU-Benchmark und läuft selbst gehostet rund 25-mal günstiger als die entsprechende API. DeepSeek-V3 erzielt 88,5 % – und übertrifft damit knapp ein proprietäres Spitzenmodell in dieser Kennzahl. Für die große Mehrheit der Unternehmensaufgaben ist das Modell, das Sie innerhalb Ihrer eigenen Mauern betreiben können, nicht mehr der Kompromiss, der es vor zwei Jahren war.

Was passiert, wenn die KI aufhört, nur zu reden

Eine Entwicklung macht all dies aus umsichtig dringlich. Die KI in Ihrem Unternehmen wird aufhören, ein Chatbot zu sein, und anfangen, ein Agent zu sein – Software, die nicht nur Fragen beantwortet, sondern Handlungen vornimmt, mit ständigem Zugriff auf Ihre Systeme.

Gartner erwartet, dass bis Ende 2026 40 % der Unternehmensanwendungen KI-Agenten einbetten werden, gegenüber unter 5 % ein Jahr zuvor. Aber nur etwa 5 % der Unternehmen haben Agenten tatsächlich vom Pilotprojekt in die Produktion überführt, und das Sicherheitsbild ist wirklich alarmierend: 92 % der Sicherheitsverantwortlichen sagen, dass ihnen die volle Sicht auf die KI-Identitäten fehlt, die bereits in ihrer Umgebung operieren. Ein Agent, der Ihr CRM lesen, Tickets einreichen und Geld bewegen kann, ist ein ganz anderes Risiko als ein Chatbot, der ein PDF zusammenfassen kann.

Alles, was ich beschrieben habe – die Berechtigungsdurchsetzung, die Zuständigkeitskontrolle, die Laufzeit-Guardrails, die Prompt Injection abfangen – hört auf, ein Nice-to-have zu sein, in dem Moment, in dem Ihre KI handeln kann. Ein Chatbot, der das falsche Dokument abruft, ist eine Peinlichkeit. Ein Agent mit ständigem Zugriff und ohne Berechtigungsgrenze ist ein Vorfall, der auf ein Datum wartet.

Das ist die Neurahmung, die ich Ihnen mitgeben würde. Die Guardrail-Schicht ist auch hier von Bedeutung – und es ist wissenswert, dass Standardoptionen wie NVIDIAs NeMo Guardrails echte Latenz hinzufügen, 100 bis 300 Millisekunden pro Aufruf, weshalb wir die Policy-Logik auf das spezifische Compliance-Muster abstimmen, statt einen generischen Filter aufzuschrauben. Aber der tiefere Punkt ist architektonisch. Man kann keinen Agenten auf Infrastruktur setzen, die man nicht kontrolliert, und ihn dann als reguliert bezeichnen.

Der Teil, gegen den die Leute immer Einspruch erheben

Die Leute fragen mich, ob sie wirklich wählen müssen – ob sie einige Cloud-APIs behalten und sich trotzdem souverän nennen können. Ja: Die meisten Bereitstellungen, die ich empfehlen würde, sind hybrid, sensible Workloads auf privater Infrastruktur und risikoarme auf verwalteten APIs, mit einer klaren Policy-Grenze, die entscheidet, was was ist. Souveränität war nie ein Alles-oder-Nichts-Gelübde; es geht darum, die Linie an der richtigen Stelle zu ziehen und beweisen zu können, wo sie sitzt.

Die andere Frage ist der Zeitpunkt – ist es nicht zu früh? Die österreichische Geldstrafe ist bereits gefallen. Die Deadline aus Artikel 50 steht im Kalender. Ihre Mitarbeiter fügen, während Sie dies lesen, Daten in Hunderte von Tools ein, die Sie nicht genehmigt haben. Die Kosten des frühen Handelns sind ein Projekt. Die Kosten des späten Handelns werden an einer Obergrenze von elf Prozent des Umsatzes gemessen.

Ich habe Veriprajna gegründet, weil ich zusah, wie ein treuer kleiner Chatbot einem Juniormitarbeiter ein Gehalt aushändigte, das er ihm nie hätte zeigen dürfen, und mir klar wurde, dass die gesamte Branche Modelle verkaufte, während das eigentliche Problem die Kontrolle war. Das Modell ist der einfache Teil. Das war es immer.

Ihre Leute warten nicht auf die Erlaubnis, KI zu nutzen. Die einzige offene Frage ist, ob die KI, die sie nutzen, Ihnen gegenüber rechenschaftspflichtig ist.

Wenn Sie sehen möchten, wie wir diese Kontrolle für ein spezifisches Risikoprofil gestalten – wo die Linie zwischen privat und verwaltet sitzen sollte, wie die Berechtigungsschicht aufgebaut wird, wie die realen Gesamtkosten für Ihr Team aussehen –, ist das genau das, was wir ehrlich und anbieterneutral auf der Veriprajna-Seite zur souveränen KI darlegen. Bringen Sie Ihr Dashboard mit. Ich weiß bereits ungefähr, was darauf steht.

Verwandte Forschung

Auch veröffentlicht auf

Entwickeln Sie Ihre KI mit Zuversicht.

Arbeiten Sie mit einem Team zusammen, das über umfassende Erfahrung im Aufbau der nächsten Generation von Unternehmens-KI verfügt. Wir helfen Ihnen, eine KI-Strategie zu entwerfen, zu entwickeln und einzuführen, der Sie vertrauen können.

Veriprajna Deep-Tech-Beratung ist auf die Entwicklung sicherheitskritischer KI-Systeme für die Bereiche Gesundheitswesen, Finanzen und Regulierung spezialisiert. Unsere Architekturen werden anhand etablierter Protokolle validiert und mit umfassender Compliance-Dokumentation belegt.