# Following Organizational AI Governance Policy > Following your organization's AI governance is an employee-level checklist run before acting: is this data class allowed here, is this use case approved, does this output need review before it ships, and - when any of that is unclear - who do you escalate to before proceeding. That policy layer is separate from Anthropic's own model-level safeguards; Anthropic's Responsible Scaling Policy governs how Anthropic scales its own models, not whether your specific use of Claude with specific data is compliant. Enterprise admin tooling also makes usage inside the sanctioned workspace reviewable after the fact, so working outside it, or sitting on a discovered gap instead of reporting it, is the actual risk, not a technicality. **Domain:** CCAOF-D6 · Governance, Risk & Responsible Use (15% of the exam) **Canonical:** https://claudearchitectcertification.com/concepts/organizational-ai-governance-policy **Last reviewed:** 2026-05-04 ## Quick stats - **Governance layers:** 2 (vendor + org) - **Exam domain:** CCAOF-D6 - **Domain weight:** 15% - **Employee pre-action checks:** 3 (data, use case, review) - **When unclear:** Escalate, don't decide alone ## What it is An Associate-level Claude user does not set AI policy, they operate inside one their employer already has, or should have: rules on what data can be pasted into Claude, which use cases are approved, who reviews AI-assisted work before it ships, and how usage gets audited afterward. Governance, at this level, is two layered things stacked on top of each other. The first is Anthropic's own vendor-level safety framework, how Anthropic itself scales and safeguards its models. The second is the organization's own admin controls and internal policy, layered on top when a company deploys Claude to its employees. The two layers answer different questions. Anthropic's layer answers whether a model is safe to keep scaling; it does not answer whether a specific employee's use of a specific customer's data, inside a specific company's Claude deployment, satisfies that company's own data-handling rules. That second question belongs to the organization, and the associate's job is to follow the answer, not assume the vendor layer already covers it. Once a company enables audit tooling on its Claude deployment, usage inside the sanctioned workspace also becomes reviewable after the fact, which changes what "following policy" means in practice, from a trust exercise into something that can be checked. ## How it works What actually falls to the employee, day to day, is a short checklist, run before acting, not after. Before pasting data: is this data class (customer PII, financial records, unreleased material) allowed in this tool under company policy, and am I inside the company's sanctioned workspace rather than a personal account? Before adopting Claude for a new workflow: is this use case on the approved list, or does it need sign-off first, even if the task looks obviously low-risk? Before shipping AI-assisted output externally: does this specific output type require a human reviewer's sign-off, and has that review actually happened? None of this requires understanding admin tooling or vendor-level safety frameworks, it requires checking the answer against the org's own policy before proceeding, not after. When the answer isn't clear, escalate before proceeding, don't decide alone. "This use case seems fine to me" is not a substitute for approval, and guessing at a data-handling rule is not the same as confirming it. The standard escalation path is: check the written policy first, then raise it with the designated policy owner, AI governance lead, or compliance/legal contact your org names for exactly this - before running the task, not after. The same path applies in reverse: if you spot a gap (a use case running without approval, PII that reached an unsanctioned account, an AI-assisted output that shipped without required review), report it promptly through that same channel rather than quietly self-correcting and moving on; governance depends on gaps being surfaced, not smoothed over. This is layered underneath two things an employee doesn't operate, but should recognize as separate from their own responsibility. Anthropic's own Responsible Scaling Policy (RSP) governs how Anthropic itself trains and scales its models, it is vendor-level and says nothing about whether a specific employee's use of specific data satisfies the company's own rules. Separately, an org's admin/security team enforces its policy technically, not just in writing, through Enterprise-tier tooling (audit access to usage, spend controls, role-scoped admin access), which means work done inside the sanctioned workspace is reviewable after the fact even without any complaint being filed. Neither of these is something an employee configures, but both are reasons "no one will notice" is a bad assumption, and why escalating a concern yourself is safer than hoping it goes unnoticed. Most companies' internal policy structure echoes a recognizable pattern - NIST's AI Risk Management Framework (Govern, Map, Measure, Manage) - even if no one calls it that. Use-case approval is a Map step (classify the risk before deployment); required review before shipping is a Measure step; an escalation channel for gaps or mistakes is a Manage step. Recognizing the pattern explains why a policy asks for approval or review at all, rather than treating either as arbitrary friction, but an associate's job is following the steps, not designing the framework. ## Where you'll see it in production ### Marketing associate summarizing customer feedback Checks whether customer PII is allowed in Claude under company policy and routes the task through an approved Project or workspace instead of a personal account before pasting a complaints spreadsheet. ### Enterprise security team Reviews audit-accessible usage logs to confirm AI-assisted work followed the required human-review step before it shipped externally - work outside the sanctioned workspace is a visible gap, not a hidden one. ### Associate unsure about a new workflow Checks the written policy, doesn't find a clear answer, and escalates to the org's named AI governance/compliance contact before running the task rather than guessing based on how low-risk it looks. ## Decision tree 1. **Does the data you are about to paste into Claude include customer PII or other regulated data?** - **Yes:** Check whether your organization's policy allows this data class in this tool, or route the task through an approved Project or workspace instead of a personal account. - **No:** Proceed, but confirm the use case itself is approved before continuing. 2. **Is this use case on your organization's approved-use list?** - **Yes:** Proceed under the normal workflow. - **No:** Get sign-off before using Claude for it, even if the output looks harmless, an unapproved use case is a policy gap, not a technical one. 3. **Does the output need human review before it ships externally?** - **Yes:** Route it through the required reviewer before sharing, this is a governance control, not an optional quality step. - **No:** Ship it, but remember usage may still be audited afterward if Compliance API access is enabled on your org's deployment. 4. **Are you working inside the company's sanctioned Claude workspace rather than a personal account?** - **Yes:** Your usage is potentially auditable after the fact, working inside policy is both required and visible. - **No:** This is itself a policy violation in most organizations, independent of what you actually did with the tool. 5. **Are you genuinely unsure whether a data class, use case, or output is covered by policy, or did you discover a gap (unapproved use, misrouted data, a review step that got skipped)?** - **Yes:** Escalate to your org's designated policy owner or compliance/legal contact before proceeding (or immediately after discovering the gap) - don't decide unilaterally and don't quietly self-correct a discovered gap without reporting it. - **No:** Proceed under the checklist above; no escalation needed for a clear-cut case. ## Exam-pattern questions ### Q1. An employee argues that because Anthropic publishes a Responsible Scaling Policy, their company's use of Claude with customer financial records is automatically compliant with the company's own data-handling rules. Is this reasoning correct? No. The RSP governs how Anthropic scales and safeguards its own models, it says nothing about whether a specific company's use of a specific data set satisfies that company's own regulatory or data-handling obligations. The distractor "the RSP covers our compliance obligations too" conflates vendor-level model safety with org-level usage governance, two separate layers this objective tests separately. ### Q2. A sales associate wants to paste a spreadsheet of customer complaints into their personal Claude account to draft a summary for an exec deck. What should they check first? Whether an approved Project or workspace exists for this use case, and whether customer PII is allowed in it under company policy, not whether the output looks fine. The distractor "it is fine since Claude does not retain data by default" skips the actual question this objective tests: whether this org's policy permits this data class in this tool, regardless of any vendor-level retention default. ### Q3. An employee uses an unsanctioned personal Claude account for a work task instead of the company's sanctioned workspace, reasoning that if the output is good, no one will know. What is wrong with that reasoning? Work done inside a company's sanctioned Claude workspace is potentially auditable after the fact through Enterprise-tier admin tooling, so working outside it isn't hidden by being unaudited, it's a separate, more serious policy violation regardless of output quality. Since it was avoidable, the right move once realized is to flag it to the policy owner rather than let it stand unreported. The distractor "quality output means no one checks how it was produced" ignores that governance is about process, not just outcome. ### Q4. A new associate isn't sure whether a task they're about to run counts as an "approved use case" under company policy, and their manager is unavailable. What should they do? Check the written policy first, and if it doesn't resolve the question, escalate to the org's designated policy owner or compliance/legal contact before running the task, waiting for their manager specifically isn't required if another named escalation path exists. The distractor "proceed since the task seems low-risk and ask forgiveness later if needed" substitutes individual judgment for the organization's defined approval process, exactly what following governance means avoiding. ### Q5. A new associate is told their company's AI policy requires use-case approval before deploying Claude to a new workflow, and finds this frustrating since the workflow seems obviously safe. What is the best way to understand why this step exists? Use-case approval functions like the Map step in a governance framework such as NIST's AI RMF, identifying and classifying risk before deployment, independent of any one employee's judgment that a use case is "obviously safe." The distractor "skip approval since the task is low-risk in my judgment" substitutes individual judgment for the organization's defined process, exactly what following organizational governance means avoiding. ## FAQ ### Q1. Does Anthropic's Responsible Scaling Policy mean my company's Claude usage is automatically compliant? No. The RSP governs how Anthropic scales and safeguards its own models. Whether your company's specific use of Claude with specific data satisfies your company's own regulatory or data-handling obligations is a separate, organization-level question. ### Q2. How does a company actually enforce its AI policy, not just write it down? Through product-level admin controls on Claude Enterprise (audit access to usage, spend approval workflows, role-scoped admin access) - technical enforcement rather than a document employees are trusted to remember. As an employee this mainly means: usage inside the sanctioned workspace is potentially reviewable after the fact. ### Q3. I'm not sure whether a task or data class is covered by policy. What should I do? Check the written policy first. If that doesn't resolve it, escalate to your org's designated policy owner, AI governance lead, or compliance/legal contact before proceeding - don't decide unilaterally based on your own risk judgment, and don't wait for a specific manager if another named escalation path is available. ### Q4. I discovered a governance gap (unapproved use case, misrouted data, a skipped review step). Should I quietly fix it myself? No - report it through the same escalation channel you'd use for a question, promptly. Governance depends on gaps being surfaced and tracked, not silently self-corrected, even when the fix seems obvious. --- **Source:** https://claudearchitectcertification.com/concepts/organizational-ai-governance-policy **Last reviewed:** 2026-05-04 **Evidence tiers**, 🟢 official Anthropic doc / API contract · 🟡 partial doc / inferred · 🟠 community-derived · 🔴 disputed.