Die KI-Verordnung gilt als Bremse. In regulierten Branchen ist sie das Gegenteil: der Grund, warum ein zögernder Kunde endlich unterschreibt.
Der Anstoß kommt selten aus dem eigenen Haus. Er kommt als Excel-Tabelle vom größten Kunden: ein Lieferantenfragebogen, 42 Zeilen, und in Zeile 31 steht: „Setzen Sie KI-Systeme im Sinne des EU AI Act (Verordnung (EU) 2024/1689) ein? Wenn ja, in welcher Rolle?“ Der Engineering Lead weiß, dass das Team Claude Code einsetzt. Was er nicht weiß: ob das Unternehmen damit Anbieter, Betreiber oder etwas Drittes ist, und ob die ehrliche Antwort den Rahmenvertrag gefährdet. Also landet die Zeile bei der Compliance-Abteilung. Das Compliance-Team setzt einen Termin an, und dort reden vier Leute über vier verschiedene Regelwerke, als wären sie dasselbe.
Das muss nicht sein. Der Satz, der diese Sitzung rettet, lautet: Die KI-VO ist nicht die DSGVO. Ich bin kein Anwalt, und was folgt, ist eine Gesprächsgrundlage für genau diese Runde, keine Rechtsberatung.
Kurz gefasst: Bei üblichen Rollouts von Coding Agents ist Ihr Unternehmen meist Betreiber, nicht Anbieter. Der Agent selbst ist in der Regel kein Hochrisiko-System. Relevant bleiben Art. 4 zur KI-Kompetenz, mögliche Transparenzpflichten nach Art. 50 und die Frage, ob vom Agenten erzeugter oder geänderter Code in Hochrisiko-Systeme fließt. Der praktische Nachweis besteht aus einer dokumentierten Einführung, einer Klassifikation der Repositorys und Review-Stufen nach Risiko.
Wie sich diese Einordnung ins Gesamtbild fügt, zeigt der Leitfaden, der die KI-VO neben Rollout, Tooling und Messung einordnet.
Vier Regelwerke, ein Tisch, eine Verwechslung
Die gute Nachricht zuerst: Jedes der vier Regelwerke hat einen anderen Zweck. Sie müssen keines davon neu erfinden. Entscheidend ist nur, sie sauber auseinanderzuhalten.
Die DSGVO schützt personenbezogene Daten. Beim Einsatz eines Coding-Agenten lautet die Frage: Verarbeitet er personenbezogene Daten, etwa aus Test-Fixtures oder Commit-Nachrichten? Wie Sie das klären, steht im Beitrag dazu, was der Agent im Repository sehen darf.
Das BetrVG regelt in § 87 Abs. 1 Nr. 6 die Mitbestimmung bei technischen Einrichtungen, die Verhalten oder Leistung überwachen. Dabei kommt es nicht nur auf die Absicht des Arbeitgebers an, sondern auf die objektive Eignung der Einrichtung. Die bloße Bereitstellung des Werkzeugs ist deshalb selten der Kern. Entscheidend ist, welche personenbezogenen Nutzungsdaten entstehen und wer sie auswerten kann, etwa Telemetrie, Prompt-Protokolle, IDE-Nutzungsdaten oder Produktivitätsauswertungen pro Person. Wie das Gespräch mit dem Betriebsrat gelingt, steht in einem eigenen Beitrag.
MaRisk und DORA regeln Anforderungen an Finanzstabilität und IKT-Risikomanagement. Wer selbst nicht unter Finanzaufsicht steht, hat in der Regel kein direktes MaRisk-Thema. DORA kann trotzdem auftauchen, etwa in der Lieferantenprüfung, also dem Vendor Assessment, oder im Vertrag, sobald Sie IKT-Leistungen für ein Finanzunternehmen erbringen. Für interne Rollouts außerhalb des Finanzsektors bleibt der Ordner meist geschlossen; wer unter BaFin-Aufsicht steht oder Banken als Kunden betreut, findet die Anforderungen der BaFin an Coding Agents im eigenen Beitrag.
Die KI-VO schließlich, formal die Verordnung (EU) 2024/1689, gilt branchenübergreifend. Sie schützt Grundrechte und Sicherheit beim Einsatz von KI-Systemen, unabhängig von Branche und Datenart.
Genau da liegt die Wurzel der Verwechslung. Die KI-VO ist die einzige branchenübergreifende der vier, deshalb wird sie als „neue DSGVO“ gelesen. Sie ist es nicht. Wer sie wie die DSGVO liest, verhandelt das falsche Risiko. Denn die KI-VO stellt an Sie nur zwei Fragen: In welcher Rolle treten Sie auf, und welches Risiko hat das System, das Sie einsetzen?
Anbieter oder Betreiber: Welche Rolle hat Ihr Unternehmen nach der KI-VO?
Die erste Frage lautet: In welcher Rolle tritt Ihr Unternehmen auf? Art. 3 der KI-VO kennt den Anbieter (Nr. 3: wer ein KI-System entwickelt und unter eigenem Namen in Verkehr bringt), den Betreiber (Nr. 4, im englischen Text „deployer“: wer ein KI-System in eigener Verantwortung beruflich nutzt) und den Anbieter eines GPAI-Modells, also eines KI-Modells mit allgemeinem Verwendungszweck (Nr. 63: bei üblicher Tool-Nutzung Anthropic, OpenAI, Google oder Microsoft, nicht Ihr Unternehmen). Die Definitionen im Wortlaut stehen beim AI-Act-Service-Desk der EU-Kommission. Die Modellrolle kommt für Sie erst in Betracht, wenn Sie selbst Modelle bereitstellen, erheblich verändern oder unter eigener Verantwortung weitergeben.
Die zweite Frage betrifft die Risikokategorie. Verbotene Praktiken nach Art. 5 gelten seit dem 2. Februar 2025: Social Scoring, manipulative Systeme und Emotionserkennung am Arbeitsplatz sind für Coding Agents so gut wie immer irrelevant. Danach kommen Hochrisiko-Systeme nach Art. 6 in Verbindung mit Anhang III und Anhang I, Transparenzpflichten nach Art. 50 und schließlich das minimale Risiko als Auffangkategorie ohne eigene Pflichten.
Ein deutsches Unternehmen, das Claude Code, Cursor oder Copilot einsetzt, ist damit in aller Regel Betreiber eines KI-Systems mit minimalem Risiko. Das ist die erste ruhige Antwort für die Sitzung, und für Zeile 31 des Fragebogens.
Aber die Rolle kann kippen. Art. 25 macht aus dem Betreiber einen Anbieter, wenn er ein Hochrisiko-System unter eigener Marke weitervertreibt, es wesentlich verändert oder seine Zweckbestimmung so ändert, dass es hochriskant wird. Die saubere Formel lautet deshalb: Wir sind Betreiber, minimales Risiko, es sei denn, eine der drei Bedingungen aus Art. 25 greift. Bei fast allen Teams greift keine davon. Ein Coding-Agent, der Pull Requests vorbereitet, wird nicht dadurch hochriskant, dass Sie ihm einen eigenen System-Prompt geben.
Die einfachste Pflicht gilt schon
Während alle auf 2027 starren, gilt eine Pflicht der KI-Verordnung schon seit dem 2. Februar 2025: Art. 4 zur KI-Kompetenz, für Anbieter und Betreiber gleichermaßen. In Compliance-Runden wird sie oft als KI-Schulungspflicht bezeichnet und regelmäßig übersehen. Das trifft es aber nur zur Hälfte. Die bisherige Fassung verlangt, dass Personal und beauftragte Dritte über ein ausreichendes Maß an KI-Kompetenz verfügen, bemessen an Vorkenntnissen und Einsatzkontext. Die beschlossene Omnibus-Fassung formuliert zurückhaltender: Anbieter und Betreiber müssen Maßnahmen ergreifen, um diese Kompetenz zu fördern. Ein festes Kompetenzniveau jeder einzelnen Person müssen sie nicht garantieren. Für Engineering-Teams ändert das den praktischen Kern kaum.
Bei der Durchsetzung lohnt Genauigkeit. Art. 4 gehört nicht in die 35-Millionen-Drohkulisse des Art. 99, ist aber auch keine unverbindliche Empfehlung. Für Engineering-Teams zählt deshalb vor allem der Nachweis: Zielgruppe, Inhalte, Datum, Teilnehmende, Datenregeln und Vorgaben für Code-Reviews dokumentieren. Orientierung geben das Q&A der EU-Kommission zur KI-Kompetenz und das Living Repository des AI Office mit Praxisbeispielen anderer Unternehmen.
Deshalb die Entlastung: Eine kurze, dokumentierte Einführung erfüllt Art. 4 in der Regel. Sie beantwortet vier Fragen: was das Werkzeug kann, wo seine Grenzen liegen, wie Vorschläge des Agenten geprüft werden und welche Daten nicht in den Prompt gehören. Dieselbe Einführung liefert nebenbei Material für Fragen, die auch bei § 87 BetrVG und, unter Finanzaufsicht, bei MaRisk auftauchen: Wer nutzt das Werkzeug, welche Daten entstehen, wie wird geprüft und wo liegen die Grenzen? Eine Pflicht, drei Baustellen. Und ein Team, das diese vier Fragen aus dem Stand beantwortet, ist das Team, das ein regulierter Kunde sehen will.
Wenn der Code in einem Hochrisiko-System landet
Der Coding-Agent selbst ist selten ein Hochrisiko-System. Aber „nicht Hochrisiko“ heißt nicht „unreguliert“: Art. 4 gilt ohnehin, und Art. 50 kann greifen, wenn Menschen direkt mit einer KI-Funktion Ihres Produkts interagieren oder Ihr Produkt Inhalte erzeugt. Wichtiger ist oft der umgekehrte Fall. Der Code, den der Agent schreibt, landet manchmal in Systemen aus Anhang III: Bewerberauswahl und Personalentscheidungen (Nr. 4), Kreditwürdigkeitsprüfung natürlicher Personen (Nr. 5, mit ausdrücklicher Ausnahme für die Betrugserkennung), Risikobewertung und Preisbildung bei Lebens- und Krankenversicherungen (ebenfalls Nr. 5). Bei Medizinprodukten kommt Anhang I dazu.
Dann greifen die Anforderungen aus Art. 9 bis 15, von Risikomanagement bis Cybersicherheit. Sie gelten für das Hochrisiko-System, nicht für den Coding-Agenten.
Der Coding-Agent wird also nicht automatisch hochriskant, nur weil sein Code in einem Hochrisiko-System landet.
Die Pflichten aus Art. 9 bis 15 treffen vor allem den Anbieter des Hochrisiko-Systems, also meist das Unternehmen, das es baut und verantwortet. Betreiber solcher Systeme haben daneben eigene Pflichten. Für Engineering bleibt die praktische Frage trotzdem klar: Welche Repositorys liefern Code in Hochrisiko-Systeme, und wie streng werden Änderungen durch den Agenten dort geprüft?
Art. 15 verlangt für solche Systeme ausdrücklich Schutz gegen Data Poisoning, also manipulierte Trainings- oder Eingangsdaten, und adversariale Angriffe. Genau dort werden fehlerhafte Ausgaben des Agenten zum Compliance-Thema.
Die Antwort aus dem Engineering ist Architektur, kein Papierkrieg. Dokumentiert wird nicht der Agent. Dokumentiert wird, welche Repositorys Code für Anhang-III-Systeme enthalten. Für diese Repos legen Sie fest, welche Prüftiefe für Änderungen durch den Agenten gilt. Ich nenne das Risk Lanes: Risikoklassen mit passenden Review-Stufen, beschrieben im Beitrag zum Engpass im Pull Request. Wie dieselbe Logik unter Finanzaufsicht aussieht, zeigt der Blick auf BaFin und MaRisk. Meine Faustregel: Wenn Sie nicht sagen können, welche Repos Code für Anhang-III-Systeme enthalten, muss zuerst das Engineering antworten, nicht die Compliance-Abteilung.
Und Sie haben Zeit dafür. Der Digital Omnibus, das EU-Änderungspaket zur Vereinfachung der Digitalgesetze, hat die Hochrisiko-Fristen verschoben: Anhang III (eigenständige Hochrisiko-Systeme) auf den 2. Dezember 2027, Anhang I (in Produkte eingebettet) auf den 2. August 2028. Die Transparenzpflichten nach Art. 50 bleiben grundsätzlich beim 2. August 2026; nur für bestimmte, bereits am Markt befindliche Systeme, die synthetische Inhalte erzeugen, gibt es eine Übergangsfrist bis zum 2. Dezember 2026. Das Paket ist beschlossen: Das Parlament stimmte am 16. Juni zu, der Rat am 29. Juni 2026. Im Amtsblatt stand es Anfang Juli 2026 noch nicht. Die neuen Stichtage sind also politisch beschlossen, formal aber noch nicht in Kraft. Für Sie heißt das: Sie haben Spielraum, um Risikoklassen und Review-Stufen sauber aufzusetzen. Warten müssen Sie nicht. Hetzen müssen Sie aber auch nicht.
Was die Modellanbieter schon übernehmen
Seit dem 2. August 2025 greifen die Pflichten für Anbieter von GPAI-Modellen, die nach diesem Datum auf den Markt kommen. Für Modelle, die schon vorher verfügbar waren, läuft die Übergangsfrist bis zum 2. August 2027. Art. 53 verlangt von GPAI-Anbietern wie Anthropic, OpenAI und Google technische Dokumentation, Informationen für nachgelagerte Integratoren, eine Urheberrechtsrichtlinie und eine öffentliche Zusammenfassung der Trainingsinhalte. Für die größten Modelle kommt Art. 55 dazu: Modellbewertung mit dokumentiertem Adversarial Testing, also gezielten Angriffstests, dazu Vorfallmeldung und Cybersicherheit. Der Digital Omnibus hat diese Fristen nicht angetastet, die Details erklärt das GPAI-Q&A der EU-Kommission. Als freiwilliges Nachweisinstrument dient der GPAI Code of Practice vom Juli 2025: Anthropic, OpenAI, Google und Microsoft haben unterzeichnet, Meta nicht.
Ein großer Teil der Pflichten liegt damit beim Modellanbieter, einschließlich der Dokumentation zum Modell. Bei Ihnen bleiben die Betreiberpflichten, vor allem Art. 4, dazu gegebenenfalls Transparenz und menschliche Aufsicht im eigenen Produkt. Die Urheberrechtsrichtlinie der Anbieter nimmt Ihnen das eigene Risiko beim generierten Code aber nicht ab, mehr dazu im Beitrag zum Urheberrecht an KI-generiertem Code.
Zur Einordnung der Größenverhältnisse: Verstöße von Modellanbietern ahndet die EU-Kommission separat nach Art. 101 (bis 15 Mio. Euro oder 3 Prozent des Umsatzes), nicht Sie als Betreiber. Und die Staffel des Art. 99, bis 35 Mio. Euro oder 7 Prozent für verbotene Praktiken, betrifft für ein Team mit Coding Agents fast ausschließlich andere. Für Ihren Rollout ist wichtiger, wer welche Pflicht trägt, nicht die maximale Bußgeldhöhe.
So gehen Sie in den nächsten Compliance-Termin
Gehen Sie in den nächsten Compliance-Termin nicht mit der Frage „Dürfen wir Claude Code einsetzen?“. Gehen Sie mit einer Bestandsaufnahme hinein. Vier Fragen genügen: In welcher Rolle treten wir auf? Welche Risikokategorien betreffen uns heute, in zwölf Monaten und in 24 Monaten? Wer ist bei uns für Art. 4 verantwortlich? Und welche Repos enthalten Code, der später in Anhang-III-Systemen landet? Wenn Sie diese vier Fragen beantworten können, ist die KI-VO-Diskussion zu achtzig Prozent geführt.
Der eigentliche Gewinn liegt woanders. Dieselbe Bestandsaufnahme ist das Dokument, das ein regulierter Kunde in der Lieferantenprüfung sehen will. Wer die Verantwortungskette auf einer Seite zeigen kann, beantwortet Zeile 31 des Fragebogens in einem Satz und verkürzt die nächste Due-Diligence-Runde gleich mit.
Bleibt die Frage nach der Aufsicht. In Deutschland soll die Bundesnetzagentur zentrale Marktüberwachungsbehörde werden, soweit nicht andere Fachbehörden zuständig sind. Das Durchführungsgesetz, das KI-Marktüberwachungs- und Innovationsförderungsgesetz (KI-MIG), hat der Bundestag am 11. Juni 2026 beschlossen, die Zustimmung des Bundesrats stand Anfang Juli 2026 noch aus. Der Ansprechpartner auf Behördenseite zeichnet sich also ab; an den Hausaufgaben ändert das nichts.
Ordnung ist kein Aufwand, sie ist Vorsprung
Die KI-Verordnung verbietet keine Coding Agents. Sie sortiert, wer wofür geradesteht: branchenübergreifend, mit klaren Stichtagen und nachvollziehbaren Zuständigkeiten. Wer die drei Ebenen trennt (Rolle, Risikokategorie, Stichtag), führt ein produktives Gespräch. Wer sie vermischt, verhandelt das falsche Risiko. Und in einem Markt, in dem Ihr Kunde diese Klarheit sehen will, bevor er unterschreibt, ist Ordnung kein Aufwand. Sie ist Ihr Vorsprung.
Quellen
- EUR-Lex: Verordnung (EU) 2024/1689 (KI-Verordnung / AI Act)
- EU-Kommission: AI-Act-Service-Desk, Art. 3 (Begriffsbestimmungen)
- EU-Kommission: AI Literacy, Questions & Answers (Art. 4)
- EU-Kommission: Living Repository zu KI-Kompetenz-Praktiken
- EU-Kommission: General-Purpose AI Models, Questions & Answers (Art. 53/55)
- EU-Kommission: Guidelines für Anbieter von GPAI-Modellen (Fristen und Pflichtenumfang)
- EU-Kommission: The General-Purpose AI Code of Practice
- Rat der EU: Pressemitteilung zur finalen Zustimmung zum Digital Omnibus on AI, 29. Juni 2026
- Bundesarbeitsgericht: Beschluss 1 ABR 16/23 zur Mitbestimmung bei technischen Einrichtungen
- Deutscher Bundestag: Beschluss des Durchführungsgesetzes zur KI-Verordnung (KI-MIG), 11. Juni 2026
Stand: 2. Juli 2026. Der Digital Omnibus war zu diesem Zeitpunkt beschlossen, aber noch nicht im Amtsblatt veröffentlicht. Das KI-MIG wartete auf den Bundesrat. Beide Angaben vor wichtigen Entscheidungen mit dem aktuellen Stand abgleichen.
