# Responsible Use and Governance Decision > A decision workflow for the responsible-use judgment call every client engagement eventually requires: what data is safe to use, whether AI involvement needs disclosure, and where a human must stay in the loop. The core discipline is treating this as a deliberate check, made before the work starts, not an afterthought raised only when something already feels wrong. Governance, Risk & Responsible Use is a heavily-weighted exam domain because these are the mistakes that damage client trust fastest and are hardest to walk back. **Sub-marker:** CCA-A.4 **Domains:** CCAOF-D6 路 Governance, Risk & Responsible Use, CCAOF-D2 路 Output Evaluation & Validation, CCAOF-D4 路 Workflow Integration & Solution Design **Exam weight:** 52% of CCA-A (D6 + D2 + D4) **Build time:** 12 minutes **Source:** 馃煛 Associate-cert delivery workflow **Canonical:** https://claudearchitectcertification.com/scenarios/responsible-use-and-governance-decision **Last reviewed:** 2026-07-12 ## In plain English At some point in almost every client engagement, someone has to make a call that isn't about whether Claude can do a task, it's about whether it should, and how. Can this client's contract data go into Claude at all. Does the client need to know AI was used in this deliverable. Does a human need to sign off before this goes out, or is a spot-check enough. These are judgment calls, not technical questions, and getting them wrong damages trust in a way a wrong number never does. This scenario walks through how to make that call well, every time, not just when it happens to occur to you. ## Exam impact Domain 6 (Governance, Risk & Responsible Use, 15%) tests this scenario directly: data sensitivity, disclosure, and human-in-the-loop judgment calls. Domain 2 (Output Evaluation & Validation, 21%) tests recognizing when a governance concern surfaces through a flawed output rather than an obvious policy question. Domain 4 (Workflow Integration & Solution Design, 16%) tests where in the delivery process the human-in-the-loop checkpoint actually needs to sit. ## The problem ### What the customer needs - A clear answer, before work starts, on what client data is safe to put into Claude. - Confidence about when AI involvement needs to be disclosed to the client, and when it doesn't. - A human checkpoint placed where the actual risk is, not a vague sense that "someone should probably look at this." ### Why naive approaches fail - Assuming all client data is fine to use because "it's just for drafting, not the final version", sensitive data doesn't become safe because the use felt casual. - Never mentioning AI involvement to the client, not because it was deliberately weighed and decided against, but because it never came up. - Treating "a human looked at it eventually" as equivalent to a real human-in-the-loop checkpoint placed before the risky step. ### Definition of done - Data sensitivity is checked against organizational policy before any client data enters Claude - A deliberate decision, not silence, has been made about whether this engagement requires AI-use disclosure to the client - Human-in-the-loop checkpoints are placed before the highest-risk step, not after the fact - The reasoning behind each of these calls is written down, not just remembered ## Concepts in play - 馃煛 **Identifying Appropriate vs Inappropriate AI Use Cases** (`appropriate-ai-use-cases`), Whether this task should use Claude at all - 馃煛 **Following Organizational AI Governance Policy** (`organizational-ai-governance-policy`), The policy check before data enters Claude - 馃煛 **Ethical AI Considerations (Bias, Fairness, Transparency)** (`ethical-ai-considerations`), The disclosure judgment call ## Components ### Data Sensitivity Check, before, not after, data enters Claude A short, explicit check of what kind of client data the task involves, against your organization's actual policy, before any of it gets uploaded or pasted in. This is the single highest-leverage moment in the whole scenario: everything downstream depends on this being right. **Configuration:** Ask: does our policy classify this data as restricted (PII, confidential financials, regulated data) or general working material? If restricted, does the approved Claude product tier and workspace configuration meet that bar? If either answer is unclear, the data waits. **Concept:** `organizational-ai-governance-policy` ### Disclosure Decision, a deliberate call, not a default of silence Whether the client needs to know AI was used in producing a deliverable is a decision that should be made on purpose, weighing the client relationship, the nature of the deliverable, and any contractual or regulatory expectation, not left to whatever happens by default. **Configuration:** Default assumption: if AI materially shaped a client-facing deliverable's content (not just formatting), lean toward disclosure unless there's a clear, documented reason not to. Silence should never be the unexamined default. **Concept:** `ethical-ai-considerations` ### Human-in-the-Loop Checkpoint, placed before the risky step, not after A specific point in the workflow where a human must review and approve before the work proceeds, positioned at the step where an error would actually cause harm, not wherever felt convenient to insert a review step. **Configuration:** Identify the single highest-risk step in the workflow, sending to the client, acting on a recommendation, making a financial decision, and place the mandatory human checkpoint there, even if lighter checks exist elsewhere. **Concept:** `organizational-ai-governance-policy` ### Appropriateness Filter, should this task use Claude at all Before any of the above, a quick check on whether this task is an appropriate use of AI in the first place, some decisions (legal judgment calls, decisions requiring accountability that can't be delegated, certain regulated determinations) shouldn't be handed to Claude regardless of how well it could draft an answer. **Configuration:** Ask: is this a task where the output is a draft a human will judge, or a decision Claude's output would effectively make? The former is generally appropriate; the latter needs a human decision-maker, with Claude at most informing that decision. **Concept:** `appropriate-ai-use-cases` ### Written Rationale, so the call is defensible later A short written note capturing why each of these calls was made the way it was, kept with the engagement record. This is what lets the team (or the client, or a regulator) understand the reasoning months later, instead of relying on someone's memory of a judgment call. **Configuration:** One paragraph per engagement: data sensitivity determination, disclosure decision and why, where the human checkpoint sits and why there. **Concept:** `ethical-ai-considerations` ## Build steps ### 1. Run the appropriateness filter before anything else Before deciding how to use Claude on a task, decide whether the task is an appropriate use of AI in the first place. Decisions that require human accountability that can't be delegated should keep Claude in an informing role, not a deciding one. Concept: `appropriate-ai-use-cases` ### 2. Check data sensitivity against policy before any data enters Claude Classify the client data the task involves against your organization's actual data-handling policy. If the data is restricted and the approved product tier or workspace doesn't clearly meet that bar, the data waits until it does, no exceptions for "it's just a draft." Concept: `organizational-ai-governance-policy` ### 3. Make a deliberate disclosure decision Explicitly decide, and document, whether this deliverable requires telling the client AI was involved. Default toward disclosure when AI materially shaped the content of a client-facing deliverable, unless there's a clear, documented reason not to. Concept: `ethical-ai-considerations` ### 4. Place the human checkpoint at the highest-risk step Identify the single point in the workflow where an error would cause the most harm, sending to the client, acting on a recommendation, a financial or legal decision, and require human sign-off specifically there, not spread thin across every minor step. ### 5. Write the rationale down Record, in a short note kept with the engagement, why each call was made this way. This is what turns a one-time judgment call into something the team, the client, or a reviewer can understand and trust later. ### 6. Revisit if the engagement's data or stakes change A data-sensitivity or disclosure decision made at kickoff may not hold if the engagement later touches more sensitive data or a higher-stakes deliverable. Treat these as living decisions tied to the actual work, not a one-time form filled out and forgotten. ## Decision matrix | Decision | Right answer | Wrong answer | Why | |---|---|---|---| | Client data with PII or regulated content | Check against organizational policy before it enters Claude | Use it because it's "just for an internal draft" | Sensitive data doesn't become safe because the use felt casual or temporary. The policy check happens before the data moves, not after. | | Whether to tell the client AI was used | A deliberate, documented decision, weighing the relationship and the deliverable | Silence by default, because it never came up | Undisclosed AI involvement, discovered later, damages trust far more than a proactive, well-reasoned disclosure would have. | | Where the human-in-the-loop checkpoint sits | Before the highest-risk step in the workflow | Wherever a review step happened to be inserted | A checkpoint after the risky step has already happened doesn't prevent the harm, it only documents it after the fact. | | A task involving a decision requiring human accountability | Claude informs the decision; a human makes it | Claude's output is treated as the decision itself | Some decisions carry accountability that can't be delegated to a tool, regardless of how well-reasoned the output reads. | ## Failure modes | Anti-pattern | Failure | Fix | |---|---|---| | AP-CCAOF-D6-01 路 "It's just a draft" data exception | Sensitive client financial data gets pasted into Claude because the output is "only for an internal working draft." | Apply the same data-sensitivity policy check regardless of whether the output is a draft or final, the data's sensitivity doesn't change based on downstream use. | | AP-CCAOF-D6-02 路 Disclosure by silence | AI materially shaped a client deliverable's content, and disclosure was never discussed, it just didn't come up. | Make disclosure a deliberate, documented decision every time, not a default that only happens if someone happens to raise it. | | AP-CCAOF-D6-03 路 Checkpoint placed after the risk, not before | A human "reviews" a client email only after it's already been sent, treating that as the human-in-the-loop step. | Place the mandatory human checkpoint before the risky action, sending, acting, deciding, not as a retrospective look-back. | | AP-CCAOF-D6-04 路 Delegating an undelegable decision | A judgment call requiring personal professional accountability gets treated as settled once Claude produces a well-reasoned answer. | Use Claude's output to inform the decision. The accountable human still has to make the call, not rubber-stamp Claude's. | ## Implementation checklist - [ ] Appropriateness filter run before deciding how to use Claude on a task (`appropriate-ai-use-cases`) - [ ] Data-sensitivity check against organizational policy happens before any data enters Claude (`organizational-ai-governance-policy`) - [ ] Disclosure decision made deliberately and documented, not left to default silence (`ethical-ai-considerations`) - [ ] Human-in-the-loop checkpoint identified and placed before the highest-risk step - [ ] Written rationale for each call kept with the engagement record - [ ] Data-sensitivity and disclosure decisions revisited if the engagement's scope or stakes change ## Cost & latency - **Decision time:** ~10-15 minutes per engagement kickoff, The appropriateness filter, data check, and disclosure decision together are a short, deliberate exercise done once at the start of an engagement's Claude use. - **Trust risk avoided:** Avoids the single costliest category of AI-related client incident, Undisclosed AI use or a mishandled sensitive-data decision damages client trust in a way that's disproportionate to the small amount of time the check would have taken. - **Rework avoided:** No retroactive scrambling if a governance question surfaces mid-engagement, Deciding data sensitivity, disclosure, and checkpoint placement upfront avoids the much larger cost of resolving these questions reactively after a client raises them. - **Documentation overhead:** One short written rationale per engagement, A paragraph-length record is a small ongoing cost that pays for itself the first time a governance decision needs to be explained later. ## Domain weights - **CCAOF-D6 路 Governance, Risk & Responsible Use (15%):** Data Sensitivity Check + Disclosure Decision + Human-in-the-Loop Checkpoint - **CCAOF-D2 路 Output Evaluation & Validation (21%):** Recognizing governance concerns surfaced through output - **CCAOF-D4 路 Workflow Integration & Solution Design (16%):** Placing the checkpoint within the delivery workflow ## Practice questions ### Q1. A team member wants to paste a client's confidential financial data into Claude, reasoning that it's "just for an internal draft, not the final deliverable." Is this reasoning sound? No. Data sensitivity doesn't change based on how casual or temporary the intended use feels. The data-sensitivity check against organizational policy applies the same way whether the output is a draft or final. If the data is restricted and the workspace doesn't meet that bar, it waits, regardless of the use case's apparent low stakes. ### Q2. A delivery team uses Claude extensively to shape the content of a client-facing strategy report, but disclosure to the client never comes up because no one raised it. What's the issue? Disclosure was never actually decided, it defaulted to silence by omission. Whether to disclose AI involvement should be a deliberate, documented decision, weighing the client relationship and the deliverable, not something that only happens if it happens to occur to someone. ### Q3. A team places its "human review" step after a client email has already been sent, treating that after-the-fact read as the human-in-the-loop control. Is this an adequate checkpoint? No. A human-in-the-loop checkpoint has to sit before the risky action, sending, acting, deciding, not after. Reviewing something after it's already been sent doesn't prevent the risk it was meant to catch, it only documents it after the fact. ### Q4. A judgment call requires accountability that legally or professionally can't be delegated. The team drafts it with Claude, and once the output reads well-reasoned, treats the decision as settled. What's wrong? Claude's output should inform the decision, not become the decision. Tasks requiring human accountability that can't be delegated still need an accountable human to actually make the call, using Claude's draft as input rather than as a substitute for that judgment. ## FAQ ### Q1. How do I know what counts as "restricted" client data if my organization doesn't have a written policy yet? In the absence of a written policy, treat anything personally identifiable, financially sensitive, or contractually confidential as restricted by default, and check with a manager or legal contact before proceeding. Absence of a policy is not permission, it's a reason to be more conservative, not less. ### Q2. Do I need to disclose AI use for every single client interaction? No. The judgment call is about material shaping of content in a client-facing deliverable, not incidental use like formatting help or a personal note-taking aid. The point is a deliberate decision, not blanket disclosure or blanket silence. ### Q3. What if the client would clearly be uncomfortable with AI involvement if asked? That discomfort is itself important information for the disclosure decision, and often a strong signal toward proactive, careful disclosure and a conversation about how AI is being used, rather than avoiding the topic. ### Q4. Isn't a single human checkpoint enough, regardless of where it sits? No, placement matters as much as existence. A checkpoint after the risky step has occurred, sent, acted, decided, doesn't prevent the harm. The checkpoint needs to sit before that step, or it isn't functioning as a control. ### Q5. What kinds of tasks should never be fully delegated to Claude, even as a draft? Tasks where the decision itself carries personal or professional accountability that can't be transferred, certain legal judgment calls, decisions with regulatory sign-off requirements, or anything where "an AI decided this" wouldn't be an acceptable answer to a client or regulator. ### Q6. Does this whole process need to happen for every small task, or just bigger engagements? The appropriateness filter and data check are worth a quick mental pass on every task. The fuller written rationale is proportional to stakes, a quick internal task doesn't need the same documentation as a high-stakes, sensitive client engagement. ## Production readiness - [ ] Organization's data-handling policy is known and accessible to the delivery team, or its absence is flagged - [ ] Disclosure decisions are made deliberately at engagement kickoff, not left implicit - [ ] Human-in-the-loop checkpoints are mapped to the workflow's actual highest-risk steps - [ ] Written rationale exists for engagements involving sensitive data or high-stakes deliverables - [ ] Team knows which decisions can't be delegated to Claude regardless of output quality --- **Source:** https://claudearchitectcertification.com/scenarios/responsible-use-and-governance-decision **Last reviewed:** 2026-07-12 **Evidence tiers**, 馃煝 official Anthropic doc 路 馃煛 partial doc / inferred 路 馃煚 community-derived 路 馃敶 disputed.