6.1 Appropriate vs. Inappropriate Use Cases

Every question in this domain sits on top of one fact: Anthropic's Usage Policy (AUP) sets the outer boundary of acceptable use of Claude, and it applies with heightened requirements for high-risk and agentic scenarios. It is the authoritative standard for what counts as appropriate use — not a pricing page, not a context-window doc, and never the model's own self-assessment of whether a request is fine. If you remember nothing else from this lesson, remember that the AUP is where "is this allowed at all" gets answered first.

But the AUP is only the outer boundary, not the whole fence. Inside it, organizations layer their own AI policy on top: which tools and plans are approved, which categories of data may be used at all, what review steps are required before output ships, and who to ask when something doesn't fit neatly into either list. An Associate operates inside both boundaries simultaneously — clearing the AUP does not automatically clear your employer's policy, and a generous internal policy can never override the AUP.

"Appropriate use" isn't a vague vibe — it has a fairly concrete shape. It's language and knowledge work with human review: drafting, summarizing, analysis, research, brainstorming, and general process support. Notice the common thread — a person is still reviewing before the output does anything consequential. That review step is doing a lot of quiet work in the definition; it's the difference between Claude assisting and Claude deciding.

Inappropriate or restricted use is the mirror image: anything that violates the AUP outright, breaches organizational policy, mishandles regulated data, or — this is the one people miss most — places unverified AI output directly into a high-stakes decision without a human checking it first. Notice that the last category doesn't require the AI to have done anything wrong. The output could be perfectly accurate. The violation is procedural: nobody verified it before it mattered.

Two specific rationalizations show up again and again, both in real workplaces and on the exam, and both are wrong for the same underlying reason: they treat the absence of an explicit "no" as a "yes."

The first is "it's just internal." Data or output that never leaves the building still has to follow data-governance rules — internal distribution is not the same thing as unregulated. A spreadsheet of customer account numbers doesn't stop being regulated data because it's only going to a colleague's inbox. The second is assuming that anything not explicitly forbidden is automatically fine. The AUP and organizational policy set affirmative boundaries of what's allowed, not a blacklist of what's banned — silence on a specific scenario is not the same as permission, and a genuinely novel case should be escalated (more on that in Lesson 6.3), not waved through by default.

• •"It's just internal" does NOT excuse bypassing data-governance rules — internal-only distribution is not the same as unregulated.
• •"It's not explicitly forbidden" does NOT mean it's automatically permitted — policy sets affirmative boundaries, not merely a blacklist.
• •Both rationalizations share a root cause: treating silence as a green light instead of as a reason to check.

The single most tested pattern in this task statement is what to do with a borderline case — a request that's plausibly valuable but bumps against a data or policy restriction. The exam habitually offers four shapes of answer: do the risky thing anyway, do a half-measure that sounds safe but isn't, abandon the task entirely, or find the actual compliant adjustment. The fourth option is almost always correct.

Take the canonical worked example: a PM wants to upload a spreadsheet of customer names and account numbers to analyze trends, but policy restricts regulated personal data. Uploading as-is fails the "it's just internal" trap. Uploading it while telling Claude "don't retain this" fails too — instructing a model not to retain data is not a policy control, because the control that matters is not exposing the regulated data in the first place, not a promise about what happens to it afterward. Abandoning the analysis entirely also fails, because it throws away value that a compliant path would have preserved. The correct move is to remove or anonymize the identifiers before uploading — the analysis proceeds, and the protected data is never exposed.

Everything so far in this lesson has been about a single request bumping against a data or policy restriction. There's a related but distinct skill tested here: classifying an entire use case — not "can I upload this file" but "should this whole workflow be handed to Claude at all." The tool for that job is the same one AI Fluency's Delegation competency uses to size up a single workflow step, just aimed at a bigger target: how reversible it is, what an error would cost, whether it needs a distinctly human touch, and who's accountable.

• •Reversibility — if something goes wrong, is there a window to catch and fix it before real damage is done?
• •Consequence of error — setting reversibility aside, what does a wrong output actually cost: money, time, someone's trust, someone's job?
• •Human creativity or empathy — is there a layer of judgment, relationship, or genuine care here that a model can't actually provide, regardless of how polished its output reads?
• •Accountability — is there a specific person who has to answer for how this turns out, and are they actually in a position to exercise that responsibility over something AI generated?

None of these four is a solo gatekeeper. Failing one doesn't automatically sink the use case, and passing all four doesn't automatically clear it either. Run all four, then ask a follow-up question: which ONE, if it changed, would actually move the classification? That's the load-bearing criterion, and naming it is what makes a classification defensible instead of a gut call. A low-stakes, fully reversible task can still need a human when the human-element criterion is the one doing the real work — a retirement send-off note can be resent or fixed at no real cost, which reads as low-risk on paper, but it's inherently about a relationship, and a machine-drafted sentiment nobody personalized reads as exactly that the moment it's noticed. Conversely, a high-stakes task can still clear the bar when the right gate hands accountability back to a person — a board-facing quarterly summary carries real consequences if it's wrong, but a named reviewer signing off before distribution turns an irreversible-feeling task into something gated and checkable.

Of the three classifications, "appropriate with human review" trips people up the most — the mistake isn't picking the wrong label, it's treating the label itself as the finished answer. Describing a use case as needing "human oversight" names a bucket; it does not build a safeguard. Until the safeguard is spelled out, the use case isn't actually ready to run, no matter how confident the label sounds. A properly built safeguard answers three questions concretely: WHO reviews — the specific accountable role, not whoever happens to be free; WHAT they check for — the exact failure the review exists to catch, not a vague "make sure it looks right"; and WHEN in the process the check happens — before the output goes anywhere, never after.

The same test applies just as cleanly outside HR scenarios. "Claude will draft the vendor payment approval and finance will sign off" sounds like a gate, but it still isn't one — which finance role, checking for what specifically, and at what point relative to the payment actually going out? Compare it to: "the accounts-payable lead verifies the vendor's bank details match the last confirmed invoice, before the payment batch is submitted." Same underlying task, but only the second version gives a reviewer something to actually audit after the fact. If you can't fill in WHO, WHAT, and WHEN without hand-waving, that's the signal the use case isn't ready to run yet — the fix isn't a stronger label, it's a more specific gate.

Apply this to the performance-rating scenario from the previous note, classified "appropriate with human review." The classification alone doesn't finish the job — the gate does: WHO is the employee's direct manager, not HR generally and not a peer; WHAT they verify is that the draft rating reflects the employee's full body of work rather than only what happened to be captured in project notes, and that it's a number the manager is willing to personally defend; WHEN is before the rating is entered into the HR system, not as a post-submission audit. Stated that way, the gate is auditable by anyone reviewing the process later. Stated as "a manager reviews it," it is not — and that gap is exactly what the exam tests: pick the right label, then, if the label is "appropriate with human review," state the gate in a form a reviewer could actually check.

Task Statement 6.1 questions describe a request and a restriction, then offer answer choices shaped like the four options above. The winning habit is the same one every time: identify what's actually restricted, then look for the option that adjusts the request to comply rather than the option that ignores, half-measures, or abandons.

• •✗ Assuming internal-only use is automatically safe, or that silence in policy means permission.
• •✗ Treating a downstream promise ("don't retain this") as if it were an upstream control.
• •✗ Abandoning a task that a compliant adjustment could have saved.
• •✓ Naming the actual restriction, then finding the adjustment (usually anonymization or minimization) that satisfies it without losing the task's value.