Safety, privacy, and governance
Review guardrails, redaction, data boundaries, access, retention, model cards, and operational approvals.
What you will practice
Inspect guardrail policy; Review input redaction; Review output redaction; Locate sensitive fields.
Use the worked examples when needed, then test your understanding without them.
- 01Inspect guardrail policyA guardrail policy names risks, checks and escalation boundaries. A policy document is not proof that those controls are actually enabled in the serving path.Practice
- 02Review input redactionInput redaction limits sensitive data sent to a model or logged by an application. Verify the resulting payload rather than assuming that a redaction switch caught every field.Practice
- 03Review output redactionOutput redaction has to inspect the produced response, not just the original input. A model may repeat sensitive source material in a new wording or field.Practice
- 04Locate sensitive fieldsSensitive-field review depends on context and policy. Distinguish operational metadata from credentials and personal data before exporting a diagnostic record.Practice
- 05Check data retentionRetention describes how long data is kept and for what purpose. A retention setting should match policy and actual deletion behavior, not just a label in a form.Practice
- 06Inspect access boundariesAccess boundaries limit which subjects can read or change which resources. Relevance to a task does not grant permission to cross a tenant or role boundary.Practice
- 07Read a model cardA model card records intended uses, limits and evaluation context. It is an evidence source for review, not a guarantee of suitability for every deployment.Practice
- 08Review approved useApproved use is specific to the task, data and controls that were reviewed. A new high-impact use needs its own assessment rather than inheriting an unrelated approval.Practice
- 09Inspect refusal evidenceRefusal evidence should be evaluated against the actual policy and task. Over-refusal and missed refusals are different failure modes with different user impacts.Practice
- 10Review human escalationHuman escalation needs an identified recipient, a bounded reason and a safe hold state. A vague “ask someone” message is not an operational handoff.Practice
- 11Check audit metadataAudit metadata should record what changed, who authorized it and which versions were involved. Avoid collecting raw secrets simply to make an audit record look complete.Practice
- 12Separate safety and qualitySafety and task quality are separate evaluation dimensions. A useful answer can violate a data boundary, while a safe refusal can still be unhelpful for an allowed request.Practice
- 13Prepare a governance reviewGovernance review checks intended use, data permission, access, retention, testing and ownership together. Mark missing evidence explicitly rather than assuming it exists.Practice
- 14Write a risk summaryA risk summary should describe the failure, affected boundary, mitigation and residual uncertainty. Do not promise zero risk from a finite set of checks.Practice
- 15Safety and governance checkpointA safety checkpoint needs both policy and tested enforcement. Keep releases gated when a required control or approval is missing, even if the model output looks plausible.Practice