Governance, Safety & Risk Management

Governance, Safety & Risk Management is 14% of the CCAR-P blueprint — about 9 of the 63 questions. The objectives are implementing guardrails and safety controls, identifying the risks, limitations and failure modes of LLM systems, applying human-in-the-loop validation strategies, ensuring compliance — the guide names GDPR, HIPAA and FedRAMP as examples — and addressing ethical considerations including bias, fairness and transparency.

Read the compliance objective carefully, because it is easy to prepare for it wrongly. This is not a law exam and it is not testing whether you can recite a regulation. What an architect owns is the translation: turning an obligation the organisation has accepted into properties of the system that can be pointed at and checked. Where data is processed and stored. How long it is kept, by whom, in which copies. What lands in logs. Who can read a trace. Which decisions require a documented human review. Which of those matter, and how strictly, is set by the organisation's own risk posture and its legal advisers — the architecture's job is to make each one explicit and verifiable rather than assumed.

The safety half is more concrete and is where most of the marks are. Guardrails are layered and they live outside the model. A control the model can read is a control it can be talked out of, and most questions here are built on that distinction.

What the exam actually tests

• —Layering controls across input, output and action, and knowing which layer a given risk belongs to
• —Why a guardrail written into a prompt is not enforcement
• —Placing human review where it changes an outcome, without creating approval fatigue
• —Naming LLM failure modes precisely enough to attach a control to each
• —Translating an organisational obligation into verifiable architectural properties
• —Treating fairness and transparency as measured, evidenced system properties

Guardrails are layered, and they live outside the model

Three layers, and questions usually turn on picking the right one. Input controls validate and classify what enters, keeping untrusted content — retrieved documents, user uploads, web pages, ticket bodies — separated from trusted instructions. Output controls check what comes back: schema validation, policy classification, verifying that a citation resolves to a document that actually says it. Action controls sit on the tools, deciding what the system may do regardless of what it decided to say.

The architectural point is that none of these can be a sentence in a system prompt. The model reads content that may carry instructions of its own and cannot reliably tell those from yours. Enforcement belongs where the model cannot reach: the tool implementation, the permission layer, a validator between the model and the next system.

Defence in depth applies normally. One layer will fail; the design question is what catches it.

Human-in-the-loop: where the gate goes, and what it costs

Put a human gate before actions that are irreversible or expensive — refunds, deletions, outbound messages to customers, anything with a financial or legal consequence — and before decisions the organisation has decided a person must own. Do not put one inside a tight tool-use loop, where it converts minutes of work into hours and produces nothing but delay.

The part candidates skip is designing the review itself. A gate is only a control if the reviewer can exercise judgement, which requires enough context, enough time, and a volume low enough to stay attentive. The approval payload matters: what the system wants to do, why, and what it found. Measure the gate like any other component — a near-total approval rate is usually evidence that review has become a formality, and a formality generates an audit trail documenting scrutiny nobody applied.

Compliance as an architectural specification

Convert obligations into properties. Useful ones recur across regimes, whatever the specific requirement turns out to be: where processing and storage physically happen; how long inputs, outputs and traces are retained and in how many copies; whether logs, error messages and evaluation sets contain regulated content; who can read a trace and whether that access is itself recorded; whether a vendor's retention and residency configuration matches what was committed; and which decisions require a documented human review before taking effect.

Each is checkable, which is the point — an architecture that can only assert compliance cannot demonstrate it. Two practical consequences follow. Several of these properties are expensive to reverse, so they belong in design rather than a pre-launch review. And they are not one-time: adding a tool, a log sink, a region or a vendor changes the answers, so the specification needs an owner and a re-check trigger.

Failure modes worth naming at design time

Name them precisely enough that each attaches to a control. Fabrication — confident, plausible, wrong — is worst where output looks citational, and the control is verification against a source rather than a confidence question put to the model, which is not a reliable signal. Prompt injection arrives through content the system itself retrieves, so the control is isolating untrusted content and restricting what any instruction inside it could reach.

Data leakage travels through paths people forget: logs, error messages, evaluation sets built from production traffic, tool results that return more than was needed. Silent degradation follows a change in something you do not own — an index rebuild, a dependency, a model version — and the control is monitoring plus a regression suite. Over-trust is a downstream system treating output as authoritative because it arrived as valid JSON; structural validity says nothing about whether the content is right.

Bias, fairness and transparency as system properties

These are measured, not asserted. A fairness claim you cannot evidence is a liability rather than a control, so the practical form is evaluation broken down across the segments the system actually serves — not an aggregate, which is precisely where disparate outcomes hide.

Transparency has an architectural consequence that catches people out. Explaining an adverse outcome afterwards requires that the evidence still exists: which documents were retrieved, which tools ran, what the configuration was. A pipeline that discards intermediate state cannot explain itself later, and no policy fixes that once the data is gone. If explainability is a requirement, retaining the decision trace is part of the design — and the user-facing half is disclosure: being clear about what the system is, what it is not, and where it is known to be unreliable.

Where candidates go wrong

How to study this domain

Do not study regulations. Study the translation, because that is what an architect is accountable for and what the exam can fairly test. Take one system you know and write the properties out: where data is processed, what is retained and for how long, what appears in logs, who can read a trace, which decisions need a human signature. Any answer of 'I would have to check' is the gap the questions probe.

For the safety objectives, drill one question until it is automatic: where is this control enforced? Prompt text, a tool description, and the model's own judgement are all wrong whenever a stronger enforcement point exists — and in a well-constructed question, one always does.

Build a two-column list of failure modes and controls — fabrication, injection, leakage, silent degradation, over-trust — with a concrete control for each. Questions here often describe a symptom without naming the failure, so recognising it is the first move.

Finally, get comfortable with controls having costs: human review costs throughput, output validation costs latency, retaining traces for explainability costs storage and creates its own exposure. The professional answer names the cost rather than pretending the control is free.

Common questions