This article provides a practical structure you can adapt to your organisation's size, risk appetite and regulatory context. It is an editorial synthesis, not an official template from any standards body or regulator.
The useful test is simple: can a team follow a decision from request to assessment, approval, control, evidence and review? If ownership disappears between those steps, the organisation has principles, but it does not yet have a workable operating model.
What is an AI governance framework?
A governance framework is the operating model that sits above individual policies and procedures. It defines the boundaries within which decisions are made, the roles responsible for those decisions, and the evidence that shows the system is working.
The NIST AI Risk Management Framework 1.0 is voluntary, and NIST says version 1.0 is under revision. Its Core uses four continuous functions: Govern, Map, Measure and Manage, with Govern cross-cutting.
ISO/IEC 42001:2023 defines requirements for an organisation-wide AI management system, including establishment, implementation, maintenance and continual improvement. It is a standard, not law. ISO's own certification explanation says that external certification bodies perform certification rather than ISO itself.
The OECD AI Principles, updated in May 2024, provide a non-binding backdrop for lifecycle accountability, traceability and systematic risk management. They do not supply an implementation template or legal verdict.
No single framework is mandatory for every organisation. A practical framework synthesises elements from these sources and adapts them to local context, risk appetite and applicable requirements.
Start with the obligations that actually apply to the organisation, rather than adding a regulator's name to a generic checklist. Where the EU AI Act is relevant, for example, the analysis starts with territorial scope, the organisation's role, the system's classification and the applicable date in the consolidated Act. The European Commission's AI Act overview records phased application and time-sensitive dates. That does not make every AI use high-risk or every duty applicable to every organisation.
Framework, policy and management system: what changes?
These three terms are often used interchangeably, but they describe different layers of the same governance effort.
| Layer | What it is | Example |
|---|---|---|
| Framework | The operating model: roles, processes, artefacts and review cycles | Your organisation's AI governance structure |
| Policy | Approved rules and decision rights within the framework | All AI use cases require risk assessment before deployment |
| Management system | The full set of policies, procedures, records and improvement loops | An ISO/IEC 42001-aligned system |
A framework tells you what to build. A policy tells you what is required. A management system is the living collection of both, plus evidence and review.
Once that structure is clear, you can turn the operating model into a governance policy that states who may decide what, which minimum requirements apply and when a matter must be escalated.
The UK Government AI Playbook offers a useful public-sector implementation pattern: named ownership, a live inventory, lifecycle assessment, assurance, testing, escalation and change control. It was published in February 2025 for civil servants and government organisations; private organisations may adapt its ideas but should not present it as a universal obligation.
The components of a practical AI governance framework
The following map is an editorial synthesis requiring adaptation. Each component supports a specific decision and produces evidence that the system is operating.
| Component | Decision it supports | Accountable role | Working artefact | Evidence or review signal |
|---|---|---|---|---|
| Scope and principles | Which AI uses are in or out of scope | Executive sponsor | Scope statement, risk appetite | Scheduled and change-triggered review, change log |
| AI inventory | What systems and use cases exist | Governance coordinator | Living register | Completeness check, owner confirmation |
| Risk tiering | How to prioritise assessment effort | Risk owner | Tier definitions, criteria | Tier assignment records |
| Approval | Who can authorise a use case | Defined authority | Approval record, conditions | Approval log, exception register |
| Policies and procedures | What rules apply at each stage | Policy owner | Policy documents, SOPs | Version control, acknowledgement |
| Technical and organisational controls | How risks are treated | Technical owner, control owner | Control specifications, configurations | Control testing, evidence |
| Supplier oversight | Whether a provider is suitable | Procurement, security | Vendor assessment, contract | Reassessment triggers, change notices |
| Incidents | How problems are detected and resolved | Incident lead | Incident log, post-incident review | Incident metrics, recurrence |
| Monitoring | Whether controls and outcomes are on track | Governance coordinator | Dashboards, review minutes | KPI trends, audit findings |
| Improvement | How the framework evolves | Executive sponsor | Improvement plan, lessons learned | Framework version, review outcomes |
The NIST AI RMF Core supports documented requirements, risk tolerance, defined roles, executive accountability, inventories, impact documentation and third-party risk work. Meeting a selection of these outcomes does not prove compliance or effectiveness; they require tailoring to your context.
Read the map from left to right. The artefact records the decision, while the final column asks how you will know whether the related process or control operated. An inventory entry can show that a use case has an owner; it does not show that the use was assessed or approved. In the same way, a policy acknowledgement shows receipt, not that someone followed the rule in a live workflow.
You do not need to write every artefact from scratch. Once the organisation has made the underlying choices, it can adapt the organisation-wide AI policy template to record them. Keep the source decisions alongside the finished document so reviewers can see why a clause, threshold or approval route exists.
Roles, accountability and decision rights
A framework needs named accountability, not necessarily a separate committee. Depending on scale and risk, an organisation may use:
- An accountable executive who owns the framework and reports to the board or senior leadership.
- A governance coordinator who maintains the inventory, tracks assessments and schedules reviews.
- Business or use-case owners who request AI use and are responsible for its operation.
- Technical owners who implement and maintain controls.
- Relevant specialists in privacy, security, legal, procurement, HR, risk and assurance.
The ICO's accountability and governance guidance for AI supports senior-management involvement, documented accountability, proportionate structures, roles, training and live reassessment after material change. This is data-protection guidance, not a complete AI governance framework, and the page is under review following the Data (Use and Access) Act 2025.
An existing risk or technology board may be sufficient. A separate AI committee is a design choice, not a universal requirement. The key is that every decision has a named owner and a clear escalation path.
Separate accountability from administration. One person may maintain the inventory and chase reviews without holding authority to accept risk. Likewise, a technical owner may implement a control without being able to approve the use case it supports. A short decision-rights table should state who recommends, who decides, who implements and who must be consulted.
The policy owner can then set day-to-day acceptable-use rules for employees and contractors without turning every routine question into a board decision.
Governing the AI lifecycle
The NIST AI RMF 1.0 PDF describes the four functions as continuous and interacting, not a fixed linear sequence. In practice, an organisation cycles through:
- Define: scope, objectives, applicable requirements, risk appetite.
- Map: context, people, information, providers, potential impacts.
- Measure: assess inherent risk, evaluate controls, determine residual risk.
- Manage: approve, condition, redesign, restrict or reject; implement controls; monitor; review.
The DSIT Introduction to AI Assurance distinguishes assessment, audit, conformity assessment and verification as distinct assurance techniques. It was published in February 2024 and is guidance, not law.
Each lifecycle stage should have a defined owner, a working artefact and a review trigger. The NIST AI RMF Playbook offers optional implementation suggestions; organisations need not implement every suggestion.
Consider a fictional customer-support team proposing an AI search tool over its knowledge base. Mapping identifies the users, provider, document collection, affected customers and possible failures. Measurement considers the risks before controls, then tests proposed safeguards. Management records whether the use is approved, approved with conditions, redesigned or rejected. A material provider or data-flow change sends the use back through the relevant parts of the loop.
The detailed record belongs in a separate process. Teams can assess a proposed AI use case without turning the framework page into a universal assessment form.
Risk tiers, approval paths and exceptions
Risk tiering helps an organisation allocate assessment effort proportionately. A simple approach uses three tiers:
- Tier 1 (low): minimal impact, well-understood use, established controls. Lighter assessment, standard approval.
- Tier 2 (moderate): some impact on people or data, new or evolving use. Full assessment, defined approval authority.
- Tier 3 (high): significant impact, novel use, sensitive data or regulated context. Enhanced assessment, senior approval, specialist review.
These tiers are an editorial synthesis. Your organisation must define its own criteria, thresholds and approval authorities. No source makes a universal tiering scheme mandatory.
Record risk before and after controls separately. Inherent risk describes the exposure in the defined scenario before the proposed safeguards are taken into account. Residual risk describes what remains once specific controls and their supporting evidence have been considered. Neither label makes the decision: the locally authorised person still has to accept, condition, redesign or reject the use.
Exceptions should be time-limited, documented, and subject to review. The NIST Govern Playbook suggests inventory fields including purpose, use, risks, data, ownership, scope, maintenance and review. These are suggestions, not a statutory register schema.
Supplier approval also remains a separate decision. Procurement and security teams should assess an AI supplier against the intended service, data flow, evidence and contract. A satisfactory supplier review does not approve every use of that supplier's product.
Evidence, monitoring and incident response
Evidence is what lets a reviewer distinguish a documented framework from one that operates in practice. For each control, an organisation should be able to answer:
- Was the control implemented?
- Does it operate as intended?
- What is the evidence?
- When was it last tested or reviewed?
Keep decision evidence and outcome evidence distinct. A configuration record may show that a control was enabled. A test result may show that it behaved as expected under defined conditions. Monitoring may later show whether incidents, overrides or outcome quality are moving in the intended direction. Those records answer different questions and should not be collapsed into one green status.
The ISO/IEC 23894:2023 guidance standard supports integrating AI-related risk management into organisational activity and tailoring it to context. It is guidance, not legislation or guaranteed compliance.
Incident response within AI governance should cover detection, triage, response and review. Detection may come from user reports, monitoring, audits or external notifications. Triage assesses severity and scope. Response includes containment, remediation and communication. Review captures root cause, lessons learned and any framework or control updates needed.
The NIST Generative AI Profile supports governance, content provenance, pre-deployment testing and incident disclosure as prominent generative-AI considerations. It is a voluntary companion to the AI RMF, published in July 2024.
Define the response path before an incident occurs. Staff need to know where to report a problem, who may pause the affected use, which records must be preserved and who decides whether affected people or external bodies need to be told. The post-incident review should then produce owned changes, not just a meeting note.
A phased implementation roadmap
Rather than a universal 30-, 60- or 90-day schedule, use maturity phases. Each phase has an owner, an output and a test of completion.
| Phase | Focus | Owner | Output | Test of completion |
|---|---|---|---|---|
| 1: Foundation | Scope, principles, accountability, initial inventory | Executive sponsor, governance coordinator | Scope statement, named roles, draft inventory | Senior leadership sign-off; inventory covers known systems |
| 2: Assessment | Risk tiering, first use-case assessments, approval paths | Risk owner, use-case owners | Tier definitions, completed assessments, approval records | At least one use case assessed and decided; approval path exercised |
| 3: Controls | Technical and organisational controls, supplier oversight | Technical owners, procurement | Control specifications, vendor assessments, contract terms | Controls implemented and tested; vendor decisions documented |
| 4: Monitoring | Dashboards, incident process, periodic review | Governance coordinator | Monitoring plan, incident log, review schedule | First review cycle completed; incidents logged and reviewed |
| 5: Improvement | Lessons learned, framework updates, continuous refinement | Executive sponsor | Improvement plan, updated framework | Framework version updated; improvement actions tracked |
The ISO AI management-systems explainer describes a Plan-Do-Check-Act model and recurring organisational risk assessment and treatment. This is a public overview; do not invent clause-level requirements from it.
Move through these phases according to dependency, not calendar time. A team cannot test an approval path until the scope, owners and decision authority are clear. It should not call a control complete until someone can produce the implementation record and the agreed test result. Different business areas can mature at different speeds, provided exceptions and gaps remain visible to the accountable owner.
Document-level controls within AI governance
A file-level check is one possible control inside an approved workflow, not the governance framework itself. The independent workflow comes first: establish governance, authorise the use case, classify and minimise information, assess the provider, and implement organisational and technical controls.
Once those steps are complete, a document-level checkpoint can provide evidence about a specific document version before it enters an AI workflow. This is a narrow, technical control that supports the wider governance process.
.mdSiren is a document security workspace for AI, coming soon. Its Standard Scan will check the exact document version before AI use, route that version to Approved, Needs review or Quarantine, and keep Approved versions in a private Library for dependable reuse. The result remains limited to the reported checks and scan policy in force; it does not create governance, assign organisational risk, approve a use case or replace the other controls in this framework.
To place this step in context, see document-focused AI workflows.
Frequently asked questions
What is an AI governance framework?
It is the organisation's coordinated system for deciding which AI uses are permitted, who owns those decisions, how risks are assessed and controlled, and how evidence and outcomes are reviewed. It sits above individual policies and connects roles, processes, artefacts and review cycles.
What should it include?
A practical framework will usually include scope and principles, an inventory of AI systems and use cases, risk-tiering criteria, approval paths, policies and procedures, technical and organisational controls, supplier oversight, incident response, monitoring and a mechanism for improvement. The specific content depends on your organisation's size, risk appetite and regulatory context.
Is a framework the same as an AI policy?
No. A framework is the operating model; a policy is an approved set of rules within that model. The framework defines what to build and who is accountable; the policy states what is required. A policy without a supporting framework can lack context and a clear route to implementation.
Does a small organisation need an AI governance framework?
A small organisation needs proportionate governance. It may not need a separate committee or a formal management system, but it does need named accountability, a record of what AI is in use, a process for assessing and approving new uses, and a way to review whether controls are working. The framework can be lightweight.
Which AI governance framework should an organisation use?
No single framework is mandatory. The NIST AI RMF is voluntary and under revision. ISO/IEC 42001 is a standard for an AI management system. The OECD AI Principles are non-binding. A practical approach is to synthesise elements from these sources and adapt them to your local context, risk appetite and applicable requirements.
