The Government Wants Your AI Product. It Cannot Legally Buy It.

Why Public Sector Behaves Unlike Every Other Segment

In commercial sales, a motivated champion can usually get a deal through security review. In federal, the champion cannot override the requirement, because the requirement does not belong to them. An authorizing official has to accept risk on behalf of the agency, and that acceptance rests on a standardized body of evidence about your system. No amount of product enthusiasm substitutes for that package.

The practical consequence is that public sector cannot be treated as an opportunistic channel you serve when an inbound lead appears. Either you decide to build toward authorization deliberately, or you decline the segment. The middle path — accepting a pilot, storing agency data, and figuring out compliance later — is where vendors get into genuine trouble.

Everything Starts With the Boundary

The authorization boundary is the definition of what is being authorized: which services, which infrastructure, which data flows, which external connections. It is drawn before the control work begins, and drawing it badly is the most expensive mistake available, because every subsequent artifact references it.

AI products tend to have messier boundaries than the framework anticipates. A typical stack might include a hosted application, a vector database, an embedding service, one or more model APIs, an evaluation pipeline, an observability platform capturing prompts and completions, and a support tool where staff can view customer content to debug a bad output. Each of those is either inside the boundary or is an external service that data leaves the boundary to reach — and the second category is the one teams routinely forget to enumerate.

The Model Provider Problem

Most AI products do not run their own models. That means a critical processing step happens at a vendor whose compliance posture you inherit and cannot change. If that provider offers an authorized government-facing offering, you may be able to leverage it and route agency traffic there. If it does not, you are left with unattractive options: self-host an open-weight model inside your boundary, degrade the product for government tenants, or wait.

This creates an architectural argument worth having early. A system with a hard abstraction between application logic and inference — where the model endpoint is a swappable dependency rather than an assumption baked into a hundred call sites — can redirect government traffic to a compliant deployment without a rewrite. A system that hardcodes one provider's SDK throughout cannot. That decision costs almost nothing at the start and is nearly impossible to retrofit later.

Where the Control Framework Meets Nondeterminism

Cloud control catalogs were written for systems that behave the same way twice. They ask for configuration baselines, change control, integrity verification and defined system behavior. Generative components strain several of those assumptions in ways assessors are still working out.

• Change control versus model updates: if a provider silently updates a model behind a stable endpoint name, your system's behavior changed without a change ticket. Pinning versions where possible and documenting how you learn about updates is the minimum defensible answer.
• Audit logging of AI actions: where the system takes actions rather than returning text, the log must show what was proposed, what was approved, by whom, and what executed. "The assistant did it" is not an audit trail.
• Data retention in prompts and outputs: prompt logs are often the highest-sensitivity store in the whole system and the one with the least deliberate retention policy, because it grew out of debugging.
• Least privilege for a system that reads everything: retrieval components tend to be given broad access for convenience. Under assessment, "the index can see all tenant documents" is a finding, not an implementation detail.
• Personnel and location requirements: some government-facing offerings carry expectations about who can access systems and from where, which affects hiring and support staffing, not just infrastructure.

StateRAMP Is Usually the Realistic First Door

State and local agencies buy considerably more software than most vendors assume, and the state-level program serving them shares a control foundation with the federal one. For a small AI company, the sequence that tends to work is to win state or municipal business first, build the evidence base and operational habits while the stakes are lower, then extend toward federal with most of the documentation already written.

The evidence overlaps but the programs are distinct, so be careful with how you describe your status. Claiming a posture you do not hold, or blurring "working toward" with "authorized," is both a sales problem and a representation problem — and in government contracting, representations carry consequences that commercial marketing copy does not.

What to Do Before You Spend Anything

1. Identify a specific agency or state entity that wants the product. Authorization work without an identified buyer is speculative capital.
2. Draw the real boundary on one page, including every external service that touches customer input or output — logging and analytics included.
3. Determine your inference path's compliance status. If your model provider has no government-facing offering, decide now whether you would self-host.
4. Read your own terms of service as an agency lawyer would. Training rights, subprocessor lists, data location and retention are the clauses that end deals.
5. Audit your public site for claims you would have to substantiate — certifications, "government-ready," security assertions, and anything implying a status you have not obtained.
6. Budget for the recurring obligation, not the project. Continuous monitoring is staffing, not a line item that ends.

Frequently Asked Questions