There is a particular sentence that ends many otherwise-promising government AI pilots, and it is not "the tool didn't work." It is "the tool worked, and it turns out we were never authorized to use it this way." Government agencies and their contractors carry a records-processing burden at least as heavy as any private-sector industry — benefits administration, case management, procurement documentation, the endless correspondence that keeps a bureaucracy accountable to the public it serves — but they operate under a compliance bar that is categorically different in kind from the private sector, not merely higher in degree. In the public sector, the first question is never "is this tool effective." It is "is this tool lawfully authorized to touch this data at all," and that question has a definite, checkable answer that exists independently of how well the tool performs.
1. FedRAMP as the Cloud Gatekeeper
The Federal Risk and Authorization Management Program establishes a standardized, government-wide security assessment that cloud services must pass before they may lawfully process federal data, regardless of which specific agency wants to use them. It exists precisely to prevent every agency from having to independently re-evaluate every vendor's security posture from scratch, which sounds efficient in principle but has a hard edge in practice: a commercial AI tool without FedRAMP authorization cannot be used to process federal data for this purpose regardless of its capability, its price, or how much a program office wants to use it. This is a bright-line rule, not a risk-tolerance judgment left to the discretion of the procuring office, and treating it as negotiable is the single most common way well-intentioned pilots turn into compliance incidents.
The practical difficulty is that FedRAMP authorization is a genuinely lengthy, resource-intensive process, which creates a real temptation to route around it — to use an unauthorized commercial tool "just for testing," or to process a supposedly de-identified subset of data through it on the theory that de-identified data escapes the requirement. Neither workaround reliably holds up. The authorization requirement attaches to the system processing federal data, not to a subjective judgment about how sensitive that particular batch happens to be, and "just for testing" has a way of becoming permanent the moment a program office discovers how useful the pilot actually is.
2. CMMC and Controlled Unclassified Information
For Department of Defense contractors specifically, the Cybersecurity Maturity Model Certification 2.0 program layers additional, more specific requirements on top of FedRAMP, built on the NIST SP 800-171 control set for protecting Controlled Unclassified Information, commonly abbreviated CUI. What makes CMMC distinctly consequential for AI workflow tools is a scoping principle that catches many organizations by surprise: the boundary of a CMMC assessment expands to cover every system CUI passes through, full stop, including a workflow automation tool that was procured for an entirely different, seemingly unrelated purpose, the moment that tool ever touches CUI in the ordinary course of its use.
This means a contractor cannot meaningfully narrow its CMMC assessment boundary by simply not thinking too hard about which systems touch CUI — the assessment boundary is a fact about the data flow, not a fact about what the contractor intended when it bought the tool. An innocuous-seeming productivity tool that an employee uses to summarize a document containing CUI, even once, even informally, has pulled that tool inside the assessment boundary as a matter of scoping methodology, whether or not anyone updated the System Security Plan to reflect it.
3. Contractual Flow-Down
Obligations under FAR Subpart 4.19 and DFARS 252.204-7012 do not stop at the prime contractor; they flow down through every layer of subcontractors, and a workflow automation vendor is, functionally, a subcontractor the moment it touches contract-related data, whether or not the contracting officer's representative ever saw that vendor's name in a subcontracting plan. An agency or contractor cannot procure around this obligation by internally classifying the AI vendor as "just a tool" rather than a subcontractor — the flow-down clauses attach based on what the vendor actually does with the data, not on the internal label a procurement team assigns to the relationship on paper.
This creates a genuine tension for contracting officers under deadline pressure: the AI vendor selling the workflow tool is very unlikely to describe itself, in its own marketing, as a subcontractor subject to DFARS flow-down clauses, and its standard commercial terms are usually written for an ordinary SaaS customer, not for a defense-contract subcontractor. Closing that gap — getting the vendor to actually accept flow-down obligations in writing, or confirming through independent means that the vendor already holds the relevant certifications — is unglamorous, time-consuming diligence work, and it is also the work that actually determines whether the contractor is exposed.
4. Architecture as the Practical Answer
A fully on-premises or edge deployment — processing entirely inside the agency's or contractor's own accredited enclave — keeps CUI from ever crossing into a cloud boundary in the first place, which is very often a more tractable path in practice than pursuing FedRAMP authorization for a given workflow tool, particularly for a smaller contractor without the resources to sponsor or wait out a full authorization process. If the data never leaves the accredited enclave, the FedRAMP cloud-authorization question and much of the CMMC boundary-expansion problem simply do not arise for that specific workflow, because there is no cloud service in the data path to authorize.
A masked secure-cloud model remains entirely appropriate for genuinely non-sensitive, non-CUI administrative workloads — routine public-facing correspondence, unclassified scheduling, general research assistance that never touches contract-specific technical or program data. But the classification decision separating these two categories has to be made deliberately, documented in writing, and revisited as workflows evolve, not assumed once at the start of a project and left unexamined as the tool's usage quietly expands into adjacent, more sensitive territory over the following year.
5. The Audit Conversation, in Practice
When a CMMC assessor or an agency inspector general's office actually reviews an AI deployment, the conversation rarely turns on whether the underlying technology is impressive. It turns on a small number of blunt, specific questions: can you show me the System Security Plan entry for this tool, can you show me the data flow diagram that proves CUI does or does not pass through it, and can you show me the flow-down documentation for the vendor if it does. An organization that built its deployment around a clear, documented boundary — this workflow runs entirely on our own accredited infrastructure, this other workflow runs on an authorized cloud service, and here is the paperwork for each — answers those questions in minutes. An organization that never drew that boundary deliberately spends the audit reconstructing it after the fact, under considerably more pressure and with considerably less credibility.
This is, in the end, the same lesson that recurs across every regulated industry this series has examined, restated in the specific vocabulary of federal procurement: the deployment-model decision is not a technology detail to be resolved by whichever team happens to own IT purchasing. It is the compliance decision, expressed in architecture, and it deserves the same deliberate, documented attention as any other clause in a federal contract.
6. Conclusion
In government deployment, the architecture decision is inseparable from the authorization question, and there is no way to fully decouple the two, no matter how good the underlying AI tool is. An agency or contractor that treats deployment model as an afterthought, settled implicitly by whatever tool a program office happened to select, has in practice made the compliance decision by default rather than by design — and default is very rarely the answer that survives an audit, a CMMC assessment, or an inspector general's inquiry.