CCAO-F Glossary - Governance, Risk, and Responsible Use

Quick-lookup definitions for every domain, with exam context and links back to the lesson that covers each term.

Appropriate Use Case (Human-in-the-Loop Test): A business use case for Claude is appropriate when a human with real authority to change the outcome reviews a consequential decision before it takes effect on the person it affects, and that review is substantive rather than a rubber-stamp formality. Fully autonomous high-stakes decisions — such as auto-rejecting job applicants below a score threshold or approving/denying loans end-to-end with no analyst check — fail this test regardless of how accurate the system is. Review that only happens after the affected person has already been notified, such as a post-hoc spot-check, does not count, because it doesn't stand between the decision and the person.; Exam context: Watch for scenarios where a human is technically 'somewhere in the process' but without real authority or timing — a low-rate spot-check on notices already sent, or a reviewer with no context to overrule Claude. These read as appropriate on a skim but fail the actual test.; See also: 6.1 Appropriate and Inappropriate Use Cases
Ethical Implications of AI Use: Two ethical concerns govern responsible Claude use beyond the human-in-the-loop test itself: fairness and transparency. Fairness matters because an AI-assisted process applied at scale can quietly encode a bias that a purely human, one-case-at-a-time process would have caught — a reviewer who rubber-stamps Claude's output without real context or authority isn't providing oversight that catches this. Transparency matters because concealing AI's material involvement from someone it would affect (for example, an applicant's ability to know a scoring system was used, so they can meaningfully appeal) is itself an ethical problem, separate from whether the underlying decision was accurate.; Exam context: A common distractor assumes transparency about AI involvement only matters if the decision turns out wrong. The exam treats concealment as a problem in its own right, independent of accuracy.; See also: 6.1 Appropriate and Inappropriate Use Cases
Scoped Role / Least Privilege: Least privilege is a governance principle requiring that each person be granted the minimum Console access their actual job requires, not the broadest role available because it's easier to hand out once. Anthropic Console organizations support multiple deliberately scoped roles, and matching a person's described job need — not their job title — to the narrowest fitting role is a core admin responsibility. It's an ongoing habit, not a one-time setup task: roles should be revisited and narrowed when a contractor's engagement ends, someone changes teams, or a pilot project wraps up.; Exam context: The exam frames questions around a specific described job need rather than a job title alone, and treats over-provisioning as wrong even when the broader role 'would technically work' for the person's job.; See also: 6.2 Console Roles and Scoped Permissions
Console Roles: Claude Code User & Billing: The Claude Code User role grants building/experimentation access — the Workbench and the organization's Claude Code workspace — without administrative capabilities like API key management or webhook configuration. The Billing role grants the reverse scope: it can update payment methods and monitor usage/cost data across the organization, but has no access to the Workbench, Claude Code workspace, API keys, or webhooks. Both are concrete examples of roles deliberately scoped to what the job actually needs.; Exam context: A common distractor argues Billing 'should' also include Workbench access for convenience. The exam wants least privilege and blast-radius limitation named as the reason to keep it scoped as-is.; See also: 6.2 Console Roles and Scoped Permissions
Blast Radius: The scope of damage a mistake or a compromised account can actually cause, bounded by what its assigned role permits. A compromised Billing-role account, for example, cannot mint a new API key, redirect a webhook, or touch production, because that access was never granted in the first place — scoping roles tightly is a real control that shrinks blast radius, not merely a tidiness preference.; Exam context: Questions test whether you can articulate blast-radius limitation as the governance reason for scoping, not just recall that scoped roles exist.; See also: 6.2 Console Roles and Scoped Permissions
Bulk Department Access: An Enterprise-tier Console feature that lets an admin add an entire department to a Project in a single action, rather than sharing individually with each employee. It is a genuine, built-in Team/Enterprise collaboration feature reflecting that enterprise deployments need to distribute access at the scale of an org chart, not a workaround like a shared login or an externally maintained distribution list.; Exam context: The exam distinguishes this real product feature from manual per-person workarounds, and separately tests whether using it is the appropriate choice for a given Project's sensitivity — see Project Access Governance.; See also: 6.3 Project Sharing and Access Governance
Project Access Governance (Convenience vs. Control): The judgment of whether to use broad bulk sharing or narrower, role-based sharing for a given Project, driven by the organization's own AI governance policy rather than by what's most convenient. A help-center drafting Project may reasonably be shared broadly across a department; a Project containing draft contract terms or unreleased pricing strategy should follow policy restricting it to specific roles or groups (for example, Sales leadership and Legal) even though bulk-adding the whole department is one click away.; Exam context: A common distractor assumes an admin's action is compliant simply because the admin has the technical permission to perform it — technical capability is not the same as policy compliance.; See also: 6.3 Project Sharing and Access Governance
Data Residency: An umbrella term covering two independently controllable aspects of where a Claude-based system handles data: where a given API request's model inference is processed, and where an organization's data is stored at rest. A regulatory or privacy requirement can apply to only one of these, so identifying which lever a described requirement actually concerns is essential before choosing a control.; Exam context: The exam tests whether you can read a scenario for which specific requirement — inference or storage — is stated, rather than reaching for a generic 'data residency' answer.; See also: 6.4 Data Residency and Privacy Considerations
Inference vs. Storage Location: Inference location controls where a specific API request's model computation runs — a narrow, per-request setting. Storage location controls where an organization's data persists at rest — a standing, organization- or workspace-wide setting. A requirement to run inference on US infrastructure without changing where workspace data is stored calls for the per-request inference control only; a blanket requirement that all customer data live within a particular region is a storage-at-rest requirement, a separate control entirely.; Exam context: The most common trap is conflating the two — reaching for a workspace-wide storage setting when the scenario explicitly says storage should stay unchanged (a signal pointing to the inference-specific control), or the reverse.; See also: 6.4 Data Residency and Privacy Considerations
Data Sensitivity Classification: The step of determining what a piece of data actually is — and whether it should be sent to Claude at all — before deciding how to apply any residency control. Some categories, such as certain health information or government-issued IDs, may need exclusion or special handling entirely, independent of where inference runs or where results are stored. De-identification reduces risk but does not eliminate the need for this classification step.; Exam context: A common distractor assumes de-identified or 'low-risk-sounding' data is automatically exempt from classification. De-identification lowers risk but doesn't remove the requirement to classify.; See also: 6.4 Data Residency and Privacy Considerations
Audit Trail (Activity Feed): The Activity Feed is Anthropic's Console capability designed to retain an organization's administrative and usage activity for 6 years, supporting compliance investigations and incident review — situations that typically surface well after the events themselves occurred. A standard usage dashboard covering only recent activity does not satisfy a multi-year retention requirement.; Exam context: The exam tests whether you name the Activity Feed specifically (not a generic 'usage dashboard') when a scenario describes a multi-year lookback for compliance or incident review.; See also: 6.5 Audit Trails and the Transparency Hub
Transparency Hub: A separate, public-facing Anthropic resource where the company publishes periodic reports on its own safety practices and enforcement measures at the company level. It is not a per-organization activity log a compliance officer would use to audit their own account — that is the Activity Feed's job — so the two capabilities serve different audiences and purposes despite the similar-sounding names.; Exam context: A frequent distractor confuses the Transparency Hub with an internal audit tool. The exam tests recognizing it as Anthropic's own public reporting, not an organization's internal activity record.; See also: 6.5 Audit Trails and the Transparency Hub