Der 2. August 2026 ist für Unternehmen mit AI-Systemen ein wichtiger Stichtag. Ab diesem Zeitpunkt greifen unter anderem die Transparenzpflichten nach Art. 50 des EU AI Act. Für Unternehmen, die bereits mit AI-Agenten arbeiten oder solche Systeme produktiv einführen wollen, ist das mehr als ein rechtlicher Termin im Kalender. Es betrifft die Frage, ob eine Agenten-Architektur im Betrieb erklären kann, was passiert ist, welche Daten genutzt wurden, welche Aktionen ausgelöst wurden und wo menschliche Kontrolle vorgesehen ist.
Bei einfachen Informationssystemen lässt sich diese Transparenz noch relativ klar abgrenzen. Anders sieht es aus, wenn Agenten Daten aus CRM, ERP, Ticketing, Dokumentenablagen oder Fachsystemen abrufen und daraus Empfehlungen oder Aktionen ableiten. Je stärker ein Agent in produktive Abläufe eingebunden ist, desto mehr hängt die Nachvollziehbarkeit an der technischen Umsetzung: an Logs, Berechtigungen, Datenflüssen, Tool-Freigaben und definierten Prozessgrenzen.
Der AI Act löst diese Fragen nicht allein durch juristische Dokumentation. Er macht aber sichtbar, dass Transparenz, Kennzeichnung und technische Nachweise nicht erst am Ende eines Projekts ergänzt werden können. Sie müssen früh in Architektur, Integration und Betriebsmodell eingeplant werden.
Was ab August 2026 konkret relevant wird
Der EU AI Act ist seit 1. August 2024 in Kraft und wird stufenweise angewendet. Verbote bestimmter AI-Praktiken und AI-Literacy-Anforderungen gelten bereits seit Februar 2025. Für General-Purpose-AI-Modelle gelten zentrale Pflichten seit August 2025. Am 2. August 2026 treten weitere Teile in Anwendung, darunter die Transparenzpflichten nach Art. 50.
Für Agenten-Architekturen sind dabei vor allem diese Punkte relevant:
- Nutzer müssen in bestimmten Fällen erkennen können, dass sie mit einem AI-System interagieren.
- AI-generierte oder manipulierte Inhalte müssen unter bestimmten Voraussetzungen kenntlich gemacht werden.
- Bei Hochrisiko-Systemen spielen Logging, technische Dokumentation, Human Oversight, Robustheit und Risikomanagement eine zentrale Rolle.
- Die konkrete Fristenlage für Hochrisiko-Systeme sollte je nach Systemtyp und Einsatzkontext geprüft werden, da sich durch die AI-Omnibus-Einigung einzelne Anwendungsfristen verschoben haben.
Das ist für Agenten-Architekturen wichtig, weil viele produktive Agenten nicht nur Inhalte erzeugen, sondern mit Systemen arbeiten. Sie greifen auf Daten zu, rufen Tools auf, bereiten Entscheidungen vor oder stoßen Prozesse an. Damit entstehen Nachweisanforderungen nicht nur auf Dokumentenebene, sondern direkt in der technischen Umsetzung.
Warum das Agenten-Architekturen direkt betrifft
Viele Agenten-Projekte der letzten Jahre wurden zuerst aus einer Produktivitätslogik heraus gebaut. Der Fokus lag auf Funktion, Geschwindigkeit und Nutzen: Kann der Agent Informationen finden? Kann er Tickets vorbereiten? Kann er Datensätze prüfen? Kann er E-Mails formulieren oder Fachbereiche entlasten?
Das war für frühe Experimente nachvollziehbar. Im produktiven Betrieb reicht diese Perspektive aber nicht mehr aus. Sobald ein Agent mit echten Daten, echten Nutzern und echten Prozessfolgen arbeitet, verschiebt sich die Frage.
| Frühe Agenten-Logik | Produktive Agenten-Logik |
|---|---|
| Funktioniert der Use Case? | Ist die Handlung nachvollziehbar? |
| Kann der Agent auf Systeme zugreifen? | Ist der Zugriff begrenzt und kontrolliert? |
| Spart der Agent Zeit? | Sind Datenquellen und Outputs erklärbar? |
| Gibt es eine gute Demo? | Ist der Betrieb prüfbar und steuerbar? |
Für die Architektur bedeutet das: Transparenz darf nicht als Oberfläche verstanden werden, die man am Ende ergänzt. Sie hängt an Datenflüssen, Berechtigungen, Logs, Schnittstellen, Systemgrenzen und Freigabeprozessen. Ein Agent, der über mehrere Systeme hinweg arbeitet, braucht deshalb nicht nur Zugriff. Er braucht kontrollierten Zugriff.
Logging wird zur Grundlage für Nachweise
Ein produktiver Agent braucht ein Logging-Konzept, das über klassische API-Logs hinausgeht. Normale Systemlogs zeigen oft, dass ein Request stattgefunden hat. Für einen belastbaren Nachweis reicht das häufig nicht aus. Entscheidend ist, ob später nachvollzogen werden kann, welche Datenquellen der Agent verwendet hat, welcher Kontext in die Antwort oder Aktion eingeflossen ist und ob ein Mensch an einer relevanten Stelle eingebunden wurde.
Gerade bei agentischen Systemen sind mehrere Ebenen relevant: Welche Tools oder Schnittstellen wurden aufgerufen? Welche Daten wurden gelesen oder verändert? Welche Empfehlung oder Aktion wurde erzeugt? Wurde eine menschliche Freigabe eingeholt? Gab es einen Versuch, eine Systemgrenze zu überschreiten, und wurde dieser Versuch blockiert oder protokolliert?
Ohne diese Datenbasis bleibt Nachvollziehbarkeit abstrakt. Dann existiert Governance zwar als Policy, aber nicht als technischer Nachweis. Genau an dieser Stelle wird Architektur entscheidend. Logging ist nicht nur ein Betriebsdetail, sondern die Grundlage dafür, dass ein Unternehmen später erklären kann, wie ein Agent gearbeitet hat.
Kennzeichnung von AI-Interaktionen muss eingebaut sein
Die Transparenzpflicht gegenüber Nutzern klingt zunächst einfach: Menschen sollen wissen, wenn sie mit einem AI-System interagieren. In der Praxis wird das anspruchsvoller, sobald Agenten über mehrere Kanäle arbeiten. Ein Agent kann in einem Chat sichtbar sein, über E-Mail antworten, in einem Portal eingebettet sein oder per Sprache mit Nutzern interagieren.
Wenn die Kennzeichnung nur als Textbaustein in einem einzelnen Frontend gedacht wird, entstehen schnell Lücken. Der Agent kann dann in einem Kanal korrekt gekennzeichnet sein, in einem anderen aber nicht. Saubere Architektur muss deshalb berücksichtigen, wo AI-Interaktionen entstehen und wie die Kennzeichnung kanalübergreifend abgesichert wird.
Das betrifft externe Nutzer ebenso wie interne Szenarien. Auch Mitarbeitende sollten erkennen können, ob sie eine rein menschliche Einschätzung, eine AI-generierte Empfehlung oder eine durch AI vorbereitete Aktion vor sich haben. Je stärker AI in Arbeitsabläufe eingebettet wird, desto wichtiger wird diese Unterscheidung.
Prozessgrenzen und Eingriffspunkte werden wichtiger
Ein Agent, der Informationen sucht, ist weniger kritisch als ein Agent, der Aktionen auslöst. Sobald ein System Tickets verändert, Kundendaten aktualisiert, Dokumente bewertet, Empfehlungen für Entscheidungen erzeugt oder Prozesse anstößt, braucht es definierte Grenzen. Diese Grenzen sollten nicht nur in einer Richtlinie stehen, sondern technisch greifen.
Dazu gehören genehmigte Datenquellen, klar definierte Tool-Freigaben, Rollen- und Berechtigungskonzepte, Eskalationspunkte für menschliche Freigaben und technische Stopps bei kritischen Aktionen. Ein Agent muss nicht alles dürfen, nur weil eine Schnittstelle technisch erreichbar ist. In vielen Fällen ist genau diese Trennung der zentrale Kontrollpunkt.
Human Oversight wird dadurch konkreter. Es reicht nicht, allgemein festzuhalten, dass ein Mensch eingreifen kann. Die Architektur muss zeigen, wo dieser Eingriff vorgesehen ist, wann er ausgelöst wird und wie er dokumentiert wird. Gerade in kritischen Prozessen entscheidet diese Ausgestaltung darüber, ob menschliche Kontrolle im Betrieb tatsächlich vorhanden ist oder nur auf dem Papier steht.
Datenherkunft wird Teil der Nachweiskette
Agenten erzeugen Outputs nicht aus dem Nichts. Sie greifen auf Daten zu, kombinieren Informationen und leiten daraus Antworten, Empfehlungen oder Aktionen ab. Deshalb reicht es nicht, nur den finalen Output zu speichern. Unternehmen müssen auch verstehen, aus welchen Quellen der Output entstanden ist.
Relevant ist dabei nicht nur die Quelle selbst, sondern auch ihr Zustand zum Zeitpunkt der Nutzung. War der Datenstand aktuell? War die Datenquelle für diesen Zweck freigegeben? Wurde auf personenbezogene, vertrauliche oder regulierte Informationen zugegriffen? Und konnte der Agent zwischen belastbaren und weniger belastbaren Quellen unterscheiden?
Datenintegration wird damit auch zu einem Compliance-Thema. Wer seine Datenflüsse nicht kennt, kann die Herkunft von Agenten-Outputs kaum belastbar erklären. Für Unternehmen mit mehreren Systemen, historisch gewachsenen Schnittstellen oder uneinheitlichen Datenmodellen ist das oft der Punkt, an dem AI-Governance sehr praktisch wird.
Was Unternehmen jetzt prüfen sollten
Die naheliegende Reaktion auf den AI Act ist juristische Beratung. Das ist sinnvoll, aber nicht ausreichend. Juristische Einordnung klärt, welche Pflichten auf ein konkretes System zutreffen. Für agentische Architekturen braucht es zusätzlich eine technische Bestandsaufnahme.
Dabei geht es nicht darum, sofort jedes System neu zu bauen. Der erste Schritt ist Transparenz über den Ist-Zustand: Welche Agenten sind bereits produktiv oder produktionsnah? Wo interagieren sie mit Nutzern? Welche Systeme und Datenquellen sprechen sie an? Welche Aktionen können sie auslösen? Wo gibt es menschliche Freigaben? Welche Logs existieren bereits, und welche Nachweise wären heute im Fehlerfall verfügbar?
Aus dieser Bestandsaufnahme ergeben sich die nächsten Architekturentscheidungen. Manche Lücken lassen sich über bessere Protokollierung schließen. Andere erfordern klarere Berechtigungskonzepte, getrennte Tool-Freigaben, zusätzliche Freigabeschritte oder eine sauberere Trennung zwischen Empfehlung und Ausführung.
Wichtig ist vor allem, diese Fragen nicht erst kurz vor einem Audit oder einer Behördenanfrage zu stellen. Dann ist Nachvollziehbarkeit schwer nachträglich herzustellen. Sie muss dort entstehen, wo Agenten auf Daten, Tools und Prozesse zugreifen.
Saubere Architektur wird zum Vertrauenssignal
Der AI Act wird häufig als Compliance-Thema diskutiert. Für Agenten-Architekturen greift das zu kurz. Transparenz, Logging, Kennzeichnung und Human Oversight sind nicht nur regulatorische Anforderungen. Sie entscheiden auch darüber, ob Fachbereiche, Kunden, Partner und IT-Verantwortliche einem produktiven Agenten vertrauen können.
Unternehmen, die nachvollziehbar zeigen können, wie ihre Agenten arbeiten, welche Grenzen gelten und wo Menschen eingebunden werden, haben deshalb einen praktischen Vorteil. Sie können AI-Systeme kontrollierter betreiben, Risiken früher erkennen und gegenüber internen wie externen Stakeholdern klarer erklären, was ihre Architektur leistet und was bewusst ausgeschlossen ist.
Der August 2026 ist daher weniger ein einzelner Stichtag, an dem plötzlich alles neu wird. Er ist ein sichtbarer Marker für eine Entwicklung, die bereits begonnen hat: AI-Systeme werden nicht mehr nur danach bewertet, was sie können. Sie werden zunehmend daran gemessen, ob ihre Nutzung transparent, steuerbar und nachweisbar bleibt.
Was jetzt zählt
Für Unternehmen mit produktiven oder produktionsnahen Agenten ist die wichtigste Frage nicht, ob der AI Act relevant wird. Die wichtigere Frage ist, an welchen Stellen die eigene Architektur bereits nachweisfähig ist und wo sie nur funktional funktioniert.
Wenn Agenten in Unternehmenssysteme eingebunden werden, müssen Logging, Kennzeichnung, Datenherkunft, Berechtigungen und menschliche Eingriffspunkte früh mitgedacht werden. Nicht als Zusatzdokumentation am Ende, sondern als Teil der technischen Umsetzung.
Damit verschiebt der AI Act die Diskussion an eine sehr praktische Stelle: weg von allgemeinen AI-Richtlinien und hin zu konkreten Architekturentscheidungen. Genau dort entscheidet sich, ob ein Agent nur produktiv läuft oder auch nachvollziehbar, begrenzt und prüfbar betrieben werden kann.