May regulated companies use AI coding tools - and under which conditions?

Generally yes, because the frameworks regulate the development process and its evidence, not the authorship of code. The recurring conditions: the code passes the same defined verification and validation regardless of who or what wrote it; traceability from requirement to implementation to test stays intact; tool data flows respect confidentiality rules; and the usage itself is risk-assessed and documented. Sector rules and your notified body or supervisor add specifics - the assessment is theirs and your QA/regulatory team's.

What does DORA mean for AI coding in financial companies?

DORA (applicable since January 2025) makes ICT risk management a regulated discipline for financial entities - including secure development practices and control of ICT third-party providers. An AI coding tool enters twice: as a third-party service whose data path and contract need managing, and as an influence on code that must still pass your secure development lifecycle. DORA does not name AI tools; supervisors ask how your ICT risk framework covers them.

Can AI-generated code go into a medical device?

IEC 62304 and the MDR regulate the software lifecycle - requirements, architecture, implementation, verification, maintenance - and demand documented evidence at each stage. Code that enters that lifecycle must satisfy the same verification whether a human or an assistant wrote it; what changes with AI is the volume of unverified input and the importance of provenance. Manufacturers additionally face AI Act duties if the device itself contains AI (Annex I deadline now August 2028). The conformity assessment stays with your notified body.

How does automotive handle AI-generated code?

Through the same instruments it already trusts: ISO 26262 for functional safety and Automotive SPICE for process capability, both built on traceability - every requirement maps to implementation and test. AI-generated code does not break this model; it stresses it, because volume rises and authorship blurs. OEM confidentiality terms and TISAX add the data-flow question: repository context reaching a cloud tool is exactly the material those terms protect.

Is there a sector where AI coding tools are simply forbidden?

We know of no general prohibition in the major EU frameworks as of July 2026 - the rules consistently regulate process, evidence and data protection rather than banning tool categories. Practical prohibitions do exist locally: OEM or client contracts that exclude external code processing, air-gapped environments where cloud tools cannot physically operate, and internal policies. Check contracts before frameworks - they bind first.

What is the common denominator across all three sectors?

Evidence over authorship. Every framework in this article converges on the same three demands: a defined process the code went through, verification results that prove it, and traceability that links change to requirement. Teams that verify each AI run against a written task and keep the record satisfy the shape of all three - the sector-specific depth then comes on top.

Compliance

AI Coding in Regulated Industries

Last updated: 2026-07-024 min read

AI coding in regulated industries is not forbidden – it is conditioned. DORA, IEC 62304/MDR and ISO 26262/Automotive SPICE regulate the development process and its evidence, not the author of the code: the same verification, the same traceability, the same documented lifecycle apply whether a human or an assistant wrote the change. What AI shifts is volume and provenance – which makes the evidence side harder and more important, not the usage illegal.

Contents

The common principle: rules bind the process, not the author

Legal status: July 2, 2026. This article describes sector regulation for orientation – it is not legal advice; the assessment belongs to your QA, regulatory and legal teams.

None of the major frameworks asks who typed the code. They ask whether the code went through a defined process, whether verification proves it works, and whether a requirement can be traced to its implementation and test. That is why the honest answer to “may we?” is almost always yes – and why the honest follow-up is harder: AI raises code volume while, across industries, the quality guarantee still has to come from your process, not from the tool.

The three sectors at a glance

Sector	Key frameworks	What they demand for AI code
Financial (fintech, banks, insurers)	DORA (since Jan 2025), EBA/EIOPA guidance	AI tool as managed ICT third party; secure development lifecycle covers generated code; incident attribution
Medical devices	MDR, IEC 62304, ISO 13485; AI Act Annex I (Aug 2028) if the device contains AI	Full lifecycle evidence per change; V&V independent of authorship; provenance in the technical file
Automotive	ISO 26262, Automotive SPICE, TISAX; UNECE R155/156	Requirement-to-test traceability; process capability incl. AI usage; strict confidentiality of code and prototypes

What the three regulated sectors demand when AI writes code - the demands differ in depth, not in kind: process, evidence, traceability (status: July 2026).

Sector depth varies – a 62304 lifecycle documents more per change than a DORA ICT framework – but the shape repeats. Notably, medical device manufacturers whose products contain AI face dual MDR + AI Act compliance, with the embedded-AI deadline now at August 2028 – a product question distinct from using AI to write conventional device code.

Where AI coding actually creates friction

Volume vs. evidence. The lifecycle demands evidence per change; AI multiplies changes. Without per-run records, the documentation debt grows exactly as fast as the productivity gain.
Traceability vs. blurred authorship. “Which requirement does this change implement?” needs an answer per AI run – which presumes the run had a written task in the first place.
Confidentiality vs. cloud context. OEM terms, patient-adjacent code and trading logic are exactly what repository-context tools ingest. The BSI/ANSSI recommendations treat this data path as a first-class risk; local processing shortens the analysis.

The practical setup that satisfies all three shapes

Because the frameworks converge on process, evidence and traceability, one setup serves them all as the base layer: a written, checkable task per AI run (the traceability anchor), verification of the change against that task before it enters the regulated lifecycle, and a per-run record of what was checked – the audit trail your assessors will ask about. Sector depth (safety analyses, clinical evaluation, ASIL classification) then builds on a documented foundation instead of a reconstruction. The policy side lives in our governance guide.

Where Reality Graph fits

Reality Graph provides that base layer: verification of each AI coding run against its written task, inside your environment – compatible with the confidentiality rules that make cloud context hard in these sectors – with an evidence report per run. It is not a medical, automotive or financial compliance product and holds no sector certification – it feeds your regulated process with documentation; the conformity judgment stays with your assessors.

This orientation gives you

The author-vs-process principle that unlocks the sector question
Three sectors mapped to their actual frameworks, dated
The three real friction points, named without alarmism
One base setup that fits all three evidence shapes

It does not give you

Legal or regulatory advice - your QA/RA/counsel own that
A conformity pre-assessment for any concrete product
Sector depth - 62304 or 26262 work starts after this page
A claim that any tool is 'approved' for regulated use

If these boundaries fit how your team wants to ship:

Get early access See how it works

FAQ

May regulated companies use AI coding tools - and under which conditions?: Generally yes, because the frameworks regulate the development process and its evidence, not the authorship of code. The recurring conditions: the code passes the same defined verification and validation regardless of who or what wrote it; traceability from requirement to implementation to test stays intact; tool data flows respect confidentiality rules; and the usage itself is risk-assessed and documented. Sector rules and your notified body or supervisor add specifics - the assessment is theirs and your QA/regulatory team's.
What does DORA mean for AI coding in financial companies?: DORA (applicable since January 2025) makes ICT risk management a regulated discipline for financial entities - including secure development practices and control of ICT third-party providers. An AI coding tool enters twice: as a third-party service whose data path and contract need managing, and as an influence on code that must still pass your secure development lifecycle. DORA does not name AI tools; supervisors ask how your ICT risk framework covers them.
Can AI-generated code go into a medical device?: IEC 62304 and the MDR regulate the software lifecycle - requirements, architecture, implementation, verification, maintenance - and demand documented evidence at each stage. Code that enters that lifecycle must satisfy the same verification whether a human or an assistant wrote it; what changes with AI is the volume of unverified input and the importance of provenance. Manufacturers additionally face AI Act duties if the device itself contains AI (Annex I deadline now August 2028). The conformity assessment stays with your notified body.
How does automotive handle AI-generated code?: Through the same instruments it already trusts: ISO 26262 for functional safety and Automotive SPICE for process capability, both built on traceability - every requirement maps to implementation and test. AI-generated code does not break this model; it stresses it, because volume rises and authorship blurs. OEM confidentiality terms and TISAX add the data-flow question: repository context reaching a cloud tool is exactly the material those terms protect.
Is there a sector where AI coding tools are simply forbidden?: We know of no general prohibition in the major EU frameworks as of July 2026 - the rules consistently regulate process, evidence and data protection rather than banning tool categories. Practical prohibitions do exist locally: OEM or client contracts that exclude external code processing, air-gapped environments where cloud tools cannot physically operate, and internal policies. Check contracts before frameworks - they bind first.
What is the common denominator across all three sectors?: Evidence over authorship. Every framework in this article converges on the same three demands: a defined process the code went through, verification results that prove it, and traceability that links change to requirement. Teams that verify each AI run against a written task and keep the record satisfy the shape of all three - the sector-specific depth then comes on top.

Keep reading

GovernanceThe AI Coding Policy TemplateEight sections with the reasoning per section - tools, data rules, task rules, verification, evidence, agent permissions, exceptions, review. The full template is in-page, no download gate.GovernanceThe EM Guide to AI Code QualityThroughput stays green while quality erodes - the four leading indicators from git and PR data, their warning signs and interventions, and the operating rhythm that steers without micromanaging.All articlesThe whole collection – 43 cited, dated guides on verifying AI-generated code.