The fastest way to kill an AI initiative in 2026 isn't bad technology. It's the security review. The use case is approved, the budget exists, the team is ready, and then someone from information security asks one question: "So where exactly does our data go?" If the answer involves a vendor's cloud in another jurisdiction, you've just added six months to the project. Maybe forever.
We see this constantly, and it's usually nobody's fault. The deployment model simply wasn't discussed until after vendor selection, which is the wrong order. This post is about getting it into the conversation early: what the deployment options actually are, what "your data never leaves your cloud" has to mean in practice, and the questions that separate real answers from sales answers.
Why this got serious
For years, data location was a question only banks and hospitals asked. That's over. EU AI Act obligations are now in force and phasing in by risk category, with documentation and transparency requirements that depend directly on where and how your AI processes data. Data residency rules keep tightening across jurisdictions. And legal teams have read enough vendor contracts by now to ask sharper questions about model training: is our data being used to improve someone else's product?
The practical effect is that security and legal now sit in every AI buying decision. A vendor that can't give clean answers on data flow doesn't get blocked by the CIO. It gets blocked two levels down, in a review meeting the CIO never sees.
The three deployment models
Every enterprise AI offer on the market lands in one of three buckets. The labels vary; the data flows don't.
| Vendor cloud | Hybrid | Self-hosted / your cloud | |
|---|---|---|---|
| Where data is processed | Vendor's infrastructure | Split: sensitive steps stay local, the rest goes out | Entirely inside your perimeter |
| Time to deploy | Fastest | Moderate | Moderate, depends on your infra readiness |
| Security review | Hardest: full vendor assessment, data transfer agreements | Complex: two regimes to document | Simplest: your existing controls apply |
| Data residency | Vendor's regions, check the contract | Partial control | Full control |
| Model training on your data | Contract-dependent, read clause by clause | Contract-dependent | Off by default, you hold the models |
| Audit trail | What the vendor exposes | Stitched across both sides | Your logging, end to end |
None of these is wrong everywhere. Vendor cloud is a fine answer for low-risk use cases on non-sensitive data, and it's usually the fastest start. The trouble begins when the data is regulated, confidential, or commercially sensitive, and it flows to infrastructure you don't control under a contract nobody read closely. That mismatch is what security reviews exist to catch.
"A vendor that can't give clean answers on data flow doesn't get blocked by the CIO. It gets blocked two levels down, in a review meeting the CIO never sees."
What "no data leaves your cloud" actually requires
Plenty of vendors say it. Fewer can show it. The phrase only means something if four things are true, and each one is checkable.
Model hosting
The AI models themselves run on your infrastructure: your cloud tenant or your data centre. If documents are sent to an external API for inference, data has left your cloud, whatever the marketing slide says. Ask where inference happens. The answer should be a place you administer.
Connector architecture
Integrations with your SAP, Salesforce, or document stores should run inside your network and pull data to a processing layer that's also inside it. Watch for connectors that "sync" data to a vendor staging environment first. That staging environment is someone else's cloud.
Audit trails
Every document processed, every extraction made, every automated decision should be logged in a system you control. Under the EU AI Act this stops being good practice and starts being evidence you're required to produce.
Access controls
Vendor staff access for support and maintenance should be explicit, scoped, and logged. "Our engineers may access the system for troubleshooting" is a clause worth negotiating before signature. It's much harder afterwards.
Eight questions for the security review
Put these to any AI vendor before procurement. They're the ones our own customers' security teams ask us, so we can confirm they have teeth.
- Where, physically, is inference performed? Region and infrastructure, not "securely in the cloud".
- Does any of our data leave our network at any point? Including telemetry, logs, and "anonymised usage data".
- Is our data ever used to train or improve your models? Get the answer in the contract, not the meeting.
- What audit logs exist, and who holds them? You want logs in your own systems, queryable without vendor help.
- How is vendor support access controlled and recorded? Named accounts, scoped permissions, session logs.
- What happens to our data when the contract ends? Deletion timelines, verification, and what "deletion" covers.
- Which subprocessors are involved? A self-hosted claim with three subprocessors behind it isn't self-hosted.
- Can you support deployment in our own cloud tenant? If the answer is no, every other answer above gets more important.
A pattern worth knowing: vendors with genuinely clean data-flow stories tend to answer these questions quickly and in writing. The ones who schedule a follow-up call with a solutions architect to "walk through the architecture" are often buying time. Not always. Often.
Frequently asked questions
The AI models, connectors, and processing all run inside your own infrastructure, whether that's your cloud tenant or your data centre. Your documents and operational data never leave your network perimeter, which simplifies security review, data residency, and compliance.
Yes. Obligations are now in force and phasing in by risk category. Where your data is processed, what audit trails exist, and whether you can explain automated decisions all depend on the deployment model, so the decision belongs in procurement, not after it.
No. For non-sensitive data and low-risk use cases it's often the fastest reasonable choice. The risk comes from mismatches: regulated or confidential data flowing to infrastructure you don't control, under contracts nobody read closely.
Getting started
PI2AI was built for the strict end of this spectrum. The platform runs inside your infrastructure, self-hosted or fully managed, and no data leaves your cloud. If you're scoping an AI deployment and the security review is already looming, the AI platform page covers the deployment model in detail. And before any of that, make sure you've picked the right process to start with: our selection framework is here.