AI governance for regulated industries — what it means in practice

AI governance in a regulated industry works when every material system decision has an owner, a criterion, evidence and a reassessment date. An AI policy alone cannot provide that control. The operating model must connect RACI accountability, decision records, an Evidence Pack and recurring AI Assurance. The law sets duties according to role, risk and use case; the working method below is Semitora practice for translating those duties into technical work and a reviewable audit trail.

Table of contents

This map moves from accountability for one system to evidence, sector decisions, reassessment and the boundary between law and implementation practice.

• The operating model: decision, evidence, action
• RACI and decision rights for a specific system
• Decision Record: one decision, one trail
• Evidence Pack and AI Assurance
• Decision matrix for finance, healthcare and manufacturing
• Reassessment triggers
• What the AI Act requires and what Semitora practises
• FAQ about AI governance in regulated industries

The operating model: decision, evidence, action

The smallest useful unit of governance is not a committee or policy; it is a decision about a defined system version and use case.

A sound decision answers five questions: what is being allowed, who is accountable, which evidence supports it, what conditions apply, and when the assessment reopens. The team can then do concrete work: repair a test set, change permissions, stop a release or deliberately accept a limitation.

The model runs as a loop. First describe the system and intended use, then assess risk and requirements, collect evidence, make the decision, and monitor the conditions on which it rested. A change to the model, data or process starts another turn. That does not mean the board approves every small update. It means the organisation defines escalation thresholds in advance and knows who has authority for each class of decision.

In practice, an AI-system register is useful input to the loop, but the register is not the outcome. The outcome is a defensible state: current classification, approved quality criteria, working human oversight, a response plan and named owners. If one item is missing, the record should expose the gap and its due date rather than hide uncertainty behind a green status.

RACI and decision rights for a specific system

RACI becomes useful when it covers named decisions rather than broad statements such as “IT is responsible for AI”.

Assign one A, the role accountable for the outcome, to every stage. R performs the work, C is consulted before the decision, and I is informed. For risk classification, a compliance owner may be accountable while the technical team supplies the system function and data description. For production approval, the business-process owner may be accountable while security, privacy and the model owner assess their criteria. The allocation depends on the organisation; the AI Act does not mandate a RACI table.

Decision rights should cover at least admission to a proof of concept, production approval, a change to the model or data sources, residual-risk acceptance, human handoff, rollback and system withdrawal. The committee’s name matters less than operational clarity. The person on duty must know who can stop the system, and the accountable owner must receive enough evidence to sign the decision.

Start with the open AI Governance RACI and decision-rights template. Complete it for one system using roles that actually exist in your organisation. Then challenge it with a scenario: the model starts giving answers unsupported by source material. If the table does not say who sets the alert threshold, who cuts traffic and who approves restoration, it still describes an organisation chart rather than control over risk.

Decision Record: one decision, one trail

A Decision Record should let an independent reader reconstruct why a defined system version was approved, restricted or stopped.

The record contains the system and version identifier, decision, owner, date, criteria, evidence links, known limitations, validity conditions, the next calendar review and event-driven reassessment triggers. Do not paste full reports into the form. Link to a versioned evaluation result, remediation ticket, approved architecture and decision log. The record stays short while preserving a path to primary artifacts.

Consider an employee-facing RAG assistant for a call centre. The team approves it for two case categories only. Criteria cover citation completeness, a ban on changing customer data autonomously, and human transfer when a defined intent appears. Evidence consists of golden-set results, an access-control test and logs from trial traffic. A base-model update, new document category or fall in grounded-answer performance below the agreed threshold triggers reassessment. That is a claim another reviewer can inspect.

Avoid recording “the system complies with the AI Act” when the assessment only covered quality testing. State the boundary instead: “meets the technical production-gate criteria for version X; legal classification is in document Y; open actions are in register Z.” Precision prevents a narrow result from being represented as broader assurance.

Evidence Pack and AI Assurance

An Evidence Pack gathers the support for a decision, while AI Assurance checks whether that evidence still represents the live system and its risk.

In Semitora practice, the pack covers system inventory and owner, role and risk classification, criteria and golden set, evaluation plan and results, logs and versioning, human handoff, rollback, the go/no-go decision and remediation. It is not a single statutory document named by the AI Act. It is a working structure that connects artifacts produced by product, data, security, compliance and operations teams.

The detailed structure is explained in AI Act Evidence Pack: seven proof items. AI Assurance adds a recurring independent check: was the right version assessed, was the sample fit for purpose, can results be reproduced, does human control work, and does the decision follow from the evidence? Such a review does not replace legal advice or a formal conformity assessment.

The pack should grow with the potential consequence of error. An internal procedure search tool needs less depth than a system that affects healthcare provision or credit decisions. Even a lower-impact case should retain a minimum record: version, owner, criterion, result and decision. Without those fields, the next team cannot distinguish a tested system from a polished demonstration.

Decision matrix for finance, healthcare and manufacturing

Sector context changes the harm, data and escalation path, so the same model should not automatically receive the same governance decision everywhere.

Sector and example	Governance decision	Semitora evidence	Owner	Reassessment trigger
Finance — credit-analyst assistant	Does the output only support analysis, or influence a decision, and when must the analyst reject the recommendation?	Process map, prohibited-automation test, golden set, override log and record of answer grounds	Credit-process owner	Change to data sources, model, decision threshold or analyst use
Healthcare — RAG for staff	Does the tool provide administrative information, or enter clinical decision-making, and how does human transfer work?	Use boundary, source review, citation-completeness test, handoff scenarios and incident log	Healthcare-process owner	New specialty, document set, model, or error that could affect a patient
Manufacturing — maintenance-instruction assistant	Can the recommendation initiate an action on machinery and which interlocks apply before execution?	Instruction version, access-control test, out-of-scope test, operator confirmation and rollback plan	Maintenance owner	Change to line, instruction, control integration, autonomy level or safety event

The columns “Semitora evidence”, “Owner” and “Reassessment trigger” describe Semitora implementation practice, not a literal AI Act requirement. The matrix does not automatically classify any example as high-risk. Classification requires analysis of the specific purpose, function, organisation’s role, annex routes and exceptions. Our guide to an AI readiness audit and what we check helps frame that work, but formal legal interpretation should be agreed with the appropriate adviser.

The most important sector difference often sits outside the model. In finance, it may be how an analyst uses the recommendation. In healthcare, it is the boundary between administrative and clinical information. In manufacturing, connection to a physical process can determine the consequence. Governance must therefore cover the interface, procedure and human behaviour, not only API parameters.

Reassessment triggers

A calendar review is necessary but insufficient because risk usually changes after a specific event in the system or business process.

A technical trigger could be a new model, embedding, system prompt, knowledge base, agent tool or access-control mechanism. Business triggers include a new user group, product, channel, jurisdiction or decision supported by the system. Evidence triggers arise after quality regression, an incident, complaint, failed handoff or data-distribution shift. A legal trigger follows a change in legislation, guidance or use-case classification.

Define a response for every trigger. A small index update may run an automatic golden-set regression. A base-model change may block release until evaluation is repeated. A patient-safety incident should start escalation, preserve logs and force a stop-or-continue decision. An alert without an owner and response time is only a notification.

Metrics must lead to action. RAG evaluation: how to measure quality shows how to connect criteria, a test set and results. Governance adds a decision threshold, accountable person and rule for what happens after crossing that threshold. This turns a dashboard from observation into control.

What the AI Act requires and what Semitora practises

The AI Act sets duties according to organisational role, system type and use case; it does not prescribe one universal RACI operating model for every company.

The primary source is Regulation (EU) 2024/1689. For high-risk systems, it addresses matters including risk management, data requirements, technical documentation, logging, information for deployers, human oversight, and accuracy, robustness and cybersecurity. Responsibilities differ between providers and deployers. It is therefore wrong to apply the full list to every chatbot or assume that buying a packaged tool removes the business user’s duties.

The timetable was amended by Regulation (EU) 2026/1744, which entered into force on 27 July 2026. Amended Article 113 keeps the general application date of 2 August 2026. For high-risk AI systems referred to in Article 6(2) and Annex III, Chapter III, Sections 1–3, except Article 6(5), apply from 2 December 2027. For high-risk AI systems referred to in Article 6(1) and Annex I, the same sections, again except Article 6(5), apply from 2 August 2028. Those later dates do not remove rules already in application or duties under other sector legislation. The current legal context is summarised on Semitora’s AI Act page.

RACI, Decision Records, the Evidence Pack name, one A per decision, the trigger set and the AI Assurance cycle described here are Semitora implementation practice. They are designed to create a navigable trail between an obligation, technical control, test result and decision. They are not a compliance guarantee. This article is informational and does not replace legal advice, formal classification or conformity assessment for a specific system.

FAQ about AI governance in regulated industries

These answers clarify common accountability boundaries without turning an implementation method into a universal legal obligation for every organisation.

Does every company using AI need an AI governance committee?

No. It does need clear decision rights, a system owner and a risk-appropriate escalation path. Existing roles can perform those functions in a smaller organisation. A committee helps when decisions cross several domains or require joint approval, but creating one does not itself prove control.

Is RACI required by the AI Act?

The AI Act does not require a table called RACI. In defined situations, however, it assigns concrete duties to relevant actors and requires responsibilities to be carried out. RACI is Semitora’s method for translating that allocation into operational decisions. Another mechanism can work if it identifies accountable owners and performers just as clearly.

How does an Evidence Pack differ from technical documentation?

Technical documentation has a legally defined scope for systems subject to the relevant requirements. An Evidence Pack is Semitora’s broader working structure connecting documents, test results, operational logs, decisions and remediation. It may reference technical documentation as one item of evidence, but does not replace it.

How often should an AI system be reviewed?

There is no useful single interval for all systems. Set a calendar review and event-driven triggers. The greater the consequence of error and the faster the model, data or process changes, the stronger the control should be. Every material Decision Record should name both the next calendar review and the event-driven triggers that force earlier reassessment.

Where should an organisation start with AI governance?

Choose one live or planned system. Describe the use case, company role, owner, data, users and possible consequence of error. Then create its RACI, define the first decision gate and collect evidence for that gate. If scope remains uncertain, begin with an AI readiness audit and keep technical findings distinct from legal advice.