Government AI: Inside the Authorization Boundary, Under Public Records Rules

Sometimes, and the constraint is authorization rather than policy preference. A hosted AI service handling federal data generally needs FedRAMP authorization at an impact level appropriate to that data, and several providers now hold authorizations at the lower and moderate levels. What does not transfer is the authorization itself covering your specific use — the agency still assesses and accepts the risk. For sensitive categories, or where procurement timelines make a new authorization impractical, deploying open weights inside an already-authorized boundary is frequently the faster route.

Treat them as though they do. Records law generally attaches to material made or received in the course of official business, and a prompt that informs an agency decision fits that description comfortably. The practical consequence is architectural: capture the interaction into a records system with retention by schedule, rather than letting it live in a tool's temporary log. Agencies that skip this discover the problem when the first request arrives and the material has already aged out. Confirm the specific classification with your records officer.

Both can sit inside an authorized boundary; they differ in who operates the hardware and how quickly you can scale. Authorized government cloud regions give you elasticity without a datacentre, at the cost of an ongoing provider dependency and a boundary that includes their service. On-premise gives you the tightest control and the simplest boundary story, which matters most for the highest impact levels and for genuinely disconnected sites. Because the weights are portable either way, this is a deployment decision you can revisit without rebuilding.

Keep a human accountable for the determination and document the system accordingly. Federal AI governance policy singles out rights-impacting and safety-impacting uses for additional practices — impact assessment, testing, monitoring, and public transparency — so the first step is classifying honestly which category a use case falls into. In practice most successful public-sector deployments start well away from that line: drafting correspondence, summarising case files, and answering staff questions against policy documents, where the official still decides.

More often than expected, because the hardware requirement is modest for the workloads that matter. A single 24 GB GPU running a 32B-class model serves a program office for drafting and retrieval, at a capital cost comparable to a few staff laptops and no per-token bill afterwards. The larger cost is usually the integration and governance work rather than the GPU. Start with one well-scoped use case, size it with our compatibility checker, and expand once the value is demonstrated rather than procuring for a hypothetical peak.