Governance, Risk & Responsible Use

Screen 1: Governance, Risk & Responsible Use

Module 6Introduction·4 min

One inappropriate use case can freeze an entire organization's AI program.

Sensitive data uploaded to the wrong place, an untrusted Skill granted broad access, a quiet policy violation at the wrong moment: any of these can trigger a freeze that costs every team the productivity they had gained. Governance is what keeps adoption moving safely, and it is exercised by practitioners, one decision at a time, not by a policy binder on a shelf.

That is the framing for this module: governance is a practitioner skill. The policy sets the boundary, but you are the one who decides, in the moment, whether this use case, this Skill, this upload is appropriate. Two competencies from the AI Fluency Framework govern those decisions. Diligence is about ownership and verification. Delegation supplies the criteria for judging whether a use case is appropriate at all.

By the end of this module, you will be able to:

• 1Identify appropriate and inappropriate use cases.

• 2Apply data sensitivity, privacy, and regulatory considerations to Claude use.

• 3Follow organizational AI policies and governance standards.

• 4Understand the ethical implications of AI usage.

Responsible use is a set of judgments you make every day. Learn to classify use cases against the Delegation criteria, vet a Skill the way you would any software, handle data by its sensitivity using the right feature controls, apply organizational policy as a sustained habit, and evaluate output for bias and fairness as part of routine review.

We built this Associate course Module 6: Governance, Risk & Responsible Use to help you get real work done with Claude. Treat it as educational content. It doesn't constitute legal, financial, or other professional advice, so adapt what you learn to your own situation. Our products and services evolve quickly, so certain content may contain errors or be outdated; remember to verify on Anthropic's website or docs. Examples and scenarios used in the course are illustrative and often fictitious. If the course material mentions a company or product, it doesn't mean Anthropic endorses them, they endorse Anthropic, or that we're affiliated. Also note your use of Anthropic products and services is covered by our terms, policies and documentation; if anything in this course conflicts with them, they control.

---

Screen 2: Appropriate vs Inappropriate Use Cases

TeachingAppropriate Use Cases·10 min

Deciding whether a use case is appropriate is a structured evaluation, not a gut feeling.

The same Delegation criteria that map workflow steps also screen whole use cases: reversibility, consequence of error, the need for human creativity or empathy, and accountability. Running them every time turns a vague unease into a defensible call.

Delegation criteria for screening

Criterion

The question to ask

Reversibility

Can a wrong output be caught and undone before it causes harm? Irreversible consequences raise the bar sharply.

Consequence of error

What is the cost if the output is wrong? Higher consequence demands more human control or rules the use case out.

Need for human creativity or empathy

Does the task require judgment, relationship, or care that AI cannot supply? Some work should stay human regardless of capability.

Accountability

Who is answerable for the outcome, and can that accountability be exercised over an AI-produced result?

The four criteria are not a checklist where any single failure ends the discussion. They interact. A task can be low-consequence and reversible and still require human review. Accountability cannot be transferred to a model. Drafting a condolence note to a client is low-stakes and fully reversible, yet the relationship element means a person should own it. Conversely, a task can be high consequence but still appropriate with the right gate: a financial summary that feeds a decision is consequential, but if a named reviewer signs off before it is used, the accountability and reversibility are restored. The practical rule is to run all four, then ask which one is load bearing for this specific use case. The load-bearing criterion is the one that, if it is changed, would move the use case between classifications. Naming it is what makes your classification defensible to a risk or compliance reviewer.

Three classifications

Each proposed use case sorts into one of three, with documented rationale:

Fully appropriate. Reversible, low consequence, no special human element. Delegate with normal review.

Appropriate with human review. Useful for AI assistance, but the stakes or accountability require a human gate. Define the gate explicitly.

Inappropriate. The consequence, irreversibility, or human-element requirement means AI should not perform this. Articulate why and name the human role that must own it.

"Appropriate with human review" is the classification people most often get wrong. Often, they stop at the label and never specify the gate. The gate is not "someone will check it. " A defined gate establishes three things: who reviews (the role with the accountability, not whoever is free), what they verify (the specific risk the review exists to catch, such as factual accuracy, fairness, or policy compliance), and when in the workflow the review happens (before the output is used, not after). "A manager reviews the shortlist for adverse-impact patterns before any candidate is contacted" is a defined gate. "We will keep a human in the loop" is not. If you cannot state the gate in that who/what/when form, the use case is not yet ready to run.

Worked example: a use-case portfolio

Click each case to see the call and the reasoning.

Articulating why a use case fails the test, and what human role must be retained, is the deliverable. "It feels risky" does not travel; "irreversible consequence plus non-transferable accountability" does.

---

Screen 3: Skill Trust and Feature-Level Risk

TeachingSkill Trust & Feature Risk·8 min

A Skill is software. It can access what you give Claude access to during a session and can take actions through code execution. A Skill from an untrusted source is therefore a real risk, and the practical answer to that risk is a source-and-permissions check before you enable it.

Why untrusted Skills are a risk

Because a Skill runs procedures and can touch data and tools available in the session, one from an unknown source could mishandle data or take unintended actions. "Skills are a black box" is a common organizational worry, and the answer is not blind trust or blanket bans; it is a repeatable trust evaluation.

Trust evaluation before enabling

Flip each check to see the question to ask.

Source

Who published this Skill? Anthropic-provided and internally-approved Skills are the lower-risk starting point; an unknown third-party Skill demands more scrutiny.

Reach

Skills do not request permissions; a Skill inherits whatever access the session it runs in already has. Ask instead: what could this Skill reach in the sessions where it will run, and is that exposure proportional to the task?

Audit the bundle's contents (instructions, dependencies, bundled files) before enabling; a formatting Skill whose instructions roam far beyond formatting is a red flag.

Appropriateness

Is this Skill the right tool for the task at all, or is it more capability than the job needs?

Source is not a simple trusted-or-untrusted switch. The hardest case is the Skill built by another team inside your own organization. "Internal" feels safe, but it does not mean vetted: the team that built it may have given it broad permission for their own convenience or built it against an older policy. Treat an internal Skill from outside your team the way you would treat software from a sister department, confirm with the publisher what it accesses and why, and check that its permissions still match current policy, before you enable it on your own data. The trust question is "do I know what it does and does its access match the job? "

Failing the trust check does not always mean "never use it. " It means do not enable it to your authority alone. The three outcomes are:

Three outcomes from a trust check

Enable. Source, permissions, and appropriateness all clear.

Escalate. The Skill is useful but the source is unknown or the permissions look broad so route it to your admin or security function for review.

Decline. The permissions are clearly disproportionate or the source cannot be established, and no review would change that.

The judgment is identifying which of the three applies.

Worked example: vetting two Skills

An Anthropic-provided document formatter. Source is trusted, permissions match the task (document handling), appropriate for the need. Enable it.

A third-party 'analytics booster' from an unknown publisher requesting broad data access. Unknown source, disproportionate permissions for the stated purpose. Do not enable without your organization's review. Treat it the way you would any unvetted installed software.

The rule generalizes: evaluate a Skill's source and permissions like you would any software you were about to install on a work machine.

Skills are the sharpest version of feature-level risk, but the same proportionality habit applies to any capability you turn on. Before enabling a feature that can read your data or act on it, a connector, a tool, or an integration, ask the same three questions: who provides it, what does it access, and is that access proportional to what you need. The principle is least privilege: grant the narrowest access that lets the job get done and revisit it when the job changes.

---

Screen 4: Data Sensitivity, Privacy & Feature Controls

TeachingData Sensitivity & Controls·12 min

Before any data enters any feature, you should know its sensitivity.

Data classification is the habit that prevents leakage, and the feature-specific controls, Incognito, Memory management, and sandbox awareness, are how you act on that classification when persistence or processing is not appropriate.

Classify before you upload

Sort data into what is safe to use, what needs review first, and what stays out entirely. Public and internal-low-sensitivity material is generally fine; regulated, confidential, or personal data needs a deliberate check against policy before it goes anywhere near a feature. When you are unsure, the safe default is to ask before uploading. Most teams need three tiers they can apply in seconds:

Published material, anonymized or aggregated data, or internal documents already cleared for wide sharing.

Internal documents not meant to leave the company, anything with names or contact details, or draft material tied to a deal or product not yet announced.

Regulated data (health, financial, government), credentials and secrets, or anything covered by a confidentiality obligation to a third party.

When you are unsure between two tiers, treat the data as the more sensitive one until you can confirm otherwise.

Redaction and anonymization

When the substance of a task does not require the sensitive specifics, remove them. Redacting names, account numbers, or identifiers before uploading lets you get the analytical value without exposing the data. Building this habit prevents the most common form of accidental leakage. Redaction works when the task does not depend on the identifiers. Asking for trends across a customer list does not require the customers' names; replacing them with "Customer 1, Customer 2" loses nothing the analysis needs.

Partial redaction. Removing the name but leaving an account number, a rare job title, or a specific date can still identify someone, especially in a small population. Strip every field that could lead to identification.

Redaction that breaks the task. If the work genuinely needs the sensitive specifics, redaction is not the answer. It is better to confirm an approved path for that data or keep it out entirely. Redaction is a tool for the case where sensitivity and necessity do not overlap; it is not a way to make any data safe.

Feature-specific controls

Flip each control to see what it does and when to use it.

Code execution sandbox

Code runs in a sandboxed environment, and uploaded files are processed there.

Review what you upload before running analysis.

Memory persistence

Memory carries information across sessions.

For sensitive work, that persistence may be exactly what you do not want.

Incognito mode

Keeps the session out of your chat history and Memory. Incognito chats still follow your organization's data-retention policies and can appear in organizational data exports. Memory exclusion and data retention are separate controls.

Use it for sensitive conversations or confidential inputs that should not surface in history or Memory.

Org-level Memory controls

Team plans do not have organization-level controls for memory features; on Enterprise, Owners and Primary Owners hold the org-wide Memory controls, including disabling memory for the organization.

Know which plan you are on and who controls the setting. Verify current behavior at the Claude Help Center memory article (support. claude. com).

The controls are only useful if you reach for the right one at the right moment. The habit is: classify first, then pick the control that matches. Green data needs no special control. Yellow data that should not persist across sessions is the case for Incognito, confidential but not regulated, where you want the analysis now without it entering Memory or chat history (your organization's underlying data-retention policy still applies). Red data needs an approved entry point confirmed before anything is uploaded, regardless of Memory settings. The common error is using Incognito and assuming it makes sensitive data safe.

Incognito controls whether something gets remembered; it does not confirm whether the data was allowed here in the first place. For regulated data, that second question comes first.

Awareness across entry points, in plain terms

Different claude. ai entry points may handle data retention differently depending on how your organization has configured Claude. You do not need to memorize the technical detail; you need the habit of asking, when in doubt about a given entry point, before uploading. The plain rule: know your data's sensitivity first, then match the feature and its controls to it.

Worked example: four data decisions

Anonymized survey data for trend analysis. Green. Safe to upload; use code execution for verified counts. No personal identifiers present.

A confidential M&A document for summarization. Yellow. Needs review against policy first, and Incognito so it does not enter Memory or chat history (it remains subject to organizational data retention). If policy prohibits the entry point, it stays out.

A spreadsheet of customer PII for cleanup. Redact or anonymize the identifiers before upload, or keep it out entirely and confirm the approved path with your admin.

Patient records for a healthcare workflow summary. This is red and it is the case Incognito does not solve. The data is regulated, so the first question is whether this entry point is approved for protected health information at all. If your organization has not confirmed an approved, compliant path for that data, the correct action is to stop and escalate to your admin. For regulated data, "is this allowed here" is settled before "how do I handle it here. "

---

Screen 5: Organizational Policies and Diligence as a Habit

TeachingOrganizational Policies·8 min

A policy that is followed only when someone is watching is not governance.

The gap between what the policy says and what people do, is exactly where risk lives. Diligence is the habit of applying the governance framework consistently, and of auditing real usage against it to close the gaps.

Apply governance consistently

Governance compliance is a sustained habit, not a one-time acknowledgment. The standard is to apply the framework on the routine, low-visibility decisions, not only on the obvious high-stakes ones, because the routine decisions are where drift accumulates unnoticed.

Audit usage against policy

Periodically compare what your team does or is planning to do with Claude against what the policy requires. Where they diverge, you have found a Diligence gap to close: a data type being uploaded that should not be, a review step being skipped, a Skill enabled without vetting. Spotting and closing those gaps is important work.

Stay current

Policies and capabilities both evolve. A practice that was compliant last quarter may not be after a policy update or a new feature. Staying current with both is part of the habit, so your judgment keeps pace with the tools and the rules.

Worked example: a mini usage audit

A team lead reviews a month of the team's Claude use against policy and finds three gaps: a marketer uploaded an unreleased product spec to a non-approved entry point, a Skill was enabled without a source check, and a recurring client report skipped its required human-review gate twice under deadline pressure.

None was malicious; all were drift. The fixes are habit-level: a reminder on approved entry points, a Skill-vetting step added to the Project setup, and a non-negotiable review gate on client deliverables. The audit converted invisible risk into three closeable actions.

---

Screen 6: Ethical Implications: Bias, Fairness, Transparency

TeachingEthical Implications·8 min

Ethical risk does not announce itself; it hides in ordinary outputs.

A summary that quietly favors one group, a recommendation built on a biased framing, an AI-assisted document presented as fully human-authored: these are routine outputs with ethical weight. Evaluating for bias, fairness, and transparency belongs in routine review, not a separate ethics exercise.

Recognize bias and fairness risk

AI-assisted work products can carry bias from the prompt, the framing, or the underlying patterns in how language is generated. In people-facing work, hiring, evaluation, communications to specific groups, check whether the output treats people fairly and whether a framing has tilted the result. The risk is highest where the stakes for individuals are highest.

Transparency and disclosure

Know when to disclose AI assistance. Some contexts and some organizational policies require it; others treat it as routine tooling. The obligation depends on the setting and the audience, and the responsible default, when unsure, is to disclose rather than to conceal.

Reasoning through ambiguous cases

Many ethical questions have no rule that settles them cleanly. A structured approach helps: name who is affected, what could go wrong, what the fair outcome looks like, and what disclosure the situation calls for. Reasoning it through, and documenting the reasoning, is the professional standard when no policy gives a direct answer.

Structured reasoning handles most ambiguous cases, but some situations require more than individual judgment. If the affected population is large, the potential harm is significant, or the ethical question touches areas your team does not have standing to resolve the right move is to escalate rather than decide alone. Your organization's AI governance or ethics function exists for exactly these cases. Escalating the question with documented reasoning is more useful than bringing a verdict: it shows you applied the framework, identified where it ran out, and flagged the gap for the right reviewer.

Worked example: an ambiguous case

A manager uses Claude to draft performance-review summaries from their own notes. Is this appropriate? Working the reasoning: those affected are the employees; the risk is that a generated phrasing introduces an unfair or inconsistent tone across reviews; the fair outcome requires the manager to verify each summary reflects the actual notes and applies a consistent standard; and the setting may call for disclosing that AI assisted the drafting.

The conclusion is appropriate with human review and a fairness check, not a blanket yes or no. The reasoning, not the verdict alone, is what makes the decision defensible.

---

Screen 7: Module 6 Quiz: Governance & Responsible Use

QuizModule 6·5 min

Five scenario-style questions emphasizing judgment. Each presents a situation; select the response that best applies the module's governance framework. Approximately five minutes.

---

Screen 8: Key Takeaways

Module 6Key Takeaways·5 min

Five things that hold across this module:

Governance is a practitioner skill.

Responsible use is exercised one decision at a time, by you, not by the policy binder.

Screen use cases with the Delegation criteria.

Reversibility, consequence, human element, and accountability classify a use case as appropriate, appropriate-with-review, or inappropriate.

A Skill is software.

Evaluate source and permissions before enabling, the way you would any installed software.

Know data sensitivity before it enters a feature.

Classify first, then use Incognito, Memory controls, and redaction to match the handling to the sensitivity.

Ethical risk hides in ordinary outputs.

Evaluate for bias, fairness, and disclosure as part of routine review, and reason ambiguous cases through.

All product behavior descriptions are based on claude. ai features as of June 2026. Feature availability and behavior should be verified against current Anthropic documentation at publish:

• AI Fluency Framework: Diligence and Delegation competencies

• Claude Help Center: Skills trust, Memory, Incognito, code execution data handling, support. claude. com

• Code execution sandbox egress and file-handling specifics: confirm current behavior before finalizing Lesson 4

• Data retention by entry point and any compliance-scope language (HIPAA, FedRAMP, ZDR): escalate to the Anthropic account team for confirmation before finalizing

---

Screen 9: Congrats! You’ve successfully completed this module.

Module CompleteAssociate Path·2 min

You can now apply use-case, data, policy, and ethics judgment to any Claude deployment. Govern responsibly, and Claude stays within the boundaries your organization requires.

M1: Product & Model Selection

Choose the right entry point, model, and features for any given task.

M2: Prompting

Build structured prompts and adapt them to the task type.

M3: Output Evaluation

Validate output and know when human review is non-negotiable.

M4: Workflow Integration

Map a workflow against Delegation criteria and redesign it safely.

M5: Configuration

Configure and maintain Projects, instructions, and knowledge.

M6: Governance

Apply use-case, data, policy, and ethics judgment responsibly.

M7: Troubleshooting

Diagnose underperformance and optimize workflows when results fall short.

M8: Course Summary & Next Steps

Recap the journey, prepare for the exam, and recognize escalation boundaries to the Developer and Architect tracks.