KI in der Softwareentwicklung regulierter Branchen: So bleiben Nachvollziehbarkeit und Compliance gewahrt

Das Wichtigste in Kürze Banken, Versicherungen, Zahlungsdienstleister, Medizintechnikunternehmen und Industrieunternehmen stehen unter demselben Druck wie alle anderen, Software schneller auszuliefern. Viele von ihnen zögern jedoch beim Einsatz von KI in der Softwareentwicklung, weil sie befürchten, die Kontrolle darüber zu verlieren, was in Produktion geht und wie sich das gegenüber Prüfern erklären lässt. Diese Sorge ist berechtigt, die daraus gezogene Schlussfolgerung jedoch oft nicht. Aufsichtsbehörden verbieten KI in der Softwareentwicklung selten; sie erwarten Verantwortlichkeit, Nachvollziehbarkeit und Nachweise. Ein Entwicklungsprozess, der auf diesen Prinzipien aufbaut, kann KI sicher nutzen und trotzdem jede Prüfung bestehen. Dieser Beitrag zeigt, worauf es Aufsichtsbehörden tatsächlich ankommt, wo KI mit geringem Risiko eingesetzt werden kann, welche Kontrollen KI-gestützte Entwicklung prüfungsfest machen und welche Ergebnisse ein reguliertes Unternehmen realistisch erwarten kann.
Warum regulierte Unternehmen zögern
In den meisten regulierten Unternehmen beginnt die Diskussion über KI in der Softwareentwicklung mit einer Liste von Bedenken. Rutscht KI-generierter Code am Review vorbei? Können wir belegen, wer eine Änderung freigegeben hat? Verlassen proprietärer Code oder Kundendaten das Unternehmen? Was sagt die Prüfung dazu?
Diese Fragen sind berechtigt. In der Praxis ist das größte Risiko aber oft nicht die KI selbst, sondern ihr unkontrollierter Einsatz. Verbietet ein Unternehmen KI-Tools grundsätzlich, nutzen Entwickler sie häufig trotzdem, über private Konten und im Browser. Das Ergebnis ist die schlechteste aller Varianten: kein Produktivitätsgewinn auf Unternehmensebene und keinerlei Kontrolle.
Die zielführendere Frage lautet daher nicht, ob KI eingesetzt werden soll, sondern wie sie so eingesetzt werden kann, dass jede Änderung erklärbar, überprüfbar und einer verantwortlichen Person zuzuordnen bleibt.
Worauf es Aufsichtsbehörden tatsächlich ankommt
Die regulatorischen Rahmenwerke unterscheiden sich je nach Branche und Land, doch ihre Anforderungen an die Softwareentwicklung beruhen auf wenigen wiederkehrenden Prinzipien.
Verantwortlichkeit. Für jede Änderung, die in Produktion geht, ist eine benannte Person verantwortlich. KI kann unterstützen, aber keine Verantwortung übernehmen.
Nachvollziehbarkeit. Es muss rekonstruierbar sein, wer was geändert hat, warum, auf Grundlage welcher Anforderung und wer die Änderung geprüft und freigegeben hat.
Funktionstrennung. Wer eine Änderung schreibt, sollte sie nicht allein freigeben. Das Vier-Augen-Prinzip gilt unabhängig davon, ob Code von Hand oder mit KI-Unterstützung entstanden ist.
Management von Drittanbieterrisiken. Externe Tools und Dienstleister, die Code oder Daten des Unternehmens verarbeiten, gehören zur Risikolandschaft und müssen entsprechend bewertet werden.
Datenschutz und Vertraulichkeit. Personenbezogene Daten, Kundendaten und Geschäftsgeheimnisse dürfen nicht in Systeme gelangen, deren Nutzung das Unternehmen nicht kontrolliert.
Nachweise. Kontrollen zählen nur, wenn sie belegt werden können. Prüfer suchen nach Aufzeichnungen, nicht nach Absichten.
Mehrere Regelwerke machen diese Prinzipien konkret. Im Finanzsektor der EU gilt seit Januar 2025 der Digital Operational Resilience Act (DORA) mit Anforderungen an das IKT-Risikomanagement, die Meldung von Vorfällen und das Management von IKT-Drittdienstleistern; die Aufsicht erfolgt in Deutschland durch die BaFin und in Österreich durch die FMA. (DORA ist nicht mit den gleichnamigen DORA-Metriken zur Messung der Softwareauslieferung zu verwechseln, auf die wir weiter unten ebenfalls eingehen.) Die KI-Verordnung der EU (AI Act) verpflichtet Unternehmen, die KI-Systeme einsetzen, seit Februar 2025, für ausreichende KI-Kompetenz ihres Personals zu sorgen. Die DSGVO regelt jede Verarbeitung personenbezogener Daten. In der Medizintechnik legt IEC 62304 die Anforderungen an den Lebenszyklus von Medizinprodukte-Software fest, in der Automobilindustrie spielen Rahmenwerke wie ISO 26262 und Automotive SPICE eine vergleichbare Rolle.
Ein Aspekt wird in Deutschland und Österreich häufig übersehen: die Mitbestimmung. Tools und Kennzahlen, die geeignet sind, Verhalten oder Leistung von Beschäftigten zu überwachen, unterliegen in Deutschland der Mitbestimmung des Betriebsrats (§ 87 Abs. 1 Nr. 6 BetrVG); in Österreich sieht das Arbeitsverfassungsgesetz vergleichbare Beteiligungsrechte vor. Wer KI-Tools und Delivery-Metriken einführt, sollte den Betriebsrat daher frühzeitig einbinden und klarstellen, dass Kennzahlen auf Team- und nicht auf Personenebene ausgewertet werden.
Keines dieser Regelwerke verbietet KI-gestützte Softwareentwicklung. Alle verlangen jedoch, dass der Entwicklungsprozess kontrolliert und dokumentiert bleibt.
Wo KI mit geringem Risiko eingesetzt werden kann
Nicht jeder KI-Einsatz birgt dasselbe Risiko. Ein sinnvoller Ansatz beginnt dort, wo der Nutzen hoch und die Compliance-Auswirkung gering ist, und wird dann schrittweise erweitert.
Je höher die regulatorische Relevanz des Codes, desto stärker muss die menschliche Kontrolle sein. Das bedeutet nicht, dass KI aus kritischen Bereichen ausgeschlossen ist, doch ihre Rolle verschiebt sich vom Autor zum Assistenten, etwa beim Erklären von Code, beim Vorschlagen von Tests oder beim Hinweis auf mögliche Probleme.
Ein Compliance-konformer Entwicklungsprozess mit KI
Ein Entwicklungsprozess, der KI nutzt und dennoch prüfungsfest bleibt, beruht auf wenigen Kontrollen. Die meisten davon erweitern Praktiken, die regulierte Unternehmen bereits kennen.
1. Tools freigeben und Anbieter bewerten. Nutzen Sie ausschließlich KI-Tools mit Enterprise-Bedingungen, die die Rechte am Output klären, die Verwendung von Unternehmensdaten für das Modelltraining ausschließen und festlegen, wo Daten verarbeitet werden. Für Finanzunternehmen im Anwendungsbereich von DORA sind diese Anbieter in der Regel im bestehenden Rahmen für IKT-Drittanbieterrisiken zu bewerten.
2. Klare Datenregeln festlegen. Legen Sie fest, welcher Code und welche Informationen mit KI-Tools geteilt werden dürfen. Produktivdaten, Kundendaten und Zugangsdaten sollten per Richtlinie und, wo möglich, durch technische Kontrollen ausgeschlossen sein. Das fügt sich nahtlos in ein umfassenderes KI- und Datenmanagement ein.
3. Dieselben Review-Standards anwenden. KI-gestützter Code durchläuft exakt denselben Review- und Freigabeprozess wie manuell geschriebener Code. Die Freigabe erteilt die prüfende Person, nicht das Tool, das bei der Erstellung geholfen hat, und sie bleibt dafür verantwortlich.
4. KI-Unterstützung nachvollziehbar machen. Verknüpfen Sie jede Änderung mit einem Ticket oder einer Anforderung, wie es in regulierten Teams ohnehin üblich ist. Kennzeichnen Sie zusätzlich KI-gestützte Änderungen einheitlich, etwa über Labels in Pull Requests oder Commit-Konventionen, damit Prüfer und interne Reviewer erkennen, wo KI beteiligt war.
5. Kontrollen in der Pipeline durchsetzen. Richtlinien sind nur so stark wie ihre Durchsetzung. Statische Codeanalyse, Abhängigkeits- und Lizenzscans, die Erkennung von Zugangsdaten im Code und automatisierte Tests sollten bei jeder Änderung laufen und fehlerhafte Releases blockieren. Ausgereifte DevOps- und Cloud-Sicherheitspraktiken machen diese Prüfungen zum festen Bestandteil der Auslieferung statt zu einem manuellen Nachgedanken.
6. Das Team schulen. Entwickler müssen nicht nur wissen, wie sie KI-Tools wirksam einsetzen, sondern auch, wo deren Grenzen liegen und welche Regeln gelten. Das hilft zugleich, die Anforderungen des AI Act an die KI-Kompetenz zu erfüllen.
7. Ergebnisse messen. Erfassen Sie Delivery-Kennzahlen wie Deployment-Frequenz, Durchlaufzeit von Änderungen und Change Failure Rate, ergänzt um Compliance-Indikatoren wie Freigabequoten im Review und Prüfungsfeststellungen. Die Messung belegt, dass schnellere Auslieferung nicht auf Kosten der Kontrolle geht.
Was realistisch ist: ein Beispiel aus dem Fintech-Bereich
Ein Fintech-Unternehmen aus Mittel- und Osteuropa wollte die Auslieferung neuer Funktionen beschleunigen, ohne Abstriche bei Codequalität oder Nachvollziehbarkeit für Prüfungen in seinen Entwicklungsteams zu machen. Gemeinsam mit dem Kunden haben wir den Softwareentwicklungsprozess mit Schwerpunkt auf einer Compliance-konformen Integration von KI-Tools analysiert, Workshops zu kontrollierten KI-gestützten Arbeitsabläufen durchgeführt und ein 30-Tage-Betriebshandbuch entwickelt, das auf die regulatorischen Freigabeschritte des Unternehmens abgestimmt ist.
Zu den Ergebnissen, die auf unserer Seite zur KI-gestützten Softwareentwicklung ausführlicher beschrieben sind, gehörten:
- ein Netto-Effizienzgewinn von rund 10 bis 15 Prozent über den gesamten Entwicklungsprozess,
- eine niedrigere Change Failure Rate bei vollständig erhaltener Nachvollziehbarkeit für Prüfungen,
- eine Compliance-Freigabe von 100 Prozent für alle KI-gestützten Codeänderungen,
- eine bessere Transparenz der Delivery-Leistung über alle Teams hinweg durch Dashboards mit DORA-Metriken.
Der Effizienzgewinn ist bewusst moderat. Er entspricht dem, was ein strukturierter KI-Einsatz in einem kontrollierten Umfeld typischerweise leistet, und nicht der Verdopplung der Produktivität, die Marketingmaterialien häufig versprechen. Für ein reguliertes Unternehmen ist ein nachhaltiger zweistelliger Gewinn ohne Kontrollverlust ein starkes Ergebnis.
Typische Fehler, die Sie vermeiden sollten
KI grundsätzlich verbieten. Ein Verbot verhindert die Nutzung selten; es verlagert sie in unkontrollierte Kanäle. Ein gesteuerter Einsatz ist sicherer als ein Verbot, das niemand durchsetzt.
Uneingeschränkte Nutzung zulassen. Der umgekehrte Fehler ist ebenso riskant. Ohne freigegebene Tools, Datenregeln und Review-Standards kann das Unternehmen keine Kontrolle nachweisen.
KI-Output als bereits geprüft betrachten. Auch Code, der sauber und plausibel aussieht, braucht ein sorgfältiges menschliches Review. Gut formatierter Code kann subtile Fehler verbergen.
Richtlinien schreiben, ohne sie durchzusetzen. Eine Richtlinie, die nur als Dokument existiert, überzeugt keinen Prüfer. Kontrollen müssen in der Pipeline und im Arbeitsalltag verankert sein.
Den Betriebsrat zu spät einbinden. Werden KI-Tools und Kennzahlen ohne Beteiligung der Arbeitnehmervertretung eingeführt, drohen Verzögerungen und Vertrauensverlust im Team.
Auf Messung verzichten. Ohne Ausgangswerte und laufende Kennzahlen kann das Unternehmen weder den Nutzen der KI belegen noch zeigen, dass Qualität und Stabilität erhalten geblieben sind.
Kontrolle ist die Voraussetzung für Tempo
In regulierten Branchen lautet die Frage nie nur, wie schnell sich Software ausliefern lässt, sondern wie schnell sie ausgeliefert werden kann, ohne an Erklärbarkeit und Belastbarkeit einzubüßen. KI ändert an dieser Rechnung nichts; sie erhöht aber die Bedeutung eines sauber gestalteten Prozesses. Unternehmen, die Verantwortlichkeit, Nachvollziehbarkeit und Nachweise in ihre KI-gestützte Entwicklung einbauen, können schneller und zugleich mit mehr Sicherheit vorankommen.
Dieselbe Reife wird zunehmend auch für Investoren sichtbar. In einer technischen Due Diligence ist ein kontrollierter und messbarer KI-Einsatz in der Softwareentwicklung ein klares Signal für Engineering-Qualität, während unkontrollierte Nutzung als Risikofaktor gilt. Wenn Ihr Unternehmen KI in die Softwareentwicklung einführen möchte, ohne Kompromisse bei der Compliance einzugehen, erfahren Sie auf unserer Seite zur KI-gestützten Softwareentwicklung, wie wir mit einem fokussierten, messbaren Pilotprojekt starten.
Dieser Beitrag dient ausschließlich der allgemeinen Information und stellt keine Rechts- oder Aufsichtsberatung dar. Die konkreten Anforderungen an Ihr Unternehmen hängen von Branche, Rechtsordnung und zuständiger Aufsichtsbehörde ab.
FAQ - KI in der Softwareentwicklung regulierter Branchen: So bleiben Nachvollziehbarkeit und Compliance gewahrt
Stuft der AI Act KI-Coding-Assistenten als Hochrisiko-KI-Systeme ein?
In der Regel nicht. Coding-Assistenten, die in der Softwareentwicklung eingesetzt werden, fallen üblicherweise nicht unter die im AI Act definierten Hochrisiko-Kategorien. Unternehmen, die KI-Systeme einsetzen, müssen jedoch für ausreichende KI-Kompetenz ihres Personals sorgen, und die Einstufung eines konkreten Anwendungsfalls sollte stets im Einzelfall geprüft werden.
Gelten Anbieter von KI-Tools im Sinne von DORA als IKT-Drittdienstleister?
Für Finanzunternehmen im Anwendungsbereich von DORA gehören KI-Tools, die Code oder Daten des Unternehmens verarbeiten, in der Regel zur IKT-Drittanbieterlandschaft. Sie sollten im bestehenden Rahmen für das Management von Drittanbieterrisiken bewertet werden, einschließlich Vertragsbedingungen, Ort der Datenverarbeitung und Ausstiegsoptionen.
Muss KI-generierter Code gesetzlich gekennzeichnet werden?
In den meisten Fällen besteht keine allgemeine gesetzliche Pflicht, KI-gestützten Code zu kennzeichnen. In regulierten Umgebungen ist es dennoch gute Praxis, weil es die Nachvollziehbarkeit verbessert und den Nachweis von Kontrollen bei Prüfungen erleichtert.
Muss der Betriebsrat bei der Einführung von KI-Tools beteiligt werden?
Häufig ja. In Deutschland unterliegen technische Einrichtungen, die geeignet sind, Verhalten oder Leistung der Beschäftigten zu überwachen, der Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG; in Österreich bestehen nach dem Arbeitsverfassungsgesetz vergleichbare Beteiligungsrechte. Eine frühzeitige Einbindung und eine Betriebsvereinbarung schaffen Klarheit und beschleunigen die Einführung.
Darf KI bei der Entwicklung von Medizinprodukte-Software eingesetzt werden?
Ja, sofern der Entwicklungsprozess weiterhin die Anforderungen von Normen wie IEC 62304 erfüllt, einschließlich dokumentierter Anforderungen, Verifikation, Risikomanagement und Änderungskontrolle. KI kann diese Tätigkeiten unterstützen, doch Verifikation und Verantwortung verbleiben bei qualifizierten Personen.
Wie lange dauert die Einführung von KI in die Softwareentwicklung eines regulierten Unternehmens?
Ein fokussiertes Pilotprojekt für ein Team und einen Bereich der Entwicklungspipeline kann in etwa zwei Wochen messbare Ergebnisse liefern. Die Ausweitung auf ein vollständiges Produktteam oder mehrere Teams dauert in der Regel einige weitere Wochen, abhängig von der Zahl der Pipelines und der Komplexität der regulatorischen Anforderungen.



