When AI adoption accelerates, the instinct is to write a new AI governance framework. A new committee, a new policy set, a new register, a new set of controls. Within a year there are two parallel programmes: the established information security management system, and an AI framework that few people maintain and fewer follow.
There is a better route. Most AI risk is an extension of risks the organization already manages: data protection, third-party risk, access control, change management and incident response. An integrated framework adds what is genuinely new about AI to the programme you already run, rather than building a second one beside it.
Why not a separate framework
- Duplication. Two risk registers, two sets of owners, two audits, and the same teams asked for evidence twice.
- Drift. A standalone AI framework is usually written once and rarely updated, so it falls out of step with both the technology and the rest of the controls.
- Gaps at the seams. AI incidents are also security, privacy and supplier incidents. Separate frameworks leave nobody responsible for the overlap.
- Weak adoption. Business teams already know how to request access, review a vendor and report an incident. A new process to learn is a new reason to bypass it.
What is actually new about AI
Integration does not mean pretending nothing changes. AI introduces risks that existing controls do not fully cover, and the framework has to name them:
- Data leakage through prompts, training data and connected tools.
- Unreliable output: fabricated or biased results being used in decisions.
- New attack paths, including prompt injection, model manipulation and over-permissioned agents.
- Dependence on third-party models, with limited visibility into how they are built and changed.
- Unapproved use. Employees adopt tools faster than governance can review them.
- Regulatory exposure, notably the EU AI Act, which phases in obligations by risk category over several years. Check the current timetable for your use cases.
Build on the standards you already use
You do not need to invent the structure. Three reference points fit together well.
- ISO/IEC 27001 and the NIST Cybersecurity Framework give you the management system, the risk process and the control baseline.
- ISO/IEC 42001, the AI management system standard, follows the same high-level structure as ISO 27001 and other management system standards, so its requirements can be added to an existing system instead of running beside it.
- The NIST AI Risk Management Framework offers a practical vocabulary, organized around Govern, Map, Measure and Manage, for identifying and handling AI-specific risk.
The principle is the same as in any integrated programme: map each control once, then show which requirements it satisfies. One control library, many frameworks.
The building blocks
Governance. Assign executive accountability for AI risk, and place it inside the existing risk and security governance rather than a separate body. Define the roles: business owner, system owner, risk and compliance, security, privacy, legal.
Inventory and classification. Extend the asset register to cover AI systems, models, datasets and AI features embedded in approved software. Classify each by purpose, data sensitivity and impact on people, since the risk and any regulatory category depend on how the system is used.
Risk assessment. Add AI-specific risk scenarios to the existing methodology, and require an assessment before a new AI use case goes live. Scale the depth of review to the risk, so low-risk uses are quick to approve.
Policy and acceptable use. One short, clear AI usage policy: what is allowed, what data may never be entered, which tools are approved, and how to request a new one.
Third-party and supply chain. Extend vendor due diligence with AI questions: training on customer data, data location, model change notification, incident reporting and audit rights.
Technical controls. Identity and access for AI tools and agents, data loss prevention, logging, secure development and testing for AI features, and monitoring for misuse.
Assurance and incident response. Include AI in internal audit scope, add AI scenarios to incident playbooks and tabletop exercises, and define how errors and harmful outputs are reported and corrected.
Make it usable
- A fast lane. Pre-approve common low-risk uses and tools so people have a sanctioned route that is faster than going around the process.
- A single intake. One form and one queue for new AI requests, routed to security, privacy and legal in parallel.
- Clear ownership. Every AI system has a named owner who answers for its use, data and performance.
- Training. Short, role-based guidance on what is safe to share and how to check AI output.
Measure whether it works
A framework you cannot measure becomes shelfware. Useful indicators include the percentage of AI systems in the register with a completed risk assessment, the time to approve a low-risk request, the number of unapproved tools discovered and brought under governance, vendor assessments completed, and AI-related incidents and near misses. Review them in the same forum as your other security and risk metrics.
A sensible order of work
- First 30 days: agree ownership, publish a short AI usage policy, and start discovery of the AI already in use.
- Next 60 days: build the AI inventory, add AI scenarios to the risk method, and stand up the intake and fast lane.
- Following quarter: extend vendor due diligence, map controls to the frameworks that apply to you, and bring AI into internal audit and incident exercises.
The goal is an AI control framework that nobody has to remember is separate, because it is simply part of how the organization manages risk. That is easier to maintain, easier to audit, and far more likely to be followed.
If you would like help integrating AI governance into an existing ISO 27001 or NIST CSF programme, get in touch through the consultation form.