What procurement actually asks about your AI

Why do these questions decide the deal?

When an enterprise buys software that touches personal data, the deal does not close in the demo. It closes after a vendor security review, run by people whose job is to find the weak answer. For AI features, the review concentrates on one theme: where does the data actually go, and can the vendor prove it?

Below are the questions that recur, why they are asked, what a weak answer looks like, and what a defensible answer contains. If you can answer all of them with documents rather than sentences, the review becomes a formality.

"Do you transfer personal data outside the EU/EEA? Under what mechanism?"

Why they ask. Transfers of personal data to countries outside the EU/EEA are restricted under Chapter V of the GDPR. Since the Schrems II judgment (CJEU Case C-311/18, 2020) invalidated the EU-US Privacy Shield, buyers know that transfer arrangements need individual scrutiny, not a checkbox. Their DPO is personally on the hook for approving your answer.

A weak answer. "Our infrastructure is hosted in the EU." This does not answer the question. It says where the servers are, not whether any processing step, sub-processor, or support path moves data out.

A defensible answer. A per-flow statement: which data leaves the EU (if any), to which recipient, under which mechanism (an adequacy decision, standard contractual clauses, or another Article 46 safeguard), and with what supplementary measures. If nothing leaves, a statement of that fact backed by an audited data-flow map, not by assumption.

"Provide your complete sub-processor list, including AI providers."

Why they ask. Under Article 28 GDPR, engaging another processor requires the controller's authorisation, and buyers inherit risk from every name on your list. AI features tend to add sub-processors quickly: model providers, vector databases, evaluation tools, logging services. Buyers have learned that the published list is often the stale one.

A weak answer. A list that names your cloud provider and payment processor but omits the model API, the error tracker that receives prompt fragments, or the analytics tool that sees user content. Omissions found later read as concealment, even when they were oversight.

A defensible answer. A complete, dated list that includes every AI-path service, each with its processing location, its corporate jurisdiction, and its role in the data flow. The list matches the data-flow map exactly. Where a sub-processor is EU-hosted but US-owned, the list says so instead of hoping nobody checks.

"What is your Schrems II posture for US-owned providers?"

Why they ask. An EU region of a US-owned cloud passes a residency check while the operating entity remains subject to US law, including the CLOUD Act, which can compel US providers to produce data they control regardless of where it is stored. Sophisticated buyers ask about this gap directly.

A weak answer. "All our providers are GDPR compliant." Compliance claims by vendors about their own vendors carry no evidential weight, and the phrase signals that the distinction between residency and jurisdiction has not been understood.

A defensible answer. An honest mapping: which dependencies are EU-owned, which are EU-hosted but US-owned, what data each one can access, and what mitigations apply (encryption arrangements, pseudonymisation before the data reaches the provider, contractual measures, or planned migration). Nearly every modern stack carries some exposure here. Buyers do not expect zero; they expect you to know exactly where yours is.

"Show us the DPA chain for the AI path."

Why they ask. A data processing agreement with you is worthless to the buyer if the chain breaks one level down: if your model provider's terms permit training on customer data, or if a tooling vendor in the path has no DPA at all. Reviewers increasingly walk the chain.

A weak answer. Your own DPA template, with silence about the layers beneath it.

A defensible answer. The full chain: your DPA with the customer, your agreements with each AI-path sub-processor, and the specific terms governing training use, retention, and deletion at each layer. Where a provider offers a zero-retention or no-training option, evidence that it is actually enabled on your account, not just available.

"Where do prompts, embeddings, and logs physically live?"

Why they ask. These are the three places AI features leak residency in practice. Prompts can contain anything a user types, embeddings are derived from personal data and are personal data when they relate to identifiable people, and logs are copied into observability platforms nobody thought to include in the compliance review.

A weak answer. "Data is processed in the EU." Singular "data", no breakdown, no mention of logs or caches.

A defensible answer. A per-artifact account: prompt storage location and retention, embedding storage and the region of the vector store, log destinations including third-party observability tools, cache locations, and backup geography. This is exactly one row group of a sovereignty matrix, which is why the matrix format exists.

What should you do with this list?

Two things. First, answer each question for your own stack in writing before a buyer asks; the gaps you find are your remediation backlog. Second, notice the pattern: every defensible answer is a document, and every weak answer is a sentence. An audit is the process of replacing sentences with documents.