EU AI Act August 2026: 5 Architekturanforderungen für KI

Was mich in Gesprächen immer wieder überrascht: Das Thema landet bei Legal oder beim Datenschutzbeauftragten und kommt selten in der Architektur-Runde an. Das ist das falsche Ressort. Wer Compliance als Rechtsprojekt behandelt, baut zweimal.

Ich bin kein Anwalt. Was ich bin: jemand, der KI-Systeme in produktiven Umgebungen baut und betreibt. Und aus dieser Perspektive ist der EU AI Act vor allem ein Architekturproblem.

Dieser Artikel erklärt, was das konkret bedeutet. Keine Rechtstexte. Keine Disclaimer. Fünf technische Anforderungen, die jedes KI-System erfüllen muss.

Was gilt ab 2. August und was hat noch Zeit?

Zuerst ein wichtiger Hinweis zur Fristenlage, denn hier gibt es aktuell Verwirrung.

Das EU-Parlament hat im Juni 2026 die Fristen für Hochrisiko-KI verschoben. Eigenständige Hochrisiko-Systeme nach Anhang III – darunter KI in der Personalauswahl, Kreditwürdigkeitsprüfung oder Bildungsbewertung – müssen erst bis zum 2. Dezember 2027 vollständig compliant sein. Eingebettete Hochrisiko-Systeme in regulierten Produkten haben bis zum 2. August 2028 Zeit.

Was nicht verschoben wurde, sind die allgemeinen Transparenzpflichten nach Artikel 50. Sie gelten wie geplant ab dem 2. August 2026.

Dazwischen liegt eine dritte, oft übersehene Frist: der 2. Dezember 2026. Sie betrifft nicht die Transparenzpflicht als solche, sondern einen technisch anspruchsvolleren Teil davon – die maschinenlesbare Kennzeichnung KI-generierter Inhalte, etwa über Wasserzeichen oder auslesbare Metadaten, im Unterschied zu einem für Menschen sichtbaren Hinweis. Für diese technische Umsetzung hatten Bestandssysteme, die bereits vor dem 2. August 2026 auf dem Markt sind, ursprünglich sechs Monate Übergangszeit. Der Rat hat diese Frist im Mai 2026 auf drei Monate verkürzt, mit dem 2. Dezember 2026 als neuem Stichtag. Wichtig dabei: Diese Schonfrist gilt ausschließlich für Bestandssysteme. Jedes generative KI-Produkt, das ab dem 2. August 2026 neu auf den Markt kommt, muss die maschinenlesbare Kennzeichnung von Anfang an erfüllen.

Das bedeutet praktisch: Wer KI-Systeme betreibt, die mit Menschen interagieren oder Inhalte erzeugen, ist ab August in der Pflicht. Die Hochrisiko-Ausnahme ist keine Einladung zum Warten, sie ist mehr Zeit für saubere Vorbereitung. Und noch etwas, das kaum diskutiert wird: Artikel 4 der Verordnung schreibt eine nachweisbare KI-Kompetenz im Unternehmen vor. Kann ein Unternehmen das nicht belegen, haften Geschäftsführer persönlich.

Warum ist das kein reines Legal-Thema?

Ich sage das direkt, weil es wichtig ist: Compliance ist eine Architekturfrage.

Nachweise, Audit-Logs, Human-Oversight-Punkte, das sind keine Dokumentationspflichten, die man nachträglich in ein System einhängt. Sie sind entweder von Beginn an Teil des Systemdesigns oder man baut sie zweimal. Einmal sauber, einmal unter Druck.

Wer Audit-Logs als Pflaster betrachtet, zahlt doppelt. Wer sie als Architekturbestandteil versteht, baut einmal und hat gleichzeitig eine bessere Grundlage für Debugging, Qualitätssicherung und Governance. Das ist keine Einschränkung. Es ist ein besseres System.

Die 5 Anforderungen technisch erklärt

Provenance: Woher kommen die Daten?

Jedes KI-System, das produktiv eingesetzt wird, greift auf Daten zu. Die Frage, die der EU AI Act stellt, ist: Woher kommen diese Daten? Welche Modelle wurden eingesetzt? Unter welchen Bedingungen wurden sie trainiert?

Das klingt nach einer Dokumentationsaufgabe. Technisch ist es mehr. Provenance bedeutet, dass jeder Schritt in der Datenpipeline nachvollziehbar ist – von der Quelle bis zum Output. Bei Systemen, die auf proprietären Modellen aufbauen oder Drittanbieter-Daten verwenden, ist das eine nicht-triviale Anforderung. Praktisch bedeutet das, dass die Datenherkunft Teil des System-Designs sein muss und nicht erst dann dokumentiert, wenn jemand fragt. Protokolliert, wenn Daten fließen.

In unseren Projekten bei communicode ist das kein Zusatzaufwand. Datenfundament und Datenherkunft sind Bestandteil unseres AI Integration Hub – der Architektur, die wir ohnehin bauen, bevor ein KI-System produktiv geht.

Provenance beantwortet, woher Daten kommen – nicht, wer sie beim Verarbeiten sehen kann. Wer Cloud-LLMs einsetzt, muss auch das absichern: Confidential Computing verschlüsselt Daten selbst während der Inferenz, sodass nicht einmal der Modell-Anbieter Einblick hat. Für diesen Anwendungsfall arbeiten wir mit Lösungen wie Privatemode AI: The always encrypted AI service von Edgeless Systems.

Audit Logs: Was hat das System entschieden?

Ein KI-System, das Entscheidungen trifft – Produktpreise anpasst, Bewerbungen filtert, Kreditanträge bewertet – muss dokumentieren, was es wann entschieden hat und auf Basis welcher Daten.

Das hat zwei Funktionen:

• interne Qualitätssicherung: Fehler in KI-Systemen sind schwer zu debuggen, wenn man nicht weiß, was das System gesehen hat. Audit-Logs sind ein technisches Werkzeug, das Teams nutzen sollten.
• regulatorische Nachvollziehbarkeit: Der EU AI Act verlangt, dass Entscheidungen rekonstruierbar sind. Lückenlos bedeutet: nicht erst dann, wenn jemand fragt, sondern sobald die Entscheidung getroffen wird.

Mein Hinweis aus der Praxis: Wer CI/CD-Denken auf KI-Systeme anwendet, hat hier bereits einen Teil der Antwort. Jede Änderung am System, jeder Deployment-Schritt, jede Modelländerung wird protokolliert. Das ist bekannte Ingenieurspraxis auf einen neuen Kontext angewandt.

Human Oversight: Wer greift ein, wenn das System irrt?

Das ist die Anforderung, die am häufigsten missverstanden wird.

Human Oversight bedeutet nicht, dass ein Mensch jeden KI-Output prüft. Es bedeutet, dass definiert ist, an welchen Punkten ein Mensch eingreifen kann, muss oder wird. Wo liegt der Schwellenwert? Was passiert, wenn das System unter einem Konfidenz-Level liegt? Wer bekommt welche Eskalation? Diese Fragen müssen vor Go-Live beantwortet sein – technisch, nicht in einem Policy-Dokument.

In der Praxis bedeutet das: Jedes KI-System braucht definierte Eskalationspunkte, die technisch erzwingbar sind. Kein Override-Button nach dem Fehler. Eine Architektur, die bei Unsicherheit stoppt und eskaliert.

Nur unter dieser Bedingung ist Autonomie vertretbar ist.

Risikoeinstufung: Was ist eigentlich Hochrisiko?

Bevor man die Anforderungen der Risikoklassen umsetzt, muss man wissen, welcher Klasse das eigene System angehört.

Die Einordnung ist nicht trivial, denn Anhang III des EU AI Act definiert Hochrisiko-Systeme nach Anwendungsbereich: KI in der Personalauswahl, im Bildungsbereich, in kritischer Infrastruktur, in der Strafverfolgung, in der Kreditwürdigkeitsprüfung. Für diese Systeme gelten die verschärften Pflichten, aktuell mit verschobener Frist bis Dezember 2027, aber mit unveränderten inhaltlichen Anforderungen.

Was viele übersehen: Die Einstufung hängt nicht nur vom Produkt ab, sondern vom Kontext. Ein KI-System, das HR-Teams bei der Vorauswahl von Bewerbungen unterstützt, kann Hochrisiko sein, auch wenn es als "Entscheidungsunterstützung" vermarktet wird.

Mein Rat: Die Einstufung selbst vornehmen, bevor es jemand anderes tut. Die Konsequenzen der falschen Einordnung nach oben sind erheblich.

Transparenz: Wer weiß, dass er mit KI interagiert?

Artikel 50 des EU AI Act verpflichtet ab dem 2. August 2026 zur Transparenz gegenüber Personen, die mit KI-Systemen interagieren. Wer mit einem Chatbot kommuniziert, muss das wissen. Wer KI-generierte Inhalte konsumiert, muss das erkennen können.

Das löst man nicht erst über UX, sondern über die Architektur. Die Kennzeichnung muss für Menschen unmittelbar erkennbar sein, eine maschinenlesbare Markierung in Metadaten allein reicht nicht. Für Unternehmen, die generative KI im Content-Bereich einsetzen – Produktbeschreibungen, Marketing-Texte, automatisierte E-Mails – hat das direkte operative Konsequenzen. Die Kennzeichnungsprozesse müssen in die Produktionsprozesse integriert werden. Nachträglich ist das aufwendig.

Und ja: Das betrifft auch die interne Nutzung. Wenn zum Beispiel KI im Recruiting eingesetzt wird, haben Bewerber ein Recht darauf, das zu wissen.

Nachgerüstet vs. von Anfang an gebaut – Der Unterschied

Ich erlebe das in Projekten immer wieder. Es gibt zwei Szenarien:

Szenario A: Das System läuft. Compliance kommt nach.

Audit-Logs werden als paralleles Projekt umgesetzt. Das bedeutet, bestehende Entscheidungslogik muss rückwirkend dokumentiert werden – häufig ohne vollständige Daten. Human-Oversight-Punkte werden als Notschalter eingebaut, nicht als architektonischer Bestandteil. Das kostet Zeit, Budget und erzeugt technische Schulden.

Szenario B: Compliance ist Architekturbestandteil.

Protokollierung läuft von Beginn an mit. Jede Entscheidung des Systems ist nachvollziehbar. Oversight-Punkte sind Teil des Systemdesigns. Provenance ist nicht Aufgabe des Dokumentationsteams, sondern des Datenpipeline-Designs.

Der Unterschied in der Umsetzung ist nicht dramatisch. Der Unterschied im Ergebnis ist erheblich. Wer einmal baut, hat ein saubereres System. Wer zweimal baut, hat Schulden und eine Compliance-Dokumentation, die nie ganz stimmt.

Bei communicode sind Provenance, Audit-Logs und Human-Oversight-Punkte Architekturbestandteile jedes KI-Integrationsprojekts – Teil unseres AI-Governance-Ansatzes innerhalb der Agentic Architecture. Kein Pflaster, das wir hinten draufkleben.

Die wichtigste Frage für Sie

Ich schreibe diesen Artikel nicht für Jurist:innen. Ich schreibe ihn für Entscheider:innen im IT-Bereich – Digitalleiter:innen, IT-Leiter:innen, E-Commerce-Leiter:innen etc. – die gerade einschätzen müssen, wo ihr Unternehmen steht.

Die ehrliche Frage lautet: Können Sie heute, ohne nachzuforschen, sagen, was Ihr KI-System gestern entschieden hat und warum?

Wenn die Antwort nein ist, haben Sie ein Audit-Log-Problem. Wenn Sie nicht wissen, ob Ihre Systeme Hochrisiko sind, haben Sie ein Klassifizierungsproblem. Wenn KI-Outputs bei Ihnen ohne definierten Oversight-Punkt live gehen, haben Sie ein Governance-Problem.

Keines dieser Probleme ist unlösbar. Aber keines löst sich von selbst.

Was jetzt zu tun ist – Kurze Orientierung

Die Frist für Transparenzpflichten ist der 2. August 2026. Das sind keine drei Monate mehr. Das sind nur noch zwei Wochen.

Für Hochrisiko-Systeme gilt aktuell der 2. Dezember 2027. Das ist zwar mehr Zeit, aber keine Einladung zum Abwarten. Die inhaltlichen Anforderungen ändern sich durch die Fristverschiebung nicht. Was sich ändert, ist der Zeitpunkt, ab dem sie durchgesetzt werden.

Mein Vorschlag: Beginnen Sie mit einer ehrlichen Bestandsaufnahme. Welche KI-Systeme betreiben Sie? In welche Risikoklasse fallen sie? Was ist bereits dokumentiert, was nicht?

Wenn Sie das noch nicht gemacht haben, ist jetzt der richtige Zeitpunkt. Denn ein System, das Sie nicht verstehen, ist ein System, dem Sie nicht vertrauen sollten.

Wenn Sie wissen wollen, wie AI-ready Ihre eigene Systemlandschaft ist: Unsere Reifegrad-Analyse zeigt Ihnen in wenigen Schritten, wo Sie stehen.