AI Governance Beyond the Policy PDF

Picture this. It's a Tuesday afternoon board meeting. The CISO gets a question from a director who just read a Financial Times piece about AI risk: "How many AI systems do we operate, and which ones are high-risk?"

The CISO pauses. Not because they don't care about AI governance. They published an AI acceptable use policy last year. The legal team reviewed it. It went through the approval chain. It lives on SharePoint.

But that policy doesn't answer the question. It can't. A policy document doesn't inventory systems. It doesn't classify risk tiers. It doesn't collect evidence that controls are operating. The CISO knows this. The board doesn't, at least not yet.

This gap between having an AI policy and running an AI governance program is where most organizations sit today. And three regulatory frameworks are about to make that gap very expensive. As we detail in our EU AI Act deadline analysis, the enforcement clock is already ticking.

Three frameworks, one deadline pressure

Three things happened in the last 18 months that changed the math on AI governance.

The EU AI Act entered force. High-risk AI system obligations become enforceable in August 2026. Article 6 defines what counts as high-risk. Article 9 requires a risk management system. Article 13 mandates transparency. Article 14 demands human oversight mechanisms. Article 15 sets accuracy, robustness, and cybersecurity requirements. This isn't guidance. It's law, with fines up to 35 million euros or 7% of global turnover.

ISO 42001 was published. The first international standard for AI management systems. It borrows the Annex SL structure that ISO 27001 practitioners already know, which means it plays nicely with existing ISMS implementations. Clause 6.1 covers AI risk assessment. Clause 8.4 addresses AI system lifecycle management. Clause 9 requires performance evaluation. Organizations pursuing certification need demonstrable, auditable processes.

NIST AI RMF gained federal traction. Executive Order 14110 directed federal agencies to adopt the AI Risk Management Framework. Its four functions (Govern, Map, Measure, Manage) are showing up in procurement language and contract requirements. If you sell to the US government, or to organizations that sell to the US government, NIST AI RMF compliance is becoming a table-stakes question.

These three frameworks aren't competing standards. They're converging on the same core obligations from different directions. They all want you to know what AI systems you operate. They all want risk classification. They all want evidence that controls are functioning. The difference is in the specifics: which articles, which clauses, which subcategories.

The organizations treating them as three separate projects are going to spend three times the effort for overlapping outcomes.

The policy-to-operations gap

Let's be specific about what "having a policy" actually gives you.

A typical AI acceptable use policy covers who can use AI tools, what data can go into them, and what approval process exists for new deployments. Good ones include sections on bias, transparency, and accountability. Some reference NIST AI RMF or ISO 42001 at a high level.

Here's what a policy doesn't give you:

• An inventory of AI systems currently in operation, including shadow AI adopted by business units without IT involvement
• Risk classification for each system mapped to regulatory tiers (EU AI Act distinguishes unacceptable, high, limited, and minimal risk)
• Evidence that controls are implemented and operating, not just documented
• Continuous assessment, because an AI system's risk profile changes when its training data changes, its deployment context shifts, or its user population grows
• Cross-framework traceability, showing how a single control satisfies obligations under NIST AI RMF, ISO 42001, and EU AI Act simultaneously

The policy is necessary. It's the starting point. But it's not a program. And when a regulator, auditor, or board member asks for evidence, a PDF doesn't constitute proof of operational governance.

Framework convergence map

The overlap between these three frameworks is substantial. Understanding it is the key to avoiding redundant work. Here's how the core obligations map across all three:

This isn't a complete mapping. The full crosswalk involves hundreds of individual requirements. But the pattern is clear: the same operational capability satisfies obligations under all three frameworks. Build an AI system inventory once, and you've addressed GOVERN 1.1, Clause 6.1.2, and Article 49 simultaneously.

The question is whether your tooling supports that kind of cross-framework traceability, or forces you to maintain three parallel control sets.

From controls on paper to controls in production

Operationalizing AI governance means closing the loop between a control statement and the evidence that proves it's working. This loop has five components:

1. Control definition. What does the control require? Who owns it? What framework obligations does it satisfy? A control like "AI systems shall be classified by risk tier before deployment" needs to be specific enough to audit and broad enough to cover multiple framework requirements.

2. Evidence specification. What artifact proves this control is operating? For risk classification, that might be a completed risk assessment form with scoring rationale, approved by the AI governance committee, dated within the last 12 months.

3. Collection mechanism. How does evidence get gathered? Manual uploads create staleness. API-driven collection from operational systems (Azure AI Studio deployment records, model registry entries, incident management tickets) keeps evidence fresh.

4. Assessment logic. Is the control implemented? Operating? Proven? There's a difference between having a risk classification procedure (documented), having classified your AI systems (implemented), running the classification process on a regular schedule (operating), passing an external audit of that process (proven), and using classification outcomes to drive automated deployment gates (optimized).

5. Reporting. Can you show an auditor, a board member, or a regulator the current state of your AI governance controls, with evidence attached, without scrambling? If producing that report takes two weeks of analyst time, your program isn't operational. It's reactive.

Five maturity levels for AI governance controls

Not every organization needs to reach the top. But every organization needs to know where it stands.

Documented. The control exists on paper. You have a policy or procedure that describes what should happen. No evidence that it's actually happening.

Implemented. The control has been put into practice at least once. You've completed an AI system inventory. You've done a risk classification. But it might already be out of date.

Operating. The control runs on a regular schedule. AI system inventory gets refreshed quarterly. Risk classifications are reviewed when systems change. Evidence is collected, not just created once and forgotten.

Proven. An independent party (internal audit, external auditor, regulator) has validated that the control works. You have attestation evidence, not just operational evidence.

Optimized. The control drives automated decisions. A new AI system deployment triggers an automatic risk classification workflow. Evidence collection happens through system integrations, not human effort. Exceptions are flagged in real time.

Most organizations with an AI policy are at Documented. The EU AI Act requires at least Operating for high-risk systems. ISO 42001 certification requires Proven. The distance between where you are and where you need to be determines your program timeline.

How Kyudo operationalizes this

Kyudo is an AI-native GRC platform deployed inside your Azure tenant. Six modules, one Compliance Graph connecting controls, evidence, risks, policies, frameworks, and vendors.

Here's how the pieces fit AI governance specifically.

Controls Hub and the 156 AAT controls. The Secure Controls Framework (SCF) includes 1,470+ controls across 80+ frameworks. Within that, the Artificial & Autonomous Technologies (AAT) domain contains 156 controls purpose-built for AI governance. These cover AI system inventory, risk classification, bias assessment, transparency requirements, human oversight, and incident reporting.

Kyudo's STRM Engine (Set Theory Relationship Mapping, per NIST IR 8477) maps these 156 controls across EU AI Act, ISO 42001, and NIST AI RMF simultaneously. Define a control once. Attest to it once. Satisfy obligations across all three frameworks. The Controls Hub scores each control 0-100 based on evidence completeness, freshness, and assessment results.

Evidence Hub for operational proof. Every piece of evidence in Kyudo carries a hash, full lineage tracking, and a confidence score. Evidence freshness matters: artifacts less than 7 days old are fresh, 8-30 days is aging, and anything over 30 days is stale. For AI governance, evidence sources include Azure AI Studio deployment records, model registry metadata, risk assessment forms, bias testing results, incident reports, and human oversight logs.

The Continuous Multi-Framework Control Assessment Engine (CMCAE) runs assessments on a schedule, flagging controls where evidence has gone stale or where assessment scores have dropped below threshold. You don't wait for an audit to discover gaps.

PolicyPilot for AI-specific policies. PolicyPilot generates policy documents grounded in your linked controls, with citations on every draft. Need an AI risk classification policy that references your specific control mappings to Article 6 of the EU AI Act and Clause 6.1.2 of ISO 42001? PolicyPilot drafts it with the citations built in. Every AI output carries a confidence score, and anything below the 0.7 threshold gets flagged for human review.

Risk Management tied to the graph. Risks link to controls and evidence through the Compliance Graph. An AI bias risk doesn't float in a separate risk register. It connects directly to the bias assessment controls, the evidence proving those controls operate, and the framework obligations they satisfy. Board-ready dashboards show risk posture without requiring translation from spreadsheets.

Two-Layer Trust architecture. This is worth understanding. Layer 1 is deterministic: scoring, validation, crosswalk mapping. No AI involved. When Kyudo calculates a control score or maps a control to a framework article, that's math, not inference. Layer 2 is advisory: NLP summarization, policy drafting, evidence gap analysis. Every Layer 2 output includes confidence scores and citations. You always know which layer produced what, and you can verify Layer 2 outputs against Layer 1 ground truth.

Microsoft produces the security truth. Kyudo turns it into audit proof.

"Can't we just extend our existing GRC tool?"

Fair question. Let's take it seriously.

The OneTrust argument. OneTrust has built an AI governance narrative. They acquired Ethicenta and built AI risk assessment workflows. If you're already an OneTrust customer for privacy, the pitch is compelling: add AI governance to your existing platform.

The gaps: OneTrust started as a privacy platform. Its operational cyber GRC capabilities are limited. If you need to cover SOC 2, CMMC, HIPAA, and AI governance in one platform, OneTrust handles the AI piece but leaves you running a separate tool for everything else. There's no customer-hosted deployment option, so your governance data sits in OneTrust's cloud. For organizations with sovereignty requirements (government contractors, defense supply chain, regulated industries in jurisdictions with data residency laws), that's a non-starter.

The Credo AI argument. Credo AI is purpose-built for AI governance. Their AI risk assessment capabilities are strong. They understand the regulatory landscape.

The gaps: Credo AI is an AI governance pure-play. It doesn't cover SOC 2. It doesn't cover CMMC. It doesn't cover HIPAA. If your AI systems process health data, you need AI governance controls AND HIPAA controls, and Credo AI only gives you one side. It's AWS-hosted, which means the same sovereignty concerns apply. And because it's a standalone tool, your AI governance controls live in a different system than your operational security controls, so cross-framework mapping requires manual reconciliation.

The Vanta/Drata argument. These platforms excel at SOC 2 and compliance automation. Fast to deploy, well-designed, good developer experience.

The gaps: They don't have AI governance controls. At all. No AAT domain. No EU AI Act mapping. No ISO 42001 crosswalk. If AI governance is on your roadmap (and with August 2026 approaching, it should be), you'll need another tool.

What Kyudo does differently. One control set. 1,470+ controls including 114 for AI governance. Deployed inside your Azure tenant (sovereignty-grade). Microsoft Security-native evidence collection. AI that reasons over governance through a Knowledge Graph, not just chatbot-style Q&A. You don't choose between operational cyber GRC and AI governance. You get both, mapped through the same Compliance Graph.

The question isn't whether you need AI governance tooling. It's whether you want one platform that covers the full scope, or three tools stitched together with spreadsheets. If your vendors are deploying AI on your behalf, the complexity multiplies further, as we explore in Vendors Deploying AI? You Need a Risk Program.

Your Monday morning checklist

If you read one section of this post, read this one. These are the concrete steps to move from policy to program.

Week 1: Inventory

• Identify every AI system in production (include third-party AI embedded in SaaS tools)
• Assign an owner to each system
• Document data sources, deployment context, and user population for each
• Record results in a system register, not a slide deck

Week 2: Classify

• Apply EU AI Act risk tiers (unacceptable, high, limited, minimal) to each system
• Document classification rationale (why this tier, what factors drove the decision)
• Identify which systems require conformity assessment under Article 43
• Flag any systems that might fall under the unacceptable risk category (Article 5)

Week 3: Map controls

• Select a control framework (SCF's AAT domain gives you 156 controls pre-mapped to three frameworks)
• Map each control to NIST AI RMF functions, ISO 42001 clauses, and EU AI Act articles
• Identify evidence requirements for each control
• Assess current maturity level (Documented, Implemented, Operating, Proven, Optimized)

Week 4: Operationalize

• Define evidence collection mechanisms (manual vs. automated)
• Set assessment schedules (quarterly for most controls, continuous for high-risk systems)
• Build reporting templates for board, audit, and regulatory audiences
• Assign accountability: who reviews evidence freshness, who approves assessments, who reports to the board

Ongoing

• Monitor evidence freshness (stale evidence is worse than no evidence, because it creates false confidence)
• Reassess risk classifications when AI systems change (new data, new use cases, new deployment contexts)
• Track framework updates (all three frameworks are actively evolving)

Readiness is not an audit activity. It is an operating discipline.

---

Want the full framework crosswalk? Download the framework map showing how 156 AI governance controls map across EU AI Act, ISO 42001, and NIST AI RMF, with evidence requirements for each.