US GAO discusses testing challenges in federal AI acquisitions

Do not accept a performance claim about an AI application on a certificate, model card or supplier statement alone, as the US GAO discusses in its challenges with federal AI acquisitions. Our analysis is that buyers should verify performance independently before award with representative validation data, monitor the lifecycle and set thresholds, retests and a refusal option.

On 5 November 2026 the U.S. Government Accountability Office published an assessment of AI acquisitions at federal agencies. The GAO discusses challenges in federal AI acquisitions, including evaluating proposals and performance and collecting lessons learned. It also notes that lessons learned can include practices such as contract terms and testing requirements. Our analysis extends that point: where appropriate, buyers should use independent, context-specific testing before award rather than treating supplier claims as sufficient evidence. This recommendation is our procurement analysis, not a statement that the GAO prescribed this exact framework. These frameworks come from the US and UK public sector; they do not constitute a Dutch procurement norm, nor an elaboration of the European GDPR rules on personal data or of the EU AI Act (Regulation (EU) 2024/1689) for high-risk AI. In our assessment they do support a control principle that applies just as firmly to private organisations.

What does the GAO assessment say about testing AI before contract award?

The GAO discusses challenges in federal AI acquisitions, including evaluating contractor proposals and performance and accessing technical expertise. It reports that agencies could benefit from collecting lessons about practices such as contract terms and testing requirements, and recommends that selected agencies systematically collect and share lessons learned. Our analysis is that business AI procurement should not responsibly rest on supplier claims or general certifications alone: buyers should verify before award what a system can do, organise independent evaluation where appropriate, and keep tracking performance throughout the lifecycle. Our further analysis is that, for material or higher-risk procurements, a one-off supplier demonstration should not be treated as sufficient evidence on its own, and that the contract should provide for repeat testing when performance or the system changes.

Other official frameworks make this concrete. The Department of Energy requires, before procurement, an AI Impact Assessment covering, among other things, privacy, cybersecurity, data quality, bias and explainability, plus minimum accuracy and performance thresholds, change notifications and testing before a new version goes live. The Department of the Interior asks that evaluation teams test products during selection where possible and that suppliers be obliged to monitor performance, remedy unacceptable behaviour and roll out new versions only after they meet the standards.

Why are certificates, model cards and supplier claims not enough as evidence?

Because a statement about one's own performance is not an independent test. An academic study of vendor self-reports for public-sector AI reports that those documents often lack the baseline, the method and the context needed to assess claims such as high accuracy on their own. The authors recommend supplementing self-reports with independent audits, sandbox pilots and your own evaluations, rather than relying on statements alone.

The RICS AI procurement guide draws the same line: before purchase, set out the extent to which the system has been tested for fitness for the intended purpose, and ask for written information about data processing, training-data quality, known gaps, bias risks and the practical test results. A figure without a basis for comparison is no proof that the system works for you. That aligns with the idea that buying a compliant AI model does not settle your own obligations under the EU AI Act.

What evidence must I have before award and how do I set it out contractually?

Work in four steps, from your own requirements to enforceable agreements. The supplier documentation is input that you verify, not standalone evidence.

1. Define the task and the thresholds. Set out the intended use, data classification, error costs, operational limits and minimum performance, privacy, bias and safety thresholds before you go to market. Where the AI processes personal data, assess before deployment which GDPR obligations apply to the concrete processing.
2. Request documentation as input to be verified. Gather model, data, safety, privacy, change and limitation documentation, but treat it as claims that you test.
3. Test independently with ring-fenced data. Have an evaluation function test with representative validation data and scenarios the supplier cannot optimise for. Alongside average performance, record error types, uncertainty, bias, robustness, privacy behaviour, security, latency, cost and failure modes.
4. Make the acceptance criteria contractual. Arrange monitoring, incident reporting, change notification, retesting before a new version, access to relevant logs, and a rollback or termination right if performance or risks move outside the agreed limits.

Translate that last step into hard wording, not a general reliability promise. That calls for an enforceable audit right with concrete inspection evidence and for concrete examples of audit evidence that you can document.

What does this mean for directors, lawyers and CISOs buying AI?

Because the burden of proof shifts onto the buying organisation, in our assessment this affects every director who signs off on an AI purchase; so you add a pre-award verification phase with your own, ring-fenced validation set before the award decision is taken. Our practical assessment is that, because vendor self-reports often lack baseline and method, a lawyer in a dispute over substandard performance should not build on a certificate alone; so the lawyer now sets out measurable thresholds, an obligation to retest after model changes and a rollback or rescission clause, and checks whether the processing of personal data complies with the GDPR. Our assessment is that, because models can be changed after award, a CISO should not treat a one-off acceptance test as lasting evidence; the contract should require change notification, relevant log access and reassessment before each new version. And because a private organisation rarely has the internal evaluation capacity of a federal agency, in our assessment there is a risk that the verification is skipped; so you assign that function explicitly, internally or via an independent third party, and include in your procurement policy a refusal option where the supplier provides insufficient verifiable evidence. What follows from your own policy, you can read in our topic hub on AI governance and responsible procurement.

In short, as a decision list:

• Verify before award yourself, with data the supplier does not know.
• Set out thresholds, retests and rollback contractually, not as an intention.
• Monitor after award and reassess before each new version.
• Do not procure where verifiable evidence is insufficient.

Sources: The article draws on an assessment by the U.S. Government Accountability Office and on acquisition frameworks from RICS, the U.S. Department of Energy and the Department of the Interior, supplemented by academic research into vendor self-reports.