Wie man verbotene KI-Praktiken operationalisiert, ohne Produktentwicklung zu verlangsamen

Verbotene KI-Praktiken zu operationalisieren bedeutet, Article-5-Screening zu einem normalen Produkt-, Vendor- und Internal-Tool-Workflow zu machen. Nicht jeder Product Manager muss KI-Jurist werden. Das Ziel ist, unannehmbare Nutzungen fruh zu erkennen, Unsicherheit an den richtigen Reviewer zu routen, Evidenz zu speichern und risikoarme Arbeit ohne unnotige Verzogerung weiterlaufen zu lassen.

Fur SaaS-Teams funktioniert ein schlankes Modell am besten: kurzer Intake, Entscheidungsroute, Launch Gate und Evidenzstandard. Wenn der Use Case keine Article-5-Red-Flags zeigt, geht er in normale AI Classification, Security, Privacy und Product Review. Wenn er klar eine verbotene Kategorie beruhrt, stoppt die Arbeit bis zum Redesign oder bis zu einer spezialisierten Bestatigung. Wenn der Fall unklar ist, geht er mit ausreichenden Fakten an einen benannten Reviewer.

Mit einer engen operativen Frage starten

Die falsche erste Frage lautet: Sind wir AI-Act-compliant? Fur ein Team, das shippen will, ist das zu breit. Besser ist: Konnte dieser konkrete KI-Use-Case in eine verbotene Kategorie fallen?

Diese Frage gehort in Product Discovery, Feature Review, Security Design Review, Privacy Review, Vendor Onboarding, Internal Tool Approval, Customer Configuration Review und wesentliche Anderungen nach Launch. Der erste Screen sollte kurz bleiben. Fragt, ob das System Entscheidungen beeinflusst, verdeckte oder manipulative Techniken nutzt, vulnerable Nutzer adressiert, Personen kontextubergreifend bewertet, biometrische Daten nutzt, Emotionen ableitet, Gesichtsbilder scraped oder sensible Bereiche wie Arbeit, Bildung, Kredit, Law Enforcement, Sicherheit oder essenzielle Dienste beruhrt.

Der Screen muss keine juristische Schlussfolgerung liefern. Er muss die nachste Route bestimmen.

Drei Routen statt einer grossen Review

Teams werden langsam, wenn jede KI-Frage durch denselben schweren Prozess geht. Besser sind drei Routen.

Route eins: weiter. Wenn die Fakten keine Article-5-Red-Flags zeigen, dokumentiert das Team die Antwort und macht mit normaler Klassifizierung und Risk Review weiter.

Route zwei: stoppen und neu gestalten. Wenn der Use Case klar eine verbotene Kategorie beruhrt, darf das Produkt nicht wie geplant weiterlaufen. Beispiele sind Emotionserkennung fur Worker-Engagement, Facial-Recognition-Datenbanken aus ungezieltem Scraping oder verdeckte Manipulation mit wahrscheinlich erheblichem Schaden.

Route drei: eskalieren. Viele schwierige Falle sind unklar, weil Fakten fehlen, Vendor Labels vage sind oder Kundenkonfiguration den Kontext verandert. Eskalation braucht einen benannten Legal-, Compliance- oder AI-Governance-Reviewer mit Zielzeit.

Ownership vor dem ersten Fall definieren

Ownership entscheidet, ob AI Governance schnell oder zah wird. Product besitzt Zweck, User Journey, betroffene Personen, Kundenkonfiguration und Launch-Zeitplan. Engineering besitzt Data Flows, Modellintegration, Logs, Architektur und technische Grenzen. Security besitzt Vendor Risk, Access, Deployment und Third-Party Assurance. Legal oder Privacy besitzt die Article-5-Analyse und den Evidenzstandard. Compliance oder der AI-Governance-Owner pflegt Prozess, Decision Tracking und Launch Gates.

So muss Product keine juristische Bedeutung erraten und Legal muss technische Fakten nicht nachtraglich aus Screenshots rekonstruieren.

Mindest-Evidenzpaket bauen

Das Evidenzpaket sollte klein genug fur den normalen Arbeitsfluss und spezifisch genug fur Kunden, Auditoren oder Regulatoren sein. Bewahren Sie System- oder Feature-Name, Owner, Reviewer, Zweck, betroffene Gruppen, AI-Act-Rolle, Vendor oder Modell, Datenkategorien, Antworten des Screens, Schlussfolgerung, Begrundung, erforderliche Anderungen, Datum und Re-Review-Trigger auf.

Speichern Sie Evidenz dort, wo die Arbeit passiert: im Produkt-Ticket, Vendor Record, Release Checklist oder Trust Evidence Folder. Separate Tabellen konnen am Anfang helfen, sollten aber nicht die einzige Wahrheit bleiben, wenn die echte Arbeit anderswo stattfindet.

Mit Delivery verbinden

Ein Prohibited-Practice-Workflow funktioniert nur, wenn er an Delivery gekoppelt ist. Ein fehlender Screen sollte AI-enabled Launches blockieren. Eine klare Red Flag blockiert Launch bis Redesign oder formaler Freigabe. Ein unklarer Fall blockiert nur bis zur Entscheidung des benannten Reviewers. Ein dokumentiertes "keine Red Flag" sollte allein keine zusatzliche Verzogerung erzeugen.

Vorhersehbares Routing ist der Geschwindigkeitshebel. Teams konnen Governance tragen, wenn sie wissen, was als Nachstes passiert.

Vendor AI und Konfiguration sichtbar machen

Vendor AI ist riskant, weil Labels wie Insight, Sentiment, Safety, Identity oder Personalization nicht erklaren, was das System tatsachlich tut. Fragen Sie nach Daten, Outputs, betroffenen Personen, Konfiguration, Biometrie, Emotionserkennung, Facial Databases, Profiling und manipulativen Techniken.

Prufen Sie auch Kundenkonfiguration. Ein Feature kann im Default akzeptabel sein und durch Einsatz in Arbeit, Bildung, Public Safety oder Identity riskant werden. Definieren Sie Trigger fur Re-Review, etwa neue Datenquellen, neue Nutzergruppen, biometrische Optionen, reduzierte Human Review oder neue regulatorische Guidance.

Haufige Fehler

Der erste Fehler ist ein Legal Memo statt Workflow. Harte Falle brauchen vielleicht ein Memo, aber Routinearbeit braucht Screen, Route, Owner und Evidenz. Der zweite Fehler ist zu spate Review. Wenn Design, Vertrag, Messaging und Engineering fast fertig sind, kostet Redesign mehr. Der dritte Fehler ist der Glaube, Human in the loop lose alles. Er kann helfen, macht aber verbotene Manipulation oder sensible biometrische Inferenz nicht automatisch zulassig.

Vergessen Sie auch interne Tools nicht. Employee Analytics, Training, Security Investigations, Support Scoring und Account Prioritization konnen Personen betreffen, auch wenn sie nie als Produkt verkauft werden.

Rollout in zwei Wochen

In Woche eins: bestehende AI Use Cases, Vendor AI und interne Tools erfassen. Einen kurzen Screen in Product Intake und Vendor Review einfugen. Reviewer benennen. Release-blockierende Zustande definieren. Evidenzort festlegen.

In Woche zwei: die wichtigsten Use Cases screenen, insbesondere Customer-Facing AI, Employment Tooling, Biometrie, Identity, beeinflussende Systeme und Vendors mit unklaren Outputs. Ergebnisse speichern, offensichtliche Lucken schliessen und unklare Falle in einen Backlog geben.

Danach gehort der Workflow in normales Change Management. Jede neue Feature-, Vendor- oder wesentliche Konfigurationsanderung wird gescreent, erzeugt Mindest-Evidenz und hat bei Unsicherheit einen Reviewer mit Frist.

FAQ

Was ist der praktische Zweck?

KI-Nutzungen identifizieren, die blockiert, neu gestaltet oder eskaliert werden mussen, bevor sie in Produkt, Vendor Workflow, Kundenkonfiguration oder internen Prozess gelangen.

Wann gilt das fur SaaS?

Wenn ein Team KI baut, kauft, integriert, verkauft, konfiguriert oder nutzt, die Article-5-Kategorien beruhren kann.

Was zuerst dokumentieren?

Intake Screen, Entscheidungsroute, benannter Reviewer, Release-Regeln und Mindest-Evidenzpaket 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 notice that the first AI Act rules started applying on 2 February 2025.
• European Commission AI Pact webinar page on prohibited-practice guidelines and AI system definition.