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

No framework on this page supplies a blanket tool permission. First determine which law, standard, contract and internal policy applies to the product and entity. Then assign an owner for tool data flows, change verification, traceability and approval. The legal and conformity assessment remains with your QA, regulatory and legal teams.

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?

The primary sources reviewed here do not state a general category-wide ban as of July 16, 2026. That is not permission: a product scope, national rule, contract, customer term, confidentiality requirement or internal policy may still prohibit a particular tool or data path. Have the accountable legal, QA and security owners decide from the applicable text.

What is the common denominator across all three sectors?

A reusable control pattern is a written task, linked change, verification receipt and named approval. It is only a base pattern: it does not itself satisfy DORA, IEC 62304, ISO 26262 or a contract. Each accountable sector owner must map and tailor it to the applicable requirement.

Compliance

AI Coding in Regulated Industries

Last updated: 2026-07-164 min read

AI coding in regulated industries requires an applicability decision before a control design. DORA, IEC 62304 and ISO 26262 have distinct scopes; contracts and internal policies add separate constraints. This review maps each source to an accountable owner, a reviewable artifact and an explicit boundary rather than issuing a blanket tool verdict.

Contents

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

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

Tool authorship does not settle applicability. A binding rule, sector standard, contract and internal policy have different legal force and different owners. The useful engineering question is therefore not “is AI allowed?”, but which requirement applies, who owns the decision, and which reviewable work product demonstrates the selected control.

Four layers, four owners

A verification report implements a control; it neither decides a law's scope nor replaces a conformity judgement.
	Binding rule	Standard	Contract / internal policy	Operational control
Norm typeWhether the source is law, a standard, a contract/policy, or implementation.	EU or national law when its scope appliesDORA RTS - Delegated Regulation (EU) 2024/1774 · 2026-07-16	Normative sector standard when adopted, contracted, or used for conformityIEC 62304:2006+AMD1:2015 - software lifecycle processes · 2026-07-16	Customer, OEM, procurement, or internal requirementEditorial control mapping · 2026-07-16	Technical implementation of a selected requirementEditorial control mapping · 2026-07-16
Applicability checkWho determines whether and how the requirement applies.	Legal/regulatory assessment by product, entity and jurisdictionDORA RTS - Delegated Regulation (EU) 2024/1774 · 2026-07-16	QA/safety selects edition, scope and tailoringIEC 62304:2006+AMD1:2015 - software lifecycle processes · 2026-07-16	Legal, procurement and governance read the actual textEditorial control mapping · 2026-07-16	Control owner reviews design and operating effectivenessEditorial control mapping · 2026-07-16
Accountable ownerWhich role owns the decision or control.	Management body or named accountable functionDORA RTS - Delegated Regulation (EU) 2024/1774 · 2026-07-16	QA, safety, or process ownerIEC 62304:2006+AMD1:2015 - software lifecycle processes · 2026-07-16	Contract or policy ownerEditorial control mapping · 2026-07-16	Engineering plus independent reviewerEditorial control mapping · 2026-07-16
Work productWhich reviewable output is produced.	Applicability analysis and duty mappingDORA RTS - Delegated Regulation (EU) 2024/1774 · 2026-07-16	Lifecycle artifacts, traceability and reviewsIEC 62304:2006+AMD1:2015 - software lifecycle processes · 2026-07-16	Tool allowlist, data rules and approval pathEditorial control mapping · 2026-07-16	Task, change, test receipt and approvalEditorial control mapping · 2026-07-16

A verification report implements a control; it neither decides a law's scope nor replaces a conformity judgement.

The three sectors at a glance

Three sectors, separate applicability boundaries

The shared control design is useful; legal or normative applicability remains sector-specific.
	Finance	Medical devices	Automotive
Primary anchor	DORA + Delegated Regulation 2024/1774DORA RTS - Delegated Regulation (EU) 2024/1774 · 2026-07-16	IEC 62304 for software lifecycle; assess MDR/product scope separatelyIEC 62304:2006+AMD1:2015 - software lifecycle processes · 2026-07-16	ISO 26262:2018 for safety-related E/E systemsISO 26262:2018 - road-vehicle functional safety · 2026-07-16
Reviewable control	Roles, risk, testing and approval before productionDORA RTS - Delegated Regulation (EU) 2024/1774 · 2026-07-16	Link lifecycle task, change, verification and maintenanceIEC 62304:2006+AMD1:2015 - software lifecycle processes · 2026-07-16	Link safety requirement, software change, verification and change controlISO 26262:2018 - road-vehicle functional safety · 2026-07-16
Boundary	DORA does not name AI coding; assess entity and function scopeEditorial control mapping · 2026-07-16	IEC 62304 excludes final device validation and releaseIEC 62304:2006+AMD1:2015 - software lifecycle processes · 2026-07-16	ISO 26262 does not apply to every piece of automotive softwareISO 26262:2018 - road-vehicle functional safety · 2026-07-16

The shared control design is useful; legal or normative applicability remains sector-specific.

These anchors are deliberately separate. IEC 62304 states a software-lifecycle scope and excludes final device validation and release; ISO 26262 concerns safety-related road-vehicle E/E systems; and DORA applies through its financial-entity and ICT-function scope. The Commission’s current timeline places product-integrated high-risk AI-system rules at August 2, 2028. None of those facts determines whether one specific coding assistant is acceptable.

Where AI coding actually creates friction

Volume vs. evidence. AI assistance can increase change volume. Measure the actual volume and review load; do not assume a productivity gain or a matching documentation multiplier.
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.

A base control pattern to assess and tailor

A reusable starting point is 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 that a named control owner can assess. It is not evidence that an assessor will accept the format. 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. Which parts of a run stay on the machine, and the two cases where something does leave it, are set out under what leaves your environment.

This orientation provides

Primary sources and an as-of date
Separate norm types and owners
Sector-specific applicability boundaries
One reviewable base-control pattern

It does not provide

Legal or regulatory advice
A conformity pre-assessment
A claim that a tool is approved
A substitute for sector-specific safety or QA work

Applicability first, control second, record third.

FAQ

May regulated companies use AI coding tools - and under which conditions?: No framework on this page supplies a blanket tool permission. First determine which law, standard, contract and internal policy applies to the product and entity. Then assign an owner for tool data flows, change verification, traceability and approval. The legal and conformity assessment remains with your QA, regulatory and legal teams.
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?: The primary sources reviewed here do not state a general category-wide ban as of July 16, 2026. That is not permission: a product scope, national rule, contract, customer term, confidentiality requirement or internal policy may still prohibit a particular tool or data path. Have the accountable legal, QA and security owners decide from the applicable text.
What is the common denominator across all three sectors?: A reusable control pattern is a written task, linked change, verification receipt and named approval. It is only a base pattern: it does not itself satisfy DORA, IEC 62304, ISO 26262 or a contract. Each accountable sector owner must map and tailor it to the applicable requirement.

Keep reading

ComplianceThe EU AI Act for Development TeamsTeams using AI coding tools are usually deployers - the small duty set that actually applies, the post-omnibus deadlines (Dec 2027/Aug 2028), and what the Act does not regulate: your code quality. Not legal advice.ComplianceGDPR-Compliant AI CodingCode is rarely personal data - the context AI tools ingest often is. The eight-point checklist: data flow, Art. 28 DPA, transfers, training opt-outs, minimization. Assessment stays with your DPO.All articlesThe whole collection - 58 cited, dated guides on verifying AI-generated code.

Sources

Want to see what your last agent run would have looked like?

Request access