Before asking whether AI can do something, an organization has to establish who answers for it when it does it badly.
This isn’t a formality. It’s the question that, if asked at the start, determines most of the technical choices that follow: what actions the system can perform, where it stops, what gets logged, which checks are mandatory.
If it’s asked at the end, typically at the first significant error, the answers have already been given implicitly by the architecture. And they’re rarely the ones the organization would have chosen.
The minimum roles
Governance doesn’t require a dedicated structure. It requires three responsibilities to be assigned to named people, even part-time and even in small organizations.
The process owner. This is whoever answers for the outcome of the process the system operates in, and keeps answering for it after the system is introduced. They decide which activities can be assisted, which thresholds to apply, when to suspend use.
It’s the role most often left undefined, because it seems absorbed by the project. It isn’t: a project has a project lead, who’s done at launch. The process has an owner, who stays.
The technical lead. Oversees operation: monitoring, updates, incident management, vendor relations. Needs to know the architecture well enough to diagnose anomalous behavior and assess the impact of a change.
The compliance lead. Checks compliance against data protection, sector regulation and the AI Act, and maintains the documentation. In most organizations this is an existing role that picks up a new scope.
Alongside these, where the output affects people, involving someone who represents the users. This isn’t a control role, it’s a detection role: systematic errors get noticed first by whoever uses the tool every day.
The check is simple. If, faced with a significant error, it isn’t immediately clear who calls whom, the roles aren’t defined.
What needs to be documented
Five elements, kept up to date and not reconstructed after the fact.
The data. Which sources feed the system, on what legal basis, with what permissions, kept for how long. This is the connection point with existing GDPR documentation and shouldn’t be duplicated: it should be linked.
The versions. Which configuration is active, which model, which document corpus, since when. Without versioning it’s impossible to establish whether an error found today also affects outputs produced three months ago.
The criteria. Confidence thresholds, routing rules, cases where human confirmation is mandatory. These need to be written in language understandable to non-technical people, because they’re governance decisions expressed as parameters.
Discarded cases. Outputs rejected or corrected by operators, with the reason. This is the most useful documentation and the most neglected: it feeds improvement and is the evidence that human oversight is real, not nominal.
Incidents. What happened, what impact, what intervention, what corrective measure. With a definition of what counts as an incident set in advance, otherwise nothing gets logged.
The AI system registry as a working tool
The AI Act has made the registry a familiar topic. The risk is that it gets filled in as a compliance exercise, kept by one function and ignored by the others.
A useful registry answers five questions for each system in use: what it’s for, who owns it, what data it processes, what risk classification it has, when it was last checked.
The first attempt at filling it in almost always produces two unexpected results.
Tools adopted independently by individual offices surface, unknown to management or IT. This is the most common outcome and the most useful one: you can’t govern what you don’t know about.
And it turns out some systems considered critical fall under limited risk, while others thought marginal touch more sensitive areas than expected.
On the regulatory side, keep in mind that the framework was recently amended. The obligations for high-risk systems under Annex III, originally due in August 2026, now apply from December 2, 2027 following the amendments introduced in July 2026, while transparency, oversight and penalties are already in force. The classification of your own systems still needs to be verified with legal counsel against the consolidated text.
The postponement isn’t a reason to delay the inventory. Sixteen months is not much time for an organization that needs to identify the systems in use, classify them, update the documentation and train those responsible.
How to start governance with limited resources
A four-step path, sustainable even without dedicated structures.
Inventory the systems in use, including those adopted informally. A shared spreadsheet is enough to start.
Assign an owner to each one. A name, not a function.
Classify by consequence before technology: what would happen if the output were wrong and nobody noticed. This is a question anyone who knows the process can answer, and it produces an immediate priority ranking.
Define controls only for the systems at the top of that ranking. One effective control on three significant systems is worth more than a formal procedure on twenty.
What governance doesn’t do
It doesn’t make an inaccurate system accurate. These are separate checks: governance is about roles, documentation and controls; accuracy is measured on real cases.
It doesn’t remove accountability, it makes it explicit and traceable. In the event of an error, the organization still answers for it; with defined governance it can show what measures it had in place.
It doesn’t replace operational judgment. No procedure covers every case, and people’s ability to recognize an anomalous situation remains the most effective control.
And it doesn’t work if it stays a document. Governance that doesn’t produce periodic reviews, logged discards and traceable decisions exists only on paper.
In closing
AI governance isn’t a separate chapter: it’s how an organization decides what to delegate and under what guarantees. It’s cheap to set up and expensive to catch up on later.
The starting point is an honest inventory and assigning an owner to each system. From there, the rest can be put in order.
If you’re working through this, we’re available for a conversation about governance and compliance applied to your context, starting from the systems already in use.
