The Contract Is Not the Finish Line
Public-sector AI procurement is the subject of this series, and its central question is deceptively simple: what remains for an agency to govern after it has chosen a vendor and signed a contract? The answer matters because agencies are using AI for mission work ranging from veteran services and administrative support to disaster response and defense. This series gives readers a way to judge the whole acquisition—not just the award—by tracing how requirements, rights, testing, operating conditions, public accountability, and institutional learning fit together.
The decision is bigger than the award
A public agency does not acquire “AI” in one uniform form. It may buy a model, license software, obtain computing infrastructure, commission development, purchase testing, or subscribe to a service that produces outputs over time. In each case, the agency is connecting a vendor’s capability to a public mission, a set of data, an internal workflow, and people who may be affected by the result. Procurement is therefore not just a financial transaction between buyer and seller. It is the point at which an institution decides what it needs, what it will accept as evidence, what it must be able to see, and which responsibilities it will retain.
The scale of that decision is growing. The Government Accountability Office reported in 2026 that federal agencies more than doubled their use of AI from 2023 to 2024, according to the Federal Chief Information Officer. GAO’s review of selected acquisitions found agencies experimenting with several ways to obtain these capabilities, while facing recurring problems involving expertise, data and intellectual-property rights, requirements, testing, time, and cost. The report’s most consequential finding is not that agencies lack interest in AI. It is that they are often learning how to acquire it separately, without a reliable way to preserve and transfer what earlier acquisitions have taught them.
The federal response already recognizes that the acquisition cannot be isolated from later use. GAO describes Office of Management and Budget guidance organized around three aims: maintaining a competitive AI marketplace, tracking performance and managing risk, and bringing the right functions into the process. Those aims reach across pre-award planning, award terms, and post-award oversight. They also reveal why procurement is a useful place to begin without being a sufficient place to stop. A solicitation can ask for portability or testing, but only operation can show whether the promised capability performs for the agency’s actual users. A contract can assign rights, but only later decisions reveal whether those rights are usable when the agency needs to share data, investigate a failure, or leave a vendor.
That creates a tension that cannot be resolved by choosing either speed or caution as a general principle. Faster access can matter when a capability supports a time-sensitive mission or when the market is changing quickly. Yet an agency that moves quickly without securing meaningful performance measures, data rights, or access to technical expertise may discover later that it cannot tell whether the system works, why it failed, or how to change suppliers. Conversely, a process that adds every possible review without regard to risk can consume scarce public capacity and make a useful capability obsolete before deployment. Responsible procurement has to make this trade-off explicit rather than hiding it behind the word “efficient.”
The first correction, then, is conceptual. A contract award is a control point, but it is not proof that control has been secured. It records an agreement about what a vendor will provide under specified conditions. It does not, by itself, guarantee that the conditions will remain stable, that the performance claim will hold in a new setting, or that the agency will retain enough leverage to respond when reality changes.
In this context, control has a practical meaning. It is the ability to ask a consequential question and obtain an answer that can change what the agency does. Can the agency measure performance with data that reflect its population? Can it tell whether a new version is materially different? Can it require a vendor to correct a problem, preserve evidence, or explain an output well enough for a responsible official to review it? Can it move the service, restrict its use, or stop it without losing access to essential records? These are not all questions for the contracting officer, and not all can be solved in contract language. But if they are never anticipated before award, the agency may discover that its formal authority is larger than its practical ability to act.
Two clocks run at once
Federal acquisition has a familiar rhythm: pre-award work defines the need and prepares the solicitation; the award phase evaluates offers and selects a provider; the post-award phase administers the contract and oversees performance. AI introduces another rhythm. Its lifecycle runs through design, development, deployment, and continuous monitoring, and those stages can be iterative rather than neatly sequential. A model can be updated. New data can change the environment in which it operates. A service can alter its outputs or pricing. Staff can adapt their behavior to its recommendations, producing a workflow unlike the one evaluated at the start.
Those two clocks meet at the award. Before the award, the agency has its strongest opportunity to define the mission outcome, assemble the right expertise, require useful tests, and negotiate rights over data, outputs, security, portability, and future changes. After the award, it must use those foundations to observe the deployed capability, challenge vendor claims, authorize or constrain use, and decide whether to renew, remediate, replace, or stop it. If the pre-award work treats the capability as a finished product, the post-award team may inherit a service it cannot independently evaluate. If the post-award work is treated as routine administration, a change in the model or in the people and data around it can become a governance event without anyone naming it as one.
The award therefore has two jobs. It should make the initial exchange clear enough to authorize a responsible start, and it should preserve enough information and leverage for later decisions. The second job is easy to overlook because it produces no immediate spectacle. A requirement for independent testing may sit unused if the first deployment goes smoothly. A clause about data rights may seem abstract until another public partner needs the output. A record of why a model was rejected may appear unnecessary until a similar proposal arrives under a new name. The value of these provisions is revealed by change, not by the signing ceremony.
This is also why “post-award” should not be read as a single final phase. It contains ordinary administration, but it can also contain a new round of design and evaluation. An agency may need to redefine a performance measure after learning how users actually interact with the system, or to revisit the risk of a workflow after an update changes its capabilities. The process is still procurement of public capability, even when the immediate action is monitoring, remediation, renewal, or exit.
The following loop captures the basic relationship:
The loop does not mean that every AI system changes in the same way, or that monitoring can predict every failure. It means that completion has to be defined more carefully. An agency may complete a solicitation and award while still having an unfinished governance problem: how to recognize a material change, who has authority to act, what evidence counts, and what happens when the capability no longer serves the mission. The 2024 analysis of Canadian and World Economic Forum procurement checklists reaches a similar conclusion from a different direction. A checklist can remind an expert to examine important categories, but it cannot turn a generalist into an AI evaluator or make an imperfect audit complete.
Three kinds of gap follow from this distinction. The first is an evidence gap: the agency has a performance claim but no dependable way to test it against the people, data, and conditions of actual use. The second is an authority gap: officials observe a problem but lack clear rights, responsibilities, or contractual remedies to respond. The third is a learning gap: the agency handles an incident or retires a system, but does not preserve the context and reasoning that would help the next acquisition. These gaps can coexist. A technically sophisticated team may still be unable to share model outputs because rights were not secured. A detailed checklist may still fail to surface a problem if no expert can interpret the vendor’s answer. A successful pilot may still teach little if its assumptions and limitations disappear when the project closes.
The checklist experience is valuable precisely because it exposes this institutional boundary. The Canadian directive and the World Economic Forum guidance place responsible questions inside procurement, but the researchers found that technical assessment requires expertise and that no expert audit will catch everything. Public transparency can allow people outside the original review team to identify a missed concern and help refine future standards. In other words, a governance process has to be designed for correction. It should not assume that the person who completed the form, the vendor who supplied the evidence, or the official who authorized deployment has the only relevant perspective.
The question this changes
Once procurement is viewed as a lifecycle, the useful question is no longer simply, “Did the agency follow the acquisition procedure?” It becomes: did the agency buy enough knowledge and leverage to govern the capability it is introducing? That question has several practical parts. Were the requirements specific enough to test? Were the agency’s data and intellectual-property interests protected? Could an independent evaluator examine performance with data the vendor did not control? Did the contract account for updates, operating costs, and exit? Could operators challenge an output rather than merely approve it? And would the agency record a failure or retirement so that the next buyer did not start from zero?
These questions keep the public institution and its relationships in view. Vendors may develop or update the core capability. Contracting officials translate mission needs into enforceable terms. Technical, legal, privacy, security, and domain experts interpret evidence. Operators bring the system into a real workflow. Oversight bodies and affected publics provide scrutiny that internal reviewers may miss. A weakness at any point can narrow the choices available to everyone else. The agency may still possess a contract, but not the practical ability to measure, challenge, share, update, or stop what it bought.
That practical ability is especially important in government because the affected party is not simply a customer who can choose another product. A benefits triage system, a disaster-assessment tool, a health-support service, or an administrative chatbot can shape how public resources and attention are distributed. The agency may have duties to explain decisions, protect sensitive information, preserve fair treatment, and maintain continuity of service. Those duties do not disappear because a vendor supplied the model. Nor do they imply that every procurement deserves the same burden of review. They do imply that the agency must know which consequences are material and must design a route for responding when the capability does not behave as expected.
The evidence supports a strong direction, not a universal formula. GAO’s detailed review covered a nongeneralizable sample of 13 acquisitions at four agencies, and the checklist research drew on implemented frameworks and conversations across several jurisdictions. A later synthesis proposes adaptive governance for frontier AI but explicitly does not test that framework empirically. These limits matter: they tell us to treat lifecycle governance as a reasoned response to observed failure surfaces and uncertainty, not as a guarantee that any particular checklist, repository, or contract vehicle will produce good outcomes.
The rest of this series follows the consequences of that distinction. It begins with what it means to acquire a changing system, then examines the pre-award choices that preserve control, the trade-offs among acquisition routes, the evidence required in operation, and the institutional practices that turn experience into learning. The next question is the foundation for all of them: when the model, data, infrastructure, and workflow can change after the contract is signed, what exactly has the agency bought?