On 8 May 2026 the US Department of Energy (DOE) published an Acquisition Letter AL 2026-05. The letter turns AI procurement within the DOE from a matter of generic security requirements into a detailed, contractually enforceable set of conditions. The DOE states that it will not acquire, develop or operationally deploy AI systems or services without documented compliance. In concrete terms the letter sets out AI Impact Assessments, bias tests, data provenance, security architecture, lifecycle management, transparency documentation, incident reporting and enterprise controls — all embedded as procurement terms and evaluation criteria.
At first glance this looks like a US government matter. But the letter is a readable example of a broader shift that is also relevant for European professionals: when procuring AI services in high-impact environments, the conversation moves from which product to which demonstrable properties.
From generic security to demonstrable properties
The DOE letter does not stand alone. As early as 27 January 2026 the Department of the Interior (DOI) set out procedures for procurement planning, market research, source selection and contract administration around AI in the memorandum Acquisition of Artificial Intelligence (AI). Teams must classify use cases by impact, identify privacy, civil rights and data rights risks early, include anti-lock-in provisions in contracts, enforce vendor testing and patching, and make data portability and IP rights explicit.
What stands out about both documents is that the requirements are not framed as non-binding best practices, but are tied to eligibility, payment and termination. A supplier that cannot demonstrate how its system handles bias, data management or logging is not eligible.
The lawyers at Gibson Dunn describe in their analysis GSA AI Procurement Rules how the proposed GSAR clause 552.239-7001 ("Basic Safeguarding of Artificial Intelligence Systems") aims to standardise this line for all government contracts with AI capabilities. Key points are obligations around data and IP rights, transparency about model changes, incident reporting and auditing — with a broad definition of 'AI system' that also encompasses embedded AI in business processes.
A broader trend, not one department
That the DOE and DOI letters are not isolated cases is clear from two other sources. Vorp Labs summarised the landscape in US AI Procurement Clauses, July 2026 and listed typical contract terms for LLM suppliers: openness about supply chain and training data, a ban on unauthorised training on government data, safeguarding and incident reporting, portability and lock-in protection, change notifications and testing and flow-down obligations.
The movement is also taking shape at state level. Morgan Lewis described in California Executive Order Expands AI Oversight Through State Procurement how California is expanding AI oversight through public procurement, with vendor certification requirements around harmful or unlawful content, algorithmic bias and effects on civil rights. Here too those requirements are embedded as selection criteria in contracts and suppliers must show demonstrable controls.
Procurement becomes a question of evidence
The common thread through these sources is that it is no longer enough to have a clause on paper. The requirements — bias, data provenance, privacy, logging, impact classification and human oversight — must remain demonstrable in practice. This changes the nature of AI procurement: alongside legal terms, there is a growing need for a verifiable evidence layer that shows the selected services also meet the agreements during use.
For professionals working with confidential information — lawyers, notaries, company doctors, journalists, researchers and compliance teams — this is not an abstract government matter. Anyone who deploys AI on sensitive files will increasingly need to be able to show, during tendering, contract management and re-selection, how data and output are handled.
What this means for a verification console
At this point the news touches on the work of I am Vera. Vera is not a language model or chatbot, but a privacy-focused verification layer. The Semantic Privacy Shield is designed so that pre-processing and anonymisation take place on EU infrastructure and the workflow only sends anonymised content to the selected AI models; if a privacy check fails, nothing is forwarded.
Precisely that logic aligns with the requirements the DOE, DOI and the GSA proposals describe around data provenance, privacy and logging. A console that makes verification steps visible and compares several models against each other can help enable oversight on points that procurement terms now explicitly demand: is the output traceable, is the input protected, and is the process documentable? Vera does not eliminate errors and cannot vouch for correctness or truth — it makes oversight more insightful, while the professional final judgement remains with the user. Through the evidence layer, material is created that may be useful during audits and re-selection.
The lesson from the US procurement letters is sober: selecting AI services is no longer just a product choice. It is a question of evidence. Anyone who takes that question seriously arranges their way of working so that compliance is not only laid down contractually, but also remains visible and verifiable in daily practice.