How to Build an AI Governance Framework

An AI governance framework is the written structure that decides how your organization approves, assesses, controls and reviews AI systems. A usable one has six parts: principles, a structure with named roles, a risk tiering scheme, controls matched to each tier, a review cadence, and a mapping to a published framework such as NIST AI RMF or ISO/IEC 42001 so the result is recognizable to customers and auditors. You can build the first version in a few working sessions. This guide gives each part, with a mapping table and three examples sized from a small agency to a division inside a larger company.

What the framework must answer

Before writing anything, test the framework against the questions it has to answer for any AI system, bought or built. If a part of the document does not help answer one of these, cut it.

1. Which AI systems do we have, and who owns each one?
2. How do we decide whether a new AI use is allowed, and who decides?
3. How risky is each system, and what do we require at each level of risk?
4. What data may each system use, and under what rules?
5. How do we know a system is working as intended after launch, and what do we do when it is not?
6. What evidence can we show a customer, auditor, insurer or regulator?

Notice that none of these questions mention a specific technology. A framework written around today’s chatbots will be out of date in a year; one written around decisions, owners and evidence will not. Our overview of what AI governance is covers the vocabulary if you are starting from zero.

Principles

AI governance principles are the short list of commitments every control traces back to. Keep them to one line each and make them testable. The set below is drawn from the NIST AI RMF trustworthiness characteristics and the objectives in ISO/IEC 42001, which is why auditors recognize them.

• Accountability. Every AI system has a named owner who answers for its behavior.
• Transparency. People know when they are interacting with AI or when AI shaped a decision about them, and staff can explain what a system does and does not do.
• Fairness. Systems that affect people are tested for harmful bias before launch and after changes.
• Validity and reliability. Systems are tested against defined accuracy expectations and monitored for drift.
• Safety and security. Systems cannot be used to cause harm, leak data or be manipulated into unintended actions without detection.
• Privacy. Personal and regulated data is used by AI only under the same rules that govern it everywhere else.
• Human oversight. A person can review, override and stop any AI output that matters, and knows when they are expected to.
• Proportionality. Governance effort scales with risk. Low-risk tools get light rules; high-risk systems get the full set.

Structure and roles

The AI governance structure is the set of roles and the forum where decisions are made. The roles are stable across organizations; what changes with size is how many people fill them and whether the forum is a standing meeting or a committee with a charter.

Role	Responsibility	Who usually fills it
Executive sponsor	Owns the program, approves the policy, resolves conflicts, reports to the board or owners	CEO, COO, CIO or general counsel
AI governance lead	Runs the program day to day: inventory, intake, assessments, review cadence, evidence	Head of IT, security, privacy or compliance; a fractional consultant in smaller firms
Governance forum	Approves new uses, reviews high-tier assessments, decides on incidents and exceptions	A standing agenda item in a leadership meeting, or a committee with IT, security, legal, HR and business representation
System owner	Accountable for one AI system: its purpose, users, outputs and monitoring	The business leader whose team uses it (HR for a hiring tool, a clinician for a clinical tool)
Technical owner	Builds, configures, tests and monitors the system; keeps the technical documentation	Internal engineering, IT, or the vendor’s counterpart
Security and privacy	Reviews data flows, access, vendor terms, logging and security testing	CISO, privacy officer, or the IT lead wearing both hats
Legal and compliance	Advises on applicable laws, contracts, notices and records; this role works with outside counsel	General counsel, compliance officer, outside counsel
People and training	Owns the policy rollout, acknowledgments, training and consequences	HR

Three AI governance models by size

Smaller organizations run a centralized model: one lead, one forum, every decision in one place. Mid-sized organizations usually move to a hub-and-spoke model: a central lead sets policy and standards while system owners in each department run their own assessments against them. Large organizations run a federated model with divisional governance leads reporting into an enterprise committee. Pick the one that matches how other decisions already get made; a governance model that fights the organization chart does not survive.

Risk tiering

Risk tiering is the engine of proportionality. Each AI system in the inventory gets a tier based on two things: the sensitivity of the data it touches and the effect its output has on people or the business. Three tiers plus a prohibited category are enough for almost every organization.

Tier	Criteria	Examples
Prohibited	Uses the organization will not permit at all, whatever the controls	Covert monitoring of employees, AI-only decisions on hiring or firing, uses barred by law or contract
High	Affects people’s access to jobs, credit, housing, insurance, healthcare, education or legal rights; or processes regulated data at scale; or acts autonomously in production systems	Resume screening, loan scoring, clinical decision support, an agent that changes customer records
Moderate	Produces content or recommendations that a person reviews before they take effect; touches confidential business data	Drafting customer emails, summarizing contracts, code assistants, internal document search
Low	No personal or confidential data; outputs are advisory and easily checked	Grammar and translation tools, meeting-note formatting, brainstorming on public information

Two rules keep tiering honest. First, the system owner proposes the tier and the governance lead confirms it; owners tend to under-rate their own systems. Second, a tier can only go down after an assessment, never on the owner’s say-so.

Controls by tier

Controls are what the tier buys you. Writing them as a matrix makes the framework usable: a system owner can read across a row and know exactly what is required.

Control	Low	Moderate	High
Inventory entry with owner	Required	Required	Required
Acceptable-use policy applies	Required	Required	Required
Vendor due diligence	Basic check of terms	Questionnaire, data terms, security attestation	Full review plus contract clauses, business associate agreement where health data is involved
Risk assessment	Not required	Short form	Full assessment, reviewed by the forum
Impact assessment	Not required	If people are affected	Required, refreshed on material change
Data rules	No personal or confidential data	Classified data per policy; retention limits	Documented data flows, minimization, access control, logging
Testing before launch	None	Functional checks by the owner	Accuracy, bias and security testing with recorded results
Human oversight	Not required	Human reviews output before use	Designed review step, override and stop controls, staff trained on them
Transparency	None	Internal labeling	Notice to affected people, explanation available, contest path
Monitoring	Usage only	Periodic owner review	Defined metrics, scheduled review, incident path, drift checks
Change control	None	Owner notified of vendor changes	Re-assessment on model, prompt or data change

For systems you build, add the application-security items from the OWASP Top 10 for LLM applications (prompt injection, sensitive information disclosure, improper output handling, excessive agency) to the moderate and high rows.

Review cadence

A framework without a calendar decays. The cadence below is deliberately light; the point is that each activity has a date and an owner.

When	Activity	Owner
On request	Intake review of a new AI use; tier assigned; assessment if required	Governance lead, forum for high tier
On change	Re-assessment when a model, prompt, data source or vendor changes materially	System owner
On incident	Harmful or wrong output handled through the incident process; lessons fed back into controls	System owner, security
Quarterly	Inventory reconciled against spend and new vendor features; monitoring results reviewed; open actions tracked	Governance lead, forum
Annually	Policy refreshed; tiers re-confirmed; training repeated; framework itself reviewed against new laws and standards	Executive sponsor, governance lead

Mapping table (NIST AI RMF / ISO 42001)

Mapping each part of your framework to NIST AI RMF and ISO/IEC 42001 does two things: it shows reviewers that you did not invent your approach, and it exposes gaps. The table below is the mapping we use as a starting point; the NIST AI RMF guide and the ISO 42001 guide explain the references.

Framework part	NIST AI RMF 1.0	ISO/IEC 42001
Principles	Trustworthiness characteristics; Govern 1 (policies and processes)	Clause 5.2 AI policy; Annex A.2 policies related to AI
Structure and roles	Govern 2 (accountability structures, roles and training), Govern 3 (workforce diversity and inclusion)	Clause 5.3 roles and responsibilities; Annex A.3 internal organization
Inventory and context	Map 1 (context), Map 2 (categorization), Map 3 (capabilities and benefits)	Clause 4 context of the organization; Annex A.6 AI system life cycle
Risk tiering and assessment	Map 4 and Map 5 (risks and impacts); Measure 1 and 2 (metrics and evaluation)	Clause 6.1 and 8.2 AI risk assessment; 8.4 AI system impact assessment; Annex A.5
Controls by tier	Manage 1 and Manage 2 (prioritizing and treating risks)	Clause 6.1.3 and 8.3 AI risk treatment; Annex A.4, A.7, A.9
Vendor management	Govern 6 (third-party risks); Manage 3 (third-party resources)	Annex A.10 third-party and customer relationships
Monitoring and incidents	Measure 3 and 4 (tracking and feedback); Manage 4 (incident response)	Clause 9 performance evaluation; Clause 10 improvement; Annex A.6 and A.8
Review cadence and evidence	Govern 1 and Govern 4 (culture and review); Playbook suggested actions	Clause 7.5 documented information; 9.2 internal audit; 9.3 management review

Category numbering in the NIST table follows AI RMF 1.0; confirm against the current published text before citing it in a formal document. Where a law requires a specific assessment or record, check the current official text as well. This is general information, not legal advice.

Examples

Three AI governance examples show the same framework at different sizes. None of these is a client; they are composites of the situations we see.

A small marketing agency

Fifteen people, no AI built in-house, heavy use of writing and image tools plus AI features in the CRM. The framework is four pages: principles, an owner (the operations lead), a two-page acceptable-use policy, an inventory of nine tools with tiers, and a quarterly review on the leadership agenda. The only moderate-tier controls are a vendor terms check and a rule that client material goes only into tools with a no-training clause. Setup took two working sessions.

A multi-site medical group

An ambient documentation tool, a patient-facing scheduling chatbot, AI summaries inside the EHR, and staff use of general assistants. The clinical tools are high tier. The framework adds a governance committee with a clinician chair, impact assessments for the clinical tools, business associate agreements, HIPAA risk analysis entries, a human-review requirement for any AI-generated clinical content, and monitoring of output corrections. The policy prohibits entering protected health information into any tool outside the approved list.

A division inside a manufacturer

The division is building a predictive maintenance model and an internal document assistant, inside a parent company with its own risk function. The framework follows a federated model: the division appoints a governance lead who applies the parent’s policy, runs tiering and assessments locally, and reports to the enterprise committee quarterly. The build projects add data governance for training data, documented model choices, pre-launch testing, OWASP-based security testing for the assistant, and change control for retraining.

A short list of AI governance best practices runs through all three: name owners before buying tools, keep the policy short, tier everything, write the controls as a matrix, put review dates on a calendar, and map to a published framework. Our AI governance maturity model helps you judge how far along each of these you already are.

Where PS3G fits

PS3G builds AI governance frameworks as part of its AI governance consulting service, for organizations of every size. Our six-week starter program produces the pieces in this guide: principles, structure, inventory with tiers, the control matrix, assessments for high-tier systems, the review calendar and a mapping to NIST AI RMF and ISO/IEC 42001. We work with your counsel on legal questions, and we govern the AI features in our own HIPAA-compliant EHR and telehealth platform, DocVilla, under the same framework, so the templates have been used in a regulated setting before they reach you.

Related reading

• What Is AI Governance? A Practical Guide for Any Size of Organization
• NIST AI RMF Explained: Govern, Map, Measure, Manage
• ISO 42001 Explained: The AI Management System Standard
• AI Governance Maturity Model and Checklist: Where Are You Today?
• AI governance consulting services

Frequently asked questions

What should an AI governance framework include?

Six parts: principles, a structure with named roles and a decision forum, a risk tiering scheme, controls matched to each tier, a review cadence with dates and owners, and a mapping to a published framework such as NIST AI RMF or ISO/IEC 42001. The inventory and the acceptable-use policy are the two documents the framework depends on most.

How many risk tiers do we need?

Three working tiers (low, moderate, high) plus a prohibited category cover almost every organization. More tiers add arguments about boundaries without adding safety. The tier should be set by the data a system touches and the effect its output has on people or the business, proposed by the system owner and confirmed by the governance lead.

Which AI governance framework should we follow, NIST AI RMF or ISO 42001?

Use NIST AI RMF as the structure for your risk program; it is free, voluntary and widely recognized in the US. Treat ISO/IEC 42001 as the target if customers or regulators will ask for certification, or if you already hold ISO 27001 and want one integrated management system. The two map to each other well, and most organizations use both.

Who should sit on an AI governance committee?

The executive sponsor, the governance lead, security, privacy or legal, HR, and the business leaders who own high-tier systems. In a small organization that is three or four people and a standing agenda item rather than a separate committee. Add a clinician for healthcare uses and a model risk reviewer for financial decisions.

How often should the framework be reviewed?

Review individual systems on change and on incident, reconcile the inventory and monitoring results quarterly, and review the framework itself annually against new laws, standards and the way the organization actually uses AI. The annual review is also when tiers are re-confirmed and training is repeated.