December 11, 2025

The Real Reason the Government Hasn't Been Able to Use AI Like Everyone Else

Federal agencies are on track to spend billions on artificial intelligence this year. State governments are racing to modernize. Defense contractors are weaving AI into everything from logistics to targeting simulations.

By Jay Cadmus

The $3.3 Billion Problem Nobody Is Solving

Federal agencies are on track to spend billions on artificial intelligence this year. State governments are racing to modernize. Defense contractors are weaving AI into everything from logistics to targeting simulations.

Yet the day-to-day reality inside most public sector teams looks very different.

You want to use Claude or GPT to analyze procurement data. To summarize vendor performance reports. To draft policy language faster. To prototype an internal tool that could save your team hundreds of hours.

But you cannot paste real data into the prompt.

Your files contain Social Security Numbers. Names. Addresses. Contract numbers. FOUO markings. CUI designations you are legally obligated to protect.

So you do not use AI at all. Or you use AI on your personal account hoping to gain some insight into the work you're doing while avoiding the data sensitivity nature around that scope. The all too-common challenge that exists.

Or you use it on fake data and pretend the results mean something.

Or you spend six hours manually scrubbing a single spreadsheet before you can safely run it through a model. By the time you are done, any productivity gain that AI promised has evaporated.

This is the dirty secret of AI adoption in government. The blocker is not access or budget. It is security.

And almost nobody is building tools that actually solve that problem.

Why AI Pilots Stall In Government

Across industry, there is a growing wave of organizations canceling or shelving AI projects after early experiments. In the public sector, the pattern is even sharper. Agencies are experimenting with AI, but very few deployments make it into daily workflows in a meaningful way.

Most postmortems blame vague factors like "lack of strategy" or "immature models." That misses what is specific about government work.

Public sector AI projects stall because they never get safe access to the real data they need.

When federal and state leaders are asked why AI adoption is dragging, they rarely talk about model quality. Instead, they point to things like:

• Data access and quality, especially where PII and CUI are involved
• Security and compliance friction that slows or blocks experiments
• Legacy IT constraints and siloed environments
• Shortage of cleared staff who understand both mission and modern tools

Official assessments describe "structural impediments to execution" and "processes for security and compliance" as major sources of friction for responsible AI. Consulting analyses of failed public sector pilots tell a similar story. Projects do not die because a model cannot summarize or classify. They die because nobody can legally give the model the real documents in the first place, or because every dataset has to be scrubbed manually before it can leave a secure enclave.

The gap is not algorithmic. It is operational. The blockers sit in data handling, security controls, and compliance workflows, not in the underlying AI capabilities.

The CUI Problem Nobody Talks About

If you work with federal contracts, you already speak the language of CUI: Controlled Unclassified Information.

CUI covers a wide range of sensitive government data that is not classified but still requires protection. Think contract details, personally identifiable information, law enforcement records, technical specifications, financial data, and countless other categories that live in your email, spreadsheets, and shared drives.

A new FAR rule finalized in 2025 standardizes how contractors must handle CUI across all agencies. Requirements include access controls, encryption, incident reporting within hours, audit trails, and continuous monitoring.

The practical problem is simple. CUI is everywhere.

Every email thread about a task order. Every spreadsheet with vendor names and rates. Every PDF with pricing information. Almost any dataset you might want to analyze with AI probably contains CUI, PII, or both.

Under current rules, you cannot paste CUI into a public cloud AI system unless that system has been specifically authorized to handle it. The same goes for legacy markings like FOUO and for anything that contains PII, which triggers its own set of privacy protections.

So when a program manager wants to use AI to analyze performance data, they face a brutal choice:

1. Do not use AI at all
2. Manually redact everything sensitive before using AI
3. Build synthetic data that tries to mimic the real thing
4. Violate policy and hope nobody notices

Option four happens more often than anyone wants to admit. Shadow AI usage is rampant. Staff quietly paste snippets from internal documents into consumer tools because IT has not given them anything better.

Options two and three are what compliant teams actually do. And they are both painful.

The Manual Redaction Trap

Manual redaction is how most agencies still handle sensitive data.

An analyst opens a document, reads through it line by line, identifies every piece of sensitive information, and either blacks it out or deletes it. For spreadsheets, they go cell by cell. For PDFs, they use Acrobat or a similar tool to mark and remove content.

Everyone who has done this knows the reality. Manual redaction is slow, exhausting, and error-prone.

A single long report can burn half a day. A large dataset can consume a week. By the time you are done scrubbing the file, the AI analysis you wanted to run feels like an afterthought.

It is even worse for video and audio. Law enforcement and public safety agencies routinely spend hours chasing faces, tattoos, license plates, and background conversations frame by frame or minute by minute to meet disclosure deadlines.

The more volume you have, the more the backlog grows. FOIA teams feel this every day. Statutory deadlines do not care that there are only so many hours in a week for someone to black out names.

And the punchline is brutal. Manual redaction is inconsistent. Different analysts catch different things. Fatigue leads to missed redactions. One overlooked Social Security Number can become a security incident, a privacy complaint, and a career-defining problem.

You cannot manually scrub data fast enough to make AI useful. You also cannot skip scrubbing without breaking the rules.

The Synthetic Data Workaround

To avoid handling real data, some agencies lean into synthetic data.

Synthetic data is artificially generated information that mimics the statistical patterns of real data without containing actual PII or mission-sensitive content. It is valuable for training models, testing pipelines, and sharing examples without exposing real records.

There is serious momentum behind this approach. Federal programs are explicitly calling for synthetic data solutions that "model and replicate the shape and patterns of real data while safeguarding privacy." Vendors and integrators are building synthetic data engines to serve that need.

Synthetic data is helpful. It is not a magic bullet.

First, it is expensive. Building high-quality synthetic datasets takes time, tooling, and expertise. You need to deeply understand the original data structures and relationships before you can mirror them.

Second, it can drift away from reality. Synthetic data preserves overall distributions and correlations. It often misses the weird edge cases and messy outliers that real-world decisions hinge on.

Third, it does not help when you actually need to analyze specific contracts, real vendor performance, or actual investigative records. You cannot answer a congressional inquiry about a particular program using synthetic data. You cannot audit real spending with fake numbers.

Synthetic data reduces some risk. It does not replace the need to safely work with real information.

What Actually Needs To Exist

Once you look past the buzzwords, the need is straightforward.

Government teams need a way to sanitize real datasets before they touch any cloud AI service. That sanitization has to happen locally, on their own machine or within their secured environment. It needs to be fast, reliable, and predictable.

In practical terms, that means:

Broad PII detection. Cover Social Security Numbers, credit cards, email addresses, phone numbers, physical addresses, dates, and more. Not just one pattern or two, but the full range of things that can tie back to a person.

Smart replacement instead of blind deletion. Blanking out "John Doe" removes context. Replacing it with a realistic fake like "Michael Smith" keeps the structure of the data while breaking the link to the real person. AI models can still find patterns because relationships remain intact.

Procurement and logistics ID coverage. Government data contains unique identifiers beyond typical PII: contract numbers, CLINs, solicitation numbers, shipping IDs, CAGE codes, and other procurement-sensitive fields that need to be sanitized before any analysis.

CUI awareness. The tool needs to recognize markings and labels that indicate the presence of CUI, FOUO, or other protected categories and warn the user before they do something risky.

Purely local operation. No APIs. No phone-home telemetry. No external logging. The data should never leave the machine until after it has been sanitized.

Optional auditing. Security and compliance teams need proof that data was scrubbed. The tool should let users export a clear record of what was detected and changed, without silently shipping that record to a third party.

That is the gap local-first scrubbing tools exist to fill.

AI Is Now Accessible. So Where Is The Disconnect?

The Department of Defense has launched multiple generative AI platforms in recent months, to include the latest, GenAi.mil. The GSA has struck deals with major AI providers to make their tools available through federal procurement channels. Cloud platforms are racing to earn FedRAMP authorizations. The message from leadership is clear: AI tools are now accessible to your agency and your teams.

That is genuinely good news. It means the bottleneck is shrinking where "there's no AI for us to use" and is now shifting over to something far more specific and far more solvable: "can we safely prepare our data to use with these tools."

Even with authorized AI endpoints, approved cloud providers, and sanctioned procurement agreements, the fundamental problem remains unchanged. Your data still contains sensitive information. Your legal and compliance obligations still forbid pasting raw datasets into systems you do not fully control.

Getting approval to use AI is only half the puzzle. The other half is figuring out what to actually feed those AI systems without breaking the law or creating a breach.

That is where the real work happens. That is where a local-first scrubbing layer fits into the workflow.

Instead of being an alternative to the new AI platforms, a local scrubbing layer becomes the front door to them. You sanitize the workbook or document on your own machine, strip or swap the PII, flag anything that looks like CUI, and only then hand the cleaned version to whatever authorized AI service your organization has approved.

As more official AI services become available across DoD, civilian agencies, and the broader federal space, the bottleneck shifts from "we do not have access to AI" to "we do not have a safe way to prepare data for these new endpoints."

Local-first scrubbing changes that equation.

Why This Matters Now

Three trends are colliding at the same time.

First, CMMC 2.0 is rolling into contracts. If you touch CUI, you are now living under a more formal, auditable cybersecurity regime. The days of informal "best effort" data handling are over.

Second, the FAR CUI rule standardizes expectations across agencies. You can no longer rely on one contracting officer's interpretation versus another. Safeguarding requirements are becoming consistent and enforceable.

Third, AI is getting easier to buy. GSA schedules now include major AI providers. Cloud platforms are racing to secure FedRAMP authorizations for their AI services. Leaders are asking the same question in every review: "Why are we not using this yet?"

If you cannot solve the "how do we scrub the data" problem, you cannot answer that question honestly. You will either block progress in the name of compliance or quietly bend the rules.

Local-first scrubbing tools are not the whole answer. But they are a critical part of it.

The Bigger Picture

The government has good reasons to be strict about sensitive data. PII protections exist because real people are harmed when their information leaks. CUI rules exist because some information, even if unclassified, provides a blueprint for adversaries if it is mishandled.

The policy isn't usually the problem. The tooling gap is.

Cloud AI services are maturing. FedRAMP boundaries are expanding. Major vendors are bringing more capabilities into authorized environments. That is all positive.

But authorization alone does not solve the front-end problem. Someone still has to decide what goes into those systems. Someone still has to scrub out the things that are never supposed to leave a given enclave.

Right now, that "someone" is an overworked human with a redaction tool and a deadline.

It does not have to stay that way.

What Is Missing

If you are tired of staring at spreadsheets with a black marker mindset, start with a local-first scrubbing layer on a real dataset. See how it changes your comfort level with bringing AI into the loop. Then pressure-test it: where does it fail, what does it miss, and what features would your security team need to bless it as a standard tool.

Because the real blocker to AI in government is not capability. It is security.

And the only way past that is to build tools that treat security as the starting point, not an afterthought.

References

• FAR CUI rule (finalized 2025): standardized contractor handling of Controlled Unclassified Information
• CMMC 2.0 cybersecurity requirements for defense contracts
• Department of Defense generative AI platforms, including GenAI.mil
• GSA agreements with major AI providers through federal procurement channels
• FedRAMP authorization program for cloud AI services