Zum Inhalt springen

Compliance

KI-Coding in regulierten Branchen

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

KI-Coding in regulierten Branchen ist nicht verboten – es ist an Bedingungen geknüpft. DORA, IEC 62304/MDR und ISO 26262/Automotive SPICE regulieren den Entwicklungsprozess und seine Nachweise, nicht den Autor des Codes: Dieselbe Verifikation, dieselbe Nachvollziehbarkeit, derselbe dokumentierte Lebenszyklus gelten, ob Mensch oder Assistent die Änderung schrieb. Was KI verschiebt, sind Volumen und Herkunft – das macht die Nachweisseite schwerer und wichtiger, nicht den Einsatz illegal.

Inhalt

Das gemeinsame Prinzip: Regeln binden den Prozess, nicht den Autor

Rechtsstand: 2. Juli 2026. Dieser Artikel beschreibt Branchenregulierung zur Orientierung – er ist keine Rechtsberatung; die Bewertung gehört zu eurem QA-, Regulatory- und Rechts-Team.

Keins der großen Regelwerke fragt, wer den Code getippt hat. Sie fragen, ob der Code einen definierten Prozess durchlaufen hat, ob Verifikation belegt, dass er funktioniert, und ob sich eine Anforderung bis zu Implementierung und Test verfolgen lässt. Deshalb ist die ehrliche Antwort auf „dürfen wir?“ fast immer ja – und die ehrliche Anschlussfrage härter: KI erhöht das Code-Volumen, während die Qualitätsgarantie weiterhin aus eurem Prozess kommen muss, nicht aus dem Tool.

Die drei Branchen im Überblick

BrancheZentrale RegelwerkeWas sie für KI-Code verlangen
Finanz (Fintech, Banken, Versicherer)DORA (seit Jan. 2025), EBA-/EIOPA-GuidanceKI-Tool als gesteuerter IKT-Drittanbieter; Secure-Development-Lifecycle erfasst generierten Code; Incident-Zuordnung
MedizintechnikMDR, IEC 62304, ISO 13485; AI Act Annex I (Aug. 2028), wenn das Produkt KI enthältLückenlose Lebenszyklus-Nachweise pro Änderung; V&V unabhängig von Autorschaft; Herkunft in der technischen Dokumentation
AutomotiveISO 26262, Automotive SPICE, TISAX; UNECE R155/156Nachvollziehbarkeit Anforderung→Test; Prozessreife inkl. KI-Einsatz; strenge Vertraulichkeit von Code und Prototypen
Was die drei regulierten Branchen verlangen, wenn KI Code schreibt – die Forderungen unterscheiden sich in der Tiefe, nicht in der Art: Prozess, Nachweis, Nachvollziehbarkeit (Stand: Juli 2026).

Die Tiefe variiert – ein 62304-Lebenszyklus dokumentiert mehr pro Änderung als ein DORA-IKT-Rahmen –, aber die Form wiederholt sich. Bemerkenswert: Hersteller, deren Medizinprodukt selbst KI enthält, tragen doppelte MDR- plus AI-Act-Compliance, mit der Frist für eingebettete KI jetzt bei August 2028 – eine Produktfrage, getrennt vom KI-Einsatz beim Schreiben konventionellen Geräte-Codes.

Wo KI-Coding tatsächlich Reibung erzeugt

  • Volumen vs. Nachweis. Der Lebenszyklus verlangt Nachweise pro Änderung; KI multipliziert Änderungen. Ohne Nachweise pro Run wächst die Dokumentationsschuld genauso schnell wie der Produktivitätsgewinn.
  • Nachvollziehbarkeit vs. verschwommene Autorschaft. „Welche Anforderung setzt diese Änderung um?“ braucht eine Antwort pro KI-Run – was voraussetzt, dass der Run überhaupt einen schriftlichen Auftrag hatte.
  • Vertraulichkeit vs. Cloud-Kontext. OEM-Klauseln, patientennaher Code und Trading-Logik sind genau das, was kontextbewusste Tools einlesen. Die BSI/ANSSI-Empfehlungen behandeln diesen Datenpfad als Risiko erster Klasse; lokale Verarbeitung verkürzt die Analyse.

Das praktische Setup, das alle drei Formen bedient

Weil die Regelwerke auf Prozess, Nachweis und Nachvollziehbarkeit zulaufen, bedient ein Setup alle drei als Basisschicht: ein schriftlicher, prüfbarer Auftrag pro KI-Run (der Nachvollziehbarkeits-Anker), Verifikation der Änderung gegen diesen Auftrag, bevor sie in den regulierten Lebenszyklus eintritt, und ein Nachweis pro Run über das Geprüfte – der Audit-Trail, nach dem eure Prüfer fragen werden. Branchentiefe (Sicherheitsanalysen, klinische Bewertung, ASIL-Klassifizierung) baut dann auf einem dokumentierten Fundament auf statt auf Rekonstruktion. Die Richtlinien-Seite steht im Governance-Guide.

Wo Reality Graph ansetzt

Reality Graph liefert diese Basisschicht: Verifikation jedes KI-Coding-Runs gegen seinen schriftlichen Auftrag, innerhalb eurer Umgebung – verträglich mit den Vertraulichkeitsregeln, die Cloud-Kontext in diesen Branchen schwer machen – mit einem Prüfbericht pro Run. Es ist kein Medizin-, Automotive- oder Finanz-Compliance-Produkt und trägt keine Branchen-Zertifizierung – es speist euren regulierten Prozess mit Dokumentation; das Konformitätsurteil bleibt bei euren Prüfern.

Diese Orientierung gibt euch

  • Das Autor-vs.-Prozess-Prinzip, das die Branchenfrage aufschließt
  • Drei Branchen auf ihre realen Regelwerke abgebildet, datiert
  • Die drei echten Reibungspunkte, ohne Alarmismus benannt
  • Ein Basis-Setup, das zu allen drei Nachweis-Formen passt

Sie gibt euch nicht

  • Rechts- oder Regulatory-Beratung – die gehört QA/RA/Justiziariat
  • Eine Konformitäts-Vorbewertung für ein konkretes Produkt
  • Branchentiefe – die 62304- oder 26262-Arbeit beginnt nach dieser Seite
  • Die Behauptung, irgendein Tool sei für regulierten Einsatz „zugelassen“

Wenn diese Grenzen zu eurem Team passen:

FAQ

Dürfen regulierte Unternehmen KI-Coding-Tools einsetzen – und unter welchen Bedingungen?
Grundsätzlich ja, denn die Regelwerke regulieren den Entwicklungsprozess und seine Nachweise, nicht die Autorschaft des Codes. Die wiederkehrenden Bedingungen: Der Code durchläuft dieselbe definierte Verifikation und Validierung, egal wer oder was ihn geschrieben hat; die Nachvollziehbarkeit von Anforderung über Implementierung bis Test bleibt intakt; die Datenflüsse der Tools respektieren Vertraulichkeitsregeln; und der Einsatz selbst ist risikobewertet und dokumentiert. Branchenregeln und eure Benannte Stelle bzw. Aufsicht ergänzen Spezifika – die Bewertung liegt bei ihnen und eurem QA-/Regulatory-Team.
Was bedeutet DORA für KI-Coding in Finanzunternehmen?
DORA (anwendbar seit Januar 2025) macht IKT-Risikomanagement für Finanzunternehmen zur regulierten Disziplin – einschließlich sicherer Entwicklungspraktiken und Steuerung von IKT-Drittanbietern. Ein KI-Coding-Tool tritt zweimal auf: als Drittanbieter-Dienst, dessen Datenpfad und Vertrag gemanagt werden müssen, und als Einfluss auf Code, der trotzdem euren Secure-Development-Lifecycle durchlaufen muss. DORA nennt KI-Tools nicht; die Aufsicht fragt, wie euer IKT-Risikorahmen sie abdeckt.
Darf KI-generierter Code in ein Medizinprodukt?
IEC 62304 und die MDR regulieren den Software-Lebenszyklus – Anforderungen, Architektur, Implementierung, Verifikation, Wartung – und verlangen dokumentierte Nachweise auf jeder Stufe. Code, der in diesen Lebenszyklus eintritt, muss dieselbe Verifikation bestehen, ob Mensch oder Assistent ihn schrieb; was sich mit KI ändert, sind Volumen ungeprüften Inputs und das Gewicht der Herkunft. Hersteller, deren Produkt selbst KI enthält, treffen zusätzlich AI-Act-Pflichten (Annex-I-Frist jetzt August 2028). Das Konformitätsurteil bleibt bei eurer Benannten Stelle.
Wie geht Automotive mit KI-generiertem Code um?
Mit den Instrumenten, denen die Branche schon vertraut: ISO 26262 für funktionale Sicherheit und Automotive SPICE für Prozessreife, beide auf Nachvollziehbarkeit gebaut – jede Anforderung bildet auf Implementierung und Test ab. KI-generierter Code bricht dieses Modell nicht; er belastet es, weil das Volumen steigt und die Autorschaft verschwimmt. OEM-Vertraulichkeitsklauseln und TISAX ergänzen die Datenfluss-Frage: Repository-Kontext, der ein Cloud-Tool erreicht, ist genau das Material, das diese Klauseln schützen.
Gibt es eine Branche, in der KI-Coding-Tools schlicht verboten sind?
Uns ist Stand Juli 2026 kein generelles Verbot in den großen EU-Regelwerken bekannt – die Regeln regulieren durchgängig Prozess, Nachweis und Datenschutz statt Tool-Kategorien zu verbieten. Praktische Verbote existieren lokal: OEM- oder Kundenverträge, die externe Code-Verarbeitung ausschließen, Air-Gapped-Umgebungen, in denen Cloud-Tools physisch nicht funktionieren, und interne Richtlinien. Prüft Verträge vor Regelwerken – sie binden zuerst.
Was ist der gemeinsame Nenner über alle drei Branchen?
Nachweis vor Autorschaft. Jedes Regelwerk in diesem Artikel läuft auf dieselben drei Forderungen zu: ein definierter Prozess, den der Code durchlaufen hat, Verifikationsergebnisse, die das belegen, und Nachvollziehbarkeit, die Änderung mit Anforderung verknüpft. Teams, die jeden KI-Run gegen einen schriftlichen Auftrag verifizieren und den Nachweis aufbewahren, erfüllen die Form aller drei – die branchenspezifische Tiefe kommt dann obendrauf.

Weiterlesen

Quellen

Die Beta verfolgen – oder testen, sobald sie öffnet?

Early Access anfragen