Spanien veröffentlicht erste nationale Leitlinien zur EU‑KI‑Verordnung: Was Unternehmen jetzt konkret tun müssen

Spanien hat als eines der ersten EU‑Mitgliedstaaten umfassende Leitlinien zur praktischen Umsetzung der EU‑Verordnung über Künstliche Intelligenz (EU AI Act) veröffentlicht. Herausgeber ist die nationale KI‑Aufsichtsbehörde AESIA. Die Guides richten sich an Anbieter und Betreiber von KI‑Systemen – mit einem klaren Schwerpunkt auf Hochrisiko‑KI – und übersetzen den Verordnungstext in konkrete Governance‑Anforderungen, Prozesse und Checklisten.

Für Unternehmen mit Kunden oder Standorten in der EU bieten diese Leitlinien einen der bislang detailliertesten Einblicke, wie Aufsichtsbehörden die Pflichten des AI Act auslegen werden – und worauf sie bei Prüfungen achten.

1. Kontext: Was genau Spanien veröffentlicht hat – und von wem

1.1 AESIA als Vorreiter unter den EU‑Aufsichtsbehörden

Spanien hat mit der Spanish Agency for the Supervision of Artificial Intelligence (AESIA) früh eine zentrale KI‑Aufsichtsbehörde geschaffen. Sie fungiert als Marktüberwachungsbehörde für verbotene und Hochrisiko‑KI‑Systeme und ist im Ministerium für digitale Transformation angesiedelt. Damit gehört Spanien zu den Mitgliedstaaten mit einer vergleichsweise klaren Governance‑Struktur für den AI Act.

AESIA wurde zudem vom spanischen Gesetzgeber als zentrale Stelle in einem nationalen KI‑Rahmen positioniert und ist Ansprechpartner für Unternehmen, andere nationale Behörden und EU‑Institutionen in Fragen der KI‑Aufsicht.

1.2 Umfang der neuen Leitlinien

Auf der AESIA‑Website wurden im Rahmen des spanischen KI‑Regulatory‑Sandkastens nun 16 Leitlinien (Guides 01–16) plus ein Sammlungs‑ZIP mit Checklisten und Beispielen veröffentlicht. Die Guides sind ausdrücklich nicht rechtsverbindlich, orientieren sich aber eng an den Anforderungen des AI Act und sind so angelegt, dass sie als Grundlage für die späteren EU‑weiten technischen Leitlinien dienen sollen.

Die Guides decken u. a. folgende Themenblöcke ab:

• 01–02: Einführende Erläuterungen zum AI Act und praktische Beispiele

• 03: Konformitätsbewertung

• 04: Qualitätsmanagementsystem

• 05: Risikomanagement

• 06: Menschliche Aufsicht

• 07: Daten und Daten‑Governance

• 08: Transparenz

• 09: Genauigkeit

• 10: Robustheit

• 11: Cybersicherheit

• 12: Protokolle und Logs

• 13: Marktüberwachung nach Inverkehrbringen (Post‑Market Surveillance)

• 14: Incident‑Management

• 15: Technische Dokumentation

• 16: Handbuch zur Nutzung der Checklisten

Damit liegt eines der vollständigsten nationalen Pakete zur Operationalisierung des AI Act vor – deutlich detaillierter als vielerorts bislang verfügbare allgemeine EU‑FAQ oder kurze Aufsichts‑Statements.

1.3 Einbettung in EU‑Zeitplan und nationale Gesetzgebung

Der AI Act ist seit August 2024 in Kraft; zentrale Pflichten für Hochrisiko‑Systeme werden ab August 2026 gelten. Spanien arbeitet parallel an einem ergänzenden nationalen KI‑Gesetz, das u. a. Zuständigkeiten, Sanktionen und Verjährungsfristen präzisiert und AESIA als Hauptsanktionsbehörde für verbotene und Hochrisiko‑Systeme etabliert.

Die nun veröffentlichten Leitlinien sind bewusst vorgezogene Orientierungshilfen, damit Unternehmen ihre Governance‑Strukturen rechtzeitig anpassen und Investitionen planen können.

2. Kerninhalte der spanischen Leitlinien – was ist wirklich neu?

2.1 De‑facto‑Standard für ein KI‑Qualitätsmanagementsystem

Der Guide 04 (Qualitätsmanagementsystem) geht deutlich weiter als der Gesetzestext und skizziert ein nahezu vollständiges KI‑QMS‑Modell, das in bestehende ISO‑Strukturen (z. B. ISO 9001, ISO 27001, ISO 42001) integrierbar ist.

Wesentliche Elemente:

• Verantwortlichkeiten: klare Zuordnung von Rollen wie „AI Compliance Officer“, „Product Owner KI‑System“, „Data Steward“, „Security Officer“ inklusive Eskalationswegen.

• Policy‑Architektur: Trennung zwischen einer übergeordneten „AI Governance Policy“ und spezifischen Verfahrensanweisungen (z. B. für Datenlabeling, Modellfreigabe, Änderungskontrolle).

• Lebenszyklus‑Orientierung: Pflicht zur Dokumentation und Steuerung über den gesamten KI‑Lebenszyklus (Use‑Case‑Definition, Entwicklung, Test, Deployment, Betrieb, Stilllegung).

• Schnittstellenmanagement: Betonung der Verantwortung von Importeuren, Distributoren und internen „Deployern“ – also nicht nur der ursprünglichen Modellanbieter.

Praktische Implikation: Unternehmen, die KI bislang nur in bestehende IT‑QM‑Strukturen „hineingehängt“ haben, werden ihre Governance deutlich nachschärfen müssen.

2.2 Konkrete Erwartung an Risiko‑Management und „Risk Register“

Der Guide 05 (Risikomanagement) beschreibt ein wiederkehrendes Risiko‑Managementverfahren und konkretisiert, welche Inhalte ein „Risk Register“ für Hochrisiko‑KI enthalten sollte, u. a.:

• Beschreibung des Einsatzkontexts (Zweck, Nutzergruppen, Umgebung, betroffene Rechte und Interessen)

• systematische Gefährdungsanalyse (z. B. Diskriminierungsrisiken, Sicherheitsrisiken, Fehlinterpretationen, Missbrauchsszenarien)

• Bewertung entlang von Schweregrad, Eintrittswahrscheinlichkeit und Entdeckbarkeit

• Zuordnung von Mitigationsmaßnahmen (technisch, organisatorisch, vertraglich)

• Festlegung von Acceptable Risk Levels mit Genehmigung durch eine zuständige Stelle

Neu und praxisrelevant ist, dass AESIA explizit auf Iterativität und Nachvollziehbarkeit pocht: Risikobewertungen müssen nach größeren Modell‑ oder Datenänderungen aktualisiert und versioniert werden. „One‑off“-Analysen genügen nicht.

2.3 Menschliche Aufsicht als gestalteter Prozess – nicht nur ein „Button“

Der Guide 06 (Menschliche Aufsicht) betont, dass „human oversight“ weit mehr ist als eine Option, automatisierte Entscheidungen zu übersteuern. Er fordert u. a.:

• Klare Definition der Aufsichtsrolle (Kompetenzprofil, Schulungsanforderungen)

• Operationalisierte Eingriffsmöglichkeiten (z. B. Freigabeprozesse, Vier‑Augen‑Prinzip, temporäres Abschalten von Modulen)

• Designanforderungen an Benutzeroberflächen, damit Aufsichtspersonen Modellentscheidungen kritisch prüfen können (Erklärbarkeit, Kontextinformationen, Unsicherheitsanzeigen)

• Protokollierung, wann und wie menschliche Eingriffe stattfinden und welche Wirkungen sie hatten

Für Unternehmen bedeutet das: Oberflächliche Lösungen („KI darf jederzeit von einem Menschen überschrieben werden“) ohne klare Prozesse und Schulung werden Aufsichtsprüfungen voraussichtlich nicht bestehen.

2.4 Daten‑ und Modell‑Governance bis ins Detail

Der Guide 07 (Daten und Daten‑Governance) und Guide 15 (Technische Dokumentation) liefern einen sehr klaren Eindruck davon, wie tief Behörden in Daten‑ und Modellentscheidungen hineinleuchten wollen.

Beispielhafte Anforderungen:

• Datenherkunft und ‑kategorien: systematische Erfassung von Quellen, Lizenzen, Verarbeitungszwecken, ggf. Rechtsgrundlagen (insb. im Zusammenspiel mit DSGVO).

• Datenqualität: Verfahren zur Erkennung von Bias, fehlenden Werten, Inkonsistenzen, „Data Drift“ in Betrieb.

• Annotierung und Labeling: Dokumentation von Label‑Prozessen, Qualifikation der Labeler, Qualitätssicherung.

• Modellversionierung: eindeutige Zuordnung von Datenständen, Trainingsläufen, Hyperparametern, Evaluationsmetriken und Deployment‑Versionen.

Damit zeichnen die Guides faktisch den Blueprint für ein unternehmensweites AI Asset Register und ein technisches Audit‑Dossier, das bei Marktüberwachungen vorgelegt werden kann.

2.5 Transparenz, Genauigkeit, Robustheit und Cybersecurity als „Prüfpfade“

Die Guides 08–11 operationalisieren die aus dem AI Act bekannten Anforderungen weiter:

• Transparenz (08): definierte Zielgruppen (Endnutzer, Geschäftskunden, Behörden) mit jeweils spezifischen Informationspaketen; Erwartung klarer „Model Cards“ und Nutzerinformationen.

• Genauigkeit (09): Verpflichtung, Zielmetriken (Accuracy, Recall, FPR etc.) pro Use Case festzulegen, diese kontinuierlich zu monitoren und Schwellenwerte zu definieren, ab denen ein System als nicht mehr konform gilt.

• Robustheit (10): Tests gegenüber Verteilungsverschiebungen, adversarialen Inputs, Lastspitzen und sicherheitskritischen Fehlerszenarien.

• Cybersicherheit (11): Einbindung in bestehende ISMS‑Strukturen, spezielle Risiken wie Model Theft, Data Poisoning, Prompt Injection (bei generativen Systemen) und Zugang zu Modell‑APIs.

Unternehmen erhalten damit eine Art implizites Test‑ und Auditprotokoll, das sich sehr gut in interne und externe KI‑Audits übersetzen lässt.

2.6 Post‑Market‑Surveillance und Incident‑Management

Mit den Guides 13 (Post‑Market‑Surveillance) und 14 (Incident‑Management) adressiert AESIA einen Bereich, der im AI Act teilweise abstrakt formuliert ist und hohe praktische Relevanz hat.

Kernelemente:

• Pflicht zu einem Überwachungsplan für Hochrisiko‑Systeme mit Kennzahlen, Beobachtungsmechanismen und definierten Review‑Zyklen.

• Einrichtung eines Meldesystems für interne und externe Vorfälle (z. B. schwerwiegende Fehlentscheidungen, Sicherheitsvorfälle, systematische Diskriminierungen).

• Erwartung eines formalen Incident‑Workflows (Erkennung, Erstbewertung, Eskalation, Ursachenanalyse, Abstellmaßnahmen, Dokumentation und ggf. Meldung an Behörden innerhalb bestimmter Fristen).

Unternehmen, die solche Strukturen bislang nur im klassischen IT‑Security‑ oder Datenschutzkontext (z. B. DSGVO‑Datenschutzverletzungen) kennen, müssen ihre Prozesse auf KI‑spezifische Szenarien erweitern und miteinander verzahnen.

3. Konkrete Auswirkungen auf Unternehmen – Risiken und Chancen

3.1 Warum die Leitlinien auch außerhalb Spaniens relevant sind

Obwohl die AESIA‑Guides formal nur für Spanien erstellt wurden, sind sie aus mehreren Gründen de facto EU‑weit relevant:

1. Sie wurden im Rahmen eines europäisch abgestimmten KI‑Sandkastens entwickelt und sollen als Basis für EU‑Leitlinien dienen.

2. Spanien ist in der EU‑Governance‑Architektur sichtbar positioniert; AESIA ist in EU‑Gremien vertreten und beeinflusst dort Interpretationen.

3. Viele Anforderungen sind direkt aus dem AI Act abgeleitet – Unternehmen, die sich an diesen hohen Standard anlehnen, minimieren das Risiko späterer Nachschärfungen.

Für international tätige Anbieter und Betreiber von KI‑Systemen empfiehlt es sich deshalb, die Guides als konservativen Referenzstandard zu verstehen.

3.2 Regulatorische und operative Risiken

Wer die jetzt sichtbare Richtung ignoriert, läuft in mehrere Risikokategorien hinein:

• Regulatorisches Risiko: Bußgelder und Untersagungen bei Nichteinhaltung, insbesondere im Hochrisiko‑Bereich (z. B. Kredit‑Scoring, Personalrecruiting, Medizinprodukte, kritische Infrastrukturen).

• Verzögerungsrisiko: Projekte müssen kurz vor oder nach Go‑Live „zurück auf Los“, weil zentrale Dokumentation, Risikobewertungen oder Überwachungsprozesse fehlen.

• Reputationsrisiko: Behörden‑Verfügungen, medienwirksame Vorfälle oder diskriminierende Entscheidungen einzelner Systeme können zu erheblichen Vertrauensverlusten führen.

Gerade für Konzerne mit komplexen IT‑Landschaften ist das Risiko fragmentierter Umsetzungen (jede Business‑Unit macht „ihr eigenes KI‑Compliance“) hoch – AESIA betont dagegen explizit zentrale Governance.

3.3 Strategische Chancen

Gleichzeitig eröffnen frühe, strukturierte Anpassungen Chancen:

• Vertrauensvorsprung bei Kunden durch nachvollziehbar gesteuerte, dokumentierte KI‑Systeme.

• Effizientere Audits (intern, durch Kunden, durch Aufsichtsbehörden) dank standardisierter Dokumentation und Checklisten.

• Skalierbarkeit: Ein einmal etabliertes KI‑Governance‑Framework ist auf neue Use Cases und Märkte übertragbar.

• Besseres Risikoprofil in Verhandlungen mit Versicherern, Investoren und Aufsichtsbehörden.

In Summe gilt: Wer sich heute an den spanischen Guides orientiert, reduziert die Wahrscheinlichkeit teurer Re‑Designs in zwei bis drei Jahren deutlich.

4. Praxisnahe Beispiele und Szenarien

4.1 Bank mit KI‑gestützter Kreditvergabe (Hochrisiko‑System)

Eine europaweit tätige Bank betreibt ein KI‑basiertes Scoring‑System zur Kreditentscheidung.

Herausforderung: Das System fällt klar unter Hochrisiko‑KI. Bisher existiert eine Sammlung technischer Dokumente, aber kein durchgängiges KI‑QMS.

Anwendung der AESIA‑Guides:

• Aufbau eines AI Risk Registers entlang der in Guide 05 beschriebenen Struktur, inklusive Diskriminierungsrisiken (z. B. indirekte Benachteiligung bestimmter Gruppen durch Proxy‑Variablen).

• Ergänzung des bestehenden Kreditrisiko‑Managements um eine eigene Modell‑Governance‑Schiene mit klaren Freigabeprozessen.

• Schulung der Kreditsachbearbeiter als „human overseers“, inklusive Dokumentation, in welchen Fällen sie Modellvorschläge abweichend entscheiden und warum.

• Einrichtung eines Post‑Market‑Surveillance‑Dashboards, das z. B. Ablehnungsquoten nach Kundensegmenten überwacht und bei Auffälligkeiten eine tiefergehende Analyse auslöst.

4.2 Industrieunternehmen mit visueller Qualitätskontrolle

Ein Fertigungsunternehmen setzt ein Computer‑Vision‑System zur Qualitätskontrolle ein. Der Use Case kann je nach Einordnung Hochrisiko‑Charakter haben, z. B. wenn sicherheitskritische Komponenten betroffen sind.

Anwendung der AESIA‑Guides:

• Guide 07 fordert ein systematisches Daten‑ und Label‑Management: Das Unternehmen führt ein Register der verwendeten Bilddaten, dokumentiert Labelprozesse und definiert regelmäßige Re‑Sampling‑Zyklen, um „Data Drift“ (neue Materialien, geänderte Beleuchtung) zu erkennen.

• Über Guide 10 und 11 werden Robustheits‑ und Sicherheits‑Tests eingeführt: Stress‑Tests mit verschmutzten Sensoren, veränderten Lichtbedingungen und adversarialen Mustern.

• Nach Guide 13 richtet das Unternehmen eine laufende Überwachung ein, die Fehlklassifizierungen nach Produktionschargen erfasst und mit Qualitätsdaten (Rückläufer, Reklamationen) verknüpft.

Ergebnis: Das Unternehmen ist in der Lage, regulatorische Anforderungen nachzuweisen UND produktionsrelevante Kennzahlen (Ausschuss, Nacharbeit) zu verbessern.

4.3 Personaldienstleister mit KI‑gestütztem Matching

Ein HR‑Dienstleister nutzt ein KI‑System, das Bewerberprofile mit Stellenangeboten abgleicht und Rankings erzeugt. Dieser Use Case ist nach AI Act typischerweise als Hochrisiko eingestuft.

Relevante Leitlinien:

• Transparenz (Guide 08): Das Unternehmen entwickelt verständliche Erklärtexte und visuelle Darstellungen, wie das Matching erfolgt, welche Daten einfließen und welche Rolle menschliche Recruiter spielen.

• Bias‑Kontrolle (Guide 05 und 07): Es werden Testdaten und Metriken eingeführt, die systematische Benachteiligung bestimmter Gruppen erkennen (z. B. nach Alter, Geschlecht, Herkunft), und entsprechende Korrekturmechanismen.

• Human Oversight (Guide 06): Recruiter dürfen Vorschlagslisten anpassen, müssen Abweichungen aber begründen. Diese Begründungen werden ausgewertet, um das Modell iterativ zu verbessern.

So entsteht eine belastbare Argumentation, dass das System zwar automatisiert unterstützt, aber nicht intransparent oder diskriminierend agiert.

5. Was Unternehmen jetzt konkret tun sollten

5.1 Gap‑Analyse gegen AESIA‑Guides durchführen

Unternehmen mit relevanten KI‑Use‑Cases sollten kurzfristig eine strukturierte Gap‑Analyse durchführen:

1. Inventarisierung aller KI‑Systeme (inkl. zugekaufter SaaS‑Lösungen und interner Tools).

2. Einordnung, welche Systeme Hochrisiko oder in anderen Pflichthorizonten (Transparenzpflichten, generative KI) liegen.

3. Mapping der heutigen Governance‑Strukturen (Policies, Rollen, Prozesse, Dokumente) auf die AESIA‑Guides 03–15.

4. Identifikation von Lücken bei Risiko‑Management, Dokumentation, menschlicher Aufsicht, Monitoring und Incident‑Management.

Das Ergebnis sollte ein priorisierter Maßnahmenplan mit Zeithorizonten sein – idealerweise abgestimmt mit Rechts‑, Compliance‑, IT‑ und Fachbereichen.

5.2 Zentrales AI Governance Framework etablieren

Statt isolierte Initiativen in einzelnen Abteilungen zuzulassen, empfiehlt sich ein zentrales AI Governance Framework, das:

• eine unternehmensweit gültige AI Policy definiert;

• Rollen und Verantwortlichkeiten (inkl. Eskalationswege) klar regelt;

• Mindestanforderungen an Dokumentation, Tests und Monitoring vorgibt;

• mit bestehenden Governance‑Systemen (Informationssicherheit, Datenschutz, Qualitätsmanagement, Risikomanagement) verzahnt ist.

Die AESIA‑Guides können dabei als Template dienen, welches Niveau mindestens erwartet werden wird.

5.3 Technische und organisatorische Roadmap synchronisieren

Viele Anforderungen lassen sich nicht allein rechtlich oder organisatorisch lösen, sondern erfordern konkrete technische Anpassungen:

• Logging‑Infrastruktur für KI‑Systeme (Guide 12)

• Monitoring‑Dashboards für Metriken wie Accuracy, Fairness, Drift

• Schnittstellen zur bestehenden SIEM‑/Security‑Infrastruktur

• Tools für Dokumentation und Versionierung von Daten und Modellen

Die Roadmap sollte daher gemeinsam von IT, Data/AI‑Teams, Compliance und Fachbereichen erstellt werden.

5.4 Pilotprojekte in kritischen Use Cases starten

Statt auf ein Big‑Bang‑Programm zu setzen, ist es sinnvoll, ein oder zwei kritische Use Cases als Pilot zu wählen (z. B. Kreditvergabe, HR‑Matching, sicherheitskritische QC) und dort die AESIA‑Anforderungen konsequent umzusetzen.

Lernziele:

• Welcher Dokumentationsaufwand entsteht tatsächlich?

• Wo fehlen Tools oder Rollen?

• Welche Prozesse müssen angepasst werden (z. B. Freigaben, Change‑Management)?

Die Erfahrungen können dann in skalierbare Standards überführt werden.

6. Fazit und zentrale Erkenntnisse

Spanien liefert mit den AESIA‑Leitlinien eines der ersten umfassenden Pakete, wie der EU AI Act in der Praxis aussehen wird. Auch wenn die Dokumente formal nicht bindend sind, setzen sie einen faktischen Maßstab für Governance‑Niveau, Dokumentationstiefe und Risiko‑Management.

Für Unternehmen ergibt sich daraus weniger die Frage, ob sie sich an diesen Standards orientieren sollten, sondern wie schnell sie dies tun. Wer frühzeitig ein robustes KI‑Governance‑Framework etabliert, reduziert nicht nur regulatorische Risiken, sondern schafft auch eine belastbare Grundlage für skalierbare, vertrauenswürdige KI‑Anwendungen.

Wichtigste Take‑aways für Entscheider

• AESIA‑Guides sind Blaupause: Spanien liefert eines der ersten vollumfänglichen Leitlinienpakete zur Umsetzung des EU AI Act – weit über bloße FAQ hinaus.

• Fokus auf Governance statt Einzel‑Use‑Case: Qualitäts‑ und Risiko‑Management, Daten‑Governance und menschliche Aufsicht werden als integriertes System verstanden.

• Dokumentationstiefe steigt deutlich: Risk Register, technische Dossiers, Monitoring‑Pläne und Incident‑Prozesse werden zu Pflichtbausteinen für Hochrisiko‑KI.

• Relevanz über Spanien hinaus: Als EU‑Vorläufer sind die Leitlinien ein konservativer Referenzstandard für alle Unternehmen im EU‑Binnenmarkt.

• Jetzt handeln, nicht warten: Frühzeitige Gap‑Analysen, zentrale Governance‑Strukturen und Pilotprojekte in kritischen Use Cases reduzieren spätere Kosten und Risiken.

Häufig gestellte Fragen (FAQ)

Was sind die spanischen AESIA-Leitlinien zur EU‑KI‑Verordnung?

Die AESIA-Leitlinien sind ein Paket aus 16 praxisorientierten Guides, die den EU AI Act in konkrete Anforderungen, Prozesse und Checklisten übersetzen. Sie richten sich vor allem an Anbieter und Betreiber von Hochrisiko‑KI‑Systemen und dienen als praktische Auslegungshilfe der gesetzlichen Pflichten.

Warum sind die spanischen Leitlinien auch für Unternehmen außerhalb Spaniens relevant?

Die Leitlinien wurden im Rahmen eines EU‑weiten KI‑Sandkastens entwickelt und orientieren sich eng am Wortlaut und der Systematik des EU AI Act. Unternehmen im gesamten EU‑Binnenmarkt können sie als konservativen Referenzstandard nutzen, um sich frühzeitig auf Prüfungsmaßstäbe der Aufsichtsbehörden vorzubereiten.

Wie helfen die AESIA‑Guides bei der Umsetzung eines KI‑Qualitäts- und Risikomanagements?

Die Guides beschreiben detailliert, wie ein KI‑Qualitätsmanagementsystem (KI‑QMS) und ein iteratives Risikomanagement mit Risk Register aufgebaut werden sollen. Dazu gehören klare Rollen, dokumentierte Lebenszyklus‑Prozesse, Bewertungsmethoden für Risiken sowie Vorgaben zu Monitoring, Protokollierung und Incident‑Management.

Welche Rolle spielt menschliche Aufsicht („human oversight“) nach den spanischen Leitlinien?

Menschliche Aufsicht wird als gestalteter Prozess verstanden, nicht nur als Not‑Aus‑Button für automatisierte Entscheidungen. Die Leitlinien fordern definierte Aufsichtsrollen, Schulungskonzepte, klare Eingriffsmöglichkeiten und eine lückenlose Dokumentation, wann und wie Menschen in KI‑Entscheidungen eingreifen.

Was ist der Unterschied zwischen bisherigen IT‑Governance‑Strukturen und einem KI‑Governance‑Framework nach AESIA?

Klassische IT‑Governance fokussiert meist auf Systeme und Sicherheit, während ein KI‑Governance‑Framework zusätzlich modell- und datenbezogene Aspekte sowie spezifische KI‑Risiken adressiert. Die AESIA‑Guides verlangen unter anderem ein AI Asset Register, modellbezogene Tests zu Genauigkeit, Robustheit und Bias sowie dedizierte Prozesse für Post‑Market‑Surveillance von KI‑Systemen.

Welche unmittelbaren Schritte sollten Unternehmen jetzt zur Vorbereitung auf den EU AI Act unternehmen?

Unternehmen sollten zunächst alle bestehenden KI‑Systeme inventarisieren und prüfen, welche als Hochrisiko gelten. Darauf aufbauend empfiehlt sich eine Gap‑Analyse gegenüber den AESIA‑Guides, der Aufbau eines zentralen AI‑Governance‑Frameworks und die Umsetzung von Pilotprojekten in kritischen Use Cases, um Prozesse, Rollen und Tools realitätsnah zu testen.

Welche Risiken drohen Unternehmen, wenn sie die Leitlinien und den EU AI Act ignorieren?

Bei Nichteinhaltung drohen Bußgelder, behördliche Untersagungen und Verzögerungen in KI‑Projekten, wenn Systeme kurz vor oder nach dem Go‑Live nachgebessert werden müssen. Zusätzlich steigt das Reputationsrisiko durch medienwirksame Vorfälle, diskriminierende Entscheidungen oder Sicherheitsprobleme, die mangels Governance nicht rechtzeitig erkannt und adressiert werden.