Das Wichtigste in Kürze

• Der AI Act reguliert KI-Systeme, nicht Entwicklungsmethoden: Deterministische Software ohne KI zur Laufzeit fällt nicht unter die Hochrisiko-Regeln, auch wenn Agenten sie gebaut haben.
• Zwei Pflichten gelten trotzdem schon: Artikel 4 (KI-Kompetenz, eine Bemühenspflicht seit Februar 2025) für jeden, der Coding-Agenten einsetzt, und die Transparenzpflichten nach Artikel 50 seit dem 2. August 2026, sobald KI zur Laufzeit mitläuft.
• Wer ein KI-System entwickeln lässt und unter eigenem Namen in Betrieb nimmt, ist Anbieter. Das gilt auch für Behörden ohne eine Zeile eigenen Code. Die Rolle gehört geklärt, bevor der Vertrag mit dem Dienstleister steht.

Wenn Agenten Code schreiben, stellt sich in fast jedem Gespräch mit Behörden und ihren IT-Dienstleistern dieselbe Frage: Was sagt eigentlich der AI Act (KI-Verordnung) dazu? Meist hören wir eine von zwei Antworten. Die einen warnen: Der AI Act gilt schon jetzt, also braucht jede agentisch gebaute Software eine KI-Compliance. Die anderen geben Entwarnung: Der AI Act wurde mit dem Digital Omnibus verschoben, also muss man vorerst gar nichts tun. Beide Antworten sind falsch, weil sie die Verordnung als einen Block behandeln. Tatsächlich stellt sie eine präzisere Frage: Wo steckt ein KI-System? In einem agentischen Entwicklungsprojekt gibt es dafür zwei Kandidaten: die Software, die am Ende in der Behörde läuft, und den Coding-Agenten, mit dem sie gebaut wird. Die Software ist meist kein KI-System. Der Agent ist eines, und irgendjemand betreibt ihn. Außerdem unterscheidet die Verordnung zwischen Pflichten, die schon gelten, und solchen, die erst kommen.

Wir bei &amp haben die Frage zuerst für unser eigenes Vorgehen geprüft und dann aus der Sicht derer, die solche Software beauftragen, abnehmen und betreiben: Behörden und deren IT-Systemhäuser. Eines vorweg: Wir sind Ingenieure, keine Juristen. Für die rechtliche Bewertung im Einzelfall ziehen wir juristischen Rat hinzu, und das empfehlen wir jedem, der vor einer Vertrags- oder Vergabeentscheidung steht. Wir halten es aber für genauso wichtig, das Verständnis selbst aufzubauen: Wer Agenten Code schreiben lässt, muss die rechtlichen Fragen in der Architektur, im Vertrag und im Kundengespräch beantworten können, nicht erst, wenn ein Jurist sie stellt. Diesen Beitrag haben wir deshalb nach bestem Wissen gegen Gesetzestexte, Gesetzesbegründungen und Urteile geprüft. Das Ergebnis liegt zwischen den beiden Antworten: deutlich handhabbarer, als die Warnung nahelegt, weil die Hochrisiko-Regeln für die meisten Fachanwendungen gar nicht einschlägig sind, und unbequemer als die Entwarnung, weil Artikel 4 und, wie Teil 2 zeigt, Vertragsrecht und Produkthaftung sehr wohl greifen.

Was der AI Act regelt und was er nicht regelt

Der AI Act knüpft an das Inverkehrbringen, die Inbetriebnahme und die Verwendung von KI-Systemen an. Seine Hochrisiko-Regeln betrachten damit das Produkt, das beim Nutzer ankommt, nicht den Herstellungsweg, auf dem es entstanden ist. Ein Agent, der Code schreibt und danach nicht mehr Teil des laufenden Systems ist, ist aus Sicht der Hochrisiko-Regeln ein Entwicklungswerkzeug. Er steht damit in einer Reihe mit dem Compiler und der Entwicklungsumgebung, nicht mit dem regulierten Produkt.

Daraus folgt die zentrale Frage, und sie ist erfreulich einfach: Steckt zur Laufzeit KI im System? Lautet die Antwort nein, ist Anhang III nicht einschlägig, und zwar auch dann nicht, wenn die Anwendung fachlich hochkritisch ist.

Ein abstrahiertes Beispiel aus der Verwaltungspraxis macht das greifbar. Eine Fachanwendung holt Daten aus einem Quellsystem, transformiert sie anhand einer festgelegten Geschäftslogik und stellt das Ergebnis als Dokument für nachgelagerte Stellen bereit. Die Verarbeitung ist vollständig deterministisch, jeder Rechenschritt ist im Code nachlesbar. Selbst wenn Agenten diese Software vollständig gebaut haben, ist das Ergebnis kein KI-System im Sinne der Verordnung. Daran ändert auch nichts, dass die Anwendung fachlich kritisch ist: Die Hochrisiko-Einstufung setzt immer ein KI-System voraus, kritische Fachlichkeit allein genügt nicht.

An dieser Stelle wird häufig zu schnell weitergedacht. Die Aussage bedeutet nicht, dass das Vorgehen unproblematisch ist. Sie bedeutet nur, dass die Hochrisiko-Vorschriften des AI Act nicht der Maßstab sind, an dem sich solche Software messen lassen muss. Wer sie trotzdem heranzieht, streitet über das falsche Gesetz, während die Fragen, die tatsächlich zählen, liegen bleiben.

Die eine Stelle, an der der AI Act den Entwicklungsprozess doch erfasst

Ganz entkommt agentische Softwareentwicklung dem AI Act allerdings nicht, und dieser Punkt geht in der öffentlichen Diskussion fast vollständig unter.

Artikel 4 verpflichtet Anbieter und Betreiber von KI-Systemen, Maßnahmen zur KI-Kompetenz ihres Personals und der Personen zu ergreifen, die in ihrem Auftrag mit KI-Systemen arbeiten. Diese Pflicht hängt nicht an einer Risikoklasse. Sie gilt für alle KI-Systeme, unabhängig davon, ob sie hochriskant sind, und sie gilt seit dem 2. Februar 2025. Wer Coding-Agenten beruflich einsetzt, ist Betreiber eines KI-Systems. Das trifft den Dienstleister, der damit entwickelt, und genauso die Behörde oder das Systemhaus, deren eigene Entwickler Agenten nutzen. Damit greift Artikel 4 unmittelbar beim Einsatz der Entwicklungsagenten, also genau im Entwicklungsprozess, den die Hochrisiko-Regeln gerade nicht erfassen.

Das ist die präzise Fassung der Lage, und sie ist wichtiger als die bequeme: Der AI Act erfasst agentische Softwareentwicklung nicht über das Risiko des gebauten Produkts, sondern über die Kompetenz der Menschen, die die Agenten bedienen. Die Anforderungen sind gering. Artikel 4 ist eine Bemühenspflicht: Verlangt sind nur Maßnahmen, die die KI-Kompetenz fördern, kein garantiertes Niveau, keine Prüfung, kein Zertifikat. Der Digital Omnibus hat das noch einmal klargestellt, dazu unten.

Aber die Aussage, der AI Act sei für den Entwicklungsprozess schlicht nicht relevant, stimmt nicht. Wer Agenten im eigenen Haus zulässt, sollte zeigen können, dass die Menschen, die sie steuern, dafür geschult sind.

Wo der AI Act Behörden und ihre Dienstleister tatsächlich trifft

Neben Artikel 4 gibt es drei Konstellationen, die eine genaue Einordnung verlangen. Diese Einordnung nehmen die Beteiligten selbst vor, eine behördliche Freigabe vorab gibt es dafür nicht. Zuerst die Frage, ob überhaupt ein KI-System entsteht und in welche Risikoklasse es fällt, dann die, wer dafür als Anbieter einsteht.

Der Agent als Teil des Auslieferungsgegenstands. Hier verläuft die Grenze, die in der Praxis am häufigsten verschwimmt. Sie lautet: Agent baut Software gegenüber Agent läuft in der Software mit. Sobald ein Agent zur Laufzeit in der Behörde Entscheidungen trifft oder auch nur vorbereitet, ist er ein KI-System im Sinne der Verordnung. Damit kippt die Antwort auf die erste Frage, und die Einordnung ist neu zu klären: in welche Risikoklasse das System fällt und wer als Anbieter dafür einsteht. Diese Grenze sauber zu ziehen und in der Architektur sichtbar zu halten, ist Architekturarbeit, die sich im Compliance-Nachweis auszahlt: Wer zeigen kann, welche Komponenten zur Laufzeit ein Modell aufrufen und welche nicht, hat in Minuten statt in Gutachten beantwortet, ob überhaupt ein KI-System vorliegt. Auftraggeber sollten sich genau diese Übersicht geben lassen, bei der Abnahme und bei jeder Erweiterung.

Die Rollenlogik: Behörde als Anbieterin ohne eine Zeile Code. Anbieter im Sinne der Verordnung ist, wer ein KI-System entwickelt oder entwickeln lässt und es unter eigenem Namen in Verkehr bringt oder in Betrieb nimmt. Lässt eine Behörde ein KI-System entwickeln und nimmt es unter eigenem Namen in Betrieb, ist sie Anbieterin dieses Systems, mit allen Pflichten seiner Risikoklasse. Dafür muss die Behörde keine Zeile Code geschrieben haben. Der Dienstleister ist in dieser Konstellation Zulieferer, und für Hochrisiko-Systeme verlangt Artikel 25 Absatz 4 eine schriftliche Vereinbarung darüber, welche Informationen, technischen Zugänge und Unterstützung er liefert.

Umgekehrt gilt für den Dienstleister: Integriert er ein fremdes KI-Modell in ein Produkt, das er unter eigenem Namen anbietet, ist er selbst Anbieter. Artikel 25 regelt, wann ein Dritter durch eigenes Etikett, wesentliche Änderung oder neue Zweckbestimmung in diese Rolle rückt. Die Antwort auf die Frage, wessen Name am Ende auf dem System steht, gehört deshalb vor die erste Zeile Integrationscode, in die Leistungsbeschreibung und in den Vertrag. Daran hängt die Rolle, und an der Rolle hängen die Pflichten.

Die Anbieterrolle für eigene KI-Produkte. Wer selbst ein KI-System in Verkehr bringt oder in Betrieb nimmt, das unter Anhang III fällt, trägt die vollen Anbieterpflichten. Das ist produktweise zu prüfen und betrifft KI-Produkte, nicht die Werkzeuge, mit denen entwickelt wird.

Der aktuelle Stand: was der Digital Omnibus wirklich geändert hat

Mit der Verordnung (EU) 2026/1744 vom 8. Juli 2026, veröffentlicht im Amtsblatt am 24. Juli 2026 und in Kraft seit dem 27. Juli 2026, hat der Unionsgesetzgeber den AI Act an mehreren Stellen entschärft.

Die Pflichten für eigenständige Hochrisiko-Systeme nach Anhang III gelten nun ab dem 2. Dezember 2027 statt ab dem 2. August 2026. Für eingebettete Systeme nach Anhang I verschiebt sich der Geltungsbeginn auf den 2. August 2028; der dort maßgebliche Begriff des Sicherheitsbauteils wurde zugleich enger gefasst. Das betrifft Maschinen, Medizinprodukte und ähnliche harmonisierte Produkte und spielt für Fachanwendungen der Verwaltung kaum eine Rolle. Artikel 4 wurde weiter abgeschwächt: Aus der Pflicht, Kompetenz nach besten Kräften sicherzustellen, wurde die Pflicht, Maßnahmen zu ergreifen, um ihre Entwicklung zu unterstützen. Die Verordnung stellt nun ausdrücklich klar, dass niemand verpflichtet ist, für irgendeine Person ein bestimmtes Niveau an KI-Kompetenz zu garantieren. Eine Bemühenspflicht war Artikel 4 schon vorher, jetzt ist sie auch als solche formuliert. An den Adressaten ändert das nichts: Die Pflicht liegt weiterhin bei Anbietern und Betreibern.

Gegenläufig, und deshalb die eigentliche Pointe: Die Transparenzpflichten nach Artikel 50 gelten seit dem 2. August 2026. Sie betreffen KI-Systeme, die mit Menschen interagieren oder Inhalte erzeugen, also etwa einen Chatbot oder eine generative Komponente in einer Fachanwendung. Das führt zurück zur Grenze aus dem vorigen Abschnitt: Für deterministisch gebaute Software ohne KI zur Laufzeit lösen sie nichts aus, für einen mitlaufenden Agenten sehr wohl.

Eine allgemeine Kennzeichnungspflicht für alles, woran eine KI mitgewirkt hat, enthält die Verordnung nicht. Für Behörden ist ein Punkt konkreter als für Entwickler: Betreiber müssen offenlegen, dass ein Text KI-erzeugt ist, wenn er veröffentlicht wird, um die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren. Ausgenommen sind Texte, die einer menschlichen Überprüfung oder redaktionellen Kontrolle unterzogen wurden und für deren Veröffentlichung jemand die redaktionelle Verantwortung trägt.

Wer also pauschal sagt, der AI Act gelte jetzt, liegt falsch. Wer sagt, er sei verschoben, liegt genauso falsch. Verschoben wurden die Hochrisiko-Pflichten. Scharf gestellt sind die Transparenzpflichten.

Fazit und Ausblick: warum das keine Entwarnung ist

Die Ausnahme in Artikel 50 gilt nur für Texte, mit denen die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse informiert wird. Ihr Gedanke aber reicht weiter und trägt die beiden folgenden Teile dieser Serie: Entscheidend ist nicht, welches Werkzeug ein Ergebnis erzeugt hat, sondern wer die Verantwortung dafür übernimmt. Für den Entwicklungsprozess selbst bleibt vom AI Act damit nur noch Artikel 4. Wer daraus schließt, agentisch gebaute Software sei rechtlich unproblematisch, macht denselben Fehler wie die Entwarnungsfraktion vom Anfang, nur eine Ebene tiefer.

Ein Maßstab für agentisch gebaute Software existiert trotzdem, er liegt nur außerhalb des AI Act, und er ist schärfer, als vielen lieb ist. Er findet sich an drei Stellen: im Vertragsrecht mit seiner Beweislast; in der Produkthaftung, die Software ab dem 9. Dezember 2026 zum Produkt macht; und im IT-Grundschutz, der seinen Blick gerade vom vorgeschriebenen Prozessschritt auf die nachweisbare Wirksamkeit richtet. Darum geht es in Teil 2 und Teil 3 dieser Serie.

Was schon nach diesem ersten Teil feststeht: Die Diskussion um agentische Softwareentwicklung dreht sich zu oft um die Frage, was das Werkzeug darf. Die rechtlich tragende Frage ist eine andere: Wer steht am Ende für das Ergebnis ein, und kann er zeigen, worauf er sich dabei gestützt hat.

Bei &amp beantworten wir diese Frage mit einem Grundsatz, den Teil 3 in die Praxis übersetzt: Wir automatisieren die Ausführung, nicht die Verantwortung.

‍