Checkliste Hochrisiko-KI-Systeme fuer Gruender und Compliance Leads

Hochrisiko-KI-Systeme brauchen eine Checkliste, weil die Schwierigkeit selten im Begriff selbst liegt. Schwierig ist zu belegen, dass der richtige Use Case geprueft, die richtigen Owner benannt, die passenden Controls aktiviert und ausreichend Evidenz fuer Kunden, Board, Auditoren oder Regulatoren behalten wurde.

Nach dem EU AI Act kann Hochrisiko-Klassifizierung ueber regulierte Produkte oder ueber gelistete Use Cases in Annex III entstehen. Die Entwurfsleitlinien der Kommission vom Mai 2026 helfen bei der Anwendung von Article 6, aber die Verordnung bleibt die rechtliche Grundlage.

1. KI-Use-Case bestaetigen

Klaere zuerst, ob der Workflow wirklich ein KI-System nutzt. Begriffe wie Automation, Intelligence, Insight, Scoring, Empfehlung, Assistent oder Optimierung reichen nicht.

Erfasse Systemname, Produktbereich, Zweck, Modell oder Vendor, Output, Nutzer des Outputs und ob die Funktion kundenbezogen, mitarbeiterbezogen, intern oder eingebettet ist. Wenn kein KI-System vorliegt, dokumentiere das und schliesse die Hochrisiko-Pruefung.

2. AI-Act-Rolle bestimmen

Rollen koennen Provider, Deployer, Importeur, Distributor, Produkthersteller oder andere Akteure in der AI-Wertschoepfungskette sein. Ein SaaS-Unternehmen kann je nach Workflow verschiedene Rollen haben.

Dokumentiere, wer entwickelt, wer den Zweck kontrolliert, wer Konfiguration kontrolliert, wer das System in der EU bereitstellt und welche Vendor-Unterlagen oder Role Statements vorliegen.

3. Route fuer regulierte Produkte pruefen

Frage, ob das KI-System Sicherheitskomponente eines regulierten Produkts sein kann oder selbst ein reguliertes Produkt ist. Relevant sind unter anderem Medizinprodukte, Maschinen, Transport, Luftfahrt, Funkanlagen, Spielzeug, Aufzuege und Industrieumgebungen.

Pruefe auch, ob die KI sicherheitsrelevantes Verhalten, Diagnose, Monitoring, Steuerung, Warnung oder Fehlererkennung unterstuetzt und ob eine Dritt-Konformitaetsbewertung erforderlich sein kann.

4. Annex-III-Use-Cases pruefen

Annex III ist fuer SaaS oft die naheliegendere Route. Achte auf Biometrie, kritische Infrastruktur, Bildung, Recruiting, Beschaeftigung, Worker Management, Zugang zu essenziellen Diensten, Kreditwuerdigkeit, Versicherung, Justiz, Migration und demokratische Prozesse.

Klassifizierung folgt Zweck und konkreter Nutzung. Das gleiche Modell kann in einem internen Schreibassistenten geringeres Risiko haben und in einem Recruiting-Workflow hochriskant sein.

5. Kundenkonfiguration pruefen

SaaS ist oft konfigurierbar. Eine Standardfunktion kann sensibel werden, wenn Kunden damit Bewerber ranken, Mitarbeitende bewerten, Studierende beurteilen oder Zugang zu wichtigen Diensten beeinflussen.

Pruefe, ob Kunden Datenfelder, Kriterien, Schwellenwerte oder Labels waehlen koennen, ob sensible Workflows moeglich sind und ob es vor Aktivierung ein Review-Gate gibt.

6. Owner und Gates setzen

Benennen Sie Product Owner, Engineering Owner, Legal oder Compliance Owner, Security oder Risk Owner und einen customer-facing Owner fuer freigegebene Aussagen.

Eine fehlende Klassifizierung sollte Releases in sensiblen Domains blockieren. Eine wahrscheinliche Hochrisiko-Klassifizierung sollte vertiefte Pruefung und Launch-Bedingungen ausloesen.

7. Mindest-Evidenz festlegen

Behalte Intake, Systembeschreibung, Rollenbewertung, regulierte-Produkt-Pruefung, Annex-III-Pruefung, Zweckbeschreibung, Betroffenenanalyse, Datenfluss, Vendor-Dokumente, Klassifizierungsentscheidung, Reviewer, Datum, Begruendung, Quellen, Launch-Entscheidung, Controls und naechsten Review-Trigger.

Bei wahrscheinlichem Hochrisiko kommen Risk-Management-Record, Data-Governance-Entscheidungen, technische Dokumentation, Testing, Human-Oversight-Design, Logging, Monitoring, Incident-Pfad und Konformitaetsroute hinzu.

8. Controls in Produktarbeit uebersetzen

Risk Management wird ein Feature-Risikorecord. Data Governance wird Regeln fuer Trainings-, Test-, Eingabe-, Kunden- und Feedbackdaten. Technische Dokumentation wird ein Evidenzordner. Transparenz wird zu Kundenanweisungen. Human Oversight wird ein echter Review-Prozess. Monitoring wird zu Metriken mit Owner und Kadenz.

9. Entscheidung wieder oeffnen

Oeffne die Pruefung erneut, wenn Zweck, Modell, Vendor, Version, menschliche Review, Kundenkonfiguration, Markt, Datenkategorien, Monitoring-Ergebnisse, Leitlinien, Standards oder Risikoappetit sich aendern.

FAQ

Was sollten Teams verstehen?

Sie sollten verstehen, wann Hochrisiko-KI-Systeme anwendbar sein koennen, welche operativen Aenderungen folgen und welche Evidenz die Arbeit belegt.

Warum ist das praktisch wichtig?

Weil die Klassifizierung Produktdesign, Launch-Gates, Kundendokumentation, Vendor-Review, Monitoring, Incident Response und Audit-Evidenz beeinflussen kann.

Was ist der groesste Fehler?

Hochrisiko-KI als einmalige Rechtsauslegung zu behandeln statt als wiederholbaren Workflow mit Ownern, Triggern, Evidenz und Eskalation.

Quellen

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission draft guidelines on the classification of high-risk AI systems.
• European Commission AI Act FAQ on high-risk AI systems.
• European Commission guidance on AI Act standardisation.