One control plane, three clouds, one audit

Lesson 5 of 5 in Guardrails in the Cloud: Implementing Controls on AWS, Azure, and GCP.

Now close the loop that lesson one opened. An auditor — internal, notified body, or market-surveillance authority — does not ask 'do you use Bedrock Guardrails?' They ask 'show me how you satisfy Article 12' or 'walk me through Annex A control 6.2.8'. Your job is to hold the mapping in both directions: every obligation points at the guardrails that implement it, and every guardrail points at the obligations it evidences. Write that mapping down before the audit and the audit becomes a table lookup; write it after and it becomes archaeology.

From guardrail to obligation — the crosswalk auditors want to see
Guardrail	EU AI Act	NIST AI RMF	ISO/IEC 42001 Annex A
PII redaction / masking	Art 10 data governance (and GDPR minimisation running alongside)	MANAGE — treating identified privacy risk; privacy-enhanced characteristic	A.7 — data for AI systems: quality, provenance, protection
Content filtering	Art 15 robustness; Art 9 risk-mitigation measures	MANAGE — risk treatment for identified harms; safe characteristic	A.6 — life-cycle design criteria; A.9 responsible use
Grounding / hallucination checks	Art 15 accuracy (declared accuracy metrics need a mechanism behind them)	MEASURE — quantifying valid and reliable behaviour in operation	A.6 — verification and validation across the life cycle
Injection & jailbreak defense	Art 15 cybersecurity — resilience against attempts to alter use or behaviour	MEASURE + MANAGE — secure and resilient characteristic	A.6 with ISO 27001 controls carried in — security is a joint-audit item
Invocation logging	Art 12 automatic recording of events; Art 19 log retention; feeds Art 72 post-market monitoring	MEASURE — the evidence base every other function consumes; GOVERN accountability	A.6.2.8 — AI system recording of event logs
Human-review routing	Art 14 human oversight — the routing rule is the oversight measure, its queue metrics the proof it works	GOVERN + MANAGE — accountable and transparent; oversight configuration	A.9 — responsible use; oversight of AI-assisted decisions
Synthetic-content labeling / AI disclosure	Art 50 transparency — machine-readable marking of generated content, disclosure of AI interaction	GOVERN — transparency policies made operational	A.8 — information for interested parties

Most large organisations run more than one of these clouds — which threatens you with three dialects of every control and three different answers to the same audit question. The working cure is policy-as-code: define the guardrail requirements once, in a vendor-neutral specification ('all customer-facing inputs are screened for injection; PII is masked before inference; grounding threshold ≥ 0.8 for regulated advice; every intervention is logged with these fields'), keep it in version control like any other code, and compile it into each cloud’s dialect — a Bedrock guardrail resource here, a Content Safety configuration and Azure Policy there, a Model Armor template on GCP. Terraform and its relatives make the guardrail configuration itself reviewable, diffable, and rollback-able: the change history of your guardrails becomes part of your compliance evidence.

The payoff compounds at audit time. One spec, three implementations, one crosswalk table: when the auditor asks how injection defense works, you show the spec, the three compiled configurations, and the intervention metrics from all three clouds — instead of three engineering teams describing three architectures from memory.

The guardrail limit test — can a technical control carry this obligation?

Interactive decision tree — outcomes:

No guardrail can help
Article 5 bans practices, not implementation details. A social-scoring system with immaculate PII masking is a banned system with good hygiene. The only compliant configuration is not deploying it. Escalate to legal — this is a stop, not a settings question.
Supporting control only
A guardrail can feed a risk management system or an impact assessment (its metrics are excellent inputs), but the obligation is organisational: documented processes, roles, reviews. Pair the technical control with the process artifact — neither substitutes for the other.
A control and its evidence
This is the sweet spot: the obligation demands a runtime behaviour, the guardrail enforces it, and the configuration plus logs prove it. Record the mapping (which article, which control, which dashboard) in your control register now — future-you at audit time says thanks.
Unverifiable control
An unlogged guardrail is a claim, not a control. Auditors verify operation, not existence — turn on the metrics, version the configuration, set the retention, and only then count it toward the obligation.

What guardrails cannot do

Three limits to keep in front of every enthusiastic platform team. They cannot make an unlawful use lawful — a prohibited practice with a PII filter is still a prohibited practice, and a high-risk system with excellent guardrails still needs its risk management system, conformity assessment, and registration. They cannot un-send data — an input filter that blocks a prompt containing health data still received that prompt; where processing must never occur, the control belongs upstream, at the data layer. They are attack surface as well as defense — filters are themselves models with false negatives, and every vendor’s jailbreak-detection claims meet a public internet full of people disproving them weekly. Guardrails lower residual risk; they never zero it, and they never substitute for the decision not to deploy.

Key terms: policy as code, post-market monitoring, human oversight, red-teaming

Tool: Guardrail Catalog — Browse the pre-baked reference catalog: common guardrails with ready-made obligation mappings, per-cloud implementation notes, and the evidence each one should emit — a starting point for your own control register.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.