AI Governance Framework: How to Build One That Works

AI reaches most organizations through several doors at once. A licensed assistant here, an AI feature switched on inside an existing SaaS tool there, and a handful of tools nobody filed a ticket for.

The governance framework that's supposed to cover it all usually arrives later, if at all. In The Netwrix 2026 Data and Identity Security Report, 41% of organizations already run agentic AI in production on behalf of humans, while 11% have operationalized AI governance through enforced, continuous, and proactive review.

Confidence tracks that gap, and it isn't pretty. Only 18% of organizations in the $100 million to $1 billion revenue band feel very confident they'd pass an independent audit of AI governance and controls, according to Grant Thornton.

Meanwhile, 42% of mid-market IT leaders surveyed in The Netrio’s Mid-Market AI Readiness Report reported a confirmed AI-related security incident or exposure in the past year. The framework that closes that distance ties every written rule to a control someone can test and a record someone can pull.

What is an AI governance framework?

An AI governance framework is a structured set of policies, roles, processes, and controls that govern how an organization designs, deploys, and uses AI systems. This includes licensed assistants, public tools staff access through a browser, AI features shipped inside SaaS applications, and internal models.

ISO/IEC 42001 refers to an AI management system, which emphasizes the operating structure. An AI risk management framework puts it on identifying and treating risk.

These three documents often get muddled, and the distinction determines who's accountable. A framework defines accountability and process across lifecycle stages. A policy sets the rule, and an assessment tests how well either one works on a given date.

Why an AI governance framework matters

The framework earns its place by turning scattered decisions into something a board, a regulator, or an auditor can inspect:

• Approval on evidence: Security can sign off on an AI rollout with a named list of what each tool reaches and under which identities, instead of an assurance from whoever built it.
• A defensible audit trail: Risk assessments, access reports, configuration history, and committee minutes are all in one place when someone asks for them.
• Contained blast radius: Scoping and access limits decide how much data a compromised or misconfigured AI session can reach.
• Faster approvals, not slower ones: A standing intake path and risk tiers let low-risk use cases through quickly and route the rest to real review.
• One program instead of two: AI risk lands in the registers, control libraries, and review gates already running, so nothing gets maintained twice.

Each of those depends on the same underlying thing: knowing what AI can currently achieve in a live environment.

Why existing governance programs fall behind AI

Three forces land on the security team at roughly the same time. Each one widens the distance between what the policy claims and what the environment can prove.

AI arrives faster than it gets approved

Usage runs ahead of policy, and the numbers aren't close. ISACA's 2026 AI Pulse Poll found 90% of digital trust professionals believe employees are using AI at their organization, while only 38% of those organizations have a formal, comprehensive AI policy.

Sequencing explains most of the shortfall. The RSM AI survey report found that roughly a third of middle-market organizations move into pilots or production before governance controls are in place, with 16% only reaching governance after something goes wrong. What builds up is a pile of one-off approvals and undocumented exceptions. It holds fine until someone asks for evidence.

Compliance deadlines have started passing

Standards arrived first and set the expectation for structure. ISO published ISO/IEC 42001 on 18 December 2023 as an international AI management system standard, and most teams pair it with the NIST AI RMF as a voluntary companion.

Then the EU timeline moved, and not in the direction most teams had planned for. The Digital Omnibus on AI, adopted as Regulation (EU) 2026/1744 on 8 July 2026, pushed most high-risk obligations back to 2 December 2027 for standalone Annex III systems and 2 August 2028 for product-embedded Annex I systems.

Two dates didn't move, and both are behind us. Article 50 transparency duties and the Commission's enforcement powers over general-purpose AI models have applied since 2 August 2026, per the AI Act enforcement timeline. Generative systems already on the market before that date have until 2 December 2026 to meet the Article 50(2) marking duty, which is the next real deadline for most teams.

AI amplifies permission debt you already have

An AI tool exercises access that's already there. Microsoft's own oversharing guidance is blunt about it: Copilot inherits existing Microsoft 365 permissions and protections, so over-permissioned sites, inherited access, and missing sensitivity labels must be corrected before deployment.

Years of ad hoc sharing that nobody noticed become searchable the moment a prompt can reach them. Fixing that layer first is also where the payoff shows up, since organizations with unified identity and data governance are nearly five times more likely to report full AI readiness.

The six pillars of a working AI governance framework

Most published frameworks bury data access visibility within broader domains such as privacy or data governance. It gets its own pillar because certification and audit depend on it, and ISACA's AI audit procedures specifically ask for access logs, change-management processes, and role-based policies.

1. Scope and inventory

Scope defines what every other control applies to. It names the AI systems and use cases at play, along with the business objectives, risk appetite, and regulatory obligations associated with each.

ISO/IEC 42001 Clause 4.3 requires that scope to be available as documented information. A scope statement without any supporting inventory fails on the first sample.

2. Ownership and approval paths

Accountability lands on named individuals. An executive sponsor, a governance lead, security, data protection, and business-unit owners each hold a specific decision right.

ISO/IEC 42001 control A.3.2 puts it directly, requiring that "roles and responsibilities for AI shall be defined and allocated according to the needs of the organization." The working test is whether anyone can say who approves a new use case and who can switch one off.

3. Policy mapped to controls

Policy covers acceptable use, prohibited data types, human-in-the-loop requirements, transparency expectations, and incident handling. A policy works when every line names the control that enforces it.

Those controls are access restrictions, data classification, one of the DLP solutions already deployed, conditional access, and logging. A rule with no control behind it is a sentence, not a safeguard.

4. Data and identity visibility

This pillar answers two questions about any AI interaction. What data could the tool reach, and which human, machine, or non-human identity invoked it?

It's also the pillar most programs can't prove. The report quantifies why, finding that 74% of organizations lack a single, unified view of sensitive data and the identities that can access it. Granted access and effective access are different lists, and they diverge fast in any environment with history.

5. Lifecycle management

Lifecycle runs from data through model development, deployment, review, and retirement, with a decision gate at each transition. Retirement is the gate almost nobody reaches, and it's the one auditors ask about.

Identity lifecycle management already handles joiners, movers, and leavers for people, and AI agents belong in the same discipline. NIST AI RMF subcategory MANAGE 2.4 calls for mechanisms and assigned responsibilities to supersede, disengage, or deactivate AI systems performing inconsistently with intended use.

6. Measurement and improvement

Measurement gives the governance committee something to decide on. The measures that earn their place are AI incident counts, policy exceptions, risk-assessment coverage, and control effectiveness.

Clauses 9 and 10 of ISO/IEC 42001 cover monitoring, internal audit, management review, and corrective action. Anything that doesn't change a decision isn't worth tracking.

How to build the framework in five steps

The pillars describe what the finished framework holds. Building it runs in a different order, starting with the AI already in the environment rather than the policy someone wants to write. Work these five steps in sequence.

1. Inventory the AI already running

Pull from three sources, because no single system knows everything. Licensed apps and service principals come from your identity provider, embedded AI features come from vendor release notes and admin centers, and unsanctioned tools come from egress logs.

Expect the sanctioned list to undercount badly. A 2026 PagerDuty survey found that 66% of office professionals have used AI at work despite believing their policies didn't allow it, and only 20% of organizations fully monitor or govern shadow AI.

Then sort what you found into risk tiers. Internal productivity, customer-facing services, and regulated data use each warrant different levels of scrutiny, and the tier determines how much of the remaining work a system receives.

2. Assign owners and build the approval path

Assign each AI system a named owner in IT, security, data protection, or the business line that uses it. Teams, committees, and distribution lists don't count.

Then map the request path, from risk assessment through control design, sign-off, and a review date. Write down who grants exceptions and who can suspend a system when its risk changes.

Keep it honest with recurring access certification, which confirms administrators, service accounts, applications, and AI agents still hold only what their current work needs. Active Directory service accounts are usually where the stale entitlements hide.

3. Map each rule to a control you can test

Take the policy line by line and write the enforcing control next to it. If you can't name one, the rule isn't enforceable yet and belongs on the gap list.

State the red lines flatly and without hedging. No generative AI access to unclassified personally identifiable information (PII), with named carve-outs for legal and human resources data.

Privileged access needs to be handled on its own terms. Administrators configuring AI services need elevation, so issue short-lived just-in-time (JIT) credentials per approved session and apply zero standing privilege to the accounts that integrate those services.

4. Fold AI into the processes you already run

Add AI risk categories to the existing risk registers, control libraries, and issue trackers, then route AI use cases through the intake, change-management, and security-review gates already in place. ISACA guidance recommends exactly that, with AI risk management augmenting established cyber, risk, and privacy programs.

Give third-party and embedded AI the same treatment, recording the provider, data flows, integration method, retention terms, owner, and exit plan. Where access reviews require tooling, compare the IGA tools against the systems already in scope.

5. Set the cadence, then prove it works

Fix the review cadence before the first review is due, and embed these measures into the existing IT risk assessment cycles. Check what the compliance tools already deployed can report before buying anything new.

Then test the framework the way an auditor would. Pick one AI system, pull its owner, risk tier, control set, access report, and last review date, and see how much of that you can produce inside an hour.

Aligning the framework with NIST AI RMF and ISO/IEC 42001

A framework built this way ends up written in your own vocabulary. Auditors, customers, and regulators won't ask for it that way. They ask which standard you align with, and mapping lets you answer without rebuilding anything.

Clause 5 of ISO/IEC 42001 covers ownership and AI policy, Clauses 6 and 8 cover risk and impact assessment, and Clauses 9 and 10 cover measurement and improvement. Four of the six pillars above are renamed.

Which of the two you map first isn't a coin flip, though, and the reason gets lost because both get named in the same breath. ISO/IEC 42001 is auditable and certifiable. The NIST AI RMF is neither. That difference decides what you can claim and where your evidence has to land.

What the AI RMF can and can't do for a data-centric program

The AI RMF Core organizes risk management across Govern, Map, Measure, and Manage, and its subcategories are outcome statements, not requirements. NIST publishes no conformity assessment schemes, accreditation criteria, or certification body requirements. You can say your program aligns with the AI RMF or that controls map to its subcategories. You can't say "NIST AI RMF certified."

There's a second limitation worth knowing before you map anything. Across all 72 subcategories, none name access control, identity, authentication, permissions, or data provenance. So knowing which identities can reach which data, the thing an evidence pack actually turns on, maps to the AI RMF by interpretation rather than by textual hook.

Three subcategory families carry that weight in practice. The third-party set is the strongest, with GOVERN 6.1 covering policies for third-party AI risk, MANAGE 3.1 requiring that "AI risks and benefits from third-party resources are regularly monitored," and MAP 4.2 covering internal risk controls for third-party components. MEASURE 2.7 and 2.10 are where security and privacy evaluation evidence lands. For de-provisioning, pair MANAGE 2.4 with GOVERN 1.7.

Why the NIST crosswalk needs translating before an audit

NIST publishes a crosswalk from AI RMF subcategories to ISO/IEC 42001, and it saves real work. It also has a property that catches teams out. Each of its 202 control references points to Annex B, and it cites zero Annex A controls.

That distinction determines whether your mapping survives an audit. Annex A is normative, its controls read "shall," and the Statement of Applicability is built from it. Annex B is implementation guidance; its controls read "should," and it states plainly that organizations don't have to justify including or excluding that guidance in the Statement of Applicability. A crosswalk row that sends MANAGE 2.4 to "B.9.4 Intended use of the AI system" points to advice, not to the auditable control.

The translation is mechanical because 42001 numbers the two annexes in parallel, so B.9.4 is the guidance for A.9.4. Skipping it is the common mistake. One more thing to know going in: the crosswalk targets ISO/IEC FDIS 42001, the final draft, rather than the published standard.

The clause most programs miss

Risk assessment and impact assessment are separate obligations in 42001, and conflating them is the most common gap in a first-time Statement of Applicability. Clause 6.1.2 assesses risk to your own AI objectives, with likelihood, risk levels, and risk criteria. Clause 6.1.4 assesses outward impact on individuals, groups of individuals, and societies, with none of that likelihood machinery.

The relationship runs one way. Clause 6.1.4 requires that impact assessment results be considered in the risk assessment, while note 6.1.2 states that an organization may use an impact assessment to assess consequences. Each carries its own documented information obligation; Annex A.5 controls the impact side, and Clause 8.4 requires running both at planned intervals or upon significant change and retaining the results. ISO/IEC 42005 supplies the method, though it's guidance and can't be certified against.

Data and identity visibility gets its hook from the controls rather than the clauses. Of the 38 Annex A controls across nine categories, A.7.5 Data provenance is the one a data-centric program wants, since it requires a documented process for recording AI data provenance.

What certification actually asks for

Certification runs in two stages under ISO/IEC 17021-1, with certification-body competence set by ISO/IEC 42006, published in July 2025. Stage 2 is the one people plan for, since it evaluates implementation and effectiveness on-site against artifacts such as completed risk assessments and AI system event logs.

Stage 1 is the one that catches people out. It evaluates preparedness for Stage 2, including whether internal audits and management review have actually been performed rather than merely scheduled. A full internal audit cycle needs to be behind you, which usually pushes the realistic certification date back a quarter from what teams assume.

AI governance framework checklist

Six questions surface gaps that become audit findings. Answer each against the environment you have, not the one in the policy:

• Does the program name accountable owners and set review cycles with real dates?
• Have you found every AI system in use and mapped each to the data and identities it reaches?
• Do your AI policies point at specific technical controls, covering access restrictions, DLP, conditional access, and logging?
• Does the framework align to NIST AI RMF, ISO/IEC 42001, or both, so coverage can be benchmarked?
• Can you produce risk assessments, configuration logs, access reports, and committee minutes on request?
• Do you have a plan to update the framework as tools, regulations, and risks shift?

Anything you can't answer is a gap that needs an owner, a remediation plan, and a validation date.

How Netwrix closes the AI governance evidence gap

Pillar four is where governance intent meets environmental reality, and it runs on data that native tooling keeps in brief form or scatters across portals. Netwrix supplies that layer through named AI governance capabilities, and it's worth being precise about what each product does.

Reporting what AI can reach

Netwrix 1Secure answers the pre-rollout question while the decision is still reversible, reporting on the sensitive data Copilot can access before anyone enables it. After go-live, it reports on Copilot activity, listing users, timestamps, and referenced resources, and flagging responses that expose sensitive data. It also tracks roles, permissions, and changes across Microsoft Entra ID.

Netwrix Access Analyzer handles the harder half of the question. It resolves nested group membership to calculate effective access for Active Directory and Microsoft Entra ID users, SharePoint sites, and file systems, surfacing open access and broken inheritance. That turns pillar four from an assertion into a per-identity report you can hand across the table.

Retaining evidence past the log window

Frameworks are audited months after decisions are made, which makes this a retention problem before it's a reporting one. Netwrix Auditor records who changed what and when with before-and-after values, and builds state-in-time reports from daily configuration snapshots.

Two regulated customers show the difference at examination time. First National Bank and Trust of Beloit maintains continuous OCC compliance across 300 users at 17 locations, replacing a full week of manual checklist work with an hour of preparation.

Credissimo proves GDPR and ISO/IEC 27001 compliance across its consumer finance operations, generating audit reports 85% faster, in a day instead of a week.

Netwrix covers the data access, identity, and audit-reporting layer that pillar four needs and that broader AI governance platforms assume you already have. Those platforms run the broader workflow; the AI vendor retains control of model behavior; and the framework, the committee, and the decisions stay with you.

Prove the framework on one system first

Leadership trusts a framework when current access, configuration, and activity data inform its decisions. That argues against launching the whole program at once. Pick one high-impact system, then measure sensitive data exposure, permission breadth, exception volume, and the completeness of the evidence pack.

A licensed assistant running on your existing tenant makes the best prototype, because its permission model rides on access decisions already in place and the visibility tooling exists today. Run the six pillars against that one system, see what the evidence actually proves, and carry the pattern across the rest of the AI inventory from there.

Request a demo to see what your AI tools can reach, map the identities behind them, and keep the change history your next audit will ask for.