AI Governance Framework: 10 Questions to Ask in 2026

If you have built AI, bought it, or simply let your team loose on it, three things are now coming for you: a breach, a regulator, or a lawsuit. In IBM's Cost of a Data Breach Report 2026, 43% of the breached organisations studied reported a shadow AI incident, meaning AI nobody in security approved. A year earlier it was 20%. It more than doubled in twelve months.

I have spent 30 years auditing systems for organisations like Microsoft, Cisco, BP, Vodafone and VISA, and AI is the most under-secured technology I see businesses running today. The good news is that the fix is not exotic. Most of the risk collapses into ten questions, and you can answer all ten with a spreadsheet and a fortnight of attention.

This is the AI governance framework I use, ordered so the questions that stop live attacks come first and the ones that stop fines come last. For each you get what to do this week, what a good answer sounds like, and what a bad answer sounds like, because the bad answers are the ones people say out loud without realising they have just failed the audit.

Three Things People Mean by “AI Governance”

Before the ten questions, one distinction that saves a lot of wasted effort. I teach this in our AI-driven engineering workshops because I keep watching people get it confused, and the confusion is expensive.

“AI governance” is doing three different jobs:

This article is mostly the third one. The ten questions are aimed at AI that is live, or close enough to live that the decisions are already made, where your customers are exposed to it and not only you.

Worth being precise about that, because it changes what you can do with the answers. Every question below assumes there is a running system to point at: an application to try to break, accounts to enumerate, decisions to pull, a model whose training data you now have to reconstruct. You can absolutely read this before you build, and you should, because knowing what you will be asked shapes what you build. But these are audit questions. They are asked of something that exists.

Two of them deliberately reach back into the first. Question 3 asks what AI your staff signed up for without telling anyone, and Question 2 uses a flaw in an internal assistant as its worked example. That is not the framework losing its footing. It is the honest observation that the tool your team adopted last Tuesday becomes the thing you ship the moment it touches a customer, and the register you build in Question 3 is the only place that transition is visible. Where a question crosses layers, I say so.

The reason the blur matters is that each layer gives false comfort about the others. A locked-down agent can still ship un-reviewed architecture. A flawless development process does not stop your assistant deleting a production database. And if someone tells you their company has an “AI governance committee”, that is usually a fourth thing again: a policy about employees using AI at work, which governs none of the three.

If you are unsure which regime applies to something you have built, the trigger is not how clever the system is. It is who is exposed to it. A personal tool with a blast radius of your own machine needs layer one. The moment colleagues depend on it daily, add change control. The moment customers touch it, you are in layer three and everything below applies.

Why These Ten, and In This Order

The ordering is deliberate and it is not the order most frameworks use.

Most governance material starts with policy, ownership and regulatory mapping, because that is how compliance documents are structured. I start with prompt injection and access control, because those are what attackers are exploiting this quarter. If your AI is compromised next Tuesday, a signed RACI will not help you. If it is fined next year, you will have had months of warning.

So: questions one to five are the live-fire ones. Six and seven are what happens when it goes wrong and where it came from. Eight, nine and ten are accountability, fairness and law, the ones with the longest fuses and the biggest eventual bills.

Work them in order if you are starting from nothing. If you already have a security function, jump to Question 3, because an inventory is the thing almost nobody has and everything else depends on.

Q1: How Do You Defend Against Prompt Injection?

Prompt injection is LLM01, the number one entry in OWASP's Top 10 for LLM Applications, and it held that position in the 2026 revision published this month. Land one and an attacker can leak your data, execute commands on your systems, and do real damage overnight.

Be careful what you promise yourself here. OWASP is explicit that no foolproof prevention for prompt injection is known, so the honest goal is not a wall but layers that shrink the blast radius: validate inputs, separate system prompts from user content, restrict which tools the model can call, require human approval for high-impact actions, and test adversarially. That stack is walked through step by step in our LLM security best practices guide. For the wider threat picture, we catalogue 23 distinct AI attack types.

Even perfect injection defences will not save you if everything on your network is reachable by everything else.

Q2: Who, and What, Can Your AI Access?

Of the organisations that suffered an AI-related breach in IBM's 2026 study, 92% lacked proper AI access controls, and only about four in ten limited access to their AI systems at all. When that goes wrong an attacker does not need to be clever. They walk in through a door you left open.

Microsoft 365 Copilot's EchoLeak vulnerability (CVE-2025-32711) showed the shape of it. Aim Labs demonstrated a zero-click chain: one email, no clicks from the victim, and information Copilot could reach across OneDrive, SharePoint and Teams was disclosed to the attacker. Microsoft rated it 9.3 critical and fixed it server-side before disclosure, with no evidence of exploitation in the wild. (NVD scores the same flaw 7.5, which is a useful reminder that a single CVSS number is an opinion, not a measurement.)

Treat AI agents as identities in their own right. They hold credentials and act on systems, so they need their own policies rather than inheriting a human's. This is where most organisations are weakest. We looked at why only 21% have real control over their AI agents, against 97 million monthly MCP SDK downloads and 30-plus CVEs. That piece is written about the agents working for you, layer one, but the authorisation problem it describes is identical the moment an agent sits inside something you ship: proving who an agent is has largely been solved, and deciding what it may do has not.

Access control is layers, not a switch. Permissions decide which tools the agent can reach at all; hooks block specific dangerous calls; scope rules bound each task; an egress firewall governs what leaves the box. The discipline that makes it hold is that every layer reads the same decision and fails closed on anything it cannot parse. A disagreement between two layers is not redundancy, it is a bypass.

Access controls only protect the AI you know about. Most companies do not know what they are running.

Free download

The 10 questions, expanded into 50 you can actually audit.

Every sub-question with what good looks like, how to fix a bad answer, and the authoritative source. Mapped to OWASP, NIST AI RMF, ISO 42001 and MITRE ATLAS.

Send me the playbook →

Free. No payment, no course required.

Q3: Do You Have a Shadow AI Inventory?

This is the number that moved most this year. 43% of the breached organisations IBM studied in 2026 reported a shadow AI incident, up from 20% the year before. More than two-thirds had no governance process to limit it. The denominator matters and is widely misquoted: that is 43% of organisations that were breached, not 43% of all breaches and not 43% of all companies. (We keep every shadow AI statistic traced back to its publisher, including the widely repeated ones that do not hold up.)

An inventory is the foundation every other question stands on. You cannot apply an access control, a guardrail or a monitoring rule to a tool you do not know exists.

This is the question that most obviously crosses the layers, and deliberately so. An employee expensing a transcription tool is a first-layer problem right up until that tool is summarising customer calls inside a workflow you support, at which point it is part of what you ship and nobody wrote it down. The register is where that transition becomes visible, which is why it belongs here rather than in an acceptable-use policy.

Because this is the question people most often get wrong, here is the whole thing: all five sub-questions from the Playbook, with the fixes. The other nine questions have five each as well.

That last one is the one I would do first. A survey finds what people are willing to tell you; the expense report finds what they forgot to mention.

Once you know what you are running, the question becomes what to do about it. We tested the free and commercial options and ranked what actually reduces shadow AI risk. The answer is less about blocking tools than most vendors would like.

Now you know what you have. The next question is what is coming out of it.

Q4: What Are Your Output Guardrails, and How Do You Know the Answer Is Right?

If I could make you do one thing on this entire list, it would be the kill switch. Everything else reduces the chance of an incident. The kill switch is the only control that limits how long one lasts.

The Playbook puts it more bluntly than I would have: if you cannot take the AI offline within five minutes, you do not have a kill switch. You have a wish.

Without output guardrails your AI can leak customer data, invent commitments you are then held to, or humiliate your brand publicly. DPD's chatbot called the company “the worst delivery firm in the world” and wrote a poem about its own incompetence. The BBC ran it. That took one bored customer and five minutes.

One trap worth naming, because it is the one engineers miss: if your AI's output is consumed by another system (a database query, a shell command, rendered HTML) treat it as untrusted input and sanitise it. Otherwise prompt injection quietly becomes SQL injection.

The Half of This Question Everyone Skips

Everything so far is the safe half: stopping the AI doing damage. There is a second half, and it fails completely differently. The correct half asks whether the output is actually true, and it fails by being confidently wrong.

Air Canada again, but for a different lesson than the one in Q8: there the point was who carries the liability, here it is what produced it. The chatbot leaked nothing and broke no permission. It got the refund procedure wrong, sounded certain, and the tribunal made the airline honour it. A model that leaks data fails loudly and somebody notices. A model that is confidently wrong fails quietly, in your brand voice, to a customer who believes it.

Permission guards stop damage. Only verification stops confidently wrong, and that is the half almost everyone leaves as a filter bolted on at the end.

Why You Cannot Ask the Model to Check Itself

The instinct is to have the AI review its own answer. It does not work. A DeepMind and University of Illinois team put it in the title of the paper: large language models cannot self-correct reasoning yet, finding that performance sometimes degrades after self-correction. What works is independent checking. Cohere found a panel of diverse evaluator models beats a single large judge while costing roughly seven times less.

So the rule to build around: the thing that did the work never grades the work.

The Failure That Passes Every Automated Check

Here is the one that should worry you, because tooling will not catch it. Your knowledge base says a decision is made case by case. Your AI answers “that should be fine.” It has contradicted nothing, so a faithfulness metric passes it by construction, and you have just made a commitment nobody authorised.

Nobody's chatbot announces a fabricated refund policy in bold. It softens a deferral into an assurance, and the customer hears a commitment. I went looking for this properly: of eight AI red teaming tools I installed and ran, only two could even test that class of failure. The other six test the attack surface, which is a different question entirely.

That article is the full treatment of this bonus question, including what happened when I turned the method on my own responder and measured the same question across fresh sessions before and after each fix. The honest headline: the first fix moved it from zero out of five to one out of five. If you are answering this eleventh question seriously, start there.

The Three Controls Worth Building

The control patterns underneath this, the hooks, gates, verification and recovery, are set out in AI guardrails: how to build AI you can trust. It is written from governing my own agents, so read it as patterns to port rather than a customer-facing playbook: the prevent, detect, respond and recover structure transfers directly, the specific rules will not. If you want a runtime guardrail in the request path specifically, we walked through NVIDIA's NeMo Guardrails, including the 404 that stops most setups.

A kill switch only helps if somebody notices in time to press it.

Q5: Are You Monitoring and Logging AI Prompts?

You cannot react to what you cannot see, and AI breaches hide well. Of the organisations that suffered an AI-related incident, 68% had no policy overseeing AI use or shadow AI at all, which means no logging requirement, no alerting, and no trail to investigate with. The year before it was 63%, so the gap widened while shadow AI incidents doubled.

Monitoring catches what reaches production. To find the failures before they get there, we tested eight AI red teaming tools hands-on, including the failure class almost none of them check for.

Monitoring tells you something has gone wrong. Then what?

Q6: Do You Have an AI-Specific Incident Response Plan?

In Pacific AI's 2025 governance survey of 351 organisations, only 54% kept an incident response playbook for AI-specific risks. That matters because AI compromise does not behave like the incidents your plan was written for. Restoring the model from backup may not clear it, because the corruption often is not in the weights at all: it can sit in saved memory, a vector store or a cached retrieval index that your restore never touches.

Security researcher Johann Rehberger demonstrated this on Google Gemini in February 2025, poisoning its long-term memory with a delayed tool-invocation technique. A poisoned document planted a false memory that survived across later sessions until a user spotted it and deleted it by hand. Restarting the chat does not clear it.

Your plan will fail fast if the compromise arrived inside a component you did not build.

Q7: How Secure Is Your AI Supply Chain?

In Harness's 2025 survey of 500 security practitioners, 62% said they had no visibility into where LLMs were in use across their organisation. Every AI vendor you use is part of your attack surface, and if your vendor leaks, you leak.

In 2024 researchers tested more than 200 Custom GPTs and extracted system prompts and uploaded knowledge files from them, in many cases by little more than asking the model to repeat what came before. No exploit, no tooling. If your vendor's configuration is one well-phrased question away from being public, so is anything you put in it.

If you are choosing what to bring in rather than auditing what you already have, our map of the AI security tool landscape is searchable by category: pentest and red-team agents, LLM guardrails, agent and MCP security.

Vendor vetting is technical work, and technical work does not happen when nobody owns it.

Free download

The 10 questions, expanded into 50 you can actually audit.

Every sub-question with what good looks like, how to fix a bad answer, and the authoritative source. Mapped to OWASP, NIST AI RMF, ISO 42001 and MITRE ATLAS.

Send me the playbook →

Free. No payment, no course required.

Q8: Who Owns AI Risk, and Who Can Override the Machine?

When AI causes harm, nobody in the resulting legal process cares that ownership was unclear. Air Canada discovered this when its chatbot invented a bereavement refund policy that did not exist. Its defence, as the British Columbia Civil Resolution Tribunal characterised it, was that the chatbot was in effect a separate legal entity responsible for its own actions. The tribunal rejected that in February 2024 and ordered the airline to pay.

There is now a regulatory version of the same requirement: EU AI Act Article 14 requires high-risk AI to be designed so a human can step in and stop it.

Ownership is the foundation. It does not help if nobody can explain what the AI actually did.

Q9: Do You Test for Bias and Explainability?

AI hiring tools are facing lawsuits and enforcement now, not eventually. The EEOC's first AI hiring discrimination settlement landed in 2023, when iTutorGroup paid $365,000 over software the agency said automatically rejected more than 200 applicants using age cut-offs of 55 for women and 60 for men. Note what that means: nobody set out to build a discriminatory system, and the cut-offs were sitting in the configuration in plain sight.

The legal hook is narrower than most summaries suggest, so it is worth stating precisely. GDPR Article 22 gives a qualified right not to be subject to decisions based solely on automated processing where those decisions have legal or similarly significant effects. The right to meaningful information about the logic involved comes from Articles 13, 14 and 15 read alongside it. So this does not apply to every AI-assisted decision, but where it does apply, “the model decided” is not an answer you can give.

Bias and explainability are compliance questions, and compliance is where the fines live.

Q10: Are You Compliant With the EU AI Act and GDPR?

This one changed while the video was still current, and it changed in the direction most coverage still gets wrong. On 2 August 2026 the European Commission began enforcing the AI Act, and the Article 50 transparency obligations started to apply: chatbots must tell users they are AI, and AI-generated or altered content must be labelled with machine-readable marks.

What did not land that day is the high-risk regime. A simplification package pushed those back, so under the Commission's own implementation timeline the rules for Annex III high-risk systems apply from 2 December 2027, and high-risk AI embedded in regulated products under Annex I from 2 August 2028. Plenty of articles still say August 2026. They are working from a timeline that predates the amendment.

That extra runway is not a reason to stop reading. Penalties have been enforceable since August 2025, and under Article 99 they reach €35 million or 7% of worldwide annual turnover for prohibited practices, with lower tiers below. The prohibitions and the GPAI rules are already live. What you have gained is time to classify your systems before the high-risk obligations bite, not permission to skip it.

Alongside it: New York City's Local Law 144 already bites. If you use an automated employment decision tool that substantially assists or replaces discretionary hiring or promotion decisions for a role in NYC, you need a bias audit from the past year, the results published, and candidate notices given. Running the audit alone is not compliance. And if your model was trained on personal data without a lawful basis under GDPR Article 6, that is a separate fine on top.

The EU is not the only jurisdiction moving, and the picture differs sharply by region. We maintain a full breakdown of AI regulations around the world, covering the EU AI Act, US state laws, the UK and China, with what security teams actually have to do in each.

What Good Looks Like: Three Maturity Levels

The ten questions are pass/fail on the page, but real organisations sit somewhere on a curve. Roughly:

Honest caveat: moving up a level costs organisational will far more than it costs money. Every control on this page is cheap. Getting one named person to accept that their review depends on it is the expensive part.

If the person who ends up owning this is you, the credential side is worth a look. We ranked the best AI security certifications by cost, exam format and whether they actually map to real job requirements.

Which Standards This Maps To

The ten questions are not invented from nothing. They trace to four bodies of work, and if you are being audited these are the names that will come up:

The Playbook maps each of the fifty sub-questions to specific controls in each of these, which is the part that turns “we should do better on AI” into a defensible position.

Testing Any of This, This Week

Start from your own failure modes, not a scanner's catalogue. Write down what your AI must never do: quote a price it cannot verify, promise an outcome, agree to a policy that does not exist, speak for a decision that is someone else's to make. That list is your test suite and no tool ships with it.

Then run those cases as fixtures against your own guardrail rather than against the model, so a passing test means your layer held rather than the model happening to behave. Every confirmed failure becomes a permanent fixture. That is how correctness stops being a vibe and starts being a regression suite.

And the audit itself

This page gives you one move per question. The Playbook gives you fifty: every sub-question with what good looks like, how to fix a bad answer, the authoritative source, and status, owner and due-date columns so you can run it as a real audit rather than read it.

Send me the playbook →

Where to Start

Ten questions. Answer them all honestly and you are in a small minority. Remember that of the organisations breached through AI, 68% had no AI policy at all.

If ten feels like too many, start with four: the inventory (Q3), because nothing else works without it; the kill switch (Q4), because it is the only control that shortens an incident; logging (Q5), because it is the difference between knowing and guessing; and one named owner (Q8), because the other nine do not get done otherwise.

I would rather you did those four properly this month than all ten badly this week.

What This Looked Like When I Did It

I run an AI that answers inbound enquiries as StationX. It talks to strangers about money and careers, and it quotes a real price on a programme that costs thousands. That puts it squarely in layer three, and it is the reason I can tell you which parts of this list are genuinely hard.

Here is what actually got built, mapped to the questions above.

The kill switch (Q4) is a Redis flag, not a deploy. One command turns the AI off and every inbound message routes to a human inbox with the model never called. It had to be that fast, because the point of a kill switch is that you reach for it during an incident, and anything requiring an SSH session and a redeploy is a wish rather than a control.

One design decision I would repeat: the flag defaults to ON when missing. A wiped cache means the bot answers rather than going silent. That is deliberate (the switch is an override, not a heartbeat) but it has a consequence you have to build around. Testing a fresh deploy means disabling first, verifying with the bot silent, then enabling for a controlled window. Get that backwards once and your test messages go to real customers.

Output guardrails (Q4) are layered, and the deterministic layer catches what the model cannot. Any price the AI outputs must match a signed price table exactly or the reply is blocked before sending. Not “checked by the model”. Blocked, deterministically. On top of that a cheap fast model reviews each draft for over-promising, and a banned-phrase scan catches things like “guaranteed job”.

That price table is the single most valuable control in the stack, and it exists because of a specific failure. An early design let the owner maintain an allow-list of approved claims as substrings. An adversarial review killed it before it shipped: the substring approach let a one-word edit reintroduce a job guarantee. The fix was to make the money rule un-editable in code. A price not in the signed table always blocks, regardless of who wrote what in the config.

The prompt is the first control, not the whole stack. Early testing showed careful prompt grounding answered accurately even under deliberate baiting, and that result was a trap. It would have been easy to stop there. Production safety is layered by definition, because the prompt is the layer an attacker is talking to.

Injection surfaces expand quietly (Q1). When the email channel went live, the subject line became attacker-controlled input feeding straight into the untrusted-message slot. Nothing about the model changed; the attack surface grew because a channel was added. That is the argument for Q3's inventory in miniature. The thing you are governing is not static.

Monitoring is where I am honestly still behind (Q5). There is a command that surfaces inbound messages matching injection patterns, and it is a heuristic scan over logged content rather than a real audit table. It shows attempts that got logged. It does not yet show which guardrail fired and why, or output blocks where a draft was rejected before sending, because that decision trace is not persisted yet. A proper security-events table is the actual fix and it is on the list.

I am telling you the gap rather than the highlight reel, because every organisation answering these ten questions will find one like it. The useful question is not whether you have gaps. It is whether you know where they are and what the fix is.

The Next Layer: Building AI That Is Governable

One closing thought, and it is the thing I actually believe about where this goes.

These ten questions are how you govern AI that is already running, and they work. But you will have noticed how much easier some of them are to answer when the system was built with them in mind. A kill switch is trivial if someone designed a seam to cut; it is a project if nobody did. Provenance is a lookup if it was recorded at the time and an archaeology dig if it was not.

So the way to make this audit cheap is to move it upstream.

That is layer two from the top of this article: governing how the software gets built in the first place. Screen the risk before you start, frame whether it is worth doing, spike the riskiest unknown, build it properly, verify it is safe to ship, and gate the go/no-go decision. Speed where it is safe, rigour where it counts.

AI-driven engineering is how AI systems are going to be built. It will not retire this checklist. Monitoring, incident response, bias testing and your regulatory evidence are all obligations that begin at deployment and cannot be engineered away beforehand. What it changes is how many of these ten you answer by pointing at a design decision rather than by starting a project.

Frequently Asked Questions

About the Author

Nathan House, Founder & CEO of StationX

Nathan House has 30 years of hands-on cybersecurity experience and is Cambridge-educated, holding CISSP, CISA, CISM, OSCP, CEH, and SABSA. He founded StationX in 1999 — one of the UK’s first cybersecurity companies — and has secured £71 billion in UK mobile banking transactions and the London 2012 Olympics, advising clients including Microsoft, Cisco, BP, Vodafone, and VISA. He authored the world’s most popular cybersecurity course — a #1 Udemy bestseller taken by over 500,000 students — and was named Cyber Security Educator of the Year 2020, AI Security Educator of the Year, and a UK Top 25 Security Influencer 2025. A DEF CON speaker and featured expert on CNN, Fox News, NBC, and the BBC, Nathan leads StationX’s training of more than half a million students worldwide.