Executive Diagnostic

UK & US AI Governance Readiness Assessment

A 40-point self-assessment for engineering organisations deploying AI tools. It is informed by NIST AI RMF 1.0, OWASP GenAI LLM Top 10 2026, ICO guidance, and practical controls across data, vendors, human oversight, AI literacy, and incident response. It supports structured review; it is not a certification or legal opinion.

Last reviewed August 2026 ~15 min self-assessment 40 checkpoints across 8 categories
Your progress
0 / 40
Discuss your gaps with Matt Unlock the remaining 30 checkpoints to export the full assessment.
🗺️

AI Risk Classification & Inventory

Identifying and classifying every AI system in your organisation before broader governance can apply

0 / 5
1.1
A complete inventory of all AI systems in use across the engineering organisation has been compiled and is actively maintained.
Include AI coding assistants (Copilot, Cursor, Codeium), LLM APIs, AI-powered testing, monitoring tools, and AI in CI/CD pipelines. Untracked tools are the most common governance gap.
1.2
Each AI system has been assessed against the NIST AI RMF risk categories (Govern, Map, Measure, Manage).
NIST AI RMF 1.0 is a voluntary, non-sector-specific framework for managing AI risk. NIST states that a revision is in progress, so use the current framework as a structured reference rather than a compliance certificate.
1.3
AI tools used in HR processes (performance reviews, hiring decisions, workforce analysis) are explicitly identified and risk-classified.
Using AI to analyse developer productivity metrics for HR decisions creates significant legal exposure in both UK (Equality Act) and US (Title VII / EEOC) employment law contexts.
1.4
AI coding assistants assessed specifically for use in safety-critical or regulated system development (medical devices, financial services, critical infrastructure).
AI-generated code used in regulated software may elevate the overall system's risk profile regardless of the tool's own classification. UK FCA and US FDA both have active AI guidance for their sectors.
1.5
A designated AI Responsible Person or governance lead is identified with documented accountability for AI risk management.
A named AI-risk owner is a practical governance pattern, not automatically a statutory DPO requirement. The role should be documented and able to escalate decisions across engineering, security, legal and procurement.
🔒

Data Governance & Privacy

Ensuring AI deployments comply with UK GDPR, US privacy laws, and data residency obligations

0 / 5
2.1
Data flows into every AI tool have been mapped: what data is sent, where it is processed, and whether it is used for model training by the vendor.
AI tools differ in retention, training and sub-processor terms. Document the actual configuration, data flows and applicable legal basis instead of relying on a vendor’s generic product description.
2.2
A Data Protection Impact Assessment (DPIA) or equivalent privacy risk assessment has been completed for high-risk AI deployments.
Required under UK GDPR Article 35 for processing that is likely to result in high risk to individuals. Increasingly expected by US enterprise clients conducting vendor due diligence.
2.3
Data residency requirements are documented and verified for all LLM API calls. No customer or PII data is sent to jurisdictions not covered by your agreements.
A common audit failure: developer prompts including PII sent to US-hosted LLM APIs without a valid data transfer mechanism under UK GDPR.
2.4
AI-generated outputs that reference or synthesise personal data are reviewed before inclusion in production systems or client-facing deliverables.
LLMs can regurgitate training data. Automated review processes must catch PII in generated code comments, logs, or documentation.
2.5
AI vendor contracts include data processing agreements (DPAs) with clear retention, deletion, and audit rights.
Enterprise procurement teams and auditors will ask for DPAs. Many AI tool vendors offer them but require them to be explicitly requested.
Full assessment unlock

Unlock the remaining 30 checkpoints and remediation brief

You can self-assess the first two categories natively. To reveal the full governance assessment, covering Security Controls, IP & Copyright, Human Oversight, AI Literacy, Vendor Risk, and Incident Response, plus the board-ready remediation brief, enter your institutional email below.

Corporate domains only. The unlock request is routed to principal review and the full framework opens instantly in this browser.
🛡️

Security Controls: OWASP GenAI LLM Top 10 2026

Defending against the specific attack vectors introduced by LLM and agentic AI systems

0 / 5
3.1
Prompt injection controls are in place for any LLM-powered feature in customer-facing or internal tooling.
Prompt injection remains a material risk for LLM and agentic systems. Treat model input and output as untrusted, constrain privileges, and validate every downstream action.
3.2
Sensitive data and secrets are blocked from reaching LLM context windows via developer tooling or automated scanning.
Sensitive information disclosure can expose credentials, personal data and proprietary context. Use layered controls appropriate to the workflow, including policy, secrets handling, scanning, access control and output review.
3.3
AI-generated code is reviewed by SAST tooling calibrated for AI-specific vulnerability patterns before merge.
AI-authored code should pass the same security gates as human-authored code, with additional review where generated dependencies, permissions or insecure defaults create workflow-specific risk.
3.4
Agentic AI systems (autonomous agents with tool access) operate under least-privilege principles with explicit scope and permission boundaries.
OWASP LLM08 (Excessive Agency). Agents with file system, API, or code execution access must have their permission scope explicitly bounded and monitored.
3.5
AI system supply chain risk is assessed: third-party model weights, fine-tuned models, and plugin/tool integrations are reviewed for integrity.
Third-party models, datasets and components create supply-chain risk. Provenance, integrity checks and change monitoring may also be requested during customer assurance or SOC 2-related reviews.
©️

IP & Copyright Exposure

Managing the ownership and legal risk of AI-generated code and content in your codebase

0 / 5
4.1
A formal policy defines ownership of AI-generated code and who is legally accountable for it in client deliverables.
UK and US courts have not settled AI copyright definitively. Your contracts with clients must address whether AI-generated code is owned, licensed, or disclaimed. This is now a standard enterprise procurement question.
4.2
AI tool vendor indemnification coverage is confirmed and documented for copyright claims arising from generated output.
GitHub Copilot, Google Gemini Code Assist, and Amazon CodeWhisperer all have different indemnification policies. Verify your tier explicitly. Not all enterprise plans include IP indemnity.
4.3
Duplicate/reference code detection (e.g., GitHub Copilot's "duplication detection" filter) is enabled for AI coding tools.
Copilot and similar tools can output verbatim open-source licensed code. Duplication detection filters reduce but do not eliminate this risk. The filter must be explicitly enabled in enterprise settings.
4.4
Your AI tool usage policy explicitly prohibits inputting client IP, trade secrets, or proprietary algorithms into external LLM prompts.
Developers regularly paste proprietary algorithms or client-sensitive logic into public LLM interfaces for debugging. This is a contractual breach risk in most enterprise engagements.
4.5
Legal has reviewed and signed off on the organisation's AI tool selection from an IP risk perspective.
Many engineering teams deploy AI tools without legal review. A formal sign-off creates a defensible record and catches contractual conflicts before they become claims.
👁️

Human Oversight & Auditability

Maintaining meaningful human control and audit trails across AI-assisted decision making and delivery

0 / 5
5.1
Every AI-assisted production deployment requires human review and sign-off. No fully autonomous AI-to-production pipelines exist without an override mechanism.
Fully autonomous AI deployment is a red line for enterprise buyers and insurers. Human-in-the-loop at the deployment gate is the minimum acceptable standard.
5.2
AI system decisions or outputs that affect individuals are logged with sufficient context to be explainable in a post-incident review.
Transparency and explainability obligations depend on the processing context. ICO guidance addresses data-protection compliance for AI processing personal data; NIST treats explainability and interpretability as trustworthiness characteristics within a voluntary framework.
5.3
Model performance and output quality is monitored in production with alerting on drift, degradation, or anomalous output patterns.
LLM behaviour changes with model updates and prompt drift. Production monitoring must catch degradation before it surfaces as a client incident.
5.4
A documented rollback or override procedure exists for any AI system that can be triggered without requiring a full deployment cycle.
Enterprise buyers will ask how quickly you can disable or revert an AI system if it produces harmful or incorrect outputs. The answer must be documented and tested.
5.5
AI tool usage activity logs are retained for a defined period and accessible to security and compliance teams.
Where telemetry is used for governance or assurance, define what is collected, who can access it, its legal basis, and a proportionate retention period. Do not retain logs indefinitely by default.
📚

AI Literacy & Team Readiness

Ensuring your engineering organisation can use AI tools safely, effectively, and responsibly

0 / 5
6.1
All engineering staff using AI tools have received role-appropriate training covering capabilities, limitations, and responsible use policies.
Effective AI literacy should reflect the tools, roles and risks in scope: hallucinations, insecure code generation, data handling and over-reliance. Generic awareness alone is unlikely to change engineering behaviour.
6.2
Training records and competency assessments are documented and available to demonstrate compliance to enterprise buyers or auditors.
"We did a session" is not auditable. You need attendance records, materials, and evidence of completion, especially if you're selling to US federal contractors or UK regulated entities.
6.3
AI literacy training is included in new hire onboarding for all roles that will interact with AI tools in the course of their work.
Ensures governance coverage scales with headcount. Teams that add headcount without updating onboarding are creating ongoing compliance gaps.
6.4
Refresher training is scheduled at least annually and updated when new AI tools or significant model updates are deployed.
AI risks evolve rapidly with model updates. A training programme that was accurate in 2024 may miss material risks introduced by agentic capabilities in 2025–26.
6.5
Leadership and board-level stakeholders have received a briefing on AI risk, governance obligations, and the organisation's current posture.
Board-level AI awareness is increasingly expected by investors, insurers, and enterprise clients. A documented briefing protects directors and enables informed governance decisions.
🔗

Vendor Risk & Lock-in Management

Evaluating and managing the concentration risk and exit costs of your AI tool stack

0 / 5
7.1
A formal vendor evaluation framework exists for AI tool procurement, covering security, data handling, SLA, financial stability, and exit terms.
AI vendor consolidation is accelerating. Teams that adopted tools based on capability alone without evaluating exit terms face significant switching costs and potential service interruption.
7.2
LLM API dependencies in production systems have been abstracted via a model routing layer or SDK to enable provider switching without re-engineering.
Direct integration with a single LLM provider's API creates hard lock-in. Abstractions (LangChain, Portkey, custom routing layers) allow model substitution as the market evolves.
7.3
The total cost of replacing or removing each critical AI tool has been estimated and reviewed by engineering and finance leadership.
Lock-in risk is more than contractual. It includes codebase dependency, institutional knowledge, and re-training time. Estimating exit cost surfaces the real risk exposure.
7.4
AI vendor sub-processor lists have been reviewed to confirm no unexpected fourth parties process your data.
Review the vendor’s sub-processors, locations and change-notification terms against your data-processing agreement and applicable data-protection responsibilities.
7.5
AI tool security certifications (SOC 2 Type II, ISO 27001, CSA STAR) have been obtained and are reviewed annually at contract renewal.
Vendor certifications lapse, scope changes, and exceptions accrue. Annual review at contract renewal is the minimum standard for enterprise procurement hygiene.
🚨

AI Incident Response Readiness

Being operationally prepared to detect, contain, and communicate AI-specific security and quality incidents

0 / 5
8.1
Your existing incident response plan has been updated to include AI-specific incident categories: prompt injection, model poisoning, IP leakage, and AI-generated vulnerability deployment.
Extend the existing incident process for AI-specific signals such as prompt injection, unsafe agent actions, model or retrieval drift, and sensitive-context disclosure.
8.2
A documented procedure exists for notifying affected clients if an AI-generated code defect reaches production in their environment.
UK GDPR Article 33 and US state breach notification laws may be triggered by AI incidents involving personal data. The notification procedure must be tested, not theoretical.
8.3
A tabletop exercise or incident simulation covering an AI-specific scenario has been conducted in the last 12 months.
Incident response plans that have never been tested are plans, not capabilities. A tabletop exercise surfaces gaps in ownership, communication, and tooling before a real incident does.
8.4
AI vendor SLAs and breach notification obligations are documented, so you know how quickly each vendor must notify you of a security incident involving your data.
A notifiable personal data breach generally must be reported to the ICO without undue delay and, where feasible, within 72 hours of awareness. Vendor notification terms should leave enough time to assess the incident and meet any applicable reporting duty.
8.5
Post-incident review processes for AI incidents include root cause analysis of the governance or process failure, not just the technical remediation.
AI incidents rarely have purely technical root causes. Governance gaps, training failures, and process omissions are typically contributing factors. Reviews that only address the technical layer will see recurrence.

What does your score mean?

0–14 / 40: High exposure. Your answers indicate material governance gaps that warrant prioritised review. Read the 2-page assessment outline to see whether the Transformation Assessment fits the wider delivery problem.

15–27 / 40: Partial posture. Core controls exist but significant gaps remain. A targeted remediation programme can close these efficiently without disrupting delivery velocity.

28–40 / 40: Strong posture. You have a documented, defensible governance posture. A gap review and board-level narrative may still be valuable before your next enterprise procurement cycle.

Framework status and primary references

This is a practical self-assessment, not legal advice, an audit opinion, or a certification. Requirements vary by use case, sector, data and jurisdiction. Primary references reviewed in August 2026: NIST AI RMF (NIST notes that 1.0 is under revision), OWASP GenAI LLM Top 10 2026, ICO guidance on AI and data protection, and ICO breach-reporting guidance.