Governance, Procurement and the Regulator

Everything so far has been code. This chapter is about the people who will ask whether the code exists, and it is the chapter most engineers skip.

Skip it and someone else answers for you, usually badly, usually by writing a policy that bans something useful and permits the thing that actually hurt you.

The good news is that the first seventeen chapters have produced the artifacts a governance process wants. The work here is mostly translation.

What you already have

Seven asks, seven artifacts, all of which exist because they were useful rather than because a form demanded them. That is the right order to build them in and it is worth saying so when someone proposes the reverse.

Shadow AI

Before governing your agent, find out how many you have.

The pattern is consistent across organisations: a sanctioned agent that went through review, and an unknown number of others built by teams who found the frameworks easy, connected them to real data, and never told anyone because it did not feel like a project.

Those second agents have no trifecta audit, no gate, standing credentials, and often a tool that reads a shared drive. They are also usually the most privileged, because they were built by people who had the access and skipped the part where somebody asks why.

An inventory is worth more than a policy here. Ask three questions across engineering: which systems call a model API, which of those can take an action rather than produce text, and what credentials those hold. That list is the actual scope of your problem, and it is reliably longer than anyone expects.

Policies that ban unsanctioned agents produce hidden agents. An easy sanctioned path with the gate already wired in produces fewer of them, because the sanctioned path is less work than building it yourself.

The regulator

For a US company the relevant question is usually whether you serve EU users, because the EU AI Act reaches you if you do.

The timeline moved in 2026 and the movement is worth getting right, since a great deal of published material is now wrong.

Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July 2026, published in the Official Journal on 24 July and entered into force on 27 July. It amends the AI Act and defers a substantial part of it.

• Article 50 transparency obligations applied from 2 August 2026. This date held. It is the one that most likely touches a customer-facing agent, and the obligation is essentially that people are told they are dealing with an AI system.
• High-risk obligations under Annex III moved to 2 December 2027. Product-embedded systems under Annex I moved to 2 August 2028.
• Prohibited practices have been enforceable since February 2025, and general-purpose model obligations since August 2025.

The practical consequence for most readers is narrow. If your agent talks to people, tell them it is an agent. If it makes decisions in a high-risk domain, you have until December 2027 and a genuine compliance project rather than a chapter.

This book gives no legal advice and this section is not it. Take the dates to your counsel and let them tell you which annex you are in.

The vendor questionnaire

When procurement asks you to assess an AI vendor, the standard questionnaires ask about model providers, training data and hallucination rates. Those are the wrong questions for an agent.

Six better ones, all of which come from this book:

1. What can the agent do, not what can it say? Enumerate the actions. If they cannot, they have not thought about it.
2. Which of those actions are irreversible, and what stands in front of them? The answer should not be a system prompt.
3. Where does its authority come from? A service account with standing credentials is a different risk from per-task capabilities derived from the user.
4. What untrusted content does it read? If it reads documents, web pages or tickets, it has leg two of chapter 3.
5. What can it reach outbound, and is that list configurable by us?
6. What will your logs tell us after an incident? Ask for a sample record. If it shows prompts and completions and nothing about permissions, chapter 17 will not be possible.

A vendor who answers these well has read the same evidence you have. A vendor who responds by describing their guardrail model has answered a different question, and chapter 4 explains why that answer is insufficient on its own.