Niemand übernimmt die Verantwortung, wenn ein KI-Agent versagt
Acht von zehn Führungskräften in Europa und dem Nahen Osten berichten, dass im vergangenen Jahr ein KI-Vorfall bis in den Vorstand oder die Geschäftsleitung eskaliert ist. Fragt man dieselben Führungskräfte, wer beim nächsten Vorfall durch einen KI-Agenten die Verantwortung übernimmt, erhält keine einzelne Rolle mehr als 17 Prozent der Stimmen.
Diese Aufteilung stammt aus einer IBM-Studie vom 14. Oktober 2026, für die Censuswide 3.221 Führungskräfte in Unternehmen mit mindestens 1.000 Mitarbeitenden in Großbritannien, Frankreich, Deutschland, Italien, Spanien, den Niederlanden, Saudi-Arabien und den VAE befragte. Die Feldarbeit fand vom 14. bis 24. September 2026 statt. Die 80-Prozent-Zahl war die Schlagzeile. Für CISOs oder Chief Compliance Officer ist jedoch die tiefere Erkenntnis wichtiger: Wer trägt die Verantwortung, wenn KI-Agenten Fehler machen?
Man kann es den „verwaisten Vorfall“ nennen. Der Vorstand hat das KI-Risiko offiziell zugewiesen, die Agenten greifen weiterhin auf sensible Daten zu, und wenn etwas schiefgeht, verteilt sich die Verantwortlichkeit auf acht verschiedene Antworten. Das ist ein Governance-Problem – und ein Evidenzproblem. Denn eine Aufsichtsbehörde, die fragt, wer einem Agenten Zugriff auf Daten erlaubt hat, erwartet einen Namen und ein Prüfprotokoll, nicht ein Gremium. Kiteworks Secure Data Exchange adressiert genau diesen zweiten Teil der Frage. Dieser Beitrag erklärt, wie beide Aspekte zusammenhängen.
Wichtige Erkenntnisse
1. Die Anzahl der Vorfälle ist nicht mehr die Nachricht.
80 Prozent der befragten Führungskräfte berichten, dass ein KI-Vorfall im vergangenen Jahr bis in den Vorstand oder die Geschäftsleitung gelangte. Die entscheidende Frage ist nun, was die Unternehmensleitung über ihre Reaktion nachweisen kann.
2. Verantwortlichkeit ist dort fragmentiert, wo es zählt.
Die Zuweisung der KI-Verantwortung auf Vorstandsebene ist nahezu universell, aber keine einzelne Rolle wird bei negativen KI-Agenten-Ergebnissen von mehr als 17 Prozent genannt.
3. Informelle Eskalation ist ein Audit-Risiko.
Mehr als ein Drittel der Vorfälle, die Führungskräfte erreichten, geschahen informell – damit fehlt dem Chief Compliance Officer eine nachvollziehbare Dokumentation der Entscheidungen.
4. Verträge sind keine Kontrollen.
Die meisten Unternehmen steuern KI von Drittanbietern mit Vertragsklauseln und Audit-Rechten, während nur eine kleine Minderheit Drittanbieter-KI kontinuierlich überwacht oder unabhängige Prüfungen verlangt.
5. Die Datenpflichten bleiben bestehen.
Der Zeitplan des EU AI Act hat sich verschoben, aber die DSGVO-Sicherheits- und Meldepflichten sowie die NIS 2-Berichtspflichten gelten weiterhin für den Agentenzugriff.
Acht von zehn Vorständen haben bereits einen KI-Vorfall erlebt
Beginnen wir mit der Zahl, die niemand wegdiskutieren kann. Laut dem IBM-Report „The New Realities of AI Governance“ berichten 80 Prozent der befragten Führungskräfte, dass im vergangenen Jahr ein KI-bezogener Vorfall bis in den Vorstand oder die Geschäftsleitung gelangte. Das ist kein hypothetisches Risiko mehr, sondern ein wiederkehrender Tagesordnungspunkt.
Was danach geschah, ist aufschlussreicher als die reine Anzahl der Vorfälle. In Unternehmen, bei denen ein Vorfall die Führungsebene erreichte, geben 43 Prozent an, dass dieser formell geprüft wurde, während 37 Prozent von einer informellen Kommunikation sprechen. Noch einmal: In mehr als einem Drittel der Fälle gelangte ein KI-Vorfall per Flurgespräch und nicht über einen Governance-Prozess an die Unternehmensspitze.
Eine informelle Eskalation hinterlässt keine nachvollziehbare Dokumentation. Wenn eine Aufsichtsbehörde fragt, wie die Führung von dem Vorfall erfuhr, was entschieden wurde und wann, ist „wir haben darüber gesprochen“ keine Antwort, die ein Chief Compliance Officer vorlegen kann. Die formelle Prüfung ist die Kontrolle. Die informelle Erwähnung ist das Risiko.
Die im Bericht genannten Konsequenzen sind ebenso konkret: 40 Prozent der Unternehmen, bei denen ein Vorfall die Führungsebene erreichte, nennen eine Änderung der KI-Governance-Policy als Hauptergebnis, 38 Prozent eine Anpassung der Investitions- oder Rollout-Pläne, 37 Prozent die Einbindung externer Berater und 35 Prozent eine Benachrichtigung der Aufsichtsbehörden. Diese Werte sind als Richtwerte zu verstehen – sie stammen aus einer von einem Anbieter beauftragten Umfrage unter Führungskräften in acht Märkten, nicht weltweit.
Trotzdem verdient die Zahl zur Benachrichtigung der Aufsichtsbehörden besondere Aufmerksamkeit, denn sie ist die einzige, die eine Behörde aus eigenen Akten verifizieren könnte. Mehr als ein Drittel der Unternehmen, die einen Vorfall eskalierten, sprachen anschließend auch mit einer Aufsichtsbehörde. Für Verantwortliche für Audit-Readiness rückt damit die Evidenzfrage von „irgendwann“ auf „dieses Quartal“.
Sie Vertrauen auf die Sicherheit Ihres Unternehmens. Aber Können Sie es Nachweisen?
Jetzt lesen
Vorstandsverantwortung existiert, aber Agentenverantwortung nicht
Auf dem Papier sieht alles ordentlich aus. Die IBM-Umfrage ergab, dass 98 Prozent der Befragten die Verantwortung für KI-Risiken formell auf Vorstandsebene zugewiesen haben, und 26 Prozent verfügen über einen eigenen KI-Ausschuss auf Vorstandsebene. Governance-Strukturen sind nahezu überall vorhanden.
Doch die entscheidende Frage ist: Wer trägt die Verantwortung, wenn ein KI-Agent ein unerwünschtes Ergebnis produziert? CIO oder CTO waren mit 17 Prozent die häufigsten Einzelantworten, keine Rolle wurde von mehr als 17 Prozent genannt. Geteilte C-Suite-Verantwortung lag bei 14,5 Prozent, Chief Risk oder Chief Compliance Officer bei 14 Prozent, Chief AI Officer bei 13 Prozent, das implementierende Team bei 11 Prozent, der KI-Anbieter bei 10 Prozent, ein Geschäftsbereichsleiter bei 10 Prozent und der CEO bei 9 Prozent.
Das ist kein Streit über Organigramme, sondern das Fehlen eines solchen. Ein Vorstandsausschuss kann eine Risikokategorie besitzen, aber ein Vorfall braucht eine Person, die erklären kann, was der Agent getan hat, mit wessen Autorisierung und unter welcher Policy. Acht verschiedene Antworten, keine davon eine Mehrheit, zeigen: Die meisten Unternehmen haben diese Zuweisung noch nicht getroffen.
Diese Aufteilung verdient die übliche Vorsicht bei Umfragen. Eine IBM-Umfrage unter Führungskräften in acht Märkten im Jahr 2026 ist kein allgemeingültiger Branchenstandard für die Verantwortung bei KI-Sicherheit. Andere Umfragen in anderen Regionen sehen CIO, CTO oder CISO an der Spitze. Die Konstante ist die Fragmentierung selbst.
Hier liegt der Kern des Problems: Verantwortlichkeit, die nur auf Ausschussebene existiert, liefert keine Beweise. Evidenz entsteht auf der Datenebene, wo ein namentlich benannter Autorisierer, eine Agentenidentität, eine Policy-Entscheidung und ein Prüfprotokoll zusammenkommen. Existiert diese Kette, gibt es eine faktische Antwort auf die Verantwortungsfrage. Fehlt sie, diskutiert das Unternehmen über Schuld, während die Uhr der Aufsichtsbehörde weiterläuft.
Meistens fällt dieses Vakuum dem CISO zu, unabhängig davon, ob der Titel in den Antworten auftaucht. Die Sicherheitsleitung ist die Person, an die sich der Vorstand im Ernstfall wendet – und damit wird die fehlende Kette zum persönlichen wie institutionellen Problem.
Für Menschen konzipierte Governance skaliert jetzt auf Agenten
Agenten sind bereits in einem relevanten Anteil dieser Unternehmen im produktiven Einsatz. IBM berichtet, dass 35 Prozent agentische KI produktiv nutzen und 75 Prozent erwarten, dass Agenten bis 2027 ohne menschliche Freigabe jeder Aktion agieren. Gleichzeitig sagen nur 37 Prozent, dass ihre Governance für agentische Deployments ausgelegt ist, weitere 45 Prozent sehen Nachbesserungsbedarf.
Stellt man diese Zahlen gegenüber, wird das Problem deutlich: Der Rollout folgt dem Kalender, die Governance der Absicht. Laut Bericht setzen 56 Prozent die Einführung im vereinbarten Risikorahmen fort, während ihre Governance nachzieht, ein Drittel verzögert Deployments bis zur Governance-Reife. Die Mehrheit baut das Flugzeug während des Flugs.
Governance-Lag ist der passende Begriff: Es ist die Zeitspanne zwischen dem ersten Zugriff eines Agenten auf regulierte Daten und dem Tag, an dem die Steuerungsmaßnahmen revisionssicher sind. Jeder Tag in diesem Intervall erzeugt Zugriffsereignisse, die später nicht mehr nachvollzogen werden können.
Eine Klarstellung ist für die interne Dokumentation wichtig: „Ohne menschliche Freigabe jeder Aktion“ meint Delegation, nicht Unabhängigkeit. Ein Mensch autorisiert den Workflow, eine Policy legt fest, was der Agent darf, und das Protokoll dokumentiert beides. Agenten werden zu einer zweiten Identitätsklasse im Governance-Modell – sie ersetzen nicht die menschliche Verantwortlichkeitskette. Wer sie als autonome Akteure außerhalb dieser Kette behandelt, hat die Aufgabe falsch verstanden.
Hier zeigt sich auch der Preis des Wartens: Identität, Policy und Logging nachträglich auf bereits produktive Agenten aufzusetzen, heißt, eine Historie zu rekonstruieren, die nie erfasst wurde. Werden die Kontrollen von Anfang an in die Datenebene integriert, ist jede Agenteninteraktion von Beginn an gesteuert. AI Data Governance früh umzusetzen ist günstiger als forensische Nacharbeit im Nachhinein.
Geteilte Verantwortlichkeit braucht eine einzige Evidenzkette
Wenn Verantwortlichkeit geteilt ist, muss die Evidenzkette eindeutig sein. Das ist das Designprinzip, das das Vakuum schließt, ohne auf das Organigramm zu warten.
Beginnen Sie beim Autorisierer: Jeder Agenten-Workflow sollte auf eine namentlich benannte Person zurückführbar sein, die ihn delegiert hat – wie beim Zugriff eines menschlichen Anwenders auf dessen Account. Ist die Agentenidentität mit der des delegierenden Menschen verknüpft, gibt es eine faktische Antwort auf die Verantwortungsfrage – unabhängig davon, welcher Titel letztlich für das KI-Risiko verantwortlich ist.
Als Nächstes folgt die Policy: Rollenbasierte Regeln bestimmen, was ein Mensch sehen darf, aber ein Agent agiert aufgabenübergreifend – ein reines Rollenmodell ist zu grob. Attributbasierte Zugriffskontrolle bewertet das Profil des Agenten, die Sensibilität der Daten, den Kontext und die gewünschte Operation. Ein Agent mit Leserechten für einen Ordner darf diesen nicht automatisch herunterladen.
Dann folgt das Protokoll: Ein manipulationssicherer Audit-Trail, der festhält, wer den Agenten autorisiert hat, welche Daten er berührt hat, unter welcher Policy und wann, macht aus einer Untersuchung einen Bericht. Das ist in der Praxis entscheidend: Aufsichtsbehörden arbeiten mit Tagesfristen, und ein Evidenzpaket, das Wochen zur Erstellung braucht, ist ein gefundenes Fressen für Beanstandungen.
Kiteworks Compliant AI steuert Agentenzugriffe auf der Datenebene genau nach diesem Prinzip: Es prüft die Agentenidentität und verknüpft sie mit dem menschlichen Autorisierer, bewertet jede Anfrage anhand attributbasierter Policies, setzt FIPS 140-3-validierte Verschlüsselung ein und erstellt manipulationssichere Audit-Einträge. Der Kiteworks Secure MCP Server bringt dieses Modell auch für KI-Clients wie Claude und Copilot, wobei jede Anfrage die bestehenden Nutzerberechtigungen via OAuth 2.0 übernimmt und im gleichen Audit-Trail wie E-Mail, Filesharing und Managed File Transfer protokolliert wird. Ein Audit-Trail über alle Kanäle ist entscheidend – fünf Tools bedeuten fünf Audit-Lücken.
Der Vendor-Blindspot ist der Audit-Blindspot
Das Verantwortungsproblem endet nicht an der Unternehmensgrenze. Laut IBM-Umfrage sehen 54 Prozent der Führungskräfte Governance-Lücken bei KI, die von wichtigen Anbietern und Partnern genutzt wird.
Die gewählten Kontrollen sprechen für sich: Vertragsklauseln führen mit 43 Prozent, Audit-Rechte folgen mit 39 Prozent, während kontinuierliches Monitoring von Drittanbieter-KI nur bei 21 Prozent und unabhängige Prüfungen oder Zertifizierungen bei 13 Prozent liegen. Papierkontrollen dominieren, überprüfbare Kontrollen sind selten.
Eine Klausel ist ein Versprechen. Ein Protokoll ist eine Tatsache. Wenn der Agent eines Partners auf Ihre regulierten Daten zugreift, sagt der Vertrag, was passieren sollte – aber nur Ihre eigenen Aufzeichnungen zeigen, was tatsächlich geschah. Diese Asymmetrie ist der Vendor-Blindspot, der spätestens dann zum Audit-Blindspot wird, wenn ein Prüfer den Zugriffshistorie für ausgelagerte Daten verlangt.
Für europäische Unternehmen ist diese Lücke kodifiziert. Die NIS 2 Directive verpflichtet betroffene Unternehmen, die Sicherheit der Lieferkette als Teil ihrer Maßnahmen zum Cybersecurity-Risikomanagement zu steuern. Die Management-Body-Regelungen übertragen die Verantwortung für die Genehmigung und Überwachung dieser Maßnahmen auf die Unternehmensleitung. Praktisch heißt das: Third-Party Risk Management muss nachweisen, was Partner und deren Agenten mit Ihren Daten gemacht haben – nicht nur einen unterschriebenen Fragebogen vorlegen. Ein reifes Vendor Risk Management fordert Zugriffsprotokolle und Policy-Entscheidungen an und prüft deren Existenz, bevor es der Regulator tut.
Die Lücke hat auch einen Preis, der selten im Risikoregister auftaucht: Wenn der Agent eines Anbieters auf Ihre Daten zugreift und das Protokoll nur im System des Anbieters existiert, hängt Ihre Antwortfähigkeit gegenüber der Aufsicht davon ab, wie schnell der Anbieter reagiert und ob dessen Aufbewahrungsfristen zu Ihren passen. Beides kann eine Klausel nicht garantieren – schon gar nicht, wenn die 72-Stunden-Frist läuft.
Der AI Act wurde verschoben, aber die Datenpflichten bleiben
Manche Führungskräfte lesen die Neuigkeiten zur Verschiebung des EU AI Act als Erleichterung. Der AI Omnibus (zusammengefasst vom Future of Privacy Forum) verschob das Anwendungsdatum der Annex-III-Hochrisikoanforderungen vom 2. August 2026 auf den 2. Dezember 2027 und für Annex-I-Systeme vom 2. August 2027 auf den 2. August 2028. Das Parlament verabschiedete den Text am 16. Juni 2026, der Rat am 29. Juni 2026, die Veröffentlichung erfolgte am 24. Juli 2026 im Amtsblatt.
Das ist eine Terminverschiebung für eine Regulierung, kein Governance-Stopp. IBM fand heraus, dass 41 Prozent der EU-Führungskräfte in der Stichprobe ihre Governance-Investitionen vorziehen – viele nutzen die gewonnene Zeit zum Aufbau, nicht zum Abwarten.
Der Grund ist einfach: Regulierer regulieren Daten, nicht Modelle. Die DSGVO gilt für personenbezogene Daten, egal ob ein Mensch oder ein Software-Agent sie verarbeitet. Die Pflicht zur sicheren Verarbeitung nach Artikel 32 und die 72-Stunden-Meldepflicht nach Artikel 33 hängen nicht vom Zeitplan des AI Act ab. NIS 2 bringt eigene Meldefristen: eine Frühwarnung binnen 24 Stunden und eine ausführlichere Meldung binnen 72 Stunden nach einem erheblichen Vorfall. Keine dieser Pflichten enthält eine Ausnahme für Agenten.
Für Chief Compliance Officer oder Datenschutzbeauftragte bleibt die praktische Frage gleich: Wenn ein Agent nachts um zwei auf personenbezogene Daten zugreift und etwas schiefläuft, kann das Unternehmen nachweisen, wer den Zugriff autorisiert hat, was der Agent gesehen hat und welche Policy dies erlaubte – und das innerhalb der Frist der Aufsicht? Ein DPO, der diese Frage nicht beantworten kann, ist heute bereits bei der DSGVO exponiert – unabhängig davon, was der AI Act für 2027 vorsieht.
Was CISO und CCO vor der nächsten Vorstandssitzung tun können
Hören Sie auf zu fragen, welcher Führungskraft KI gehören sollte. Fragen Sie stattdessen, ob jeder Agenten-Workflow einen Verantwortlichen, eine Policy und ein Protokoll hat. Das sind drei Punkte, die Sie noch diesen Monat überprüfen können – unabhängig davon, wie die Führungsfrage ausgeht.
Erstens: Ordnen Sie jedem Agenten-Workflow mit Zugriff auf regulierte Daten einen namentlich benannten Autorisierer zu und dokumentieren Sie dies so, dass Identitätssystem und Audit-Trail es sehen. Ein Vorstandsausschuss für „KI-Risiko“ ersetzt nicht eine Person, die „diesen Agentenzugriff“ verantwortet. Die Aufteilung der IBM-Befragten auf acht Rollen zeigt: Meistens fehlt genau dieser Punkt.
Zweitens: Führen Sie einen Evidenz-Drill durch. Wählen Sie einen Agenten-Workflow und lassen Sie das Team innerhalb weniger Stunden den vollständigen Zugriffsverlauf für eine Stichprobe vorlegen – inklusive Autorisierung, berührter Daten und zugrundeliegender Policy. Dauert die Antwort Wochen, haben Sie Ihre Evidenzlücke gemessen – und eine Zahl für den Vorstand, die dieser versteht.
Drittens: Formalisieren Sie die Eskalation von Vorfällen. Die 37 Prozent der Vorfälle, die informell an die Führung gelangten, sollten künftig über einen dokumentierten Review laufen, der Entscheidungen und Zeitpunkte festhält. Eine schriftliche Dokumentation der Reaktion ist selbst ein Beweis – und kostet wenig.
Viertens: Verankern Sie bei Anbieter-KI beobachtbare Kontrollen statt nur Vertragsklauseln. Fordern Sie von Partnern Protokolle und Policy-Entscheidungen für alle Agenten, die Ihre Daten berühren, und schreiben Sie das Recht auf deren Erhalt in die Vereinbarung. Kontinuierliches Monitoring bei 21 Prozent ist der Wert, den es zu übertreffen gilt.
Fünftens: Erzwingen Sie Datenminimierung auf Operationsebene. Ein Agent, der nur die für seine Aufgabe nötigen Daten erhält, verursacht im Fall eines Vorfalls ein kleineres Problem und eine einfachere Story für die Aufsicht.
Die eigene Formulierung von IBM ist es wert, sichtbar zu bleiben. In der Pressemitteilung sagt Ana Paula Assis, IBM-Chair für EMEA und APAC, dass Governance „nicht länger als Compliance-Übung behandelt werden kann“. Die Konsequenz für Audit-Verantwortliche ist klar: Governance, die keine Evidenz auf Abruf liefern kann, bleibt eine Compliance-Übung – egal, wie sie genannt wird.
Mehr darüber, wie Sie evidenzsichere Protokolle zu KI-Agentenzugriffen auf regulierte Daten erstellen, erfahren Sie, wenn Sie heute eine individuelle Demo vereinbaren.
Häufig gestellte Fragen
Die IBM-Umfrage zeigt keinen Konsens – keine Rolle wird von mehr als 17 Prozent der Befragten genannt. Die Antwort muss daher aus dem Design kommen, nicht aus dem Organigramm. Machen Sie Verantwortlichkeit workflow-basiert, indem Sie jedem Agenten einen namentlich benannten menschlichen Autorisierer zuweisen und die Delegation dokumentieren. So erhält der Regulator eine faktische Antwort, auch wenn Führungskräfte noch über Titel diskutieren. Kombinieren Sie die Zuweisung mit einem Audit-Trail, der die Aktionen des Agenten auf diese Person zurückführt, und mit klarer Data Governance-Verantwortung für die berührten Daten.
Sie verschiebt den Zeitplan für eine Regulierung, nicht für die bestehenden Datenpflichten. Der Omnibus verschob das Annex-III-Hochrisikodatum auf den 2. Dezember 2027, aber DSGVO-Sicherheits- und Meldepflichten sowie NIS 2-Berichtspflichten sind davon unabhängig. Die meisten Compliance-Teams sollten die gewonnene Zeit als Aufbauphase und nicht als Pause nutzen. Ein praktischer Einstieg ist ein Gap-Review gegenüber den DSGVO-Compliance– und NIS 2-Compliance-Anforderungen für Agentenzugriffe auf regulierte Daten.
Rechnen Sie mit Fragen dazu, wer den Zugriff autorisiert hat, welche Daten der Agent berührt hat, welche Policy dies erlaubte und wann – beantwortet mit Protokollen, nicht Erinnerungen. Die gleichen Fragen gelten für menschliche Anwender, weshalb ein Regulator ein Systemprompt eines Modells nicht als Zugriffskontrolle akzeptiert. Protokolle müssen manipulationssicher und in einem für Prüfer lesbaren Format exportierbar sein. Eine Chain of Custody, die Agenten- wie menschliche Aktionen abdeckt, schließt die Lücke. Im Data Policy Engine werden diese Policy-Entscheidungen dokumentiert.
Erkennen Sie zunächst an, dass Vertragsklauseln und Audit-Rechte – die häufigsten Kontrollen in der IBM-Stichprobe – Absicht und nicht Verhalten beschreiben. Verlangen Sie von Partnern Zugriffsprotokolle und Policy-Entscheidungen für Agenten, die Ihre Daten berühren, und prüfen Sie deren Existenz, bevor Sie sie benötigen. Integrieren Sie das Thema in Ihr bestehendes Third-Party Risk Management, damit KI-Nutzung ein dauerhafter Prüfpunkt wird und kein Einzelfall. Unabhängige Prüfungen, von nur 13 Prozent genutzt, sind die stärkste und am wenigsten verbreitete Kontrolle.
In die Datenebene integrierte Governance beseitigt meist einen Engpass, statt einen zu schaffen – Projekte müssen nicht mehr auf manuelle Compliance-Prüfungen jedes Outputs warten. Die Verlangsamung entsteht, wenn Kontrollen erst nachträglich auf produktive Agenten aufgesetzt werden und Teams rekonstruieren müssen, was passiert ist. Die IBM-Feststellung, dass 56 Prozent weiter deployen, während die Governance nachzieht, zeigt, wie verbreitet der Retrofit-Ansatz ist. Der Aufbau auf Kiteworks Compliant AI bedeutet, dass jede Agentenanfrage von Beginn an bewertet, verschlüsselt und protokolliert wird – im Einklang mit Zero Trust Generative AI-Prinzipien.
Weitere Ressourcen
- Blog-Beitrag
Zero‑Trust-Strategien für erschwinglichen KI-Datenschutz - Blog-Beitrag
Wie 77 % der Unternehmen bei KI-Datensicherheit versagen - eBook
AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit Datensicherheit spielen - Blog-Beitrag
Es gibt kein „–dangerously-skip-permissions“ für Ihre Daten - Blog-Beitrag
Aufsichtsbehörden fragen nicht mehr, ob Sie eine KI-Policy haben. Sie wollen den Nachweis, dass sie funktioniert.