AI Vendor Due Diligence: Luxembourg's 2026 Checklist

Q: 6. AI Act role: are they a provider or a deployer?

Ask the vendor to state, in writing, whether they are the *provider* of the AI system or component and what documentation they will hand you as a *deployer*. This is the single most-confused point in every AI contract right now, and it determines who owns which obligation in August 2026.

AI Vendor Due Diligence: The 2026 Procurement Checklist for Luxembourg Companies

Learn more about AI implementation in Luxembourg in our comprehensive guide.

Most Luxembourg AI deals are still bought the way SaaS was bought in 2018: a demo, a reference call, a discount on annual billing, sign. That worked when the worst-case downside was an unused licence. It does not work when the tool processes client data, sits inside a CSSF-supervised activity, or becomes the system a regulator asks you to explain. We wrote the deployment-stack side of this in EU sovereign cloud vs. hyperscalers vs. on-prem; this is the other half — the questionnaire you send the vendor before you care where it runs.

This is the 12-point checklist we actually use when we sit on the buyer's side of a Luxembourg AI procurement. It is deliberately short. A questionnaire nobody completes protects nobody.

Why a Luxembourg-specific checklist

Generic AI vendor checklists are written for US enterprise buyers and miss the three things that decide Luxembourg deals: the GDPR/Schrems II data-transfer position, the CSSF outsourcing regime (Circular 22/806 and the DORA + AI Act overlap), and the multilingual reality that the tool has to work in FR/DE/EN — sometimes LU and PT — on day one, not "on the roadmap". Skip those and you will discover them during the contract, which is the most expensive place to discover them.

The 12-point checklist

1. Sub-processors and where data physically sits

Ask for the full sub-processor list, not "we use AWS". You need the model provider, the hosting region, and any analytics or logging vendor in the chain. The honest answer is a list; an evasive answer is a paragraph.

2. Model provider and data-training position

Get it in writing: is your data used to train or fine-tune any model, including "to improve the service"? For business and client data the answer you want is an unambiguous no, contractually, with the API tier specified (enterprise/zero-retention tiers differ materially from default consumer tiers).

3. Data residency and transfer mechanism

Where is data at rest, where is it processed, and what is the legal transfer mechanism if anything touches a US-headquartered provider? "Frankfurt region" is not a Schrems II answer — the corporate jurisdiction of the processor is. See the deployment-stack post for why this is the row that most often decides the deal.

4. GDPR Article 28 DPA — and whether it is actually signable

A real Data Processing Agreement, with documented technical and organisational measures, that your DPO can sign without 40 redlines. The quality of the standard DPA is a strong proxy for how many EU customers the vendor already has. Our GDPR-compliant AI guide for Luxembourg SMEs covers what "good" looks like here.

5. CSSF outsourcing readiness (if you are supervised)

If the workload sits in a CSSF-supervised activity, the vendor must already understand Circular 22/806: support for the outsourcing register, audit and access rights, the regulator's right to inspect, and sub-outsourcing notification. Vendors who have done this in Luxembourg say so in one sentence. Vendors who haven't ask what CSSF is.

6. AI Act role: are they a provider or a deployer?

Ask the vendor to state, in writing, whether they are the provider of the AI system or component and what documentation they will hand you as a deployer. This is the single most-confused point in every AI contract right now, and it determines who owns which obligation in August 2026.

7. Security posture you can verify

ISO 27001 or SOC 2 Type II, a recent penetration test summary, and an incident-response SLA with a defined notification window. "We take security seriously" is not a control. Ask for the certificate's scope — certifications often exclude the exact component you are buying.

8. Model behaviour: accuracy, hallucination, and human-in-the-loop

For anything customer-facing or decision-supporting, ask how the vendor measures accuracy, what the documented failure modes are, and where the human checkpoint sits. A vendor who claims zero hallucination is either not measuring or not telling you.

9. Multilingual performance — tested, not promised

Luxembourg is the test no demo accounts for. Ask for a live test on your FR and DE content, ideally with a LU or PT sample. Performance on English marketing copy tells you nothing about performance on a German legal clause or a French CSSF circular.

10. Exit and data portability

Before you sign: how do you get your data out, in what format, on what timeline, and what happens to it after termination? An exit clause you cannot operationally execute is not an exit clause — and under DORA the regulator will ask you to walk through it.

11. Pricing model and lock-in mechanics

Per-seat, per-token, or per-outcome — and what changes at renewal. Map the realistic 3-year cost including the migration cost of leaving. The headline number is rarely the number that matters.

12. Reference customer in a comparable Luxembourg context

Not "a bank in Germany". A reference at a comparable size, sector, and regulatory exposure in Luxembourg or the Greater Region. The absence of one is not disqualifying for a new category — but it changes your pilot design.

How to weight the answers

Not every line carries equal weight, and the weighting depends on the workload:

Regulated / client-data workload: items 1–6 and 10 are pass/fail. A weak answer on any one of them ends the evaluation. This is the same logic we apply in private AI deployment for regulated industries and the CSSF use-cases guide.
Internal-productivity workload (non-personal data): items 2, 7, and 11 dominate; the residency questions soften.
Customer-facing workload: items 8 and 9 move to the top — a tool that hallucinates in German in front of your customer is a brand problem, not just a compliance one.

The build-vs-buy interaction

This checklist is also a build-vs-buy filter. If three vendors in a row fail items 2, 6, and 10, that is a signal the category is not mature enough to outsource yet and you should re-run the build vs. buy decision with a bias toward a thinner, more controllable build. Procurement due diligence and the build-vs-buy question are the same conversation viewed from two ends.

What good looks like

A vendor worth signing answers all 12 in writing, in under a week, without escalating to legal for the basics. A vendor who treats the questionnaire as friction is showing you how the relationship will run once the contract is signed and the leverage has moved to their side. The questionnaire is not bureaucracy — it is the cheapest diligence you will ever run, because every item on it is something you would otherwise learn during an incident.

How we use this with clients

We run this as a half-day exercise: we score the shortlisted vendors against the 12 points, flag the pass/fail items for the specific workload, and produce a one-page recommendation your DPO and management can sign. We have no vendor relationships and no referral fees, which is the only position from which a procurement opinion is worth anything.

If you are about to sign an AI contract and want the checklist run properly before you do, book a vendor due-diligence review. You bring the shortlist and the real workload; you leave with a scored matrix and a signable recommendation.

Related reading: