Exam Room · AI Practitioner

Cheat Sheet: Responsible AI, Security, and Governance

· 12 min read

AI Fundamentals · part of The Exam Room

A fast pass over responsible AI, security, and governance: the eight dimensions by name, and the terms that get skimmed past because they sound generic.

The eight responsible-AI dimensions at a glance

Dimension Canonical scope
Fairness Impacts are equitable across stakeholder groups
Explainability Understanding and evaluating why a system produced a given output
Privacy and security Appropriately obtaining, using, and protecting data and models
Safety Preventing harmful output and misuse; about what the model emits
Controllability Mechanisms to monitor and steer behaviour: intervene, override, shut down; about human power over the system
Veracity and robustness Correct output under unexpected or adversarial input
Governance Organisational processes to define, implement, and enforce responsible AI
Transparency Informing stakeholders how the system works, including that it is AI at all, so they can choose how to engage with it

Security and governance terms at a glance

Term What it covers
Interpretability Understanding a model’s internal mechanics: how it actually computes an output
Explainability (as distinct from interpretability) A post-hoc account of why a specific output happened, without opening the model up
Fairness-through-unawareness The naive, failing fix of deleting a protected attribute from the data
Shared responsibility model (Bedrock) AWS owns infrastructure and model hosting; you own your data, prompts, IAM configuration, and compliance of your own usage
Amazon Macie Finds PII and other sensitive data in S3
Amazon Inspector Finds vulnerabilities in workloads: EC2, ECR images, Lambda
AWS Config Tracks resource configuration and evaluates it against rules
AWS Artifact AWS’s own downloadable compliance certifications: SOC reports, ISO certificates
ISO/IEC 42001 The AI management system standard; 27001’s sibling, for AI governance specifically
Direct prompt injection Malicious instructions arrive through the instruction channel: the user’s own message
Indirect prompt injection Malicious instructions arrive through the data channel: a retrieved document, a tool result, a webpage
Jailbreaking Getting a model to ignore its own safety training via crafted prompts, distinct from injection

Decision rules

  • If the concern is equitable impact across groups, name it fairness; if the concern is why an output happened, name it explainability; do not reach for a control before naming the dimension.
  • If the concern is a model doing something harmful, that is safety; if the concern is a human’s ability to intervene, override, or shut the system down, that is controllability. The two are adjacent and frequently swapped.
  • If the concern is disclosing that a system is AI at all, or how it works, that is transparency, not governance; governance is the organisational process behind enforcing all of this, not the disclosure itself.
  • If a review asks for a model’s internal mechanics, that is interpretability; if it asks for an after-the-fact account of one output, that is explainability. An LLM almost never offers the first.
  • If someone proposes fixing bias by deleting the protected attribute from the data, name the trap: fairness-through-unawareness. Other features still act as proxies, and now the bias cannot even be measured.
  • If a Bedrock security question is about infrastructure or model hosting, that is AWS’s side of shared responsibility; if it is about your data, prompts, IAM, or usage compliance, that is yours.
  • If PII in a data store is the concern, use Macie; if vulnerabilities in a workload are the concern, use Inspector; if resource configuration drift against a rule is the concern, use Config. Three different objects being checked.
  • If you need AWS’s own compliance evidence, that is AWS Artifact; if you need your own model’s documentation, that is a Model Card; if you need evidence of your own usage, that is Audit Manager. Match the author to the artefact.
  • If malicious instructions arrive in the user’s own message, that is direct injection; if they arrive through a retrieved document or tool result, that is indirect injection. The channel is the tell, not the intent.
  • If a crafted prompt is getting the model to override its own safety training rather than an application’s instructions, name it jailbreaking, not injection.

Traps

  • Reaching for “safety” whenever anything sounds risky. Safety is specifically about harmful output; a human-oversight question is controllability even if it feels adjacent.
  • Treating transparency and governance as the same dimension because both sound like paperwork. Transparency is disclosure to stakeholders; governance is the organisational process behind everything else.
  • Promising interpretability on a foundation model. What you can actually deliver is explainability as traceability: citations, documented behaviour, a stated rationale.
  • Assuming removing a protected attribute makes a model fair. It is fairness-through-unawareness, and it typically makes bias worse and unmeasurable.
  • Reading shared responsibility as AWS taking your side of it too. AWS secures the infrastructure and hosts the models; your data, prompts, IAM configuration, and the compliance of your own usage stay yours, however managed the service feels.
  • Mixing up Macie, Inspector, and Config because all three sound like general “security scanning”. Each checks a different object: data, workload, configuration.
  • Treating AWS Artifact as documentation about your own AI usage. It is AWS’s own certification downloads, not your evidence trail.
  • Calling every prompt-based attack “prompt injection”. A jailbreak targets the model’s own alignment; injection targets an application’s instructions, and it further splits by which channel the malicious content arrived through.

Say it in one line

  1. AWS names eight responsible-AI dimensions: fairness, explainability, privacy and security, safety, controllability, veracity and robustness, governance, and transparency.
  2. Safety is about what a model emits; controllability is about a human’s power to intervene, override, or shut it down.
  3. Interpretability is internal mechanics; explainability is a post-hoc account. An LLM offers the second, rarely the first.
  4. Fairness-through-unawareness fails because other features act as proxies for the deleted attribute, and now bias cannot be measured either.
  5. Bedrock’s shared responsibility: AWS owns infrastructure and hosting; you own data, prompts, IAM, and usage compliance.
  6. Macie finds PII in S3, Inspector finds workload vulnerabilities, Config tracks resource configuration against rules.
  7. AWS Artifact is AWS’s own compliance certification downloads, distinct from a Model Card (your model) or Audit Manager (your usage evidence).
  8. ISO/IEC 42001 is the AI management system standard, 27001’s sibling for AI governance.
  9. Direct injection arrives through the instruction channel; indirect injection arrives through the data channel; jailbreaking targets the model’s own alignment rather than an application’s instructions.

These posts are LLM-aided. Backbone, original writing, and structure by Craig. Research and editing by Craig + LLM. Proof-reading by Craig.