The Government Can’t Adopt AI at Yesterday’s Speed

In early June, the White House issued an executive order aimed at accelerating the federal government’s adoption and secure use of advanced AI. The directive calls on agencies to prioritize cyber defense, expand programs that put AI-enabled defensive tools to work, and facilitate access to frontier models.

But encouraging agencies to adopt AI is only half the battle. The harder part is creating the conditions to put those capabilities to work.

AI moves fast. The most capable models from OpenAI, Anthropic and Google can change within weeks. Government software authorization operates on an entirely different timeline. An authorization can take months, if not years. An agency restricted to already-authorized models can find itself effectively going back in time compared with what is available commercially.

For agencies responding to the executive order, the goal is speed — but not at the expense of context or mission security. That means first recognizing when the technology changes and then clearing the processes that prevent teams from acting on it. Agencies also have to get much more deliberate about where security boundaries actually belong.

Change is the only constant

Sports media leaned on a phrase that has become something of a meme this year. Whenever a big trade might be coming, everyone is “monitoring the situation.” Government technology teams should be doing the same thing with AI.

News could break tomorrow that materially changes what an agency can do. A model could receive an authorization teams have been waiting for, or a new capability could become available. Teams that recognize it and adapt within a day or two gain a real advantage over teams that find out months later.

This task doesn’t belong to one person with AI in their title either. An entry-level employee who spots an important development can create value by sharing it. So can a CISO who recognizes that the same development unlocks something the organization has been waiting for. Staying current must become part of how the organization operates.

Make authorization continuous

Of course, paying attention to change only matters if your processes allow you to act on it.

A typical authorization can take six to eight months, with some taking more than a year. Much of that effort goes into producing the system security plan, where one or two people are responsible for writing substantial explanations of how a system meets hundreds of individual requirements.

AI can attack that bottleneck directly. If it has secure access to the system context, it can accelerate the initial documentation and help keep it current as the system changes.

I’ve seen the difference firsthand. About four years ago, I helped produce a system security plan that received glowing reviews across the agency. It took a team of five or six people roughly six months. Last month, I used AI to create something that was probably 75% of the way there in a day. Six months to one day is an enormous shift. But the lesson isn’t that AI can write compliance documentation faster. 

We should be wary of spending months authorizing individual AI products when those products are changing every few weeks. The more durable goal is a secure process for continuously adopting new capabilities. Build that, and AI starts to compound the gains of Continuous Delivery and Continuous Authorization—and where the ambition of the executive order starts becoming operationally realistic.

Build low, ship high

No magic model resolves the tension between access and security. Sometimes, the right decision is to accept the limitations of an authorized model.

If you’re working in a sensitive customer environment, access to the project context may be far more valuable than access to the newest commercial model. A secured model available through a service like AWS Bedrock may be more expensive or less capable than what you can access through a commercial Claude subscription. 

Still, the entire project doesn’t need to operate within the same constraints. Teams should get much more granular about where that security boundary needs to exist. One useful principle is to build low and ship high. Find the portions of the project that don’t require sensitive information, build those locally using the best commercially available tools you’re permitted to use, then move that work into the secured environment.

The catch is context. Claude can’t mind-read your project. If the model can’t see the folders, code, or project information, you have to be much more deliberate about guiding it. You need to give it enough context to be useful without giving it the secured information it shouldn’t have. Guiding it that way is an art, and right now a lot of the industry is still figuring out where that balance makes sense.

You’re not trying to eliminate tradeoffs. You’re trying to understand them well enough to apply security constraints where they’re necessary, instead of everywhere by default.

From policy to practice

Ultimately, an executive order can create urgency, but it can’t resolve these questions for agencies. The technology is changing too quickly, and teams are starting from very different places. Broad policy can point everyone in a direction, but the specifics have to come from inside, where practitioners are putting these tools to work.

You gather peer intelligence fastest in person. Prodacity, Rise8’s three-day training event where GovTech leaders learn to ship mission-critical software faster, August 25-27 in Nashville, puts you in a room with people shipping under the same mandates, compliance, and timelines you are, and includes discussions about what AI-native tools are making possible right now. 

For government agencies, closing the gap with the commercial sector takes the right conditions more than raw speed: people who notice when the technology moves, and processes that let them act. The six-month document became a day of work because I sat down and tried it. The rest of the specifics will come the same way.