There is a well-understood distinction in programme governance between a sponsor and an owner. The sponsor secures budget, champions the project at senior level, and removes organisational blockers. The owner is accountable for the system's behaviour in production — for what it does, what it gets wrong, and what happens when it fails. These are different jobs. They require different information, different authority, and different accountability structures.
Most AI projects have a sponsor. Many do not have an owner in the operational sense — a named individual who is accountable for the system's outputs, who receives its performance data, and who has the authority and obligation to act when something is wrong. When those two roles are conflated, or when the owner role is left unfilled after deployment, the result is a system that nobody is watching in the way that matters. Problems accumulate. Signals are missed. By the time anyone with authority becomes aware that something is wrong, it has been wrong for a long time.
The Post Office Horizon scandal is the most documented case of this failure at scale — and the Inquiry's findings about the governance structure are as instructive as any technical post-mortem.
What the Horizon Inquiry established about accountability
The Horizon IT system, developed by Fujitsu and deployed in Post Office branches from 1999, produced accounting discrepancies that sub-postmasters were unable to explain. The Post Office pursued prosecutions and civil recovery actions against over 700 sub-postmasters on the basis of the Horizon data, despite internal awareness of bugs and unexplained discrepancies in the system.
The Post Office Horizon IT Inquiry, chaired by Sir Wyn Williams, has examined in detail how this was possible. Among the structural findings: the governance arrangements for the system created a situation in which complaints from sub-postmasters about the system's behaviour were handled by people with an institutional interest in the system's reliability, and were not escalated to anyone with both the authority to act and the independence to evaluate them objectively.
This is not a story about malicious actors, though the Inquiry has addressed individual conduct extensively. It is a story about what happens when a deployed system produces outputs that affect real people, and no one with decision-making authority has a clear, documented obligation to evaluate those outputs against an independent standard of correctness.
"The evidence before the Inquiry suggests a persistent failure to take seriously the possibility that the Horizon system was producing incorrect data. This failure was not confined to any single individual — it was structural. The governance arrangements did not create a clear accountability for someone with authority to say: this system may be wrong, and we must investigate that possibility rather than defend against it."
The EU AI Act's Article 26 is a direct response to this structural gap. It requires deployers of high-risk AI systems to designate a named individual responsible for overseeing the system's operation — with specific obligations including monitoring actual performance against intended purpose, and reporting to the provider when the system is not performing as intended. Not a sponsor. An owner. Named, accountable, obligated.
The four accountability gaps that Horizon represents
The Horizon governance structure had senior leadership, vendor contracts, operational procedures, and a helpdesk. What it lacked were four things that the Article 26 deployer obligation is now designed to require for all high-risk AI systems deployed in the EU.
Why this is an active risk in current AI deployments
The pattern the Horizon Inquiry has documented is not historical. It is the default governance structure for the majority of enterprise AI deployments today. A project team builds and deploys a system. The project team moves on. The system is owned by the business unit that uses it — but the business unit's accountability is for the outputs, not for the correctness of the system producing them. Nobody has the explicit obligation to ask whether the system is getting it wrong, independent of whether the people affected by the system are raising complaints.
Complaints are not a reliable signal. Sub-postmasters raised complaints for years. The complaints were handled by people with an institutional interest in the system's reliability. The signal did not reach anyone with the authority and independence to act on it. This is not an exception — it is a predictable consequence of a governance structure that treats system correctness as the vendor's problem rather than the deployer's obligation.
Article 26 is written precisely to prevent this. The deployer obligation is structural: a named individual, with specific authorities and specific monitoring obligations, accountable for the system's performance throughout its operational life. Not the project sponsor. The system owner.
Before any AI system is deployed, fill in four fields in the governance record. These fields do not require a new governance framework — they require a decision about who is accountable, made explicitly rather than by default.
Named system owner: [name and role] — accountable for the system's outputs in production from deployment date onwards.
Performance data routing: [how and how often] the owner receives performance data, independent of the team that built or maintains the system.
Suspension authority: [name and role] has unilateral authority to suspend the system pending investigation, without requiring vendor approval or board sign-off.
Anomaly investigation obligation: any output-driven action against a user must be reviewed against an independent check before it is executed, and that review is the owner's obligation, not the caseworker's discretion.
If any of these four fields cannot be filled, the system is not ready to deploy. Not because the technology is incomplete. Because the accountability structure that makes the technology governable has not been established.