The Choices That Shape Control Before Award
A public agency cannot preserve post-award control by adding a monitoring meeting after it has signed an AI contract. The more important work begins earlier: defining what the system must accomplish, what evidence can show that it does so, who can interpret that evidence, and which rights the agency will need when circumstances change. This is the focus here. By looking at an AI acquisition as a set of connected responsibilities rather than a vendor response and a price, we can see which pre-award choices give the agency genuine leverage later.
Requirements that can be tested and owned
A broad ambition—“use AI to improve benefits delivery,” “detect anomalies,” or “make administrative work more efficient”—is not yet a requirement that a vendor can be held to. A usable requirement identifies the public task, the people and conditions involved, the outcome that matters, the limits on acceptable error, and the evidence that will be used to judge performance. It need not prescribe every technical method. In fact, a performance-oriented requirement can leave room for a supplier to propose a better method. But it must make the agency’s mission and its standard for success concrete enough to compare alternatives and to revisit the decision after deployment.
That translation is not the sole work of a contracting office. GAO reports that officials at each of its five selected agencies identified limited access to subject-matter experts as a challenge. The relevant expertise is broader than machine learning. An acquisition may need people who understand data and infrastructure, cybersecurity, privacy, civil rights and civil liberties, budgeting, program evaluation, the mission domain, and the acquisition rules. The precise mix depends on the use. A benefits tool and a cybersecurity alert system will not raise identical questions, but neither can be evaluated responsibly by treating the vendor’s technical description as self-interpreting.
Experts add value at the points where a plausible answer can conceal an important omission. A supplier may report high accuracy across several demographic categories. That information may be useful, but it does not by itself reveal whether errors are false positives or false negatives, whether the errors carry different consequences, or whether an unobserved factor is shaping the result. The checklist research describes a health-care example in which an algorithm can predict historical health-care use accurately while mistaking access to care for severity of illness. A procurement official who asks only whether the intended population resembles the training population may miss the social condition that makes the proxy unreliable. A domain expert can ask whether the measured outcome is actually the public outcome the agency cares about; a technical expert can ask what additional tests would expose the weakness.
This is why an AI checklist should be understood as an expert prompt, not as a substitute for expertise. The Canadian Directive on Automated Decision-Making and the World Economic Forum’s AI Procurement in a Box make categories of concern visible. They can help a team remember to ask about data, privacy, bias, security, explainability, and monitoring. But a checklist cannot decide what a sufficient description of the training data looks like, whether a proposed metric is meaningful, or whether a vendor’s claim that a model is too complex to explain deserves acceptance. The researchers’ red-teaming exercise found that a vendor could comply narrowly with a requirement while weakening its purpose. Interpretation is part of the control, not an optional refinement.
Requirements also need to anticipate the handoff from selection to operation. GAO reports that officials at all five selected agencies struggled with early testing and continuous evaluation, in part because AI systems vary so much that universal tests do not yet exist. The implication is not that testing should wait for a perfect standard. It is that the agency has to define, before award, how it will learn enough about the proposed capability to make a decision. OMB guidance summarized by GAO encourages agencies to test proposed AI solutions before awarding contracts and to monitor and evaluate them throughout the acquisition lifecycle. It also calls for validation data defined by the agency and not accessible to the vendor when independent evaluations are conducted.
That arrangement changes the relationship between a requirement and a test. The requirement is not simply a sentence in a solicitation; it is a statement of what the agency will later observe. If a disaster-assessment system is meant to support decisions across regions, the evaluation cannot rely only on examples that resemble the vendor’s most convenient data. If a benefits-support system is meant to prioritize cases, the agency must ask what outcome the prioritization is supposed to improve and how it will detect harmful ordering effects. If a chatbot is intended for administrative assistance, the agency needs a way to assess not only fluent answers but also privacy, escalation, recordkeeping, and the consequences of confident error.
The same logic applies to changes after award. Before signing, the agency should know which changes are material enough to require notice, testing, or approval. A new model version may be obvious, but a change in retrieval data, an altered service interface, a different operating region, or a new user population may matter just as much. The initial requirement should identify the conditions under which the baseline no longer provides enough assurance. Otherwise, the agency will be forced to negotiate the meaning of “the same system” only after a problem has appeared.
An agency also needs to decide who owns each judgment. The vendor may know how a model was trained and what has changed in the service. A technical evaluator may know how to test it. A program leader may know what an error means for the mission. A contracting official may know which commitments can be enforced. The requirement is incomplete if it assigns a performance target but leaves unclear who can accept evidence, who can reject a release, who can authorize use, or who must investigate an exception. Cross-functional work is not bureaucratic decoration. It is how the agency connects different kinds of knowledge before one missing perspective becomes a post-award surprise.
The control surface can be represented as a network of relationships rather than a stack of documents:
The point of this diagram is not to enumerate every contract artifact. It is to show what crosses the interfaces. The agency defines a mission and a requirement; the vendor supplies a capability; data enter the capability and outputs return to an agency workflow or to public and partner users. Tests connect outputs to performance metrics. Contract terms create rights and reviews that can operate across the relationship. If one connection is missing, the agency may still possess a signed agreement, but the system around it may not be governable.
Rights decide what can survive the contract
The most visible procurement question is often, “What will the vendor deliver?” The more durable question is, “What will the agency be able to do with the data, outputs, evidence, and service after delivery?” Government data and intellectual-property rights determine whether the agency can share a model output with a public partner, inspect a result, commission an independent test, move to another provider, or preserve records when a service ends. These rights are legally and technically distinct. Ownership of a dataset is not the same as ownership of a trained model, a generated output, a log, or permission to use a service. The right answer depends on the product, how it was developed and funded, the mission, and the applicable agreement.
The practical stakes appear in GAO’s examples. Officials supporting FEMA’s Geospatial Damage Assessment effort told GAO that they could not share model outputs with other federal and state partners because the necessary data rights had not been obtained at award. The constraint did not arise because sharing was irrelevant to the mission. It arose because the contract had not preserved an option the agency later needed for disaster recovery. A system can be accurate enough for an internal demonstration and still be inadequate for the public coordination task if the agency cannot lawfully or contractually move its outputs to the people who need them.
DOD’s Maven acquisition illustrates a different failure. Officials reported that early contracts lacked AI-related requirements needed to hold vendors accountable for weekly deliverables in an Agile development process. Follow-on contracts added more defined AI requirements, metrics, and model-performance expectations. The lesson is not that an early contract was worthless or that every Agile arrangement needs identical language. It is that speed without a clear performance relationship can make the agency dependent on a supplier’s account of progress. A later correction may improve the next contract, but it cannot always recover the leverage that was missing in the first one.
VA officials supporting an Automated Decision Support effort reported that the agency struggled to establish effective evaluation factors because of limited technical expertise. VA officials also described standard security language as insufficient for a rapidly changing environment and worked to develop more comprehensive terms. These observations connect expertise to rights. An agency cannot protect information or define a credible security obligation if it does not understand what the system accesses, how it changes, which interfaces expose it, or what evidence will demonstrate that protections are working. A clause can be present and still fail to express the mission’s actual need.
Rights over data and outputs are only one part of future leverage. A public agency may need access to logs, test results, model or service version information, documentation of material changes, and the ability to use its own validation data. It may need portability so that records or workflows can move if the service is replaced. It may need limits on vendor access to sensitive chat interactions or operational data. It may need a process for handling an update that changes performance, a security event, or an incident that affects public trust. These provisions should not be treated as a universal model contract; they are questions that the agency should answer in relation to the capability and the consequences of error.
Exit is part of the same design. A capability may be retired because it does not improve outcomes enough to justify its cost, because a new service is more suitable, because the mission changes, or because the agency cannot accept a newly discovered risk. An exit plan should therefore address what happens to data, outputs, records, integrations, user access, and ongoing obligations. It should also address the practical transition: who can operate the replacement, how users are informed, and what evidence must be preserved for oversight. A contract that makes termination legally possible but operationally impossible does not provide meaningful exit.
This is where vendor lock-in becomes more than a market concern. If the agency cannot compare a current service with alternatives because the vendor controls the relevant data or evaluation environment, the agency loses competition as a future discipline. If it cannot distinguish a model update from a change in service quality, it loses the ability to negotiate from evidence. If it cannot share outputs with partners, it loses mission capacity even if the vendor continues to perform its narrow service obligation. Portability, data access, testing rights, and clear update procedures preserve choices that may never be used but matter when the original arrangement stops fitting.
The rights question also has a public-accountability dimension. An agency may need to protect personal information, security-sensitive details, or legitimate intellectual property. Those limits do not eliminate the need to document what the system does, how it was evaluated, who is responsible, and what happened when it failed. Public transparency is not identical to releasing every model detail. It is the ability of authorized reviewers, oversight bodies, partners, and, where appropriate, the public to understand enough about performance and process to detect a material problem. Privacy and security constraints should shape the form of disclosure, not become a reason to leave the agency itself unable to inspect its purchase.
A useful pre-award test is to ask whether the agency can still do five things after the contract is signed: measure the capability against the mission, challenge a vendor’s account, share what the mission requires, update or replace the service, and stop using it without losing essential records or public capacity. No contract can guarantee that all five will always be easy. Nor can every agency obtain every preferred right, especially when buying a commercial service. But an inability to ask for, negotiate, or document these capabilities should be treated as a material limitation on the acquisition, not discovered only when a failure makes the limitation visible.
The next decision is not which contract vehicle wins in the abstract. Once the agency knows what control it needs, it can compare faster, more flexible, more customized, or more established acquisition routes by asking which ones preserve those requirements and which ones require compensating safeguards. That comparison is the subject of the next stage: speed can be valuable, but it is never the whole value of a public-sector AI purchase.