The Enterprise AI Procurement Checklist for Regulated Organizations

Most enterprise AI evaluations end well before the hard part. A shortlist is assembled, demos are run, a preferred vendor emerges — and then the contract goes to legal, the architecture goes to security, and the questions that come back are not about features at all. Where does the data sit? Who can audit? What happens when the model is upgraded? What can we take with us if we leave?

This is a checklist for that second stage. It assumes the functional evaluation is done, and covers what regulated organizations have to establish before an AI platform can be deployed: which regime applies, what belongs in the contract, what evidence the vendor must produce, and whether the exit is real.

Start by classifying the purchase, not the product

The obligations attached to an AI platform depend on what it will be used for and who is buying it. Three classifications should be settled before the contract is drafted, because each pulls in a different set of requirements.

Is any intended use high-risk under the EU AI Act? Annex III lists the stand-alone categories — among them creditworthiness assessment, life and health insurance risk assessment and pricing, employment decisions, and access to essential public services. If a planned workflow lands there, the deployer obligations in Article 26 apply to you, not only to the vendor. The Digital Omnibus on AI, approved by the European Parliament in June 2026, deferred stand-alone Annex III obligations to 2 December 2027 and Annex I product-embedded systems to 2 August 2028 — breathing room, not a cancellation, and the Article 50 transparency obligations were not moved.

Does the service support a critical or important function? For financial entities under DORA, this determines whether the baseline contractual clauses in Article 30(2) suffice or whether the enhanced set in Article 30(3) applies — full audit and access rights, exit strategies, participation in threat-led penetration testing where in scope, and detailed continuity obligations. It also determines what goes into the register of information submitted to the competent authority.

Is it a data processing service under the EU Data Act? The switching provisions have applied since 12 September 2025 to IaaS, PaaS and SaaS offerings, with no grandfathering for pre-existing contracts. If the platform is delivered as a service rather than deployed inside your estate, the portability and termination rules apply — and the contract should specify exhaustively which data and digital assets are exportable.

A self-hosted deployment changes the shape of several of these questions but does not remove them. The vendor is still a third party, the model is still supplied by someone, and the support arrangement is still a contract.

The clauses that decide the deal

Feature parity is common; contractual parity is not. These are the provisions where vendors differ most, and where a weak position is hardest to fix later.

• Data location and processing. Not “in the EU” but the specific systems, including where support staff connect from, where diagnostic bundles are sent, and where any managed component runs.
• Subcontracting and model supply. Which third parties are involved, including model providers and any inference or evaluation service. Under DORA this feeds the register of information; under any regime it is the difference between knowing your supply chain and assuming it.
• Audit and access rights. Who may inspect what, on what notice, and whether the right extends to your regulator. For arrangements supporting a critical or important function this is not optional.
• Change control for models and prompts. A model upgrade changes system behaviour. The contract should treat it as a change — notice, release notes, the ability to pin a version, and a supported path to stay on a prior version through a validation window.
• Logging, retention and evidence access. What is logged, in what format, retained for how long, and exportable by you without vendor assistance. Evidence you cannot retrieve independently is evidence you do not have.
• Training and derived data. An unambiguous prohibition on your prompts, documents, embeddings and outputs being used to train or improve anything outside your environment. Silence here is not neutrality.
• Termination and transition. A defined notice period, a transition window during which service continues, and a specified data retrieval period. The Data Act’s switching framework sets a template worth applying even where it does not strictly apply: a maximum two-month notice period, a switching window, and a minimum retrieval period.

The evidence file

Ask for the artefacts, not the assurances — a claim that a product is “compliant with” a regulation is a marketing position, not a transferable protection, and under both the AI Act and DORA the obligations stay with you. A vendor that has done the work can produce most of the following within a week; one that cannot is telling you something useful.

• Model inventory for everything shipped or recommended: provenance, version, and the licence text with its field-of-use and redistribution terms.
• Documented risk management and testing records for the platform’s own AI components, including how evaluation was performed and what the residual risk position is.
• The logging specification: which events are captured, with what identifiers, and how a single decision can be reconstructed end to end.
• The human oversight design: where approval steps sit, how they are enforced, and whether they can be disabled by configuration.
• Security certifications and their scope — ISO/IEC 27001, SOC 2 where relevant, and increasingly ISO/IEC 42001 for the AI management system itself, now common enough among enterprise vendors that its absence deserves a question.
• Penetration test summaries, the vulnerability disclosure process, and the subprocessor list with notice terms for changes.

Testing the on-premises claim

“On-premises” is used loosely enough that it should be verified rather than accepted. Four questions separate a self-contained deployment from a cloud service with a local footprint.

1. Does anything call out? Licence checks, telemetry, model downloads, update servers, error reporting. Ask for the full egress list, then ask to see the product operate with egress blocked.
2. How are models obtained and updated in a restricted network? An offline path — signed artefacts, an internal registry, a documented import procedure — or none.
3. Where does inference happen for every feature? Including the most recently added ones, which is where hosted dependencies tend to appear.
4. Can your team operate it? Installation, upgrade, backup, restore, key custody and incident response, on your own runbooks and change calendar.

The exit test

The exit provision most contracts contain is about ending the relationship. The one you need is about taking the work with you. Before signature, establish what a migration would actually involve.

Source documents are rarely the problem — you already have them. The value that accumulates inside an AI platform is elsewhere: agent and workflow definitions, prompt libraries, tool configurations, access policies, evaluation and golden question sets, retrieval indexes and embeddings, and the audit log. Ask which of these are exportable, in what format, and whether the export is machine-readable or a PDF of a screen.

Embeddings deserve a specific answer, since they are tied to the model that produced them: portability really means whether you can re-index elsewhere, and how long that takes at your corpus size. Agent definitions deserve another — a workflow expressed in an open, inspectable structure survives a platform change in a way that one buried in a proprietary runtime does not. This is the practical core of evaluating vendor lock-in, and it is far cheaper to negotiate before signature than during a migration.

How VDF AI approaches procurement review

VDF AI is deployed inside the customer’s own environment, which resolves several of these questions structurally rather than contractually: prompts, documents, embeddings, model outputs and audit logs stay within the customer’s boundary, and inference runs on their infrastructure. Models are registered and version-pinned so an upgrade is a deliberate, recorded change rather than a silent one. Agent and workflow definitions, access policies and audit logs are the customer’s own records inside their own systems. And for buyers assembling an evidence file, the artefacts that regulators and third-party risk teams ask for — model register, logging specification, human-approval design, access policy — are platform features rather than documents written after the fact.