Trust and control

Executive summary

Stage 4 is where technical feasibility becomes organisational permission to operate. Before you scale spend or expose AI to customers, you must demonstrate that the solution is safe, lawful, governable and observable—not merely accurate on a demo set. Completing this stage means you can produce threat models, DPIA inputs, risk classifications, model cards, approval gates, observability plans and incident runbooks that satisfy security, legal, risk and audit stakeholders. Stage 4 does not replace Stage 2 evaluation (topic 21); it wraps eval in security, privacy, governance and operations so production failure is detectable, contained and accountable.

When to use this page

• After Stage 2 feasibility and Stage 3 architecture sketches exist—but before customer-facing or high-risk internal launch.
• When security, legal, risk or compliance asks "how do we know this is safe?" and the team only has accuracy metrics.
• When moving from pilot to production scale, new region, new model vendor, or new data source.
• When an incident, regulator question or audit finding exposes gaps in logging, retention, or approval trails.
• When integrating agents with tools that read, write or spend money on behalf of users.

Executive view

Ask for the **Stage 4 artefact pack** before signing scale investment: threat model summary, DPIA status, risk tier, model card, approval gate evidence, SLO draft and kill-switch owner. Challenge launch when any Tier High+ item lacks named owner and dated sign-off.

Decision required: Is residual risk documented and accepted by the right authority—and can we stop or roll back the system in minutes if behaviour degrades?

Technical view

Work topics 17–20 in sequence or parallel by workstream, but **do not ship** without cross-links: security controls must appear in observability; privacy retention must match logs; governance risk tier must drive eval bars from topic 21.

File artefacts in document control with version IDs. Trust and control is **evidence**, not a slide saying "we follow best practice."

Outcome

Primary outcome: You can demonstrate that the AI solution is safe and governable—producing artefacts that security, privacy, risk and operations stakeholders can review without reverse-engineering the codebase.

Secondary outcomes:

• Gate launches on documented controls—not informal "we tested it."
• Connect technical measures (injection defence, redaction, tracing) to governance (risk tier, approvals, model cards).
• Operate with SLOs, drift detection and incident response—not firefighting without runbooks.

Stage 4 does not require perfect security or zero residual risk. It requires explicit controls, owners, evidence and stop procedures.

Who Stage 4 is for

Profile	Typical gap	Stage 4 fix
Strong builder, weak security	Great RAG; no threat model	Topic 17
Engineer ignoring legal	Full prompts in logs	Topic 18
Product skipping governance	No risk tier or inventory	Topic 19
Dev without ops discipline	No tracing, rollback or SLOs	Topic 20
Compliance officer entering mid-programme	Artefacts missing	Stage 4 exit checklist as gap analysis

Entry criteria

Start Stage 4 when all of the following are true:

• Stage 2 evaluation plan (topic 21) exists with risk-aware thresholds—or documented exception with sponsor acceptance.
• Stage 3 architecture sketch covers identity, network, data stores and model API boundaries.
• A named use case with intended users, data categories and automation level (HITL vs auto-send) is documented.

Do not treat Stage 4 as optional for customer-facing, employee decisions on compensation/credit, or any system with tool write access.

Minimum entry artefact: one-page solution brief—users, data flows, model/agent scope, regions, integrations.

Exit criteria

Declare Stage 4 complete only when all exit checks pass:

Artefacts (minimum set)

Artefact	Source topic	Pass test
Threat model + abuse-case catalogue	17	Top abuse cases mapped to controls; injection and tool misuse covered
Control matrix (security)	17	Identity, secrets, authZ for tools, supply chain addressed
DPIA / processing map inputs	18	Lawful basis, retention, residency, subprocessors documented
Retention schedule aligned to logs	18	Prompt/trace storage matches policy; redaction design
Risk classification + inventory entry	19	Tier assigned; approval gates defined
Model card (or system card)	19	Intended use, limits, eval summary, oversight
Observability plan + SLO draft	20	Tracing, logging, drift signals, rollback path
Incident response outline for LLM apps	20	Severity matrix, kill-switch, comms owner

Knowledge checks

• Answer ≥12/15 questions from topics 17 and 18 without notes.
• Explain one negative case (security theatre, privacy debt, governance checkbox, ops blind flight) with numbers.
• Walk through stop procedure for a Tier High assistant in under 3 minutes.

Behavioural checks

• Peer reviewer confirms artefacts are filed and cross-linked (e.g. log retention matches DPIA).
• At least one tabletop or walkthrough of injection or incident scenario completed.

Exit is not "we talked to InfoSec." Exit is artefacts reviewed and signed.

Capability map

Stage 4 spans four numbered topics (17–20). Topic 21 (evaluation) is Stage 2/5 adjacent but feeds governance and observability gates.

Topic 17 — Security Engineering

Capability: Design security in—identity, least privilege, encryption, SSDLC—and address AI-specific threats: prompt injection, indirect injection via documents, secrets exposure, excessive agency, denial-of-wallet, supply chain.

You know it when: You produce a threat model with abuse cases and a control matrix that maps to implementation (not generic "follow OWASP").

Deep link: Security Engineering

Topic 18 — Privacy, Legal and Compliance

Capability: Apply privacy by design—lawful basis, minimisation, DPIA, retention, transfers, residency—and align AI logging/training boundaries with UK/EU GDPR themes and sector rules.

You know it when: You redesign logging after discovering full prompts with customer names—and auditors accept the processing map.

Deep link: Privacy, Legal and Compliance

Topic 19 — Responsible AI and AI Governance

Capability: Implement governance mechanisms—principles, risk tiers, inventories, approval gates, model cards, oversight, contestability, kill-switches—aligned to NIST AI RMF and ISO/IEC 42001 themes.

You know it when: Credit memo assistant is classified Tier High with human approval, model card and documented stop procedure—not "we'll monitor it."

Deep link: Responsible AI and AI Governance

Topic 20 — MLOps, LLMOps and Observability

Capability: Operate models and prompts—deployment pipelines, versioning, canaries, drift detection, tracing, structured logging, SLOs and incident response for LLM applications.

You know it when: Faithfulness drop after corpus update is detected via traces, rollback completes in minutes, and post-incident case enters golden set.

Deep link: MLOps, LLMOps and Observability

Topics in this stage (quick index)

17. Security Engineering
18. Privacy, Legal and Compliance
19. Responsible AI and AI Governance
20. MLOps, LLMOps and Observability

Adjacent: AI Evaluation and Quality Assurance — quality evidence required by governance and ops gates.

Recommended practice sequence

Sequence A — Standard (4 weeks, ~8–10 hours/week)

Week	Focus	Outputs due
1	Topic 17 + Security & privacy playbook skim	Threat model, abuse cases, control matrix
2	Topic 18	Processing map, DPIA inputs, retention schedule
3	Topic 19 + Governance playbook	Risk tier, model card, approval gate table
4	Topic 20 + Evaluation & observability	Observability plan, SLOs, rollback runbook outline

Sequence B — Live engagement crash (2 weeks)

Use when launch date is fixed and trust artefacts are missing:

1. Days 1–3: Topic 17 top-5 abuse cases + injection controls for RAG/agents.
2. Days 4–5: Topic 18 logging redaction and retention alignment.
3. Week 2: Topics 19–20 risk tier, model card stub, tracing + kill-switch owner.

Rule: Tier High launches require written risk acceptance if any Stage 4 artefact is amber—not verbal "we're fine."

Sequence C — Post-incident remediation

After security, privacy or quality incident:

1. Forensic trace review (topic 20) → root cause bucket (injection, data leak, model drift, governance gap).
2. Update threat model and controls (17), logging/DPIA (18), governance tier or gates (19), monitors and IR (20).
3. Add incident cases to eval golden set (21).

Integration with playbooks and 8D

Stage 4 capability	Playbook / reference
Security controls, injection, secrets	Security & privacy
Governance, risk tiers, model cards	Governance
Tracing, SLOs, deployment gates	Evaluation & observability
Quality bars feeding governance	Topic 21 + VALUE gate
Methodology spine	8D Framework — Deliver, Demonstrate

Deep-link rule: Learning Map teaches judgement and artefact standards; playbooks walk implementation patterns. Produce both competency proof and delivery references on engagements.

Common failure modes

Failure mode	How it shows up	Fix
Security bolt-on	Threat model after build complete	Topic 17 in design phase
Full prompt logging	GDPR breach waiting to happen	Topic 18 redaction by design
Governance theatre	Policy PDF, no inventory	Topic 19 risk tier + gates
Ops blind flight	No traces when users complain	Topic 20 observability plan
Eval without trust	90% faithfulness, open tool API	Cross-link 17 authZ + 21 eval
Checkbox DPIA	Generic template, no AI specifics	Topic 18 processing map
No kill-switch	"We'll turn off feature flag… somewhere"	Topic 19 stop procedure owner
Vendor trust	"Azure/OpenAI is secure"	Shared responsibility model in 17
Retention mismatch	Logs kept 7 years; policy says 90 days	Topic 18 schedule alignment
Stage 5 before Stage 4	Commercial scaling without audit trail	Block scale until exit criteria

Stage 4 anti-pattern: the compliant demo

Team passes internal demo; InfoSec review scheduled after pilot go-live. Week 3: retrieved document contains indirect injection; agent emails summary to wrong distribution list. No abuse-case catalogue; no tool authZ; logs hold full customer PII. Incident cost £380K remediation + regulatory notification; programme paused 9 months.

Stage 4 antidote: Threat model and tool allow-list before pilot; redacted logging; risk tier and stop owner named in steering pack.

Stage 4 anti-pattern: observability as afterthought

Production RAG serves 12,000 queries/day. No trace IDs; faithfulness complaints rise 40% over 6 weeks. Root cause: chunker change in silent deploy. MTTR 11 days because engineers cannot reproduce retrieval path.

Stage 4 antidote: Deployment pipeline with eval gate (21) + retrieval source in traces (20) + rollback runbook tested quarterly.

Real-world scenarios

Scenario A — UK insurer: Stage 4 gates customer launch

Context: Customer policy Q&A RAG; Stage 2 eval at 94% citation correctness; Stage 3 on Azure UK region. Legal asks for DPIA; InfoSec for threat model; risk committee for Tier classification.

Stage 4 work (6 weeks parallel):

• 17: STRIDE + 12 abuse cases; indirect injection controls (strip HTML, isolate retrieved text, no tool auto-send); rate limits 500 req/user/day; API keys in Key Vault, not env files in CI logs.
• 18: Lawful basis legitimate interest with LIA; prompts stored as redacted hash + trace ID, 90-day retention; subprocessor list includes foundation model provider; UK residency documented.
• 19: Tier High (customer influence); model card v1; human review on compensation intents; kill-switch owned by Head of Digital Operations; AI inventory entry AI-2026-0147.
• 20: OpenTelemetry traces with retrieval_ids, model_version, prompt_version; SLO p95 latency ≤5.5s; faithfulness proxy alert; rollback to prior index build in <15 min runbook drill.

Outcome: Launch approved; 90-day incident count 2 Sev3 (citation edge cases), 0 Sev1; audit sample passed on retention and access logs.

Scenario B — Retail bank: agent with payment lookup tools

Context: Internal agent drafts servicing responses and calls read-only payment API. Engineering wants auto-send for "low risk" intents.

Stage 4 decision: Auto-send rejected for Tier High-B; all outputs HITL until 6 months stable metrics. Tool authZ: OAuth scoped to user SSO identity; deny-by-default tool list; payment API returns masked PAN only.

Numbers: Red team finds 3/40 injection cases exfiltrate retrieved memo content before controls; 0/40 after retrieval sandbox + output DLP. Denial-of-wallet test: burst 10,000 requests blocked at £50/day user cap.

Lesson: Excessive agency is a Stage 4 topic 17 + 19 decision—not only a prompt engineering fix.

Manager review rubric (Stage 4 gate)

Dimension	Red	Amber	Green
Threat model	None	Generic checklist	Abuse cases + controls mapped
Privacy	Unknown lawful basis	DPIA draft	Processing map + retention signed
Governance	No tier	Tier verbal	Tier + model card + approvals
Observability	No traces	Logs only	Traces, SLOs, rollback tested
Incident readiness	No owner	Owner unnamed	Kill-switch + IR table exercised
Cross-artifact consistency	Logs contradict DPIA	Partial align	Retention, eval, governance aligned

Green on ≥5/6 dimensions → recommend Stage 5 commercialisation for that workstream.

Questions you should be able to answer (Stage 4 level)

1. What is the top abuse case and primary control?
2. What lawful basis applies and where is DPIA status?
3. What risk tier is assigned and who approved residual risk?
4. Where are prompts/logs stored, for how long, and who can access?
5. Does data leave residency boundary—for inference, logs or training?
6. Who can stop the system in production and in how many minutes?
7. What model card version matches production?
8. What SLOs matter and what triggers rollback?
9. How do you detect injection or retrieval poison attempts?
10. What tools can the agent call and under what authZ?
11. How are secrets managed and rotated?
12. What supply-chain dependencies are pinned and scanned?
13. How does eval evidence (topic 21) link to governance gates?
14. What happened in the last tabletop or red-team exercise?
15. What negative case from Stage 4 would apply to your industry?

Negative cases — when trust and control fails

Failure mode	Symptom	Prevention
Bolt-on security	Pentest finds critical issues late	Topic 17 in design
Log hoarding	DSAR nightmare	Topic 18 retention + redaction
Tier inflation	Everything "low risk"	Topic 19 classification rubric
Traceless ops	Cannot debug wrong answer	Topic 20 tracing standard
Approval theatre	Sign-off without reading model card	Gate checklist with evidence links
Shared responsibility confusion	"Cloud provider handles security"	17 control matrix RACI
Kill-switch orphan	Nobody knows flag location	19 named owner + drill
DPIA copy-paste	No AI-specific flows	18 processing map
Supply chain surprise	Compromised dependency	17 SBOM + pin
Stage 5 skip	Scale before demonstrate	Exit criteria enforcement

Output

Stage 4 portfolio deliverables (engagement pack minimum):

• Threat model summary and abuse-case catalogue (topic 17)
• Security control matrix with tool authZ and secrets posture (topic 17)
• Data processing map and DPIA inputs (topic 18)
• Retention schedule aligned to logging and observability (topic 18)
• Risk classification and AI inventory entry (topic 19)
• Model card or system card with oversight design (topic 19)
• Observability plan with SLO draft and trace schema (topic 20)
• LLM incident response outline and rollback runbook (topic 20)

Stage 4 completion checklist

• Threat model covers injection, tools, secrets and supply chain
• Lawful basis and retention documented; logs match DPIA
• Risk tier assigned with approval gates and stop procedure owner
• Model card published and version-linked to production
• Tracing includes retrieval sources, model and prompt versions
• SLOs and rollback runbook tested at least once in tabletop
• Cross-artifact review: security, privacy, governance, ops consistent
• Peer review filed in pattern library with sector tag

Related playbook content

• Security & privacy — injection defence, identity, encryption patterns
• Governance — risk tiers, inventories, approval workflows
• Evaluation & observability — tracing, dashboards, deployment gates
• AI Evaluation and Quality Assurance — quality evidence for gates
• How to use this Learning Map — reference depth standards
• VALUE gate — demonstrate evidence before scale
• 8D Framework — Deliver and Demonstrate stages

Key takeaways

• Stage 4 outcome is demonstrable safety and governability—artefacts, not assertions.
• Topics 17–18 address security and privacy; 19 addresses accountability; 20 addresses operability.
• Evaluation (21) supplies quality evidence; Stage 4 wraps it in controls, law and ops.
• Common failure is launch first, trust later—antidote is exit criteria before customer exposure.
• Kill-switch, retention and trace schema must be named before scale—not discovered in incident.
• Stage 5 commercialisation without Stage 4 invites regulatory, security and reputational debt.

What to do next

1. If arriving from Stage 3, begin with Security Engineering—threat model before hardening sprints.
2. Work Privacy, Legal and Compliance in parallel with logging design—not after go-live.
3. Pair Responsible AI and AI Governance with steering committee rhythm.
4. Implement MLOps, LLMOps and Observability before declaring pilot "production."
5. When exit criteria pass, continue to Commercialisation and delivery.