Domain 6 — Governance, Risk, and Responsible Use
CCA Associate Foundations course · Page 7 of 10 · ← Back to all courses · Weight: 15%. Mark this page complete at the bottom to advance your course progress.
6.1 — Claude's Safety vs. Your Organization's Policy · Core
Claude's trained safety behaviors reduce obviously harmful, general-purpose output — they apply automatically, everywhere, with no configuration. What they do not do is know your company's specific rules: what data may be entered, which decisions need sign-off, which tools are approved. A request can pass Claude's safety checks completely and still violate your organization's acceptable use policy (AUP) — those are two separate layers, and the organization is always responsible for the second one.
⚠ Often-missed — Non-Refusal ≠ Compliance · Gap
If Claude helps with something and doesn't refuse, that proves only that the request cleared Claude's general safety training. It proves nothing about whether your company's AUP permits it. An employee sharing confidential M&A details, or skipping a required Finance Director approval before submitting financial projections, has violated policy even though Claude never refused — this exact framing is one of the most repeated scenario setups on the exam.
6.2 — Data Privacy: Share Only What the Task Needs · Core
Never enter: passwords, API keys, tokens; patient health records without proper setup; SSNs, passport numbers, full financial account details; confidential business data not approved for AI use.
Data exposure can happen even when Claude behaves perfectly. If a tool call returns a full customer record including SSN and Claude faithfully includes it in a reply, that's not a model error — it's a design failure: too much sensitive data was allowed into the context in the first place. The fix is structural (trim the input/tool output before it reaches Claude), never just an instruction telling Claude not to repeat it — that's probabilistic, not a control.
6.3 — Three Regulatory Frameworks · Core
| Framework | Triggered by | Key mechanism |
|---|---|---|
| GDPR | Processing any EU resident's personal data — regardless of where your company is based | Data minimization; right to erasure |
| HIPAA | US patient health information (PHI) | A signed BAA (Business Associate Agreement) required before any vendor touches PHI — seeing a BAA requirement signals HIPAA specifically |
| FedRAMP | Selling/operating cloud services for a US federal agency | Authorization is per specific product/configuration, not a blanket provider certification |
All three can apply to the same organization at once (a telehealth company with EU patients that also serves a federal agency faces all three). GDPR is explicitly extraterritorial — the trigger is the data subject's EU residency, never the company's home country.
6.4 — Human Review for Consequential Actions · Core
Human authorization is required before an irreversible or high-impact action executes — not after:
- Sending external communications (emails, contracts)
- Financial transactions/commitments
- Data deletion (irreversible by definition)
- Decisions affecting a person's opportunities: credit, hiring, benefits eligibility
For high-volume, low-risk, reversible work, sampled review is sufficient — per-action approval isn't required everywhere, only where the action is irreversible or consequential. Regulatory human-accountability requirements apply regardless of model accuracy — a 99%-accurate model still doesn't substitute for the mandated human sign-off on an adverse credit decision.
6.5 — Bias, Fairness, and Transparency · Core
Aggregate accuracy does not prove fairness. A 95%-overall-accurate system can be 71% accurate for one language or demographic group — always check per-slice, not just the total. Fairness needs consistent criteria across groups (different thresholds per demographic is disparate treatment, even with good intentions) and ongoing monitoring — a system fair at launch can drift unfair as usage patterns shift over months.
Transparency has three separate, all-required elements:
- Disclose AI involvement — presenting Claude as a human (a human name, photo, evasive answers to "are you AI?") is a violation on its own.
- Explain the decision — "the AI decided" is not an explanation; the actual factors must be articulable.
- Document known limitations so users know when to seek other help.
Disclosure alone is never sufficient — that's the standard exam trap in this section.
Exam reflexes for Domain 6
- Claude doesn't refuse a request → proves nothing about company policy compliance; check the AUP separately.
- Full customer record (with SSN) faithfully returned by Claude → not a model error; the design let too much data into context.
- BAA mentioned in a scenario → signals HIPAA specifically, not GDPR.
- "EU resident's data, non-EU company" → GDPR still applies; extraterritorial by design.
- Irreversible action (send, pay, delete) proposed with no human step → requires authorization before execution, always.
- 90%+ aggregate accuracy cited as proof of fairness → wrong; check per-slice before concluding anything.
- Different confidence thresholds by demographic group, even "for equity" → disparate treatment, not a fix.
- AI discloses it's AI but gives no reasoning for a decision → transparency incomplete; explainability is a separate requirement.
Test yourself on this domain. Take the Domain 6 practice quiz — 38 questions, instant scoring, an explanation for every answer.