AI Governance Framework: Components, Standards, and a Build Plan

An AI governance framework is the set of policies, roles, processes, and records an organization uses to decide which AI systems it builds or uses, how it controls their risks, and how it proves that to customers and regulators. In practice it covers nine components: policy, roles and a committee, an AI inventory, risk and impact assessment, life-cycle controls, vendor management, monitoring, incident handling, and training. ISO/IEC 42001 is the certifiable standard most companies use to structure it, with the NIST AI RMF as a common companion for risk practice.

If a customer's procurement team has just asked how you govern AI, this page explains what they expect to see and how to build it without creating a binder nobody reads.

What an AI governance framework actually is

Think of it as a management system, not a document. A framework answers five questions that customers, auditors, and regulators keep asking:

1. What AI do you have? An inventory of systems you build, embed, or buy.
2. Who decides? Named owners and a body with authority to approve, restrict, or stop an AI use case.
3. How do you judge risk? A repeatable method to assess risks to the business and impacts on people.
4. What controls apply? Requirements at each stage of the AI life cycle, plus rules for vendors and employees.
5. How do you know it is working? Monitoring, incident handling, internal review, and improvement.

A policy alone answers none of these well. A framework turns principles into decisions with evidence attached.

The nine components

Component	What it is	Typical evidence	ISO 42001 reference
AI policy	Top-level commitments and principles approved by leadership	Signed policy, review history	Clause 5.2; Annex A.2
Roles and committee	Named accountability, decision rights, escalation path	Charter, RACI, minutes	Clause 5.3; A.3
AI inventory	Register of AI systems you develop, provide, or use	Inventory with owners and risk tier	Clause 4; A.4
Risk assessment	Method to identify, analyze, and evaluate AI risks	Risk register, treatment plan	Clauses 6.1.2, 6.1.3
Impact assessment	Assessment of consequences for individuals, groups, society	Completed impact assessments	Clause 6.1.4, 8.4; A.5
Life-cycle controls	Requirements for design, data, testing, deployment, operation	Design docs, test results, release approvals	A.6, A.7
Vendor management	Due diligence and contract terms for third-party AI	Vendor assessments, contract clauses	A.10
Monitoring and incidents	Performance tracking, event logs, incident response and disclosure	Dashboards, logs, incident tickets	A.6, A.8
Training and awareness	Role-based competence plus general AI awareness	Training records, completion rates	Clause 7.2, 7.3

1. AI policy

The policy states why you use AI, the principles you hold yourself to (for example fairness, transparency, human oversight, privacy, security), and who is accountable. Keep it short, two to four pages, and push detail into procedures. We cover structure and sample language in the AI policy template guide.

2. Roles and a governance committee

Someone has to own the framework day to day (often the head of security, compliance, or a designated AI governance lead), and a cross-functional group has to make the hard calls. Each AI system also needs a named business owner. Without named owners, inventories go stale and risk acceptances never get signed.

3. AI inventory

You cannot govern what you have not listed. The inventory covers three categories: AI you build into your product, AI features inside tools you buy (CRM, support desk, code assistants), and general-purpose AI tools employees use. For each, record the owner, purpose, data used, users affected, vendor, and risk tier. The AI risk assessment guide walks through building one.

4. Risk assessment

A risk assessment looks at what could go wrong and how it affects your objectives: model errors, data leakage, bias, security attacks such as prompt injection, vendor failure, regulatory exposure. Use a defined scoring method so results are comparable across systems, and record treatment decisions with an accountable owner.

5. Impact assessment

An impact assessment looks outward: what the system could do to the people and groups it touches, and to society. ISO 42001 treats this as a separate requirement from risk assessment, and ISO/IEC 42005 (published 2025) gives guidance on how to run one. Results feed back into risk treatment.

6. Life-cycle controls

These are the requirements that apply as a system moves from idea to retirement: documented objectives and requirements, data quality and provenance checks, verification and validation before release, deployment approval, operational monitoring, and technical documentation. If you already run a secure development life cycle, extend it rather than building a parallel one. See the Annex A controls guide for the full list.

7. Vendor management

Most companies use far more third-party AI than they build. Extend vendor due diligence to ask how a supplier trains and evaluates its models, whether your data is used for training, where data is processed, what logging and incident notification they offer, and whether they hold relevant certifications. Put the answers into contracts, not just questionnaires.

8. Monitoring and incident handling

Define what "working correctly" means for each system (accuracy thresholds, drift indicators, complaint volumes, abuse signals) and who watches it. Then define what counts as an AI incident, how it is triaged, and when customers or authorities must be told. Most teams fold this into their existing security incident process with AI-specific categories.

9. Training and awareness

Two layers: everyone gets awareness training on acceptable use and how to report concerns; people who build, buy, or approve AI get role-specific training. Keep records. Under the EU AI Act, providers and deployers are expected to take measures to support AI literacy among staff who operate AI systems (see the law section below).

How ISO 42001, NIST AI RMF, and the law fit together

These are not competing options. They do different jobs.

	ISO/IEC 42001:2023	NIST AI RMF 1.0	EU AI Act
Type	International management-system standard	Voluntary US framework	Binding EU regulation
Published by	ISO and IEC (JTC 1/SC 42)	NIST (AI 100-1)	European Parliament and Council
Released	December 2023	January 26, 2023	In force August 2024, phased application
Certifiable?	Yes, by an accredited certification body	No official certification	Conformity assessment for high-risk systems
Cost to use	Purchase the standard	Free	Compliance cost depends on role and risk
Best for	Proving governance to customers with a certificate	Structuring risk practice and vocabulary	Legal obligations for systems in the EU market

ISO/IEC 42001

ISO/IEC 42001 defines requirements for an AI management system (AIMS). It uses the same harmonized structure as ISO 27001 and ISO 9001: clauses 4 through 10 cover context, leadership, planning, support, operation, performance evaluation, and improvement, and Annex A lists 38 controls in 9 areas. It applies to any organization that develops, provides, or uses AI. Because it is certifiable, it is the framework that produces a document you can hand a customer. Our ISO 42001 hub explains it in detail, and the ISO 42001 vs ISO 27001 vs SOC 2 guide covers how it sits next to existing security programs.

NIST AI RMF

The NIST AI Risk Management Framework is organized into four functions: GOVERN, MAP, MEASURE, and MANAGE. It describes seven characteristics of trustworthy AI and comes with a Playbook of suggested actions and a Generative AI Profile (NIST AI 600-1, July 2024). It is free and voluntary, and there is no official certification. A common pattern is to use NIST AI RMF for day-to-day risk practice and ISO 42001 as the management system that gets audited. See ISO 42001 vs NIST AI RMF.

EU AI Act and other laws

The EU AI Act (Regulation (EU) 2024/1689) sorts AI systems by risk and places obligations on providers and deployers. As of October 2026, the key dates are:

• February 2, 2025: prohibited practices and AI literacy provisions started to apply.
• August 2, 2025: obligations for general-purpose AI models started to apply.
• August 2, 2026: most transparency obligations under Article 50 started to apply.
• December 2, 2027: obligations for high-risk systems listed in Annex III (for example certain employment, education, and credit uses), deferred from August 2026 by the Digital Omnibus on AI, Regulation (EU) 2026/1744, which entered into force in July 2026.
• August 2, 2028: obligations for high-risk AI embedded in products covered by Annex I EU product legislation, also deferred by the Omnibus.

The Omnibus also softened the AI literacy provision so that organizations must take measures to support AI literacy rather than guarantee a specific level. These dates have already moved once, so check the current text before relying on them. This is not legal advice; your obligations depend on your role and how each system is classified.

A management system does not make you compliant with any law on its own. What it does is give you the inventory, risk process, documentation, and oversight that legal compliance work depends on. Building the framework first means legal analysis has something to work from.

Step-by-step build plan for a mid-size company

This plan assumes a company of roughly 100 to 500 people, with some AI in the product and plenty of AI tools in use internally. Durations are indicative and depend on how much already exists.

Weeks 1–2: Sponsor, scope, and baseline

• Get an executive sponsor (CEO, CTO, or COO) who will sign the policy and chair or attend the committee.
• Decide scope: which products, AI systems, teams, and locations are in. Start narrower than you think; you can expand.
• Run a gap assessment or at least our free readiness self-assessment to see what you already have from ISO 27001, SOC 2, or privacy work.

Weeks 2–4: Inventory and roles

• Build the AI inventory. Pull from procurement records, SSO app lists, expense reports, engineering architecture docs, and a short survey of team leads.
• Assign an owner to every system.
• Draft the committee charter (outline below) and hold the first meeting.

Weeks 3–6: Policy and method

• Write the AI policy and AI acceptable use policy. Use the policy template as a starting point.
• Define your risk scoring method, risk acceptance thresholds, and impact assessment template.
• Map the policy to existing security, privacy, and data policies so they do not conflict.

Weeks 5–9: Assess and treat

• Run risk assessments on every in-scope system, prioritizing customer-facing and high-impact ones.
• Run impact assessments where systems affect individuals or groups in meaningful ways.
• Choose treatments, assign owners and due dates, and record accepted risks with a named approver.
• If you are heading toward ISO 42001, draft the Statement of Applicability, justifying each included or excluded Annex A control.

Weeks 8–12: Embed controls

• Add AI checkpoints to your development life cycle: requirements, data review, evaluation before release, deployment approval.
• Add AI questions to vendor due diligence and contract templates.
• Add AI categories to incident response.
• Launch awareness training and role-based training.

Month 3 onward: Operate, review, improve

• Run monitoring and keep records.
• Hold committee meetings on a fixed cadence.
• Run an internal audit and a management review. For certification you will need these, plus a few months of operating records, before the Stage 2 audit. See how to get ISO 42001 certified and the ISO 42001 checklist.

Auditor's note: In audits, the most common gap we look for is a framework that exists on paper but has no decisions in it. A committee charter with no minutes, a risk register where every risk is "medium" and nobody accepted anything, an inventory last updated at kickoff. Auditors sample evidence of operation. Two or three real decisions, documented with reasoning and a named approver, carry more weight than a polished policy set.

Sample AI governance committee charter outline

Use this as a skeleton. Keep the final version to two or three pages.

1. Purpose. The committee oversees how the company develops, provides, and uses AI systems, so that AI use supports business objectives, stays within risk appetite, and meets legal and customer commitments.

2. Authority. The committee is established by [executive sponsor or board] and may approve, condition, pause, or prohibit AI use cases within scope. It may require risk or impact assessments before any AI system is deployed or materially changed.

3. Membership.

• Chair: [executive sponsor or delegate]
• AI governance lead (secretary and framework owner)
• Engineering or ML lead
• Product lead
• Security lead
• Privacy or legal counsel
• Data lead
• Rotating business representative from a team that uses AI heavily

4. Responsibilities.

• Approve and review the AI policy and acceptable use policy.
• Approve the risk scoring method and risk acceptance criteria.
• Review the AI inventory and risk tiers at least quarterly.
• Decide on high-risk use cases and accept or reject residual risk above defined thresholds.
• Review significant AI incidents and corrective actions.
• Set and track AI objectives and report to leadership.
• Provide input to management review.

5. Decision-making. Quorum is [majority including chair or delegate]. Decisions are by consensus where possible; otherwise the chair decides and dissent is recorded. Urgent decisions may be taken by the chair and AI governance lead and ratified at the next meeting.

6. Meetings. At least quarterly, plus ad hoc meetings for urgent reviews. Agenda and materials circulated in advance. Minutes record decisions, owners, and due dates.

7. Escalation. Issues outside the committee's authority, or residual risks above the committee's threshold, are escalated to [executive team or board].

8. Conflicts of interest. Members declare conflicts and recuse themselves from decisions on systems they own when the decision concerns accepting risk on that system.

9. Reporting. The committee reports to [executive team] at least [twice a year], covering inventory changes, top risks, incidents, objective status, and audit findings.

10. Review. The charter is reviewed annually and after significant organizational or regulatory change.

Where TrustAIMS fits

TrustAIMS is an advisory firm founded by former Big Four auditors. We help companies build and operate an ISO 42001 AI management system: a fixed-fee gap assessment (from $12,500, about two weeks), certification readiness, and an ongoing AIMS retainer for internal audits and management review. We are not a certification body and cannot certify you; the body that certifies you cannot also consult for you, and that separation protects the value of your certificate.

If you want a quick read on where you stand, start with the free 10-question readiness assessment.