Governance and accountability
Sooner or later, leadership, a regulator or a journalist asks three questions about every AI feature: what does it do, with which data, and who answers when it goes wrong. This lesson gives you the tools to answer in ten minutes: an AI inventory, risk tiers with the controls each one needs, the regulation basics engineers meet, an AI incident process, and the one-page governance pack leadership signs.
By the end you can
- Build an AI inventory that covers every AI feature, including vendor tools, with an owner, data, model version and review dates
- Assign risk tiers by use and attach the controls each tier requires
- Explain the basics of the EU AI Act, data protection rights around automated decisions, and when to involve legal
- Run an AI incident from detection to review, with a kill switch and preserved traces
- Write a one-page governance summary with a named owner for every feature
The everyday picture
Think about the food-safety file in a busy restaurant kitchen. It lists every supplier and every dish. It marks the risky ones, such as raw chicken and shellfish, and says what each needs: fridge temperatures written down twice a day, separate boards, cooking temperatures checked. It names who is responsible on each shift. It says what to do when a customer gets sick: stop serving the dish, keep a sample, write down what happened, call the inspector if the law says so.
The file exists because an inspector can walk in on any day and ask, and because when something goes wrong, nobody remembers details a week later. The kitchen doesn't keep the same file for a side salad as for oysters, and the head chef can't say "the suppliers are responsible". AI governance is that file for your AI features. You can't show what you didn't write down, and you can't hand accountability to a vendor.
The AI inventory: every feature, written down
An AI inventory is the base of everything else. You can't tier, monitor or answer questions about a feature nobody listed. When Mangrove first built its inventory, the AI platform team expected four entries and found seven:
| Feature | Who it affects | Personal data | Tier | Owner |
|---|---|---|---|---|
| App assistant (products, allergens, delivery) | Customers | Own orders, questions | Medium | Nadia |
| Ask Ops (store questions, drafted tasks) | Store staff, stock | Staff names in tasks | Medium | Imran |
| Demand forecast | Stores, stock | None | Medium | Tomás |
| Churn model and win-back coupons | Customers | Order history | Medium | Marketing lead |
| Product description drafts | Customers (after review) | None | Low | Catalogue lead |
| Review summariser (built by marketing in a no-code tool) | Head office | Reviewer names | Low | None at first |
| Vendor CV-screening feature that HR wanted to switch on | Job applicants | CVs | High | Head of HR |
The last two were found outside the AI team, which is normal. To find them, combine four sources: a code search for calls to model APIs, finance's list of AI-related subscriptions, a question in the vendor-buying checklist ("does this product use AI to make or suggest decisions?"), and a short form any team can fill in. Each entry then records:
- purpose, and what it must not be used for;
- users and the people affected (often different: applicants are affected by the CV tool but never use it);
- model and provider, with the pinned version, as in Evals that never stop;
- data used, and whether it is personal;
- risk tier, a named person as owner, eval status, the last red-team date (Guardrails and red-teaming) and the next review date.
Keep the inventory as structured data next to the code, not as a slide. Then a query can tell you which features are overdue for review, and the traces from Observability for LLM systems can carry the inventory id, so cost and quality roll up per entry.