From obligation to configuration
Lesson 1 of 5 in Guardrails in the Cloud: Implementing Controls on AWS, Azure, and GCP.
Somewhere between the legal team and the engineering team, every AI governance programme crosses a translation gap. The law says 'appropriate levels of accuracy, robustness and cybersecurity' (EU AI Act, Article 15). The engineer needs something they can type: a filter threshold, an IAM policy, a log destination. This module lives in that gap — it is where obligations become configuration.
The first distinction to get precise is between a technical guardrail and a process control. A technical guardrail runs in the request path: it inspects an input or an output in milliseconds, and machine-enforces a decision — block, redact, flag, route. A process control runs around the system: review boards, sign-offs, staff training, incident procedures. Auditors want both, and confusing them is expensive in both directions. A PII filter cannot substitute for a lawful basis to process data; an ethics committee cannot catch a prompt injection at 2 a.m.
Enterprises rarely bolt guardrails onto each application separately. The dominant architecture is the enterprise LLM gateway: one internal service that every application must call to reach any model — the hyperscalers' hosted models, a fine-tuned model, sometimes several vendors at once. The gateway is where authentication, quota, routing, and guardrails concentrate, which means governance gets one enforcement point and one audit trail instead of forty.
Guardrails then live at five layers, and a mature deployment has something at each:
- Input layer — prompt-injection screening, PII redaction, denied-topic checks before the model sees anything.
- Output layer — content filters, grounding checks, protected-material detection before the user sees anything.
- Data layer — what the system may retrieve, retain, and learn from: DLP policies, retention rules, no-training commitments.
- Access layer — who and what may invoke which model, under which guardrail, with least privilege identities.
- Monitoring layer — metrics, logs, and alerts that turn the other four layers into evidence.
Anatomy of a guarded request
- User request
- LLM gateway
Authenticates the caller, applies quota, routes to a model — the single choke point where every guardrail attaches.
- Input guardrails
Prompt-injection screening, PII redaction, denied-topic checks. The model never sees what fails here.
- Input allowed?
- Model inference
- Output guardrails
Content filters, contextual grounding checks, protected-material detection — applied to what the model produced.
- Output allowed?
- Safe refusal returned
A configured message replaces the blocked content. The block itself is a governance event worth recording.
- Response delivered
- Logging & monitoring
Every decision — allowed, redacted, or blocked — lands in the audit trail. This node feeds Article 12 record-keeping and your incident process.
One more piece of mental furniture before the vendor tours: shared responsibility for AI. Cloud security taught everyone that the provider secures the infrastructure and you secure what you build on it. AI adds new rows to that contract — and the rows that matter most to a regulator all land on your side.
| Layer | The hyperscaler gives you | What remains yours |
|---|---|---|
Model safety training | Base alignment and safety training of managed models; default refusal behaviour. | Verifying those defaults hold for your use case and your users — vendor red-teaming was not done on your domain. |
Guardrail tooling | The services exist and are maintained: Bedrock Guardrails, Azure AI Content Safety, Model Armor. | Turning them on, choosing thresholds, deciding block vs mask vs log — an unconfigured guardrail protects no one. |
Data governance | Encryption, data-residency options, contractual no-training-on-your-prompts commitments. | What data you send at all: lawful basis, minimisation, retention, and the Article 10 quality of anything you fine-tune on. |
Access control | IAM / RBAC primitives, condition keys, audit of who called what. | Least-privilege design: which identity may invoke which model, under which guardrail, and nothing more. |
Monitoring | Metrics, logs, dashboards, alerting plumbing. | Alert thresholds, incident response, and routing the logs into your compliance artifacts before anyone asks for them. |
Lawfulness of the use | Nothing. No cloud service makes a use case legal. | Risk classification, fundamental-rights impact assessment, conformity assessment, and the decision to deploy at all. |
Key terms: guardrail, llm gateway, Shared responsibility model, least privilege, prompt injection
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.