Governance, Risk & Responsible Use: A Crash Course

Four questions. Three possible answers. One habit that keeps useful AI work safe enough to survive.

Start with an ordinary Tuesday

A logistics company has a good year with AI. Operations cuts reporting time. Marketing drafts campaigns faster. Finance automates routine matching. The tools become ordinary enough that people stop thinking of each use as an "AI decision."

Then a project manager uploads a customer spreadsheet containing names and account numbers into the AI chat she uses every day. She is not trying to break a rule. She is trying to answer a director's question before lunch.

The company freezes AI use while it investigates. Teams that did nothing wrong lose workflows they relied on, because one routine decision created a risk the organisation could not ignore. The scenario is a fictional composite, and it is the shape the real cases take: not a dramatic failure, but one ordinary decision that nobody framed as a decision.

That is the problem governance is meant to solve, and a policy document cannot solve it alone. A policy cannot look at the file on your screen. It cannot decide whether the task needs the customer names. It cannot notice that a new connector can now send messages as well as read them. Those decisions happen where the work happens, which means they are yours.

This course gives you a small decision procedure for them: quick enough that you will actually run it, and written down in a form a manager can review.

The whole course in 30 seconds

The 30-second version

Before AI does meaningful work, ask four questions:

1. The Case: Can AI do this work?
   Yes · Yes, with a defined human review · No
2. The Data: Can this information go in?
   Yes · Check first / add a control · Not through this route
3. The Capability: Can I turn this tool, Skill, connector, or action on?
   Enable · Escalate for review · Decline
4. The People: Could this affect someone unfairly or require disclosure?
   Decide and document · Disclose · Escalate the question

The middle answer is where most professional judgment lives, because it requires you to name a reviewer, control, approved route, disclosure, or escalation. By the end you will have run all four on one workflow you own and written the answers on a single page, the Governance Record.

When not to run this. "Meaningful work" means work that touches someone else's data, someone's money, or a decision about a person. Rewording your own email, summarising a public article, or drafting notes that nobody else will act on does not qualify. Run the questions on the work that does and skip them for the rest. A habit that costs ten minutes on every trivial task is dropped within a week, and then it protects nothing.

Pick a workflow now. Choose one real piece of work you own or influence, where AI already helps or soon will. Each of the four questions ends with a short Now do it block that fills in one part of a one-page record for that workflow, so by the time you reach Part 2 the page is mostly written. Anything marked Going deeper is optional on a first read. The Now do it blocks are not.

Practice safely

Do not paste confidential, personal, regulated, privileged, or otherwise restricted work material into an AI tool just to complete an exercise in this course. Use a fictional example, synthetic data, or an entry point your organisation has already approved for that data.

An AI assistant can help you apply a framework. It is not your policy owner, security reviewer, compliance function, legal adviser, or final authority on whether a particular data type or tool is approved.

---

📚 Teaching Aid

Open Full Slideshow

View Full Presentation for Governance, Risk & Responsible Use

---

Part 1: The four questions

1. The Case: Can AI do this work?

A support agent has a billing complaint in the queue. The customer says they were charged twice, and the agent wants AI to draft the reply from the account record. Should AI do this work? Make the call before you read on: yes, yes with a review, or no.

This question comes first because if AI should not be doing the work, the later questions about data and tools do not matter.

You do not need a complicated risk matrix for most everyday cases. Ask four questions. Governance material built on the AI Fluency Framework calls these the Delegation criteria, because they are the same screens you use to decide which parts of a workflow to hand over. Here they screen the whole use case rather than one step of it.

Screen	Plain-English question
Reversibility	If the output is wrong, can we catch and undo it before harm happens?
Consequence of error	What happens if it is wrong? Is the cost trivial, expensive, harmful, regulated, or irreversible?
Human judgment or empathy	Does the task depend on relationship, care, original judgment, or context a person should personally own?
Accountability	Who is answerable for the outcome, and can that person meaningfully review and own what the AI produced?

1.1 Choose one of three answers

Fully appropriate. The work is low consequence, reversible, and easy to review in the normal course of work. AI can do it without a special governance gate.

Examples: drafting an internal FAQ from approved source material, restructuring notes, creating first-pass meeting summaries, or generating alternative headings.

Appropriate with human review. AI is useful, but a specific human check is required before the output is used, sent, published, or acted on.

Examples: drafting customer replies about billing, preparing a management summary from financial data, or creating a shortlist that influences who receives attention next.

Inappropriate. The task should remain human-owned because the consequence, irreversibility, or human responsibility cannot be repaired by review.

Examples include making a final medical, legal, disciplinary, or other professional determination where a qualified person must make and own the judgment. AI may sometimes support the work, but it should not become the final decision-maker simply because it is capable of producing an answer.

1.2 Find the deciding factor

Professionals often use formal language such as load-bearing criterion. In plain English, this means the deciding factor.

Ask:

If one of the four answers changed, which change would move this use case into a different classification?

That is the factor carrying the decision.

For a condolence message, the decisive factor may be the human relationship even though the message is easy to rewrite. For a customer billing reply, accountability may be decisive because the company remains responsible for what it tells the customer about their money.

Naming the deciding factor improves the quality of the discussion. Instead of "this feels risky," you can say:

"This is appropriate with review because the organisation remains accountable for the factual claim."

That sentence can be checked, challenged, and improved.

1.3 A human in the loop is not a gate

The phrase "a human will review it" sounds responsible and often means nothing in practice.

A defined gate has three parts:

• Who reviews: the role that actually holds the responsibility
• What they verify: the specific risk the review is meant to catch
• When they review: before the output becomes hard to undo.

Compare:

"Someone will check it."

with:

"The account manager checks delivery facts against the dispatch record before the report is sent to the customer."

The second statement is a control. The first is an intention. If you cannot write the gate in that form, the workflow is not ready to run.

Going deeper: consequence and accountability are different

A high-consequence task is not automatically prohibited. Sometimes a well-designed gate restores sufficient control. Conversely, a low-consequence task can still require a human because the human relationship is the point of the task.

Do not score the four criteria mechanically and add them up. Use them to expose the reason the case belongs in one category rather than another.

Also remember: accountability cannot transfer to a tool. Delegating a task does not delegate accountability. A manager, clinician, lawyer, employer, or company does not become less responsible because an AI system drafted part of the work.

Worked examples

Use case	Classification	Why	Gate, if needed
Turn approved policy documents into an internal FAQ draft	Appropriate	Reversible, low consequence, authoritative sources exist	Normal editorial review
Draft a customer response to a billing complaint	Appropriate with review	Company remains accountable for facts about the customer's account	Support agent verifies account facts and tone before sending
Generate a final professional determination	Inappropriate as the final decision-maker	Professional accountability and consequence cannot be transferred to the tool	Human professional makes and owns the determination
Summarise candidate applications to help organise reading	Appropriate with strong review and policy checks	Consequential to applicants and sensitive to unfair filtering	Hiring owner reviews inclusion and exclusion decisions before action

If you said "yes, with a review" for the billing reply, you made the call the table makes. If you said plain "yes," notice what moves it to the middle: the company is accountable for what it tells a customer about their money, and the agent's check is the gate.

Now do it: Block 1 of your record

For the workflow you picked, write in your own words:

• what AI does, and what the human still does
• the classification: appropriate, appropriate with review, or inappropriate
• the deciding factor
• the gate, as who checks what, and when.

You may ask an AI assistant to challenge your reasoning. Do not ask it to approve the workflow.

Here is a workflow I am thinking of handing to AI: [describe it, using a fictional or already-approved example].

Push back on my reasoning. Screen it on reversibility, consequence of error, how much human judgment it needs, and who stays accountable. Tell me whether it looks fully appropriate, appropriate with a human review, or inappropriate, and say which single factor is actually deciding that.

If it needs review, write the gate as who checks what, and when. Do not tell me the workflow is approved or compliant, and list anything you would need me to confirm with my organisation.

---

2. The Data: Can this information go in?

A project manager has a spreadsheet of customer names and account numbers and wants AI to find spending trends across the customer base. Company policy restricts sharing regulated personal data. Upload it as it is, strip the identifiers first, upload it with an instruction not to retain it, or skip the analysis? Decide before you read on.

A perfectly reasonable AI task can still be run on data that should not be placed in that tool or route.

Use this order:

Classify the data → ask whether the task needs the identifying details → confirm the route → choose the control.

Do not start with a privacy feature and work backwards.

2.1 Use three practical tiers

Your organisation may use different labels. Translate these to your policy rather than replacing it.

Green: generally permitted. Public material, genuinely anonymised or aggregated data, and internal material approved for broad use in the relevant AI environment.

Yellow: check first or add a control. Internal-only documents, personal contact information, customer or employee identifiers, confidential drafts, unannounced deal or product information, or other material whose use depends on the approved route and configuration.

Red: do not use through an unapproved route. Credentials, secrets, highly regulated or specially protected data, privileged material, or third-party confidential information you are not authorised to disclose. Licensed or copyrighted material held under terms that forbid copying it into another system belongs here too, whatever its sensitivity.

If you are unsure between two tiers, use the more sensitive one until somebody authorised to interpret the policy confirms otherwise.

2.2 Ask the most useful data question

Before deciding a sensitive task is impossible, ask:

Does the task actually need the identifiers, or only the pattern?

This is the key branching question.

If you are analysing spending trends, the model may not need customer names. If you are reconciling a particular account, the identifier may be essential.

2.3 Redaction is useful, but it is not magic

When the task does not need the sensitive fields, remove them before the data reaches the model.

Redaction fails in two common ways.

Failure 1, partial redaction: you removed the obvious identifier but left enough clues to identify the person. A rare job title, exact date, region, age, or combination of ordinary facts can identify somebody as reliably as a name.

Failure 2, redaction that breaks the task: you removed information the task actually needs. The result is safe-looking but useless. If individual account identifiers are necessary to reconcile transactions, redaction is not the control for that task.

Replacing names with "Customer 17" is a first move, not a verdict. After it, ask one question: does anyone still hold the list that maps Customer 17 back to a real person? If yes, the data is pseudonymised. It keeps its tier, and it must not be stored, reused, or shared as if it were anonymous. If the list is gone, no mapping travels with the file, and the task only needed the pattern, the analysis is no longer touching the protected fields and the restriction on them no longer applies. That second case is the ordinary one. Anonymised means the data meets your organisation's standard for no longer being traceable to a person, and it is that standard, not the relabelling, that lets the tier drop.

2.4 The route matters as much as the tool name

An entry point is the specific route by which material reaches an AI system: a normal chat, a project/workspace, an incognito or temporary conversation, a file upload, a connector, an API, a desktop agent, or another interface.

Different routes can have different retention, access, logging, and admin properties, different contractual terms, and different answers to whether the provider may use what you enter to train its models.

So the useful question is not:

"Is this AI product approved?"

It is:

"Is this route approved for this data and this purpose?"

For sensitive or regulated data, that approval should come from the relevant administrator, policy owner, security function, compliance team, or contract. It does not come from a guess at the keyboard.

The word purpose in that question does real work. Data arrives with the reason it was collected attached. A gym holds members' phone numbers to send class reminders. Using the same numbers to sell supplements is a different purpose, and the objection is not about the phone numbers, it is about the promise made when they were collected. Before you run customer, employee, or applicant data through a new AI workflow, ask whether the purpose it was collected for covers this use. If it does not, that is a question for whoever owns the data, not a reason to proceed quietly.

2.5 Privacy and workspace controls answer narrower questions

Features such as temporary conversations, memory controls, retention settings, sandboxed execution, encryption, projects, or organisation-managed workspaces can reduce particular risks. They do not answer the earlier authorisation question by themselves.

Think of controls this way:

Control	What it may help with	What it does not decide
Temporary/incognito conversation	History or memory persistence	Whether the data was permitted to enter the system
Memory controls	Cross-session reuse of information	Whether the original upload was allowed or how long all underlying data is retained
Code-execution sandbox	Limiting where code or file-processing can operate	Whether the data was authorised for that environment
Project/workspace	Keeping shared knowledge, instructions, files, and related work together	Whether every file or data type is approved for that workspace
Organisation-managed account and admin controls	Roles, feature controls, retention, exports, audit, or compliance options depending on the plan and configuration, including who can disable memory org-wide (see 2.6)	Blanket approval for every workflow, data type, or audience

In plain English: sandboxing and authorisation are different

A sandbox is an execution boundary, not an approval boundary. It can reduce what code or file-processing can reach outside an isolated environment, but the information still entered a system and outputs can still leave it. Ask separately whether the data is allowed in that route and whether the resulting files or actions are allowed out.

2.6 Claude routes and controls: five distinctions

Claude-specific example, checked September 2, 2026

Use these as routing distinctions, not as a substitute for your organisation's policy or contract.

• Memory is not retention, and the off switch is plan-dependent. Memory affects what Claude can carry forward across work. Chats and memory-related data still follow the applicable retention and export controls. Who can switch memory off for everyone also depends on the plan. Team plans do not have organisation-level controls for memory features. On Enterprise, Owners and Primary Owners hold the org-wide memory controls, including disabling memory for the whole organisation. If a governance decision depends on memory being off, confirm which plan you are on and who holds that setting.
• Incognito is not zero retention. Incognito chats do not appear in normal chat history or memory, but Anthropic currently documents a 30-day default retention period, with longer custom retention possible on Enterprise. Incognito is currently available only outside Projects.
• Training use depends on the plan. On Free, Pro, and Max, whether your chats may be used to improve Claude's models is a choice you make in your privacy settings, and allowing it extends retention of those chats to five years. On Team, Enterprise, and the API, inputs and outputs are not used for training by default. Incognito chats are not used for training on any plan. If a governance decision depends on inputs never training a model, confirm the plan the route runs on and the setting, rather than assuming.
• A sandbox is not data authorisation. Execution isolation can reduce the reach of code. It does not prove that a sensitive file was allowed into that environment.
• Private in the interface does not mean absent from organisational records. Team/Enterprise provide organisational data-export mechanisms, and Enterprise adds additional compliance and audit mechanisms. Treat administrative visibility and exportability as part of the route assessment.

Product behaviour changes quickly. If a decision depends on one of these features, verify current Anthropic documentation and your organisation's configuration.

Worked examples

Meeting notes with no confidential material. Usually green or ordinary internal use, subject to your company's approved AI environment.

Anonymised survey responses for trend analysis. Green once the identifiers are genuinely gone. If the output includes counts, percentages, or totals that somebody will act on, have them computed in the code execution sandbox rather than generated as prose. A number a decision rests on should be calculated, not written.

Internal sales pipeline with customer names. Usually yellow. Ask whether names are needed. If not, remove them. If yes, confirm the approved route.

Credentials or API secrets. Red. Do not paste them into an ordinary AI conversation. Use your organisation's approved secret-handling mechanism.

Patient, financial, privileged, or other specially protected records. Treat as red until your organisation has explicitly approved the specific route and use case. Do not infer permission from the fact that the AI product has an enterprise plan or security page.

The spreadsheet from the top of this question: spending trends need the pattern, not the people. Strip the identifiers, check that no mapping travels with the file, and run the analysis. Uploading it as it is breaks policy. Skipping the analysis protects nobody. And an instruction to the model not to retain the data is a wish, not a control.

Now do it: Block 2 of your record

For your workflow, record:

• what data enters
• its tier under your organisation's policy
• whether the task needs the identifiers at all, and which fields you can remove
• the approved route if sensitive fields remain, and whether the purpose the data was collected for covers this use.

For redaction practice, use synthetic data shaped like the real material. Do not paste a partially redacted sensitive document into an unapproved chat to ask whether the redaction was good enough.

---

3. The Capability: Can I turn this on?

A colleague sends you a Skill they found on a public forum. It turns meeting notes into summaries, it has worked well for them, and nothing in its bundled instructions limits it to meeting notes. Enable it, escalate it, or decline it? Decide before you read on.

AI systems increasingly do more than generate text. They can use Skills, tools, plugins, connectors, web pages, files, code, browsers, email, calendars, CRMs, and other services.

The question is no longer just "do I trust the model?" It is:

What authority am I adding to this session or agent?

3.1 Treat extensions like software, not like prompts

A Skill may contain instructions, scripts, resources, dependencies, or procedures. A connector may expose data or actions in another system. A plugin may combine both.

Do not judge these by the friendliness of the description or the fact that a colleague shared them.

One property of Skills matters more than any other, and it is the one people get wrong.

A Skill does not carry its own permission list. A connector has scopes that you grant and can narrow. A Skill has no such dial. It runs with whatever access the session it runs in already has, so its reach is everything that session can reach, not only what its stated task needs. Where a Skill's definition carries a list of tools, that list pre-approves them so they run without prompting you. It widens what happens silently. It does not narrow what the Skill can touch.

This is why the second check below asks what the Skill could reach, rather than what it is asking for. It is not asking for anything.

Run five checks:

1. Source: who created or published it?
2. Reach: what data, files, systems, tools, or credentials could it touch in the environment where it runs?
3. Fit, which some governance material calls appropriateness: is that reach proportionate to the job you actually need done?
4. Outside content: will it read web pages, incoming email, customer files, shared documents, or other content you did not author?
5. Actions: can it send, pay, delete, publish, edit, approve, or otherwise cause a hard-to-reverse change?

The first three tell you whether the capability belongs in the workflow. The last two tell you how dangerous a mistake or hostile instruction could become.

Before you can answer the second check, open the package. A Skill bundle can carry instructions, scripts, dependencies, and files, and reading them is the only way to know what it does rather than what its description claims. The red flag is scope creep. A formatting Skill whose instructions roam well beyond formatting is telling you something its summary line did not.

Internal does not mean vetted

The hardest source case is not the anonymous forum download. It is the Skill built by another team inside your own company, because "internal" feels vetted without being vetted.

The team that built it may have granted it broad reach for their own convenience, or built it against a policy that has since changed, or designed it for data less sensitive than yours. None of that is bad faith. It is context you do not share.

Treat it the way you would treat software from a sister department. Confirm with the publisher what it accesses and why, and check that its reach still matches current policy, before you enable it on your own data. The trust question was never about their intent. It is whether you know what it does and whether its reach matches your job.

3.2 Use three outcomes

Enable. You know the source, the reach is proportionate, the task fits, and the actions are controlled.

Escalate. The capability may be useful, but you cannot establish something important: the source is uncertain, the reach is broad, the tool wants unnecessary access, or the security implications are beyond your role.

Decline. The capability is clearly disproportionate, untrustworthy, or unnecessary for the job.

Escalating is not "asking permission to be careful." A good escalation names the exact unresolved question:

"This tool is useful, but it requests write access to our shared drive even though the workflow only requires reading. Can security review whether that access can be narrowed?"

That is far better than "Can I use this?"

3.3 Trusted tool, untrusted content

A capability can come from a trusted publisher and still read content written by somebody you do not trust.

An email, web page, customer upload, or shared document can contain instructions that attempt to steer the model. This family of attacks is commonly called prompt injection.

The key insight for non-specialists is simple:

Who wrote the tool and who wrote the content are two different trust questions.

The risk becomes much higher when an AI workflow both reads untrusted content and can take consequential actions.

For ordinary knowledge work, a useful default is:

• let AI read only what it needs
• prefer read-only access when it is enough
• keep send, publish, pay, delete, approve, or irreversible edits behind a defined human gate until the workflow has earned a higher level of autonomy.

For agent builders

At system level, "reach" becomes architecture: scoped credentials, tool allow-lists, typed actions, confirmation policies, network restrictions, isolation, audit logs, and clear separation between reading content and executing actions.

The governing principle is least privilege: give an agent the narrowest authority that lets it complete the job, then revisit that authority when the job changes.

Going deeper: scanning helps, but it is not approval

Security scanning can raise the floor by detecting some malicious Skills or plugins. It does not establish that the capability is appropriate for your data, environment, or intended use.

Anthropic's current Enterprise documentation, for example, describes skill/plugin scanning as a beta check for malicious content on certain new uploads/edits and explicitly notes that a pass is not a guarantee of safety in every respect.

Keep the source/reach/fit review even when a scanner passes the package.

Worked examples

Document-formatting Skill from a trusted publisher. Source is known, purpose matches the job, and it does not introduce unnecessary authority. Enable in an approved environment.

Third-party "analytics booster" with broad instructions and unknown source. Useful idea, unresolved trust and reach. Escalate with the specific concerns instead of experimenting on real company data.

Read-only connector to a reporting database. If the route is approved and the access is limited to the tables required, enable. Do not grant write access "just in case."

Agent that reads incoming email and can automatically send external replies. Outside content plus consequential action. Require stronger controls and a human gate unless the organisation has deliberately designed, tested, and approved a higher-autonomy workflow.

The forum Skill from the top of this question: the publisher is unknown, and the Skill will run with everything your session can reach, which is out of all proportion to summarising notes. A colleague's recommendation is warmth, not vetting. Escalate it with that specific concern, or decline it. Enabling it and watching for a week grants the access before the risk is understood.

Now do it: Block 3 of your record

For every Skill, connector, integration, browser, code tool, or action in your workflow, write:

• source, reach, and fit
• the outside content it reads
• the consequential actions it can take
• the outcome: enable, escalate, or decline.

If you ask an AI assistant to inspect a Skill or plugin package, ask it to find concerns. Do not ask it to certify the package as safe.

Read this package and tell me what it actually instructs the AI to do, including anything that goes beyond what it says it is for.

Point out any file, network, credential, tool, or external-service access you can see, and explain what would become risky if the session it runs in can reach sensitive data or take consequential actions.

Do not certify it as safe. Finish with one of three lines: obvious concerns found, no obvious concerns found in this review, or not enough information to say.

---

4. The People: Could this affect someone unfairly or require disclosure?

A hiring coordinator uses AI to screen incoming applications into a shortlist and forwards it to the hiring manager as "the candidates who qualified." The manager interviews only those people and never sees the ones the screen dropped. What is the concern here, and is it the first one you would have named? Decide before you read on.

The first three questions mostly protect the organisation and its information. This one makes you look outward.

Ask:

1. Who is affected, including people who never see the output?
2. What could go wrong for them?
3. Would they be able to notice or challenge it?
4. What would a fair process look like?
5. Is disclosure required, or would AI involvement reasonably matter to them?

Bias does not only arrive with the data. It can enter through the prompt, through the way the task was framed, or through the underlying patterns in how language gets generated. A request to rank "the strongest candidates" carries an unstated standard, and the output will inherit it. So the check is not only whether the facts are right. It is whether a framing has tilted the result and whether the output treats people fairly, and the risk of getting that wrong rises with the stakes for the individual.

4.1 Look at who was excluded

One of the easiest AI risks to miss occurs when the system narrows a set and humans inspect only the survivors.

Examples:

• candidate shortlists
• fraud or risk flags
• support tickets selected for escalation
• leads selected for attention
• documents selected as relevant
• people or cases ranked for priority.

If AI systematically removes a group, nobody notices if the review looks only at what remains.

A practical control is to sample exclusions as well as inclusions.

This is especially important in high-impact decisions involving employment, access, benefits, education, finance, health, or other significant opportunities. Your organisation may also have legal or policy restrictions on automated decision-making in these areas. The framework here does not replace them.

That is the shortlist from the top of this question. The concern is not that AI was involved, and not only that the applicants were never told, though that may matter too. It is that nobody is looking at who was removed.

4.2 Disclosure: use rules first, judgment second

Ask in this order.

First: is disclosure required? Check law, policy, contract, professional rules, client commitments, and organisational standards. If one of them requires disclosure, the decision is already made.

Second: if no rule answers it, would AI involvement reasonably change this person's understanding of the work or the relationship?

AI that reformats a table is different from AI that drafts what an employee will understand as a manager's personal assessment. Routine tooling does not always need a label. Consequential or relational work often deserves more transparency.

Two disclosure cases come up often enough to deserve their own lines.

Authorship. Work that goes out under your name, or your organisation's, is yours to stand behind however much of the drafting AI did. Your organisation may have a rule about labelling AI-assisted documents, and some professional bodies and publishers require it. Where no rule exists, the test is the one above: would the reader's understanding of the work change if they knew? A board paper, a reference letter, or a published article usually says yes. A tidied-up meeting agenda usually says no.

The notetaker in the meeting. An AI notetaker that joins a call touches all four questions at once. It is appropriate with a review of the summary before it circulates, because a summary that misattributes a commitment is a real error. The conversation may hold customer, employee, or deal information, so the recording and transcript take a route that needs the same check as any upload. The notetaker is a participant with reach to the whole conversation. And everyone in the room is affected, so announce it at the start. Some jurisdictions require every participant's consent to a recording, and a colleague who finds out afterwards will not experience it as routine tooling.

When no rule settles it and the case is an ordinary one, the default is to disclose rather than to conceal. Disclosure usually costs little, and concealment is what damages trust when it surfaces later. When the case is not ordinary, escalation is better than inventing a rule. The next section says what makes a case not ordinary.

4.3 Escalate the question, not a verdict

Structured reasoning handles most ambiguous cases on its own. Three signals mean it should not handle this one alone:

• the affected population is large
• the potential harm is significant
• the question touches an area your team does not have standing to resolve, such as law, contract, employment, or professional obligation.

Any one of them is enough. Escalating at that point is not timidity. It is routing the decision to whoever actually holds it.

Weak escalation:

"I think this is fine. Can you approve it?"

Strong escalation:

"Here is the workflow, who is affected, the control we added, and the point the framework does not settle: whether our disclosure obligation applies to this audience."

A strong escalation gives the reviewer something specific to decide.

Worked example: performance-review drafting

A manager wants AI to turn their own notes into draft performance-review summaries.

Case: appropriate with human review. The manager must own the assessment and verify every statement against the underlying notes.

Data: employee information is sensitive internal material. Use only an approved route and minimise unnecessary personal details.

Capability: ordinary drafting may need no new connector. If a system pulls data automatically from HR tools, access and scope require much stronger review.

People: employees are directly affected. The manager should check consistency across employees, not merely whether each individual paragraph sounds plausible. Disclosure obligations depend on policy, contract, and context.

The point is not that AI makes performance reviews automatically wrong. The point is that the workflow needs controls shaped around the way the output can affect people.

Now do it: Block 4 of your record

For your workflow, write:

• who is affected, including people who never see the output
• what harm or unfairness is plausible, and whether you review exclusions as well as inclusions
• what disclosure a rule requires, and what disclosure your own judgment adds
• what, if anything, needs escalation.

If the fairness question is the one you are least sure about, work it aloud:

Here is a workflow: [describe it, using a fictional or already-approved example].

Take me through four questions one at a time, and wait for my answer before you move on. Who is affected, including people who will never see the output? What could go wrong for them, and would they be able to tell? What would a fair outcome look like? What disclosure is required by a rule, and what would only be my own judgment?

Then tell me whether this is mine to decide and document, or something to escalate. If it should be escalated, draft it as a question with my reasoning attached, not as a request for approval. Do not tell me the workflow is compliant.

---

Part 2: Put the four questions together

5. One ordinary workflow, start to finish

Ayesha leads operations at a regional logistics company. Her team manually prepares a weekly service-exception report for large customers. She proposes using AI to draft the report from dispatch records, then having the account manager send it.

5.1 The Case

• Reversibility: high before sending. Low after sending.
• Consequence of error: meaningful because delivery failures may affect contracts and customer trust.
• Human element: moderate. The summary is mechanical, but tone matters on disputed accounts.
• Accountability: the company remains responsible for every factual claim.

Classification: appropriate with human review.

Deciding factor: accountability.

Gate: The account manager checks delivery facts against the dispatch record and reviews the tone on disputed accounts before the report is sent.

5.2 The Data

Inputs include customer names, shipment information, delivery windows, failure reasons, and some free-text operational notes.

This is at least yellow under the simple model because it is internal/customer data and contains identifiers.

Does the task need the identifiers? Yes: a customer report must identify the customer and shipments.

So the team does not solve the issue by stripping every identifier. It confirms that the specific workspace and integration route are approved for this information.

5.3 The Capability

The team wants a connector to the dispatch system.

• Source: internal platform team.
• Reach: only the reporting tables required.
• Fit: strong. It eliminates a manual export step.
• Outside content: some free-text fields contain text copied from customer communications.
• Actions: the workflow does not need permission to send the report.

Outcome: enable read-only access after scope confirmation. Keep sending with the account manager.

5.4 The People

Customers are affected, but so are drivers and operations staff described in failure notes.

A summary could accidentally turn "weather delay" into "driver failure," or apply harsher language to some teams than others.

Add a fairness/accuracy check: attribution must match the dispatch record, and the team should periodically compare phrasing across reports for consistency.

Disclosure: check contractual and organisational requirements first. If they are silent, AI drafting of a routine operational report may not require a special customer notice, but employee-facing consequences deserve separate consideration.

5.5 The Evidence

A control is stronger when you can tell whether it is working.

For the first quarter:

• Success measure: account managers complete the factual/tone check before sending
• Failure threshold: any material AI-generated factual error reaches a customer
• Monitor: Ayesha reviews a sample monthly
• Residual risk: a consistent wording bias across all reports could survive individual checks, so the sample review compares across customers as well as within each report.

One modest workflow has now produced a classification, a gate, a data route, a permission boundary, a fairness check, and a monitoring plan. That is governance as work design, not paperwork added after the fact.

---

6. The Governance Record: one page that survives the meeting

The four questions are useful in your head. They become organisationally useful when the answers are written down.

A Governance Record is a one-page record for one workflow. If you have been filling in the Now do it blocks, four of its five parts already exist for the workflow you picked.

The fifth part is the Evidence line, which Ayesha's team wrote in 5.5: a success measure, a failure threshold, who monitors and how often, and the residual risk that remains when every control works as designed. The footer names the owner, the date, and the re-check triggers: model, feature, data, audience, permission, policy, vendor term, or business consequence.

A blank field is better than a guessed one. If the owner or approved route is unknown, write OPEN QUESTION and route it to the right person. Section 10 has the whole record as one copyable block, and the two steps that finish it.

---

7. What to do when something goes wrong

Governance is not the promise that nobody will ever make a mistake. It is the ability to surface mistakes early enough to contain them.

Common incident types include:

• Data: information entered a route that was not approved for it
• Output: an AI-assisted output went out with a material error or harmful framing
• Action: an AI tool sent, changed, deleted, approved, or shared something it should not have
• Security: untrusted content steered an AI system or tool in an unintended way
• Fairness: a ranking, filtering, or screening process appears to have disadvantaged people and the issue was not caught by review.

The first-hour procedure

1. Stop the spread. Do not forward, repost, or create unnecessary new copies.
2. Record the facts. What happened, what data/output/action was involved, which route or system, when it happened, and whether anything went onward.
3. Report promptly through your organisation's incident path. For sensitive or regulated cases, timing may matter legally, so do not wait until you have a perfect explanation.
4. State the facts plainly. Avoid speculation and self-defence. The incident owner needs a reliable account.
5. Follow the incident owner's instructions. Do not independently decide questions such as deletion, notification, disclosure, or evidence preservation when they may have legal, contractual, security, or forensic consequences.

Do not quietly delete evidence and hope the issue disappears. Deleting your visible copy may not delete organisational or vendor records, and it can interfere with investigation or required preservation.

Report near misses too. A near miss reveals where the process is confusing or the approved route is too hard, without the cost of a full incident.

For managers

How the organisation treats the first person who reports a good-faith mistake determines whether the next ten mistakes are reported or hidden. Accountability matters, and so does creating a reporting path people can actually use.

---

Part 3: Make the habit survive real work

8. Why governance drifts

High-stakes decisions often receive attention because everybody knows they are important. Routine decisions are more dangerous to governance because each one feels too small to count.

A person uses a slightly easier tool. A human review becomes a glance. A connector keeps permission after the project changes. A sensitive field starts appearing in a dataset that used to contain none.

No single moment looks like a programme-level failure. The accumulated distance between the intended process and the actual process is the risk. That distance has a name worth using in a review: the Diligence gap. The name comes from Diligence in the AI Fluency Framework, the competency of taking responsibility for how AI is used and for what happens to its output, which at team scale means auditing what people actually do rather than assuming the policy is being followed.

8.1 Run a usage audit on the work people actually do

A lightweight team audit should answer:

• Which AI workflows are actually in use?
• What data is actually going through them?
• Did defined human gates really run?
• What new tools, Skills, connectors, or permissions were added?
• What changed in the model, feature, route, data, or audience?

Here is what one turns up. A team lead reviews a month of the team's AI use against policy and finds three gaps: a marketer uploaded an unreleased product spec to an entry point nobody had approved, a Skill was enabled without anyone checking its source, and a recurring client report skipped its required review gate twice under deadline pressure. None of it was malicious. All of it was drift. The fixes are habit-level: a reminder on approved entry points, a Skill-vetting step built into Project setup so it happens by default, and a review gate on client deliverables treated as non-negotiable. The audit converted invisible risk into three actions someone can close.

A reasonable starting point for many teams is a small quarterly sample, with more frequent review during a new rollout or after gaps are found. Do not turn this into a universal compliance requirement: frequency should match the risk, policy, and sector.

8.2 Audit the process, not the person

If a governance audit becomes a hidden performance review, people will show auditors only the cleanest work. The organisation then loses visibility into the behaviour it was trying to understand.

The purpose is to find system gaps: confusing rules, unnecessary friction, weak gates, stale permissions, or practices that evolved without review.

8.3 The friction rule

If the approved path takes ten steps and the unapproved path takes one, ordinary people under deadline pressure will discover the one-step route. The result has a name, shadow AI: work data flowing through tools and accounts the organisation never approved and cannot see.

That is not a reason to excuse policy violations. It is a reason to treat usability as part of the control system.

When you find repeated workarounds, ask:

"What makes the approved way harder than the unsafe way?"

Fixing that friction may produce more risk reduction than another reminder email.

8.4 When there is no AI policy

If your organisation has no AI policy, do not invent one and present it as official.

Instead, create an interim proposal for the appropriate owner to endorse. A useful one-page starting point can contain:

• approved AI products and specific routes for work data
• a short list of data types that require confirmation before use
• the human-gate rule for external or consequential outputs
• the review rule for new Skills, connectors, and high-authority tools
• one named role or channel for questions and incidents.

In regulated environments, that interim guide does not substitute for legal, compliance, security, privacy, or contractual approval.

8.5 Re-check when the workflow changes

Calendar reminders help, but change is the stronger trigger.

Re-check the Governance Record when any of these changes:

• model or model family
• AI product feature or retention behaviour
• connector, Skill, plugin, permission, or action
• data type or sensitivity
• source of outside content
• audience or population affected
• consequence of error
• law, policy, contract, or vendor terms.

"Approved last year" is not a reason to skip review if the thing that was approved is no longer the same thing.

---

Part 4: Use it tomorrow

9. The one-minute checklist

Before AI does meaningful work, run this:

Question	Quick check	Middle answer requires	The trap it catches
Case	Can AI do this task responsibly?	A defined human gate: who / what / when	"A human will review it" with no loop defined
Data	Can this information go through this route?	A control, data minimisation, or confirmed approved route	Treating privacy mode as permission, or abandoning work the pattern alone could do
Capability	Should this tool or authority be enabled?	A specific security/admin review question	Assuming an extension can only do what its description says
People	Could this affect people or require disclosure?	A fairness check, disclosure, or escalation	Reviewing only what AI selected, never what it excluded

Under all four sits the same trap: forcing the question into a plain yes or no. That produces recklessness and abandonment in equal measure.

Then ask one final question:

What changed since the last time we decided this was okay?

If nothing changed, continue. If something material changed, re-check the relevant block.

---

10. Finish the Governance Record

If you worked the four Now do it blocks, you have Blocks 1 to 4 for a workflow you own. Two steps remain, and then the whole record is below as one copyable block.

Step 5: The Evidence

Add:

• success measure
• failure threshold
• monitoring owner/cadence
• residual risk.

Step 6: Share the record

Send it to the person who owns the workflow, policy, or risk with a simple request:

"This is how I propose to run the workflow. Please correct any assumption about approval, data route, reviewer, or control."

The goal is not to collect signatures for every harmless task. It is to turn non-obvious assumptions into visible decisions before they become incidents.

Here is the whole record as one copyable block. Fill it in, delete nothing, and write OPEN QUESTION wherever you do not yet know the answer.

GOVERNANCE RECORD
Workflow:                        Owner:                    Date:

THE CASE
  Classification:      appropriate / appropriate with review / inappropriate
  Deciding factor:
  Gate: who               what they verify              when

THE DATA
  Tier:                green / yellow / red
  Does the task need the identifiers?     yes / no
  Fields removed:
  Approved route:

THE CAPABILITY
  Tools, Skills, connectors enabled:
  Source:                                  Reach:
  Outside content it reads:
  Actions it must not take without review:

THE PEOPLE
  Who is affected:
  Fairness check (including exclusions):
  Disclosure decision:                     Required by / judgment
  Open question or escalation:

THE EVIDENCE
  Success measure:
  Failure threshold:
  Monitored by:                            How often:
  Residual risk:

RE-CHECK IF: model, feature, data, audience, permission, policy,
vendor term, or business consequence changes.

---

11. Plain-English glossary

Delegation criteria. The four screens used to decide whether AI should do a piece of work: reversibility, consequence of error, human judgment or empathy, and accountability. Governance material built on the AI Fluency Framework groups them under Delegation, the competency of deciding how work divides between the human and the AI.

Appropriate with review. AI may do the task, but a specific human gate must run before the outcome is used.

Defined gate. A review that names who reviews, what they verify, and when in the workflow.

Deciding factor / load-bearing criterion. The factor that is actually carrying the classification. If it changed, the classification would likely change.

Accountability. Who remains answerable for the outcome. Accountability cannot transfer to a tool, so delegating the task does not delegate the answerability.

Diligence. In the AI Fluency Framework, the competency of taking responsibility for how AI is used and for what happens to its output. At team scale it means auditing what people actually do rather than assuming the policy is being followed.

Diligence gap. The distance between what the policy requires and what people actually do. This is where risk lives.

Data tier. A simple classification of how carefully information must be handled. This course uses green / yellow / red as a teaching model. Use your organisation's actual scheme in practice.

Entry point / route. The specific way data reaches an AI system, such as chat, project, connector, API, or file upload.

Purpose. The reason data was collected. A new use of the same data needs to be covered by that reason or by a fresh permission, whatever tier the data sits in.

Redaction. Removing fields the task does not need before the information reaches the AI system.

Pseudonymisation. Replacing direct identifiers with labels while a way to reconnect the data to people still exists.

Anonymisation. Transforming data so that it meets the relevant standard for no longer being identifiable. The exact test depends on jurisdiction, policy, and context.

The five checks. Source, reach, fit, outside content, and actions. The first three decide whether a capability belongs in the workflow. The last two decide how dangerous a mistake or a hostile instruction becomes. Some governance material calls fit appropriateness. It is the same question.

Prompt injection. Malicious or misleading instructions placed inside content an AI system reads, such as a web page, email, or document, in an attempt to steer its behaviour.

Least privilege. Giving a person, service, or agent only the access required for the task.

Shadow AI. Work data flowing through AI tools or accounts the organisation never approved and cannot see. Usually caused by the approved route being harder than the unapproved one.

Residual risk. What can still go wrong after the planned controls work as designed.

Governance Record. The one-page summary of the Case, Data, Capability, People, evidence, owner, and re-check triggers for a workflow.

---

12. What this course does not replace

This framework does not replace:

• applicable law or sector regulation
• your organisation's privacy, security, acceptable-use, records, HR, legal, procurement, or risk policies
• client contracts, confidentiality terms, or professional obligations
• formal security assessment of software or agent architecture
• structured model evaluation for high-impact systems
• legal advice about whether particular data is personal, anonymous, privileged, regulated, or permitted for a given AI provider.

It gives practitioners a way to recognise which question they are facing and arrive at the right owner with useful reasoning.

If your organisation runs a formal AI management system, it may be built on the NIST AI Risk Management Framework or on ISO/IEC 42001. These four questions are the practitioner's slice of that kind of system, not a substitute for it.

To keep the underlying judgment sharp, the capacity to notice when a fluent output is wrong, read How to Think in the AI Era. For the practical checklist on installing and scoping extensions, read Skills & Connectors, with one correction: its guidance on starting read-only and granting narrow scopes describes connectors, which have scopes. Skills do not, as Section 3.1 explains.

If you are collecting credentials, see Certifications for the exams this material prepares you for.

---

13. Where this leads in The AI Agent Factory

The four questions scale into the rest of the book:

• The Case becomes autonomy design and the human–agent operating model in Human–Agent Teams.
• The Data becomes custody, context, minimisation, and approved routes across agent systems, worked through in General Agents on the Web and Cowork.
• The Capability becomes tool boundaries, scoped credentials, confirmations, typed actions, and audit logs in Designing Agent Experiences and the Mode 2 material.
• The People becomes evaluation, disclosure, fairness checks, monitoring, and recourse, and eventually the governance layer of a System of Record.
• The Governance Record becomes a compact input to design review, testing, launch criteria, and ongoing monitoring.

If you have not yet read AI Fluency, read it alongside this course. AI Fluency helps you decide how to delegate work well. This course helps you decide how to make that delegation defensible and repeatable inside an organisation.

---

Appendix: Going deeper for managers and builders

Both sections are optional on a first read. They carry the four questions into the two places they have to survive next: a review meeting, and a system design.

A.1 For managers: evidence, residual risk, and review quality

This section is for managers, governance leads, and risk owners who need to defend the design later.

Add evidence to every important control. A control stated only as "the manager reviews it" is a belief until you can see that the review occurs and catches the intended problem. For meaningful workflows, write the four Evidence fields from Section 6: a success measure, a failure threshold, a monitoring owner and cadence, and the residual risk. Residual risk is not a confession that the design failed. Every real control leaves something outside its boundary, and naming it is what lets the right owner decide whether the remainder is acceptable.

Review quality matters more than review volume. A human gate does not make a workflow safe because a person clicked "approve." Good review has access to the source material, enough time, a specific risk to look for, authority to reject, and a position before the outcome becomes hard to reverse. If reviewers routinely approve everything, investigate whether the control is unnecessary, badly placed, or impossible to perform, not whether the reviewers need another reminder.

Sample the edge cases. Random samples are useful, but high-risk systems should also sample where failure is more likely or more expensive: unusual inputs, minority categories, escalations, low-confidence outputs, exclusions, and cases near thresholds. For AI systems that change over time, evaluation eventually moves into structured test sets, baselines, and monitoring, which the evaluation material of this book covers. The Governance Record is the bridge to it.

---

A.2 For agent builders: the four questions as architecture

The framework changes shape when AI acts through software rather than waiting for a person to copy and paste.

• The Case becomes an autonomy level. Not "can the agent do this" but "what level of autonomy has this task earned": draft only, propose an action for confirmation, act within a narrow reversible boundary, and act autonomously only where reliability, monitoring, and rollback justify it.
• The Data becomes custody and minimisation. Design what the agent may read, where it stores, what enters prompts and logs, how long it is retained, and which sensitive fields can be excluded before the agent sees them. Do not rely on users remembering to redact what the architecture can remove.
• The Capability becomes scoped authority. Narrow credentials, read-only where sufficient, explicit tool allow-lists, confirmation for consequential actions, audit trails, and separate identities for agents rather than shared human credentials.
• The People becomes evaluation and recourse. Fairness testing across relevant groups, review of exclusions and false negatives, meaningful disclosure where required, a way to appeal or reverse consequential outcomes, and monitoring after deployment.

The practitioner framework and the system architecture should tell the same story. If the Governance Record says "human approves before send" but the API token can send without confirmation, the architecture has already overruled the policy.

---

Sources and product notes

The screening approach builds on the AI Fluency Framework by Rick Dakan and Joseph Feller, particularly its ideas around Delegation and Diligence. The three-answer structure, deciding-factor test, route-first data reasoning, and Governance Record are adaptations for this book.

Product-specific behaviour changes faster than governance principles. Claude examples in this course were re-checked on September 2, 2026 against current Anthropic documentation. Before relying on a product feature for a real decision, verify the current source:

• Use incognito chats
• Is my data used for model training? (consumer plans)
• Is my data used for model training? (commercial products)
• Use Claude's chat search and memory
• What are Projects?
• How can I create and manage Projects?
• Roles and permissions
• Export your organisation's data
• Configure custom data retention controls for Enterprise plans
• Claude Cowork architecture overview
• What are skills?
• Use skills in Claude
• Agent Skills, Claude Platform Docs
• Get started with skill and plugin scanning

The treatment of anonymisation and regulated data is deliberately principle-based. Different jurisdictions and sectors use different legal tests. Remove information the task does not need, then check the remaining dataset and the intended route against the standard that actually governs your organisation.

---

Flashcards Study Aid

---

Test Your Understanding

The four questions read easily and run hard. These scenarios drop you into somebody else's decision with the pressure already applied. Twelve come up per sitting, drawn from a larger pool, so a second attempt is not the same paper.

Answer from the reasoning rather than the wording, and for each one, notice which of the four questions you are actually being asked. That identification is half the skill.

Checking access...

---

The sentence to remember

Classify before you act. If the answer is in the middle, name the commitment. Then write down why.