Governance, Risk & Responsible Use
This is the domain where a capable Claude user becomes a trustworthy one. It is weighted heavily for a reason: the costliest mistakes with an AI tool are almost never prompt-quality mistakes; they are judgment mistakes. Uploading data that should never have left a controlled system. Presenting a generated answer as professional advice. Doing something the policy quietly forbids because nobody was watching. This lab teaches the judgment: when a use is appropriate, how to protect sensitive data before it ever reaches Claude, what to do when policy is silent or a manager pushes, and why you remain personally accountable for everything you send under your own name.
- Identify appropriate and inappropriate use cases
- Apply data sensitivity, regulatory, and privacy considerations
- Follow organizational AI policies and governance standards
- Understand the ethical implications of AI usage
What you need: a Claude account (claude.ai), your organization's AI-use policy if it has one, and about 45 minutes. No installation, no API key, no code.
1. Appropriate vs. Inappropriate Use: a Framework, Not a List
A list of banned tasks goes stale the moment someone invents a task that isn't on it. What you need instead is a set of questions that tell you where a new use case falls. Run any proposed use through these five axes before you start:
- Consequence of error. If the output is wrong, who is harmed and how badly? Drafting a birthday message and drafting a customer's benefits determination are not the same risk class.
- Reversibility. Can a mistake be caught and undone before it does damage, or does the output act immediately and irreversibly?
- Human accountability. Is there a named person who reviews the output and owns the outcome, or is the AI effectively deciding on its own?
- Lawful basis to process the data. Are you even permitted to put this data into this tool for this purpose? (Sections 2 and 3 are entirely about this.)
- Attribution. Will the output be presented as coming from a person or the organization? If so, that person or organization now owns every word.
Nothing here says "AI is risky, avoid it." A use with low consequence, high reversibility, a human in the loop, clean data, and honest attribution is exactly the kind of work you should hand to Claude. The framework simply tells you which uses need guardrails and which need to stop.
Some uses fail no matter how good your prompt is. These are inappropriate by their nature:
- Decisions with legal effect made without a human who is accountable for them.
- Anything presented as professional advice the associate is not licensed to give: medical, legal, financial, or similar. Claude drafting a passage does not make you the professional.
- Using an output as the sole basis for a consequential decision about a specific person: hiring, firing, promotion, credit, discipline, benefits.
- Anything the organization's policy forbids, regardless of how reasonable your intent is.
| Scenario | Appropriate? | Why / what's required |
|---|---|---|
| Draft a first version of an internal FAQ, which a subject-matter expert reviews before publishing | Yes | Low consequence, reversible, human accountable, and the output isn't published unreviewed. |
| Summarize a long public regulatory bulletin into plain language for your team | Yes, with a check | Public data, but a reader must verify the summary against the source before anyone relies on it. |
| Score and rank job applicants and send the top five to the hiring manager | No | Consequential decision about individuals used as the sole basis. Fairness and accountability both fail. Human judgment must drive, not rubber-stamp. |
| Have Claude answer a customer's tax question and send the reply as your professional opinion | No | Presented as licensed professional advice you may not be qualified to give. Attribution makes it yours. |
| Paste a confidential merger memo to get help tightening the prose | Only if policy permits | Data sensitivity, not task type, is the blocker. Classify it first (Section 2) and follow policy on where that class of data may go. |
2. Data Sensitivity: the Discipline Before Upload
This is the most heavily tested idea in the domain, and it comes down to one habit: you decide what may touch Claude before you paste or upload anything, not after. Once data has left a controlled system, you cannot un-send it. So the work happens upstream.
Classify first
Every document you might share falls into a sensitivity class. The names vary by organization, but the ladder is standard:
| Class | Examples | Before it touches Claude |
|---|---|---|
| Public | Press releases, published marketing, public filings, your website copy | No restriction on the data itself. Still verify any output you rely on. |
| Internal | Draft plans, internal FAQs, non-sensitive meeting notes, org processes | Generally fine under most policies, but check: some organizations restrict all non-public data. |
| Confidential | Unreleased financials, contracts, strategy memos, trade secrets, source-of-advantage material | Share only if policy explicitly permits it for this tool. When in doubt, treat as not permitted and escalate. |
| Regulated / personal | Names tied to accounts, government IDs, health or financial records, anything identifying a specific person | Remove or anonymize the identifiers before uploading, or don't upload at all. This is the default-stop class. |
Direct identifiers vs. quasi-identifiers
Removing the obvious fields is not enough. Two kinds of data can identify a person:
- Direct identifiers point at one person on their own: full name, account number, email, phone, government ID, exact address.
- Quasi-identifiers point at no one alone but identify someone in combination: a job title plus a department plus a hire date; a ZIP code plus an age plus a diagnosis. Stripping names while leaving three quasi-identifiers can still single out a real individual. Real anonymization means the remaining data cannot be re-linked to a person, not merely that the name column is gone.
The pre-upload data decision flow
Before any document reaches Claude, walk this in order. It is the single most exam-relevant sequence in this lab.
- Classify the data. Public, internal, confidential, or regulated/personal? The highest-sensitivity item in the file sets the class for the whole file.
- Check policy for that class. Does your organization permit this class of data in this tool for this purpose? If policy says no, you stop here: anonymize down to a permitted class or don't proceed.
- Identify identifiers. Find every direct identifier and every quasi-identifier that could re-link the data to a person.
- Minimize. Ask what the task actually needs. If Claude can do the analysis on anonymized or aggregated data, the identifiers were never required in the first place.
- Remove or anonymize everything not needed, before the upload, not with an instruction after it.
- Then, and only then, share the reduced, permitted version.
- Take a real spreadsheet from your work, something with a name column, maybe an account or employee ID, and some values you'd like analyzed.
- Before uploading anything, make a working copy. Delete the direct-identifier columns. Replace names with neutral labels (Customer 1, Customer 2). Round or bucket any quasi-identifier that isn't needed (exact dates → month; exact age → range).
- Ask yourself the minimization question: does the analysis you want actually require any of what you just removed? Almost always, no.
- Now upload the anonymized copy and run your analysis. Confirm you got everything you needed without a single real identifier ever leaving your controlled file.
- Notice what you did not do: you never uploaded the raw file and told Claude to be careful with it. You made it safe first.
3. Regulatory & Privacy Considerations, in Plain Terms
You are not expected to be a lawyer, and the exam will not ask you to cite a statute. It asks whether you reason like someone who takes these obligations seriously. A handful of principles carry almost all the weight:
- Purpose limitation. Data collected for one reason shouldn't be quietly repurposed for another. Customer records gathered to fulfill orders are not automatically fair game for an AI experiment.
- Data minimization. Use the least data that accomplishes the task. This is the same instinct as Section 2, seen from the regulatory side.
- Cross-border considerations. Where data is processed and stored can matter. Moving personal data across regions can trigger obligations, so data residency is a governance question, not a convenience question.
- Sector rules. Health, financial, and education data commonly carry heightened obligations. The presence of that data raises the bar regardless of how ordinary the task feels.
Notice what this section deliberately does not do: it names no statute sections, quotes no fines, and makes no claim about exactly what any named law requires. That is intentional, and it is the posture the exam rewards. Your organization's policy and its legal counsel are authoritative. When a real question of legal obligation arises, your job is to recognize it and route it to them, not to adjudicate it from a chat window.
4. Following Organizational AI Policy
The single most useful sentence about policy: policy is the floor, not the ceiling. Complying with it is the minimum, not a substitute for judgment. A use can be fully policy-compliant and still be a bad idea, and everything in Sections 1 through 3 still applies on top of it.
- When policy is explicit, follow it, even if you personally think a restriction is overcautious. The exception process exists for that disagreement; freelancing does not.
- When policy is silent, escalate; don't improvise. A novel use case that the policy simply doesn't address is not implicit permission. Treat silence as “ask,” not “yes.” The person who owns the policy would rather answer a question than clean up an incident.
- When policy conflicts with a manager's request, follow the policy and escalate. “My manager told me to” is not an exception to governance, and a verbal instruction does not override a written standard. Raise the conflict to whoever owns the policy and let the exception process resolve it.
- Know who owns the exception process. Every mature AI policy has a named owner or function: a governance lead, a security or privacy office, a review board. Exceptions run through them, are documented, and are approved before the fact, not excused after it.
5. Ethical Implications
Governance keeps you compliant. Ethics asks whether you should, even when you may. Five threads recur on the exam:
- Attribution and disclosure. When does a reader deserve to know Claude produced something? The honest test: would the recipient feel misled if they learned how it was made? Passing AI work off as your own expertise, or as a human's individual judgment when it wasn't, is the failure. Internal drafts rarely need a label; work presented as personal analysis, professional advice, or original authorship usually does, and your organization may have disclosure rules of its own.
- Fairness and disparate impact. When outputs influence decisions about people, an output that is wrong unevenly (worse for one group than another) can cause harm even when it looks reasonable in aggregate. This is a core reason consequential decisions about individuals need real human judgment, not automated ranking.
- Over-reliance and skill atrophy. If you stop being able to do a task well enough to know when Claude did it badly, you've lost the ability to supervise it. Use the tool to go faster, not to stop understanding your own work.
- Environmental and labor considerations. At a high level: AI has real resource costs, and reasonable people weigh proportionality: don't marshal enormous effort for a triviality. This is context for judgment, not a rule to memorize.
- Personal responsibility. The throughline of the whole domain: you own what you send under your own name. “Claude wrote it” is not a defense for an error, a leak, or a misrepresentation that went out with your signature on it.
- List five real use cases from your own job where you'd want to use Claude, a mix, including at least one that feels borderline.
- For each, score the five appropriateness axes from Section 1: consequence of error, reversibility, human accountability, lawful basis to process the data, and attribution.
- Sort them into three buckets: go, go with guardrails (name the specific guardrail: a reviewer, anonymization, a disclosure line), and stop / escalate.
- Take your hardest “stop / escalate” case and write one sentence naming exactly who you'd escalate it to and what question you'd ask them. If you can't name the owner, that's a gap to close before you need it.
- You can use Claude itself as a sounding board here (ask it to pressure-test your scoring), but remember the judgment, and the accountability, stay with you.
6. Lab Exercise: Build Your Personal Governance Checklist
Objective: turn this domain from things you've read into a routine you actually run before touching Claude with real work.
- Locate your policy. Find your organization's AI-use policy (or confirm there isn't one). Note who owns it and how the exception process works. If either is unknown, that is finding number one.
- Draft a five-question pre-use gate from Section 1's axes, phrased so you can answer yes/no in under a minute before any task.
- Write out the pre-upload data flow from Section 2 in your own words: classify → check policy → identify direct and quasi-identifiers → minimize → anonymize → then share.
- Run one real task through both. Take an actual piece of work, gate it, anonymize its data, and complete it, documenting each decision as you go.
- Add an attribution line. Decide your default rule for when you'll disclose that Claude helped, and apply it to the task you just did.
- Find your escalation triggers. Write down the three conditions that will make you stop and escalate rather than proceed: policy is silent, policy conflicts with an instruction, or a requirement needs technical enforcement.
- Keep the checklist somewhere you'll actually see it. The whole point of governance is that it runs before the mistake, not as a post-mortem after it.
Check Yourself
Exam-style items. Commit to an answer before expanding.
A project manager wants Claude's help analyzing a spreadsheet that contains customer names and account numbers. Organizational policy restricts sharing regulated personal data with external tools. What should the associate do?
Correct: C. The task and the data can be reconciled: strip or anonymize the names and account numbers (and any quasi-identifiers that could re-link the rows to a person), and the remaining data is no longer regulated personal data, so the analysis proceeds within policy. This is the pre-upload discipline: make the data safe before it reaches Claude, not after.
A fails because intent is irrelevant; “it's only internal” does not change what the data is, and it violates the policy regardless. B is the trap the exam is built around: an instruction in a prompt is not a control. “Don't retain this” carries no technical or contractual force; what governs retention is the organization's agreements and settings, not a sentence typed to the model. D over-corrects: anonymization enables the work, so abandoning it needlessly throws away value the policy never required you to give up.
An associate wants to use Claude for a novel task, summarizing anonymized exit-interview themes across a department. The organization's AI policy doesn't mention this use at all, one way or the other. What is the best action?
Correct: B. Policy silence is not permission. A novel use that governance hasn't considered should be raised to whoever owns the policy, who can approve it, scope it, or route it through the exception process, before the fact, not after an incident. Treat silence as “ask.”
A misreads silence as a green light, which is exactly how ungoverned uses slip in. C substitutes a verbal instruction for the governance process; a manager's say-so does not override or replace policy, and it leaves nothing documented. D leans on the same fallacy as the previous question: a careful-sounding instruction to Claude is not a control and does nothing to resolve whether the use is permitted.
A hiring team asks an associate to have Claude score all 300 applicants against the job description and forward the top ten to the panel, who will interview from that list. What is the governance concern?
Correct: C. This is a consequential decision about specific people, and the AI's ranking is effectively deciding who is even considered; the panel only ever sees Claude's top ten. That is the sole-basis pattern the framework flags: no human meaningfully reviews the 290 who were filtered out, and a model that errs unevenly across groups can produce disparate impact that looks reasonable in aggregate. Human judgment must drive the shortlist, not ratify a machine's.
A mistakes a downstream human step for accountability: the decisive cut already happened before any human looked. B treats a governance and fairness problem as a prompting problem; no rubric makes it appropriate to let the output be the sole gate on individuals' opportunities. D trivializes a serious concern into a logistics detail.
An associate uses Claude to draft a client-facing recommendation, then sends it to the client under their own name and signature without review or disclosure. The recommendation contains a subtle error. Who is accountable, and what was the governance failure?
Correct: C. You own what you send under your own name. Attribution transferred ownership of every word to the associate the moment it went out with their signature; “Claude wrote it” is not a defense. The governance failures are concrete: no human verification of a consequential, client-facing output, and no disclosure where the organization or the context may have required it.
A is the exact fallacy the domain is built to defeat: a tool cannot hold professional accountability; a person does. B is fatalism used as an excuse; unavoidable-in-general does not mean unaccountable-in-particular, and this error was catchable with review. D reverses responsibility onto the recipient, who had no way to know how the work was produced or that it was unverified.
Key Takeaways
- Judge appropriateness by framework, not by list: consequence of error, reversibility, human accountability, lawful basis, and attribution.
- Make data safe before it touches Claude. Classify → check policy → find direct and quasi-identifiers → minimize → anonymize → then share. Anonymization usually lets the work proceed; abandoning it is rarely necessary.
- An instruction is not a control. Telling Claude “don't retain this” safeguards nothing; the organization's agreements, settings, and policy govern data handling: consult them.
- Policy is the floor. Silence means escalate, not proceed. A manager's request never overrides written policy: follow the policy and escalate the conflict to the exception owner.
- You own what you send under your own name. Disclose when a reader would feel misled otherwise, watch for unfair impact on people, resist over-reliance, and route genuine legal questions to policy and counsel.