Artificial Intelligence hat grundlegend verändert, wie Software entworfen, entwickelt, getestet und gewartet wird. Engineering-Teams nutzen AI heute für Codegenerierung, Pull-Request-Reviews, Testfälle, Dokumentation und sogar für Vorschläge zur Weiterentwicklung der Architektur. Für regulierte Organisationen ging es jedoch nie nur darum, ob AI die Produktivität steigert. Die eigentliche Herausforderung besteht darin, nachzuweisen, dass jede AI-gestützte Änderung kontrolliert, nachvollziehbar und mit den Anforderungen von Regulatoren und Auditoren vereinbar bleibt.
In der Europäischen Union und in der Schweiz konzentrieren sich regulatorische Erwartungen zunehmend auf Governance statt auf einzelne Technologien. DORA adressiert die operative Resilienz, der EU AI Act definiert Anforderungen an vertrauenswürdige AI, ISO-Managementsysteme verlangen weiterhin nachweisbare Kontrolle über Softwareentwicklungsprozesse, während FINMA von beaufsichtigten Instituten erwartet, Technologierisiken zu verstehen, zu steuern und kontinuierlich zu überwachen – unabhängig davon, ob diese intern oder bei externen Anbietern entstehen. Keines dieser Frameworks verbietet AI-gestützte Entwicklung. Entscheidend ist der Nachweis, dass Organisationen weiterhin die Kontrolle behalten.
Aus Audit-Sicht sollte AI als weiterer Bestandteil des Software Development Life Cycle (SDLC) betrachtet werden – nicht als Ersatz für bestehende Governance. Jedes erzeugte Artefakt muss weiterhin etablierte Engineering-Praktiken, Human Review, Security Validation, Testing, Change Management und dokumentierte Freigaben durchlaufen. Die Technologie entwickelt sich schnell weiter, die Verantwortung bleibt jedoch beim Menschen.
Dieser Guide konzentriert sich darauf, was Auditoren in der Praxis tatsächlich prüfen, anstatt regulatorische Anforderungen lediglich zu wiederholen. Er zeigt, wie Governance-Mechanismen gestaltet werden können, die DORA unterstützen, mit ISO-Managementsystemen im Einklang stehen, FINMA-Erwartungen berücksichtigen und Organisationen auf die praktischen Auswirkungen des EU AI Act vorbereiten. Die zentrale Frage ist dabei einfach: nicht, ob AI eingesetzt wurde, sondern ob die Organisation nachweisen kann, dass sie die Kontrolle behalten hat.
Organisationen beginnen ihre AI-Compliance-Reise häufig mit der Frage, welche Regulierung zuerst gilt. In der Praxis überschneiden sich mehrere Frameworks, die jeweils unterschiedliche Aspekte der Governance abdecken. Wer ihren tatsächlichen Geltungsbereich versteht, vermeidet sowohl regulatorische Lücken als auch unnötigen Compliance-Aufwand.
DORA gilt unmittelbar für Finanzunternehmen in der Europäischen Union und überträgt viele Anforderungen vertraglich auf ICT-Anbieter, die diese Organisationen unterstützen. Softwareanbieter stellen deshalb häufig fest, dass ihre Kunden Nachweise zu Secure Development, Vendor Governance, operativer Resilienz, Incident Management und Rückverfolgbarkeit verlangen – auch wenn der Anbieter selbst kein reguliertes Finanzinstitut ist. In der Praxis macht DORA Compliance damit zu einer Verantwortung entlang der gesamten Lieferkette.
Der EU AI Act ergänzt diese Anforderungen durch einen risikobasierten Ansatz für AI-Systeme. Die meisten AI Coding Assistants werden nicht allein deshalb zu High-Risk-AI-Systemen, weil Entwickler sie zur Codegenerierung einsetzen. Organisationen bleiben jedoch dafür verantwortlich, wie diese Tools verwendet werden, auf welche Informationen sie zugreifen, ob vertrauliche Daten offengelegt werden und wie Human Oversight sichergestellt wird. Der Coding Assistant selbst mag nicht als High-Risk-System eingestuft sein – sein Einsatz innerhalb regulierter Software Delivery unterliegt dennoch klaren Governance-Erwartungen.
Schweizer Organisationen (FINMA & revDSG) bewegen sich in einem anderen, aber zunehmend vergleichbaren regulatorischen Umfeld. FINMA legt grossen Wert auf Technology Governance, Outsourcing Oversight, operative Resilienz und wirksames Risk Management. Unabhängig davon, ob Software intern entwickelt oder durch AI-gestützte Anbieter unterstützt wird, bleiben beaufsichtigte Institute dafür verantwortlich, die damit verbundenen Risiken zu verstehen und wirksame Kontrollen aufrechtzuerhalten. In Verbindung mit dem revidierten Schweizer Datenschutzgesetz (revDSG) müssen Organisationen zudem einen angemessenen Umgang mit personenbezogenen Daten nachweisen – insbesondere wenn cloudbasierte AI-Services Prompts mit Kunden- oder Mitarbeiterdaten verarbeiten.
ISO-Managementsysteme ergänzen diese regulatorischen Anforderungen durch einen operativen Rahmen, der Governance wiederholbar macht. ISO/IEC 27001 verlangt unter anderem Secure-Development-Praktiken, Change Management, Supplier Oversight und nachweisbare Kontrollen. ISO 42001 adressiert Governance für AI-Managementsysteme, während ISO 9001 konsistente Engineering-Prozesse und dokumentierte Entscheidungsfindung unterstützt. Zusammen schaffen diese Standards die operative Disziplin, die Regulatoren zunehmend erwarten.
Nicht jede Regulierung gilt jedoch gleichermassen für jede Organisation. Ein Softwareunternehmen, das interne Geschäftsanwendungen entwickelt, fällt möglicherweise nicht direkt unter DORA und betreibt auch keine High-Risk-AI-Systeme im Sinne des EU AI Act. Jede denkbare Kontrollmassnahme umzusetzen führt häufig zu unnötiger Bürokratie, ohne die Resilienz tatsächlich zu erhöhen. Effektive Compliance beginnt deshalb mit einer klaren Einordnung der tatsächlichen regulatorischen Verpflichtungen.
Die grundlegende Frage der Regulatoren bleibt über diese Frameworks hinweg erstaunlich ähnlich. Entscheidend ist nicht, ob AI zur Software Delivery beigetragen hat. Entscheidend ist, wer verantwortlich blieb, wie Entscheidungen überprüft wurden, welche Nachweise vorhanden sind und ob die Governance trotz zunehmender Automatisierung wirksam geblieben ist.
Audit-Gespräche beginnen selten mit Large Language Models oder Prompt Engineering. Auditoren konzentrieren sich zunächst auf die Grundlagen der Governance. Sobald AI Teil der Softwareentwicklung ist, richten sie ihre Aufmerksamkeit auf Verantwortlichkeit, Human Oversight, Reproduzierbarkeit und Nachweise.
Eine der ersten Fragen betrifft die Verantwortung. Wenn AI-generierter Code in Produktion gelangt, wollen Auditoren wissen, wer diesen Output reviewed hat, ob der Reviewer über die erforderliche technische Kompetenz verfügte und wo die Freigabe dokumentiert wurde. Aussagen wie „Unsere Entwickler prüfen AI-Output immer“ reichen bei einem Audit selten aus, weil sie eine Absicht beschreiben, aber keinen Nachweis liefern. Auditoren erwarten dokumentierte Review-Aktivitäten, die direkt mit Commits, Pull Requests, Approvals und Deployment Records verknüpft sind.
Ein weiteres zentrales Thema ist Data Governance. Organisationen führen AI Coding Assistants häufig ein, ohne eindeutig festzulegen, welche Informationen Entwickler in Prompts verwenden dürfen. Auditoren fragen zunehmend, ob Kundendaten, Source Code, vertrauliche Algorithmen oder regulierte Datensätze in das Modelltraining einfliessen könnten. Sie erwarten Nachweise für vertragliche Schutzmechanismen mit AI-Anbietern, definierte Data-Handling-Policies und technische Controls, die eine unzulässige Offenlegung von Informationen verhindern.
Reproduzierbarkeit ist ein weiteres Merkmal ausgereifter AI-Governance. Wenn ein AI-Modell vor sechs Monaten einen bestimmten Implementierungsansatz vorgeschlagen hat, sollte die Organisation den Kontext dieser Entscheidung zumindest nachvollziehen können. Perfekte Reproduzierbarkeit ist bei probabilistischen Modellen selten möglich. Es sollten jedoch genügend Informationen vorhanden sein, um zu erklären, warum eine Entscheidung akzeptiert wurde, welche Alternativen berücksichtigt wurden und wer die Umsetzung letztlich freigegeben hat.
Der Unterschied zwischen unerfahrenen und ausgereiften Organisationen zeigt sich besonders deutlich darin, wie sie Audit-Fragen beantworten. Demo-Umgebungen konzentrieren sich auf beeindruckende AI-Fähigkeiten wie schnelle Codegenerierung und automatisierte Dokumentation. Audits verlangen etwas anderes: Evidence Chains, die Prompts, generierte Artefakte, Human Reviews, Testergebnisse, Approvals, Deployment-Entscheidungen und Operational Monitoring miteinander verbinden.
Geschwindigkeit beeindruckt in der Demo. Für Auditoren zählt Rückverfolgbarkeit.
Erfahrene Auditoren stellen den Einsatz von AI selbst selten grundsätzlich infrage. Stattdessen prüfen sie, ob AI die bestehende Governance geschwächt hat. Wenn Organisationen nicht mindestens dasselbe Niveau an Verantwortlichkeit und Kontrolle nachweisen können wie vor der Automatisierung, wird AI schnell zu einem unkontrollierten operativen Risiko statt zu einer Innovationsinitiative.
Human Oversight ist zu einem zentralen Prinzip der AI-Governance geworden. Dennoch wird häufig missverstanden, was wirksame Kontrolle tatsächlich bedeutet. Einen Entwickler lediglich vor dem Merge von AI-generiertem Code auf „Approve“ klicken zu lassen, liefert kaum einen belastbaren Nachweis dafür, dass eine echte Prüfung stattgefunden hat.
Belastbare Human Oversight setzt voraus, dass qualifizierte Personen AI-generierten Output aktiv bewerten, bevor sie die Verantwortung für dessen Umsetzung übernehmen. Ein wirksamer Review-Nachweis sollte festhalten, wer den Review durchgeführt hat, ob die Person über die erforderliche Kompetenz verfügte, wann die Prüfung stattfand, welche Aspekte bewertet wurden und warum die finale Entscheidung getroffen wurde. So wird aus einem Approval keine reine Checkbox-Übung, sondern eine nachvollziehbare Engineering-Aktivität.
Das angemessene Mass an Kontrolle hängt auch vom Grad der AI-Autonomie ab. Systeme, die einzelne Code-Vorschläge liefern, benötigen andere Governance als autonome Agenten, die komplette Features generieren, Produktionskonfigurationen verändern oder Deployments initiieren können. Je autonomer AI innerhalb der Software Delivery agiert, desto stärker müssen auch die Governance Gates werden.
Häufig unterschätzt wird dabei die Kompetenz der Reviewer. Human Oversight funktioniert nur, wenn Reviewer über ausreichend technisches Fachwissen verfügen, um Fehler, Security Vulnerabilities, architektonische Schwächen und Compliance-Auswirkungen zu erkennen. Reviews lediglich zur Erfüllung von Segregation-of-Duties-Anforderungen zuzuweisen, ohne die entsprechende Expertise sicherzustellen, schafft Governance, die auf dem Papier funktioniert, aber wenig tatsächlichen Schutz bietet.
Gut gestaltete Gates integrieren sich in bestehende Engineering-Workflows, anstatt parallele Compliance-Prozesse zu erzeugen. Pull-Request-Reviews, Architecture Approvals, Security Assessments, Quality Gates und Deployment Approvals können AI-spezifische Kriterien aufnehmen, ohne den SDLC grundsätzlich zu verändern. Ausgereifte Organisationen integrieren Governance in Engineering – statt Engineers mit separaten Compliance-Prozessen zu belasten.
Ziel ist nicht, Delivery durch übermässige manuelle Eingriffe auszubremsen. Effektive Human Oversight schafft Vertrauen, dass AI die Entwicklung beschleunigen kann, ohne Verantwortlichkeit zu reduzieren. Im besten Fall bleibt Governance für Engineering-Teams weitgehend im Hintergrund und erzeugt gleichzeitig genau die Nachweise, die Auditoren benötigen.
Nachweise unterscheiden belastbare Compliance von blosser Behauptung. Bei Audits scheitern Organisationen selten daran, dass keine Controls existieren. Sie scheitern daran, dass sie nicht nachweisen können, dass diese Controls während der gesamten Software Delivery konsistent funktioniert haben.
Die Evidence Chain sollte im Source Control beginnen und jede Produktionsänderung mit einem eindeutig identifizierbaren Commit verbinden. Darauf aufbauend sollten Commits mit Pull Requests, Code Reviews, Security Scans, automatisierten Tests, Deployment Approvals, Change Requests und Production Releases verknüpft sein. AI-generierter Content wird damit zu einem weiteren Bestandteil dieses umfassenden Traceability-Modells – nicht zu einem isolierten Governance-Prozess.
Prompt Management bringt zusätzliche Anforderungen mit sich. Organisationen müssen nicht jede Interaktion zwischen Entwicklern und AI-Assistenten unbegrenzt speichern. Stattdessen sollten Retention Policies regulatorische Anforderungen, geschäftliche Bedürfnisse und Datenschutz berücksichtigen. Prompts, die wichtige Architekturentscheidungen oder produktive Implementierungen unterstützen, können eine längere Aufbewahrung rechtfertigen als explorative Gespräche oder kurzlebige Entwicklungsexperimente.
Viele regulierte Organisationen setzen zunehmend auf Retrieval-Augmented Generation (RAG), anstatt Modellen uneingeschränkten Zugriff auf interne Informationen zu geben. RAG ermöglicht es AI-Systemen, Informationen aus freigegebenen internen Wissensquellen abzurufen, ohne Unternehmensdaten dauerhaft in das Modelltraining zu übernehmen. Diese Architekturentscheidung reduziert Vertraulichkeitsrisiken und schafft gleichzeitig stärkere Nachweise für Information Governance und Data Residency.
Datenschutz bleibt dabei ebenso wichtig. Eine übermässige Speicherung von Prompt-Verläufen kann unbeabsichtigt neue Repositories mit vertraulichen Informationen, personenbezogenen Daten oder geistigem Eigentum schaffen. Gute Governance verlangt deshalb bewusste Entscheidungen darüber, welche Informationen für Verantwortlichkeit tatsächlich benötigt werden – und welche bewusst nicht gespeichert werden sollten. Compliance bedeutet immer auch, Rückverfolgbarkeit und Verhältnismässigkeit auszubalancieren.
Auditoren arbeiten letztlich mit Reports und nicht mit rohen Entwicklungsdaten. Organisationen sollten deshalb Audit-Pakete erzeugen, die technische Aktivitäten in nachvollziehbare Governance-Artefakte übersetzen. Reports mit Reviewer Approvals, Testergebnissen, Traceability Links, Deployment-Entscheidungen und Policy Compliance reduzieren den Audit-Aufwand erheblich und stärken gleichzeitig das Vertrauen in die Kontrolle der Software Delivery.
Bei der Auswahl eines AI-Anbieters geht es für regulierte Organisationen längst nicht mehr nur um Modellleistung. Data Residency, vertragliche Schutzmechanismen und Vendor Oversight entscheiden häufig darüber, ob eine Lösung überhaupt eingesetzt werden kann – unabhängig von ihrer technischen Leistungsfähigkeit.
Data Residency sollte als Architekturentscheidung betrachtet werden, nicht nur als vertragliches Versprechen. Organisationen unter schweizerischen oder europäischen regulatorischen Anforderungen bevorzugen zunehmend Processing-Umgebungen, in denen sensible Informationen innerhalb freigegebener Jurisdiktionen bleiben oder geeignete rechtliche Schutzmechanismen für internationale Transfers bestehen. Marketingaussagen eines Anbieters allein reichen für regulatorische Nachweise selten aus.
Auch Vendor Contracts verdienen besondere Aufmerksamkeit. Organisationen sollten wissen, ob übermittelte Prompts für zukünftiges Modelltraining verwendet werden, wie lange Daten gespeichert bleiben, welche Subprozessoren beteiligt sind und wie Kunden über Änderungen in der Lieferkette informiert werden. Solche Vertragsbedingungen beeinflussen das operationelle Risiko direkt und werden zunehmend Teil von Audits.
DORA verschärft insbesondere die Anforderungen an ICT Vendor Governance. Finanzinstitute müssen kritische Anbieter identifizieren, Oversight-Mechanismen aufrechterhalten, Audit Rights definieren, Exit Strategies etablieren und operative Resilienz kontinuierlich bewerten. Softwareanbieter, die regulierte Kunden unterstützen, erhalten deshalb zunehmend detaillierte Fragebögen, deren Anforderungen weit über klassische Security-Zertifizierungen hinausgehen.
Exit Planning gehört zu den am häufigsten übersehenen Governance-Themen. Organisationen sollten frühzeitig klären, wie Development Workflows weitergeführt werden, wenn ein Anbieter längere Ausfälle erlebt, regulatorischen Einschränkungen unterliegt, sich strategisch neu ausrichtet oder eine Geschäftsbeziehung endet. Portabilität zwischen Anbietern und alternative Delivery-Ansätze tragen unmittelbar zur operativen Resilienz bei.
Regulierter AI-Einsatz verursacht zwangsläufig zusätzliche Kosten. Anbieter mit regionaler Verarbeitung, stärkeren Vertragsgarantien, dedizierten Umgebungen und erweiterten Governance-Funktionen sind in der Regel teurer als Consumer-AI-Services. Dieser Aufpreis sollte als Investition in nachweisbare Compliance verstanden werden – nicht lediglich als zusätzlicher Betriebsaufwand.
Technologie allein schafft keine Compliance. Nachhaltige Governance entsteht durch ein klar definiertes Operating Model mit eindeutigen Verantwortlichkeiten, Review-Zyklen und kontinuierlicher Verbesserung über fünf Funktionen hinweg:
Governance sollte kontinuierlich funktionieren und nicht erst kurz vor einem externen Audit sichtbar werden. Organisationen profitieren davon, AI-Nutzung regelmässig zu überprüfen, Vendor Compliance zu validieren, Evidence Repositories aktuell zu halten, Approval Records zu prüfen und sicherzustellen, dass dokumentierte Controls weiterhin der operativen Realität entsprechen. Dadurch wird Compliance zu einer laufenden operativen Disziplin statt zu einer jährlichen Dokumentationsübung.
Evidence Management verdient besondere Aufmerksamkeit. Controls, die vor einigen Jahren definiert wurden, können aufgrund der schnellen Entwicklung von AI rasch veralten. Regelmässige Validierung stellt sicher, dass Governance mit Technologie, regulatorischen Vorgaben, Risk Appetite und Vendor Capabilities Schritt hält. Aktuelle Nachweise reduzieren gleichzeitig den Aufwand für Audit-Vorbereitung und stärken die operative Resilienz.
Der wichtigste kulturelle Wandel besteht möglicherweise darin, Compliance als Engineering Capability statt als administrativen Aufwand zu verstehen. Gut gesteuerte Entwicklungsumgebungen ermöglichen Innovation, weil Erwartungen klar sind, Approvals wiederholbar werden und Nachweise automatisch aus bestehenden Workflows entstehen. So kann Compliance Delivery beschleunigen, indem sie Unsicherheit reduziert, statt zusätzliche Bürokratie zu erzeugen.
Organisationen, die AI erfolgreich in regulierter Software Delivery einsetzen, haben ein gemeinsames Merkmal: Sie entwickeln Governance parallel zur Automatisierung, statt Controls erst nachträglich einzubauen. Wenn Traceability, Accountability, Human Oversight und Vendor Governance von Anfang an als Eigenschaften der Delivery betrachtet werden, werden Audits zu Validierungsübungen statt zu dringenden Sanierungsprojekten.
Die ausgereiftesten Organisationen entwickeln Software für den Produktiveinsatz und erzeugen gleichzeitig die Nachweise, die Auditoren benötigen.
Ja. Weder DORA, ISO-Standards, FINMA-Erwartungen noch der EU AI Act verbieten AI-generierten Code. Erwartet werden vielmehr nachweisbare Human Reviews, dokumentierte Approvals, sichere Entwicklungspraktiken, umfassende Tests und vollständige Rückverfolgbarkeit vom generierten Output bis zum Production Deployment.
Wenn Ihre Kunden Finanzunternehmen sind, die DORA unterliegen, werden viele ihrer regulatorischen Anforderungen über Verträge auch an Sie weitergegeben. Selbst wenn DORA Ihre Organisation nicht unmittelbar reguliert, werden Kunden zunehmend Nachweise zu Software-Development-Governance, operativer Resilienz, Vendor Management und Security Controls verlangen.
Die meisten AI Coding Assistants werden nicht allein deshalb als High-Risk-AI-Systeme eingestuft, weil sie Softwareentwicklung unterstützen. Organisationen bleiben jedoch dafür verantwortlich, wie diese Tools eingesetzt werden, vertrauliche Informationen zu schützen, angemessene Human Oversight sicherzustellen, Verantwortlichkeiten klar zuzuordnen und nachzuweisen, dass AI-gestützte Entwicklung weiterhin etablierten Engineering- und Compliance-Controls unterliegt.
Unsere Audit-Readiness-Checkliste: AI im SDLC führt Sie durch die Nachweise zu Human Review, Rückverfolgbarkeit und Vendor Governance, die Auditoren tatsächlich erwarten – als strukturiertes Self-Assessment.
Audit-Readiness-Checkliste herunterladen