AI governance and regulatory evidence

Later than the date most plans were written against, and the obligations themselves are unchanged. Article 113 originally set 2 August 2026 for stand-alone high-risk systems and 2 August 2027 for high-risk systems embedded in regulated products. The Digital Omnibus amendment, agreed between the Council and the Parliament in May 2026 and approved by the Parliament in June, moves those to 2 December 2027 and 2 August 2028 respectively. What has been in force since 2 February 2025 is the prohibited-practice list and the AI literacy duty, and the general-purpose model obligations have applied since 2 August 2025. For a high-risk system the obligations still include conformity assessment, technical documentation, risk management, data governance, human oversight, registration and post-market monitoring, so the practical implication has not moved either: a current inventory, a defensible classification of each system, and evidence generated by your process rather than assembled retrospectively. Tenhaw designs the operating model and delivery discipline that produce that evidence; we are not lawyers, formal legal interpretation should come from counsel, and you should check the dates against the Official Journal rather than against us.

Five things, and they are all answerable in weeks rather than quarters. An inventory of the AI already running, including embedded vendor features and anything bought outside procurement, because a plan written before the count gets rewritten later. A classification of that inventory by consequence, so the board can see which systems carry real risk rather than a flat list. A named accountable individual per class of decision, which is the first thing a regulator tests and the first thing a board should. A sequence with dates, showing which processes go first and what evidence each one produces as a by-product of the work. And an honest statement of what you cannot yet evidence, because the plans that survive board scrutiny are the ones that name their own gaps before somebody else does. If a stalled pilot is what prompted the board to ask, say so, and say whether it stalled on evidence, on ownership or on the data underneath it, because those three need different money and different people.

Four places. The inventory takes far longer than planned because AI entered the organisation through tool purchases and embedded vendor features rather than one programme. Governance is written as policy rather than embedded in process, so evidence has to be reconstructed. Accountability does not resolve to a named person, which is the first thing a regulator tests. And second-line risk arrives to review a finished system rather than to co-design it, so their only available lever is to block.

By designing the audit trail into the workflow rather than adding logging afterwards: what the agent was asked, what it retrieved, which tools it called, what it decided, which human approved or overrode it, and against which version of the system. The test is whether you could reconstruct a specific decision from six months ago without asking anyone what happened.

A named individual, and that has to be established before deployment rather than after an incident. Under regimes such as SM&CR accountability cannot rest with a system. In practice this means mapping each class of agent decision to a person with matching authority, and defining explicitly which decisions require human approval based on how consequential and how reversible they are.

Everything that behaves like AI in production, not just the systems a programme built: embedded vendor features, tools bought outside procurement, and anything adopted through individual initiative. It takes so long because AI rarely entered the organisation through one front door, so enumeration means going department by department rather than reading a project list. The inventory reliably takes three times as long as planned, so scope it as work rather than a precursor. Tenhaw's founder co-designed a target operating model across 500 teams at HSBC Global Payment Solutions, so the department-by-department pass is familiar ground. You cannot classify what you cannot enumerate. The effort pays for itself, because a governance plan written before the count is the one that gets quietly rewritten two quarters later.

Help design them. The common failure is one of sequencing. Risk and compliance are brought in at the end to review a finished system, so the only lever left is to block it, which everyone then experiences as friction. Put them in the room during operating-model design, defining the control points rather than assessing them afterwards. In Tenhaw's experience this is the single highest-leverage sequencing decision in a regulated agentic programme, and it costs nothing except being early. Controls designed with the people who will have to defend them also change the evidence, producing records that hold up under assessment rather than documentation reconstructed after the fact.

No. The forcing function moved, it did not disappear, and treating the delay as an exemption is the most common thing to get wrong. The Digital Omnibus amendment postpones the stand-alone high-risk obligations to 2 December 2027 and product-embedded ones to 2 August 2028, but nothing about what a high-risk system must evidence has changed, from conformity assessment and technical documentation through to registration and post-market monitoring. The prohibitions and the AI literacy duty have been in force since February 2025, and the general-purpose model obligations since August 2025. Tenhaw's advice to clients whose plan assumed the old date is to spend the extra time on the inventory, the part that takes longest, not on waiting.

On a fixed rhythm with named owners, in the same way as any other operating cadence, and certainly more often than annually. Governance reviewed once a year describes an organisation that no longer exists, and three things need the cadence. The inventory, because new AI arrives continuously through vendor features and tool purchases rather than through a programme you control. The classification, because a system's consequence shifts as its scope and usage grow. And post-market monitoring, because the obligations on high-risk systems do not end at deployment. Run each review as a working session that updates the record, with a named owner per item, rather than a committee that receives a report.

Audit trails, evaluation results, approval records and change history, produced as outputs of the delivery process rather than as a separate documentation exercise. If producing the evidence requires a project of its own, it will be late and thin, and reconstructed documentation is exactly what an assessor is trained to notice. For a high-risk system under the EU AI Act the record needs to support conformity assessment, technical documentation, risk management, data governance, human oversight, registration and post-market monitoring. Build the requirement into how work actually flows, so the records accumulate as people deliver, and the evidence becomes close to free rather than assembled under deadline.

There is no separate FCA AI rulebook, and the regulator has said it does not intend to write one. Tenhaw designs the operating model rather than the legal opinion, drawing on a decade of delivery inside regulated organisations including HSBC. Under the Senior Managers and Certification Regime, 'the system decided' is not a defence, so an FCA AI governance framework is the regimes you already answer to applied to AI, with individual accountability as its spine. It is four things: an inventory of the AI actually running, vendor features included; a classification of it by consequence; a named accountable individual for each class of agent decision, with matching authority and an approval boundary; and evidence generated by the delivery process rather than reconstructed for inspection.

Extend what you have, then close the three gaps it leaves. Scope is the first. Model risk governance sees models that went through a model lifecycle, while AI has arrived through tool purchases, embedded vendor features and individual initiative, so the inventory is built department by department, not read off a register. Accountability is the second, because agents act, and each class of agent decision needs a named individual with matching authority and a human-approval boundary set by consequence and reversibility. Evidence is the third, so audit trails, evaluation results, approval records and change history have to fall out of how work runs. Tenhaw publishes that method in full, and you are free to adopt it without hiring anyone.

It will store evidence. It will not create it. What an assessor asks for is audit trails, evaluation results, approval records and change history for specific systems and specific decisions, and those are produced by how the work runs rather than by the tool that holds them. Buy a platform and change nothing about delivery and you have a tidy home for documentation reconstructed from people's memories, which is expensive, thin, and exactly what an assessor is trained to notice. Tenhaw sells no platform; its own engineering handbook is 72 rules on GitHub, enforced by an agent rather than filed. Get the requirement embedded in the workflow first, then choose somewhere to keep the output. The order matters more than the product does.

It is usually bought one of two ways, and Tenhaw publishes both prices rather than quoting on request. If nobody has counted the estate yet, the AI Readiness Audit is the entry point at £44,000 fixed over four weeks, with the first two weeks spent inventorying what is actually in use across the business, sanctioned or not, and ending in working prototypes rather than a slide pack. If the direction is already clear and what you need is the operating model, accountability mapped onto named people and delivery that generates its own evidence, that is Agentic Design Team work at £35,000 to £55,000 a month for two senior people. The audit is standalone with no obligation to continue, and a recommendation to stop is a valid outcome.

In two passes. First, a practical triage of your own, classifying the inventory by consequence so a board can see which systems could genuinely harm a customer, a colleague or the firm, rather than reading a flat list of everything running. Second, the legal test against the EU AI Act's own categories, which is where counsel earns the fee, because the classification has to be defensible to somebody else rather than comfortable for you. You cannot classify what you have not counted, so enumerate before either pass. And keep the classification as a live record, because a system that was low-consequence at pilot scale rarely stays that way.

No, because they answer different questions. ISO/IEC 42001 certifies that you run a management system for AI: policies, roles, controls and review. The EU AI Act asks what a particular system evidences, and for a high-risk system that means conformity assessment, technical documentation, risk management, data governance, human oversight, registration and post-market monitoring. The certificate is genuinely useful, because the disciplines overlap heavily and both want a current, defensible record, but it does not discharge a per-system obligation. Firms running 42001 properly tend to find the per-system work smaller rather than unnecessary, because the inventory, the classification and the review cadence already exist.

Built into the work it costs very little, and bolted on afterwards it costs a great deal. The expensive version is a policy saying agent decisions must be auditable while nothing in the workflow changes, so the records get assembled under deadline from memory. Where the audit trail, the evaluation results and the approval record are outputs of the delivery process, they accumulate while the team works. Tenhaw's work at Globelynx cut lead time by 60% inside six months, which is the direction disciplined delivery moves in. What people usually mean when they say governance slowed them down is second line arriving to review a finished build, with blocking as the only lever left. That is a sequencing failure rather than a control problem.