A commercial AI product that sells well to banks or insurers usually arrives at its first federal opportunity in good shape and still loses a year. The loss is rarely about the model. It is about everything wrapped around the model: where the software runs, who signed off on the security of it, what documentation exists describing how the thing makes a decision, which contract instrument the agency can put the money on, and whether anyone inside the program office has a reason to spend political capital getting it in. Those five items are the product for a federal buyer. The company that treats them as engineering work, scoped and staffed like any other release, moves a year faster than the company that treats them as paperwork to be handled later.
This is written for the person who owns that decision at a commercial AI company: the chief executive, the head of public sector, or the product leader who has just been told by a sales rep that a federal agency is interested and the pilot has to run inside the agency's own environment by the end of the quarter. What follows is the sequence, what to build, what to write down, and where the calendar actually goes.
What an agency is buying when it buys AI
Commercial buyers of AI buy an outcome and accept the vendor's word about the plumbing. Federal buyers cannot. A government program manager is personally accountable for a system that touches government data, and the accountability is written down: an authorizing official signs a document accepting risk on behalf of the agency, and that signature is what makes the software usable. Everything the agency asks a vendor for traces back to making that signature defensible.
So the questions arrive in a different order than a commercial sale. Where does the data go. Who has administrative access. What happens when the model produces a wrong answer someone acts on. Which controls does the system inherit from its hosting platform and which does the vendor implement. Can a person with a screen reader use the interface. What is the retention posture for model inputs and outputs. None of these are hostile. They are what the authorizing official will ask the program manager, forwarded upstream.
The commercial answer to most of them is a page on a trust portal. The federal answer is a control implementation summary, a system security plan, and evidence an assessor looked at the running system rather than its description. The gap between those artifacts is the first year.
The five gates, in the order they bite
Agencies do not run a single approval. They run several, each owned by a different office, and a product can clear four and stall on the fifth for a quarter. Naming them separately lets the work be assigned to different people at once rather than queued.
What decides whether a commercial AI product clears an agency gate
Editorial weighting, illustrative rather than measured. The last row is low because it is the gate companies most often discover they have already failed.
Gate one: the deployment model
The first question an agency asks about an AI product is where it runs. A single-tenant commercial cloud instance the vendor operates is one answer. A deployment inside a government cloud region the agency already has an accreditation for is a different and much easier answer. A container the agency runs itself inside its own boundary is easier still for the agency and hardest for a product built as multi-tenant software.
Products built with a single control plane, shared databases keyed by tenant, and a deployment pipeline that assumes one production environment cannot be dropped into an agency boundary without engineering. That engineering is real and it is bounded. It usually means separating the control plane from the data plane, making every external dependency configurable or optional, replacing managed services that have no government-region equivalent, removing outbound calls that cannot be justified in a network diagram, and building a deployment artifact that installs from a single manifest without any operator having access to the vendor's own infrastructure.
The failure mode is discovering in week nine of a pilot that the product phones home to a telemetry endpoint, or depends on a third-party service with no presence in a government region. Every outbound network call is a line item in a security review. Inventory them before the agency does.
Gate two: the authorization
An agency will not run a system on its network without an authority to operate signed by an authorizing official, and the path to that signature depends on how the software is delivered. Software hosted by the vendor and offered to multiple agencies goes through FedRAMP, which is a government-wide program with a published control baseline and an assessment by an accredited third party. Software installed inside an agency's own accredited environment is assessed by that agency against the same underlying control catalog, NIST SP 800-53, but under the agency's process and on the agency's calendar.
The second path is often faster for a first deployment, and companies skip past it because their sales motion assumes a hosted product. If the agency already runs an accredited platform and the product installs onto it as an application inheriting the platform's controls, the assessment scope shrinks to the application layer. That is quarters versus months.
Either way, the work is the same shape: a system security plan describing every control and how it is met, evidence for each, a plan of action for the ones not fully met, and a continuous monitoring commitment describing what gets scanned and reported after the signature. This is writing, and it is writing that only engineers can do accurately, which is why it slips. Assign it as a deliverable with a date.
Gate three: the model documentation
Federal reviewers of AI systems ask a set of questions that a commercial buyer usually does not. What data trained the model and does the company have the right to use it for that. What does the system do when it is uncertain. How does a person override it. What is measured, on what data, at what interval, and who sees the measurement when it drifts. What is logged when the system makes a decision, and can that log reconstruct the decision months later when someone asks.
Companies selling into banks have often done a version of this already, because model risk management practice in regulated finance demands documentation of model development, validation and ongoing monitoring, with independent review. That work translates. The vocabulary changes and the audience changes, but a company that can produce a model development document, a validation record and a monitoring plan for a bank supervisor is most of the way to what a federal reviewer wants.
Companies that have never faced that audience build the artifact from scratch, which takes weeks because it means reconstructing decisions made informally. The reconstruction is worth doing on its own merits: most teams find at least one measurement they thought they had and did not.
Gate four: procurement
An agency that wants a product still needs a way to buy it. The government does not have one way; it has many, and the one available depends on the agency, the dollar amount, the urgency and what vehicles the company or a reseller already holds. A small first purchase can go on a purchase card or a simplified acquisition. A larger one usually rides an existing contract vehicle, a government-wide acquisition contract, or a competed award.
The practical point for a product company is that the procurement path should be chosen before the pilot begins, not after it succeeds. A pilot that works and has no purchase path attached to it becomes a pilot that gets repeated next year with a different program office. Ask the contracting officer, early and directly, what instrument they intend to use for the follow-on and what the ceiling on it is. That conversation is normal and welcome.
Gate five: the champion
The last gate is a person. Government programs are staffed by people carrying more work than time, and moving a new system through five reviews is a serious personal expenditure for whoever does it. Nobody does it for a product they merely find interesting. They do it for a product that removes a specific thing that is currently ruining their quarter.
This changes what a first meeting is for. The useful first meeting is not a demonstration. It is a conversation in which the company learns which of the program's measured obligations is being missed, and then shows, in a follow-up, exactly how the product moves that number. The demo comes second and it is aimed at a problem the program already reports on.
What to build versus what to document
Companies waste the most time in the gap between these two categories. Some federal requirements are satisfied by writing something down accurately. Others require the software to change. Sorting them on day one prevents a quarter of thrash.
| Requirement | Usually documentation | Usually engineering | Where it hurts if deferred |
|---|---|---|---|
| Data residency and boundary | Network and data-flow diagrams | Removing outbound dependencies; region-specific builds | Week nine of a pilot, when a scan finds an unexpected egress |
| Identity and access | Access control policy, role definitions | Federated sign-on, hardware-token support, per-role authorization | The agency cannot onboard users at all without it |
| Audit logging | Retention policy and log inventory | Immutable decision logs with model version and inputs | The first incident review, when the log cannot answer the question |
| Accessibility | An accessibility conformance report | Keyboard paths, contrast, labels, focus management in the product | Procurement, where a conformance report is often required to buy |
| Model behavior | Development, validation and monitoring records | Measurement suite, drift detection, override path in the interface | The technical evaluation, where a reviewer asks for evidence |
| Encryption | Key management description | Validated cryptographic modules; customer-managed keys | Assessment, where a non-validated module is a finding |
The pattern is visible. Documentation without the underlying engineering is what produces a plan of action full of open items, and a long plan of action is what makes an authorizing official hesitate. The reverse, engineering without documentation, produces a system nobody can approve because no one can describe it. Both halves ship together or neither counts.
The architecture that survives an agency review
A commercial AI product that will be deployed inside agency boundaries has a recognizable shape, and it is worth designing toward it even before the first federal opportunity, because the same shape sells better to large regulated commercial buyers too.
The control plane separates from the data plane. Licensing, telemetry, feature flags and update distribution live in the vendor's own systems. Inference, data storage and user interaction live entirely inside the customer's environment, with no requirement to reach the vendor for the system to function. An agency deployment that stops working when the vendor's cloud has an outage will not be approved.
Every external dependency is optional or replaceable. Model weights are packaged with the deployment or pulled from a registry the agency controls. Third-party enrichment services have a configuration that disables them. Anything that cannot be made optional becomes an explicit part of the boundary description, with its own justification.
Configuration is data, not code. An agency will run a version of the product that differs from the commercial one in identity provider, network egress, logging destination, retention and enabled features. If those differences live in branches, the federal build diverges within two releases and becomes unmaintainable. They belong in configuration validated at startup.
The deployment artifact is one thing. A container image set with a manifest, an infrastructure-as-code definition, and a documented install that a government engineer can run without vendor credentials. This is also the artifact an assessor scans, so its contents need a software bill of materials that is generated by the build rather than maintained by hand.
Decision logging is a first-class feature. For every inference that affects an action, the system records the model version, the inputs or a hash of them where inputs are sensitive, the output, the confidence, whether a human overrode it, and the identity of the person who acted. This is what makes the system defensible when something goes wrong, and it is nearly impossible to retrofit because the information has to be captured at the moment of the decision.
Accessibility is in the component library. Keyboard navigation, focus management, semantic markup, contrast and screen-reader labels belong in the shared components, not in a remediation project. Retrofitting accessibility into a mature interface costs several times what building it in costs, and Section 508 makes the requirement part of what the government may buy.
Where the calendar goes on a first agency deployment
Editorial weighting, illustrative rather than measured. The last row is low because the model is almost never the thing that costs the year.
The failure modes we see repeatedly
The pilot runs somewhere the production system can never run. A team stands the pilot up in a convenient commercial account with a copy of agency data, gets a good result, and then discovers that nothing about the environment transfers. The pilot proved the model and proved nothing about deployability, which was the actual question. Build the pilot where the system will live, or against a written accreditation path from the first week.
Accuracy is claimed in marketing and not measured in the product. A number that appears on a website and cannot be reproduced by a measurement inside the system is a liability once a federal reviewer asks how it was computed. Either instrument the product to produce the number continuously on real data, or stop stating it.
The security questionnaire is answered by sales. Answers that overstate the posture are found during assessment, and being found is much worse than having a gap. An engineer answers the questionnaire, with a plan of action attached to anything not yet true.
The product's data handling was never designed for someone else's data. A system that trains on customer inputs by default, or that ships inputs to a third-party model provider, needs both a switch and a written description of what the switch does. Discovering that in a review costs the deal.
Nobody owns the government configuration. A federal deployment with no named engineer drifts. Two releases later the government build fails to start, and there is no test that would have caught it. The government configuration needs a continuous integration job like any other supported configuration.
How an engineering partner shortens the first year
Precision Federal builds AI, data platforms, software and cloud systems and delivers them into production, including inside federal agencies. For a commercial AI company entering that market, we work inside the company's engineering organization rather than beside it, and the work divides into three parts.
The first three weeks are an assessment with an output. We read the architecture, the deployment pipeline, the dependency inventory and the interface, and we return a written gap list against the deployment model the target agency actually uses: what has to change in the software, what has to be written, what can be inherited from the hosting platform, and what each item costs in engineering weeks. The list is specific enough to schedule against. Companies use it to decide whether to enter at all, which is a legitimate use.
Then we build the parts that are ours to build. Separating the control plane, replacing dependencies that do not exist in government regions, adding federated identity and hardware-token support, building the decision log, generating the software bill of materials in the build, remediating accessibility in the component library, and standing up a continuous integration job that keeps the government configuration working. This is ordinary engineering delivered against acceptance criteria written as tests: a deployment that installs from a clean checkout into a government-region environment, an interface that passes an accessibility audit, a log that can reconstruct a decision.
And we write the documentation as engineers. The system security plan, the control implementation summary, the data-flow and boundary diagrams, the model development and monitoring records. These are written by the people who built the system, which is why they survive contact with an assessor.
What the company keeps. All of it. The code is the company's code, assigned in writing, committed to the company's repositories from the first day. The data is the company's data and the agency's data; we do not hold either. The customer relationship belongs to the company, and we are visible or not visible in front of the agency as the company prefers. Our pre-existing tooling is named in the agreement, carved out of the assignment, and licensed to the company perpetually so nothing we bring can strand a future maintainer.
How it is priced. Two shapes. Fixed-price milestones where the scope is knowable, which fits the assessment, the documentation package and most of the deployment work. Or a committed team for a stated number of months where the work is exploratory and the company wants capacity it can point at what the agency asks for next. Companies commonly start with the first and convert to the second once the agency relationship is live.
The first step is one email with a one-page brief: what the product does, where it runs today, which agency or program is interested, what the interest is attached to, and the date that matters. We return a scoped, priced statement of work.
A sequence that works
For a company starting from a commercial product and a warm agency contact, the order that loses the least time is this. Confirm the deployment model the agency will accept, in writing, from someone who can say it. Choose the authorization path, hosted or inherited, and price both. Run the dependency and egress inventory, because it determines the engineering scope and takes a week. Start the accessibility remediation immediately, because it is independent of everything else and is the item most likely to block a purchase. Ask the contracting officer what instrument the follow-on will use. Build the pilot in the destination environment. Write the security documentation during the build, not after. And keep one engineer accountable for the government configuration from the first commit.
Done in that order, a company with a working commercial product is usually deployed in an agency inside two to three quarters rather than five or six. The compression comes almost entirely from running the five gates in parallel instead of discovering them one at a time.
Bottom line
Federal agencies buy commercial AI, and they buy it on terms that are knowable in advance. The product has to be able to run inside somebody else's boundary. The security posture has to exist as evidence rather than as claims. The model has to be documented well enough that a reviewer can reason about how it fails. A purchase path has to be chosen before the pilot rather than after it. And a person inside the program has to want the outcome enough to carry it. Every one of those is engineering work with a schedule, and a company that treats it that way arrives a year ahead of a company that treats it as friction.
Frequently asked questions
The variable is not sales cycle length but how much of the work is done in parallel. A company that discovers the deployment model, the authorization path, the accessibility requirement and the purchase instrument one at a time usually spends five or six quarters. A company that starts all of them in the first month, with engineering assigned to each, is commonly deployed in two to three quarters. The engineering work itself is bounded and estimable once the dependency inventory exists.
Not always. FedRAMP applies to cloud services the vendor hosts and offers to agencies. Software installed inside an agency's own already-accredited environment is assessed by that agency against NIST SP 800-53 under the agency's own process, and the application inherits controls from the platform it runs on. That path is often faster for a first deployment. Which path applies depends on how the product is delivered, so decide the delivery model first and the authorization route follows from it.
What data trained it and the right to use that data, what the system does when uncertain, how a person overrides it, what performance is measured and how often, what happens when the measurement drifts, and what is logged for each decision so it can be reconstructed later. Companies that already produce model development, validation and monitoring records for financial supervisors have most of this and need to change the audience and vocabulary rather than the substance.
Because no purchase path was chosen before the pilot started. A successful pilot with no instrument attached to it has nowhere to go, and the program repeats it the following year rather than buying. The fix is to ask the contracting officer, at the start, what vehicle the follow-on will ride and what its ceiling is. A pilot designed backward from a known purchase path converts. One designed only to prove the technology usually does not.
Typically: separating the control plane from the data plane so the system runs without reaching the vendor, removing or making optional every outbound dependency, replacing managed services with no government-region equivalent, adding federated sign-on and hardware-token support, generating a software bill of materials in the build, adding immutable decision logging, and moving environment differences into validated configuration rather than branches. An inventory of outbound network calls is the fastest way to size that work.