Verbotene KI-Praktiken: Praktischer Leitfaden fur SaaS-Teams

Verbotene KI-Praktiken sind KI-Nutzungen, die ein SaaS-Team stoppen muss, bevor sie Kunden, Mitarbeitende, Vendor-Workflows oder interne Prozesse erreichen. Article 5 des EU AI Act behandelt eine begrenzte Gruppe unannehmbarer Praktiken: schadliche Manipulation, Ausnutzung von Schwachstellen, bestimmte Formen von Social Scoring, einige strafrechtliche Risikobewertungen, ungezieltes Scraping von Gesichtsbildern, Emotionserkennung am Arbeitsplatz und in Bildung, sensible biometrische Kategorisierung sowie Echtzeit-Fernidentifizierung in offentlich zuganglichen Raumen fur Strafverfolgung mit engen Ausnahmen.

Praktisch heisst das: Warten Sie nicht, bis Legal ein fertiges Feature pruft. Bauen Sie einen Pre-Launch-Screen, der fragt, ob ein KI-Use-Case in eine verbotene Kategorie fallen konnte, klare Falle blockiert, unklare Falle eskaliert und die Entscheidung dokumentiert. Der Screen muss Produktfeatures, interne Tools, eingebettete Vendor-Systeme, Modellintegrationen und kundenseitig konfigurierbare Automationen abdecken.

Warum das wichtig ist

Das Screening verbotener Praktiken ist der Eingang zu AI Governance. Wenn ein Use Case verboten ist, sollte das Team keine normalen Controls darum bauen. Die richtige Reaktion ist stoppen, neu gestalten, eingrenzen oder eskalieren, bevor der Use Case im Roadmap- oder Kundenkontext fest verankert ist.

In SaaS kommt KI oft leise hinzu: Produkt-Nudges, Account Scoring, HR-Analytics, Vendor-Funktionen oder biometrische Module in vorhandenen Plattformen. Ein kleines Ticket kann die regulatorische und ethische Lage des Dienstes verandern.

Was zu prufen ist

Ubersetzen Sie Article 5 in operative Fragen. Nutzt das System verdeckte, manipulative oder tauschende Techniken, die Entscheidungen wesentlich beeinflussen und erheblichen Schaden verursachen konnen? Nutzt es Vulnerabilitaten wegen Alter, Behinderung oder sozialer oder wirtschaftlicher Lage aus? Bewertet es Personen uber verschiedene Kontexte hinweg? Betreibt es Social Scoring, strafrechtliche Risikoprognose nur auf Profiling-Basis, Facial-Recognition-Datenbanken durch Scraping, Emotionserkennung in Arbeit oder Bildung, sensitive biometrische Inferenz oder Echtzeit-Fernidentifizierung?

Der Modellname reicht nie. Entscheidend sind Zweck, Kontext, Daten, betroffene Personen und Wirkung des Outputs.

Praktischer Workflow

Fugen Sie KI-Fragen in Product Review, Vendor Review, Security Review, Privacy Review und Genehmigung interner Tools ein. Fragen Sie nicht nur, ob etwas verboten ist. Fragen Sie, was das System tut, wen es betrifft, welche Daten es nutzt, ob es Entscheidungen beeinflusst, ob biometrische Daten oder Emotionserkennung vorkommen und ob der Fall Arbeit, Bildung, Kredit, wesentliche Dienste, Law Enforcement oder offentliche Sicherheit beruhrt.

Klare Nein-Antworten konnen in normale KI-Klassifizierung und Risk Review gehen. Klare Ja-Antworten stoppen, bis Legal und Compliance ein Redesign freigeben oder bestatigen, dass der Fall nicht unter das Verbot fallt. Unklare Antworten gehen an einen benannten Reviewer.

Die Entscheidungsvorlage sollte System, Owner, Vendor, Zweck, betroffene Personen, Daten, Geografie, AI-Act-Rolle, Article-5-Fragen, Ergebnis, Begrundung, Anderungen, Approver und Re-Review-Trigger enthalten.

Evidenz

Bewahren Sie Intake, Produkt- oder Vendor-Beschreibung, Data-Flow-Notiz, Analyse betroffener Personen, Screenshots oder Konfiguration, Entscheidung, Begrundung, Reviewer, Datum und Redesign-Aktionen auf. Bei Vendors gehoren KI-Dokumentation, vertragliche Zusagen und Aussagen zu Biometrie, Emotionserkennung, Profiling, Modelltraining und Nutzerbeeinflussung dazu.

Die Evidenz sollte zeigen, wann die Entscheidung erneut gepruft wird: neuer Zweck, neue Nutzergruppe, neuer Markt, neue Datenquelle, geanderte Human Review, Kundeneinstellungen oder neue regulatorische Leitlinien.

Haufige Fehler

Der erste Fehler ist zu spate Prufung. Wenn das Feature fast live ist, beruhen Design, Vertrag, Messaging und Engineering oft schon auf einer Annahme. Der zweite Fehler ist, nur Customer-Facing Features zu prufen. Interne Tools konnen ebenfalls riskant sein, wenn sie Mitarbeitende, Bewerber, Training, Produktivitat, Fraud, Support oder Security betreffen.

Verlassen Sie sich auch nicht auf Vendor-Labels wie Insight, Sentiment, Safety oder Personalization. Die Frage ist, was das System tatsachlich tut. Human in the loop hilft, beseitigt aber nicht automatisch eine unzulassige Manipulation oder sensitive biometrische Inferenz.

FAQ

Was ist der praktische Zweck?

KI-Nutzungen erkennen, die blockiert, neu gestaltet oder eskaliert werden mussen, bevor sie Teil von Produkt, Vendor-Workflow oder internem Prozess werden.

Wann gilt das fur SaaS?

Wenn ein Team KI baut, kauft, einbettet, verkauft, konfiguriert oder nutzt und dabei eine Article-5-Kategorie beruhrt sein konnte.

Was zuerst dokumentieren?

Intake, Entscheidungsrecord, benannten Reviewer und Launch Gate, verbunden mit Product, Vendor, Privacy, Security und Customer Trust.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidelines on prohibited artificial intelligence practices.
• European Commission studies on Article 5 of the AI Act.