Executive Diagnostic

UK & US AI Governance Readiness Assessment

A 40-point diagnostic for engineering organisations deploying AI tools. Covers NIST AI RMF alignment, OWASP LLM Top 10 security controls, IP & copyright exposure, data governance, vendor risk, human oversight, AI literacy, and incident response. Calibrated for UK and US enterprise buyers and auditors.

Updated May 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 is the primary US federal and enterprise standard. UK enterprises aligning with US buyers increasingly need to demonstrate NIST AI RMF familiarity.
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.
Analogous to a DPO under UK GDPR. Does not need to be a dedicated role, but must be assigned, documented, and empowered to escalate.
🔒

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.
GitHub Copilot, Claude, and GPT-4 all have different data retention and training policies. UK GDPR and US CCPA require you to know and document this.
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 LLM Top 10

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.
OWASP LLM01. Prompt injection is the primary attack vector for agentic AI systems. Input validation, output sanitisation, and privilege separation are the minimum baseline.
3.2
Sensitive data and secrets are blocked from reaching LLM context windows via developer tooling or automated scanning.
OWASP LLM02 (Sensitive Information Disclosure). API keys, credentials, and PII in prompts are a leading cause of AI-related security incidents. Pre-commit hooks and IDE scanning are the standard mitigation.
3.3
AI-generated code is reviewed by SAST tooling calibrated for AI-specific vulnerability patterns before merge.
Standard SAST tools are not calibrated for AI-generated code patterns. AI-authored code has a 20–30% higher vulnerability rate and introduces specific CWE patterns (insecure defaults, over-permissive error handling) that require targeted rules.
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.
OWASP LLM03 (Supply Chain). Fine-tuned or third-party models may embed backdoors or biases. Model provenance documentation and integrity verification are required for SOC 2 AI addendums.
©️

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.
UK ICO guidance and NIST AI RMF both require explainability for AI systems affecting individuals. "The model decided" is not an acceptable audit response.
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.
GitHub Copilot Enterprise, AWS Bedrock, and Azure OpenAI all provide usage logs. These must be captured, retained, and accessible for audit. Define your retention period in writing.
📚

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.
Training must be specific to the tools deployed and the risks they introduce — hallucinations, insecure code generation, over-reliance. Generic "AI awareness" does not constitute sufficient AI literacy.
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 not just 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.
Major LLM providers use sub-processors for inference, logging, and safety filtering. UK GDPR and enterprise DPAs require these sub-processors to be disclosed and approved.
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.
AI incidents require different response playbooks than traditional security incidents. The detection signals, containment steps, and communication obligations differ materially.
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 — you know how quickly each vendor must notify you of a security incident involving your data.
Your client notification obligations run to 72 hours under UK GDPR. If your LLM vendor's notification SLA is longer, you have a structural compliance gap.
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 organisation has material governance gaps that present commercial, legal, and security risk. Book a discovery call to understand the priority remediation path.

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.