Hochrisiko-KI-Systeme: Praktischer Leitfaden fur SaaS-Teams

Hochrisiko-KI-Systeme sind KI-Systeme, die nach dem EU AI Act in einen strengeren Compliance-Pfad fallen, weil ihr Zweck, Produktkontext oder Einfluss auf Gesundheit, Sicherheit oder Grundrechte dies auslost. Fur SaaS-Teams lautet die praktische Frage nicht nur, ob ein Produkt KI nutzt. Entscheidend ist, ob ein konkreter Use Case Sicherheitskomponente eines regulierten Produkts ist, selbst ein reguliertes Produkt ist oder fur einen in Annex III gelisteten Hochrisiko-Zweck bestimmt ist.

Wenn die Antwort moglicherweise ja lautet, braucht das Team einen strukturierten Workflow. Dieser Workflow erfasst System, Rolle, Zweck, betroffene Personen, Daten, Kundenkonfiguration, Vendor-Bezug, Evidenz, Controls, Owner und Launch Gate. Die Entscheidung darf nicht nur in einem Legal Memo leben; sie muss Produkt, Engineering, Security, Privacy, Compliance und Customer Teams steuern.

Die Draft Guidelines der European Commission vom Mai 2026 erklaren die aktuelle Auslegung zu Article 6 und liefern Beispiele. Sie sind Draft Guidance, daher bleibt der AI Act selbst die Quelle der rechtlichen Pflicht.

Warum das praktisch wichtig ist

Hochrisiko-Klassifizierung verandert den Aufwand. Sie kann Anforderungen an Risk Management, Data Governance, technische Dokumentation, Logging, Transparenz, Human Oversight, Accuracy, Robustness, Cybersecurity, Quality Management, Conformity Assessment, Registrierung, Monitoring und Incident Handling auslosen.

Der grosste operative Fehler ist Ambiguitat. Ein Team kann ein Scoring-, Ranking-, Filtering-, HR-, Education-, Healthcare- oder Access-Feature ausliefern, ohne die Hochrisiko-Frage sauber zu entscheiden. Wenn Procurement, Enterprise Security oder ein Customer Audit spater fragt, ist der Use Case oft schon in Vertragen und Roadmaps verankert.

Klassifizierung hilft, Arbeit zu routen. Ein Drafting Assistant braucht nicht denselben Prozess wie ein System, das Bewerber filtert. Ein internes Summary Tool ist anders als ein Kundenworkflow fur Kredit, Arbeit, Bildung oder Essential Services.

Die zwei Hauptrouten

Die erste Route betrifft regulierte Produkte. Ein KI-System kann Hochrisiko sein, wenn es als Sicherheitskomponente eines Produkts dient oder selbst ein Produkt ist, das unter Annex-I-Harmonisierungsvorschriften fallt, und eine Third-Party Conformity Assessment erforderlich ist. Das ist relevant fur SaaS in Medical Devices, Machinery, Transport, Aviation, Robotics, Industrial oder Infrastructure Umfeldern.

Die zweite Route betrifft Annex III. Dort stehen Bereiche wie Biometrics, Critical Infrastructure, Education, Employment, Worker Management, Essential Services, Law Enforcement, Migration, Justice und Democratic Processes. Die Analyse folgt dem Zweck und konkreten Einsatz, nicht dem Modellnamen.

Fur SaaS ist Annex III oft der haufigere Trigger: Hiring, Candidate Filtering, Worker Evaluation, Student Assessment, Creditworthiness, Insurance Risk, Biometric Identification oder Legal Decision Support brauchen tiefere Review.

Wann Review auslosen

Starten Sie Review bei neuen AI Features, neuen Modellen oder Vendors, neuem Zweck, neuer Kundenkonfiguration, Einsatz in HR, Education, Healthcare, Essential Services, Credit oder Insurance, biometrischer Verarbeitung, automatisiertem Ranking, weniger Human Review, EU-Markteintritt oder Customer Questions zu AI Act Exposure.

Vendor AI braucht dieselbe Disziplin. Begriffe wie Insight, Intelligence, Automation, Recommendation, Screening, Identity oder Safety beantworten die Klassifizierung nicht. Das Team muss wissen, was das System tut, wessen Daten es nutzt, wer betroffen ist, wie Outputs verwendet werden und welche Rolle der Kunde hat.

Praktischer Workflow

Beginnen Sie mit einem kurzen Intake: Systemname, Owner, Zweck, User Journey, betroffene Personen, Geografie, Datenkategorien, Modell oder Vendor, AI-Act-Rolle, Output, Human Review, Kundenkonfiguration und Annex-I- oder Annex-III-Bezug.

Dann routen Sie. Klare No-Red-Flag-Falle gehen in normale AI Classification, Privacy, Security und Vendor Review. Klare Hochrisiko-Kandidaten gehen vor Launch in tieferes Legal- und Compliance-Assessment. Unklare Falle gehen an einen benannten Reviewer mit Frist.

Bei wahrscheinlichen Hochrisiko-Systemen erweitern Sie die Evidenz: Risk Management, Data Governance, Technical Documentation, Logging, User Instructions, Human Oversight, Testing, Cybersecurity, Post-Market Monitoring, Incident Escalation, Vendor Evidence, Conformity Route und Kundendokumentation.

Evidenz und Ownership

Evidenz muss vier Fragen beantworten: Was wurde gepruft, warum wurde so klassifiziert, welche Controls folgten daraus und wann wird die Entscheidung erneut gepruft?

Bewahren Sie AI Inventory, Intake, Produkt- oder Vendor-Beschreibung, Data Flow, Analyse betroffener Personen, Intended Purpose, Screening, Role Analysis, Entscheidung, Reviewer, Datum, Begrundung, Quellen, Launch Decision, Controls und Re-Review-Trigger auf.

Product besitzt Zweck, Journey und Konfiguration. Engineering besitzt Architektur, Datenfluss, Logs und Testing. Security besitzt Vendor, Zugriff und Cybersecurity. Privacy besitzt Datenschutz und Data Minimisation. Legal und Compliance besitzen AI-Act-Auslegung, Role Analysis und Evidenzstandard. Leadership besitzt Risk Acceptance fur sensitive oder unklare Launches.

Haufige Fehler

Der erste Fehler ist, Hochrisiko als Markenlabel zu behandeln. Dasselbe Modell kann Low-Risk Drafting oder Hochrisiko-Employment Review unterstutzen. Der zweite Fehler ist, nur Vendor-Assurances zu nutzen. Der dritte ist, Human Review als automatische Losung zu sehen. Der vierte ist fehlendes Change Management, wenn Zweck, Daten, Geografie, Kunde, Modell oder Human Review sich andern.

FAQ

Was ist der praktische Zweck?

KI-Systeme erkennen, die vor Marktbereitstellung, Inbetriebnahme oder Nutzung in sensiblen Workflows einen strengeren Governance-Pfad, mehr Evidenz und Lifecycle Controls brauchen.

Wann gilt das fur SaaS-Teams?

Wenn ein Team KI als Sicherheitskomponente eines regulierten Produkts, als reguliertes Produkt oder fur Annex-III-Zwecke wie Arbeit, Bildung, Essential Services, Biometrics, Law Enforcement, Migration, Justice oder demokratische Prozesse baut, verkauft, einbettet, konfiguriert oder nutzt.

Was zuerst dokumentieren?

AI Inventory, Hochrisiko-Intake, Role Analysis, Intended Purpose, betroffene Personen, Classification Decision, Owner, Evidenzort und Launch Gate.

Sources

• 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.
• AI Act Service Desk guidance on high-risk AI in regulated products.