A note before you start: This is a detailed article, because building an AI-ready customer profile involves more than simply connecting data sources. We explore identity resolution, events, signals, consent, governance, freshness, and the different ways customer data can be exposed to AI.
It is a longer read, so take your time. If you're working on Customer AI or customer data architecture, we believe the details are worth exploring.
In the first article of this series, we looked at a problem that appears in many AI projects involving customer data: before AI can help a customer, a sales representative, a support agent, or a product experience, it needs to understand who that customer is.
Not approximately, and not according to a single system. It needs a customer representation that remains coherent when information comes from different systems, different identities, and different business contexts.
That is the idea behind an AI-ready customer profile.
The term itself, however, can easily become another vague label. CRMs and CDPs have customer profiles. Support, marketing, product analytics, and billing systems all have their own version of the customer.
So what actually makes a profile ready for AI?
The answer is not simply that it contains more data. In many cases, giving AI more data without adding structure and context makes the problem harder.
An AI-ready customer profile is a controlled representation of the customer, built from reliable sources, connected through explainable identities, governed according to how the data can be used, and exposed through views that are appropriate for each AI use case.
That may sound less impressive than connecting an AI system to every customer data source available. In practice, however, it is much closer to what a reliable system needs.
A Customer Profile is not a data dump
One of the easiest mistakes to make is to think of a customer profile as a container where every known fact about a person or company should be collected.
It is an understandable approach. If the AI has access to everything, perhaps it can decide what is relevant.
The problem is that this moves an important part of the data architecture into the AI application itself.
A customer profile used by AI should not simply combine raw events, CRM fields, support notes, marketing attributes, billing records, and product usage data. Those sources are important, but they serve different purposes and describe the customer from different perspectives.
Moreover, it's crucial that original data remain available. Events should remain part of the history. Source records should remain traceable. Identity relationships should be explainable, and consent changes should be preserved.
But the data that exists in the customer data foundation is not necessarily the same data that should be presented directly to an AI application.
Consider a customer care assistant. It may need to know that a customer has three open tickets, that the latest one is critical, that the account is on an enterprise plan, and that the customer has recently experienced repeated login failures.
It probably does not need every page view, email click, campaign membership, sales note, or raw event property collected over the previous two years.
A sales copilot would need a different view. It might need the account owner, renewal date, contract value, recent product adoption, expansion signals, and unresolved support risks.
A product personalization system would need something different again: recent behavior, preferences, active plan, eligibility, and consent status. It should not automatically receive sensitive billing information or private support conversations.
The underlying customer data can be shared by all of these applications. What changes is the representation that each application actually consumes.
This leads to an important distinction: there is no single universal AI profile.
There is a unified customer data foundation, and from that foundation different controlled views can be created for different purposes.
Events tell you what happened
Customer data generally comes in two broad forms: events and records.
Events describe what happened.
A user signed up, logged in, opened a support ticket, used a feature, clicked an email, failed a payment, cancelled a subscription, or changed a consent preference.
Events are important because AI often needs recent context. A CRM record may say that a customer is active, but that tells us little if the customer has opened five support tickets in the last week, stopped using an important feature, and experienced two failed payments.
Events capture movement. They show behaviour, timing, sequence, and recency.
But events also become difficult to work with when they are not governed.
Event names change. Properties evolve. Different teams track the same concept in different ways. A field that was optional can later become essential. An anonymous identifier may be used before login and then need to be connected to a known user.
The same action can also be tracked twice by different systems.
Even seemingly minor changes can matter. A product release may rename an event property, or one system may start sending plan_name while another uses subscription_plan for essentially the same concept.
Nothing may appear broken at the time. Over time, however, profile logic can end up working with several slightly different interpretations of the same reality.
If those differences are ignored, the customer profile is built on unstable data.
This is why important events need structure. They should have clear names, required fields, source information, timestamps, and appropriate schema validation. It should be possible to distinguish a valid event from a malformed one, understand which version of an event schema was used, and reprocess events when the logic used to build customer profiles changes.
For AI, event quality is therefore more than an analytics concern. It directly affects the system's understanding of what is happening with the customer now.
Records tell you what is true now
Events alone are not enough.
Important customer information also lives in records maintained by SaaS and operational systems: CRM, billing, support, marketing automation, product databases, contract management, customer success platforms, and consent management systems.
These records often describe the current state of the customer.
The CRM may know the account owner, lifecycle stage, pipeline status, open opportunities, and renewal process.
Billing may know the subscription status, current plan, payment failures, contract value, renewal date, and cancellation status.
Support may know open tickets, severity, SLA status, escalation history, and recurring issues.
The consent system may know which purposes are allowed and which have been revoked.
If an AI application sees only events, it may understand what happened without knowing what is currently true. On the other hand, if it sees only operational records, it may understand the current state without seeing the recent behaviour that explains why that state is changing.
A useful customer profile needs both, because Events can answer questions such as:
What happened recently?
Which behaviour changed?
What sequence led to the current situation?
Which signals are still fresh?
.. and Records answer different questions:
What is the current plan?
Who owns the account?
Is the subscription active?
Which company does this person belong to?
Which consents are currently valid?
The profile should combine these two perspectives without confusing them.
From raw events to customer signals
If events preserve history and records describe current state, what should actually become part of the profile used by AI?
In many cases, the answer is not the raw data itself, but a set of states, summaries, derived metrics, identity relationships, permissions, and relevant recent signals.
For example, instead of putting every support event into an AI context, the profile might contain the number of open tickets, the latest severity, escalation status, recurring issue category, and date of the last support interaction.
Instead of exposing every billing record, it might contain subscription status, current plan, renewal date, payment risk, and outstanding invoice status.
The original data is still there. It can be used for investigation, analytics, auditing, or rebuilding the profile when the underlying logic changes.
The profile simply provides a more structured representation of what matters to the application.
This distinction becomes particularly important for AI because context should be intentional. Even when a model can technically process a large amount of information, that does not mean every available field belongs in every interaction.
If the AI has to reconstruct the meaning of raw data every time it receives a request, part of the data architecture has effectively been delegated to the model.
A well-designed profile moves that work into a layer where it can be defined, tested, governed, and reused.
The goal is not to hide the complexity of customer data. It is to put that complexity in the right place.
Identity Resolution is at the Core
Among all the elements that make up a customer profile, identity resolution is one of the most important.
Without it, the profile is essentially another collection of records.
Customer identity is fragmented by nature.
The same person may appear as an anonymous website visitor, a trial user, a CRM lead, a billing contact, a support requester, a product administrator, and a marketing subscriber.
They may register with a personal email address and later use a company email. They may belong to more than one workspace. They may change companies. They may interact through a shared inbox.
In B2B environments, the situation becomes even more complex because the concept of a customer is rarely limited to one individual.
There may be a company, an account, a legal entity, a workspace, a buying committee, administrators, buyers, and operational users, all connected through different relationships.
For this reason, it is useful to distinguish between identities and profiles.
An identity is an individual identifier: an email address, user ID, device ID, anonymous ID, CRM contact ID, billing customer ID, support user ID, account ID, company domain, or workspace ID.
A profile is the result of linking some of these identities according to defined rules.
That distinction has practical consequences.
If records are merged destructively, the system becomes difficult to explain and even more difficult to correct. When two identities are combined and the original information disappears, it becomes harder to understand what happened or rebuild the profile if the matching rules later change.
A more robust approach is to preserve the atomic identities and treat the customer profile as a derived object.
The profile is then not the original source of truth. It is the current interpretation of the underlying identities, records, and events.
And that interpretation should be explainable.
Explainability matters more than clever matching
Identity resolution is sometimes presented as a search for the most sophisticated possible matching algorithm.
There are certainly situations where probabilistic matching can be useful. A system may compare names, email addresses, company information, devices, behavioural patterns, or other attributes to estimate whether two records represent the same entity.
But when customer profiles are used by operational AI, the ability to explain a match can be more important than the sophistication of the matching method.
Consider what happens if two different people are incorrectly merged.
An AI application could expose information belonging to one customer to another!
It could recommend the wrong action, misunderstand the relationship with an account, or treat someone as having permissions they do not actually have.
For that reason, deterministic matching should generally provide the foundation where reliable identifiers are available.
Examples include a shared internal user ID, a verified login connecting an anonymous ID to a known user, a verified and normalized email address, a billing customer ID explicitly linked to an account, or a CRM contact ID mapped through a trusted integration.
Probabilistic matching can still have a role. It may be useful for suggestions, enrichment, review queues, or lower-risk personalization.
But the application should know the difference between a relationship that is certain, one that is likely, one that has been inferred, and one that is still disputed.
More importantly, the system should be able to explain why two identities were joined.
For example:
This anonymous identifier was connected to this user ID after login.
This support requester was connected through the same verified email address.
This billing customer was connected to this account through a trusted billing integration.
This identity was not automatically merged because the email address is generic.
That information is useful when debugging a data pipeline. It is also important when an operator needs to understand why an AI application believes it is dealing with a particular customer.
Profiles must be rebuildable
Identity rules are not permanent.
A company may decide that shared addresses such as support@, admin@, or accounting@ should not automatically identify an individual. It may introduce a new billing system, replace its CRM, add workspaces, change its account hierarchy, or decide to represent users and companies more explicitly.
When these rules change, customer profiles need to be rebuildable.
This is one of the important differences between a simple profile store and a customer data foundation.
If the system stores only the final merged profile, changing the identity logic becomes difficult. The original relationships may already have been collapsed, making it hard to determine which identities contributed to the profile or to undo an incorrect merge.
If, instead, the system preserves the atomic identities, source records, events, matching rules, and merge history, the profile can be recalculated.
That makes the architecture more adaptable as data quality improves, identity rules evolve, and new AI use cases appear.
An AI-ready profile should therefore not be thought of as a static object. It is a derived representation that can change as the underlying understanding of the customer changes.
Consent is part of the Profile
Consent and purpose limitation cannot simply be added after the customer profile has been created.
This becomes particularly important for AI because the same customer information may be appropriate for one purpose and inappropriate for another.
A support assistant may need recent ticket history to help an agent solve a customer problem, but a sales copilot may not be allowed to use the same information for commercial scoring.
A personalization system may use product behaviour while being prevented from accessing sensitive support information.
A model-training pipeline may have requirements that are different again from those of an operational retrieval system.
The customer data foundation therefore needs to know more than whether a piece of data exists. It needs enough information to determine whether that data can be used in a particular context.
This does not mean that a CDP needs to replace a consent management platform. In many architectures, the consent management platform remains responsible for collecting and managing preferences.
But that information needs to reach the customer data foundation and influence how profiles and AI-facing views are constructed.
A useful profile should be able to represent which consents are active or revoked, when and where they were collected, which purposes are allowed, which categories of data are excluded, and which AI use cases can access particular fields.
Otherwise, a company may have the correct consent information somewhere in its systems while still putting inappropriate data into an AI context.
Keep the Profile where you can govern It
This raises another architectural question: where should the AI-ready customer profile live?
There is no single answer for every organization, but for many enterprise use cases the data warehouse or lakehouse is a natural center of gravity.
In most companies, customer information is distributed across multiple operational systems. The warehouse is often where CRM data, billing records, support information, product events, account hierarchies, and internal models can be brought together, audited, and reused.
If unified profiles exist only inside a vendor platform, organizations may face limitations around access to the underlying data, proprietary APIs, identity lineage, auditing, and long-term control over the customer representation.
This does not mean that an AI application should query the warehouse directly for every interaction.
A production system may use an internal API, a cache, a semantic layer, a retrieval service, or an operational store.
The important point is where the governed customer representation can be inspected, rebuilt, and connected to the rest of the company's data architecture.
The exact technology can vary. The ability to retain control over the customer data should not.
One foundation, different views
Even a unified customer profile can be too broad for a particular AI application.
A complete profile may contain information relevant to analytics, customer success, compliance, support, billing, and marketing. There is no reason for every AI system to have access to all of it.
This is where purpose-specific views become useful.
A support assistant might receive customer identity, current plan, open tickets, recent support interactions, entitlement information, and support permissions.
A sales copilot might need the account profile, opportunity status, renewal date, product adoption signals, account health, expansion indicators, and a summary of support risk.
A personalization system might need recent product behaviour, preferences, eligibility, lifecycle stage, personalization consent, and suppressed categories.
All of these views can be derived from the same customer data foundation without exposing the same information to every application.
This separation also makes AI systems easier to evaluate. If an application receives a context designed specifically for its purpose, it becomes easier to understand what information it is using and why.
Freshness depends on the Use Case
Another common assumption is that an AI-ready customer profile must always be real time, but in practice, the required freshness depends on the application.
A weekly customer health report may work perfectly well with daily updates. A sales planning assistant may not need second-by-second information. A strategic account overview can tolerate some delay if the underlying data is accurate and complete.
Other applications have different requirements.
To give some examples, a customer care assistant may need to know about a critical ticket opened a few minutes ago, a churn intervention workflow may need to react quickly to a cancellation signal, or a consent revocation may also need to propagate quickly if it changes what an AI application is allowed to use.
For this reason, asking whether customer data is "real time" is often too simplistic.
A more useful question is to look at the whole chain.
How quickly do events arrive?
How quickly is identity resolution updated?
How quickly do the AI-facing views reflect those changes?
An event may reach the warehouse in seconds while the unified profile is recalculated every six hours. In that case, the AI application does not have a real-time customer profile.
The opposite can happen too. The profile may update quickly, but the application may still be using a stale cache.
Freshness is therefore not a single property of the architecture. It is a property of the entire path from source data to the application.
What to check before you build
Before choosing a platform or designing integrations, it is useful to ask a few practical questions.
Where do the unified profiles live? Can the company query, audit, and govern them, or do they exist only inside a vendor platform?
What are the atomic identities behind each profile? Can the system show which email addresses, user IDs, anonymous IDs, CRM IDs, billing IDs, support IDs, account IDs, and other identifiers contributed to the profile?
Why were those identities linked? Are the rules visible? Are matches deterministic, probabilistic, or manually approved? Can disputed matches be reviewed?
Can profiles be rebuilt? If identity rules change, can the company reprocess the underlying data without losing history?
Is consent part of the model? Can the company control not only which data exists, but which data can be used for a particular AI purpose?
Finally, are there different views for different AI applications, with the appropriate level of freshness and access for each one?
These questions are not just about choosing a CDP. They are questions about whether the customer representation itself can be relied upon once AI begins using it operationally.
The CDP cannot remain only an activation Layer
This brings us back to the role of the CDP.
Traditional CDPs continue to solve an important problem. They can collect events, unify profiles, create segments, and activate audiences across different tools. For many marketing use cases, these capabilities remain useful.
But AI introduces a broader requirement.
If a CDP is going to provide the customer context used by AI applications, it needs to support more than collecting data and pushing audiences to destinations.
It needs to preserve the relationship between identities and source data, make identity resolution explainable, incorporate consent and purpose-based access, provide governable customer profiles, and support different views for different applications.
This is a different expectation from the one many companies historically had for a CDP.
The question is no longer only where customer data should be activated. It is also how that data should be represented before an AI application uses it.
The Profile is a Product
There is another useful way to think about this: the customer profile should be treated as a product in its own right.
Not simply as a side effect of integrations, a collection of dashboard fields, or a marketing audience.
A customer profile that will be consumed by AI needs ownership, quality standards, documentation, access rules, monitoring, and a way to evolve over time.
Someone needs to decide which fields belong in the profile, which events can be trusted, what happens when two sources disagree, and which applications can access each view.
Someone also needs to define how freshness is measured, how errors are corrected, how consent changes propagate, and what happens to downstream AI applications when the profile logic changes.
Without this ownership, customer profiles tend to accumulate information over time without a clear model behind it. Fields become difficult to interpret, identity rules are forgotten, event meanings change, and views created for one use case are reused elsewhere without being reconsidered.
The architecture may still look clean in a diagram. The problems usually appear later, when the system is already in production.
The Data contract behind AI
Once the customer profile is designed this way, AI applications become easier to reason about.
A support assistant does not need to search blindly across every system. It can retrieve a support-specific customer view.
A sales copilot does not need to infer account health from scattered records. It can work from an account profile containing documented signals.
A personalization system does not need to determine for itself which customer fields it is allowed to use. It can receive a view that already incorporates consent and eligibility rules.
This does not remove the need for evaluation, security, prompt design, guardrails, or model monitoring.
It does, however, give those systems a more clearly defined input.
The AI application is no longer consuming "customer data" in the abstract. It is consuming a governed representation of a customer, built from known sources, with known identity relationships, known freshness, and defined limits.
That can be thought of as a data contract between the customer data foundation and the AI application.
The better that contract is defined, the less the AI application has to reconstruct for itself.
Whatk kind of CDP can support this?
An AI-ready customer profile is not something that can simply be added as another feature to a fragmented customer data architecture.
It depends on how the underlying data is collected, connected, governed, and exposed.
The implementation can take different forms. Some organizations may build these capabilities directly around their warehouse or lakehouse. Others may use a CDP or combine data infrastructure with dedicated identity-resolution and governance services.
The technology is less important than the architectural properties.
Customer data should remain accessible. Identities should be explainable. Profiles should be rebuildable. Consent should influence what AI can access. And applications should receive controlled views rather than an undifferentiated collection of everything the company knows about a customer.
These are the characteristics that make a customer profile useful as part of an AI architecture.
The next question, then, is what kind of CDP can actually support this model.
If a CDP was designed primarily around audiences, campaigns, and activation, the requirements of Customer AI may call for a broader approach to customer data.
What comes next
This is the second part of a three-part series on Customer AI and the customer profile behind it.
In the next article, we will take the next step: looking at why the traditional CDP model, built largely around campaigns and activation, starts to show its limits when the customer profile becomes a foundation for AI.
The CDP was built for Campaigns. AI needs Customer Memory.
The article is currently in preparation. If this topic is relevant to your work, stay tuned for the next part.