Risk, Governance and Accountability

Governance is a leadership job

Your managers can write practical ground rules for their teams. The Safe AI for Teams course shows them how. What they cannot do is decide the organisation's appetite for risk, which uses are off limits everywhere, or who answers to the board when something goes wrong. That sits with you.

Good AI governance is not a thick document. It is a small number of clear decisions, made deliberately, written down, and revisited. This lesson covers four: accountability, data, regulated contexts and records.

A named human owns every output

The principle is simple and it does not bend. Every output that leaves a person's desk has a named human who owns it. Not the tool, not the vendor, not "the process". A person, who checked it and put their name to it.

This matters most at the top. If a board paper, a customer decision or a public statement contains an AI error, "the system produced it" is not an answer anyone will accept, and it should not be. Vendor terms almost always disclaim responsibility for output. Accountability stays inside your organisation whether you plan for it or not.

For agents and automated processes, the owner is the person accountable for the process itself. Someone must be able to say what the system is allowed to do, how it is monitored, and when it gets switched off.

Data handling

Decide at organisation level which categories of information may go into which tools. Customer data, staff records, commercially sensitive figures, legally privileged material and anything under a confidentiality agreement usually need the tightest limits.

Then make sure there is an approved route for everyday work. When the official tools are unusable, people use personal accounts instead, and you lose visibility of where your data has gone. A clear, usable set of approved tools is a risk control, not a perk.

Regulated contexts vary

Rules that affect AI use differ by country, by sector and by contract. Data protection, employment, financial services, healthcare, legal services and public sector work can all carry specific obligations, and those obligations are changing in many places.

Do not assume that something you read about another jurisdiction applies to you, or that it does not. The right move is to ask your legal, compliance or data protection function a direct question: which of our current or planned AI uses fall under specific obligations where we operate, and what do those obligations require? If you do not have that expertise in-house, get qualified advice before you scale anything that touches personal data or regulated decisions.

Document the decisions

When you approve, limit or stop an AI use, write down what you decided, why, what risks you considered, and who owns it. A short entry is enough. Over time these entries become your AI register: a list of every significant use in the organisation, its owner, its data, and its review date.

The register does three things. It tells you what is actually running. It shows a regulator, auditor or board that decisions were made with care. And it gives you a place to notice when a small pilot has quietly become critical infrastructure.

Draft a short AI register entry from the details below.
Process: [what the process is and what the AI does in it]
Owner: [one named role]
Data involved: [categories of information]
Human check: [who reviews, at what point]
Where we operate: [countries or regions]
Sector: [your sector]
Fill in these fields: use, owner, data, human check, obligations, review date.
For obligations, do not state any law. Write TO CONFIRM WITH LEGAL and list
the questions I should ask our legal or compliance team.