Haeufige Fehler bei Hochrisiko-KI-Systemen, die SaaS-Teams immer noch machen

Der haeufigste Fehler bei Hochrisiko-KI-Systemen ist, Klassifizierung als einmalige juristische Antwort zu behandeln. Ein Team fragt, ob ein Feature unter dem EU AI Act hochriskant ist, erhaelt eine erste Einschaetzung und legt das Ergebnis in einem Dokument ab, das Product, Engineering, Security, Sales und Customer Success kaum nutzen.

Das ist fragil. Die Analyse haengt von Zweck, Deployment-Kontext, Kundenkonfiguration, betroffenen Personen, Rollenverteilung und Nutzung des Outputs ab. Diese Fakten koennen sich aendern, wenn ein Produkt in einen neuen Markt geht, einen neuen Workflow erhaelt, andere Kunden bedient, ein Vendor-Modell integriert oder menschliche Pruefung reduziert.

Fehler 1: Beim Modell statt beim Use Case starten

Die Frage "Ist dieses Modell hochriskant?" greift zu kurz. Dieselbe Modellfamilie kann einen internen Schreibassistenten, eine Support-Zusammenfassung, ein Worker-Management-Tool oder ein Bewerber-Ranking unterstuetzen. Entscheidend sind Zweck und Kontext.

Beginne mit dem Use Case: Was macht das System? Wer ist betroffen? Rangiert, bewertet, filtert, empfiehlt, ueberwacht oder beeinflusst es Entscheidungen ueber natuerliche Personen? Beruehrt es Employment, Education, Essential Services, Biometrie, Healthcare, Credit, Insurance, Justice oder andere sensible Bereiche?

Fehler 2: Kundenkonfiguration ignorieren

SaaS-Produkte sind konfigurierbar. Ein Feature kann im Default harmlos wirken und in der realen Kundenumgebung sensibel werden. Ein allgemeines Automation-Tool kann relevant fuer Employment werden, wenn Kunden es zum Ranking von Kandidaten nutzen.

Dokumentiere daher nicht nur den geplanten Zweck, sondern erlaubte und verbotene Nutzungen, sensible Settings, kundenkontrollierte Prompts, Downstream-Aktionen, betroffene Gruppen und Eskalations-Trigger. Wo riskante Konfigurationen technisch verhindert werden koennen, sind Produktkontrollen oft staerker als Policy-Sprache.

Fehler 3: Vendor-Dokumentation als komplette Antwort behandeln

Vendor-Unterlagen sind wichtig, aber sie ersetzen nicht die eigene Analyse. Der Vendor kennt oft nicht eure Kundensegmente, vertraglichen Zusagen, Geografie, Human-Review-Modell oder nachgelagerte Entscheidungen.

Bewahre Model Cards, Systembeschreibungen, Instructions for Use, Security Answers, Datenverarbeitungsbedingungen und Vertragsaussagen auf. Ergaenze eine eigene Bewertung: wie ihr das System nutzt, wer sich darauf verlaesst, welche Kundenkonfigurationen moeglich sind, welche AI-Act-Rolle ihr erwartet und wann Re-Review noetig wird.

Fehler 4: Rollen nicht klaeren

High-risk Arbeit wird unklar, wenn niemand entscheidet, wer Provider, Deployer, Importer, Distributor, Product Manufacturer oder eine andere Partei ist. SaaS-Teams nehmen manchmal an, der Vendor besitze alles, weil das Modell extern ist, oder der Kunde besitze alles, weil er den Output nutzt.

Rollenanalyse gehoert als eigenes Feld in den Review-Record. Ist die Antwort unsicher, benenne die Unsicherheit und weise einen Legal- oder Compliance-Owner zu. Diese Analyse sollte mit Produktdokumentation, Kundeninstruktionen, Vendor Management und Launch Approval verbunden sein.

Fehler 5: Human Review als Heilmittel ansehen

Human Oversight ist wichtig, entfernt aber nicht automatisch die High-risk-Frage. Ein System kann sensibel bleiben, auch wenn ein Mensch den Output prueft.

Dokumentiere, wer prueft, welche Informationen sichtbar sind, ob Override moeglich ist, wie Overrides geloggt werden, welche Schulung erfolgt und was bei unerwartetem Systemverhalten passiert. Diese Details sind nuetzlicher als der Satz "human in the loop".

Fehler 6: Klassifizierung von Release Gates trennen

Eine korrekte Tabelle hilft wenig, wenn ein sensibles Feature ohne Evidenz, Kundendokumentation, Logging, Tests oder Monitoring live geht. Klassifizierung muss Release Gates speisen.

Verbinde den Workflow mit Product Intake, Architecture Review, Privacy Review, Vendor Onboarding, Security Review, Release Approval und Customer-facing Documentation. Fehlende Klassifizierung sollte AI-Features in sensiblen Bereichen blockieren, bis ein Owner und eine Entscheidung vorliegen.

Fehler 7: Evidenzqualitaet unterschaetzen

Ein Ergebnis ohne Evidenz ist schwach. Gute Evidenz umfasst AI Inventory, Intended Purpose, Analyse betroffener Personen, Data Flow, Rollenbewertung, Annex-I- oder Annex-III-Screening, Vendor Evidence, Human Oversight Design, Logging, Tests, Monitoring, Reviewer, Datum, Rationale und Re-Review-Trigger.

Speichere Evidenz dort, wo Arbeit passiert: Product Tickets, Architecture Records, Privacy Assessments, Vendor Records, Release Checklists und Trust-Center-Materialien sind oft stabiler als eine isolierte Tabelle.

Fehler 8: Aenderungen nach Launch vergessen

Eine Klassifizierung kann veralten, wenn Zweck, Daten, Geografie, Kundensegment, Vendor, Automatisierung oder Human Review wechseln. Setze Trigger im Voraus: neuer Zweck, neue betroffene Gruppen, neue Datenkategorien, mehr Automatisierung, weniger Review, neuer Vendor, neue Kunden-Use-Cases oder neue Guidance.

Was als Naechstes zu tun ist

Pruefe zuerst alle AI-Systeme, die bereits genutzt werden: Customer-facing Features, interne Tools, Vendor-Produkte, Pilots und konfigurierbare Kundenworkflows. Beschraenke die Pruefung nicht auf generative AI.

Erfasse Owner, Zweck, betroffene Personen, Datenkategorien, Output-Nutzung, Kundenkonfiguration, Vendor-Abhaengigkeit, Rollenhypothese und Beruehrung mit regulierten Produkten oder Annex III. Danach entscheide, welche Evidenz fehlt und welcher Gate vor Launch greifen muss.

FAQ

Was sollten Teams ueber Hochrisiko-KI-Systeme verstehen?

Die Analyse ist ein Workflow, kein Label. Sie verbindet Zweck, Rollen, Kundenkonfiguration, Evidenz, Kontrollen und Launch-Entscheidungen.

Warum ist das praktisch wichtig?

High-risk Klassifizierung kann staerkere Anforderungen und Kundenpruefung ausloesen. Fruehe Entscheidungen vermeiden spaete Launch-Probleme.

Was ist der groesste Fehler?

Der groesste Fehler ist, Klassifizierung als einmaliges Memo statt als wiederholbaren Control mit Intake, Reviewer, Decision Record, Release Gate und Re-Review-Triggern zu behandeln.

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.