KI-Transparenz ist jetzt Teil der User Experience
Seit dem 2. August 2026 gelten die Transparenzregeln des EU AI Act fuer viele KI-Systeme, die mit Menschen interagieren oder Inhalte erzeugen. Fuer Produktteams ist das nicht nur eine juristische Checkliste. Es veraendert, wie Chatbots, Assistenten, automatische Empfehlungen, generierte Texte, synthetische Bilder und Support-Workflows in einer Web-App erscheinen sollten.
Die praktische Frage lautet: Versteht ein Nutzer, wann KI beteiligt ist, was die KI getan hat, wo menschliche Pruefung beginnt und wie ein Ergebnis angefochten oder korrigiert werden kann? Wenn diese Antwort in AGB versteckt ist, wirkt das Produkt genau dann unklar, wenn Vertrauen am wichtigsten waere.
Vor Labels zuerst alle KI-Touchpoints erfassen
Ein guter Transparenzplan startet mit einer Bestandsaufnahme der Produktoberflaechen, nicht mit einer Banner-Komponente. Erfasse alle Stellen, an denen KI mit Nutzern spricht, Inhalte veraendert, Entscheidungen vorbereitet, Daten zusammenfasst, Optionen sortiert, Automatisierung ausloest oder Medien erzeugt. Danach wird klar, welche Touchpoints direkte Nutzerinteraktionen sind, welche Inhalte generieren und welche nur interne Teams unterstuetzen.
Diese Karte hilft, zu wenig Kennzeichnung und Label-Muedigkeit gleichzeitig zu vermeiden. Ein Kundenportal-Chatbot braucht einen klaren Hinweis im Moment der Interaktion. Ein Admin-Assistent, der eine Support-Antwort entwirft, braucht eher Entwurfsstatus, Review-Verantwortung und Audit Trail. Ein synthetisches Produktbild oder ein oeffentlicher Artikelteaser braucht je nach Einsatz sichtbare oder maschinenlesbare Kennzeichnung.
- Chatbots, Copilots, generierte Texte, generierte Medien, Zusammenfassungen und automatische Empfehlungen identifizieren.
- Oeffentliche nutzerseitige KI von interner Team-Unterstuetzung trennen.
- Festhalten, ob das System informiert, entwirft, entscheidet, routet oder veroeffentlicht.
- Definieren, welche Outputs sichtbare Labels, maschinenlesbare Markierungen, Human Review oder blockierte Automatisierung brauchen.
- Die Bestandsaufnahme an echte Produkt-Screens binden, damit die Anforderungen testbar werden.
Hinweise als Interface-Zustaende gestalten
Gute Hinweise sind konkret, rechtzeitig und ruhig. Nutzer sollten wissen, dass sie mit KI interagieren, bevor sie sich auf eine Antwort verlassen. Gleichzeitig sollte die Oberflaeche nicht jeden Screen in eine Warnwand verwandeln. Der Hinweis gehoert nah an die KI-Interaktion und in dieselbe visuelle Sprache wie Status, Quelle und Verlaesslichkeitsinformationen.
Bei einem Chatbot kann das eine dauerhaft erkennbare Assistentenidentitaet sein, kurze Hinweistexte, Links zur Support-Eskalation und sichtbare Grenzen dessen, was der Assistent tun darf. Bei generierten Inhalten koennen es Entwurfs-Badges, Generated-by-Metadaten, Review-Status und ein Publishing-Gate sein. Bei Automatisierung helfen Aktivitaetslog und klare Unterscheidung zwischen vorgeschlagenen, freigegebenen und ausgefuehrten Aktionen.
Review und Korrektur in den Workflow einbauen
Transparenz bleibt schwach, wenn niemand darauf reagieren kann. Wenn KI Inhalte entwirft, Datensaetze sortiert oder Kundendaten zusammenfasst, sollte das Produkt zeigen, wer den Output geprueft hat, was geaendert wurde und ob das Ergebnis noch ein Vorschlag ist. Das ist besonders wichtig in Admin-Tools, in denen Teams schnell durch Queues arbeiten und der Oberflaeche Autoritaet zuschreiben.
Ein pruefbarer KI-Workflow braucht Zustaende, die technisch erzwungen werden koennen: generiert, bearbeitet, freigegeben, abgelehnt, veroeffentlicht und archiviert. Dazu kommen Berechtigungen, Zeitstempel, Quellenverweise und Rollback-Pfade. Diese Details machen KI im Alltag sicherer, weil sie abstrakte Aufsicht in konkretes Produktverhalten uebersetzen.
Logs und Nachweise als Produktinfrastruktur behandeln
KI-Funktionen beginnen oft als schlanke Experimente: ein Prompt, ein API-Aufruf und eine Antwort im UI. Fuer einen Prototyp kann das reichen, fuer einen Geschaeftsworkflow nicht. Sobald KI Kundenkommunikation, Operations oder Content-Publishing beeinflusst, sollte das System genug Nachweise speichern, um spaeter erklaeren zu koennen, was passiert ist.
Eine praktische Architektur protokolliert Modell- oder Provider-Familie, Prompt-Version, Eingabereferenzen, Output, Reviewer, Entscheidungsstatus und relevante Nutzeraktion. Dabei sollten keine unnoetigen personenbezogenen Daten gesammelt werden, aber der operative Pfad muss erhalten bleiben, den Support, Produkt und Compliance bei Vorfaellen oder Kundenfragen brauchen.
Regelaenderungen einplanen, ohne das Produkt einzufrieren
Der AI Act greift stufenweise. Transparenzpflichten gelten seit August 2026, waehrend viele High-Risk-Pflichten nach den Digital-Omnibus-Aenderungen spaetere Termine haben. Teams sollten deshalb keine einzelne Rechtsannahme fest in die Produktoberflaeche einbauen. Besser sind konfigurierbare Hinweistexte, Policy-Flags, Audit-Retention-Einstellungen und Review-Regeln, die sich aendern lassen, ohne die ganze App neu zu entwerfen.
Fuer EDS-Labs-Projekte ist ein gutes MVP eine KI-Funktion, die ab Tag eins nuetzlich und pruefbar ist: KI-Touchpoints erfassen, Hinweise direkt in die Oberflaeche einbauen, generierte Outputs sichtbar von freigegebenen Inhalten trennen, relevante Nachweise protokollieren und Menschen echte Kontrolle ueber Veroeffentlichung oder Aktion geben. So wird KI-Transparenz nicht zur nachtraeglichen Compliance-Aufgabe, sondern zu besserer Product Experience.