Für KI-Anbieter, Produktteams und Unternehmen, die KI-Systeme in Europa einsetzen, wird der EU AI Act 2026 operativ konkret. Konformitätsbewertungen müssen vorbereitet, technische Dokumentation muss fertiggestellt, Qualitätsmanagementsysteme müssen funktionieren, Logging und menschliche Aufsicht müssen nachweisbar sein. Diese Arbeit lässt sich nicht in den letzten Wochen vor einer Frist improvisieren.
Der 2. August 2026 ist für viele Hochrisiko-Pflichten der zentrale Stichtag. Auch wenn politische Vorschläge, Übergangsfristen oder Auslegungsfragen weiter diskutiert werden, sollten Unternehmen den Termin operativ ernst nehmen. Wer erst kurz vor Ablauf beginnt, riskiert Engpässe bei Fachberatung, notified bodies, interner Umsetzung und Lieferantennachweisen.
Diese Checkliste ist für AI Leads, Compliance-Verantwortliche, Engineering Manager und Gründer gedacht, die KI-Systeme für den europäischen Markt entwickeln oder einkaufen. Sie ersetzt keine Rechtsberatung, übersetzt die Anforderungen aber in praktische Arbeitspakete.
1. Prüfen Sie zuerst die Risikokategorie
Der wichtigste Schritt ist die Klassifizierung. Nicht jedes KI-System ist ein Hochrisiko-System. Viele interne Assistenztools, Marketing-Workflows oder einfache Automatisierungen fallen nicht automatisch in die strengste Kategorie. Hochrisiko kann jedoch relevant werden, wenn KI in Bereichen wie Beschäftigung, Bildung, kritischer Infrastruktur, Kreditwürdigkeit, Strafverfolgung, Migration, Medizin oder sicherheitsrelevanten Produkten eingesetzt wird.
Die Klassifizierung sollte dokumentiert werden — auch dann, wenn das Ergebnis lautet, dass das System nicht hochriskant ist. Für Beschaffung und Audits ist oft entscheidend, dass die Entscheidung nachvollziehbar getroffen wurde: Zweck des Systems, Nutzer, betroffene Personen, Datenarten, mögliche Schäden und bestehende menschliche Kontrollen.
2. Rollen klären: Provider, Deployer oder beides?
Der EU AI Act unterscheidet zwischen verschiedenen Rollen. Ein Provider entwickelt oder stellt ein KI-System bereit. Ein Deployer setzt es in eigenem Namen ein. In der Praxis können Unternehmen mehrere Rollen gleichzeitig haben, etwa wenn sie ein Foundation Model integrieren, mit eigenen Daten anpassen und als Produktfunktion ausrollen.
Diese Rollenfrage ist nicht formal. Sie entscheidet, wer technische Dokumentation liefern muss, wer Monitoring betreibt, wer Nutzer informiert, wer Datenqualität nachweist und wer bei Vorfällen reagiert. Teams sollten daher früh eine Rollenmatrix erstellen: internes Team, Modellanbieter, Cloud-Anbieter, Integrator, Kunde, Endnutzer und Subprozessoren.
3. Risikomanagementsystem aufbauen
Hochrisiko-Systeme benötigen ein laufendes Risikomanagement. Das bedeutet nicht nur eine einmalige Risikoliste. Risiken müssen identifiziert, bewertet, mitigiert, getestet und überwacht werden. Dazu gehören Fehlklassifikationen, Bias, Robustheitsprobleme, Datenverschiebung, Missbrauch, Cyberrisiken und unerwartetes Nutzerverhalten.
Ein belastbares Risikomanagement verbindet technische Tests mit menschlicher Bewertung. Für LLM- und Computer-Vision-Systeme gehören dazu Testsets, Red Teaming, Fehlertaxonomien, Szenariotests, Human Review, Grenzfallanalysen und klare Eskalationsregeln.
4. Daten-Governance dokumentieren
Daten-Governance ist eine der praktisch schwierigsten Anforderungen. Teams müssen zeigen können, welche Daten für Training, Validierung und Test verwendet wurden, woher sie stammen, welche Qualität sie haben, wie sie annotiert wurden und welche Maßnahmen gegen Verzerrungen oder Fehler getroffen wurden.
Für viele KI-Systeme ist nicht das Modell selbst der schwächste Punkt, sondern das Datenset. Unklare Labels, schlecht dokumentierte Annotation, unausgewogene Klassen oder fehlende Edge Cases führen zu instabilen Systemen. Deshalb sollten Annotation Guidelines, QA-Prozesse, Inter-Annotator Agreement, Sampling-Strategie und Datenversionen sauber dokumentiert werden.
5. Technische Dokumentation vorbereiten
Technische Dokumentation darf nicht erst am Ende geschrieben werden. Sie sollte parallel zur Entwicklung entstehen. Relevante Inhalte sind Zweckbestimmung, Systemarchitektur, Modelltyp, Datenquellen, Trainings- und Evaluationsprozess, Performance-Metriken, bekannte Grenzen, Risiken, Human-Oversight-Mechanismen, Cybersecurity-Maßnahmen und Monitoring-Konzept.
Für Teams ist es hilfreich, ein lebendes Dokument oder ein internes Compliance-Repository zu führen. Jede Modellversion, jedes relevante Datenset, jede Evaluationsrunde und jede Risikomaßnahme sollte auffindbar bleiben. Ohne Versionierung wird spätere Nachvollziehbarkeit sehr teuer.
6. Logging und Record-Keeping definieren
Viele Anforderungen hängen davon ab, ob Entscheidungen, Eingaben, Ausgaben und Systemereignisse nachvollziehbar sind. Logging muss jedoch mit Datenschutz, Sicherheit und Datenminimierung abgestimmt werden. Nicht alles sollte unbegrenzt gespeichert werden, aber kritische Entscheidungen müssen rekonstruierbar sein.
Ein gutes Logging-Konzept beantwortet: Welche Events werden gespeichert? Welche Prompts, Bilder, Metadaten oder Entscheidungen sind enthalten? Wer hat Zugriff? Wie lange werden Logs aufbewahrt? Wie werden personenbezogene Daten geschützt? Wie wird ein Vorfall untersucht?
7. Transparenz und Nutzerinformationen prüfen
Nutzer, Kunden oder betroffene Personen müssen je nach System wissen, dass KI eingesetzt wird, welche Funktion sie hat und welche Grenzen bestehen. Für Hochrisiko-Systeme sind Gebrauchsanweisungen, Leistungsgrenzen, vorgesehene Nutzung und menschliche Kontrollmöglichkeiten besonders wichtig.
Transparenz ist nicht nur ein Rechtstext. Sie muss produktseitig umgesetzt werden: UI-Hinweise, Dokumentation, Schulung, Warnungen bei unsicheren Ergebnissen, Erklärungen für Reviewer und klare Verantwortlichkeiten.
8. Menschliche Aufsicht operationalisieren
Human Oversight bedeutet nicht, irgendwo einen Menschen „in der Schleife“ zu erwähnen. Der Mensch muss die richtigen Informationen, die richtige Autorität und genug Zeit haben, um sinnvoll einzugreifen. Ein Reviewer, der nur automatisierte Entscheidungen abnickt, ist keine wirksame Aufsicht.
Teams sollten definieren, wann menschliche Freigabe nötig ist, welche Fälle eskaliert werden, welche Schwellenwerte gelten, welche Trainings Reviewer erhalten und wie ihre Entscheidungen dokumentiert werden. Bei LLM-Systemen kann das beispielsweise für Sicherheitsfälle, regulierte Antworten, Halluzinationsrisiken oder Kundendaten gelten.
9. Genauigkeit, Robustheit und Cybersicherheit nachweisen
Leistungsmetriken müssen zur Aufgabe passen. Für Klassifikation reichen Accuracy-Werte oft nicht aus. Teams sollten Precision, Recall, F1, Konfusionsmatrizen, Fehlerklassen, Subgruppenanalysen und Edge-Case-Performance betrachten. Für LLMs kommen Halluzinationsraten, RAG-Treue, Antwortqualität, Safety-Verhalten und Judge-/Human-Evaluation hinzu.
Robustheit bedeutet auch, dass das System mit realen Datenverteilungen, schlechten Eingaben, Angriffen, ungewöhnlichen Fällen und Systemänderungen umgehen kann. Cybersicherheit umfasst Modellmissbrauch, Prompt Injection, Datenexfiltration, Zugriffskontrollen und Lieferkettenrisiken.
10. Konformitätsbewertung und EU-Datenbank planen
Je nach System kann eine interne Kontrolle, eine Bewertung durch eine benannte Stelle oder ein sektorspezifischer Weg erforderlich sein. Teams sollten früh prüfen, welcher Pfad gilt, welche Nachweise benötigt werden und ob externe Kapazitäten rechtzeitig verfügbar sind. Für bestimmte Hochrisiko-Systeme kann außerdem eine Registrierung in der EU-Datenbank erforderlich sein.
Die praktische Empfehlung lautet: Arbeiten Sie rückwärts vom geplanten Marktzugang. Definieren Sie, welche Dokumente, Tests, Lieferantenerklärungen, Datenberichte und Freigaben bis wann vorliegen müssen. Compliance ist ein Projektplan, kein einzelner Rechtsreview.
12-Monats-Sequenz für KI-Teams
- Monat 1–2: Systeminventar, Rollen, Risikoklassifizierung und Gap-Analyse.
- Monat 3–4: Daten-Governance, Dokumentationsstruktur und Risikoregister aufsetzen.
- Monat 5–6: Evaluationssets, Human Review, Red Teaming und QA-Prozesse definieren.
- Monat 7–8: technische Dokumentation, Logging und Monitoring vervollständigen.
- Monat 9–10: interne Audits, Lieferantennachweise und Remediation.
- Monat 11–12: Konformitätsbewertung, Freigaben, Registrierung und Go-live-Vorbereitung.
Fazit
EU-AI-Act-Compliance ist 2026 keine reine Juristenaufgabe. Sie betrifft Daten, Engineering, Produkt, Security, Operations und Beschaffung. Die Teams, die früh beginnen, gewinnen nicht nur regulatorische Sicherheit. Sie bauen auch bessere KI-Systeme, weil Qualität, Dokumentation und menschliche Aufsicht von Anfang an mitgedacht werden.
DataVLab unterstützt europäische KI-Teams bei Datenannotation, Human Evaluation, LLM-Review, Red Teaming und QA-Prozessen für regulierte KI-Systeme. Wenn Sie Nachweise für Datenqualität oder menschliche Evaluation aufbauen müssen, kontaktieren Sie uns.
