A local AI CDP.
On-premise or private cloud.
Personalization, audience building, reactivation, next best action and analytics, all running on a model that sits inside the same deployment as the data it reads.
Nothing leaves, and nobody trains on it. AI features normally reach the model by sending customer data out of the platform. This one does not.
An open-source model Meiro deploys, or a hosted model connected with customer-held keys.
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 most CDPs can’t do this
In vendor-operated SaaS the vendor holds the account, the region and the keys, whoever the vendor is. 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 customers into their cloud, and charge accordingly.
Composable
Works with an existing warehouse, CDI or martech stack, the way point tools do. Point tools then leave the activation layer to be assembled separately.
Sovereign
The complete AI stack runs inside a private cloud or on-premise environment. Prompts, context and customer data all remain within the controlled deployment boundary.
This combination cannot be retrofitted. It is the architecture.
Five jobs, all on resolved customer profiles
Each one reads the profile Meiro already maintains, so the model works from resolved identity rather than a flat export. All five run on the same model, in the same deployment.
Real-time personalization
Web and in-app content chosen per person as the session happens, including for anonymous visitors matched to a known profile. How personalization works
Audience building
Segments described in plain language and built against every attribute on the profile, with the model proposing the definition for a person to approve.
Reactivation and churn
Lapsing customers scored against their own history, so a win-back reaches the people whose behaviour has actually changed rather than everyone who went quiet.
Next best offer
The next action ranked per person at the moment of contact, from the same profile the rest of the platform reads. Common in banking, where the offer has to be defensible.
Analytics in plain language
Questions asked of the customer base in words rather than SQL, answered against the profile store without exporting anything to a separate analytics tool.
Three guarantees the deployment makes
The model runs where it is deployed
On-premise or inside a private cloud account, in the same boundary as the data it is reading. Inference happens on the customer 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. 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 teams 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 compliance teams 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 the same boundary as the data 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 whether a given regulation is satisfied. Confirm that with legal 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-premise or in private cloud rather than at a provider’s.
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 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 a private cloud account.
Where does the model run?
Inside the same boundary as the data: on-premise, or in a private cloud account. The inference happens where it is deployed 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 using keys held by the customer, where convenience matters more than isolation. The point is that the choice is theirs 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 an existing 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 the network. The platform still connects to the sources and the 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 a private 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. Inference happens inside your infrastructure, so the outbound connections are the ones you already have: the sources and the 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 the 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 customer data.