The governance plan is filed. The high-impact AI systems are running. The quarterly attestation is due in six weeks. And somewhere between the CAIO's last all-hands with the AI governance council and the meeting you're about to walk into, their CISO started asking a question that nobody's governance plan actually answered.
That's the room you're entering.
Read what follows, then put it away.
What M-25-22 Actually Requires Them to Demonstrate
OMB Memorandum M-25-22 did something that its predecessor, M-24-10, largely didn't: it shifted the accountability standard from documentation to evidence. The operative verb changed, and the change has weight.
Under the previous framework, agencies could satisfy most AI governance requirements by producing a policy, an inventory, and a risk assessment. File the right documents, check the right boxes. M-25-22 changed that. CAIOs are now required to demonstrate that governance controls are functioning — which means producing evidence that the controls are wired into operations, not just described in a plan.
For a CAIO managing a portfolio of AI use cases, that has a specific operational translation: the governance infrastructure has to be connected to the operational infrastructure. Audit logs. Human review records. Incident documentation. Evidence that the oversight mechanisms described in the governance plan are actually triggering when they're supposed to. A policy document that says "a human reviews all high-impact decisions" is not evidence that a human reviewed the decision made at 2:47 PM on March 14th. The log that shows the review happened is evidence.
CAIOs are spending time on this that they didn't budget for. The governance plan was written by a team that understood policy. Making it demonstrable requires people who understand systems — what gets logged, where, in what format, and whether any of it is actually auditable in the way M-25-22 implies. Most agencies discovered the gap between those two things sometime in the second half of 2025, and they're still closing it.
When you're in the room, the CAIO is not worried about whether they have a governance plan. They're worried about whether they can produce evidence on demand that the plan is working. Those are different problems, and the second one is harder.
What a High-Impact AI Designation Actually Triggers
"High-impact AI" under M-25-22 is not a permanent designation that gets assigned at deployment and then forgotten. It's an ongoing classification with ongoing obligations — and the operational weight of those obligations is something a lot of agencies underestimated when they were doing their initial use case inventories.
Once a system is designated high-impact, the CAIO is running a continuous compliance program for that system. Quarterly monitoring reports. Annual re-assessments that require fresh evidence, not just a reaffirmation of the original risk assessment. Mandatory human review mechanisms for decision categories that affect individual rights or benefits. Appeal and redress processes that have to be documented and tested, not just described. And a standing obligation to notify OMB if the system's risk profile changes materially.
A CAIO with four or five high-impact AI systems is managing four or five parallel compliance programs on top of everything else in their portfolio. Each one has its own monitoring cadence, its own evidence requirements, its own human oversight architecture. The governance plan described what those programs would look like. The CAIO is now running them.
A compounding problem sits underneath all of this, and the policy coverage largely misses it. High-impact AI systems don't stay static. They get updated, retrained, connected to new data sources, extended to new use cases. Each of those changes potentially triggers a re-assessment obligation. The CAIO's team is managing a moving target while also producing evidence that the target is under control. One federal CAIO, speaking at a GovCIO Media forum in March, described it as "auditing a system that's being rebuilt while the audit is running." That's not hyperbole. That's Tuesday.
Where the CISO and CPO Coordination Has Stalled
Every published agency AI governance plan assigns accountability across three roles: the CAIO owns AI governance, the CISO owns security controls, and the CPO owns privacy and data access. On paper, the jurisdictions are clean. In practice, they collide at a specific operational event that the governance plans largely didn't resolve.
When an AI system takes an action — accesses a database, retrieves a record, generates a decision — it crosses all three jurisdictions simultaneously. The CISO wants to know what identity the system presented to the access control layer and whether that identity had appropriate authorization. The CPO wants to know what data was touched, under what legal authority, and whether the access was within the scope of the system's approved purpose. The CAIO wants to know whether the governance controls that were supposed to govern that decision were actually enforced at the moment the decision happened.
Three different questions about the same event. The governance plan addressed each domain separately. It did not resolve: what credential does the AI system use when it acts? Who authorized that credential? What is its scope? What does the audit trail look like? And critically — if something goes wrong, who attests to what the system accessed and under what authority?
The coordination meetings between CAIOs, CISOs, and CPOs on these questions are happening right now, and they're not going well. The people in the room are prepared. The questions require answers that don't exist yet in most agencies' infrastructure. The AI systems running today are largely using service accounts, API keys, or credentials inherited from the human users who provisioned them. Those credentials were designed for batch jobs and system integrations, not for AI agents making consequential decisions about benefits, contracts, or security classifications.
The CISO's question — what identity is this system presenting, and is it appropriate for what it's doing — doesn't have a clean answer in most agencies. The CPO's question — can you show me the access log for this decision and confirm it was within authorized scope — often doesn't either. The CAIO is sitting between those two questions with an accountability obligation that requires them to demonstrate governance over a system whose identity and access story was never fully resolved.
The Infrastructure Gap Underneath the Governance Framework
Your buyer is circling a specific problem without always naming it directly: the governance frameworks that agencies built in 2024 and early 2025 were written at policy altitude. They described what governance should look like. They did not specify the infrastructure required to make governance real at the operational layer.
The gap shows up most clearly in the accountability question that M-25-22 makes unavoidable: when a high-impact AI system takes an action, who is accountable for what it accessed, what credential it used, and what decision it made? Answering that question requires an audit trail. An audit trail requires that the system's identity and access events are being logged in a format that's auditable. That requires that the system has an identity in the first place — a stable, scoped, governable identity that the access control layer can enforce against and the audit system can record.
Most federal AI systems don't have that. They have service accounts with broad permissions, provisioned by whoever stood up the system, with audit logs that capture what happened but not why it was authorized or whether the scope was appropriate. The governance plan described the accountability structure. The identity infrastructure wasn't built to support it. Those are related failures, but they require different fixes, and most agencies are only now sorting out which problem they're actually solving.
The CAIO knows this. They may not use the phrase "identity infrastructure." They may describe it as "the audit trail problem" or "the access governance question" or "the thing my CISO keeps bringing up." The operational translation is the same: they cannot currently demonstrate, in the way M-25-22 requires, that they know what their high-impact AI systems accessed, under what authority, and with what scope. And the quarterly attestation is six weeks out.
How to Open the Conversation
They're living this. Walking in to demonstrate you understand the terrain is different from walking in to explain it, and more useful.
The question that surfaces the gap without sounding like a vendor pitch: "When you're preparing for a quarterly attestation on a high-impact system, what does your current audit trail actually show you about the access events — specifically, what credential was used, what was authorized, and who can attest to the scope?"
It signals that you understand the attestation obligation is operational, not documentary. It surfaces the identity and access layer as the buyer's problem, not yours. And it gives the CAIO room to describe the gap in their own language, which is the only language that will matter when they're making a procurement case internally.
Listen for the moment when they describe the coordination problem with their CISO or CPO. The infrastructure gap lives there. That's when the conversation stops being introductory.
Skip the slide about AI governance solutions. The CAIO has seen those slides. They know what the vendor narrative sounds like. What they haven't seen enough of is someone who understands that the governance plan is filed and the hard part is just starting.
That's the room. Go in.