Hochrisiko-KI-Systeme operativ umsetzen, ohne Produktlieferung zu bremsen

Hochrisiko-KI-Systeme sollten als Produkt-Workflow behandelt werden, nicht als spaete Rechtsfrage. Das Ziel ist, den KI-Anwendungsfall frueh zu erkennen, eine moegliche Hochrisiko-Route zu pruefen, verantwortliche Owner zu benennen, passende Controls auszuloesen und Evidenz dort abzulegen, wo Produkt, Security, Datenschutz, Compliance und Kundenteams sie nutzen koennen.

Nach dem EU AI Act kann Hochrisiko-Status entstehen, wenn ein KI-System mit Produktsicherheit in regulierten Produkten verbunden ist oder fuer einen sensiblen Anwendungsfall aus Annex III bestimmt ist. Die Entwurfsleitlinien der Kommission vom Mai 2026 helfen bei dieser Einordnung, ersetzen aber nicht die Verordnung. Fuer SaaS-Teams ist die operative Antwort klar: Der Review muss vor Verkauf, Konfiguration und Launch in den Delivery-Prozess eingebaut werden.

Warum das praktisch wichtig ist

Hochrisiko-KI veraendert, was das Team vor einem Launch wissen muss: Zweck, betroffene Personen, Datenkategorien, Modell oder Vendor, Rolle des Unternehmens, menschliche Aufsicht, Nutzungsanweisungen, Logging, Monitoring, Incident-Prozess, Kundenkonfiguration und Evidenz.

Die Pflichten koennen Risikomanagement, Data Governance, technische Dokumentation, Aufzeichnungen, Transparenz, menschliche Aufsicht, Genauigkeit, Robustheit, Cybersecurity, Qualitaetsmanagement, Konformitaetsbewertung, Registrierung, Monitoring und Korrekturmassnahmen betreffen. Ohne Workflow werden diese Punkte erst sichtbar, wenn ein Kunde, Auditor oder Regulator danach fragt.

Mit einem Intake-Screen starten

Der Intake muss kurz genug sein, damit Teams ihn nutzen. Er soll keine juristische Endentscheidung verlangen, sondern Fakten sammeln: Systemname, Owner, Zweck, User Journey, betroffene Personen, Geografie, Daten, Modell oder Vendor, Rolle als Anbieter oder Betreiber, Output, menschliche Nutzung des Outputs und Kundenkonfiguration.

Danach folgen zwei Fragen. Erstens: Koennte das System Sicherheitskomponente eines regulierten Produkts sein oder selbst ein reguliertes Produkt darstellen? Das ist relevant fuer Medizinprodukte, Maschinen, Transport, Luftfahrt, Funkanlagen, Spielzeug, Aufzuege und aehnliche Umgebungen. Zweitens: Koennte der Use Case in einen Annex-III-Bereich fallen, etwa Beschaeftigung, Bildung, essenzielle Dienste, Kreditwuerdigkeit, Versicherung, Biometrie, kritische Infrastruktur, Migration, Justiz oder demokratische Prozesse?

Wenn keine Route plausibel ist, wird die Begruendung dokumentiert und der normale KI-, Datenschutz-, Security- und Vendor-Review laeuft weiter. Wenn eine Route plausibel ist, braucht der Fall eine tiefere Pruefung vor Launch oder Kundenfreischaltung.

Trigger und Lanes definieren

Hochrisiko-Review sollte durch Ereignisse ausgeloest werden, die ohnehin fuer Delivery zaehlen: neues KI-Feature, neuer Zweck, neues Modell oder Vendor, Kundendaten im KI-Workflow, Output mit Einfluss auf Personen, weniger menschliche Pruefung, sensible Kundenkonfiguration, EU-Markteintritt oder Buyer-Fragen, die mit vorhandener Evidenz nicht beantwortet werden koennen.

Nutze drei Lanes. Lane eins: kein Hochrisiko-Signal, mit kurzer Begruendung und Review-Trigger. Lane zwei: unsicher oder sensibel, mit benanntem Reviewer, Frist und Launch-Sperre bis zur Klaerung. Lane drei: wahrscheinlich Hochrisiko, mit vertieftem Legal-, Produkt-, Security-, Datenschutz- und Compliance-Work.

Owner und Controls

Der Product Owner verantwortet Zweck, Konfiguration, Scope und Kundenversprechen. Engineering verantwortet Architektur, Logging, Versionierung, Fallbacks und technische Controls. Legal oder Compliance verantwortet Klassifizierungslogik, Quellen, Kundenaussagen und Review-Trigger. Security oder Risk verantwortet Vendor-Evidenz, Monitoring, Incident-Eskalation, Zugriff und Resilienz.

Pflichten muessen in Produkt-Controls uebersetzt werden. Risikomanagement wird zu einem Feature-Risikorecord. Data Governance wird zu Regeln fuer Trainings-, Test-, Eingabe-, Kunden- und Feedbackdaten. Technische Dokumentation wird zu einem gepflegten Evidenzordner. Transparenz wird zu Kunden- und internen Anweisungen. Menschliche Aufsicht wird zu einem echten Review-Prozess mit Eingriffsrechten. Monitoring wird zu Metriken, Ownern und Review-Kadenz.

Evidenz nahe am Delivery-Prozess halten

Evidenz gehoert nicht in ein separates Archiv, das erst beim Audit geoeffnet wird. Nutze Produkt-Tickets fuer Intake, Architekturaufzeichnungen fuer Technik, Vendor Records fuer Drittanbieter, Privacy Reviews fuer Daten und betroffene Personen, Security Reviews fuer Controls und Release-Checklisten fuer Gates.

Mindestens sollten Intake, Klassifizierungsentscheidung, Rollenbewertung, Quellen, Reviewer, Datum, Begruendung, ausgeloeste Controls, offene Fragen, Freigaben, Kundenlimits, Monitoring-Owner, Incident-Pfad und naechster Review-Trigger vorhanden sein.

FAQ

Was sollten Teams ueber Hochrisiko-KI-Systeme verstehen?

Sie sollten verstehen, dass Hochrisiko-KI eine operative Frage und eine rechtliche Klassifizierungsfrage ist. Der Workflow identifiziert den Use Case, routet ihn, loest Controls aus und haelt Evidenz aktuell.

Muss jedes KI-Feature als Hochrisiko behandelt werden?

Nein. Viele KI-gestuetzte SaaS-Funktionen werden nicht hochriskant sein. Das Team sollte trotzdem begruenden, warum die Hochrisiko-Route nicht ausgeloest wird.

Wann sollte ein Release pausieren?

Wenn der Use Case Personen in einem Annex-III-Bereich betreffen kann, mit Produktsicherheit verbunden ist, keine Evidenz hat, keinen Owner hat oder von einer ungeprueften Kundenkonfiguration abhaengt.

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.
• European Commission May 2026 update on AI Act implementation timing.
• European Commission report on the review of prohibitions and high-risk AI.