AI governance became urgent for most organisations not through regulation but through procurement. Customers started asking what AI you use, what data leaves your boundary, and whether their information trains a model — and most companies could not answer. Regulation and standards then arrived on top.
What an AI governance programme contains
- An inventory of AI systems — including features embedded in tools you already own, which is where most of it hides.
- Risk classification proportionate to consequence, not to technical sophistication.
- Data flow clarity — what leaves your boundary, to whom, under what terms, and whether it may be used for training.
- Lawful basis and transparency where personal data is involved.
- Evaluation before and after release — including adversarial testing, not just accuracy.
- Human oversight proportionate to consequence, documented.
- Monitoring for drift and misuse, with a route to disable a feature quickly.
- Supplier assessment for AI vendors and AI features inside existing suppliers.
The inventory is always the hardest step and always underestimated. AI is now embedded in support tools, CRMs, note-takers, developer tooling and browser extensions — and most of it arrived without a procurement decision.
ISO 42001 and the EU AI Act are different instruments
- ISO/IEC 42001 is a certifiable management system standard — the AI equivalent of ISO 27001. It gives you structure, governance and auditability, and maps cleanly onto an existing ISMS rather than requiring a parallel programme. It is voluntary, and increasingly requested commercially.
- The EU AI Act is legislation with a risk-tiered structure and obligations that fall differently on providers and deployers. It is not something you certify against in the same sense; it is something you comply with.
They are complementary: the management system is a credible way to organise and evidence the compliance work, but holding a certificate does not discharge a legal obligation.
Govern AI alongside everything else
GRC Copilot assesses AI systems against ISO 42001 and your existing frameworks together — one control library, one evidence base, no separate AI spreadsheet.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
The security dimension is architectural
AI systems introduce failure modes that policy cannot address. The defining one: a language model receives instructions and data through the same channel, so content it processes on a user's behalf — a document, a web page, a ticket — can carry instructions. Filtering helps at the margins and is not a boundary.
The controls that hold are architectural: enforce authorisation in the tool layer against the end user rather than in the prompt, require human confirmation for consequential actions, keep tools narrow and typed, and treat model output as untrusted input to whatever renders or executes it.
Shadow AI
The practical governance problem in most organisations is not the AI programme you approved — it is the tools staff adopted individually. Blanket prohibition reliably fails and drives usage out of sight. What works is a sanctioned path that is genuinely easier than the unsanctioned one, plus visibility through expense analysis, identity logs and integration governance in your major platforms.
Answering the customer questionnaire
AI questions now appear in most enterprise security reviews. Be specific: which providers you use, what data leaves your boundary, whether it may be used for training, retention, human oversight, and how you test. Vague reassurance now reads as an absence of governance, and it is increasingly a deal blocker rather than a footnote.
Where to start
Inventory first — you cannot classify, assess or answer anything without it. Then classify by consequence, close the highest-risk data flows, and adopt a management system structure once you know what you are governing. Buying a framework before the inventory produces governance for a landscape you have not mapped.
Detailed guidance
AI & Automation
- Adapting your risk assessment for AI systems — Your existing risk methodology was built for systems that fail predictably. What changes for AI - new risk categories, impact on people rath…
- AI for compliance: what it does well, and what it should never do alone — Where artificial intelligence genuinely helps compliance teams - control mapping, evidence analysis, gap detection and questionnaire respons…
- AI incident response: when the model is the problem — Traditional incident response assumes an attacker. AI incidents often have none - the system worked as built and produced harm anyway. What…
- Assessing AI vendors: the questions standard due diligence misses — Your existing vendor questionnaire was not written for AI. The additional questions that matter - training data, retention, model changes, h…
- Deepfakes and voice cloning: verification processes that survive them — Synthetic voice and video have made impersonation cheap and convincing. The defence is not detection technology - it is verification process…
- Governing AI agents: autonomy is a control decision, not a feature — An agent that can act rather than answer changes the risk entirely. How to decide what an agent may do unsupervised, contain the blast radiu…
- How AI accelerates compliance: where the weeks actually disappear — The specific compliance tasks where AI removes the most time - cross-framework mapping, evidence review, questionnaire response, gap analysi…
- Securing LLM applications: prompt injection is an architecture problem — You cannot filter your way out of prompt injection, because the model cannot reliably separate instructions from data. What that means for r…
- Shadow AI: governing the AI your staff are already using — Your people adopted AI tools before your policy existed. How to discover what is in use, decide what to allow, and govern it without driving…
- Sovereign AI: using AI for compliance without exporting your data — Compliance data is exactly the data you cannot casually send to a third-party model. How to use AI for GRC while meeting residency and confi…
- The AI questions buyers now ask - and how to answer them — Security questionnaires have grown an AI section. What enterprise buyers are asking about your use of AI, why vague answers stall deals, and…
- Why AI for compliance must be grounded in your evidence — An AI that answers compliance questions from general knowledge is a liability. Why retrieval-grounded output is the only audit-defensible ap…
Frequently asked questions
Do we need ISO 42001?
Not legally. It is worth it when customers ask for AI assurance, or when you need a defensible structure for governing AI at scale. It maps onto an existing ISO 27001 programme rather than duplicating it.
Does the EU AI Act apply to us outside the EU?
It can, depending on whether your system is placed on the EU market or its output is used there. Determine your role — provider or deployer — before assessing obligations, as they differ substantially.
Can we just ban AI tools?
You can, and usage will continue out of sight. A sanctioned, easier path plus visibility achieves more than prohibition.
Is self-hosting a model safer?
It addresses data residency and third-party exposure. It does nothing for prompt injection, excessive agency or output handling, which are application-layer problems.
What do customers ask most often?
Whether their data trains a model, which sub-processors are involved, and what human oversight exists. Have precise answers ready — these three account for most of the questions.
Key takeaways
- Procurement pressure, not regulation, is what makes AI governance urgent for most companies.
- The inventory is the hardest step — most AI arrived embedded in tools you already had.
- ISO 42001 structures the work; it does not discharge legal obligations.
- Prompt injection is an architecture constraint — limit what the model can do.