AI governance usually lands on legal and compliance desks first, and that's a mistake. Most of what the emerging frameworks actually require — knowing what models you run, what data feeds them, who can override them, and what happens when something goes wrong — is security tooling and process, not policy writing. This is a practitioner's view of what to build, not a legal summary of what to read.
Why This Is a Security Problem
Every major AI governance framework converges on the same four questions: What AI systems do you have? What can go wrong with them? How would you know if it did? What do you do when it does? That's an asset inventory, a risk register, a detection capability, and an incident response plan — the same four things security teams already own for every other class of system. AI just adds new failure modes (hallucination, bias, prompt injection, model drift) on top of the familiar ones (data exposure, unauthorized access, availability).
The EU AI Act: Risk Tiers, Not a Single Standard
The AI Act doesn't regulate AI uniformly — it sorts systems into risk tiers and scales obligations accordingly. For a security team, the practical question for every AI system in scope is: which tier does this fall into, and what does that tier require of us?
- Unacceptable risk — banned outright (e.g. social scoring, certain biometric categorisation). Rare in enterprise contexts, but worth explicitly ruling out for novel use cases.
- High risk — systems used in things like employment decisions, credit scoring, critical infrastructure, or law enforcement. These carry the heaviest obligations: risk management systems, data governance, technical documentation, human oversight, logging, and conformity assessment.
- Limited risk — mainly transparency obligations. Chatbots and generative AI tools generally land here: users need to know they're interacting with AI, and certain content needs to be labelled as AI-generated.
- Minimal risk — the majority of AI applications (spam filters, recommendation engines). No specific legal obligations beyond existing law, though voluntary codes of conduct apply.
What security teams actually do with this: build a classification process for every internal AI deployment — not just customer-facing ones — and route high-risk systems into a heavier review gate before launch, the same way you'd gate a system touching regulated data.
NIST AI RMF: Four Functions You Can Actually Operationalize
Where the EU AI Act sets legal obligations, the NIST AI Risk Management Framework gives you a process model that maps cleanly onto existing security operations. It has four functions:
Govern
Policies, accountability, and culture — who owns AI risk decisions, and what's the escalation path when a model behaves unexpectedly. In practice: an AI risk owner with actual authority to block a launch, not just a committee that reviews after the fact.
Map
Context and inventory — what AI systems exist, what they're used for, what data they touch, and what could go wrong with each one. This is the part most organisations skip, and it's the part that makes everything else possible. You cannot govern, measure, or manage risk in systems you haven't catalogued.
Measure
Testing and metrics — red teaming for adversarial robustness, bias testing, accuracy benchmarks, and ongoing monitoring for drift. This is where AI red teaming and traditional security testing overlap directly: the same instinct that drives a penetration test drives an AI red team engagement.
Manage
Response and continuous improvement — incident response specifically scoped for AI failure modes (a model leaking training data, a jailbreak in production, a biased decision at scale), with defined severity levels and remediation paths.
A Practical Checklist
If you're starting from nothing, this is the order that produces the fastest risk reduction:
- Build the model inventory first. Every model and AI-integrated feature in production or development, who owns it, what data it touches, and what it's allowed to do. You cannot do anything else on this list without this.
- Classify by risk tier. Map each inventoried system against the EU AI Act tiers (or an equivalent internal scale) regardless of whether you have EU exposure — the tiering logic is useful even where the law doesn't apply.
- Define human oversight points. For anything high-risk or agentic, identify exactly where a human can intervene before consequential action — and make sure that checkpoint isn't theatre (see: excessive agency in the OWASP LLM Top 10).
- Instrument logging and monitoring for model inputs, outputs, and actions — the same way you'd instrument any production system, with retention sufficient to support an incident investigation.
- Write the AI-specific incident response runbook. Prompt injection, model data leakage, and adversarial manipulation need playbooks distinct from a standard breach response — different evidence to collect, different stakeholders to notify.
- Red team before launch, not after. Adversarial testing belongs in the release gate, not as a post-incident afterthought.
Where ISO/IEC 42001 Fits
ISO/IEC 42001 is the management-system standard for AI — the AI equivalent of ISO 27001 for information security. If your organisation is already ISO 27001 certified, 42001 will feel familiar: it's a Plan-Do-Check-Act cycle applied to an AI management system rather than an information security management system, and the two can share infrastructure (risk registers, internal audit processes, management review cadence). It's worth treating as an extension of an existing ISMS rather than a parallel programme.
The Honest Take
None of these frameworks are complete on their own, and none of them will catch a sophisticated prompt injection or a subtly poisoned fine-tuning dataset by themselves. What they're good for is forcing the inventory and ownership questions that most organisations have been avoiding since they quietly shipped their first internal chatbot. Compliance is the byproduct. The actual goal — knowing what AI you're running and what it can do — is just good security hygiene with a regulatory deadline attached.
Resources and Further Reading
- EU AI Act (official text): artificialintelligenceact.eu
- NIST AI Risk Management Framework: nist.gov/itl/ai-risk-management-framework
- ISO/IEC 42001: iso.org/standard/81230.html
- MITRE ATLAS: atlas.mitre.org