Buying AI services after 2 August 2026: the three axes for vetting suppliers

From summer 2026, vet AI services on three axes: AI Act conformity for the service's risk category, a demonstrable AI governance system such as ISO/IEC 42001 at the supplier, and contractually fixed audit rights, data provenance and incident response. Request the accompanying documents as early as the RFP stage and make them a knock-out criterion.

The trigger is concrete. In the guide EU AI Act and Public Procurement (2026), Jorpex describes how, from 2 August 2026, the obligations for Annex III high-risk systems and the rules for general-purpose AI (GPAI) become enforceable, and how the Community of Practice on Public Procurement of AI translates the AI Act into model contract clauses (MCC-AI) for tenders. This means AI Act obligations can end up directly in procurement documents. In our assessment, that is the tipping point at which AI procurement shifts from a feature question to an evidence question.

What changes on 2 August 2026 for buying AI services?

According to the Jorpex guide, 2 August 2026 is presented as a practical turning point in which AI Act obligations for high-risk systems and GPAI can be reflected directly in procurement documents and contract clauses. The MCC-AI clauses give contracting parties ready-made contract text for transparency, risk management, data governance and human oversight. These clauses stem from the work of the Community of Practice on Public Procurement of AI, set up under the European Commission that implements the AI Act.

For you as a buyer, this means that a number of points shift from wish to hard requirement. Concretely, these become selection criteria:

• CE marking and a conformity assessment for high-risk systems;
• registration in the EU database before delivery to public purchasers;
• technical documentation (in line with Annex IV) and post-market monitoring;
• willingness to accept MCC-AI-style clauses on transparency and human oversight.

Suppliers who cannot provide this substantiation drop out sooner. In our piece on what you must be able to demonstrate about AI content from 2 August 2026, we go deeper into the difference between explanation and auditability. We gather more background in the topic hub on the EU AI Act and compliance.

What role does ISO/IEC 42001 play as a selection criterion for AI suppliers?

In parallel with the AI Act, ISO/IEC 42001 is becoming operational. AI Workplace Tools describes in Vendor Steps for Certification that certification and surveillance audits for this standard are being operationalised in July–August 2026 in North America and Europe, and advises buyers to update their RFP templates with ISO-specific questions and audit rights. AgentMode AI positions ISO/IEC 42001 in the same period explicitly as an enterprise AI procurement checkpoint.

NQA summarises the standard itself as an AI management system with requirements for scope, policy, role allocation, risk analysis, lifecycle controls, data management, third-party models, monitoring and audits. ISO/IEC 42001:2023 is thereby a certifiable and auditable standard, and so usable contractually as a reference. Therefore, do not only ask for the certificate, but for the underlying artefacts:

• the scope statement and the Statement of Applicability;
• the certification status and whether it concerns a pilot, full certification or a scope limitation;
• the risk assessment that specifically covers the service you are buying;
• model evaluation reports and data provenance;
• monitoring dashboards and incident response playbooks.

Our editorial caveat: a certificate at organisation level says little if the scope excludes the specific product. Always check whether the ISO controls apply to the service you are procuring, not to another part of the organisation.

Which three layers must I connect in my selection criteria and scorecard?

Together the sources point to three layers that you should not set out separately alongside one another, but connect in one scorecard and set of knock-out criteria:

1. Regulatory layer (AI Act, sector standards): classification as high-risk or not, CE marking, registration, technical documentation and post-market monitoring.
2. Governance layer (ISO/IEC 42001 or equivalent): policy, roles, risk processes, lifecycle controls, monitoring and incident response.
3. Contract layer (MCC-AI and bespoke): audit rights, data provenance, log retention, sub-vendor transparency and support in explaining AI outcomes.

A scorecard makes trade-offs explicit: which requirements are knock-out and which count towards the scoring. Anyone who combines these layers prevents a service from appearing legally compliant while offering no contractual audit right. That aligns with the case for combining one governance system for privacy, cyber and AI instead of separate compliance silos.

How do requirements differ between high-risk and non-high-risk AI services?

The Jorpex guide makes clear that the heaviest requirements apply to Annex III high-risk systems. Think of AI for recruitment, credit assessment or healthcare. There, CE marking, registration and full documentation are preconditions. For non-high-risk services, such as knowledge assistants, generative text support or internal tooling, the bar is lower, but not zero.

• High-risk: CE marking, EU registration, conformity assessment, human oversight and post-market monitoring as a hard requirement.
• Non-high-risk: proportional transparency and governance requirements, with logging and incident response as a contractual minimum.

The constant across both categories is that governance and evidence, such as logging and incident response, should everywhere form part of the procurement terms. For public purchasers, we worked out this logic per workflow earlier in our article on what you must record per workflow for GenAI in government.

How do I make visible per workflow which evidence is available after procurement?

Selecting on governance and evidence is step one. After that, you must be able to show which evidence is actually available if a client, regulator or auditor asks for it. That is an operational task separate from the procurement decision itself.

A verification console such as IamVera.ai can support this, but only after you have selected and contracted according to the above criteria. Vera is a privacy-focused verification layer, not a chatbot and not its own language model. It can route a task through selected independent AI models and expose verification steps, corrections, mutual differences and sources for inspection. That supports review; it is no guarantee of correctness and gives no assurance that models are error-free.

Concretely, such a console can help make visible per workflow which certified service runs in which process, which ISO/IEC 42001 artefacts and AI Act documentation apply to it, and which logs are available. The Semantic Privacy Shield replaces sensitive values with synthetic, session-only equivalents on EU infrastructure before AI processing; the workflow is fail-closed, so that when a privacy check fails nothing is sent onward. The final judgement about a supplier and about every output remains with you.

Sources: The article draws on the Jorpex guide on the EU AI Act and public procurement, analyses by AI Workplace Tools and AgentMode AI on ISO/IEC 42001, the explanation from NQA and the official ISO/IEC 42001:2023 standard.

← All articles in this topic ← All articles