What It Means to Buy a Changing System
The difficult question in public-sector AI acquisition is not whether a vendor can deliver a model or service. It is whether the agency can still understand and govern that capability after the delivery date, when the model, the data, the users, or the surrounding workflow changes. To answer that question, we need to separate the federal acquisition lifecycle from the AI system lifecycle and then examine the transitions between them. The result is a more precise view of what an agency has bought—and what it has not.
From purchase phases to system states
Federal acquisition is commonly described in three phases. Before award, an agency defines its requirements, plans the acquisition, and prepares a solicitation. During award, officials evaluate offers, negotiate where appropriate, and select an awardee. After award, the agency administers the contract and oversees the contractor’s performance. This sequence is useful because it identifies when formal decisions are made and where contractual obligations attach.
Those phases are procedural boundaries, not sealed compartments. A requirement written before award determines what can be compared during award. The terms accepted during award determine what evidence and remedies are available after it. Post-award findings can then show that the original requirement was incomplete, the test was poorly matched to the use, or the cost assumption did not survive contact with operations. In a conventional purchase, this feedback may be useful without changing the identity of the product. In an AI acquisition, it can change the capability being governed and the public consequences of relying on it.
The distinction is important for responsibility. The contracting office may complete its formal work when the award is made, while a program office, technical team, or operator carries the system into use. If those roles are not connected, the people who negotiated the evidence and rights may not be the people who monitor performance. The award can then transfer a capability without transferring the knowledge needed to govern it. Treating the phases as linked means preserving that knowledge and making the handoff itself part of the acquisition design.
An AI capability follows a different, overlapping sequence. The Government Accountability Office describes an AI development lifecycle that includes design, development, deployment, and continuous monitoring. These stages are iterative rather than strictly sequential. A system may return to development after testing, change during deployment, or require a new round of evaluation when its operating environment shifts. The two lifecycles therefore answer different questions. Acquisition asks how the government obtains a capability and defines its relationship with a supplier. The AI lifecycle asks how that capability is built, used, observed, changed, and eventually retired.
The distinction matters because the thing acquired may not be a finished object. An agency can buy a model, the infrastructure needed to run one, a software license, development support, testing, or an ongoing service. In the last case, the agency is paying for continuing access to capability and support, not merely taking delivery of a file. GAO found that most of the arrangements it reviewed involved services or licenses. Agency officials also emphasized that service quality can affect outcomes more than the quality of the underlying algorithm in some sophisticated systems. The vendor’s operations, updates, integration work, and responsiveness can become part of mission performance.
This changes the unit of completion. For a desk or a conventional software package, delivery may be a reasonable point at which the buyer verifies that the item matches the order. For a changing AI service, delivery can establish access while leaving performance, dependency, and accountability open. The service may draw on cloud infrastructure that the agency does not own, depend on vendor staff to handle updates, or expose the agency to usage costs that grow with adoption. Those features do not make the acquisition improper. They make the relationship ongoing and make the agency’s ability to inspect and renegotiate more important.
It also changes what evidence should travel with the capability. The agency needs a record of the intended use, the population and workflow considered, the baseline tests, the data permissions, and the limits communicated by the vendor. Without that record, later reviewers cannot tell whether a new result reflects a changed model, a changed population, a changed operator practice, or an assumption that was never tested. The record is not a substitute for current evaluation. It is the reference point that lets current evaluation mean something.
Even a product-like purchase can have continuing consequences. A model may be retrained or replaced. New data may be sent through the system. A software component may be added to a larger case-management or decision-support workflow. A change that looks minor to the supplier can alter the conditions under which the agency evaluated the capability. The agency may still be operating under the same contract, but the operational object has changed enough to require a new question: does the original evidence still apply?
A useful way to see the problem is as a set of states with transition triggers, rather than as a calendar that ends at signature.
The award is a gate in this picture, not the final state. It should establish enough clarity for deployment to begin responsibly, but it cannot settle every question that appears in operation. At the design and development stages, requirements, data, and evaluation methods are being assembled. At award, those choices become commitments: the agency decides what the supplier must provide, what evidence will count, and which rights and remedies are available. At deployment, the capability encounters real users and real data. Monitoring then determines whether the evidence supports continued use or sends the system back for review.
Each arrow in the diagram is therefore an evidence question. Moving from development to award asks whether the proposed capability is defined well enough to buy. Moving from award to deployment asks whether the agency has authorized a use that matches what was evaluated. Moving from deployment to monitoring asks what the agency will observe and who can interpret the result. Moving from monitoring to review asks what counts as a material change or unacceptable outcome. Finally, moving to retirement asks whether the agency can preserve records, protect affected people, and transition the mission without treating continued vendor dependence as the only option.
The transitions also have different owners. A vendor may be best placed to explain an implementation change, but the agency decides whether that change affects the mission. An operator may first notice that an output is implausible, but a technical or domain expert may need to determine whether the problem is random, systematic, or caused by a new data condition. A contracting official may know what the agreement permits, while a program leader knows what service interruption would mean. Lifecycle governance is partly the discipline of keeping these observations connected rather than allowing each role to see only its own state.
What persists across these transitions is not only the model. The agency carries forward a mission objective, a population or workflow, a set of data permissions, performance expectations, records, and responsibilities. The vendor may carry forward a service configuration, a model version, infrastructure, and support obligations. If these relationships are not recorded clearly, an update can erase the practical link between the original promise and the current system. What is lost may be difficult to recover: the baseline against which performance was measured, the reason a data source was considered suitable, or the authority to demand a change.
That is why “post-award” is a misleadingly passive label. It sounds like the procurement has moved from decision to administration. In an AI acquisition, post-award work may contain new design decisions, new tests, and new choices about whether the capability remains appropriate. GAO’s description of AI as requiring ongoing assessment reflects this difference. The agency is not necessarily buying an object once; it is establishing an arrangement in which capability and responsibility continue to evolve.
When the operating context changes
The most important transitions often originate outside the contract. A model can receive data that differ from its training data. A policy or demographic change can alter the population being served. A major shock can change how people travel, seek care, buy goods, or interact with a government service. These are forms of data or context shift: the relationship between the information entering a system and the outcome it is meant to support is no longer the same as it was during evaluation.
A shift is not automatically a failure. New data may be more representative, and an updated workflow may improve service. The governance problem is that the agency cannot know which interpretation is warranted without a baseline and a way to compare current results with the intended use. It may need to examine subgroup performance, error direction, the rate of exceptions, user overrides, or the relationship between an output and the public outcome it is meant to support. A single aggregate accuracy figure can conceal a change in who is helped or harmed. Monitoring is valuable because it turns “the context changed” into a question that can be investigated rather than a reason to assume either stability or collapse.
The checklist research gives a concrete medical example. Suppose a new screening guideline lowers the recommended age for cancer screening. A tumor-detection system trained mostly on images from older patients may now receive images from younger patients whose properties differ from the original data. The model has not necessarily been updated, but the task environment has changed. A test that was relevant before deployment may no longer tell the agency enough about current performance. The trigger for review is not just a new version number; it can be a material change in the data or use.
The same reasoning applies to feedback loops. When a hospital’s staff begin responding to an AI alert system, their actions affect the data later collected by the hospital. When students know how an explainable grading system rewards certain features, they may change how they write. In both cases, the system becomes part of the environment it is measuring. Future observations are no longer independent of the system’s own recommendations. A monitoring plan that watches only the model’s internal update history can miss this social change.
For a public agency, the feedback may also run through eligibility, inspection, or resource allocation. If a triage system places some cases first, the order in which staff investigate them can determine which cases receive richer records and which outcomes later appear in the data. If a service routes attention away from a group because its historical records contain fewer observable signals, the resulting lack of contact can look like confirmation that the group presents fewer needs. These examples do not establish that a particular procurement produced such a loop. They show why the agency must monitor the interaction between the output and the process it organizes, not only the technical behavior of the model in isolation.
None of this means that every AI system continuously learns in production or that every change causes material degradation. The evidence supports a narrower and more useful conclusion: agencies need a way to identify which changes could invalidate the original evaluation and to decide when deeper review is warranted. A stable, low-impact tool may need less frequent scrutiny than a system whose output is a principal basis for benefits, safety, enforcement, or other consequential action. The relevant question is not whether the label “AI” automatically demands one universal schedule. It is whether the agency has matched its evidence and response capacity to the consequences of being wrong.
The vendor relationship complicates that judgment. A supplier may control model updates, infrastructure changes, fine-tuning, or the service interface. The agency may not see every technical change before it affects users. Yet the public institution still owns the mission decision: whether to deploy, where to use the output, how much authority to give it, and what to do when performance is uncertain. This is not a claim that the agency alone causes every failure. It is a reason to define notification, access, testing, documentation, and escalation responsibilities before the supplier’s control over the capability becomes operational dependence.
The practical boundary is not “the agency must control every technical detail.” That would often be unrealistic, particularly when the supplier operates a general-purpose service. The boundary is whether the agency can detect changes that matter to its use and obtain enough information to make a responsible decision. A vendor notice that a model has changed is more useful when the agency has a baseline test, a designated reviewer, and authority to pause or restrict deployment. A promise of support is more meaningful when the contract and operating process identify response times, evidence access, and what happens if the service is withdrawn. Visibility and decision rights compensate, in part, for technical control that remains with the supplier.
A human operator does not automatically close the gap. The checklist analysis notes that people often over-rely on algorithmic recommendations because a system appears intelligent or because accepting its output avoids cognitive effort. A rule that says a human makes the final decision may therefore be formally satisfied while the workflow still gives the human little time, information, training, or authority to disagree. Meaningful human review requires a design in which the operator can understand the recommendation well enough for the task, challenge it without unreasonable friction, and obtain support when the consequences are high. The agency must also examine whether that review is happening in practice, not merely whether a person’s name appears in the process.
This is the sociotechnical part of the lifecycle. AI adoption changes routines, roles, organizational structures, governance arrangements, and culture. It also changes data: new patterns of use, intervention, and exception handling become part of the environment. The 2026 public-sector governance synthesis argues that reliable and explainable AI depends on data stewardship, interoperable metadata, sharing rules, and coordination across institutional levels. Procurement does not solve all of those problems, but it can either recognize them or conceal them. A contract that buys a model without specifying who maintains the data, validates changes, trains operators, or records exceptions leaves the operating system of the decision unfinished.
The lifecycle view also changes how completion should be described. Deployment may be complete in the narrow sense that users can access the service. It is not complete in the sense that the agency has proved the service will remain fit for its mission. Monitoring can support continued operation, send the capability back for remediation and revalidation, or justify retirement. A decision to replace or stop a system is not necessarily evidence that procurement failed; it may be the result of a functioning governance process. Conversely, continuing to renew a service without preserving evidence can create the appearance of stability while hiding a loss of control.
The next practical question follows directly. If later monitoring and exit depend on what the agency can observe, test, share, and require, those abilities must be shaped before award. The issue is not to predict every future change. It is to secure the expertise, requirements, data rights, and contract terms that keep future change governable.