Wann Hochrisiko-KI-Systeme gelten und was als Naechstes zu tun ist

Hochrisiko-KI-Systeme gelten, wenn ein SaaS-Team ein KI-System baut, verkauft, einbettet, konfiguriert oder nutzt, das in eine der High-risk-Routen des EU AI Act faellt. Entscheidend ist nicht, ob das Unternehmen irgendwo KI nutzt. Entscheidend ist, ob ein konkretes System mit einem konkreten Zweck in einem regulierten Produktkontext oder in einem sensiblen Annex-III-Use-Case steht.

Fuer SaaS-Teams haengt die Antwort oft von Produktzweck, Kundenkonfiguration, betroffenen Personen, Datenkategorien, Vendor-Rolle, Human Review, Markt und Output-Nutzung ab. Ein Feature kann in einem Workflow normal aussehen und in einem anderen sensibel werden.

Die zwei Hauptrouten

Die erste Route betrifft regulierte Produkte. Ein KI-System kann hochriskant sein, wenn es als Sicherheitskomponente eines Produkts vorgesehen ist oder selbst ein Produkt ist, das unter Annex-I-Harmonisierungsvorschriften faellt und eine Drittbewertung benoetigt. Das ist wichtig fuer SaaS in Medical Devices, Machinery, Transport, Aviation, Radio Equipment, Toys, Industrial Systems oder Robotics.

Die zweite Route ist Annex III. Sie betrifft Bereiche wie Biometrics, Critical Infrastructure, Education, Employment, Worker Management, Essential Services, Law Enforcement, Migration, Justice und Democratic Processes. Fuer SaaS ist diese Route oft naeher: Hiring, Candidate Ranking, Worker Evaluation, Student Assessment, Credit Eligibility oder Access Decisions koennen tiefere Pruefung ausloesen.

Wann ein Review starten sollte

Starte High-risk Review, wenn ein KI-System Menschen in einem folgenreichen Kontext beeinflussen kann. Typische Trigger sind ein neues AI Feature, neuer Vendor, neuer Zweck, neue Kundenkonfiguration, Nutzung in HR, Education, Healthcare, Essential Services, Credit oder Insurance, Biometrie, automatisiertes Ranking, weniger Human Review, EU-Markteintritt oder Kundenfragen zum AI Act.

Kundenkonfiguration ist besonders wichtig. Eine horizontale Plattform kann im Default unkritisch sein, aber sensibel werden, wenn Kunden damit Bewerber, Mitarbeitende, Studenten, Anspruchsberechtigung oder Public-Sector-Entscheidungen bewerten.

Wann es moeglicherweise nicht gilt

Nicht jedes AI-enabled SaaS Feature ist high-risk. Ein interner Drafting Assistant, Code Helper, Analytics Assistant, Support Summary oder Knowledge Search Tool kann ausserhalb der High-risk-Route liegen, wenn es nicht in einem Annex-III-Kontext arbeitet, keine Sicherheitskomponente eines regulierten Produkts ist und keine folgenreichen Personenentscheidungen unterstuetzt.

Das Feature bleibt trotzdem nicht compliance-frei. Es kann AI Inventory, Privacy Review, Security Review, Vendor Assessment, Prohibited-practice Screening, Customer Disclosure oder normale AI Governance brauchen.

Was zuerst zu tun ist

Beginne mit einem kurzen Intake: Systemname, Owner, Business Purpose, User Journey, betroffene Personen, Geografie, Datenkategorien, Modell oder Vendor, AI-Act-Rollenhypothese, Output, Human Review, Kundenkonfiguration und Bezug zu regulierten Produkten oder Annex III.

Dann route den Fall. Klare No-high-risk-Faelle gehen in normale Governance. Klare Kandidaten gehen in tiefere Legal- und Compliance-Pruefung. Unklare Faelle erhalten Reviewer, Deadline und Mindest-Evidenz.

Evidenz, die bleiben sollte

Halte AI Inventory, Intake, Produkt- oder Vendor-Beschreibung, Data Flow, Analyse betroffener Personen, Intended Purpose, Annex-I- oder Annex-III-Screening, Rollenbewertung, Klassifizierungsentscheidung, Reviewer, Datum, Rationale, Launch-Entscheidung, ausgeloeste Kontrollen und Re-Review-Trigger fest.

Bei internen Systemen gehoeren Architecture Notes, Model Documentation, Tests, Logging Design, Human Oversight und Monitoring Plan dazu. Bei Vendors: AI Documentation, Instructions for Use, vertragliche Zusagen, Security Answers, Audit- oder Certification-Materialien und Rollenaussagen.

Typische SaaS-Szenarien

Ein AI Support Assistant, der interne Tickets zusammenfasst, kann ausserhalb der High-risk-Route liegen, wenn Mitarbeitende den Output pruefen und keine Personen gerankt, bewertet oder von Zugang ausgeschlossen werden.

Ein HR SaaS Feature, das Bewerbungen filtert, Kandidaten rankt, Performance bewertet oder Kuendigungsentscheidungen unterstuetzt, ist anders. Employment und Worker Management sind Annex-III-Bereiche und brauchen tiefere Pruefung.

Ein Healthcare Workflow fuer Triage, Diagnostics oder Medical-device Functionality kann sowohl Annex III als auch regulierte Produktfragen ausloesen. Hier muessen Rollen und Conformity-Assessment-Fragen frueh geklaert werden.

FAQ

Was ist der praktische Zweck?

Der Zweck ist, Systeme zu erkennen, die einen strengeren Governance-Pfad, staerkere Evidenz, Lifecycle Controls und klare Ownership brauchen.

Wann gilt es fuer SaaS-Teams?

Wenn ein Team KI als Sicherheitskomponente eines regulierten Produkts, als reguliertes Produkt oder fuer Annex-III-Use-Cases wie Employment, Education, Essential Services, Biometrics, Law Enforcement, Migration, Justice oder Democratic Processes baut, verkauft, einbettet, konfiguriert oder nutzt.

Was sollte zuerst dokumentiert werden?

AI Inventory, High-risk Intake, Role Analysis, Intended Purpose, Analyse betroffener Personen, Klassifizierungsentscheidung, Owner, Evidenzort, Launch Gate und Re-Review-Trigger.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidance for providers and deployers of high-risk AI systems.
• European Commission AI Act FAQ.
• AI Act Service Desk guidance on Annex III high-risk AI systems.