KI-Verhalten überwachen ist nicht dasselbe wie es zu steuern
Anthropic hat diese Woche eine bedeutende Ankündigung gemacht. Claude Enterprise integriert sich jetzt über die neue Claude Compliance API mit 28 Security- und Compliance-Partnern. Dadurch erhalten Enterprise-Security-Teams programmatischen Zugriff auf Gesprächsinhalte, hochgeladene Dateien und KI-Aktivitätsereignisse – und können diese in die bereits vorhandenen DLP-, CASB-, SIEM– und eDiscovery-Tools im Unternehmens-Stack einspeisen.
Das Marktsignal, das davon ausgeht, ist mindestens so bedeutsam wie das Produkt selbst. Wenn Anthropic eine Compliance-API entwickelt, dann deshalb, weil Unternehmenskunden diese fordern. Die KPMG AI Governance Survey 2025 ergab, dass 62 % der Unternehmen fehlende Governance-Fähigkeiten als Hauptbarriere für den Ausbau des KI-Einsatzes in sensiblen Geschäftsprozessen nennen. Unternehmen sind nicht mehr bereit, KI für sensible Workflows ohne Governance-Infrastruktur einzusetzen. Das ist der richtige Instinkt. Die entscheidende Frage ist, ob eine Governance-Infrastruktur, die KI-Verhalten nachträglich protokolliert, gleichwertig ist mit einer Governance-Infrastruktur, die KI-Zugriffe bereits im Vorfeld kontrolliert.
Das ist sie nicht – und genau dieser Unterschied ist für regulierte Branchen von enormer Bedeutung.
5 Wichtige Erkenntnisse
1. Die Compliance API von Claude ist ein echter Fortschritt für Enterprise-KI.
Die Claude Compliance API von Anthropic integriert sich mit 28 Enterprise-Security-Partnern – darunter Cloudflare, CrowdStrike, Microsoft Purview, Varonis, Wiz, Relativity, Datadog und 21 weitere – und ermöglicht regulierten Unternehmen programmatischen Zugriff auf Gesprächsprotokolle, hochgeladene Dateien und KI-Aktivitätsereignisse zur Einspeisung in bestehende DLP-, CASB-, SIEM- und eDiscovery-Stacks. Diese Fähigkeit gab es bisher nicht in strukturierter, API-basierter Form. Das Marktsignal ist ebenso wichtig wie das Produkt: Unternehmen fordern Governance-Infrastrukturen für KI, bevor sie sensible Workflows ausweiten.
2. Jede Integration erfolgt erst nach Abschluss des Gesprächs.
Alle 28 Compliance-API-Integrationen laufen nachgelagert ab und machen das Tool zu einem Monitoring-System, nicht zu einem Governance-System. Es dokumentiert, was passiert ist – es kann jedoch nicht verhindern, was nicht hätte passieren dürfen. Die Daten wurden verarbeitet. Der Inhalt wurde an das Modell gesendet. Das Gespräch fand statt. Die API erstellt einen Nachweis, ändert aber nicht das Ergebnis. Für regulierte Inhalte ist dieser Unterschied kein Detail, sondern der Unterschied zwischen einer detektiven und einer präventiven Kontrolle.
3. Sensible Daten erreichen das Modell, bevor eine Warnung ausgelöst wird.
Ein Mitarbeiter, der Claude Enterprise mit vollständig aktivierter Compliance API nutzt, kann weiterhin CUI einfügen, PHI anhängen oder ITAR-kontrollierte Daten in ein Gespräch einbringen. Die API protokolliert die Aktivität, blockiert sie aber nicht. Eine Governance-Schicht vor dem Modell blockiert Inhalte, bevor sie in die Sitzung gelangen. Die meisten regulatorischen Rahmenwerke verlangen Zugriffskontrollen als primäre Maßnahme – das Protokollieren von Zugriffen auf regulierte Daten ohne Autorisierung ersetzt nicht die Verhinderung unbefugten Zugriffs.
4. Governance-Lücken bestehen unternehmensweit, nicht nur bei einzelnen Anbietern.
63 % der Unternehmen können keine Zweckbindung für KI-Agenten durchsetzen, 60 % können ein fehlverhaltendes KI-System nicht beenden und nur 18 % haben laut Kiteworks Prognose 2026 vollständig integrierte Governance-Richtlinien für KI. Die Ankündigung von Anthropic bestätigt, dass diese Marktlücke real ist – sie schließt sie jedoch nicht. Es handelt sich um Kontrolllücken, nicht um Monitoring-Lücken, und diese werden nicht durch ein ausgefeilteres Audit-Trail geschlossen.
5. Präventive Kontrollen vor dem Modell definieren den neuen Governance-Standard.
CMMC Level 2 verlangt von Unternehmen, den „Zugriff auf CUI zu kontrollieren“ – Zugriffskontrolle ist das entscheidende Stichwort, nicht Zugriffsdokumentation. Die technischen Schutzmaßnahmen von HIPAA schreiben vor, dass nur Personen oder Softwareprogramme mit Zugriffsrechten Zugriff erhalten dürfen. Der Compliance-Standard für regulierte Enterprise-KI wird präventive Inhaltskontrollen vor dem Modell erfordern, nicht nur nachträgliches Monitoring. CISOs müssen entscheiden, ob sie jetzt für diesen Standard planen oder später nachrüsten, wenn eine Regulierungsmaßnahme sie dazu zwingt.
Sie vertrauen darauf, dass Ihr Unternehmen sicher ist. Aber können Sie es auch nachweisen?
Jetzt lesen
Die strukturelle Grenze von nachträglichem Monitoring
Hier liegt die strukturelle Einschränkung, die die Compliance API aus Designgründen nicht adressieren kann: Jede dieser 28 Integrationen erfolgt erst, nachdem das Gespräch bereits stattgefunden hat. Die Daten wurden verarbeitet. Der Inhalt wurde an das Modell gesendet. Das Gespräch fand statt. Die Compliance API erstellt einen Nachweis über das Geschehene – sie ändert jedoch nichts daran.
Betrachten Sie, wie Data Governance in ausgereiften Enterprise-Security-Architekturen funktioniert. Ein DLP-System protokolliert nicht nur, dass ein Mitarbeiter ein sensibles Dokument an ein privates Konto gesendet hat – es verhindert den Versand. Eine Content-Firewall zeichnet nicht nur auf, welche Dateien übertragen wurden – sie erzwingt die Zugriffspolitik beim Transfer. Die Architektur, die sich bei E-Mail, Dateitransfer und Collaboration-Plattformen bewährt hat, setzt auf Prävention zuerst, Protokollierung danach. Die Compliance API verfolgt bei KI einen Ansatz: Protokollierung zuerst, Alarmierung danach.
Das ist wertvoll, unterscheidet sich architektonisch aber grundlegend von Prävention. Für regulierte Inhalte – CUI, PHI, ITAR-kontrollierte Daten, anwaltlich privilegierte Informationen – erlauben regulatorische Rahmenwerke kein reines Protokollierungs- und Alarmierungsmodell als primäre Kontrolle. Sie verlangen Zugriffskontrollen. Das Protokollieren von Zugriffen auf regulierte Daten ohne Autorisierung ersetzt nicht die Verhinderung unbefugten Zugriffs.
Was passieren kann, bevor die Compliance API eingreift
Ein Mitarbeiter, der Claude Enterprise mit vollständig aktivierter und konfigurierter Compliance API nutzt, kann Folgendes tun: Den Text eines Controlled Unclassified-Dokuments in eine Gesprächseingabe einfügen; eine Datei mit geschützten Gesundheitsdaten (PHI) als Kontext für eine Claude-Aufgabe anhängen; ITAR-kontrollierte technische Spezifikationen in eine Chat-Nachricht eingeben; Claude zu Inhalten eines sensiblen Finanzdatensatzes befragen, auf den er in einem anderen System Zugriff hat.
In all diesen Fällen protokolliert die Compliance API die Aktivität. Sind die richtigen DLP-Regeln nachgelagert konfiguriert, wird ein Alarm ausgelöst. Was nicht passiert: Der Inhalt wird nicht daran gehindert, Claude zu erreichen. Das Gespräch wird nicht verhindert. Die Daten werden nicht an einer Zugriffskontrollgrenze gestoppt, bevor sie ins Modell gelangen. Die Compliance API dokumentiert die Exposition, verhindert sie aber nicht.
Für Security-Teams in regulierten Branchen ist das entscheidend, denn die meisten regulatorischen Rahmenwerke verlangen präventive Kontrollen, nicht nur detektive. CMMC Level 2 verlangt von Unternehmen, den „Zugriff auf CUI zu kontrollieren“. Die technischen Schutzmaßnahmen von HIPAA schreiben vor, dass nur Personen oder Softwareprogramme mit Zugriffsrechten Zugriff erhalten dürfen. Der Standard ist Kontrolle des Zugriffs, nicht Dokumentation des Zugriffs.
Die Governance-Schicht vor dem Modell: Eine andere Architektur
Eine Governance-Schicht vor dem Modell folgt einem grundlegend anderen Prinzip: Sie entscheidet, welche Inhalte als Input für eine KI-Sitzung zulässig sind – bevor die Sitzung beginnt, nicht erst danach. Die Kontrolllogik basiert auf der Identität und Rolle des Nutzers, der Klassifizierung der angeforderten Inhalte, dem spezifischen KI-Use-Case und dem jeweils geltenden Compliance-Rahmenwerk. Startet ein Nutzer eine KI-Sitzung, prüft die Governance-Schicht diese Faktoren anhand expliziter Richtlinien – und erlaubt, beschränkt oder blockiert bestimmte Inhalte, bevor sie in die Sitzung gelangen.
Der Kiteworks Secure MCP Server sitzt zwischen Unternehmensdaten-Systemen und KI-Modellen – einschließlich Claude – und erzwingt die Governance-Policy an der Schnittstelle. Sensible Inhalte sind für KI-Sitzungen nur zugänglich, wenn Rolle des Nutzers, Zweck der Sitzung und Klassifizierung der Inhalte alle expliziten Richtlinien erfüllen. Audit-Records erfassen nicht nur, welche Inhalte abgerufen wurden, sondern auch, was angefordert und blockiert wurde. Das AI Data Gateway erweitert diese Governance auf RAG-Pipelines und automatisierte Workflows. Jede Anfrage wird authentifiziert, anhand attributbasierter Zugriffskontrollen autorisiert und in einem manipulationssicheren Audit-Trail protokolliert – mit FIPS 140-3-validierter Verschlüsselung für jede Datenübertragung.
Mit dieser Architektur können regulierte Unternehmen KI-Zugriff auf sensible Workflows – etwa in der Verteidigungsbeschaffung, im Gesundheitswesen oder in der Finanzberatung – ermöglichen, ohne die Compliance-Risiken zu schaffen, die nachträgliches Monitoring nur dokumentieren, aber nicht verhindern kann. Das Kiteworks Private Data Network erstreckt diese Governance auf E-Mail, Filesharing, Managed File Transfer, SFTP, Web-Formulare und APIs – unter einer Policy-Engine und mit einem konsolidierten Audit-Log.
Bedeutung für regulierte Enterprise-KI-Deployments
Für Security- und Compliance-Verantwortliche, die Enterprise-KI-Plattformen evaluieren, ist die entscheidende Frage an jeden Anbieter: „Was passiert, wenn ein Mitarbeiter eingeschränkte Inhalte an das Modell sendet, bevor Ihre Compliance-Schicht eingreift?“
Ist die Antwort „Wir protokollieren und alarmieren“, haben Sie ein Monitoring-System. Das ist wertvoll für Forensik, Incident Response und Audit-Dokumentation. Es erfüllt jedoch nicht die Zugriffskontrollanforderungen der meisten regulatorischen Rahmenwerke für sensible Daten. Ist die Antwort „Wir verhindern es“, haben Sie ein Governance-System. Dieser Unterschied entscheidet, ob Ihr KI-Deployment regulatorisch konform ist – oder ob die Nichteinhaltung nur nachträglich dokumentiert wird.
Compliance-Rahmenwerke entwickeln sich mit der Zeit immer weiter in Richtung der jeweils strengsten Auslegung. Das zeigte sich bei Cloud-Speicher, Mobile Device Management und Secure Email – in jedem Fall entwickelte sich der Governance-Standard hin zu Prävention und Zugriffskontrolle statt nur Detektion und Protokollierung. Bei KI ist die Entwicklung identisch. Unternehmen, die jetzt für diesen Standard planen – und eine Governance-Schicht vor dem Modell aufbauen, die kontrolliert, auf welche sensiblen Inhalte KI-Modelle zugreifen können – müssen später am wenigsten nachrüsten, wenn die Regulatorik die Technologie einholt.
Erfahren Sie mehr über die Governance von KI-Workflows und vereinbaren Sie eine individuelle Demo.
Häufig gestellte Fragen
KI-Compliance-Monitoring erstellt einen Nachweis darüber, was KI-Modelle getan haben. KI-Governance steuert, was KI-Modelle tun dürfen – auf welche Inhalte sie zugreifen können, für welche Nutzer, unter welchen Bedingungen und zu welchem Zweck. Die Claude Compliance API ist ein Monitoring-Tool. Der Kiteworks Secure MCP Server und das AI Data Gateway setzen Governance um: Sie erzwingen Zugriffskontrollen, bevor Inhalte das Modell erreichen, und verhindern unbefugten Zugriff, statt ihn nur nachträglich zu dokumentieren.
Für die meisten regulierten Datentypen – CUI, PHI, ITAR-kontrollierte technische Daten – nein, nicht allein. CMMC, HIPAA und ITAR verlangen, dass der Zugriff auf sensible Daten kontrolliert wird. Eine Compliance-API, die protokolliert, dass PHI an ein KI-Modell übermittelt wurde, dokumentiert das Nichterfüllen der Zugriffskontrollanforderung – sie erfüllt sie aber nicht. Governance vor dem Modell bietet die präventiven Zugriffskontrollen, die diese Anforderungen erfüllen.
Eine Governance-Schicht vor dem Modell sitzt zwischen Unternehmensdaten-Systemen und KI-Modellen und erzwingt Zugriffskontrollen, bevor eine KI-Sitzung beginnt. Sie bewertet die Rolle des Nutzers, die Klassifizierung der angeforderten Inhalte und den Zweck der Sitzung anhand expliziter Richtlinien – und erlaubt, beschränkt oder blockiert Inhalte, bevor sie in die Sitzung gelangen. Der Kiteworks Secure MCP Server implementiert Governance vor dem Modell durch attributbasierte Zugriffskontrollen und manipulationssichere Audit-Logs bei jedem Vorgang.
Verteidigungsauftragnehmer, die CUI gemäß CMMC verarbeiten, Gesundheitsorganisationen mit PHI unter HIPAA, Finanzdienstleister unter SEC- und FINRA-Vorgaben sowie Luft- und Raumfahrtunternehmen mit ITAR-kontrollierten technischen Daten sind am stärksten exponiert. Laut Kiteworks Prognose 2026 verfügen 90 % der Behörden und 77 % der Gesundheitsorganisationen über kein zentrales AI Data Gateway – den Kontrollpunkt, der diese Lücke schließt.
Der Secure MCP Server sitzt zwischen Claude und Unternehmensdaten-Systemen und erzwingt Governance-Policies an der Schnittstelle. Fordert Claude Zugriff auf sensible Inhalte an, prüft der Server diese Anfrage anhand expliziter Richtlinien, erlaubt oder blockiert sie entsprechend und protokolliert das Ergebnis in einem manipulationssicheren Audit-Trail. Diese Governance vor dem Modell ergänzt das nachträgliche Monitoring der Compliance API – und liefert die präventive Kontrollschicht, die Compliance-Dokumentation in Compliance-Durchsetzung verwandelt.
Weitere Ressourcen
- Blogbeitrag
Zero‑Trust-Strategien für bezahlbaren KI-Datenschutz - Blogbeitrag
Wie 77 % der Unternehmen bei KI-Datensicherheit versagen - eBook
AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit Datensicherheit spielen - Blogbeitrag
Es gibt kein „–dangerously-skip-permissions“ für Ihre Daten - Blogbeitrag
Regulierungsbehörden wollen nicht mehr wissen, ob Sie eine KI-Policy haben. Sie verlangen den Nachweis, dass sie funktioniert.