The workforce resistance explanation for federal AI stalls has the virtue of being partially true, which makes it harder to argue with and easier to over-rely on. Employees are skeptical. Middle managers feel bypassed. Agency culture rewards caution and punishes visible failures. Change fatigue is real. Federal workers have absorbed enough "transformational" initiatives to develop a healthy immune response to the next one. None of this is invented.
The problem is that the change management framing, applied to AI pilot failures, explains the wrong variable. It describes friction that's real but not fatal. Agencies have moved skeptical workforces through harder transitions than adopting a new tool. What they haven't figured out how to do is move an AI pilot from a sandboxed demo environment into a production system that can survive an ATO review, integrate with enterprise provisioning, and produce an audit trail that a CISO will sign off on. That's an architecture problem, and it was present from day one.
The GAO's 2024 review of federal AI adoption found that agencies had catalogued over 1,700 AI use cases, but fewer than 30 percent of those were in active production deployment. The gap between "we have a pilot" and "we have a system" is where the real story lives, and the gap is not primarily explained by workforce resistance. Agencies that cleared the people hurdles — executive sponsorship, workforce buy-in, training programs, the whole change management checklist — still found their pilots stranded at the same structural threshold. The question "how do we move this to production?" kept producing the same answer: we have to rebuild it.
The Pattern You Already Know
If you've spent any time in federal IT sales, you've watched shadow IT play out in slow motion. A program office deploys a SaaS tool on a government purchase card. It works. People use it. Six months later, someone asks who has access, what data it's touching, and whether there's an audit trail. The answers are bad. The tool either gets shut down or goes through a painful remediation process that costs more than the original deployment. The architecture wasn't wrong because the people were rogue — it was wrong because the deployment was never designed to fit inside the enterprise envelope.
Federal AI pilots are running this same pattern, but with a critical difference: they're doing it deliberately, with budget, with executive sponsorship, and with a PowerPoint deck calling it innovation. The architecture problem was built in from the start.
A typical federal AI pilot looks like this: a vendor spins up a tenant in their cloud environment, connects it to a sample of agency data through an API key, and demonstrates capability to a working group over eight to twelve weeks. The demo works. The working group is impressed. The pilot report says "strong potential for operational deployment." And then nothing happens for eighteen months, after which the initiative quietly dies or gets relabeled as a "phase two exploration."
What the pilot report doesn't say is that the tenant was never in the agency's cloud environment. The API key was issued to a contractor's personal account, not to a service principal governed by the agency's IAM. The data sample was pulled from a system that hasn't been classified for AI processing under the agency's data governance policy. There's no audit log that the agency controls. There's no integration with the agency's identity provider. There's no provisioning workflow. The pilot was built entirely outside the enterprise identity and compliance envelope, and moving it to production doesn't mean deploying it — it means rebuilding it from scratch inside the envelope it was never designed for.
The analogy to shadow IT holds to a point. Shadow IT is a governance problem that emerges when someone deploys something without authorization; federal AI pilots are a governance problem that emerges when something gets authorized without ever being designed for governance. The rogue employee at least knows they're operating outside the rules. The AI pilot team often doesn't know there are rules that apply to them, because nobody told them, and the vendor certainly wasn't going to raise it.
What ATO Actually Diagnoses
The Authority to Operate process gets treated as a compliance checkbox, the bureaucratic toll booth between a working system and a deployed one. That framing costs agencies years and costs vendors deals. ATO is a diagnostic instrument, and what it surfaces is exactly the checklist that most pilots were never built against.
A FISMA-aligned ATO review asks specific questions. How does the system authenticate users, and is that authentication federated through the agency's identity provider? What data does the system process, and has that data been classified and authorized for processing in this environment? What access controls govern who can do what, and are those controls integrated with the agency's RBAC or ABAC framework? What audit logs does the system produce, and are those logs in a format and location that the agency's security operations team can actually use? What's the provisioning and deprovisioning workflow when an employee joins, moves, or leaves?
A pilot built outside the enterprise envelope fails every one of these questions. The technology was never connected to the infrastructure that makes them answerable. The authentication is vendor-managed. The data classification was never done. The access controls are whatever the vendor's platform provides by default. The audit logs live in the vendor's tenant. Provisioning and deprovisioning don't exist as concepts in the pilot architecture.
OMB's M-24-10 memo, issued in March 2024, made this structural requirement explicit: agencies must ensure AI systems comply with existing federal information security requirements, including FISMA, and must integrate AI governance into existing risk management frameworks. The memo didn't create new requirements — it clarified that the existing requirements apply to AI systems. Pilots that were built as if they existed outside the FISMA envelope were already non-compliant; M-24-10 just made it harder to pretend otherwise.
The CAIO role, which M-24-10 required agencies to formalize, is now the organizational node where this tension lives. A good CAIO is asking exactly the questions that an ATO review asks, earlier in the process, precisely because they've watched enough pilots die at the production threshold to understand where the structural failure is. When a CAIO tells a vendor "we need to understand your ATO pathway," the question is whether the vendor has ever actually deployed inside a federal enterprise, or whether they've only ever run pilots.
The Discovery Leverage
The change management framing has a specific cost for sellers. Walk into a federal AI adoption conversation assuming the problem is people and culture, and you'll ask questions about workforce readiness, training programs, executive sponsorship, and change management maturity. Those questions have their place, but they don't surface the structural kill switch, and they don't position you as someone who understands where federal AI actually breaks.
The question "has this pilot gone through ATO review?" does more diagnostic work than ten minutes of change management discussion. Asked straight, it reads as a genuine probe into whether the agency has a production path or just a demo. If the answer is yes, you're talking to an organization that has at least pointed its architecture in the right direction, and the conversation is about acceleration. If the answer is no, you're looking at one of three situations: the pilot is early enough that there's still time to build it right; the pilot is mature enough that a rebuild conversation is coming whether the agency knows it or not; or the pilot is quietly terminal and nobody has said so yet.
Follow-on questions are equally diagnostic. Is the pilot running in the agency's cloud environment or the vendor's? Is user authentication federated through the agency's IdP, or is it vendor-managed? Does the agency have visibility into the audit logs, or are those logs in the vendor's tenant? A peer who's been through this asks these questions to understand whether the work has been done.
The signal is the gap between what the agency thinks it has and what it actually has. An agency that believes its AI pilot is "production-ready" because the demo went well and the working group is enthusiastic is an agency that hasn't asked the identity and compliance questions yet. That gap is your opening. You're the person who knew what questions to ask before the ATO review did.
Change management work is real and it matters. Workforce resistance can kill a deployment that's architecturally sound. A deployment that's architecturally incompatible with the enterprise never gets to the point where workforce resistance is the binding constraint. The pilots that cleared every people hurdle and still don't ship were undone at inception, when nobody asked whether the thing they were building could ever live inside the envelope it would eventually need to inhabit.
That question is yours to ask. It's also the one that signals, more than any other, that you've actually been here before.