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.

Drei Dinge, die Produktmanager jetzt tun müssen

‍

1. Inventory: Baut ein AI-Feature-Inventar

Beginne damit, Euer AI-Inventar glattzuziehen. Ihr müsst genau wissen, welche Features in Eurem Produkt auf Modellen basieren, welche Daten sie verarbeiten und wie sie den Output beeinflussen. Erstelle eine Liste mit Feldern für das Modell, den konkreten Zweck und den fachlichen Owner. Das Ziel ist die Fähigkeit, bei regulatorischen Rückfragen sofort aussagefähig zu sein. Wenn Du nicht auf Knopfdruck sagen kannst, wo generative Komponenten in Eurer Delivery-Pipeline stecken, hast Du ein Governance-Problem, das Dich später wertvolle Zeit kostet.

Ein brauchbares Inventar sollte mindestens erfassen:

• Feature oder Workflow
• Nutzergruppe und Nutzungskontext
• verwendetes Modell oder Anbieter
• Input-Daten und Output-Typen
• Sichtbarkeit des Outputs: intern, kundenseitig, öffentlich
• menschliche Kontrolle im Prozess
• bestehende Labels, Hinweise oder Erklärungen
• Owner in Product und Engineering
• offene Rechts-/Security-/UX-Fragen

2. Disclosure: Übersetzt Transparenz in UX und Spezifikation

Übersetze die Transparenzpflichten des EU AI Acts direkt in UX-Patterns und Spezifikationen. Sogenannte Disclosure-Patterns definieren klare Signale für Nutzende, wann sie mit einer KI interagieren. Das betrifft den Entry-Point, die persistente Kennzeichnung während der Nutzung und den Export von Daten. Ein sauberes Solution Design klärt diese Fragen, bevor die erste Zeile Code geschrieben wird. So verhinderst Du, dass Compliance-Anforderungen kurz vor dem Release Euer gesamtes Interface zerschießen.

Produktteams sollten pro betroffenem Feature klären:

• Wann muss der Nutzer informiert werden?
• Muss der Hinweis dauerhaft sichtbar sein oder reicht ein Entry-Point?
• Wie werden AI-generierte Inhalte markiert?
• Brauchen exportierte Inhalte Metadaten oder Provenance?
• Wie erklären wir Grenzen, Fehlerwahrscheinlichkeit und menschliche Kontrolle?
• Wie testen wir, ob Nutzer den Hinweis verstehen?

3. Ownership: Verankert AI-Readiness in Definition of Done

Verankere AI-Readiness fest in Eurer Definition of Done und Deinem Product Operating Model. Jedes neue AI-Feature braucht klare Gates in der Discovery und im Release-Prozess. Prüfe systematisch: Ist die Herkunft der Trainingsdaten geklärt? Gibt es ein Monitoring für Halluzinationen? Wer übernimmt die Verantwortung, wenn der Output fachlich falsch ist? Du misst Deinen Fortschritt hier an der Quote der AI-Features, die ohne manuelle Compliance-Sonderschichten durch die Delivery laufen. Erst wenn diese Prüfpunkte Teil Deiner täglichen Routine sind, wird Regulatorik von der Bremse zum stabilen Leitplankensystem für Deine Produktentwicklung.

Beispiele für konkrete Gates:

• Discovery: Ist das Feature überhaupt ein AI-System oder AI-gestützter Workflow?
• Solution Design: Welche Disclosure- und Provenance-Pattern sind vorgesehen?
• Delivery: Sind Logs, Labels, Erklärungen und Human-Oversight-Anteile implementiert?
• Release: Gibt es eine geprüfte Klassifizierung, Owner und dokumentierte Restrisiken?
• Betrieb: Wer reagiert auf Modellwechsel, Provider-Änderungen oder Incident-Signale?

Wenn diese Fragen nicht in eurer Definition of Done, euren Review-Routinen und euren Produktverantwortlichkeiten auftauchen, werden sie zur Nacharbeit. Und Nacharbeit unter regulatorischem Zeitdruck ist selten elegant.

Automatisierung der Compliance durch KI-Agenten

Wenn Ihr schon AI-Features baut, warum dann nicht das Operating Model um diese Features herum auch mit AI (semi-)automatisieren und optimieren? Wir zeigen Euch jetzt, wie ihr das in der Praxis umsetzen könnt.

Manuelle Überprüfungen all Eurer Features skalieren nicht und fressen die Feature-Velocity Eurer Teams. Wer versucht, den EU AI Act mit Excel-Listen und manuellen Reviews zu bändigen, verliert den Anschluss an die Release-Zyklen. Die Lösung liegt in der Automatisierung:

- Ein AI Agent übernimmt beispielsweise das Scannen von PRDs und Epics auf regulatorische Risiken, noch bevor die erste Zeile Code geschrieben wird.
- Ein anderer Agent kann Euer Backlog kontinuierlich nach Risikoklassen kategorisieren und Compliance-Checks direkt in die Definition of Done integrieren.

So wird die regulatorische Prüfung von der bürokratischen Hürde zum automatisierten Signal in der Discovery-Pipeline.

Ein praktisches Beispiel - so arbeiten wir bei ARISE - ist ein mit Lovable gebautes Inventar-System, das neue KI-Features automatisch erfasst und klassifiziert. Parallel dazu prüfen spezialisierte UI-Agenten Eure Design-Entwürfe auf notwendige Disclosure-Pattern, um Transparenzpflichten direkt im Prototyping zu lösen. Nutzt dazu beispielsweise Claude Design oder Google Stitch - es muss in euren Workflow passen. Vor jedem Release liefern automatisierte Evaluation-Runs (z.B. mit LangSmith) die notwendigen Audit-Logs, die Ihr für eine rechtssichere Dokumentation braucht. Der Fortschritt lässt sich hier hart messen: Achtet auf die Reduzierung der Review-Zyklen pro Feature und die Quote der automatisiert erstellten Audit-Events im Vergleich zum manuellen Nachaufwand.

Trotz dieser Automatisierung bleibt die rechtliche Letztverantwortung bei Dir als Produktmanager. Ein Agent kann Nuancen übersehen oder Grenzfälle falsch interpretieren, weshalb die KI-gestützte Prüfung als vorbereitende Assistenz und nicht als finaler Entscheider fungieren sollte. Der initiale Aufwand für den Aufbau dieser Infrastruktur zahlt sich jedoch sofort aus, wenn die Menge an notwendiger Nacharbeit bei Compliance-Fragen sinkt. Du musst entscheiden, welche Freigabeprozesse Du vollständig automatisierst und wo ein menschliches Sign-off basierend auf den Agenten-Daten zwingend bleibt. Wenn Ihr heute nicht wisst, wie hoch der Anteil Eurer Backlog-Items mit unklarer Risikoklasse ist, fehlt Euch die notwendige Sichtbarkeit für einen sicheren Rollout.

Was Product Leader jetzt vermeiden sollten

Drei Muster sind gefährlich:

Erstens: „Legal wird uns schon sagen, was zu tun ist.“ Legal kann Anforderungen interpretieren. Aber Legal kann nicht entscheiden, wie ein AI-Copilot im konkreten Nutzerfluss erklärt werden muss.

Zweitens: „Wir machen später ein zentrales AI-Governance-Projekt.“ Zentralisierung hilft, wenn sie Muster, Templates und Standards schafft. Sie hilft nicht, wenn Produktteams währenddessen weiter AI-Features bauen, ohne Roadmap- und DoD-Anbindung.

Drittens: „Wir warten, bis alles final geklärt ist.“ Regulierung wird immer konkretisiert. Produktverantwortung lässt sich trotzdem schon operationalisieren: Inventar, Rollen, Disclosure-Pattern, Nachweisführung, Release-Gates.

Ein pragmatisches 14-Tage-Programm

Wenn ihr noch nicht gestartet seid, beginnt mit einem fokussierten Readiness-Sprint als Kick-Off:

Woche 1:

• Alle bekannten AI-Features und AI-gestützten Workflows erfassen.
• Je Feature Owner (DRI, Direct Responsible Individual) in Product und Engineering benennen.
• Rolle einordnen: Provider, Deployer, Integrator oder Mischform.
• Transparenz- und Nachweis-Lücken markieren.

Woche 2:

• Top-5-Risikofeatures priorisieren.
• Disclosure-Pattern als UX-Entwurf skizzieren.
• Akzeptanzkriterien und DoD-Checkpoints ergänzen.
• Offene Legal-/Security-Fragen bündeln.
• Release-Gate für neue AI-Features definieren.

Ein konkretes Ergebnis dieses Sprints ist ein Product Health Check, der als strukturierter Startpunkt dient, um Legal- und Security-Fragen frühzeitig in den Discovery-Prozess einzubauen.

Erwartet nicht, in diesem Sprint alles abzuschließen. Ihr erhaltet aber ein belastbares Operating-Modell und könnt dieses nun skalieren - auf alle Features und auch auf andere Teams. Mit einem Operating-Modell wird das Thema langfristig zum Selbstläufer.

Fazit

Der EU AI Act ist kein Compliance-Anhängsel, sondern ein Kernbestandteil Eurer Produktführung. Wer Regulierung erst beim Release-Gate prüft, riskiert teure Umbauten an Architektur und UX. Nutzt die verbleibende Zeit, um Governance als Wettbewerbsvorteil zu begreifen: Ein sauberes Modell für Transparenz schafft das Vertrauen, das Eure Kunden für die Adoption fordern.

Verankert die Verantwortung für die AI-Act-Readiness direkt in den Produktteams, statt sie in Stabsstellen zu isolieren. Integriert die Anforderungen in Eure Definition of Done und Roadmap-Priorisierung. Wenn Du unsicher bist, ob Deine Strategie standhält, hilft unser Product Health Check. Wir analysieren Eure Use Cases und schaffen Klarheit für die nächsten Release-Entscheidungen. Prüfe heute: Kannst Du für jedes AI-Feature im Backlog die geltenden Transparenzpflichten benennen?

Quellen und Hinweise

• Europäische Kommission: AI Act regulatory framework overview, inklusive Inkrafttreten und Anwendungslogik: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
• Europäische Kommission: Code of Practice für Marking und Labeling AI-generierter Inhalte, veröffentlicht am 10. Juni 2026: https://digital-strategy.ec.europa.eu/en/news/commission-publishes-code-practice-marking-and-labelling-ai-generated-content
• Regulation (EU) 2024/1689 im Official Journal: https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
• Article-50-Referenztext: https://artificialintelligenceact.eu/article/50/

Hinweis: Dieser Artikel ist keine Rechtsberatung. Er beschreibt die Produkt- und Operating-Model-Perspektive. Konkrete rechtliche Bewertung sollte vor Veröffentlichung und Umsetzung mit qualifizierter Rechtsberatung geprüft werden.

‍