Welche Pflichten haben Entwicklungsteams unter dem EU AI Act?

Für den Normalfall – ein Team nutzt kommerzielle KI-Coding-Assistenten, um gewöhnliche Software zu bauen – ist das Pflichtenpaket klein: Die Organisation ist Betreiber (Deployer) und schuldet KI-Kompetenz-Maßnahmen für die Beschäftigten, die mit den Tools arbeiten (Art. 4, durch den Digital Omnibus 2026 zu einer „Unterstützungs“-Pflicht abgeschwächt); Transparenzpflichten nach Art. 50 greifen nur, wo Menschen mit von euch betriebenen KI-Systemen interagieren. Die schweren Anbieter-Pflichten treffen euch erst, wenn ihr selbst KI-Systeme in Verkehr bringt – und das Hochrisiko-Regime nur, wenn diese in die regulierten Kategorien fallen.

Ist die Nutzung von GitHub Copilot, Claude Code oder Cursor durch den AI Act reguliert?

Die Nutzung macht eure Organisation zum Betreiber eines KI-Systems – das löst Stand Juli 2026 wenig mehr aus als die abgeschwächte KI-Kompetenz-Pflicht; Coding-Assistenten stehen in keiner Hochrisiko-Kategorie. Die GPAI-Pflichten für die zugrunde liegenden Modelle tragen die Tool-Anbieter. Was der AI Act ausdrücklich nicht tut: die Qualität des Codes regulieren, den diese Tools erzeugen. Die bleibt eure Engineering-Verantwortung.

Was hat der Digital Omnibus im Juni 2026 geändert?

Drei Punkte sind für Entwicklungsteams relevant. Die Hochrisiko-Fristen wurden verschoben: eigenständige Annex-III-Systeme auf den 2. Dezember 2027, in regulierte Produkte eingebettete KI (Annex I) auf den 2. August 2028. Die KI-Kompetenz-Pflicht aus Art. 4 wurde von „sicherstellen“ auf „die Entwicklung von KI-Kompetenz unterstützen“ abgeschwächt. Die Transparenzpflichten nach Art. 50 blieben beim 2. August 2026, mit einer Watermarking-Schonfrist bis 2. Dezember 2026 für Bestandssysteme.

Wann wird ein Entwicklungsteam vom Betreiber zum Anbieter?

Grob: wenn es ein KI-System entwickelt oder entwickeln lässt und unter eigenem Namen in Verkehr bringt oder in Betrieb nimmt. Ein Team, das ein KI-Feature im eigenen Produkt ausliefert, bewegt sich für dieses System Richtung Anbieter-Rolle; ein Team, das KI-Tools nur zum Schreiben konventionellen Codes nutzt, nicht. Weil die Einstufung über das Pflichtenpaket entscheidet, gehört sie zu eurem Justiziariat, nicht in eine Daumenregel.

Verlangt der AI Act, dass wir KI-generierten Code verifizieren?

Als solcher nicht – der AI Act reguliert KI-Systeme, nicht den Code, den sie für euch schreiben. Kein Artikel schreibt Review oder Verifikation von Assistenten-Output für gewöhnliche Software vor. Die Gründe zu verifizieren sind Engineering- und Haftungsgründe: Die neue Produkthaftungsrichtlinie behandelt Software als Produkt, Branchenregeln verlangen nachvollziehbare Prozesse, und ungeprüfter KI-Code hat gemessene Fehlerraten. Der AI Act ist der falsche Ort, diese Pflicht zu suchen – es gibt sie trotzdem.

Was sollte ein Team jetzt realistisch tun?

Vier Dinge, keins davon dramatisch: dokumentieren, welche KI-Tools in welchen Rollen im Einsatz sind (das beantwortet die meisten Audit-Fragen); eine verhältnismäßige KI-Kompetenz-Maßnahme für die Tool-Nutzer durchführen und festhalten; prüfen, ob etwas, das ihr ausliefert, selbst ein KI-System ist – und wenn ja, mit dem Justiziariat gegen die Post-Omnibus-Fristen einstufen; und eure Verifikations- und Nachweis-Praxis schriftlich machen. Nicht weil der AI Act es verlangt, sondern weil die Nachbarregeln und euer eigenes Risiko es tun.

Compliance

EU AI Act für Entwicklungsteams

Zuletzt aktualisiert: 2026-07-02Lesezeit ca. 4 Min.

Für Teams, die mit KI-Coding-Tools gewöhnliche Software bauen, verlangt der EU AI Act weniger, als die Schlagzeilen nahelegen: Die Organisation ist Betreiber, schuldet eine (seit Juni 2026 abgeschwächte) KI-Kompetenz-Maßnahme nach Art. 4 und Transparenz nur dort, wo Menschen mit von ihr betriebenen KI-Systemen interagieren. Die schweren Pflichten treffen Anbieter von KI-Systemen – und die Hochrisiko-Fristen wurden auf Dezember 2027 und August 2028 verschoben. Was der AI Act nicht regelt: die Qualität des Codes, den eure Tools erzeugen.

Inhalt

Wo KI-Coding-Tools im Risikomodell des AI Act stehen

Rechtsstand: 2. Juli 2026. Dieser Artikel beschreibt Regulierung zur Orientierung – er ist keine Rechtsberatung; die Bewertung für eure Organisation gehört zu eurem Justiziariat.

Der AI Act sortiert Pflichten nach Rolle und Risiko. Rolle: Wer ein KI-System in Verkehr bringt, ist Anbieter; wer eins beruflich nutzt, ist Betreiber. Ein Team, das mit Copilot, Claude Code oder Cursor programmiert, ist Betreiber; die Tool-Hersteller sind Anbieter und tragen die GPAI-Pflichten für die zugrunde liegenden Modelle. Risiko: Coding-Assistenten stehen in keiner der Hochrisiko-Kategorien des Annex III – das Betreiber-Pflichtenpaket für den KI-gestützten Entwicklungsalltag ist deshalb wirklich klein.

Die Pflichten, die euer Team tatsächlich treffen

KI-Kompetenz (Art. 4). Seit dem 2. Februar 2025 schulden Organisationen ihren Beschäftigten rollen- und kontextgerechte KI-Kompetenz. Der Digital Omnibus vom Juni 2026 hat die Formulierung abgeschwächt – von „sicherstellen“ zu „die Entwicklung von KI-Kompetenz unterstützen“. Für ein Dev-Team bleibt die vernünftige Lesart eine dokumentierte, rollengerechte Schulung zu Fähigkeiten, Grenzen und Fehlermodi der Tools. Das Q&A der Kommission bestätigt: Ein bestimmtes Zertifikat ist nicht vorgeschrieben.
Transparenz (Art. 50). Gilt ab dem 2. August 2026, wo Menschen mit von euch betriebenen KI-Systemen interagieren – Chatbots, KI-generierte Inhalte Richtung Nutzer. Interne Coding-Assistenz fällt nicht darunter; ein KI-Feature in eurem Produkt womöglich schon.
Anbieter-Pflichten – nur wenn ihr selbst KI ausliefert. Bringt euer Team ein KI-System selbst in Verkehr, greifen die Anbieter-Pflichten; das Hochrisiko-Regime (wo einschlägig) gilt jetzt ab 2. Dezember 2027 (Annex III) bzw. 2. August 2028 (Annex I, eingebettet). Diese Einstufung ist eine juristische Entscheidung, keine Daumenregel.

Die Daten, die zählen – nach dem Omnibus

Datum	Was gilt	Wen es trifft
2. Feb 2025	KI-Kompetenz-Pflicht (Art. 4); Verbote (Art. 5)	Alle Anbieter und Betreiber – auch Dev-Teams
2. Aug 2025	Pflichten für GPAI-Modelle	Modell-Anbieter (eure Tool-Hersteller)
2. Aug 2026	Transparenzpflichten (Art. 50)	Betreiber nutzerzugewandter KI-Systeme
2. Dez 2026	Ende der Watermarking-Schonfrist für Bestandssysteme	Anbieter generativer Systeme
2. Dez 2027	Hochrisiko-Pflichten, eigenständige Systeme (Annex III) – verschoben von Aug 2026	Anbieter/Betreiber von Hochrisiko-KI
2. Aug 2028	Hochrisiko-Pflichten, in regulierte Produkte eingebettete KI (Annex I) – verschoben von Aug 2027	Produkthersteller mit eingebetteter KI

AI-Act-Fristen mit Relevanz für Entwicklungsteams nach dem Digital Omnibus vom Juni 2026 – der häufigste Sachfehler in diesem Feld sind veraltete Vor-Omnibus-Fristen (Stand: 2. Juli 2026).

Was der AI Act nicht regelt: euren Code

Der AI Act reguliert KI-Systeme – nicht die gewöhnliche Software, die euch diese Systeme schreiben helfen. Kein Artikel schreibt Review oder Verifikation von Assistenten-Output vor. Diese Lücke wird in beide Richtungen missverstanden: Sie bedeutet nicht, dass KI-generierter Code rechtlich sicher ungeprüft ausgeliefert werden kann – die Pflichten wohnen nur woanders. Die neue Produkthaftungsrichtlinie behandelt Software ab Dezember 2026 als Produkt, NIS2 stellt Entwicklungsrisiken unter Leitungs-Aufsicht, und Branchenregeln verlangen nachvollziehbare Prozesse. Verifikation von KI-Output ist die Engineering-Sorgfalt, die die Nachbarregeln voraussetzen – ihre praktische Form steht im Governance-Guide.

Wo Reality Graph ansetzt

Reality Graph gibt keine Compliance-Versprechen ab und fällt keine Rechtsurteile. Was es zu einer AI-Act-Haltung beiträgt, ist Dokumentation, wo heute meist Erinnerung ist: schriftliche Aufträge, Validierungsergebnisse und Prüfberichte pro KI-Coding-Run – Material, auf das euer Team zeigen kann, wenn jemand fragt, wie KI-Tools genutzt und kontrolliert werden. Ob das eine konkrete Pflicht erfüllt, entscheidet euer Justiziariat, nicht wir.

Diese Orientierung gibt euch

Die Betreiber/Anbieter-Unterscheidung, die eure Pflichten sortiert
Post-Omnibus-Fristen statt veralteter 2026er-Termine
Die ehrliche Grenze: Der AI Act reguliert eure Codequalität nicht
Eine kurze, konkrete To-do-Liste ohne Alarmismus

Sie gibt euch nicht

Rechtsberatung oder eine Einstufung eurer Systeme
Eine Compliance-Garantie für irgendein Tool, auch nicht Reality Graph
Jede Sonderkonstellation – dafür gibt es euer Justiziariat
Einen Grund, Verifikation zu überspringen – diese Pflicht wohnt außerhalb des AI Act

Wenn diese Grenzen zu eurem Team passen:

Early Access sichern So funktioniert es

FAQ

Welche Pflichten haben Entwicklungsteams unter dem EU AI Act?: Für den Normalfall – ein Team nutzt kommerzielle KI-Coding-Assistenten, um gewöhnliche Software zu bauen – ist das Pflichtenpaket klein: Die Organisation ist Betreiber (Deployer) und schuldet KI-Kompetenz-Maßnahmen für die Beschäftigten, die mit den Tools arbeiten (Art. 4, durch den Digital Omnibus 2026 zu einer „Unterstützungs“-Pflicht abgeschwächt); Transparenzpflichten nach Art. 50 greifen nur, wo Menschen mit von euch betriebenen KI-Systemen interagieren. Die schweren Anbieter-Pflichten treffen euch erst, wenn ihr selbst KI-Systeme in Verkehr bringt – und das Hochrisiko-Regime nur, wenn diese in die regulierten Kategorien fallen.
Ist die Nutzung von GitHub Copilot, Claude Code oder Cursor durch den AI Act reguliert?: Die Nutzung macht eure Organisation zum Betreiber eines KI-Systems – das löst Stand Juli 2026 wenig mehr aus als die abgeschwächte KI-Kompetenz-Pflicht; Coding-Assistenten stehen in keiner Hochrisiko-Kategorie. Die GPAI-Pflichten für die zugrunde liegenden Modelle tragen die Tool-Anbieter. Was der AI Act ausdrücklich nicht tut: die Qualität des Codes regulieren, den diese Tools erzeugen. Die bleibt eure Engineering-Verantwortung.
Was hat der Digital Omnibus im Juni 2026 geändert?: Drei Punkte sind für Entwicklungsteams relevant. Die Hochrisiko-Fristen wurden verschoben: eigenständige Annex-III-Systeme auf den 2. Dezember 2027, in regulierte Produkte eingebettete KI (Annex I) auf den 2. August 2028. Die KI-Kompetenz-Pflicht aus Art. 4 wurde von „sicherstellen“ auf „die Entwicklung von KI-Kompetenz unterstützen“ abgeschwächt. Die Transparenzpflichten nach Art. 50 blieben beim 2. August 2026, mit einer Watermarking-Schonfrist bis 2. Dezember 2026 für Bestandssysteme.
Wann wird ein Entwicklungsteam vom Betreiber zum Anbieter?: Grob: wenn es ein KI-System entwickelt oder entwickeln lässt und unter eigenem Namen in Verkehr bringt oder in Betrieb nimmt. Ein Team, das ein KI-Feature im eigenen Produkt ausliefert, bewegt sich für dieses System Richtung Anbieter-Rolle; ein Team, das KI-Tools nur zum Schreiben konventionellen Codes nutzt, nicht. Weil die Einstufung über das Pflichtenpaket entscheidet, gehört sie zu eurem Justiziariat, nicht in eine Daumenregel.
Verlangt der AI Act, dass wir KI-generierten Code verifizieren?: Als solcher nicht – der AI Act reguliert KI-Systeme, nicht den Code, den sie für euch schreiben. Kein Artikel schreibt Review oder Verifikation von Assistenten-Output für gewöhnliche Software vor. Die Gründe zu verifizieren sind Engineering- und Haftungsgründe: Die neue Produkthaftungsrichtlinie behandelt Software als Produkt, Branchenregeln verlangen nachvollziehbare Prozesse, und ungeprüfter KI-Code hat gemessene Fehlerraten. Der AI Act ist der falsche Ort, diese Pflicht zu suchen – es gibt sie trotzdem.
Was sollte ein Team jetzt realistisch tun?: Vier Dinge, keins davon dramatisch: dokumentieren, welche KI-Tools in welchen Rollen im Einsatz sind (das beantwortet die meisten Audit-Fragen); eine verhältnismäßige KI-Kompetenz-Maßnahme für die Tool-Nutzer durchführen und festhalten; prüfen, ob etwas, das ihr ausliefert, selbst ein KI-System ist – und wenn ja, mit dem Justiziariat gegen die Post-Omnibus-Fristen einstufen; und eure Verifikations- und Nachweis-Praxis schriftlich machen. Nicht weil der AI Act es verlangt, sondern weil die Nachbarregeln und euer eigenes Risiko es tun.

Weiterlesen

ComplianceDSGVO-konform mit KI programmierenCode ist selten personenbezogen – der Kontext, den KI-Tools einlesen, oft schon. Die Acht-Punkte-Checkliste: Datenfluss, AVV nach Art. 28, Transfers, Trainings-Opt-outs, Minimierung. Bewertung beim DSB.ComplianceAudit-Trails für KI-generierten CodeGit protokolliert, was sich änderte – nicht den Auftrag, die Validierung, die Freigabe. Die fünf Auditor-Fragen, warum der Druck unter NIS2 und neuer Produkthaftung steigt und wie man den Trail aufbaut.Alle ArtikelDie ganze Sammlung – 43 belegte, datierte Guides zur Prüfung von KI-generiertem Code.