Italiens KI-Gesetzesdekret macht KI-Governance zum Audit-Nachweis

Jedes Unternehmen, das in Italien ein Hochrisiko-KI-System betreibt, sollte nun davon ausgehen, dass ein Prüfer unangekündigt kontrollieren kann, wie dieses System getestet wird. Das Gesetzesdekret Nr. 179/2026 gibt der nationalen Cybersicherheitsbehörde Italiens genau diese Befugnis – und die anschließenden Fragen betreffen die Daten, nicht die Modellarchitektur.

Das Dekret wurde am 8. Oktober 2026 im Amtsblatt veröffentlicht und trat am 23. Oktober 2026 in Kraft. Es ist der zweite Schritt in Italiens zweistufiger Umsetzung des EU AI Act, nach Gesetz Nr. 132 vom 23. September 2025. IAPP-Reporterin Alessandra Tramonte fasste das neue Rahmenwerk zusammen, einschließlich der Benennung von AgID als Notifizierungsstelle und ACN als Hauptaufsichtsbehörde sowie als zentrale Anlaufstelle für EU-Institutionen.

Für CISOs oder Chief Compliance Officers ist die praktische Bedeutung klar: Die Verpflichtungen zur KI-Governance, die bislang in Richtliniendokumenten standen, haben nun benannte Durchsetzer mit Ermittlungsbefugnissen. Diese werden fragen, auf welche Daten ein KI-System zugegriffen hat, wer dies autorisiert hat und ob Sie dies nachweisen können. Das ist ein AI Data Governance-Problem, bevor es ein Modellproblem ist – und der Grund, warum dieses Dekret für alle relevant ist, die sensible Inhalte mit KI-Systemen austauschen.

Wichtige Erkenntnisse

1. Italien hat jetzt benannte Durchsetzer für den AI Act.

AgID fungiert als Notifizierungsstelle für Konformitätsbewertungsstellen, ACN ist Hauptaufsichtsbehörde und zentrale Anlaufstelle für EU-Institutionen.

2. Inspektionen können ohne Vorankündigung erfolgen.

ACN kann Hochrisiko-KI-Systeme sowohl aus der Ferne als auch vor Ort überprüfen – eine vorherige Ankündigung ist nicht erforderlich.

3. Das Dekret legt Behörden und Verfahren fest.

Es schafft keine neuen Verpflichtungen aus dem AI Act – die inhaltlichen Pflichten ergeben sich weiterhin aus dem AI Act selbst und dem italienischen Gesetz 132.

4. Mehrere Details sind noch offen.

Umsetzungsakte ohne Fristen, eine noch nicht eingerichtete Sandbox-Gruppe und der Zeitplan des EU Digital Omnibus bedeuten, dass sich das Gesamtbild weiterentwickeln wird.

5. Die Qualität der Nachweise entscheidet über das Prüfungsergebnis.

Regulierungsbehörden regulieren Daten, nicht Modelle. Unternehmen, die nachweisen können, wer auf welche Daten zugegriffen hat, unter wessen Autorität und mit welchem Protokoll, kommen schneller durch Inspektionen.

Was das Gesetzesdekret Nr. 179/2026 regelt

Italien hat sich für eine zweistufige Umsetzung des EU AI Act entschieden. Schritt eins war das Gesetz Nr. 132 vom 23. September 2025, veröffentlicht im Amtsblatt Nr. 223 am 25. September 2025 und in Kraft seit dem 10. Oktober 2025. Dieses Gesetz legte nationale Grundsätze fest und übertrug der Regierung die Umsetzung per Dekret. Schritt zwei ist das Gesetzesdekret Nr. 179 vom 7. Oktober 2026, das auf Grundlage von Artikel 24 des Gesetzes 132 erlassen wurde.

Das Dekret umfasst 54 Artikel. Laut konsolidiertem Text auf Normattiva erschien es in der Allgemeinen Reihe des Amtsblatts als Nummer 234 am 8. Oktober 2026 und trat fünfzehn Tage später, am 23. Oktober 2026, in Kraft. Ein separates Dekret zur polizeilichen Nutzung von KI, Gesetzesdekret Nr. 160/2026, trat bereits am 30. September 2026 in Kraft – Italiens KI-Rahmenwerk entsteht also in mehreren Teilen, nicht in einem einzigen Gesetz.

Es ist wichtig, präzise zu sein, was dieses Dekret ist: Es ist ein institutionelles und prozedurales Instrument. Es regelt, wer überwacht, wer notifiziert, wer inspiziert, wer sanktioniert und wie Beschwerden bearbeitet werden. Die Pflichten, die der AI Act Anbietern und Anwendern auferlegt, werden nicht neu geschrieben. Ein Compliance-Team, das das Dekret als neues Regelwerk für KI-Systeme liest, irrt sich. Wer es als den Moment versteht, in dem nationale Durchsetzung Realität wird, liegt richtig.

Diese Unterscheidung ist für die Planung entscheidend. Ihre Verpflichtungen zu Hochrisiko-Systemen, Transparenz und menschlicher Aufsicht ergeben sich weiterhin aus dem AI Act. Was sich am 23. Oktober geändert hat: Die italienischen Behörden haben jetzt klar definierte Rollen und Befugnisse, um zu prüfen, ob Sie diese Pflichten erfüllen.

Wer die Befugnis hat: AgID und ACN

Das Dekret teilt die Aufsicht auf zwei zentrale Behörden auf – wer welche Fragen stellt, ergibt sich aus dieser Aufteilung.

Die Agentur für Digitales Italien (AgID) ist die Notifizierungsstelle. Nach Artikel 4 ist sie für die Benennung von Konformitätsbewertungsstellen zuständig – also der Organisationen, die Hochrisiko-KI-Systeme am AI Act messen. Artikel 13 gibt AgID eine Überwachungsfunktion über diese Stellen. AgID kann eine Benennung einschränken, aussetzen oder entziehen – eine Konformitätsbewertungsstelle, die Abstriche macht, verliert ihren Status. Für Anbieter bedeutet das: Die Qualität der Prüfungen steigt, denn ein Zertifikat einer später aberkannten Stelle ist ein schwächerer Nachweis.

Die Nationale Cybersicherheitsagentur (ACN) ist laut Artikel 5 die Marktaufsichtsbehörde und laut Artikel 6 zentrale Anlaufstelle für EU-Institutionen. Das ist eine erhebliche Machtfülle für eine Cybersicherheitsbehörde. Wie die Analyse von NicFab zeigt, rückt die KI-Aufsicht damit nah an Italiens Cyber-Resilienz-Apparat, der bereits mit Betreibern kritischer Infrastrukturen nach der NIS-2-Richtlinie arbeitet.

Fachspezifische Aufsichtsbehörden bleiben beteiligt. Artikel 17 bezieht die Bank von Italien, CONSOB und IVASS für Finanzinstitute ein – Banken oder Versicherer behalten also ihre bisherigen Aufsichtsbehörden. Die Datenschutzbehörde Garante ist auf den Anwendungsbereich von Artikel 74(8) des AI Act nach Artikel 5(1)(c) des Dekrets beschränkt – sie bleibt also in ihrem klar definierten Bereich und wird nicht zur allgemeinen KI-Aufsicht.

Für multinationale Unternehmen heißt das: Ein italienischer Ansprechpartner für die meisten AI Act-Fragen, mit branchenspezifischen Aufsichtsbehörden für regulierte Sektoren. Wer bereits DSGVO-Programme umsetzt, erkennt das Muster einer Leitbehörde plus Fachaufsicht – und sollte die jeweiligen Beziehungen vor einer Inspektion klären, nicht erst währenddessen.

Inspektionen ohne Vorankündigung – und was geprüft wird

Die wohl folgenreichste Regelung für Betreiber ist Artikel 15. Er gibt ACN die Befugnis, Inspektionen aus der Ferne oder vor Ort durchzuführen – auch ohne Vorankündigung – und erstreckt diese auf die Überprüfung von Realtests von Hochrisiko-KI-Systemen. Das Dekret baut auf Artikel 24(2)(m) des Gesetzes 132 auf, der diese Prüfungsbefugnis bereits vorsah. Artikel 15(3) überlässt die Details einem Dekret des Ministerratspräsidiums auf Vorschlag der ACN – die konkreten Abläufe stehen also noch aus.

Was bedeutet eine unangekündigte Inspektion von Realtests in der Praxis? Realtests betreffen Live-Daten, oft personenbezogene Daten, die durch ein System fließen, das noch nicht am Markt ist. Ein Prüfer will den Testplan, die verwendeten Daten, die angewandten Schutzmaßnahmen und die Nachweise, dass diese Maßnahmen funktioniert haben, sehen. Es gibt keine Vorbereitungswoche, um diese Nachweise zusammenzustellen. Die Aufzeichnungen sind entweder vorhanden und abrufbar – oder nicht.

Weitere Artikel regeln, wie Verfahren eingeleitet werden. Artikel 16 legt die Auslöser fest, Artikel 18 schafft einen Beschwerdeweg – betroffene Personen können also eine Prüfung anstoßen, ohne auf ein Tätigwerden der ACN warten zu müssen. Artikel 14 führt eine Registrierungspflicht bei ACN für Hochrisiko-Systeme in kritischer Infrastruktur ein (Anhang III Punkt 2 des AI Act). Betreiber kritischer Infrastrukturen müssen also sowohl ein nationales Register führen als auch mit Inspektionen ihrer Testsysteme rechnen.

Das Muster ist durchgängig: Das Dekret gibt den Behörden die Mittel, schnell Fragen zu stellen, solange die Beweise frisch sind. Wer Audit-Nachweise erst nachträglich zusammenstellen will, wird mit diesem Modell Schwierigkeiten haben.

Bußgelder und Finanzierung der Durchsetzung

Artikel 23 legt die Bußgeldobergrenzen fest. Er übernimmt die Maximalwerte aus Artikel 99 des AI Act: bis zu 35 Mio. Euro oder 7 % des weltweiten Jahresumsatzes für schwerste Verstöße, 15 Mio. Euro für die nächste Stufe und 7,5 Mio. Euro für falsche Angaben. Das Dekret ergänzt eine nationale Stufe: 1 Mio. Euro oder 0,5 % des Umsatzes für Pflichten aus den Artikeln 27 und 86 des AI Act – das betrifft Folgenabschätzungen zu Grundrechten für bestimmte Anwender und das Recht auf Erklärung individueller Entscheidungen.

Die Finanzierung ist bemerkenswert: Einnahmen aus Bußgeldern von ACN und AgID werden vorrangig diesen Behörden zugewiesen. Eine Durchsetzungsbehörde, die sich teilweise selbst finanziert, hat strukturell ein Interesse, ihre Prüfkapazitäten auszubauen. Gleichzeitig schreibt Artikel 54 finanzielle Neutralität vor, also keine neuen Staatsausgaben – was die Garante als Widerspruch zu Artikel 70(3) des AI Act sieht, der angemessene Ressourcen für nationale Behörden verlangt. Ob ACN und AgID ausreichend ausgestattet sein werden, bleibt offen.

Ein Punkt verlangt Aufmerksamkeit: Das Dekret enthält keine Regelung, ab wann die Bußgelder gelten, und erwähnt die Verordnung (EU) 2026/1744, den EU Digital Omnibus zu KI, nicht. Wer behauptet, genau zu wissen, ab wann Bußgelder greifen, füllt eine Lücke im Text mit einer Annahme. Die vorsichtige Lesart ist: Die institutionellen Befugnisse gelten ab dem 23. Oktober 2026, die Sanktionsfristen für einzelne Pflichten richten sich nach den Terminen des AI Act.

Was noch offen ist

Einige Teile des Rahmens sind noch nicht fertig – ein Vorbereitungsplan sollte das berücksichtigen.

Die Sandbox-Regelungen in den Artikeln 26 bis 31 beschreiben eine Joint Operating Group, die noch nicht eingerichtet ist, und das Dekret setzt dafür keine Frist. Auch mehrere Umsetzungsakte, darunter die Modalitäten für Inspektionen von Realtests, haben keine Frist. Artikel 41 erklärt arbeitsrechtliche Entscheidungen, die ausschließlich automatisiert getroffen werden, für nichtig – und eine Einwilligung ist keine Ausnahme. Das ist eine strengere nationale Regel, die Arbeitgeber mit automatisierten Auswahl- oder Planungsprozessen genau lesen sollten.

Das größere bewegliche Element liegt auf EU-Ebene. Die Verordnung (EU) 2026/1744, der Digital Omnibus zu KI, wurde am 24. Juli 2026 im Amtsblatt veröffentlicht und trat am 27. Juli 2026 in Kraft. Cooleys Analyse beschreibt, wie sie wichtige Fristen des AI Act verschiebt: Die Hochrisiko-Pflichten für Annex-III-Systeme verschieben sich auf den 2. Dezember 2027, die für Annex-I-Systeme auf den 2. August 2028, während die Transparenzpflichten aus Artikel 50 ab dem 2. August 2026 gelten.

Diese Daten verändern das Tempo der inhaltlichen Pflichten, aber nicht die institutionellen Änderungen in Italien. Behörden existieren, Prüfungsbefugnisse existieren, und Realtests von Hochrisiko-Systemen können stattfinden, bevor die Hochrisiko-Pflichten für Systeme am Markt gelten. Die Verschiebung ist Zeit, um die Nachweisfähigkeit aufzubauen – kein Freibrief zum Abwarten. Quellen, die noch einen Hochrisiko-Stichtag im August 2026 nennen, sind überholt und sollten nicht als Planungsgrundlage dienen.

Warum Regulierer Daten regulieren – nicht Modelle

Führungskräfte stellen sich KI-Regulierung oft als Prüfung von Algorithmen vor. Ein Prüfer im Unternehmen stellt andere Fragen: Welche personenbezogenen und sensiblen Daten wurden vom System verarbeitet? Wer genehmigte den Zugriff? Entsprach der Zugriff dem angegebenen Zweck? Welche Nachweise gibt es dafür? Ein Modell ist von außen schwer zu prüfen – die Datenspur darum herum nicht.

Deshalb lassen sich zero trust-Prinzipien für generative KI so direkt in Audit-Bereitschaft übersetzen. Ein KI-System ist aus Kontrollsicht ein weiterer Akteur, der Daten anfordert. Es braucht eine Identität, einen definierten Geltungsbereich, eine Autorisierungsentscheidung pro Anfrage und einen Nachweis über das Geschehen. Unternehmen, die diese Kontrollen bereits für Menschen und Anwendungen durchsetzen, können sie mit geringem Aufwand auf KI ausweiten. Wer KI-Tools über breite Servicekonten auf File Shares, E-Mail-Archive und Repositorys zugreifen lässt, kann die erste Prüferfrage nicht beantworten.

Die gleiche Logik erklärt, warum der Fokus des Dekrets auf Realtests so bedeutsam ist. In der Testphase ist die Versuchung am größten, mit Echtdaten und lockeren Kontrollen zu arbeiten, da das System noch nicht produktiv ist. Doch genau diese Phase kann ein italienischer Prüfer jetzt unangekündigt prüfen. Die Kontrollumgebung für Testdaten muss dem Produktionsstandard entsprechen – und die Nachweise müssen genauso abrufbar sein.

Datenschutz und KI-Governance greifen auch praktisch ineinander. Ein zero trust-Ansatz für KI-Datenschutz verlangt bereits Datenminimierung, Zweckbindung und Zugriffsprotokollierung – genau die Nachweise, die auch eine AI Act-Prüfung fordert. Wer dies für die DSGVO bereits umgesetzt hat, ist besser vorbereitet als gedacht. Wer KI als außerhalb seines Data Governance-Programms sieht, ist es nicht.

Wie das Dekret verschiedene Rollen betrifft

Das Dekret trifft nicht jedes Unternehmen gleich – eine sinnvolle Vorbereitung beginnt mit der Frage, wo das eigene Unternehmen steht. Die drei folgenden Szenarien sind beispielhaft.

Beispiel: Ein Anbieter entwickelt ein Hochrisiko-KI-System für kritische Infrastrukturen. Dieses Unternehmen ist besonders exponiert: Das System muss ggf. bei ACN nach Artikel 14 registriert werden, die Konformitätsbewertungsstelle unterliegt der AgID-Überwachung, und jeder Realtest kann geprüft werden. Der Anbieter braucht Testnachweise, Data Governance-Dokumentation und eine nachvollziehbare Begründung für die Auswahl und Überwachung der Bewertungsstelle.

Beispiel: Ein Anwender, etwa eine Bank, nutzt ein KI-Tool für Kreditentscheidungen. Hier ist die Bank von Italien oder CONSOB nach Artikel 17 die zuständige Aufsicht, und das bestehende Aufsichtsverhältnis prägt die Prüfung. Im Mittelpunkt stehen die Datenkontrolle des Tools, die Überwachung der Ergebnisse und der Nachweis, dass für jeden Entscheidungspfad ein Mensch verantwortlich ist. Wer bereits hohe Anforderungen an ICT- und Drittparteien-Nachweise erfüllt, ist im Vorteil – sofern sich diese Nachweise auch auf das KI-Tool erstrecken.

Beispiel: Ein Arbeitgeber nutzt automatisierte Auswahl- oder Planungsprozesse. Artikel 41 erklärt arbeitsrechtliche Entscheidungen, die ausschließlich automatisiert getroffen werden, für nichtig – und eine Einwilligung ändert daran nichts. Das ist eine strenge nationale Regel: Menschliche Überprüfung im Prozess ist Pflicht, nicht Kür. Arbeitgeber sollten sicherstellen, dass eine Person mit echter Entscheidungsbefugnis jede Entscheidung prüft – und Nachweise dafür führen. Der Audit-Trail für diese Prüfung ist selbst ein Data Governance-Artefakt.

Allen drei Szenarien liegt das Gleiche zugrunde: Wissen, welche Daten die eigenen KI-Systeme erreichen, jeden Zugriff einer verantwortlichen Person zuordnen – und einen Nachweis führen, der auch einer externen Prüfung standhält.

Warum Nachweisqualität wichtiger ist als Richtliniendichte

Viele Compliance-Programme messen Fortschritt an der Zahl geschriebener Richtlinien. Prüfregime messen anders: Ein Prüfer, der eine gut formulierte KI-Richtlinie liest, stellt die nächste Frage – woher wissen Sie, dass die Richtlinie eingehalten wurde? Die Antwort steckt in den operativen Nachweisen, nicht im Papier.

Diese Lücke zwischen Papier und Praxis ist die größte Schwachstelle vieler Unternehmen. Eine Richtlinie kann vorsehen, dass KI-Tools nur auf genehmigte Repositorys zugreifen dürfen – die technische Konfiguration erlaubt aber breiten Zugriff über ein geteiltes Konto. Eine Richtlinie kann menschliche Freigabe für sensible Daten verlangen – aber kein System zeichnet auf, wer was genehmigt hat. Prüft der Prüfer die Behauptung gegen die Aufzeichnung, wird die Lücke zum Befund.

Die Lücke schließt man mit Kontrollen, die Richtlinien automatisch durchsetzen und die Entscheidung protokollieren. Werden Zugriffsregeln bei jeder Anfrage vom System angewendet, zeigt das Protokoll Regel und Anwendung – und die Richtlinie ist nicht mehr bloß Anspruch. Das ist die Logik von Policy-driven Data Governance, bei der der Data Policy Engine-Ansatz Regeln konsistent auf den Datenaustausch anwendet und jede Entscheidung dokumentiert.

Das verändert auch die Kosten der Audit-Vorbereitung: Ist der Nachweis ein Nebenprodukt des Normalbetriebs, wird eine Prüfungsanfrage zur Abrufaufgabe. Muss der Nachweis aus verstreuten Systemen rekonstruiert werden, wird jede Prüfung zum Projekt. Mit den neuen unangekündigten Prüfungsbefugnissen in Italien ist der Unterschied zwischen diesen Zuständen der Unterschied zwischen einem ruhigen Nachmittag und einer Krise.

Welche Nachweise ein Prüfer verlangt

Würde ein ACN-Prüfer heute die Testphase eines Hochrisiko-KI-Systems prüfen, würde die Anfrage wahrscheinlich auf wenige Nachweiskategorien hinauslaufen. Wer diese vorbereitet, macht aus einer stressigen Prüfung einen routinierten Dokumentenaustausch.

• Identität des Akteurs. Welches KI-System, welcher Agent oder welche Integration hat auf Daten zugegriffen – und welcher Mensch oder Verantwortliche hat dies autorisiert?
• Zugriffsbereich. Auf welche Repositorys, Ordner und Datensätze konnte das System zugreifen, auf welche hat es tatsächlich zugegriffen – und welche Richtlinie erlaubte jede Aktion?
• Datenklassifizierung. Waren personenbezogene, vertrauliche oder regulierte Inhalte betroffen – und wie wurden sie behandelt?
• Chain of Custody. Ein Nachweis, was mit den Daten nach dem Zugriff des KI-Systems geschah, inklusive etwaiger Weitergabe. Ein dokumentierter Chain of Custody macht daraus eine Nachschlageaufgabe statt einer Rekonstruktion.
• Manipulationssicherheit. Nachweis, dass die Protokolle nachträglich nicht verändert wurden. Protokolle, die ein Administrator bearbeiten kann, haben für Prüfer wenig Wert.
• Incident Handling. Wie wurden Anomalien erkannt und eskaliert – belegt durch einen Incident-Response-Prozess, der KI-bezogene Ereignisse abdeckt.

Die meisten Unternehmen können einige dieser Nachweise für Menschen und Anwendungen liefern – aber nur wenige für KI-Systeme, und noch weniger in einheitlicher Form. Über die KI-Plattform, das Dateisystem, den Identity Provider und ein SIEM verteilte Nachweise müssen manuell zusammengeführt werden – und das dauert Tage. Eine unangekündigte Prüfung lässt dafür keine Zeit.

Qualität zählt genauso wie Vollständigkeit. Ein einheitliches Audit-Log, das jede Aktion mit Identität, Richtlinienentscheidung und Ergebnis dokumentiert, ist ein stärkerer Nachweis als eine Sammlung plattformspezifischer Protokolle mit widersprüchlichen Zeitstempeln und Bezeichnungen. Prüfer honorieren Nachweise, die sie verifizieren können und die eine konsistente Geschichte erzählen. Nachweise, die spät, unvollständig oder in widersprüchlichen Formaten eintreffen, werden abgewertet.

Wie KI-Agents in die gleichen Kontrollen passen

KI-Agents bringen eine Besonderheit mit: Sie können Aktionen verketten, Tools aufrufen und Daten systemübergreifend schneller verarbeiten als ein Mensch jeden Schritt prüfen könnte. Die richtige Antwort ist kein separates, lockereres Regime für Agents – sie sollten wie menschliche Anwender nach denselben Prinzipien für Identität, Autorisierung und Audit geführt werden, mit der zusätzlichen Regel, dass jede Agent-Aktion auf einen verantwortlichen Menschen zurückführbar ist.

Dieses Prinzip entspricht auch der Einführung des Model Context Protocol (MCP). MCP verbindet KI-Assistenten mit Unternehmensdatenquellen und Tools – das ist nützlich, schafft aber auch einen neuen Weg zu sensiblen Inhalten. Ohne Kontrollen kann eine MCP-Integration dazu führen, dass ein Assistent Inhalte liest, die der anfordernde Nutzer nie sehen dürfte. Der Kiteworks Secure MCP Server adressiert dieses Risiko durch rollen- und attributbasierte Zugriffskontrolle sowie OAuth-Authentifizierung für MCP-Anfragen – jede Anfrage wird im Kiteworks-Control-Plane protokolliert.

Human Parity ist der Maßstab für jede Agent-Einführung: Kann ein menschlicher Mitarbeiter eine Datei nicht öffnen, darf es der Agent für diesen Mitarbeiter auch nicht. Wird eine menschliche Aktion mit Identität und Zeitstempel protokolliert, gilt das auch für den Agenten. Braucht ein Mensch einen dokumentierten geschäftlichen Grund für den Export eines Datensatzes, braucht der Agent ihn ebenso. So bekommt ein Prüfer auf die Frage nach Agentenzugriffen die gleiche Antwort wie auf die Frage nach Mitarbeiterzugriffen.

Dieser Ansatz begrenzt auch die Compliance-Kosten bei der Einführung von Agents: Statt für jedes neue KI-Tool ein eigenes Kontrollframework zu bauen, erweitern Sicherheitsteams die bestehenden Data-Layer-Kontrollen – mit Role-Based Access Control und Attribute-Based Access Control – auf eine neue Anfragerklasse.

Wie Kiteworks die Audit-Bereitschaft für KI-Datenzugriffe unterstützt

Kiteworks besitzt keine EU AI Act-Zertifizierung – und kein Anbieter kann ein Unternehmen allein durch das Dekret compliant machen. Was Kiteworks bietet, ist Kontrolle und Nachweis darüber, wie KI-Systeme auf sensible Inhalte zugreifen – genau die Ebene, die Prüfer untersuchen werden.

Kiteworks Compliant AI steuert KI-Zugriffe auf der Data-Layer-Ebene. Jede KI-Anfrage wird über OAuth 2.0 mit einer Identität authentifiziert, die an den menschlichen Autorisierer gebunden ist – so bleibt Verantwortlichkeit erhalten und geht nicht in einem geteilten Servicekonto unter. Attributbasierte Zugriffskontrolle wird auf Operationsebene ausgewertet, d. h. die Richtlinienentscheidung bezieht sich darauf, was das System mit einem bestimmten Inhalt tun will – nicht nur, ob es überhaupt verbinden darf. Inhalte werden mit FIPS 140-3-validierter Verschlüsselung geschützt, und Aktivitäten werden in einem manipulationssicheren Audit-Trail aufgezeichnet, der an ein SIEM gestreamt werden kann. Mehr zu FIPS 140-3 Compliance und dessen Bedeutung für Datenschutz.

Im Abgleich mit den oben genannten Nachweiskategorien hilft dieses Design, Identität des Akteurs, Zugriffsbereich und Entscheidungen auf Operationsebene in einem einzigen Protokoll nachzuweisen. Der manipulationssichere Trail beantwortet die Frage nach der Integrität, die SIEM-Integration die nach Incident Handling. Da die Kontrolle auf dem Datenaustauschweg und nicht in einem einzelnen KI-Produkt sitzt, kann dasselbe Protokoll mehrere KI-Tools abdecken – wichtig für Unternehmen mit mehreren Lösungen.

Organisationen im Finanzsektor, wo Bank von Italien, CONSOB und IVASS weiterhin eine Aufsichtsfunktion haben, werden feststellen, dass DORA und ähnliche Rahmenwerke bereits starke Drittparteien- und ICT-Nachweise verlangen. Eine gemeinsame Data-Layer für KI-Zugriffe ermöglicht, dass ein Nachweissatz mehreren Regulierern dient. Öffentliche Stellen können denselben Ansatz für den Datenaustausch in ihren KI-Projekten nutzen.

Die ehrliche Grenze: Produktkontrollen ersetzen keine Governance-Entscheidungen. Sie müssen Ihre KI-Systeme weiterhin klassifizieren, Hochrisiko-Systeme bestimmen, zulässige Zwecke definieren und Verantwortliche benennen. Technologie macht diese Entscheidungen durchsetzbar und nachweisbar – aber nicht automatisch.

Ein praktischer Vorbereitungsplan für CISOs und CCOs

Ein Dekret, das in Kraft tritt, während zentrale Umsetzungsakte noch fehlen, belohnt Unternehmen, die sich auf die wahrscheinliche Prüfungsrealität vorbereiten – nicht auf jedes Detail warten. Die folgende Reihenfolge funktioniert unabhängig davon, wie die offenen Fragen gelöst werden.

1. Inventarisieren Sie KI-Systeme und deren Datenwege. Listen Sie jedes KI-System, jeden Agenten und jede Integration auf – auch solche, die einzelne Fachbereiche eingeführt haben. Dokumentieren Sie, auf welche Daten sie zugreifen können und wie.
2. Klassifizieren Sie nach dem AI Act. Bestimmen Sie, welche Systeme Hochrisiko sein könnten – einschließlich solcher in kritischer Infrastruktur gemäß Anhang III Punkt 2, da hier eine nationale Registrierungspflicht bei ACN nach Artikel 14 besteht.
3. Verknüpfen Sie jeden KI-Akteur mit einem verantwortlichen Menschen. Ersetzen Sie geteilte Servicekonten durch Identitäten, die einem benannten Autorisierer zugeordnet sind – jede Aktion muss auf eine Person zurückführbar sein.
4. Verlagern Sie Zugriffsentscheidungen auf die Data-Layer. Setzen Sie Richtlinien für jede Operation an sensiblen Inhalten durch – nicht nur an der Applikationsgrenze. Wenden Sie dieselbe Richtlinie auf Agents und Menschen an.
5. Vereinheitlichen Sie den Audit-Trail. Führen Sie KI-Zugriffsprotokolle in ein manipulationssicheres Log zusammen und streamen Sie es an Ihr SIEM, damit Prüfer und interne Teams denselben Nachweis sehen.
6. Üben Sie eine unangekündigte Anfrage. Simulieren Sie, dass ein Prüfer innerhalb eines Tages die Testnachweise für ein Hochrisiko-System verlangt. Messen Sie die benötigte Zeit und beheben Sie die aufgedeckten Lücken.
7. Kartieren Sie Aufsichtsbehörden und offene Punkte. Dokumentieren Sie, welche Behörde oder Fachaufsicht zuständig ist, und beobachten Sie die Dekrete zu Prüfungsmodalitäten, die Sandbox-Gruppe und etwaige Omnibus-Leitlinien.

Für Unternehmen mit grenzüberschreitendem Datentransfer gehört eine Prüfung der Datensouveränität in Schritt eins – denn KI-Tests, die italienische Daten an ein extern gehostetes Modell senden, werfen sowohl AI Act- als auch Transferfragen auf.

Italien macht KI-Durchsetzung zu einer Frage benannter Behörden, Prüfungsbefugnisse und Bußgelder – und die geforderten Nachweise liegen in Ihrer Data-Layer. Wie ein einheitliches, manipulationssicheres Protokoll von KI-Datenzugriffen Ihre Audit-Bereitschaft unterstützt, erfahren Sie in einer Demo mit Kiteworks.

Weitere Ressourcen

• Blog Post
  Zero‑Trust-Strategien für bezahlbaren KI-Datenschutz
• Blog Post
  Wie 77 % der Unternehmen bei KI-Datensicherheit scheitern
• eBook
  AI Governance Gap: Warum 91 % kleiner Unternehmen 2025 russisches Roulette mit Datensicherheit spielen
• Blog Post
  Es gibt kein „–dangerously-skip-permissions“ für Ihre Daten
• Blog Post
  Regulierer fragen nicht mehr nach einer KI-Policy. Sie wollen den Nachweis, dass sie funktioniert.