Artificial intelligence has fundamentally changed how software is designed, developed, tested, and maintained. Development teams now rely on AI to generate code, review pull requests, create test cases, produce documentation, and even suggest architectural improvements. For regulated organizations, however, the discussion has never been about whether AI improves productivity. The real challenge is demonstrating that every AI-assisted change remains controlled, attributable, and compliant with the expectations of regulators and auditors.
Across the European Union and Switzerland, regulatory expectations are converging around governance rather than technology. DORA focuses on operational resilience, the EU AI Act introduces obligations around trustworthy AI, ISO management systems continue to require demonstrable control over software development processes, while FINMA expects supervised institutions to understand, govern, and continuously oversee technology risks regardless of whether they originate internally or from suppliers. None of these frameworks prohibit AI-assisted development. They simply demand evidence that organizations remain in control.
From an audit perspective, AI should be viewed as another participant in the Software Development Life Cycle rather than a replacement for existing governance. Every generated artifact must still pass through approved engineering practices, human review, security validation, testing, change management, and documented approval. The technology may evolve rapidly, but accountability remains entirely human.
This guide focuses on what auditors actually verify during assessments rather than repeating legal requirements. It explains how to build governance mechanisms that satisfy DORA, align with ISO management systems, support FINMA expectations, and prepare organizations for the practical implications of the EU AI Act. The central question throughout is remarkably simple: not whether AI was used, but whether the organization can prove it remained in control.
Organizations often begin their AI compliance journey by asking which regulation applies first. In reality, several frameworks overlap, each addressing a different aspect of governance. Understanding their scope prevents both regulatory gaps and unnecessary compliance work.
DORA applies directly to financial entities across the European Union while extending many obligations contractually to ICT providers supporting those organizations. Software vendors frequently discover that although they are not regulated financial institutions themselves, their customers require evidence demonstrating secure development practices, supplier governance, operational resilience, incident management, and traceability. In practice, DORA transforms compliance into a supply-chain responsibility where software development partners inherit significant expectations through contractual arrangements.
The EU AI Act introduces another dimension by regulating AI systems according to risk. Most AI coding assistants used during software development are not classified as high-risk AI systems simply because developers use them to write code. However, organizations still become responsible for governing how those tools are deployed, what information they access, whether confidential data is exposed, and how human oversight is maintained. The AI assistant itself may not be regulated as a high-risk system, but its deployment inside regulated software delivery certainly attracts governance expectations.
Swiss organizations (FINMA & revFADP) operate within a different but increasingly aligned landscape. FINMA has consistently emphasized technology governance, outsourcing oversight, operational resilience, and effective risk management. Whether software is developed internally or supported by AI-enabled vendors, supervised institutions remain accountable for understanding associated risks and maintaining effective controls. Combined with the revised Swiss Federal Act on Data Protection (revFADP), organizations must demonstrate appropriate handling of personal information, especially where cloud-hosted AI services process prompts containing customer or employee data.
ISO management systems complement these regulations by providing the operational framework through which governance becomes repeatable. ISO/IEC 27001 requires secure development practices, change management, supplier oversight, and evidence-based controls. ISO 42001 introduces governance principles specifically for AI management systems, while ISO 9001 reinforces consistent engineering processes and documented decision-making. Together, these standards provide the operational discipline that regulators increasingly expect to see.
Not every regulation applies equally to every organization, however. A software company developing internal business applications may not fall directly within DORA or operate high-risk AI systems under the EU AI Act. Attempting to implement every conceivable control often produces unnecessary bureaucracy without improving resilience. Effective compliance begins by understanding the actual regulatory obligations rather than implementing controls simply because they appear in another industry's guidance.
The fundamental question regulators continue asking is remarkably consistent across frameworks. They are not concerned with whether artificial intelligence contributed to software delivery. They want organizations to demonstrate who remained accountable, how decisions were reviewed, what evidence exists, and whether governance mechanisms continued operating despite the introduction of AI.
Audit interviews rarely begin with questions about large language models or prompt engineering. Instead, auditors focus on governance fundamentals. Once they learn that AI participates in software development, their attention immediately shifts toward accountability, oversight, reproducibility, and evidence.
One of the first questions concerns ownership. If AI generated code entering production, auditors want to understand who reviewed that output, whether the reviewer possessed appropriate technical competence, and where approval was formally recorded. Statements such as “our developers always verify AI output” rarely satisfy an audit because they describe intent rather than demonstrating evidence. Auditors expect to see documented review activities linked directly to commits, pull requests, approvals, and deployment records.
Another recurring topic involves data governance. Organizations frequently adopt AI coding assistants without clearly defining what information developers may include within prompts. Auditors increasingly ask whether customer information, source code, confidential algorithms, or regulated datasets could become part of model training. They seek evidence that contractual protections exist with AI vendors, data handling policies are implemented, and technical safeguards prevent inappropriate information disclosure.
Reproducibility has become another distinguishing characteristic of mature AI governance. If an AI model recommended a particular implementation approach six months earlier, can the organization reconstruct the context behind that recommendation? Perfect reproducibility is rarely achievable with probabilistic models, but organizations should at least retain sufficient contextual information to explain why a particular design decision was accepted, what alternatives were considered, and which human ultimately approved implementation.
Perhaps the biggest difference between inexperienced and mature organizations appears in how they answer audit questions. Demonstration environments often focus on impressive AI capabilities, showing rapid code generation and automated documentation. Audit environments demand something entirely different. They require evidence chains linking prompts, generated artifacts, human reviews, testing outcomes, approvals, deployment decisions, and operational monitoring. Speed impresses customers; traceability satisfies regulators.
Experienced auditors rarely challenge the use of AI itself. Instead, they examine whether introducing AI weakened existing governance. If organizations cannot demonstrate the same or stronger levels of accountability than before automation, AI quickly becomes viewed as an unmanaged operational risk rather than an innovation initiative.
Human oversight has become one of the defining regulatory principles surrounding AI adoption. Yet many organizations misunderstand what constitutes meaningful supervision. Simply requiring a developer to click “Approve” before merging AI-generated code creates little evidence that genuine review occurred.
Defensible oversight requires demonstrating that qualified individuals actively evaluated the AI-generated output before accepting responsibility for its implementation. Effective review records identify the reviewer, confirm their competence, document when the assessment occurred, explain what aspects were examined, and capture the rationale supporting the final decision. These elements transform approval from a procedural checkbox into an accountable engineering activity.
The appropriate level of oversight also depends on the degree of AI autonomy. Systems providing simple code suggestions require different governance than autonomous agents capable of generating complete features, modifying production configurations, or initiating deployments. As organizations progress from AI acting merely as an assistant toward increasingly autonomous software engineering workflows, governance gates must become proportionally stronger rather than remaining static.
Organizations frequently underestimate the importance of reviewer competence. Human oversight assumes reviewers possess sufficient technical expertise to recognize errors, security vulnerabilities, architectural weaknesses, and compliance implications. Assigning reviews solely to satisfy segregation-of-duty requirements without ensuring appropriate expertise creates governance that appears compliant on paper while offering little practical protection.
Well-designed gates also integrate naturally into existing development workflows instead of introducing separate compliance processes. Pull request reviews, architecture approvals, security assessments, quality gates, and deployment authorizations can all incorporate AI-specific evaluation criteria without fundamentally changing the SDLC. Mature organizations embed governance into engineering rather than forcing engineers to complete parallel compliance exercises.
The objective is not slowing delivery through excessive manual intervention. Effective human oversight provides confidence that AI accelerates development without reducing accountability. When implemented correctly, governance becomes almost invisible to engineering teams while producing precisely the evidence auditors expect.
Evidence represents the difference between compliant processes and compliance claims. During audits, organizations rarely fail because controls do not exist. They fail because they cannot demonstrate that those controls consistently operated throughout software delivery.
The evidence chain should begin with source control, linking every production change to a uniquely identifiable commit. From there, organizations should maintain relationships connecting commits to pull requests, code reviews, security scans, automated testing, deployment approvals, change requests, and production releases. AI-generated content becomes simply another component within this broader traceability model rather than an isolated governance process.
Prompt management introduces additional considerations. Organizations do not necessarily need to retain every interaction between developers and AI assistants indefinitely. Instead, they should define retention policies reflecting regulatory obligations, business requirements, and privacy considerations. Prompts supporting significant architectural decisions or production implementations may justify longer retention than exploratory conversations or disposable development experiments.
Many regulated organizations increasingly adopt Retrieval-Augmented Generation architectures instead of allowing unrestricted public model access. RAG enables AI systems to retrieve information from approved internal knowledge sources without permanently incorporating organizational data into model training. This architectural decision reduces confidentiality risks while supporting stronger evidence regarding information governance and data residency.
Privacy considerations remain equally important. Capturing excessive prompt history can unintentionally create new repositories containing confidential information, personal data, or intellectual property. Effective governance therefore requires deliberate decisions about what evidence supports accountability and what information should intentionally never be retained. Compliance always involves balancing traceability against proportionality.
Auditors ultimately consume reports rather than raw development data. Organizations should therefore produce evidence packages translating technical activities into understandable governance artifacts. Reports demonstrating reviewer approvals, testing outcomes, traceability links, deployment decisions, and policy compliance significantly reduce audit effort while increasing confidence that software delivery remains effectively controlled.
Selecting an AI provider has become less about model performance and increasingly about governance capabilities. For regulated organizations, data residency, contractual protections, and supplier oversight often determine whether a solution is acceptable regardless of its technical sophistication.
Data residency should be treated as an architectural decision rather than a contractual promise. Organizations operating under Swiss or European regulatory expectations increasingly prefer processing environments where sensitive information remains within approved jurisdictions or where appropriate legal safeguards govern international transfers. Simply relying on vendor marketing statements rarely satisfies regulatory scrutiny.
Vendor contracts deserve equally careful attention. Organizations should understand whether submitted prompts contribute to future model training, how long information is retained, which subcontractors participate in processing, and how customers are notified when supplier arrangements change. These contractual provisions directly influence operational risk and frequently become subjects of audit examination.
DORA significantly strengthens expectations surrounding ICT supplier governance. Financial entities must understand critical suppliers, maintain oversight mechanisms, define audit rights, establish exit strategies, and continuously evaluate operational resilience. Software providers supporting regulated customers increasingly receive detailed questionnaires requiring evidence extending far beyond traditional information security certifications.
Exit planning remains one of the most overlooked governance topics. Organizations adopting AI should consider how development workflows would continue if providers experienced prolonged outages, commercial disputes, regulatory restrictions, or strategic changes. Maintaining portability between providers or supporting alternative development approaches contributes directly to operational resilience expectations.
There is inevitably a cost associated with regulated AI deployment. Providers offering regional processing, stronger contractual protections, dedicated environments, and enhanced governance capabilities generally command higher prices than consumer-oriented AI services. Organizations should recognize this premium as an investment in demonstrable compliance rather than viewing governance merely as an operational expense.
Technology alone cannot achieve compliance. Sustainable governance emerges from clearly defined operating models establishing ownership, accountability, review cycles, and continuous improvement across five functions:
Governance should function continuously instead of appearing only before external audits. Organizations benefit from periodically reviewing AI usage, validating supplier compliance, refreshing evidence repositories, evaluating approval records, and confirming that documented controls continue matching operational reality. These activities transform compliance into an operational discipline rather than an annual documentation exercise.
Evidence management deserves particular attention. Controls established several years earlier often become outdated as AI capabilities evolve rapidly. Regular validation ensures governance remains aligned with changing technology, regulatory guidance, organizational risk appetite, and supplier capabilities. Maintaining current evidence significantly reduces audit preparation while improving operational resilience.
Perhaps the most important cultural shift involves positioning compliance as an engineering capability rather than an administrative burden. Well-governed development environments allow engineers to innovate confidently because expectations remain clear, approvals become repeatable, and evidence emerges naturally from existing workflows. Compliance therefore accelerates delivery by reducing uncertainty rather than introducing unnecessary bureaucracy.
Organizations that successfully adopt AI within regulated software delivery ultimately share one characteristic. They design governance alongside automation instead of attempting to retrofit controls after deployment. By treating traceability, accountability, human oversight, and supplier governance as delivery features from the beginning, audits become validation exercises rather than emergency remediation projects.
The most mature organizations build software for production and evidence for auditors at the same time.
Yes. Neither DORA, ISO standards, FINMA expectations, nor the EU AI Act prohibit AI-generated code. What regulators expect is demonstrable human review, documented approvals, secure development practices, comprehensive testing, and complete traceability from generated output to production deployment.
If your customers are financial entities subject to DORA, many of their regulatory obligations will extend to you through contractual requirements. Even when DORA does not regulate your organization directly, customers will increasingly request evidence covering software development governance, operational resilience, supplier management, and security controls.
Most coding assistants are unlikely to qualify as high-risk AI systems solely because they support software development. However, organizations remain responsible for governing how these tools are used, protecting confidential information, ensuring appropriate human oversight, maintaining accountability, and demonstrating that AI-assisted development remains subject to established engineering and compliance controls.
Our Audit Readiness Checklist: AI in the SDLC walks through the human-review, traceability, and vendor-governance evidence points auditors actually ask for — as a self-assessment.
Get the Audit Readiness Checklist