AI in Software Delivery for Regulated Industries: How to Keep Auditability and Compliance Intact

Executive summary Banks, insurers, payment providers, healthtech companies and industrial manufacturers face the same pressure as everyone else to deliver software faster. Many of them hold back on AI-assisted development because they fear losing control over what goes into production and how it can be explained to auditors. That concern is legitimate, but the conclusion is often wrong. Regulators rarely prohibit AI in software development; they expect accountability, traceability and evidence. A delivery process designed around those principles can use AI safely and still pass audits. This article explains what regulators actually care about, where AI fits with low risk, which controls make AI-assisted delivery audit-ready and what results a regulated company can realistically expect.

Why Regulated Companies Hesitate

In most regulated organisations, the discussion about AI in software delivery starts with a list of worries. Will AI-generated code slip past review? Can we prove who approved a change? Does proprietary code or customer data leave the company? What will the auditor say?

These questions are reasonable. But in practice, the biggest risk is often not AI itself, but uncontrolled AI. When a company bans AI tools outright, developers frequently use them anyway through personal accounts and browser tabs. The result is the worst of both worlds: none of the productivity benefits at organisational level and none of the controls.

The more productive question is not whether to use AI, but how to use it so that every change remains explainable, reviewable and attributable to a responsible person.

What Regulators Actually Care About

Regulatory frameworks differ by sector and country, but their expectations towards software delivery rest on a small set of recurring principles.

Accountability. A named person is responsible for every change that reaches production. AI can assist, but it cannot be accountable.

Traceability. It must be possible to reconstruct who changed what, why, based on which requirement, and who reviewed and approved it.

Segregation of duties. The person who writes a change should not be the only one who approves it. The four-eyes principle applies regardless of whether code was written by hand or with AI assistance.

Third-party risk management. External tools and service providers that process company code or data are part of the risk landscape and must be assessed accordingly.

Data protection and confidentiality. Personal data, customer data and trade secrets must not flow into systems where the company cannot control their use.

Evidence. Controls only count if they can be demonstrated. Auditors look for records, not intentions.

Several regulations make these principles concrete. In the EU financial sector, the Digital Operational Resilience Act (DORA) has applied since January 2025 and sets requirements for ICT risk management, incident reporting and the management of ICT third-party providers. (It should not be confused with the DORA metrics used to measure software delivery performance, which we also refer to below.) The EU AI Act has required organisations that use AI systems to ensure an adequate level of AI literacy among their staff since February 2025. GDPR governs any processing of personal data. In medical technology, IEC 62304 defines lifecycle requirements for medical device software, and in automotive, frameworks such as ISO 26262 and Automotive SPICE play a similar role.

None of these frameworks bans AI-assisted development. All of them, however, require that the delivery process remains controlled and documented.

Where AI Fits With Low Risk

Not every use of AI carries the same risk. A sensible approach starts where the benefit is high and the compliance impact is low, then extends step by step.

Strict human authorship and review, additional verification

The higher the regulatory relevance of the code, the stronger the human control must be. That does not mean AI is excluded from critical areas, but its role shifts from author to assistant, for example in explaining code, suggesting tests or flagging potential issues.

Building a Compliance-Safe AI Delivery Process

A delivery process that uses AI and remains audit-ready rests on a small number of controls. Most of them extend practices that regulated companies already have.

1. Approve tools and assess providers. Use only AI tools with enterprise terms that clarify ownership of output, exclude the use of company data for model training and define where data is processed. For financial entities covered by DORA, these providers typically need to be assessed within the existing ICT third-party risk framework.

2. Define clear data rules. Specify which code and which information may be shared with AI tools. Production data, customer data and secrets should be excluded by policy and, where possible, by technical controls. This fits naturally into a broader AI and data governance framework.

3. Apply the same review standards. AI-assisted code goes through exactly the same review and approval process as manually written code. The reviewer approves the change, not the tool that helped produce it, and remains accountable for it.

4. Make AI assistance traceable. Link every change to a ticket or requirement, as regulated teams already do. In addition, mark AI-assisted changes consistently, for example through pull request labels or commit conventions, so that auditors and internal reviewers can see where AI was involved.

5. Enforce controls in the pipeline. Policies are only as strong as their enforcement. Static code analysis, dependency and licence scanning, secrets detection and automated tests should run on every change and block releases that fail. Mature DevOps and cloud security practices turn these checks into a standard part of delivery rather than a manual afterthought.

6. Train the team. Developers need to understand not only how to use AI tools effectively, but also where their limits are and which rules apply. This also helps meet the AI literacy expectations of the EU AI Act.

7. Measure outcomes. Track delivery metrics such as deployment frequency, lead time for changes and change failure rate, alongside compliance indicators such as review sign-off rates and audit findings. Measurement proves that faster delivery has not come at the expense of control.

What Results Are Realistic: A Fintech Example

A fintech company from Central and Eastern Europe wanted to accelerate feature delivery without compromising code quality or audit traceability across its engineering teams. Together with the client, we carried out an audit of the software delivery lifecycle focused on compliance-safe AI tooling, ran enablement workshops on governed AI-assisted workflows and developed a 30-day operating playbook aligned with the company's regulatory review gates.

The outcomes, described in more detail on our AI-assisted software delivery page, included:

• a net efficiency gain of around 10 to 15 percent across the delivery lifecycle,
• a lower change failure rate while maintaining full audit traceability,
• 100 percent compliance sign-off across AI-assisted code changes,
• better visibility of delivery performance across teams through DORA metrics dashboards.

The efficiency gain is deliberately modest. It reflects what structured AI adoption typically delivers in a controlled environment, rather than the doubling of productivity often promised in marketing materials. For a regulated company, a sustainable double-digit gain with no loss of control is a strong result.

Common Mistakes to Avoid

Banning AI outright. Prohibition rarely stops usage; it pushes it into unmanaged channels. Controlled adoption is safer than a ban that nobody enforces.

Allowing unrestricted use. The opposite mistake is equally risky. Without approved tools, data rules and review standards, the company cannot demonstrate control.

Treating AI output as pre-reviewed. Code that looks clean and plausible still needs careful human review. Well-formatted code can hide subtle errors.

Writing policies without enforcing them. A policy that exists only in a document will not convince an auditor. Controls must be embedded in the pipeline and in daily practice.

Failing to measure. Without a baseline and ongoing metrics, the company can neither prove the benefits of AI nor show that quality and stability have been maintained.

Control Is What Makes Speed Possible

In regulated industries, the question is never simply how fast software can be delivered, but how fast it can be delivered while remaining explainable and defensible. AI does not change that equation; it raises the stakes for getting the process right. Companies that build accountability, traceability and evidence into their AI-assisted delivery can move faster with more confidence, not less.

The same maturity is increasingly visible to investors. In a technology due diligence, a governed and measurable approach to AI in software delivery is a clear signal of engineering quality, while uncontrolled usage is a risk factor. If your organisation wants to introduce AI into software delivery without compromising compliance, let's talk about how our AI-assisted software delivery programme can start with a focused, measurable pilot.

This article is for general information and does not constitute legal or regulatory advice. The specific requirements for your organisation depend on your sector, jurisdiction and supervisory authority.