Governance and oversight
Safety · topic safety/governance
Once agents work inside an organization, individual care is not enough. This topic covers the shared controls: a policy that says what is allowed, logs that make agent actions reviewable, awareness that a model update can change behavior overnight, a clear route for escalating when something goes wrong, the regulation that applies to AI use, and a method for assessing a use case's risk before it starts.
Concepts
- Policy
- A written statement of which AI tools may be used, with what data, for what tasks, and with what checks before results are relied on. A good policy is short, names owners and gives examples of allowed and disallowed use. Without one, every person invents their own rules and the organization's exposure is the sum of the most careless choices. glossary
- Logging and audit
- Recording what an agent was asked, what it did, which tools it called and what changed, so that a person can later reconstruct and judge its actions. Logs turn an opaque incident into a traceable one and make patterns visible across many sessions. Store them where the agent itself cannot edit them, and review a sample even when nothing has gone wrong. glossary
- Model change risk
- Providers update models, and a workflow that behaved well can behave differently after an update: a format changes, a refusal appears, a shortcut is taken. Because the model is outside your control, treat each change like a dependency upgrade: pin versions where possible, keep a test set that represents your tasks, and re-run it when the model changes. glossary
- Escalation
- The agreed route for raising an AI-related problem: a leaked document, an agent that took a wrong action, output that harmed someone. It names who to tell, how fast and what to preserve. People report faster when the route is known and blameless, and the organization learns from near-misses instead of only from disasters. glossary
- Regulation
- Law that applies to how an organization builds and uses AI, with the EU AI Act as the main example. It defines what counts as an AI system, sorts uses into risk tiers from prohibited to minimal, and puts different duties on the provider who builds a system and the deployer who uses it. Deployers owe transparency to the people affected and must make sure their staff have enough AI literacy for the tools they use. glossary
- Risk assessment
- A short, written method for judging an AI use case before it starts. Name the domains it touches, such as personal data, money, safety or reputation, then rate impact and likelihood on agreed scales and combine them into a level. A level above the agreed threshold needs extra controls or a decision, in writing, from someone with the authority to accept the risk. The record is what makes the decision reviewable later. glossary
Links
- Builds on: Agent risk
- Leads to: Guardrails and production
- Competencies drawing on it: Runs an agent in production with guardrails, Judges the risk of letting an agent act
Lessons
- Assessing the risk of a use case before it starts (tutorial)
- Introduction to the EU AI Act (explanation)
- Reading agent logs and rerunning after a model change (tutorial)
- Writing an AI policy a team can apply (tutorial)
Your reference
Each lesson above adds its takeaways and its example here once you finish it. Your reference lists every lesson you have finished.
Assessing the risk of a use case before it starts
Unlocks when you finish Assessing the risk of a use case before it starts.
Takeaways
- A risk assessment starts with the domains a use case touches (personal data, money, safety and reputation) and the people a mistake affects. That list sets the impact rating.
- Rate impact and likelihood on scales everyone agreed, multiply them into a level, and compare the level with the agreed threshold.
- Sort the work by how easily a mistake can be undone, and put that in the impact rating. Rate likelihood from the real volume of work and from how fast a mistake is noticed. A demo shows the tool can do the task, and says little about how often it fails.
- At or above the threshold, add a control that brings the level down, or get a written acceptance from the person who answers for the risk.
- The record is what makes the decision reviewable. It holds the domains, the ratings, the decision, the control and the name of who decided.
Example
Which proposals can't the team lead approve alone? · open in the lesson
Which proposals need extra controls or the risk owner's written acceptance before they start? The program prints one at or above threshold: line per proposal, in the order above, and a yes means the team lead can't approve that proposal alone. Type the three values, yes or no, separated by spaces.
Prints: yes no yes
Introduction to the EU AI Act
Unlocks when you finish Introduction to the EU AI Act.
Takeaways
- The Act applies to AI systems, which Article 3(1) defines by their ability to infer outputs from input. A tool that only executes rules a person wrote is outside it.
- Uses fall into tiers: prohibited practices (Article 5), high-risk systems (Article 6 with Annex I and Annex III), systems with a transparency duty (Article 50), and everything else, for which the Act doesn't set a specific duty.
- Providers build or brand a system and deployers use one. Changing a system's purpose into a high-risk use, or putting your name on it, makes you its provider (Article 25).
- A deployer of a high-risk system follows the instructions for use and assigns competent human oversight. It also keeps the logs for at least six months and reports incidents, and it tells the people affected (Article 26).
- Article 50 reaches everyday work through public-facing chatbots, generated media, deep fakes and public-interest text. Ordinary drafting has no Article 50 duty.
- The AI literacy duty of Article 4 has applied since February 2, 2025. High-risk duties start on December 2, 2027 and August 2, 2028, and dates have moved once, so check the review date on this page.
Example
This lesson has no runnable example or prompt block.
Reading agent logs and rerunning after a model change
Unlocks when you finish Reading agent logs and rerunning after a model change.
Takeaways
- A log records what the agent was asked, which tools it called and what it changed. Sorted into those three parts, it answers "what happened" when the agent's summary is wrong.
- A log shows what the agent did and which model version did it. It never shows why the model wrote a sentence, but the version narrows the question.
- Check that the log holds the text of what was sent. Some tools leave it out until someone turns it on.
- Keep the log where the agent can't edit it, and name one person who reads a weekly sample. A log nobody reads doesn't catch anything.
- Treat a new model version like an upgrade of any other part. Pin the version where you can, keep a task set of past tasks with agreed results, and rerun it before a new version goes live.
- A pinned version is retired with notice, so the rerun is needed later anyway. Read each row that differs against the agreed result.
Example
Which reply went against the request? · open in the lesson
One email got a sent reply although the request said to leave it as a draft for a person. Type its id as the log shows it.
Prints: E-202
Writing an AI policy a team can apply
Unlocks when you finish Writing an AI policy a team can apply.
Takeaways
- A policy line is useful when two team members reading it alone make the same call. "Use AI responsibly" leaves every team to decide for itself.
- One page with five headings is enough: allowed tasks, data, approvals, logging and escalation, with an owner and a review date at the top.
- Start every agent read-only. Each kind of write access is a separate grant, approved by the person who answers for that workflow when it goes wrong.
- An agent that connects through a person's account inherits that person's access. Give it an account with what the task needs.
- The escalation section names what stops the agent, who is told, how fast, what's kept and who restarts it. The first incident is the wrong time to find out.
- A model update is a change to a tool you depend on. Rerun last month's work before the agent goes back on live work.
Example
This lesson has no runnable example or prompt block.
Sources
AEC-10Guardrails and safety: why agent safety differs, defense layers, injection, human in the loop, Agent Engineer Course (course)AEC-11From prototype to production: eval-gated deploys, rollout, cost, Agent Engineer Course (course)Academy deploying-claude-enterprise-with-confidenceDeploying Claude Enterprise with confidence, Claude Academy (course)Academy building-effective-human-agent-teamsBuilding effective human-agent teams, Claude Academy (course)AI ActRegulation (EU) 2024/1689 (Artificial Intelligence Act), consolidated text of 27 July 2026, EUR-Lex (reference)AI Act OJRegulation (EU) 2024/1689 (Artificial Intelligence Act), as published in the Official Journal on 12 July 2024, with recitals, EUR-Lex (reference)EC AI ActAI Act, the regulatory framework for artificial intelligence, European Commission, Shaping Europe's digital future (reference)EC AI OfficeEuropean AI Office, European Commission, Shaping Europe's digital future (reference)