In this article
Most AI Platforms Move Your Data Before You Realise It
Your legal team signed off on the vendor. Your IT team enabled the integration. And somewhere between the user’s prompt and the AI’s response, your enterprise data crossed three international borders without a single alert.
This isn’t a theoretical risk. It’s the default behaviour of most AI platforms built for speed and scale, not for your compliance boundary. The question isn’t whether your data moves. It’s whether you know where it goes and whether that satisfies your regulatory obligations.
For CIOs and data officers under GDPR, India’s DPDP Act, or sector-specific rules like IRDAI or RBI’s data localisation guidelines, “we use a reputable AI vendor” is not a defensible answer anymore.
What Data Residency Actually Means for Enterprise AI
Data residency is the requirement that certain data be stored and processed within a specific geographic boundary, typically a country or region. It exists because regulators want jurisdiction over data that affects their citizens, and because organisations need to know which legal framework governs a breach or audit.
For most enterprise software, this is manageable. You pick a cloud region, your data sits there, done. AI platforms break this model entirely. They don’t just store data. They process it through inference engines, fine-tuning pipelines, embedding models, and caching layers, each of which may sit in a different location run by a different company.
The practical gap: a vendor might store your data in Frankfurt but process it through inference infrastructure in Virginia. Both are “their platform.” Only one is in your approved region. Your data residency policy has a hole in it, and most procurement checklists don’t catch this.
The Four Places Your Data Goes When You Use an AI Tool
Most enterprise teams think of data movement as a single event: data goes to the vendor, vendor processes it, done. The reality is four distinct pathways, each with different controls and different risks.
The AI Model’s Training Pipeline
Some AI vendors use customer inputs to improve their models. This is sometimes opt-out, sometimes buried in terms of service, and occasionally the default for enterprise tiers unless you explicitly disable it. When your prompts or documents feed into a training pipeline, they don’t just pass through a server. They become part of a dataset that persists, potentially indefinitely, in the vendor’s model development environment.
The compliance problem here is specific: data used for model training may be retained in systems that have no defined deletion timeline, no clear geographic boundary, and no mechanism for subject access requests. For any data covered by GDPR’s right to erasure, this is a direct conflict.
Before you connect any enterprise data source to an AI tool, check two things: does the vendor’s enterprise agreement explicitly exclude your data from training, and does that exclusion cover subprocessors as well as the primary vendor?
Third-Party Cloud Infrastructure Outside Your Region
Almost no AI vendor runs on its own hardware. OpenAI runs on Azure. Anthropic runs on AWS and Google Cloud. Most smaller AI platforms run on one of the three hyperscalers. That’s not a problem by itself. The problem is that the cloud region serving your API call is determined by latency and load balancing, not by your compliance requirements, unless you’ve specifically negotiated otherwise.
A practical example: your organisation is headquartered in Mumbai, subject to RBI’s data localisation requirements for financial data. You integrate an AI summarisation tool. The vendor’s nearest infrastructure is in Singapore. Your financial documents are now being processed outside India’s jurisdiction on every single API call.
This is not an edge case. It’s the default behaviour for most AI API products. The fix requires contractual commitments to specific cloud regions and, ideally, technical enforcement through private endpoints or VPC peering, not just policy language.
Vendor Subprocessors You Never Approved
Your AI vendor has its own vendors. These are called subprocessors, and in most enterprise AI contracts, the primary vendor retains the right to add or change subprocessors with as little as 30 days’ notice. Each subprocessor is a separate company, operating in a separate jurisdiction, under a separate security posture.
A typical mid-size AI platform might have 40 to 80 subprocessors listed in its data processing agreement. These include cloud providers, monitoring tools, customer support platforms, analytics vendors, and specialist AI infrastructure providers. Your data touches many of them during a normal session.
The audit obligation under GDPR Article 28 requires you to maintain records of all subprocessors handling personal data. Most enterprise AI procurement processes don’t enforce this. The result is a compliance gap that shows up exactly when you don’t want it, during an audit or after a breach.
Logs, Caches, and Embeddings That Persist After Sessions End
When an AI session ends, your data doesn’t necessarily leave. Vendors maintain logs for debugging, abuse detection, and billing verification. Inference caches improve response times by storing recent inputs. Vector embeddings, the numerical representations of your documents used to power semantic search, persist in vector databases that may have no automatic expiry.
The specific risk with embeddings is underappreciated. A vector embedding of a confidential document is not a copy of that document, but it is a representation that can be used to reconstruct meaningful information about it. If your embeddings are stored in a shared vector database, the isolation between your data and another tenant’s queries depends entirely on the vendor’s implementation, not on any physical separation.
Ask your vendor three direct questions: what is the retention period for inference logs, where are vector embeddings stored and for how long, and what is the deletion process when you terminate the contract? If you don’t get specific answers with timelines and geographies, treat the data as persistent and plan accordingly.
Key takeaways
- Most AI platforms process data across multiple geographic regions by default, determined by load balancing rather than your compliance requirements.
- Training data exclusions must be explicitly contracted and must cover subprocessors, not just the primary vendor, to be enforceable.
- Vendor subprocessor lists for mid-size AI platforms commonly include 40 to 80 separate companies, each a potential residency risk.
- Vector embeddings and inference logs persist after sessions end and may have no defined deletion timeline unless you contractually require one.
- The only reliable data residency control for AI workloads is processing inside your own compliance boundary, not vendor policy language alone.
Where Data Residency Controls Work and Where They Break Down
Contractual data residency clauses work well for storage. Vendors can commit to a specific cloud region for your data at rest, and most reputable enterprise vendors do. This covers your databases, document stores, and audit logs. It satisfies the most common regulatory checklist question.
They break down at inference time. The moment you send a prompt to an AI model, you’re triggering a compute operation that may route through any available infrastructure. Some vendors offer dedicated inference endpoints in specific regions, but this is typically an enterprise add-on at significant cost, not a default configuration.
They break down completely at the subprocessor level. Your contract is with the primary vendor. You have no direct contractual relationship with their cloud provider, their monitoring vendor, or their specialist AI infrastructure. The chain of data processing agreements that should protect you is only as strong as the weakest link, and most enterprise procurement teams have never reviewed a full subprocessor chain end to end.
The honest position: for regulated data under strict localisation requirements, contractual controls alone are insufficient. Technical enforcement, meaning your data never leaves your environment to reach the AI model at all, is the only approach that holds up under regulatory scrutiny.
Three Ways to Audit and Control Where Your Data Goes
You have practical options here. None of them are zero-effort, but all of them are achievable within a normal enterprise IT cycle. Pick the level of control that matches your regulatory exposure.
Option 1: Map Every AI Integration to Its Data Processing Location
Start with an inventory. List every AI tool your organisation uses, including shadow IT deployments where teams have connected AI tools without formal IT approval. For each tool, identify the primary vendor, their cloud infrastructure provider, the regions where inference actually occurs, not just storage, and the current subprocessor list from the DPA.
This exercise typically surfaces surprises. A document summarisation tool that procurement approved for a European team may be processing through US-based inference infrastructure. A customer service AI that your IT team thinks is GDPR-compliant may have added a subprocessor in the last quarterly update to their DPA that no one reviewed.
Build this map into a living register, reviewed quarterly. The AI vendor landscape changes fast. Subprocessors change. Infrastructure partnerships change. A map that was accurate six months ago may have three new gaps today.
Option 2: Require Contractual Data Residency Guarantees Before Procurement
Add a data residency checklist to your AI procurement process before any purchase order is raised. The checklist should require vendors to specify inference regions in writing, not just storage regions. It should require subprocessor lists with geographic annotations, a minimum notice period of 60 days for any subprocessor changes, and explicit training data exclusions that cover the full processing chain. For a broader framework on evaluating AI vendors against enterprise requirements, the Enterprise Low-Code Platform Buyer’s Guide covers the procurement criteria that hold up under compliance scrutiny.
Most enterprise AI vendors will negotiate on these points if you ask specifically. Many won’t volunteer the information. The vendors who refuse to provide regional inference commitments at the enterprise tier are telling you something important about their architecture and how much control they actually have over it.
Add a contract clause requiring the vendor to notify you within 72 hours of any subprocessor change that affects the geographic location of data processing. This aligns with GDPR notification expectations and gives you a practical trigger to reassess the integration if a new risk appears.
Option 3: Run AI Workloads Inside Your Own Compliance Boundary
For the highest-sensitivity data, the only reliable answer is to bring the AI model to the data rather than sending the data to the model. This means deploying AI infrastructure within your own cloud environment or on-premises data centre, inside the boundary where your data residency controls already apply.
This is increasingly practical. Models like Llama 3, Mistral, and enterprise-licensed versions of larger models can be deployed privately. Cloud providers offer dedicated AI infrastructure within specific regions. Tentoro’s approach for enterprise clients is to run AI workloads within the customer’s own cloud tenant, so data never leaves the approved environment to reach the model, not even for inference.
The cost is higher than a shared API. But for a 300-person legal team processing confidential client documents, or a financial institution running AI on transaction data subject to RBI localisation rules, the alternative is a compliance position that won’t survive a regulator’s scrutiny. Run the numbers on what a regulatory breach costs and the private deployment cost looks different. It’s also worth considering whether smaller, privately deployable models can meet your enterprise use case before assuming you need the largest available model running on shared external infrastructure.
Frequently Asked Questions
What to do next
Pull your current list of AI tools in production, including the ones your team deployed without formal IT approval, and check one thing: where does inference actually happen? Not where the data is stored. Where the compute runs when a user sends a prompt.
If you don’t have that answer for every tool on the list, you have a compliance gap. Start with your highest-sensitivity data flows first: anything touching financial records, legal documents, customer PII, or regulated health information. Map the processing location. Check the subprocessor list
