Responsible AI and AI Governance

Executive summary

Responsible AI and governance translate ethical principles—fairness, accountability, transparency, safety, human oversight, contestability—into operating mechanisms enterprises can audit: AI policies, risk tier classification, use-case inventories, approval gates, model cards, eval requirements, oversight design, audit logs and kill-switches. An AI Solution Engineer aligns programmes to NIST AI RMF (Govern, Map, Measure, Manage) and ISO/IEC 42001 themes—AI management system, impact assessment, lifecycle controls—without treating certification as a substitute for feature-level decisions. Credit memo drafting classified Tier High requires human approval, published model card, monthly fairness sampling and a named stop owner—not a generic "AI ethics" slide. Governance connects Stage 2 evaluation (topic 21) to who may launch, who accepts residual risk, and how users challenge AI-influenced outcomes.

When to use this page

• Before pilot or production launch of any AI feature—especially customer-facing, employee-affecting or financial/regulated decisions.
• When building AI inventory for enterprise risk, audit or EU AI Act preparedness.
• When stakeholders disagree on automation level (HITL vs auto-send) or residual risk acceptance.
• When integrating new model vendor, agent capability or high-risk use case into existing portfolio.
• After incident, bias complaint or regulatory question requiring governance remediation.
• When designing model cards, system cards and approval gate tables for steering committees.
• Pair with Privacy and Compliance, Security Engineering and AI Evaluation.

Executive view

Ask for **risk tier**, **approval evidence**, **model card version**, **residual risk signatory** and **kill-switch owner**. Refuse scale when Tier High launches without documented oversight and eval gates from topic 21.

Decision required: Who owns the model/system in production, who accepts residual risk, and can a affected user **contest** an AI-influenced outcome through a defined path?

Technical view

Implement governance hooks in CI/CD: block deploy without inventory ID, model card version bump, eval pass for tier. Wire **feature flags**, **audit logs** and **HITL queues** to architecture—not slide-ware.

Model cards are **honest**—document limits, eval results, known failure modes, not marketing copy.

Why this matters

Enterprises deploy AI faster than they deploy accountability. When something goes wrong—a biased hiring suggestion, wrong credit memo paragraph, agent email to wrong party—regulators, media and boards ask: Who approved this? What was known? What controls existed? Can customers challenge it?

Governance failure is not always malice; it is often missing inventory, unclassified risk, verbal sign-off, no model card, no stop procedure. The organisation cannot demonstrate due diligence—ISO 42001 and NIST AI RMF exist precisely because "we trust the vendor" fails exams and lawsuits.

The AI Solution Engineer bridges principles and mechanics: you classify use cases, define approval gates, draft model cards, design oversight (human review queues, escalation), specify contestability routes, and ensure eval evidence (topic 21) attaches to release records. You facilitate AI review board discussions with data, not adjectives.

Weak programmes publish principles posters and skip inventory. Strong programmes run tiered gates—Low features fast-track with smoke eval; High features need board sign-off, red team, fairness sample, kill-switch drill. When risk officer asks "what AI do we have?" you export inventory CSV with owners, tiers, last eval date—not a frantic Jira search.

Connect to Governance playbook, EU AI Act article, ISO 42001 article, and NIST/EU governance article.

Learn

Responsible AI principles — operationalised

Principle	Operational mechanism
Fairness	Subgroup eval, bias testing, escalation on parity gaps
Accountability	Named owner, risk acceptor, audit trail
Transparency	Disclosures, model cards, explain limits
Safety	Red team, refusal policies, harm monitoring
Human oversight	HITL gates, role-based automation limits
Contestability	Appeals path, human review of disputes
Privacy	Link to topic 18 DPIA and minimisation
Robustness	Eval regression, drift monitors (topic 20)

Principles without mechanisms are aspirational; mechanisms without principles are checkboxes. Both needed.

NIST AI RMF — Govern, Map, Measure, Manage

NIST AI Risk Management Framework (AI RMF 1.0) structures enterprise programmes:

Function	AI Solution Engineer contribution
GOVERN	Policies, roles, culture, inventory, board charter
MAP	Context, categorisation, impact assessment, stakeholder ID
MEASURE	Eval plans, metrics, red team, fairness analysis
MANAGE	Prioritise risks, implement controls, monitor, respond

Use NIST as shared vocabulary with US customers and global risk teams—not only EU AI Act lens.

Core profile mapping example:

• GOVERN-1.2 — AI inventory maintained → inventory entry per feature
• MAP-2.3 — Capabilities/limitations documented → model card
• MEASURE-2.6 — Eval before deployment → topic 21 gate table
• MANAGE-4.1 — Post-deployment monitoring → topic 20 SLOs + drift

ISO/IEC 42001 — AI management system themes

ISO 42001 specifies requirements for an AIMS (AI Management System)—certifiable like ISO 27001.

Themes ASE should supply evidence for:

Clause theme	Artefact
Context and scope	Use case boundary, excluded decisions
Leadership	Board charter, policy approval
Risk assessment	Tier classification, impact assessment
Impact assessment	DPIA + AI-specific harm analysis
Lifecycle controls	Design → deploy → monitor → retire
Data for AI	Quality, bias, provenance (link topic 09)
Monitoring and measurement	Eval + observability
Continual improvement	Incident → golden case loop

Certification is organisational; ASE still produces feature packs auditors sample.

Risk tier classification — enterprise rubric

Illustrative four-tier model (customise with legal/risk):

Tier	Criteria examples	Governance minimum
Low	Internal brainstorm; no PD; no external action	Inventory; smoke eval; principles ack
Medium	Internal Q&A on non-sensitive docs; HITL on edge cases	Model card lite; golden eval; owner sign-off
High	Customer-facing advice; employee comp/credit influence; agent write tools	Full model card; board approval; red team; fairness sample; kill-switch
Critical	Automated legal/medical/credit Decide; safety-of-life	Often prohibit or human-only Decide; continuous SME review; exec risk acceptance

Classification worksheet:

• Who is affected?
• Automation level (inform / recommend / decide)?
• Data sensitivity?
• reversibility of error?
• Regulatory references (EU AI Act annex themes, FCA, etc.)?

Anti-pattern: everything Medium to avoid scrutiny.

Approval gates — stage-gate by tier

Gate	Low	Medium	High	Critical
Product owner	✓	✓	✓	✓
ASE / tech lead	✓	✓	✓	✓
Security (topic 17)		✓	✓	✓
Privacy / DPIA (18)		✓	✓	✓
Eval pass (21)	Smoke	Full golden	Full + red team	Continuous
Risk / compliance			✓	✓
AI review board			✓	✓
Executive risk acceptance			Residual	✓

Document in approval gate table with dates, names, artefact links.

AI inventory / use-case register

Minimum fields per entry:

inventory_id: AI-2026-0147
name: Customer Policy Q&A Assistant
owner: Head of Digital Servicing
technical_owner: ASE lead
tier: High
status: Production
model_provider: Azure OpenAI
model_version: gpt-4.1-2026-04
data_categories: Customer PD, policy text
automation: Recommend + HITL on compensation intents
last_eval_date: 2026-06-15
last_red_team: 2026-05-01
model_card_version: MC-1.3
kill_switch_owner: Head of Digital Operations
retire_date: —

Central register enables portfolio risk view and EU AI Act database preparedness.

Model cards and system cards

Model card ( Mitchell et al. tradition, adapted):

1. Model details — name, version, type, provider, date
2. Intended use — supported scenarios
3. Out-of-scope / misuse — explicit prohibitions
4. Training/fine-tune data — high-level, or "inference-only API"
5. Evaluation results — metrics, datasets, dates
6. Limitations — known failure modes, languages, domains
7. Ethical considerations — fairness, environmental (optional)
8. Recommendations — HITL requirements, monitoring

System card adds orchestration: RAG corpus scope, tools, authZ, eval gates, oversight.

Publish internally at minimum; external transparency where regulation requires.

Human oversight and HITL design

Oversight levels:

Level	Description	Example
Human-in-the-loop	Human approves before action	Send email, post refund
Human-on-the-loop	Human monitors; can intervene	Live agent suggestions
Human-in-command	Human initiates; AI assists	Draft memo; human edits
Human-out-of-loop	Automated	Low-risk internal summarisation

Tier High customer influence rarely justified out-of-loop for external effects.

Design elements:

• Review queue UX with SLA
• Escalation on low confidence / policy keywords
• Audit log: who approved what when
• Training for reviewers on AI limits

Contestability — user and employee rights to challenge

Contestability means affected persons can challenge AI-influenced outcomes and obtain human review.

Minimum path:

1. Disclosure — user knows AI involved
2. Appeal channel — form, phone, in-app
3. Human review SLA — e.g. 5 business days
4. Outcome logging — override reason feeds eval golden set
5. No retaliation — employment law alignment

For credit/insurance decisions, link to regulatory explainability and adverse action notices—legal owns wording; ASE documents data available for review.

Kill-switch and stop procedures

Every Tier High+ system needs documented stop:

Element	Example
Owner	Named role + deputy
Mechanism	Feature flag, API gateway disable, tool off switch
Decision criteria	Sev1 incident, fairness breach, regulator direction
Target time	<15 minutes to contain
Communication	Status page, support script, regulator if required
Recovery	Eval re-run before re-enable

Quarterly drill: owner executes test disable in staging.

Fairness and bias — proportionate measurement

Not every feature needs demographic parity—but High tier affecting people needs subgroup analysis where lawful data exists.

Approach:

• Define protected attributes per jurisdiction (legal guidance)
• Stratify golden set and online sample
• Report metric gaps with confidence intervals
• Escalate if gap > policy threshold (e.g. 5 points on approval rate proxy)
• Document mitigations (prompt, retrieval, HITL)—not silent adjustment

Avoid fairness washing—metrics without action.

Audit logs for governance

Log decisions, not only requests:

• Tier classification and approver IDs
• Model card version at deploy
• Eval report hash at release
• HITL approvals with user ID
• Risk acceptance memos referenced

Immutable or WORM storage for Tier High; retention aligns topic 18 balance.

EU AI Act interface — governance lens

AI Act element	Governance artefact
Prohibited practices	Legal screening in intake
High-risk systems	QMS, logging, human oversight, conformity
Transparency (GP AI)	Disclose AI-generated content
GPAI providers	Vendor documentation downstream

ASE ensures inventory tier aligns with legal AI Act classification—not duplicate legal work but feed accurate use description.

AI review board — operating rhythm

Charter: approve Tier High+, set policy exceptions, review incidents, prioritise remediations.

Standing agenda:

1. New intake classifications (15 min)
2. Launch approvals with gate evidence (30 min)
3. Incident and fairness review (15 min)
4. Policy/regulatory update (10 min)

Quorum: risk, legal, privacy, tech, business line.

Monthly or fortnightly during heavy build.

Retirement and decommissioning

Governance includes end of life:

• Inventory status → Retired
• Kill-switch permanent
• Data deletion per topic 18
• Model card archived with final eval
• User communication if external

Avoid zombie APIs still reachable after "deprecation."

Frameworks and methods

GOV-TIER — classify and gate

Step	Action
Gather context	Users, data, automation, regulation
Outcome harm	Financial, legal, reputational, safety
Verify tier	Apply rubric; legal consult if borderline
Tie mechanisms	Model card, eval, oversight, kill-switch
Inventory	Register entry before pilot
Evidence pack	Link artefacts for approval
Review cadence	Quarterly tier revalidation

Model card template (sections)

## Model/System Card — {name} v{version}
**Inventory ID:** AI-2026-0147 | **Tier:** High | **Date:** 2026-06-01

### Intended use
- ...

### Out of scope
- Not for credit decisions without human-only Decide
- ...

### Architecture summary
RAG over approved policy corpus; tools: none external

### Evaluation summary (see report ER-2026-06-15)
| Metric | Result | Gate |
| Faithfulness | 92% | ≥90% |
| Citation | 94% | ≥90% |

### Limitations
- Welsh language policy PDFs OCR quality low
- ...

### Oversight
HITL on compensation intents; kill-switch: {owner}

### Approvals
| Role | Name | Date |
| Risk | ... | ... |

Approval gate table

Gate	Required artefact	Approver	Date	Status
G1 Intake tier	Classification worksheet	ASE
G2 Security	Threat model + abuse cases	CISO delegate
G3 Privacy	DPIA signed	DPO
G4 Eval	Release gate table green	ASE + Risk
G5 Board	Model card + residual risk	AI Board
G6 Launch	Kill-switch drill complete	Ops

NIST AI RMF quick crosswalk

RMF subcategory	Your artefact
GOVERN 6.1	Policies published
MAP 5.1	Impact assessment in DPIA
MEASURE 2.11	Fairness metrics in eval
MANAGE 4.3	Incident response linked topic 20

Use for gap analysis against enterprise programme.

Contestability flow

Real-world scenarios

Scenario A — UK bank: credit memo assistant Tier High

Context: Relationship managers use GenAI to draft credit memos from financials and CRM notes. Legal classifies High—not automated credit Decide, but influences lending.

Governance pack:

• Tier High; automation = recommend only; RM must edit and sign memo in core system
• Model card v1.2 documents training data exclusion, eval on 240 golden cases, omission rate 3.2%
• AI board approval 2026-03-12 with residual risk: Welsh SME financials underrepresented
• Fairness sample: monthly 100 memos stratified by region; parity review on omission flags
• Kill-switch: Head of Credit Operations; tested 12 min disable March drill
• Contestability: RM can flag "AI omission" in workflow; credit risk team review 3-day SLA

90-day outcomes:

• 0 automated credit decisions (control held)
• 4 contestability cases; 2 prompt/retrieval fixes
• FCA thematic review sample: no findings on governance documentation

Lesson: High tier needs board-grade evidence, not product owner email approval.

Scenario B — Retail: marketing copy generator Tier Low/Medium split

Context: Enterprise wants one governance process for all GenAI. Marketing copy assistant (internal) vs product description on website (customer-facing).

Decision:

• Internal brainstorm variant: Tier Low — inventory + smoke safety eval
• Customer-facing descriptions: Tier Medium — model card lite, grounding eval ≥93%, brand rubric, human publish gate

Numbers:

• Low tier launch: 2 weeks gate cycle
• Medium tier: 6 weeks with 180 case golden set
• Website return rate unchanged after Medium gates vs risky "Low for all" proposal

Lesson: Tiering enables speed where risk low without weakening High standards.

Scenario C — Public sector: contestability after complaint

Context: Council housing allocation eligibility explainer RAG; resident receives wrong eligibility summary citing outdated policy chunk.

Governance response:

1. Kill-switch explainer auto-replies; human-only responses 48 hours
2. Contestability path already published; 37 appeals in 48h window
3. Root cause: corpus freshness (topic 09); eval gap (topic 21)
4. Model card updated limitations; tier remains High with weekly freshness eval gate
5. Board review: mandatory human sign-off on eligibility wording templates

Outcome: Ombudsman complaint upheld on process delay but praised contestability mechanism; £0 additional compensation beyond correction vs prior bot without appeal path (precedent case internal).

Lesson: Contestability reduces harm when errors occur—design before incident.

Scenario D — ISO 42001 audit sample

Context: Enterprise pursues ISO 42001 certification. Auditor samples 3 production AI systems.

Evidence requested per sample:

• Inventory entry and tier
• Impact assessment linkage
• Model card version matching prod
• Eval report for current release
• Incident log or "none" with monitor proof
• Training records for HITL reviewers

Finding: One system model card outdated (v1.1 prod on v1.3 card). Minor nonconformity; fixed in 14 days with CI check blocking deploy if card version < prod tag.

Lesson: Version linkage between model card, deploy tag and inventory must be automated.

Practice exercises

Primary exercise — Classify three use cases (60 minutes)

Use cases:

1. Internal Python code completion copilot for engineers (no customer data in prompts by policy).
2. HR leave policy Q&A for employees (SSO, may log queries).
3. Insurance claims FNOL triage suggestions for handlers (customer PD, suggests next steps—not auto-adjudication).

Tasks:

1. Assign tier each with worksheet rationale.
2. List minimum governance artefacts per tier (inventory, model card depth, eval, board, kill-switch).
3. Define automation level and HITL points.
4. Draft 2-paragraph model card intended use + limitations for highest tier case.
5. Name kill-switch owner role for highest tier.

Acceptance criteria:

• Tiers differ—not all Medium
• Claims case is High with explicit non-auto-adjudication
• Contestability mentioned for employee/customer affecting cases

Stretch exercise — Full governance pack (full day)

Brief: Customer-facing mobile banking transaction dispute explainer—RAG over policy + read-only transaction API; 150k users; UK FCA context; Tier High.

Tasks:

1. Complete GOV-TIER worksheet and classification memo.
2. Full model/system card draft.
3. Approval gate table with six gates and artefact links.
4. Inventory entry all fields.
5. AI board submission one-pager: benefits, risks, residual risk, ask.
6. Contestability procedure draft with SLA.
7. Kill-switch runbook one page.
8. NIST AI RMF crosswalk (8 subcategories mapped).
9. Fairness plan: attributes, metrics, sample size, escalation threshold.

Acceptance criteria:

• Board one-pager includes numeric eval gates from topic 21
• Kill-switch drill steps with time target
• FCA Consumer Duty mentioned in oversight section

Questions you should be able to answer

1. What risk tier is this use case and who validated it?
2. Who owns the system and who accepts residual risk?
3. What approval gates were passed and when?
4. Where is the inventory entry and last review date?
5. What model card version matches production?
6. What automation level and HITL points apply?
7. How can a user contest an AI-influenced outcome?
8. Who owns the kill-switch and when was it last tested?
9. What eval evidence supports launch (link topic 21)?
10. What fairness analysis applies and last results?
11. What is out of scope use documented on model card?
12. How does this map to NIST AI RMF Govern/Map/Measure/Manage?
13. What ISO 42001 evidence would an auditor sample here?
14. What EU AI Act classification did legal assign (if applicable)?
15. What happens at retirement—data, access, communication?

Negative cases — when governance fails

Failure mode	Symptom	Prevention
Principles only	Poster, no inventory	GOV-TIER mechanics
Tier inflation down	High treated as Low	Classification rubric
Verbal approval	"Business signed off"	Gate table with dates
Stale model card	Audit finding	CI version check
No kill-switch	Incident chaos	Named owner + drill
Contestability absent	Ombudsman uphold	Published appeal path
Fairness theatre	Metrics never reviewed	Monthly sample with escalation
Board washing	Rubber stamp	Evidence pack standard
Zombie system	Retired but live API	Decommission checklist
Governance after launch	Incident triggers scramble	Intake before pilot

Case study: the Medium credit tool. Tool classified Medium to skip board. Auto-suggested credit limit increases shown to customers in error. £1.8m remediation; reclassified High; board retrospective.

Case study: model card marketing. Card claimed "no hallucination risk." Regulator quote in complaint letter. Credibility damage; card rewritten with honest limitations.

Case study: kill-switch orphan. Incident required stop; engineer on vacation only knew flag location. 4-hour delay. Now deputy owner + runbook in ops portal.

Operating-model notes

Role	Responsibility
AI review board chair	Gate Tier High+, policy
Risk / compliance	Tier validation, regulatory interface
ASE	Artefacts, facilitation, eval linkage
Product	Oversight UX, contestability channel
Legal	AI Act, contestability wording
DPO	Privacy linkage
Ops	Kill-switch execution

Cadence: Inventory refresh quarterly; tier revalidation on material change; board monthly during scale programmes.

Governance intake form fields

Capture at idea stage—before sprint commitment:

• Problem statement and decision type (inform/recommend/decide)
• Affected population and scale
• Data categories and sources
• Automation and HITL sketch
• Known regulatory references
• Sponsor and business owner
• Preliminary tier (draft)
• Similar systems in inventory (reuse or conflict?)

Route to ASE + privacy for 72-hour triage SLA on Tier unknown.

Escalation paths when tiers conflict

Product claims Low; ASE assesses High:

1. Document disagreement in classification worksheet
2. Privacy/risk tie-break within 5 business days
3. Interim High controls until resolved—do not launch Low gates on disputed case
4. Board minute if material revenue impact from delay

Never silent downgrade to meet deadline.

Model card honesty — examples of good vs bad

Bad: "This system always provides accurate answers."

Good: "Faithfulness on golden set 92% (n=240); fails on conflicting endorsements and Welsh OCR PDFs; human review required on compensation intents."

Bad: "No bias detected."

Good: "Subgroup sample (n=80/region) shows 4pt higher omission flag rate for SME segment; mitigation in progress; monitor monthly."

Honesty builds regulator trust; marketing copy belongs elsewhere.

Third-party and vendor AI governance

When using vendor SaaS AI:

• Require vendor model/system card and subprocessors list
• Contract: change notification, eval rights, deletion support, no training on your data
• Inventory marks vendor_operated vs self_operated
• Tier applies to your use—not vendor's generic certification

Due diligence sample: 3 vendor incidents public review; SOC2 ≠ domain eval.

Scenario E — NGO: transparency and vulnerable users

Context: Charity deploys benefits eligibility explainer for vulnerable users; Tier High due to population and advice nature.

Governance choices:

• Plain-language AI disclosure on every session start
• No auto-apply for benefits—signpost only to official channels
• Human advisor escalation button always visible
• Model card lists training cutoff and local policy version
• Contestability: phone line with 24-hour callback SLA

Outcome: 12,400 sessions first month; 8% escalated to human—by design; 0 media incidents; Ombudsman pre-consultation positive.

Lesson: Transparency and escalation are governance controls for vulnerable users.

Scenario F — Portfolio rationalisation audit

Context: Enterprise inventory audit finds 47 AI entries; 11 orphaned (owner left); 6 duplicate RAG on same corpus; 4 no eval in 18+ months.

Programme:

• Kill-switch orphans within 30 days or assign owner
• Consolidate duplicates—save £320K/year inference
• Re-tier all; 3 reclassified Low→High after review
• Board policy: no production without inventory ID in deploy pipeline

Lesson: Governance debt accumulates like technical debt—quarterly inventory hygiene mandatory.

AI governance maturity model (self-assessment)

Level	Characteristics
1 Ad hoc	Principles only; no inventory
2 Repeatable	Inventory; informal tiers
3 Defined	Gate tables; model cards; board
4 Managed	Metrics on fairness, eval freshness, drill compliance
5 Optimising	Automated CI governance hooks; portfolio cost/risk view

Most enterprises target Level 3 in year one; Level 4 for regulated BUs.

Linking governance to compensation and HR policy

Employee-facing AI touching performance, scheduling, or discipline:

• HR policy addendum required
• Works council / union consultation in applicable jurisdictions
• Tier minimum High; often Critical for discipline-adjacent
• Contestability via HR case management integration

Do not classify as Low because "internal only."

Documentation retention for governance artefacts

Artefact	Retention (illustrative)
Approval gate records	Life of system + 7 years
Model cards (all versions)	Life of system + 7 years
Board minutes referencing AI	Per corporate records policy
Risk acceptance memos	Life of system + 7 years
Kill-switch drill logs	3 years minimum

Align with legal records management—not developer laptop.

Pre-launch governance read-aloud

1. Inventory ID in deploy ticket?
2. Tier matches gate evidence pack?
3. Model card version = prod tag?
4. Eval report hash attached and green?
5. Kill-switch owner confirmed on-call?
6. Contestability path live in prod UX?
7. DPIA status current?
8. Board approval reference for Tier High?

Steering chair signs one-page attestation; file with release record.

NIST AI RMF playbook alignment (detailed subcategory examples)

GOVERN 1.1 — Policies: Enterprise AI policy references tiering, prohibited uses, inventory requirement.

GOVERN 1.7 — Diversity of workforce: Team building AI includes domain SME and affected community consult where appropriate—not only data scientists.

MAP 1.5 — Organisational risk tolerance: Risk appetite statement defines which Tier High residual risks exec may accept.

MAP 3.4 — Benefits and costs: VALUE gate business case linked in inventory.

MEASURE 2.5 — Validity and reliability: Topic 21 eval metrics with confidence intervals on samples.

MANAGE 2.3 — Response and recovery: Kill-switch + topic 20 incident runbook.

Use RMF as gap analysis skeleton when board asks "are we aligned with NIST?"

ISO 42001 certification path — ASE role during audit

Auditors sample 3–5 systems; ASE prepares evidence binders per sample:

• Classification worksheet signed
• Impact assessment (DPIA + AI harms)
• Lifecycle record: design decisions, changes, monitoring
• Competence records for HITL reviewers (training completion)
• Nonconformity log if any prior findings

Certification is company-level; failed sample delays certificate—treat feature docs seriously.

Governance KPIs for executive dashboard

KPI	Target	Source
% production AI with current model card	100%	Inventory
Tier High with board approval	100%	Gate table
Eval freshness (<90 days)	95% systems	Registry
Kill-switch drill compliance	100% Tier High quarterly	Ops log
Open governance Sev findings	0 at scale gate	Risk Jira
Contestability SLA met	>95% cases	CRM

Review quarterly in AI board—not annual slide refresh only.

Union and employee relations communication template

For internal copilot rollout email (legal approves):

• What the tool does and does not do
• What is logged and retention period
• Lawful basis summary in plain language
• How to access, correct, delete data (DSAR path)
• Contestability / HR escalation for AI-related concerns
• Point of contact for questions

Transparency reduces shadow IT adoption of ungoverned consumer tools.

Scenario G — Executive override attempt

Context: SVP requests bypass of AI board for "fast" customer chatbot launch before earnings call; claims Tier Low.

ASE response: Classification worksheet shows customer-facing + PD = Tier High minimum; documents override request in writing; board chair escalates to CRO; launch deferred 3 weeks.

Outcome: Proper gates applied; launch later with 0 Sev1 in first 90 days; SVP override attempt logged in governance audit trail.

Lesson: Governance authority must be protected—document executive pressure and risk acceptance chain.

Fairness remediation playbook

When subgroup metric gap exceeds threshold:

1. Pause auto-send if applicable; HITL only
2. Root cause: data skew, retrieval gap, prompt bias, label bias
3. Mitigation options: corpus expansion, retrieval filter, prompt adjustment, threshold change
4. Re-eval on stratified sample with pre-registered success criteria
5. Document residual gap and acceptance or continued monitoring
6. Board notification if gap affects protected groups materially

Never hide gap without record—regulators punish concealment worse than imperfection.

AI system lifecycle states in inventory

Status	Meaning	Allowed actions
Discovery	Intake only	No prod data
Pilot	Limited users, enhanced logging	Eval required
Production	General availability	Full gates passed
Constrained	Live with HITL/extra monitoring post-incident	Board review date
Retiring	No new users	Deletion plan active
Retired	Disabled	Archive artefacts

Deploy pipeline checks status Production or Constrained only.

Board pack structure for Tier High launch approval

One-page executive summary plus appendix:

1. Recommendation: Approve / defer / reject launch
2. Business value — metric from Stage 1 (e.g. £2.1M handle-time opportunity)
3. Risk tier and rationale — one paragraph
4. Residual risks — bullet list with acceptor name
5. Eval summary — 3 metrics with gates and results
6. Controls — security, privacy, oversight, kill-switch owner
7. Ask — specific approval motion

Appendix: model card, gate table, DPIA status line—not full legal docs.

Board members read page 1; audit samples appendix.

Contestability metrics for governance reporting

Track monthly:

• Appeals received / active users (rate)
• Median resolution time
• Overturn rate (AI wrong vs user error)
• Cases resulting in golden set additions

High overturn rate signals eval or corpus gap—not only UX issue.

Risk acceptance memo template (Tier High residual risk)

When eval or security gate is amber (e.g. 88% vs 90% target), steering may accept residual risk in writing:

• System and tier
• Gap description with metric evidence
• Compensating controls (e.g. HITL on affected intents, reduced user population)
• Expiry date for acceptance (max 90 days typical)
• Remediation plan with owner and milestones
• Signatories: business owner, risk, ASE, DPO if privacy-adjacent

Without memo, amber is no-go—not verbal "we accept."

Governance training for product owners (2-hour module outline)

1. Principles vs mechanisms (20 min)
2. Tier classification workshop (40 min)
3. Model card walkthrough (20 min)
4. Kill-switch drill observation (20 min)
5. Contestability role-play (20 min)

Certification quiz ≥80% before product owners may sign Tier Medium launches unsupervised.

Related playbook content

• Governance — inventories, approval workflows, board charters
• Security & privacy — controls feeding safety
• Evaluation & observability — eval evidence for gates
• EU AI Act (Regulation 2024/1689)
• AI Governance: NIST AI RMF and the EU AI Act
• AI Governance: Implementing ISO/IEC 42001
• Security Engineering
• Privacy, Legal and Compliance
• MLOps, LLMOps and Observability
• AI Evaluation and Quality Assurance
• How to use this Learning Map
• 8D Framework
• VALUE gate

Output

Expected outputs for this topic:

• Risk classification worksheet and tier assignment — with legal/risk validation
• AI inventory / register entry — owners, status, eval dates, model versions
• Model card or system card — intended use, limits, eval summary, oversight
• Approval gate table — approvers, dates, linked evidence
• Oversight design — HITL levels, queues, SLAs, reviewer training
• Contestability procedure — appeal path and logging
• Kill-switch runbook — owner, mechanism, drill record
• NIST AI RMF / ISO 42001 crosswalk — for enterprise programme alignment

Practice checklist

• I classified use case tier with documented rationale—not default Medium
• I listed minimum artefacts for that tier including eval and oversight
• I drafted model card sections: intended use, limits, eval, oversight
• I defined kill-switch owner and test procedure
• I documented contestability path for affected users or employees
• I mapped at least four NIST AI RMF subcategories to artefacts
• I completed approval gate table with named roles
• I filed governance pack linked to inventory ID in pattern library

Key takeaways

• Responsible AI requires mechanisms—inventory, tiers, gates, model cards, kill-switches—not principles alone.
• NIST AI RMF and ISO 42001 provide enterprise structure; ASE supplies feature-level evidence packs.
• Risk tiers drive eval depth, oversight and approval—avoid uniform lightweight governance.
• Model cards must be honest and version-linked to production deployments.
• Contestability and HITL protect users when systems err—design before incidents.
• Kill-switch owner and drills are mandatory for Tier High+ systems.

What to do next

1. Complete the three use-case classification exercise.
2. Continue with MLOps, LLMOps and Observability — operationalise gates in deployment pipelines.
3. Open Governance playbook for board and inventory templates.
4. Align eval release gates in AI Evaluation with tier requirements.