At the board meeting, the CISO of a hospital is asked who owns AI. She names herself, because she assesses the tools. The DPO says he does, because patient data are involved, and the operations manager points at IT, because IT rolled out Copilot. All three are right about their own part, and nobody knows who decides whether the transcription tool in the outpatient clinic stays.
That is the normal state of affairs, and the answer is not one owner but one owner per decision. AI governance is a series of decisions, and each one needs someone who takes it, people who feed into it, and people who see the outcome.
Why is "the DPO does AI" not an answer?
Because under the GDPR the data protection officer has a supervisory role: inform, advise, monitor compliance. That role requires independence. Whoever decides that a tool is allowed cannot at the same time independently check whether that decision was right.
Something similar holds for the CISO and IT. The CISO assesses risk, but whether a risk is acceptable for the outpatient clinic's work is something the clinic knows. IT can roll out a tool and measure it, but IT does not decide which data get discussed in a consultation. As soon as one of these three does everything, the business drops out of the decision, and the decision becomes a technical setting.
Who does what?
The names differ per organisation, the division of work less so.
| Role | Decides on | Delivers | Sees |
|---|---|---|---|
| Board | The framework, the risk appetite, who carries which role | Time and mandate | The quarterly figures: tools, share through allowed tools, what still has no decision |
| Owner in the business (department head, process owner) | Whether a tool may be used for this work: the status per tool | The context: which work, which data | The tools in use in their own work and their status |
| DPO | Nothing; checks and advises | The assessment of the processing, the DPIA, the lawful basis | The register, the measurement and its design |
| CISO | The security risk of a tool and the requirements for vendors | The risk assessment per tool | Observed tools, risk bands, notices without a decision |
| IT | Rollout, settings, measurement | The observation of what is used and the record of each status | The dashboard, the inbox with new tools |
| Procurement | Contract, data processing agreement, licences | The contractual facts per vendor | Which tools are purchased and which are in use without a contract |
| HR | AI literacy, the place of AI in job profiles and conduct rules | Training and its record | Who has received which explanation |
| Team leads | How the decision is applied in their own team | The alternative in practice, the team's questions | What the team uses and where it gets stuck |
| Works council | Consent on arrangements that affect employees | The employee's view of the design | What is recorded and who sees it |
| Employee | What happens at the moment of work: continue, alternative, adjust | The behaviour that makes up the figures | The organisation's decision when a tool opens, a marking on sensitive data |
Three things stand out. The DPO decides nothing, and that is the point. The business decides the most, and that is the role most often left unassigned. And the employee sits at the bottom as a decision-maker, not as a subject.
Which decisions really sit with the board?
Fewer than boards often think, and heavier.
The board sets the framework: which kinds of data never go into an AI tool, which environment is the preferred route, how much risk the organisation accepts in exchange for which benefit. It assigns the roles in the table, by name. And it sees the figures, regularly and at organisation level: which tools are in use, what share of use runs through allowed tools, how many tools still have no decision and whether that number is falling.
What the board does not do is decide per tool; a board that tries becomes the bottleneck every new tool waits for. What a board should ask every quarter is in what is AI governance, the pillar of this subject.
Where do the works council and the employee sit?
The works council does not review which tools are allowed, but the arrangements that affect employees: processing of their data, a facility that can observe behaviour, sometimes a mandatory training programme. A measurement of AI use therefore belongs on its table early; a decision about a translation tool for customer correspondence usually does not. Where that line runs is in when must the works council be involved in AI.
The employee is the last row and the most important one. All the decisions above converge on one moment: someone opens a tool, or types something sensitive. If they then see what the organisation has decided, with the alternative alongside, the governance works. If they see nothing, it exists in a document.
That is also why HR and team leads are in the table: AI literacy under Article 4 of the AI Act is an obligation of the organisation, and who carries it is in who is responsible for AI literacy.
What does this look like in the hospital?
After the board meeting the table is filled in, and then things move quickly.
IT shows that the transcription tool has been opened on eleven devices and has no decision yet, alongside Copilot, ChatGPT and a summarising tool nobody knew about. The CISO assesses the transcription tool: vendor outside Europe, trains on input, no data processing agreement. The DPO establishes that consultations contain health data and that this is processing that cannot go on as it is. Procurement reports there is no contract.
The head of the outpatient clinic, as owner, decides: not allowed, with the transcription feature of the approved environment as the alternative, and a request to procurement to find a tool with a data processing agreement. HR adds one line to the explanation for doctors. The works council receives the design of the measurement, not the decision about the tool.
Nobody did anything extraordinary. The only difference from the meeting before is that every step had a name.
BeeSensible supports exactly that part: the extension shows which AI tools are opened in the organisation, without a user id and without content, an administrator sees in the inbox which tools still have no decision, and the owner records the status in the AI Tools module. Who holds which role is for the organisation to decide; the product decides nothing and blocks nothing.
This is the list where the owner records the decision: a status per tool.