Roles and decision rights

An operating model is not an org chart. It is a list of decisions and, for each one, the person who makes it, the people who must be consulted first, and what is written down afterwards. Programmes fail at this layer more often than at any other, and they fail in a specific way: everything has an owner in principle and no decision has a decider in practice.

Start from the decisions, not the boxes

There are about nine decisions in an AI programme that genuinely need an allocated owner. Write them down before you design any structure.

Whether a proposed system may proceed at all. What tier it is classified as under each applicable regime. Whether the firm is provider or deployer for it. Whether an identified residual risk is accepted. Whether the system may go live. Who exercises human oversight in operation, and with what authority. Whether an event is a reportable incident, and under which deadline. Whether a change is a substantial modification. Whether a system is retired, and what is retained.

Each of those has a wrong answer that costs money, and each is routinely left to whoever is in the room. The value of writing the list is that it converts an abstract accountability debate into nine concrete appointments.

The roles that carry them

Business owner, per system. Accountable for the use case, the benefit claimed, and the residual risk accepted. This is the role that must exist for the AI Act's deployer duties to land anywhere: someone has to be accountable for using the system per its instructions and for informing affected persons.

Technical owner, per system. Accountable for the build or the configuration, the testing, the logging, the monitoring and the documentation pack tracking the deployed version.

AI governance lead. Owns the register, the classification method, the policy and the literacy record. Coordinates rather than executes. This is a thin role done well, and the most common design error is to staff it as a delivery team that quietly takes work off the first and second lines.

Human oversight role, per high-risk system, named. Not "the claims team". The Act requires natural persons with the necessary competence, training and authority, and support to exercise it, who can understand the system's capacities and limitations, monitor operation, remain aware of automation bias, correctly interpret the output, decide not to use it or to disregard, override or reverse it, and intervene or interrupt through a stop function so the system halts in a safe state. A role description that does not mention the stop function has not engaged with the provision.

Independent reviewer. FINMA's expectation of independent review separate from the developing unit makes this structural rather than optional for Swiss supervised firms. It does not have to be internal audit; it has to be someone who did not build the thing.

Legal and data protection. Consulted on classification, impact assessment and disclosure. Not the owner of those artefacts, which belong to the business.

Authority is the test, not responsibility

A role has decision rights when it can stop something. If the human oversight role can raise a concern but cannot prevent a release, the oversight is nominal and the paperwork describing it is misleading. Two practical tests:

Has the oversight role ever exercised its override, and is there a log of it? A system with oversight designed in and never exercised should prompt a question about whether it is real.

Who did the business owner have to persuade to go live? If the answer is nobody, then the go-live decision has no gate, whatever the policy says.

Competence, training and authority as a recorded trio

Article 26(2) is unusually specific in requiring all three together, and firms routinely evidence one. Training attendance is easy to produce and proves the least. Competence means the person can actually judge the output, which requires a check rather than a register entry. Authority means the organisation will support the decision if the override is unpopular, which is demonstrated by what happened the last time someone used it.

The literacy record should therefore carry, per role, the content delivered, the method, the date, how competence was checked rather than attendance recorded, and how the level was matched to that group's technical knowledge, experience and context of use. A developer, a procurement officer and a claims reviewer need materially different things, and one generic course for everyone is the failure this duty was drafted to catch.

Worked example: the model that nobody could stop

A bank's fraud detection model blocks transactions in real time. The operating model names a business owner in financial crime, a technical owner in data science, and an oversight role held by the duty manager in the operations centre.

An incident review after a weekend of false positives finds the following. The duty manager could see blocked transactions but not the score or the contributing factors, so could not judge whether a block was right. The stop function required a change request to the data science team, available Monday. The escalation route ran to a business owner who was uncontactable out of hours, and the procedure had no alternate.

On paper the operating model was complete: three named roles, documented. In practice there was no oversight, because the person holding the role could not interpret the output, could not halt the system, and could not reach anyone who could.

The remedy is not another role. It is three changes to the existing one: give the oversight role the information needed to judge an output, give it a stop mechanism it can operate itself that halts the system in a safe state, and give it an escalation route with out-of-hours cover and a named alternate. That is what converts a named role into a decision right.

As of 24 September 2026.