A local AI CDP.
Inside your own environment.
Personalization, audience building, reactivation, next best action, and analytics, on an AI model inside your own infrastructure.
Nothing leaves, and nobody trains on it. Every AI feature so far asked you to send your data out to reach the model. That condition is gone.
On-premise, private cloud, or your own cloud account.
Your customer data never makes the trip
personal data leaves to be scored
nothing crosses
Zero egress applies to AI, not to your network. The CDP still connects to your sources and your destinations exactly as it would otherwise.
Why your current CDP can’t do this
A tenant in someone else’s SaaS environment is, architecturally, neither private nor secure. That is the constraint most vendors are working around, and it is why they can offer you one of these three and not all of them.
Complete
CDI to campaign send in one platform, like the big suites. Suites like Adobe lock you into their cloud, and charge accordingly.
Composable
Works with your existing warehouse, CDI, or martech stack, like point tools. Point tools leave you to assemble activation yourself.
Sovereign
The complete AI stack runs inside your own cloud or on-premises environment. Prompts, context and customer data all remain within the controlled deployment boundary.
This combination cannot be retrofitted. It is the architecture.
What you can actually run
The model runs where you put it
On-premise or inside your own cloud account, in the same boundary as the data it is reading. Inference happens on your side of the line rather than in a vendor environment. Personalization, audience building, reactivation, next best action and analytics all run there. Anything touching customer data stays inside the same boundary.
No third party sees the data
Customer data is not sent out to be scored, which means it is not handed to a model provider in another jurisdiction, and it is not sitting in anyone else’s logs.
Nobody trains on it
Not sent means not learned from. Your customer data does not end up in someone else’s model, which is the assurance a security review is usually looking for and rarely gets.
Campaigns that don’t wait for an export
The reason AI features are slow to clear a security review is rarely the model. It is the journey the data takes to reach it, and the paperwork that journey creates.
Today, with a hosted AI feature
- Build the audience in the CDP
- Export the profiles that need scoring
- Send them out to the model provider
- Wait, then import the scores back
- Activate, and record the transfer for your DPO
Five steps, one of which is a cross-border transfer you have to justify every time the audience changes.
With the model inside the boundary
- Build the audience in the CDP
- Score it where it already sits
- Activate
Three steps, no export, no transfer to record. The audience can change hourly without anyone re-opening the legal question.
Built for the team that got told no
Marketing teams told to wait
If security has asked you to hold off on AI features until someone can say where the data goes, this is the answer to that question.
Regulated industries
Banking, insurance, telco, government-adjacent, and holding companies, plus retail pharma and retail travel, where a model provider in another jurisdiction is a transfer that needs its own legal basis.
Teams under residency rules
GDPR, Schrems II, Saudi PDPL. Where the model runs stops being a preference and starts being part of the compliance argument.
B2C digital-first businesses
Fintech, wealth platforms, insurtech, and marketplaces, where customer data is the core business asset and the same jurisdiction question applies even without a bank’s regulatory history.
What your compliance team will ask
Most AI-and-privacy writing treats the model as a processing question. For anyone moving personal data across a border to reach it, it is a transfer question first, and that is a harder one to answer.
GDPR and Schrems II
A prompt carrying personal data to a model provider outside the EEA is a transfer, not an internal processing step. Standard contractual clauses alone were not enough after Schrems II; supplementary measures have to make the transfer effective in practice. Running inference inside your own boundary means the transfer never happens, so the question of whether the safeguards hold never has to be argued.
Saudi PDPL
PDPL permits cross-border transfer on three grounds: an adequate-protection decision, appropriate safeguards, or a narrow exemption. In practice the first is unavailable, because SDAIA has not published an adequacy list, which pushes every transfer onto safeguards or exemptions and onto a case-by-case argument. Keeping inference in Kingdom removes the need to make that argument at all.
Sector rules and internal policy
Banking, insurance and public-sector policy often goes further than the statute, and is frequently written as a hard rule rather than a balancing test: customer data does not leave the bank’s infrastructure. A rule like that cannot be satisfied with contractual language. It is satisfied by architecture, or not at all.
This describes where data goes, not what your obligations are. Confirm those with your own counsel.
On-premise, at a major Czech bank
Komerční Banka’s regulatory environment requires full customer data control inside its own infrastructure. Vendor-managed SaaS was not an option. Meiro runs on the bank’s own physical servers, on the Kubernetes stack KB had already built. On public sites the SDK deploys normally; inside internet banking it is embedded directly into KB’s own applications, so every line of deployed code stays under the bank’s control.
KB proves the perimeter holds at bank scale. The local AI model is the newer piece, and it deploys inside that same perimeter.
Read the Komerční Banka story →Questions to take into that meeting
What is an AI CDP?
A customer data platform where the AI is part of the platform rather than a feature connected to it. The same system that resolves identity and builds audiences also runs the model that acts on them, so a marketer can ask for a segment, a next best offer or a reactivation campaign and get it back without an export, a ticket or a second tool. In a local AI CDP that model runs on your own infrastructure rather than a provider’s, which is the version described on this page.
What does the AI actually do inside a CDP?
Five things here: personalization, audience building, reactivation, next best action, and analytics. It reads the resolved customer profiles already in the platform, so it works from the full picture of a person rather than whatever subset an export happened to contain. Because the model is local, it does that reading inside your environment and the profiles never leave it.
How is this different from a CDP with an AI feature added on?
A bolted-on AI feature calls a model somewhere else, which means your customer data makes a trip out of the platform and into a provider you do not control. Here the model runs on the same infrastructure as the CDP. That is an architectural difference, not a settings one, and it is the reason the answer to "where does our data go" is "nowhere".
Can we move to this from Segment or another CDP?
Yes. The usual sequence is to run both in parallel while sources are reconnected, verify that identity resolution produces the profiles you expect, then move activation across channel by channel. What takes the time is not the migration itself but agreeing which historical data comes with you, and deciding where the local AI CDP is deployed: on-premise, private cloud, or your own cloud account.
Where does the model run?
Inside the same boundary as the data: on-premise, or in your own cloud account. The inference happens where you put it rather than in a vendor environment, which is the difference that matters to a security review.
Does anyone train on our customer data?
No. No third-party model provider receives it, so none of it ends up in someone else’s training set. That is usually the question a security team asks second, after they have asked where the data goes.
Can we still use a hosted model if we want to?
Yes. You can connect a hosted model with your own keys where convenience matters more than isolation. The point is that the choice is yours rather than the vendor’s, and that choosing isolation does not mean giving up the AI.
How does this affect a data residency obligation?
It removes a transfer. If your regulator expects personal data to stay in a jurisdiction, sending prompts containing that data to a model provider elsewhere is a transfer that needs its own legal basis. Running inference locally means the question does not arise. Confirm your own obligations with counsel. This is architecture, not legal advice.
What does zero egress actually mean here?
That customer data does not leave your infrastructure in order to be scored by a model. It is a statement about AI, not about your network. The platform still connects to your sources and your destinations exactly as it would otherwise. Nothing here implies the CDP runs offline.
How is this different from running a CDP in our own cloud?
Deploying the platform in your own cloud is a hosting decision. It says nothing about where a model runs. Most CDPs that deploy privately still send prompts containing customer data out to a model provider the moment you use an AI feature, because the model was never part of what got deployed. Here the model is part of the deployment.
Can our security team audit what leaves the environment?
Yes, and that is the point of drawing the boundary this way. Because inference happens inside your infrastructure, the outbound connections are the ones you already have: your sources and your activation destinations. There is no additional model-provider endpoint to review, log or justify.
What happens to what the model produces?
Scores, segments and generated content are written back inside the same boundary, alongside the data they were derived from. They are yours in the same way the source data is, and they leave only when you activate them to a destination you chose.
Does the model itself leave, or get shared?
No. The model runs on your side and stays there. If it is fine-tuned on your data, that fine-tuned model is yours and is not pooled, shared or used to improve anyone else's product.
What do we need to run this?
It is scoped with you rather than sold from a list. Model serving, hardware and the support boundary depend on which models you want and what you already run, so we work that through as part of the deployment scope.
See the architecture, live
On 17 September, Pavel Bulowski and Vojtech Kurka walk through what actually gets deployed: what runs where, what sits alongside your existing servers, and how the model is tested before it goes anywhere near your customer data.