Answering security questionnaires about AI residency, line by line

The AI addendum is where deals stall

I review several security questionnaires a week, from both directions: the ones customers send us, and the ones customers ask for help with when their own buyers question their AI features. The standard frameworks, SIG and CAIQ style questionnaires among them, have long covered encryption, access control and hosting. What has changed is the AI addendum stapled to the end. It is usually written by the buyer's privacy team rather than its security team, and it is where enterprise deals for AI features stall.

The questions are consistent from buyer to buyer, even when the wording is not. If you can answer these six precisely, you can answer almost any version of the addendum.

• In which countries are prompts and completions processed, including by subprocessors?
• Which legal entities can access prompts in the clear, and under which laws can they be compelled to disclose them?
• Are prompts or completions retained, logged, or used to train or improve models, by you or any provider?
• How long does any provider keep inputs for abuse monitoring, and who reviews them?
• How will you notify us before adding a subprocessor or changing a processing location?
• What evidence shows that requests were processed where you say they were?

Processed is not stored

The most common weak answer is a storage answer to a processing question. "Customer data is stored in Frankfurt" can be true and irrelevant if the prompt goes to a model endpoint in another region for inference. A buyer's DPO knows that a Chapter V transfer happens when personal data is made accessible in a third country, whether or not anything is written to disk, and will read your answer with that in mind.

Answer per data flow. For each AI feature, state where the prompt is processed, by which provider and in which region, and what happens when that region is unavailable. If the answer depends on the customer's configuration, say so and describe the default. A good answer reads like this: "Prompts from EU tenants are processed by Amazon Bedrock in eu-central-1 (Frankfurt) under the eu-gdpr-strict policy pack. If Frankfurt is unavailable, requests fail over to Dublin or Paris and never leave the EEA. If no EEA endpoint is available, the request fails and is not forwarded."

Name the whole chain

Buyers increasingly ask for the full processing chain, and they are right to. Under Article 28(2) a processor may engage another processor only with the controller's prior specific or general written authorisation, and under a general authorisation it must inform the controller of intended changes so the controller can object. The model provider behind your AI feature is a subprocessor in that chain, and so is any gateway in front of it.

For each hop, give the legal entity, its country of incorporation, its ultimate parent, the processing region, the retention period and whether its staff can access content. Be specific about abuse monitoring. Many model providers keep inputs for a limited period to detect misuse unless you have a zero retention arrangement, and some allow human review of flagged content. If that applies to your configuration, say so and quote the period from the provider's own terms. A buyer who finds it later will reread every other answer you gave.

Retention and training, stated exactly

"We do not train on your data" answers half the question. State what is retained, where and for how long, separately for content and for metadata. For our own gateway the answer is short. Prompts and completions stream in memory, are never written to disk and are never used for training. What we keep is a receipt for each request, which holds a hash of the request rather than its content, together with the policy pack and version, the resolved endpoint, the provider region, the model id and a timestamp. Receipts and configuration are encrypted at rest with AES-256.

Then answer for the provider hop with the same precision, because the buyer will read your answer as covering the whole chain. If a provider's zero retention applies only to certain endpoints, or only after an approval, state which applies to the endpoints you actually use.

The CLOUD Act question, answered honestly

Nearly every questionnaire from a European buyer asks some version of "can US authorities obtain our data?" The honest answer for most AI stacks has two parts. YTT SECUNET PRIVATE LIMITED is incorporated in India, and we do not claim that this puts us outside the reach of the CLOUD Act or of Indian access law. What we can describe is how little there is to reach: prompts are not retained, so there is no stored content to produce, and customers on Sovereign Dedicated run the data plane in their own VPC or data centre with signing keys held in their own HSM.

Apply the same honesty to providers. A model endpoint in Frankfurt operated by a US-parented company is in the EU for latency and residency purposes, but its operator can still receive a US legal demand, because the CLOUD Act reaches data in a provider's possession, custody or control wherever it is located. Say so, describe the mitigations that apply, and point to your transfer impact assessment. A claim of immunity is the fastest way to lose a sophisticated reviewer.

Attach evidence, not adjectives

Answers backed by documents close faster. Attach the SOC 2 Type II report, the ISO 27001 and ISO 27701 certificates, the DPA, the subprocessor list with regions, and the transfer impact assessment support pack. Then give the reviewer something they can verify without trusting you. Every gateway response carries a signed receipt in a header, and the buyer's security team can check its signature and Merkle inclusion proof with the open-source ytt-verify tool. Offer to do it live in the review call: it turns the residency question from an argument into a demonstration.

POST /v1/chat/completions HTTP/1.1
Host: eu.yttsecunet.com
Authorization: Bearer jr_live_...
X-YTT-Policy: eu-gdpr-strict@4.2.0
X-YTT-Tenant: security-review

HTTP/1.1 200 OK
Content-Type: application/json
X-YTT-Proof-Signature: eyJhbGciOiJFZERTQSIsImtpZCI6Imp1cmlzcm91dGUtZXUtMjAyNnEzIn0...

Keep the answers tied to the configuration

The last failure mode is drift. An answer written in March describes the routing in March. When an engineer adds a provider in June, the questionnaire on file is wrong, and nobody notices until the renewal. Keep an answer library in version control, where each answer names the configuration it describes, an owner and the date it was last verified. When the policy pack or the routing file changes, every answer that references it goes back to its owner for review before the next questionnaire leaves the building.

id: ai-residency-processing-location
question: "Where are prompts and completions processed?"
answer: >
  Prompts from EU tenants are processed by Amazon Bedrock in eu-central-1
  (Frankfurt) under the eu-gdpr-strict policy pack. Failover stays inside
  the EEA (eu-west-1 Dublin, eu-west-3 Paris). If no EEA endpoint is
  available, the request fails and is not forwarded.
source_of_truth:
  - policy: eu-gdpr-strict@4.2.0
  - routing: tenants/eu-default.yaml
evidence:
  - receipts: monthly bundle checked with ytt-verify --strict
  - subprocessors: https://yttsecunet.com/legal/subprocessors
owner: deepa.nair
last_verified: 2026-09-28
review_on_change: true