Was Self-hosted-KI-Agenten für Compliance-Teams wirklich bedeuten

Im April 2026 veröffentlichten die US-Bankenaufsichtsbehörden SR 26-2, die lange erwartete Aktualisierung der 15 Jahre alten Leitlinien zum Modellrisikomanagement. Die neuen Leitlinien schliessen generative und agentische KI ausdrücklich von ihrem formellen Geltungsbereich aus und begründen dies mit einer Technologie, die «neuartig und sich rasch weiterentwickelnd» sei (Federal Reserve, 2026).

Für Compliance-Teams, die KI-Agentenplattformen evaluieren, ist diese Lücke der Ausgangspunkt, nicht eine Randnotiz. Die Regulatoren haben das Regelwerk für agentische KI noch nicht fertiggestellt, und dieses Fehlen entbindet ein Unternehmen nicht von der Pflicht, diese Systeme verantwortungsvoll zu governen. Es verlagert die Verantwortung auf denjenigen, der sie einsetzt.

«Self-hosted AI Agents» bedeutet, dass die Orchestrierungs-Engine, idealerweise auch die Modell-Inferenz selbst, innerhalb einer vom Unternehmen kontrollierten Infrastruktur läuft statt in der Cloud eines Anbieters. Diese eine architektonische Entscheidung bestimmt, wo Prompts, Dokumente und Reasoning-Traces physisch liegen, wer darauf zugreifen kann und welches Landesrecht eine Offenlegung erzwingen kann.

Dieser Beitrag untersucht, was der Begriff technisch und rechtlich tatsächlich verändert, und was nicht.

Die regulatorischen Vorgaben, mit denen Compliance-Teams schon heute konfrontiert sind

Zahlreiche verbindliche Vorgaben gelten bereits für KI-gestützte Automatisierung in regulierten Branchen, obwohl eine umfassende Regulierung agentischer KI noch Jahre entfernt ist. Der DORA (Digital Operational Resilience Act) gilt seit dem 17. Januar 2025 für jedes EU-Finanzunternehmen.

Er behandelt KI-Anbieter als IKT-Drittparteien, für die eine formelle Risikobeurteilung erforderlich ist (EIOPA, 2025). Compliance-Teams brauchen eine Liste dessen, was heute gilt, keine Prognose.

EU-Vorgaben: DORA und der AI Act

Der DORA verpflichtet EU-Finanzunternehmen, ein Informationsregister zu führen, das sämtliche IKT-Drittparteibeziehungen abdeckt, einschliesslich KI-Anbieter (EIOPA; ESMA, 2025). Das ist keine in Prüfung befindliche Leitlinie, sondern eine verbindliche operative Pflicht mit bestehendem Durchsetzungsmechanismus.

Der EU AI Act legt sich mit einem gestaffelten Zeitplan über den DORA. Die Regeln zu verbotenen Praktiken traten am 2. Februar 2025 in Kraft, die Transparenzpflichten für GPAI folgten am 2. August 2025 (Europäische Kommission, 2025).

Mit der «Digital Omnibus»-Einigung vom 7. Mai 2026 wurde die Frist für Hochrisikosysteme, die viele Anwendungen im Finanzsektor betrifft, von August 2026 auf den 2. Dezember 2027 verschoben; produktintegrierte Systeme erhielten Aufschub bis August 2028 (Holland & Knight; Travers Smith, 2026).

Die Bussgelder wurden dabei nicht verschoben. Für verbotene Praktiken gelten weiterhin Bussen von bis zu 35 Mio. Euro oder 7 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist (artificialintelligenceact.eu, 2025).

US-Vorgaben: ein zunehmend fragmentiertes Bild von Bundesstaat zu Bundesstaat

Colorados SB 26-189, unterzeichnet am 14. Mai 2026 und in Kraft ab 1. Januar 2027, reguliert automatisierte Entscheidungsfindung mit Vorab-Hinweisen und Erklärungspflichten bei nachteiligen Entscheiden (Colorado General Assembly; Norton Rose Fulbright, 2026). Es ist bisher das detaillierteste Regelwerk auf Bundesstaatsebene, und andere Bundesstaaten beobachten es genau.

Texas und Kalifornien verfolgen eigene Spuren. Der texanische TRAIGA trat am 1. Januar 2026 in Kraft, mit Bussen von bis zu 200'000 USD pro Verstoss (Norton Rose Fulbright, 2025). Kaliforniens CCPA-Regeln zu automatisierter Entscheidungsfindung treten am 1. Januar 2027 in Kraft (Baker Botts, 2026). Keine zwei Bundesstaaten nähern sich denselben Anforderungen an.

Versicherungsspezifische Vorgaben: das NAIC-Bulletin

Versicherer stehen vor einer parallelen, schneller voranschreitenden Entwicklung. Das NAIC Model Bulletin on Insurers' Use of AI, verabschiedet im Dezember 2023, verlangt ein schriftliches KI-Governance-Programm für Underwriting, Tarifierung, Schadenbearbeitung und Marketing.

Mehr als 20 US-Bundesstaaten hatten es bis Mitte 2026 übernommen, und die NAIC begann im März 2026 in 12 Bundesstaaten mit dem Pilotbetrieb eines KI-Bewertungstools für Marktverhaltensprüfungen (NAIC; Quarles Law; Plante Moran, 2026).

Sicherheits- und Risikobedenken, nicht regulatorische Unsicherheit, gelten inzwischen als das grösste Hindernis, das Organisationen bei der Skalierung agentischer KI nennen. Der durchschnittliche Reifegrad im Bereich Responsible AI stieg 2026 auf 2,3, gegenüber 2,0 im Vorjahr, und nur 14 % der Organisationen berichten von vollständig integrierter Datenbereitschaft (McKinsey, 2026). Nichts davon wartet auf Klarheit auf Bundesebene.

Was «Self-hosted» technisch tatsächlich verändert

Self-hosting verändert, wo vier konkrete Kontrollentscheidungen getroffen werden: Datenresidenz, Standort der Audit-Trails, Umfang der Sub-Prozessoren-Kette und Verwahrung der Verschlüsselungsschlüssel. Jede dieser Entscheidungen verlagert sich von einem anbietergesteuerten Standard zu einer unternehmensgesteuerten Konfiguration, was genau das ist, was die meisten Compliance-Rahmenwerke des Jahres 2026 heute von Organisationen verlangen nachzuweisen.

Datenresidenz: Deployment-Entscheidung statt Inferenz-Wette

Bei Self-hosted-Systemen ist die Datenresidenz zum Zeitpunkt des Deployments festgelegt. Bei cloudgehosteten agentischen Systemen wird sie zu einer laufenden Wette pro einzelner Anfrage. Agentische Architekturen treffen dynamische Routing-Entscheidungen: externe Tool-Aufrufe, regionsübergreifende Vektordatenbank-Replikate, Delegation an Sub-Agenten. Diese können Daten ausserhalb einer definierten Region bewegen, selbst wenn die Quelldatenbank selbst nie verlassen wurde.

Das bedeutet: Residenz-Zusicherungen, die bei Vertragsabschluss zu einer Cloud-Agentenplattform gemacht wurden, müssen sechs Monate später nicht mehr zutreffen. Neue Tools oder Sub-Agenten, die dem Workflow hinzugefügt werden, können verschieben, wo die Inferenz tatsächlich läuft.

Kontrolle über Audit-Trails

Cloud-LLM-APIs legen Prompt- und Antwort-Logs sowie Reasoning-Traces standardmässig auf der Infrastruktur des Anbieters ab. Damit verlässt der Audit-Trail den definierten Sicherheitsperimeter des Unternehmens. Self-hosting hält jeden Prompt, jedes abgerufene Dokument und jede generierte Antwort innerhalb der Infrastruktur, die das Unternehmen ohnehin nach bestehenden Kontrollen prüft. Ein separates Logging-System des Anbieters, das zusätzliche Zugriffsanfragen erfordert, wird überflüssig.

Tiefe der Sub-Prozessoren-Kette

Wer Daten an einen Cloud-LLM-Anbieter sendet, gewährt Vertrauen an dessen Sub-Prozessoren, und an alle Sub-Prozessoren, die diese Sub-Prozessoren später hinzufügen. Die Commercial Data Processing Agreement von Anthropic erteilt eine generelle Vorabgenehmigung für neue Sub-Prozessoren bei einer Ankündigungsfrist von nur 15 Tagen (Heuking, 2026). Self-hosting eliminiert diese Kette, da keine Daten die vom Unternehmen kontrollierte Infrastruktur verlassen.

Eigentum an Verschlüsselungsschlüsseln: BYOK vs. HYOK

Die Unterscheidung zwischen BYOK und HYOK ist der Punkt, an dem die meisten Beschaffungsgespräche zu früh enden. Bei BYOK, Bring Your Own Key, wird der Schlüssel des Kunden weiterhin im Key-Management-System des Anbieters selbst gespeichert, sodass der Anbieter den technischen Zugriff behält. Bei HYOK, Hold Your Own Key, verbleiben die Schlüssel ausschliesslich in der vom Kunden kontrollierten Infrastruktur (IBM, 2026).

Merkmal	BYOK	HYOK
Speicherort des Schlüssels	Im Key-Management-System des Anbieters	In der vom Kunden kontrollierten Infrastruktur
Technischer Zugriff des Anbieters	Anbieter behält technischen Zugriff auf den Schlüssel	Anbieter hat keinen technischen Zugriff auf den Schlüssel
Compliance-Implikation	Daten können technisch weiterhin vom Anbieter entschlüsselt werden	Entschlüsselung liegt vollständig ausserhalb der Reichweite des Anbieters

BYOK wird häufig mit einer Sprache vermarktet, die sich kaum von HYOK unterscheidet. Genau deshalb müssen Compliance-Prüfer die Anschlussfrage direkt stellen: Wo liegt der Schlüssel physisch, und wer kann technisch darauf zugreifen.

Warum Anbieter die Unterscheidung zwischen Orchestrierung und Inferenz gerne übergehen

Das entscheidende Detail bei einer «Self-hosted»-Behauptung ist, ob die Inferenz self-hosted läuft, nicht nur die Orchestrierung. Eine Workflow-Engine kann vollständig innerhalb der Unternehmensinfrastruktur laufen, während jeder Modellaufruf weiterhin an eine externe LLM-API geht.

Nur den Orchestrator selbst zu hosten, löst das Residenzproblem in keiner Weise, sofern die Inferenzschicht nicht separat abgesichert wird, typischerweise durch das Routing an ein self-hosted oder On-Premises-Modell statt an einen Cloud-KI-Endpunkt.

Diese Lücke zeigt sich branchenweit bei self-hosted Workflow- und KI-Agenten-Tools, nicht nur in einem Einzelfall. Anbieter thematisieren diese Unterscheidung selten von sich aus, weil «self-hosted» für sich genommen bereits vollständig klingt. In der Praxis sind Orchestrierung und Inferenz zwei getrennte architektonische Entscheidungen, jede mit eigenen Implikationen für Residenz, Logging und Sub-Prozessoren. Ein Compliance-Prüfer muss beide unabhängig voneinander bewerten, statt anzunehmen, dass die eine die andere einschliesst.

Viele Plattformen vermarkten Self-hosting ausdrücklich für Anforderungen aus GDPR, HIPAA und SOC 2. Lokale Orchestrierungsinfrastruktur allein garantiert jedoch keine lokale Inferenz; ein self-hosted Workflow kann jeden Modellaufruf weiterhin an einen externen LLM-Endpunkt leiten, sofern dies nicht separat unterbunden wird. Der Orchestrator sitzt innerhalb des Perimeters; das Reasoning häufig nicht.

VPC-isolierte LLM-Bereitstellung schliesst diese Lücke direkt, weil sie die Inferenz selbst, nicht nur Speicherung oder Orchestrierung, innerhalb einer kontrollierten Netzwerkgrenze hält. Dieses eine Merkmal erfüllt gleichzeitig die Anforderungen an Datenresidenz nach GDPR, PHI-Isolation und Rechenschaftspflicht im Finanzdienstleistungssektor.

Compliance-Teams, die eine Plattform evaluieren, sollten gezielt fragen, wo das Modell ausgeführt wird, nicht nur, wo die Workflow-Logik läuft. Genau auf diese Unterscheidung ist Lunnoa ausgerichtet: Orchestrierung und Inferenz laufen beide innerhalb der eigenen Infrastruktur des Kunden, nicht nur eines von beiden.

Warum ein SOC-2-Siegel nicht die Frage beantwortet, die ein Regulator stellen wird

Ein SOC-2-Bericht bescheinigt die internen Prozesskontrollen eines Anbieters; er bescheinigt nicht, wo Kundendaten oder KI-Inferenz tatsächlich liegen. SOC 2 enthält keine KI-spezifischen Kontrollen für die Verarbeitung von Trainingsdaten, Inferenz-Logging oder die Offenlegung von Modellgewichten (Linford & Co, 2026). Eine gemeinsam genutzte Cloud-Umgebung mit SOC-2-Kontrollen bleibt strukturell eine gemeinsam genutzte Umgebung.

Diese Lücke ist relevant, weil das KI-spezifische Risiko einer Datenpanne messbar anders ist als das Risiko, für das SOC 2 konzipiert wurde. Shadow AI, also KI-Tools, die ohne organisatorische Freigabe eingesetzt werden, verdeutlicht diesen Unterschied klar.

Art der Datenpanne	Durchschnittliche Kosten
Standardvorfall	4,44 Mio. USD
Mit Beteiligung von Shadow AI	4,63 Mio. USD

Quelle: IBM Cost of a Data Breach Report, 2025 (600 befragte Organisationen, März 2024 bis Februar 2025)

Source: IBM, «Cost of a Data Breach Report», 2025

Datenpannen mit Shadow AI kosten im Schnitt 4,63 Mio. USD, das sind 670'000 USD mehr als bei Standardvorfällen. Jede fünfte Organisation meldete eine Shadow-AI-bedingte Datenpanne, und nur 37 % verfügen über Richtlinien, um Shadow AI zu erkennen oder zu steuern (IBM, 2025).

Source: IBM, «Cost of a Data Breach Report», 2025

Separat berichteten 13 % der Organisationen von direkten Datenpannen bei KI-Modellen oder -Anwendungen, und in 97 % dieser Fälle fehlten angemessene Zugriffskontrollen für KI (IBM, 2025). Ein SOC-2-Siegel bei einem Cloud-KI-Anbieter sagt nichts darüber aus, ob eine Mitarbeiterin oder ein Mitarbeiter sensible Daten über ein nicht freigegebenes KI-Tool geleitet hat. Ebenso wenig sagt es etwas darüber aus, ob die KI-Zugriffskontrollen des Anbieters selbst ausreichend waren (Linford & Co, 2026).

Zwei Missverständnisse, die einer klaren Entscheidung im Weg stehen

Self-hosted KI ist cloudbasierten Frontier-Modellen nicht grundsätzlich unterlegen

Der Fähigkeitsunterschied zwischen self-hosted und cloudbasierten Frontier-Modellen hat sich so weit verringert, dass die meisten Analysen aus dem Jahr 2026 eher ein pragmatisches Hybrid-Routing beschreiben als einen absoluten Zielkonflikt. Vorhersehbare Workloads mit hohem Volumen laufen self-hosted, während Lastspitzen oder Aufgaben, die Frontier-Reasoning erfordern, bei Bedarf an Cloud-APIs geroutet werden. Wer Self-hosting als dauerhaften Verzicht auf Leistungsfähigkeit betrachtet, verkennt, wie Unternehmen es heute tatsächlich einsetzen.

Self-hosting ist bei realem Produktionsvolumen günstiger

Cloud-KI-Plattformen verrechnen typischerweise pro Token oder pro Ausführung, sodass die Rechnung mit jedem Workflow-Lauf steigt. Self-hosting entfernt diese laufende Verrechnung: Die Infrastrukturkosten bleiben unabhängig von der Nutzung fix, sodass sich der Kostenvorteil mit wachsender Nutzung verstärkt.

Für jede Organisation, die KI-Agenten produktiv betreibt und nicht nur einzelne Workflows pilotiert, ist Self-hosting über die Zeit der günstigere Weg, zusätzlich zum kontrollierteren.

Wie eine wirklich self-hosted Plattform in der Praxis aussieht

Das Muster in diesem Beitrag läuft auf eine Messlatte hinaus: Eine Plattform ist erst dann im vollen Sinn self-hosted, wenn Orchestrierung, Inferenz, Audit-Logging und Schlüsselverwaltung allesamt innerhalb der Infrastruktur laufen, die der Kunde bereits besitzt, ohne dass eine Komponente aus Bequemlichkeit beim Anbieter verbleibt.

Teilweises Self-hosting, bei dem nur die Workflow-Schicht vor Ort läuft, während Modellaufrufe und Logs den Perimeter weiterhin verlassen, erreicht diese Messlatte nicht, selbst wenn im Marketing «self-hosted» steht.

Lunnoa wurde von Anfang an nach genau dieser vollständigen Definition gebaut. Jede Komponente, einschliesslich Workflow-Engine, Dokumentenverarbeitung und LLM-Routing, läuft auf der eigenen Infrastruktur des Kunden, ob AWS, GCP, Azure oder On-Premises. Compliance-Teams, die eine Plattform evaluieren, Lunnoa eingeschlossen, sollten dieselbe Checkliste unten anwenden, statt die Selbstbeschreibung eines Anbieters ungeprüft zu übernehmen.

Eine praktische Checkliste zur Prüfung einer «Self-hosted»-Behauptung

Die Verwendung des Wortes «self-hosted» durch einen Anbieter ist keine Spezifikation, sondern eine Marketingaussage, die anhand von sechs konkreten architektonischen Fragen überprüft werden muss. Compliance- und Sicherheitsprüfer sollten vor der Freigabe schriftliche Antworten zu jedem einzelnen Punkt verlangen, nicht eine mündliche Zusicherung im Verkaufsgespräch.

Diese Liste ist nicht theoretisch. Lunnoa ist heute bei einer Private-Equity-Firma im Compliance-Bereich im Einsatz und automatisiert dort interne Compliance-Prozesse self-hosted; die folgenden Fragen spiegeln wider, was diese Implementierung tatsächlich zu klären erforderte, nicht eine Checkliste, die aus Marketingunterlagen von Anbietern zusammengestellt wurde.

1. Läuft die Inferenz innerhalb der Unternehmensinfrastruktur, oder nur die Orchestrierung? Bestätigen Sie, dass Modellaufrufe die Netzwerkgrenze niemals verlassen.
2. Wo genau liegen die Verschlüsselungsschlüssel physisch, und wer kontrolliert das dafür zuständige Key-Management-System? Bestätigen Sie HYOK, nicht BYOK: Der Anbieter sollte zu keinem Zeitpunkt technischen Zugriff auf den Schlüssel haben, auch nicht bei Schlüsselrotation oder Backup.
3. Werden Prompts und Reasoning-Traces innerhalb des unternehmenseigenen Audit-Systems protokolliert, ohne ein separates Logging-System des Anbieters?
4. Wie lautet die vollständige Liste der Sub-Prozessoren, und wie wird das Unternehmen über Änderungen informiert? Eine Ankündigungsfrist von 15 Tagen, wie im Commercial DPA von Anthropic, ist keine Vorabgenehmigung.
5. Lässt sich die Datenresidenz pro Anfrage überprüfen, nicht nur bei Vertragsabschluss? Dynamische Tool-Aufrufe und die Delegation an Sub-Agenten können die Residenz nach dem Deployment verändern.
6. Kontrolliert das Unternehmen, nicht der Anbieter, Modell-Updates und Versionswechsel? Unangekündigte Modelländerungen erschweren Audit-Trails und die Einhaltung von Konsistenzanforderungen.

Fazit

Die Regulatoren haben noch nicht abschliessend festgelegt, wie agentische KI in regulierten Branchen zu governen ist. Der ausdrückliche Ausschluss generativer und agentischer KI in SR 26-2 macht diese Lücke offiziell statt bloss theoretisch.

Self-hosting schliesst nicht jede offene regulatorische Frage. Es bringt Datenresidenz, Audit-Trails, das Ausmass der Sub-Prozessoren-Exposition und die Verwahrung der Schlüssel jedoch zurück unter die Kontrolle des Unternehmens, solange diese Fragen offen bleiben.

Die entscheidende Unterscheidung ist nicht, ob eine Plattform als «self-hosted» bezeichnet wird. Entscheidend ist, ob die Inferenz, nicht nur die Orchestrierung, tatsächlich innerhalb der vom Unternehmen kontrollierten Infrastruktur läuft.