EU AI Act jetzt auf die Agenda: Praxisleitfaden und Umsetzungsfahrplan für DACH-Unternehmen

Der EU AI Act ist der erste umfassende Rechtsrahmen für Künstliche Intelligenz und betrifft Unternehmen in Deutschland, Österreich und der Schweiz unmittelbar – entweder als Anbieter oder Nutzer von KI-Systemen im EU-Binnenmarkt. Auch Schweizer Unternehmen müssen handeln, wenn sie KI-Systeme im EU/EWR in Verkehr bringen, dort betreiben oder Teil von EU‑Lieferketten sind. Die Vorgaben greifen gestaffelt, beginnend mit Verboten bestimmter Praktiken und gefolgt von Anforderungen an General-Purpose-AI (GPAI) und Hochrisiko‑Systeme. Wer frühzeitig Strukturen schafft, reduziert Compliance‑Risiken, beschleunigt Implementierungen und erzielt schneller messbaren Business‑Impact.

Ziel dieses Playbooks ist es, Ihnen einen klaren, praxisnahen Pfad zu zeigen: Rollen verstehen, Risiken klassifizieren, Pflichten operationalisieren, Governance verzahnen und mit einem realistischen Fahrplan in die Umsetzung gehen.

Rollen klären: Provider vs. Deployer (und mehr)

• Provider (Anbieter): Entwickeln ein KI‑System oder ein GPAI‑Modell und bringen es unter eigenem Namen/Marke in der EU in Verkehr oder stellen es in Betrieb. Dazu zählen auch Unternehmen, die ein bestehendes Hochrisiko‑System wesentlich verändern oder neu zweckbestimmen.
• Deployer (Verwender/Betreiber): Setzen ein KI‑System unter eigener Verantwortung ein, z. B. in einem Geschäftsprozess oder einer Kundeninteraktion. Auch interne Eigenentwicklungen, die nicht vermarktet werden, werden in der Praxis oft „Deployer‑Pflichten“ unterliegen.
• Weitere Akteure: Importeur, Distributor, Bevollmächtigter – in komplexen Lieferketten relevant, insbesondere bei Drittlandbezug.

Praxisbeispiele:

• Manufacturing: Ein OEM, der ein visuelles Qualitätsprüfsystem in eine Maschine integriert, kann Provider eines „Sicherheitsbauteils“ sein; das Werk, das das System in der Produktion nutzt, ist Deployer.
• Finance: Eine Bank, die Kreditwürdigkeitsmodelle von einem Vendor bezieht, agiert als Deployer; entwickelt sie das Modell selbst und rollt es konzernweit aus, übernimmt sie Provider‑Pflichten.
• Healthcare: Ein MedTech‑Hersteller, der eine KI‑Diagnostik als Bestandteil eines Medizinprodukts liefert, ist Provider; die Klinik, die das System einsetzt, ist Deployer.
• Retail: Ein Händler nutzt ein Drittanbieter‑System für Betrugsprävention (Deployer) und könnte bei starker Anpassung zum Provider werden.

Tipp: Ordnen Sie pro Use Case klar zu, wer welche Rolle hat – das bestimmt Ihre Pflichten.

Risikoklassifizierung: Von minimal bis hoch

Der EU AI Act unterscheidet grob vier Klassen:

• Verboten: z. B. bestimmte Formen von manipulativer oder verdeckter Überwachung, unzulässige biometrische Kategorisierung in sensiblen Kontexten.
• Hochrisiko: Systeme mit erheblichem Einfluss auf Sicherheit oder Grundrechte, u. a. als Sicherheitskomponente regulierter Produkte oder in speziellen Annex-III‑Anwendungsfeldern.
• Begrenztes Risiko: Transparenzpflichten, z. B. Kennzeichnung von KI‑Interaktionen oder synthetischen Inhalten.
• Minimales Risiko: Keine spezifischen Pflichten, aber Best Practices empfohlen.

Hochrisiko‑Szenarien in den Zielbranchen:

• Manufacturing: KI als Sicherheitskomponente im Sinne der Maschinen‑/Produktsicherheitsregime (z. B. kollaborative Robotik, sicherheitsrelevante Qualitätskontrollen), autonome Steuerungen, die die Sicherheit beeinflussen.
• Finance: Bewertung der Kreditwürdigkeit und Kredit‑Scoring natürlicher Personen; KI‑Systeme, die den Zugang zu Finanzdienstleistungen wesentlich beeinflussen; bestimmte AML/Fraud‑Anwendungen mit erheblicher Auswirkung auf Betroffene.
• Healthcare: KI als Bestandteil eines Medizinprodukts (MDR/IVDR), diagnostische Unterstützung, Therapievorschlagssysteme; Triage‑Entscheidungen mit Auswirkungen auf Versorgung.
• Retail: Identitäts‑/Altersverifikation beim Checkout; Betrugserkennung mit Kunden‑Impact; algorithmische Personalprozesse (z. B. Screening/Ranking) in Filialnetzen.

Hinweis: Nicht jedes KI‑System in diesen Branchen ist automatisch „hochrisiko“. Entscheidend sind der Zweck, der Kontext (Annex‑III‑Tatbestände) und ob es eine Sicherheitskomponente eines regulierten Produkts ist.

Zentrale Pflichten operationalisieren: Das müssen Sie umsetzen

Für Provider (und je nach Fall Deployer) hochrisikorelevanter Systeme gelten u. a. folgende Kernanforderungen:

• Risikomanagement über den gesamten Lebenszyklus:
  • Identifizierung, Analyse und Behandlung technischer, operationeller und grundrechtsbezogener Risiken.
  • Iteratives Vorgehen mit Tests, Validierung und Residualrisiko‑Bewertung.
• Daten-Governance und Datenqualität:
  • Geeignete Datensätze (repräsentativ, relevant, fehlerarm), dokumentierte Herkunft, Bias‑Kontrollen.
  • Klare Regeln für Datenerhebung, ‑anreicherung, ‑bereinigung und Zugriffsrechte.
• Technische Dokumentation und Konformitätsunterlagen:
  • Zweck, Systemarchitektur, Trainings-/Validierungsdaten, Leistungskennzahlen, Einschränkungen, Kontrollen.
  • Nachweis der Konformitätsbewertung und anwendbarer harmonisierter Normen.
• Transparenz und Information:
  • An Deployers/Endnutzer gerichtete Informationen für eine sichere Nutzung (Bedienungsanleitung, Einsatzgrenzen).
  • Kennzeichnungspflichten, z. B. bei KI‑Interaktion oder synthetischen Inhalten („Deepfake“-Label).
• Menschliche Aufsicht (Human Oversight):
  • Gestaltung von Prozessen, die wirksame Kontrolle ermöglichen (Vier‑Augen‑Prinzip, Eskalationen, Override).
  • Schulung der Aufsichtspersonen, klare Verantwortlichkeiten.
• Genauigkeit, Robustheit, Cybersecurity:
  • Performanceziele, Stresstests, Schutz gegen adversariale Angriffe und Model Drift.
• Logging und Protokollierung:
  • Ereignisprotokolle für Nachvollziehbarkeit, Fehlersuche und aufsichtsrechtliche Anfragen.
• Post‑Market‑Monitoring und Incident‑Management:
  • Systematisches Erfassen von Performance im Betrieb, Feedbackkanäle, Korrekturmaßnahmen.
  • Meldung schwerwiegender Vorfälle an Behörden nach den gesetzlichen Vorgaben.
• Lieferanten- und Drittparteiensteuerung:
  • Due Diligence, SLAs, Audit‑Rechte, Änderungsmanagement, SBOM/Model Cards, rechtliche Kettenverantwortung.
• Pflichten für Deployer:
  • Nutzung nach Anbieter‑Anleitung, Zweckbindung, relevante und qualitätsgesicherte Inputdaten.
  • Geeignete menschliche Aufsicht im Einsatzkontext; Wahrung von Grundrechten/Interessenausgleich.
  • Wo anwendbar: notwendige Folgenabschätzungen (z. B. Datenschutz‑DPIA, ggf. grundrechtsbezogene Bewertungen im konkreten Kontext).

GPAI‑Spezifika:

• Anbieter von GPAI‑Modellen müssen u. a. technische Dokumentation, Urheberrechts‑Compliance/Trainingstransparenz, Evaluierungen und Risikominderungen sicherstellen. Für besonders leistungsfähige („systemische“) Modelle gelten erweiterte Pflichten.
• Deployers, die GPAI nutzen, müssen über Zweckbindung, geeignete Kontrollen und Kennzeichnung synthetischer Inhalte sicherstellen, insbesondere bei Endnutzerinteraktionen.

Verzahnung mit ISO/IEC 42001, GDPR und bestehenden Frameworks

• EU AI Act definiert das „Was“ (Pflichten, Ergebnisse); ISO/IEC 42001 liefert das „Wie“ (Managementsystem für KI).
  • Policy und Governance: AI‑Leitlinie, Rollen (Owner, Risk, Compliance), Gremien (AI Board).
  • Lebenszyklus‑Prozesse: Use‑Case‑Intake, Risikobewertung, Design Controls, MLOps, Change Management.
  • Messung und Verbesserung: KPIs, Audits, Korrekturmaßnahmen, Dokumentenlenkung.
• GDPR/DSG/DSGVO:
  • Rechtsgrundlage, Datenminimierung, Zweckbindung, Betroffenenrechte, DPIA bei hohem Risiko für Personenrechte.
  • Privacy‑by‑Design/-Default ergänzen AI‑by‑Design: Datenqualität ≠ Rechtsgrundlage – beides ist nötig.
• Informationssicherheit (ISO/IEC 27001) und Datenschutzmanagement (ISO/IEC 27701):
  • Stützen Logging, Zugriffskontrollen, Vorfallmanagement, Lieferantensicherheit.
• Risikomanagement (ISO 31000) und Modellrisiko (z. B. EBA‑Leitlinien im Finanzsektor):
  • Integrieren AI‑spezifische Risiken in Ihr Enterprise Risk Management.

Ergebnis: Ein einheitliches, auditierbares Governance‑System statt paralleler Pflichteninseln.

Readiness‑Checkliste: Wo stehen Sie heute?

• Inventarisieren:
  • Vollständiges AI‑/Analytics‑Portfolio inkl. SaaS, Shadow IT, Pilotprojekte, GPAI‑Nutzung.
  • Datenflüsse, Trainings‑/Echtzeitdaten, Drittlandübermittlungen.
• Rollen und Verantwortlichkeiten:
  • Klare Zuordnung Provider/Deployer pro Use Case, Nennung der Prozess‑ und Datenverantwortlichen.
• Risikoklassifizierung:
  • Zuordnung zu Verbot/hoch/limitiert/minimal; Abgleich mit Annex‑III‑Tatbeständen und Produktsicherheitsrecht.
• Gap‑Analyse:
  • Gegen EU AI Act‑Pflichten, ISO/IEC 42001‑Kontrollen, GDPR/ISO‑27001: Wo fehlen Prozesse, Kontrollen, Nachweise?
• Daten-Governance:
  • Datensatzkataloge, Herkunft, Qualität, Bias‑Analysen, Einwilligungen/Rechtsgrundlagen, Löschkonzepte.
• Technische Basis:
  • MLOps‑Fähigkeiten (Versionierung, Reproduzierbarkeit), Testframeworks, Monitoring, Security‑Hardening.
• Dokumentation:
  • Systemdossiers, Model Cards, Bedienungsanleitungen, Risikoberichte, Audit‑Trails.
• Human Oversight und Training:
  • Entscheidungsleitplanken, Eskalationen, Schulung der Anwendenden und der Aufsicht.
• Lieferantenmanagement:
  • Vertragsanhänge (Compliance, Audit, Änderungspflichten), Due Diligence, Zertifikate/Nachweise, Sub‑Sub‑Vendor‑Transparenz.
• Betriebsrat/Interessenvertretung (DACH‑spezifisch):
  • Mitbestimmung frühzeitig integrieren, Folgen für Beschäftigte bewerten.
• Kommunikations- und Incident‑Prozesse:
  • Meldewege, Krisenkommunikation, Behördenkontakte, Verantwortliche.

Typische Fallstricke in der DACH‑Praxis

• Drittanbieter‑Blindflug:
  • Fehlende Model Cards, unklare Trainingsdatenherkunft, keine Audit‑Rechte – speziell bei US‑Hyperscalern/GPAI‑Anbietern.
• „PoC ist rechtsfrei“-Irrtum:
  • Auch Piloten brauchen Risikobewertung, Datenschutzprüfung und Transparenzmaßnahmen.
• Vermischung von Rollen:
  • Interne Anpassungen verwandeln Sie faktisch in einen Provider mit zusätzlichen Pflichten.
• Unterschätzte Datenabhängigkeiten:
  • Schrems‑II‑Risiken bei Datentransfers, fehlende Lösch-/Korrekturroutinen, mangelnde Datenabdeckung für Minderheiten → Bias.
• Lückenhaftes Logging:
  • Keine reproduzierbaren Ergebnisse bei Abweichungen oder Beschwerden; mangelnde Beweisführung.
• Sektorale Doppelregulierung:
  • Finance: BaFin/EBA‑Vorgaben zu Modellrisiko und Outsourcing.
  • Healthcare: MDR/IVDR‑Konformität inkl. klinischer Bewertung.
  • Manufacturing: Maschinenverordnung/Produktsicherheit und funktionale Sicherheit (z. B. IEC 61508, ISO 13849).
• Betriebsrat und Arbeitsrecht:
  • Späte Einbindung führt zu Verzögerungen oder Stopp von Implementierungen (z. B. bei Mitarbeiter‑Monitoring).
• Unklare Kennzeichnung:
  • Fehlende KI‑Hinweise bei Chatbots/Generierung; fehlende Deepfake‑Labels im Marketing.
• Vendor‑Lock‑in ohne Exit‑Plan:
  • Keine Portabilität, fehlende Notfallstrategie bei Anbieterwechsel oder Modell‑Degradation.

Gestaffelter Umsetzungsfahrplan: Von Compliance zu Business‑Impact

• Phase 0–3 Monate: Orientierung und Inventar
  • Governance‑Kickoff (AI Policy, Rollen, AI Board), Use‑Case‑Inventar, erste Risikoklassifizierung.
  • Quick‑Wins bei Transparenz (Chatbot‑Hinweise, Content‑Labeling), Stop‑Kriterien für verbotene Praktiken.
• Phase 3–6 Monate: Design und Kontrollen
  • ISO/IEC‑42001‑AIMS initial aufsetzen: Prozesse, Vorlagen, KPIs.
  • Daten‑ und Modell‑Kontrollen definieren (Bias‑Tests, Qualitätskriterien, Security).
  • Lieferantenverträge nachschärfen (Audit‑Klauseln, Compliance‑Anhänge, Incident‑Pflichten).
• Phase 6–12 Monate: Implementierung und Piloten unter Governance
  • MLOps/Tooling einführen (Versionierung, CI/CD, Monitoring), Dokumentationspakete standardisieren.
  • Schulungen für Entwicklung, Fachbereiche, Aufsicht; Betriebsratsvereinbarungen verhandeln.
  • GPAI‑Nutzung absichern (Policy, Prompt‑Guardrails, Content‑Labeling, Urheberrechts‑Checks).
• Phase 12–18 Monate: Konformitätsnachweise und Skalierung
  • Interne Audits/Assurance, Test‑/Validierungsberichte, Post‑Market‑Monitoring etablieren.
  • Sektorale Anforderungen integrieren (BaFin/MDR/Machinery).
  • Performance‑Tuning mit kontrolliertem Drift‑Management.
• Phase 18–36 Monate: Reifegrad, externe Prüfbereitschaft
  • Reifegradsteigerung des AIMS, kontinuierliche Verbesserung, unabhängige Reviews.
  • Portfolio‑Skalierung nur nach „Governance‑Gate“; konsolidierte Dashboards für Exekutive und Aufsicht.
  • Vorbereitung auf behördliche Anfragen/Marktüberwachung, Incident‑Response‑Drills.

Leitidee: Compliance als Enabler – jedes Kontrollartefakt (Datenkatalog, Model Card, KPI) schafft zugleich Effizienz, Qualität und Vertrauen in den Betrieb.

Praxisleitfaden für die vier Branchen

• Manufacturing:
  • Safety‑by‑Design mit Hazard‑Analysen, Validierung gegen Edge‑Cases, funktionale Sicherheit.
  • Lieferkette: OEM‑/Tier‑1‑Nachweise, Software‑Stückliste, Update‑Prozesse, Werksabnahme mit AI‑Tests.
• Finance:
  • Modellrisikopolitik, Challenger‑Modelle, Fairness‑Metriken (z. B. Equal Opportunity), Erklärbarkeit für Kundendienst.
  • Dokumentation für Aufsicht (BaFin/EBA), Outsourcing‑Register, Datenherkunfts‑Nachweise.
• Healthcare:
  • Klinische Evaluierung, HCP‑Training, Fail‑Safe‑Prozesse bei Unsicherheit, Audit‑Trails pro Fall.
  • Interoperabilität (IHE/HL7), Datenschutz auf hohem Schutzniveau, Zweckbindung klinischer Daten.
• Retail:
  • Betrugsprävention mit human‑in‑the‑loop bei Ablehnungen; klare Kundenkommunikation und Widerspruchswege.
  • Personal‑Use‑Cases nur mit Mitbestimmung, Bias‑Kontrollen bei Recruiting‑Screening, transparente Preisalgorithmen.

Lieferantensteuerung und GPAI: So behalten Sie die Kontrolle

• Due Diligence‑Paket anfordern:
  • Model Card/Technical Sheet, Trainingsdatenquellen (aggregiert), Evaluierungsberichte, Robustheits‑/Bias‑Tests.
• Vertragliche Absicherung:
  • Compliance‑Zusicherungen, Änderungs‑/Patch‑Pflichten, Sicherheitsstandards, Support‑SLAs, Audit‑/Pen‑Test‑Rechte.
• Betriebsintegration:
  • Eingangsprüfung neuer Releases, Regression‑Tests, Canary‑Rollouts, Monitoring‑Alerts.
• GPAI‑Nutzung absichern:
  • Output‑Filter/Moderation, Prompt‑Management, Verbot sensibler Daten im Prompt, Urheberrechts‑Screening.
  • Kennzeichnung generierter Inhalte; Governance für Retrieval‑Augmentation (Quellenqualität, Aktualität).

Nächste Schritte: Schlank starten, wirksam skalieren

• Starten Sie mit einer fokussierten Risiko‑ und Governance‑Baselining‑Übung für Ihr Top‑5‑Use‑Case‑Portfolio.
• Definieren Sie ein leichtgewichtiges, aber auditierbares AIMS gemäß ISO/IEC 42001 – skalierbar auf weitere Use Cases.
• Schließen Sie Ihre größten Lücken zuerst: Datenqualität/Bias‑Kontrollen, Logging, Lieferantenverträge, Transparenz.
• Verankern Sie Human Oversight dort, wo Entscheidungen Menschen erheblich betreffen.
• Bauen Sie Post‑Market‑Monitoring und Incident‑Routinen auf, bevor Sie breiter ausrollen.

Wie Unterstützung aussehen kann: Ein initiales Assessment mit Strategie‑Workshop, Risikoklassifizierung und Gap‑Analyse legt in wenigen Wochen die Basis; anschließende Projektpakete adressieren Implementierung, Training und Audit‑Vorbereitung mit klaren Meilensteinen und transparenten, wettbewerbsfähigen Preisen. Ziel ist, Compliance zu sichern, Betriebsabläufe zu optimieren und eine nachhaltige, messbare Wertschöpfung aus KI zu erreichen.