Connecting an AI application to a CRM or a customer data warehouse is relatively easy.
The harder part is deciding what the AI should actually receive.
A customer may exist in a CRM, an e-commerce platform, a support system, a billing database, an email platform, and several other systems. Each system contains only part of the picture.
Bringing all those records together is useful, but it does not automatically produce a customer profile that an AI system can reliably work with.
Before customer data becomes useful context for AI, several architectural problems need to be addressed: identity resolution, event processing, derived signals, consent, governance, data freshness, and the different views required by different applications.
This article looks at those problems from a data architecture perspective.
A customer profile is not a data dump
A common approach to customer data is to collect as much information as possible and make it available to downstream applications.
That can work for analytics, where the analyst can decide which fields and tables are relevant.
AI applications are different.
An AI system may need a much more deliberate representation of the customer. It needs to understand which information is relevant, how different pieces of data relate to each other, and which information represents the current state versus historical behavior.
Consider a customer support assistant.
It may need:
- the customer's current account status
- recent orders
- open support cases
- previous interactions
- relevant product information
A sales assistant might need a different subset:
- commercial relationship
- products purchased
- order history
- account information
- recent activity
A personalization system might instead be interested in behavioral signals and preferences.
The underlying data can be the same, but the useful representation is different.
This suggests a useful separation between the customer data foundation and the customer views exposed to applications.
The foundation contains the information needed to reconstruct and understand the customer. Application-specific views provide the context needed for a particular use case.
Events and records describe different things
Customer data generally contains two different kinds of information.
Records describe a current state: A customer has a particular account status, address, subscription, price plan, or set of entitlements.
Events describe something that happened:
A customer placed an order, opened an email, visited a product page, contacted support, changed a subscription, or interacted with a service.
Both are important, because:
If the profile contains only the current state, an AI application may lose important historical context.
If it contains only raw events, every application has to reconstruct the current state itself.
That leads to another architectural question: where should the transformation from raw events to useful customer context happen?
Suppose a customer has visited the same product category twelve times during the last month.
The raw events might look something like this:
2026-08-12 product_view category=A
2026-08-14 product_view category=A
2026-08-16 product_view category=B
2026-08-20 product_view category=A
...
An AI application may not need to process every individual event.
It may be more useful to expose a derived signal such as:
recent_interest:
category: A
event_count: 12
period: 30 days
The important point is not that every customer profile should contain this exact type of signal.
The point is that raw events and derived customer context serve different purposes, and the transformation between them should be deliberate and reproducible.
Identity resolution is at the core
Before an AI system can reason about a customer, it needs to know which records actually belong to that customer.
This is one of the fundamental problems in customer data architecture.
The same person may appear with different identifiers across different systems:
CRM
customer_id = 18427
E-commerce
customer_id = C-92831
Support
email = mario@example.com
Mobile app
device_id = 7f3a...
The identifiers may or may not refer to the same person.
Where reliable identifiers exist, deterministic matching is generally easier to understand and audit.
In other cases, more complex matching techniques may be necessary. Whatever approach is used, the result should remain explainable.
If two records are merged into the same customer identity, it should be possible to understand why.
This matters because an incorrect merge can introduce information from one person into another person's profile. Once that information becomes context for an AI application, the original identity error can propagate into subsequent interactions or decisions.
Identity resolution therefore should not be treated as a one-time preprocessing step.
It is part of the customer profile itself.
Keep the source data. Make the profile rebuildable.
Customer profiles are derived data.
That has an important architectural consequence: the profile should be possible to rebuild.
Imagine that an organization changes its identity-resolution rules.
Perhaps a new identifier becomes available, an existing matching rule was too aggressive, or a new source system is added.
If the only thing that exists is the final merged profile, changing the rules can become difficult or even impossible without starting over.
A more robust approach is to preserve the underlying information required to reproduce the profile:
Source records
+
Events
+
Identity rules
+
Merge history
↓
Customer profile
The profile is then a derived representation rather than an irreversible transformation of the original data.
This also makes experimentation easier.
If identity rules or profile logic change, the profile can be recomputed without losing the underlying history.
That property becomes increasingly important as customer data models evolve to support new AI applications.
Explainability matters more than clever matching
There is often a temptation to focus on how sophisticated the identity-resolution algorithm is.
But from an operational perspective, the ability to explain a result can be just as important as the matching technique itself.
Consider a profile that contains three source records.
Why were they merged?
Was it because they shared an email address?
Was it because several identifiers matched?
Was a probabilistic rule involved?
Did one rule have a higher confidence than another?
The system does not necessarily need to expose every internal implementation detail to every user, but the information should be available when a profile needs to be investigated.
This is particularly important when customer data becomes input to AI systems.
The more downstream applications depend on the profile, the more difficult it becomes to treat identity resolution as an opaque process.
Consent is part of the customer context
Making more customer data available to AI does not automatically make the system better.
Customer information has a purpose, a context and a set of permissions.
A support assistant, a marketing application and an internal analytics system may have different legitimate uses for the same underlying data.
This means that governance cannot be added only at the final API layer.
The customer data architecture needs to know enough about the context of the data to control which information becomes available to which applications.
The goal is not to create one enormous profile containing every possible attribute and then give every AI application access to it.
Instead, the system should be able to provide appropriate views of the underlying customer data.
Consent and purpose therefore become part of the logic that determines what can appear in an AI-facing customer view.
One foundation, different views
Once identity and underlying customer data are handled properly, another design question appears.
Should there be one customer profile for every application?
Probably not.
A better model is often:
Customer Data Foundation
|
+------------+------------+
| | |
↓ ↓ ↓
Support Sales Personalization
View View View
| | |
↓ ↓ ↓
AI assistant AI copilot AI system
The underlying customer identity and history remain consistent.
The representation exposed to each application can be different.
This avoids creating a completely separate customer-data model every time a new AI use case is introduced.
It also creates a useful boundary between the data foundation and the application consuming it.
The application does not necessarily need unrestricted access to the entire customer dataset. It needs a controlled representation of the customer that is appropriate for its purpose.
The warehouse can remain the center of gravity
This does not necessarily mean that an AI application should query the customer data warehouse directly.
The warehouse or lakehouse can remain the governed center of the customer data architecture, while different delivery mechanisms sit in front of it.
Depending on the use case, customer context might be exposed through an API, a cache, a semantic layer, or another retrieval mechanism.
The important distinction is between where the customer data is governed and how an application consumes it.
Moving customer data into a separate repository simply because an AI application needs it can introduce another copy of the data, another synchronization problem, and another governance boundary.
Keeping the underlying customer data in the environment where it is already managed can reduce that fragmentation.
Freshness is an end-to-end problem
“Real time” is often used as though it were a single technical property.
It isn't.
Suppose a customer places an order.
There may be several steps between that event and an AI assistant seeing the updated customer context:
Order placed
↓
Source system records event
↓
Event reaches data platform
↓
Identity/profile is updated
↓
Customer view is refreshed
↓
Cache or retrieval layer is updated
↓
AI application sees new context
Each step can introduce latency.
The required freshness also depends on the use case.
A support assistant may need a recent interaction to become available within minutes.
Another application may work perfectly well with data refreshed every few hours.
For this reason, “real time” should be treated as a requirement to define for a specific use case rather than as a generic property of the customer platform.
The useful question is not simply how fast is the CDP?
It is how fresh does this particular customer context need to be when the AI uses it?
The customer profile becomes a data product
Once customer data becomes a foundation for AI, the profile itself starts to look like a data product.
It needs ownership.
It needs documented definitions.
It needs quality controls.
It needs access rules.
It needs monitoring.
And it needs a way to evolve without breaking the applications that depend on it.
This is particularly important because an AI application may consume customer data without knowing how that data was originally produced.
If an application receives a field such as:
customer_status = "at_risk"
there should be a clear definition of what that field means, how it is calculated, how current it is, and where its underlying data comes from.
The same principle applies to identity, derived signals and other customer attributes.
In that sense, the customer profile becomes part of a data contract between the customer data foundation and the applications using it.
What kind of CDP can support this?
These requirements change the role of a Customer Data Platform.
A CDP designed primarily around data collection, audience creation and campaign activation addresses an important set of use cases.
**But an AI-oriented customer data architecture has additional requirements.
It needs to preserve customer history, resolve identities, support derived signals, handle governance and consent, provide purpose-specific views, and make the resulting profile rebuildable as the underlying rules evolve.**
This does not necessarily mean replacing existing marketing infrastructure.
It means recognizing that the customer profile may have to serve a broader role than it traditionally has.
Instead of being primarily an activation layer, it can become part of the data foundation used by multiple AI applications.
And that leads to a broader architectural question:
What should a CDP look like when its job is no longer limited to campaigns and activation?
That is the subject of the next article in this series:
The CDP Was Built for Campaigns. AI Needs Customer Memory.
