The 5-Question AI Vendor Due Diligence Checklist Every EU Procurement Team Needs (2026)

Signing a Data Processing Agreement with an AI vendor no longer means you have done your due diligence. Under the combined weight of the GDPR and the EU AI Act, EU procurement teams, DPOs, and IT buyers now carry a distinct set of obligations that a standard DPA was never designed to address. Get it wrong and you are looking at fines of up to €20 million or 4% of global annual revenue — plus the operational disruption of a mid-contract compliance crisis. The average non-compliance cost now sits at $5.2 million according to Ponemon's 2025 benchmark, and Gartner reported in 2026 that 34% of AI projects have been paused specifically because of compliance concerns. Five questions, asked at the right point in the buying process, eliminate most of that exposure.

Why standard vendor due diligence no longer cuts it in the EU

Traditional software procurement has relied on a short checklist: does the vendor have a DPA, is data stored in the EU, do they hold ISO 27001 or SOC 2? Those questions still matter, but they were designed for data processors that move and store information — not for systems that actively reason over it, update their own behaviour, and may feed your business data back into their training pipelines.

The EU AI Act, which began applying to general-purpose AI systems and high-risk AI in 2025 and 2026, introduced a parallel compliance layer that overlaps with GDPR but does not replace it. Where GDPR governs what happens to personal data, the AI Act governs how automated systems that affect people must be designed, documented, monitored, and audited. The same vendor interaction now triggers obligations under two distinct regulatory frameworks simultaneously — and most vendor contracts were written before either obligation was clear.

The practical consequence is that procurement teams who rely on a DPA tick-box are unknowingly transferring risk to themselves. Under GDPR Article 28, a DPA alone is insufficient for AI vendor due diligence. Buyers must also verify GDPR role allocation (is the vendor a processor, a controller, or do they operate as both in different parts of the product?), confirm storage and access locations separately, ensure SCCs or another Chapter V mechanism covers any non-EEA data transfer, and obtain a complete subprocessor list with a defined update mechanism. None of this is automatic. If your DPA does not address these points explicitly, you cannot assume they are covered.

Organisations typically need 9 to 14 months to reach full LLM compliance. Starting due diligence at contract renewal is too late. The five questions below are designed to be asked during the vendor evaluation stage, before any commercial commitment, so that the answers shape what goes into the contract rather than what gets discovered during an audit.

Question 1: Are you a "provider" or "deployer" under the EU AI Act — and what does that mean for my obligations?

The EU AI Act draws a sharp line between two roles, and the compliance obligations that fall on your organisation depend entirely on which side of that line your vendor sits. A provider is the entity that develops, places on the market, or puts into service an AI system. A deployer is any natural or legal person using an AI system in a professional context. In a typical SaaS AI relationship, the vendor is the provider and you, the buying organisation, are the deployer.

This matters because the AI Act attaches different obligations to each role. Providers of high-risk AI systems — systems that fall within the categories listed in Annex III of the Act, which include AI used in employment decisions, credit scoring, education, and critical infrastructure — must create technical documentation, conduct conformity assessments, implement automatic logging of system operation, and supply deployer-facing documentation that includes the system's intended purpose, its limitations, and instructions for human oversight. Deployers, on the other hand, are required to operate the system only within its intended purpose, maintain the logs the provider generates, ensure human oversight is implemented, and notify their supervisory authority of any serious incidents.

The problem is that many AI vendor contracts do not specify this allocation. If the contract is silent on whether the vendor is acting as a provider or a deployer, and if the tool is later classified as high-risk, both parties may be exposed — and regulators will not be sympathetic to ambiguity. Under EU AI Act Articles 11 and 12, providers must ensure that high-risk AI systems automatically generate logs sufficient to trace the system's operation for audit purposes; deployers must retain those records. If your vendor's contract does not confirm that these logs exist, are exportable, and are retained appropriately, you cannot meet your deployer obligations regardless of what your internal policies say.

Question 2: Where exactly is data stored AND processed? (storage location is not the same as processing location)

Most procurement teams ask where data is stored. Almost none ask where data is processed. These are different locations, and the gap between them is where the most common GDPR exposure in AI procurement lives today.

A vendor can truthfully say "your data is stored in Frankfurt" while processing that data — running inference, embedding, retrieval, and model operations — on infrastructure in the United States or in a jurisdiction without an adequacy decision. Stored-in-EU means the data at rest lives on a European server. Processed-in-EU means the computation over your data happens within the EEA. For GDPR compliance, both matter.

The distinction becomes acute in light of the US CLOUD Act. This legislation allows US authorities to compel US companies and their subsidiaries to produce data stored anywhere in the world, regardless of which server it sits on. A vendor headquartered in the US, or whose parent company is US-domiciled, cannot fully insulate your data from US government access even if the data is physically stored in an EU data centre. The only technical-legal architecture that eliminates this exposure is a vendor that is fully EU-owned with no US parent, which removes the basis for a CLOUD Act production order and also removes the need to conduct a Transfer Impact Assessment.

For vendors that do have US ties or that process data outside the EEA, the GDPR requires a valid Chapter V transfer mechanism. Standard Contractual Clauses (SCCs) are the most common mechanism, but they must be accompanied by a Transfer Impact Assessment that honestly evaluates whether SCCs provide effective protection given the legal environment of the receiving country. Many TIAs performed by EU companies evaluating US AI vendors are, in practice, too optimistic about the protections SCCs provide in the US legal context.

Question 3: Can you export complete audit logs, and what do they contain?

Audit log exportability is the compliance requirement AI vendors are least eager to discuss, and most contracts that do not explicitly address it should be treated as if the feature does not exist. If your contract does not specify that audit logs are exportable, in a structured format, with a defined retention period, you cannot assume you will be able to access them when a regulator or your internal DPO asks for them.

The EU AI Act creates a direct obligation here for high-risk systems. Articles 11 and 12 of the Act require providers to design high-risk AI systems to automatically log events sufficient to trace the system's operation — including inputs, outputs, and the timing of decisions. Deployers — meaning you — must retain those logs for the period specified by the relevant sectoral regulation or, in the absence of that, for a minimum period to be set by implementing acts. If you cannot export the logs from the vendor's platform, you cannot meet the retention obligation in your own systems, and you cannot produce records in response to a supervisory authority inquiry.

Beyond the AI Act, audit logs serve two other compliance functions that are often overlooked in procurement. First, in the event of a GDPR data breach, logs that record which data was accessed, by which system component, and when are essential for scoping the breach notification and demonstrating accountability to the supervisory authority. Second, for internal governance purposes — particularly for companies subject to sector-specific regulation in finance, healthcare, or critical infrastructure — logs of AI-generated outputs may be required to demonstrate that human oversight was actually exercised, not just nominally available.

Ask vendors specifically what their logs contain. A useful audit log for an AI system should record at minimum: the user or process that initiated each request, the timestamp and unique identifier for each transaction, the input submitted (or a hash thereof), the output generated, and any model version identifier active at the time. Logs that record only "a user ran a query" are not sufficient for regulatory purposes.

Question 4: Are you training on my data — prompts, transcripts, outputs?

This is the question with the most significant commercial and legal consequences, and it is the one that is most frequently buried in vendor terms of service rather than addressed head-on in the contract. AI vendors processing business data must explicitly disclose whether prompts, files, telemetry, or outputs are reused for model training. If they do not disclose this proactively, you must ask directly — and require the answer in writing, in the contract, not on a web page that can be updated without notice.

The risk here is not hypothetical. If a vendor uses your sales call transcripts, customer data, product roadmap discussions, or commercial proposals to train or fine-tune their model, several GDPR obligations are triggered. First, if those transcripts contain personal data about identifiable individuals — which sales call recordings almost always do — training on that data constitutes a new processing purpose. That purpose must have its own legal basis. Legitimate interest is unlikely to survive scrutiny for model training on third-party business data; consent from all affected data subjects is usually impractical. Second, any personal data trained into a model creates a near-permanent record that is extremely difficult to honour erasure requests against — if a data subject exercises their Article 17 right to erasure, and their data has been trained into model weights, you may be unable to comply.

Beyond GDPR, the commercial risk is straightforward. Your prompts contain your business logic, your customer intelligence, your competitive positioning, and your operational processes. If those prompts are used to train a shared model, the insights derived from them may, over time, improve the performance of the same model for your competitors who use the same platform.

The contract clause you need is specific: it should state that the vendor will not use your data — including but not limited to prompts, inputs, outputs, telemetry, file uploads, and conversation transcripts — to train, fine-tune, improve, or evaluate any AI model, whether the vendor's own model or a third-party model accessed via API. Many enterprise AI vendors offer this as a standard enterprise tier commitment; if yours does not, it should be a deal-breaker or a hard negotiated requirement.

Question 5: How will you notify me of model updates before they go live?

Model update communication protocols are a distinct vendor evaluation criterion that most procurement frameworks do not yet include — and their absence is a silent compliance risk. AI models are not like software versions that get released on a fixed schedule. They are updated continuously, sometimes without any public announcement, and each update can materially change the outputs your workflows depend on.

The compliance dimension of this is direct. If your organisation is using an AI tool in a context that requires consistent, auditable output — credit decisions, HR screening, medical triage support, contract review — a model update can silently change the criteria that produce a given output without any change to the input or the interface. The human reviewer who signed off on outputs last month may have been reviewing outputs from a different model than the one running this month. If you cannot demonstrate that your human oversight was actually effective over the model that generated the specific output under review, the audit trail is broken.

Under the EU AI Act, providers are required to keep deployers informed of significant changes to their systems — particularly for high-risk applications. But "significant" is not defined with precision in the current text, and many model changes that materially affect output behaviour will not be characterised by vendors as significant enough to trigger formal notification. You cannot rely on voluntary vendor classification; you need a contractual commitment.

The contractual commitment you need has three components. First, advance notice — a defined minimum number of days before a model update takes effect, long enough for you to test the new model against your use cases before it runs in production. Thirty days is a reasonable minimum for business-critical workflows; some regulated sectors require more. Second, a summary of what changed — not just "model performance improved" but a description of the nature of the change, the affected capabilities, and any known changes to output characteristics. Third, the ability to pin to a previous model version, or to delay migration, for a defined transition period. Without this, an update that breaks a workflow you depend on can take effect overnight with no recourse.

Certifications to look for: ISO 27001, SOC 2, and what they do not cover

Certifications matter, but they need to be read carefully. ISO 27001 and SOC 2 Type II have become the baseline expectation for enterprise AI vendors, and their absence should raise immediate questions. Their presence, however, does not answer the five questions above.

ISO 27001 is an internationally recognised standard for information security management systems. Achieving initial certification costs a vendor €6,500 to €20,000 and takes between six and twelve months. Annual maintenance costs run €2,400 to €6,500. A vendor that has invested in ISO 27001 certification has demonstrated a functioning security management process, regular risk assessments, and defined controls around access, incident management, and business continuity. What it does not demonstrate is GDPR compliance, EU AI Act compliance, a prohibition on training over customer data, or any of the AI-specific obligations described in this article.

SOC 2 Type II covers the same general territory but is structured around five Trust Service Criteria — Security, Availability, Processing Integrity, Confidentiality, and Privacy. Type II is meaningfully more rigorous than Type I because it requires a six-month operational period during which an auditor observes that controls are actually working, not merely that they exist on paper. Initial costs run €12,000 to €32,000 for the audit, with ongoing annual costs of €8,000 to €20,000. For US-headquartered vendors, SOC 2 Type II is often the primary security attestation; for EU-based vendors, it complements ISO 27001.

The practical guidance for EU procurement teams is this: treat ISO 27001 and SOC 2 Type II as necessary but not sufficient. They tell you the vendor takes security seriously. They do not tell you whether your data is being trained on, whether audit logs are exportable, or whether model updates will arrive with adequate notice. Use them to filter out vendors with no security programme, and then use the five questions in this article to assess the AI-specific risks that certifications were not designed to address.

See how Numi is built for EU compliance from the ground up — including EU data residency, zero training on customer data, exportable audit logs, and a GDPR DPA included as standard.