Der EU AI Act ist nicht mehr „irgendwann“. Er ist seit dem 1. August 2024 in Kraft, und ab dem 2. August 2026 verstreicht die zweijährige Übergangsfrist - damit wird er grundsätzlich anwendbar. Für Produktteams ist das der Punkt, an dem aus Regulierung operative Produktarbeit wird. Was bisher als ferne Compliance-Aufgabe galt, ist jetzt geltendes Recht für Deine produktiven Systeme.
Das Problem: Viele Organisationen behandeln den AI Act noch wie ein Legal-Dokument. Also wie etwas, das die Rechtsabteilung liest, zusammenfasst und irgendwann als Policy zurück in die Organisation gibt.
Das reicht nicht.
Wenn AI in Eurem Produkt steckt, treffen die Anforderungen sehr konkrete Produktentscheidungen: Welche Features sind betroffen? Wo muss Nutzertransparenz entstehen? Welche Inhalte werden als AI-generiert gekennzeichnet? Welche Nachweise müssen erhalten bleiben? Wer trägt die Verantwortung zwischen Provider, Deployer, Product, Engineering, Legal und Security?
Die unangenehme Wahrheit: Wer diese Fragen erst kurz vor dem Release stellt, baut Compliance als Retrofit. Und Retrofit ist in AI-Produkten teuer.
Als Product Manager oder Owner musst Du jetzt nachweisen, wie Du Transparenzpflichten und Risikoklassen in Deinem Backlog gelöst hast. Wer Governance und Dokumentation bisher ignoriert hat, steht heute vor einem massiven Problem in der Betriebsfähigkeit. Die EU-Kommission hat den Rahmen gesetzt, und fast jedes kommerzielle AI-Produkt muss die Basisanforderungen an Nachvollziehbarkeit und Risikomanagement nun im Live-Betrieb erfüllen. Abwarten ist keine Option mehr; die regulatorischen Leitplanken müssen jetzt fester Bestandteil Deines Product Operating Models sein.
Deine Aufgabe als Product Manager ist die sofortige Übersetzung: Interpretierbare juristische Texte müssen in konkrete Anforderungen für Engineering und Design gegossen sein. Es geht nicht mehr um die bloße Vermeidung von Bußgeldern, sondern um den Schutz Deiner Produktinvestitionen. Ein Feature, das wegen fehlender Audit-Logs oder mangelnder Transparenz jetzt offline gehen muss, ist ein Totalausfall. Der AI Act ist kein optionales Framework mehr, sondern der Standard für professionelle Produktqualität, den Dein Team ab heute in jedem Sprint beherrschen muss.
Aber - keine Panik: Wie so häufig bei Compliance-Themen muss hier nicht von heute auf morgen alles umgekrempelt werden. Es gibt 3 konkrete Maßnahmenpakete, die Du noch heute planen kannst - um dann eine Roadmap mittels eines risikobasierten Ansatzes zu erstellen.
Warum die Frist für Produktteams relevant ist
Der AI Act folgt einem risikobasierten Ansatz. Nicht jedes AI-Feature ist gleich kritisch. Aber genau deshalb müssen Produktteams wissen, welche Art von AI sie überhaupt im Produkt haben.
Für viele Product Manager sind besonders drei Bereiche relevant:
1. AI-Interaktionen mit Nutzern, etwa Chatbots, Copilots oder Assistenzsysteme.
2. Generierte Inhalte, die Nutzern, Kunden oder Dritten angezeigt werden.
3. Produktentscheidungen, bei denen AI Output in Workflows, Empfehlungen oder Automatisierung einfließt.
Die Umsetzung des EU AI Acts entscheidet sich für Dich nicht in der Rechtsabteilung, sondern im Product Operating Model. Sobald Dein Produkt Inhalte generiert oder Entscheidungen automatisiert, greifen Transparenzpflichten nach Artikel 50, die direkte Auswirkungen auf Eure UX und Eure Content-Flows haben. Es reicht nicht mehr, dass ein Feature technisch funktioniert; es muss für den Nutzer zweifelsfrei erkennbar sein, dass er mit einer KI interagiert. Das betrifft jeden Chatbot-Hinweis, jeden KI-generierten Report und jeden Export, der künftig Provenance-Metadaten enthalten muss, um die Herkunft der Informationen nachzuweisen.
Die EU-Kommission hat zusätzlich am 10. Juni 2026 einen Code of Practice für Marking und Labeling AI-generierter Inhalte veröffentlicht. Du musst jetzt klären, welche Rolle Deine Organisation rechtlich einnimmt: Seid Ihr Provider, die ein eigenes Modell in den Markt bringen, oder Deployer, die bestehende Systeme in interne Workflows integrieren? Für die meisten von Euch ist wohl letzteres relevant, aber Vorsicht bei Finetuning. Diese Rollenklärung ist die Basis für Eure Roadmap, denn sie bestimmt, ob Du nur Kennzeichnungspflichten hast oder tiefe technische Nachweise über Trainingsdaten und Risikomanagement liefern musst.
Messbar wird dieser Fortschritt für Dein Team an der Audit-Fähigkeit Eurer Features. Ein produktionsreifer Use Case braucht heute ein klares Signal: Kannst Du pro generiertem Output nachweisen, welches Modell mit welcher System-Prompt-Version und welchen Metadaten zur Kennzeichnung gearbeitet hat? Wenn Eure aktuelle Architektur diese Provenance-Daten nicht mitschreibt, baut Ihr technische Schulden auf, die Euch spätestens bei der nächsten regulatorischen Prüfung einholen. Nutzt die kommenden Sprints, um diese Nachweise als festen Bestandteil Eurer Definition of Done zu verankern, statt Compliance als nachgelagertes Problem zu betrachten.
Die falsche Frage: „Sind wir compliant?“
Wenn Du deine Legal-Abteilung fragst, ob Dein Produkt EU-konform ist, erhältst Du ein Gutachten, aber keine Produktentscheidung. Die Frage „Sind wir compliant?“ schiebt die Verantwortung weg und zwingt Dein Team in eine passive Warteschaltung. Das Problem liegt meist tiefer: In vielen Backlogs schlummert deutlich mehr AI-Nutzung, als die offizielle Roadmap vermuten lässt. Wer Compliance erst am Ende der Discovery als Checkliste begreift, verbrennt Sprints. Wenn die Architektur Anforderungen an Erklärbarkeit oder Datenherkunft ignoriert, ist das Produkt im EU-Markt schlicht nicht lieferfähig.
Du musst Compliance als festen Bestandteil Deines Product Operating Models begreifen. Statt auf Paragrafen zu starren, klärst Du die Rolle der AI im System:
- Welche AI-Fähigkeiten sind in unserem Produkt überhaupt aktiv?
- Welche davon berühren Nutzer, Kunden, Mitarbeiter oder externe Dritte?
- Welche Outputs werden gespeichert, angezeigt, exportiert oder weiterverwendet?
- Welche Rolle haben wir: Anbieter, Betreiber, Integrator, interner Nutzer oder Mischform?
- Wo müssen wir Transparenz, Nachweisführung und menschliche Verantwortung in den Produktfluss einbauen?
Echte Readiness entsteht, wenn Product, Engineering und Security am Tisch sitzen, bevor der erste Token generiert wird. Ein Warnsignal für mangelnde Reife: Dein Team kennt die Modell-Performance, kann aber keinen Audit-Trail für eine automatisierte Entscheidung vorlegen. Wenn Scope, Datenzugriff und menschliche Kontrollpunkte pro Feature dokumentiert sind, werden Zielkonflikte entscheidbar. Dein Ziel ist ein System, das im Ernstfall erklären kann, was es tut – und warum.
Im Idealfall habt Ihr bereits AIOps-Prozesse implementiert - inklusive Evaluations, denn Ihr wollt nicht ohne Einblick in das Systemverhalten arbeiten. Das kann direkt als Grundlage für Evidenz dienen - denn den Audit-Trail benötigst Du nicht nur für Compliance, sondern auch als Tracking deiner Zielmetriken für deine AI-Features.



