The missing layer between data products and enterprise AI
A customer has submitted the information needed to open a bank account. Identity documents are valid. Screening has run. Customer data is available. Yet the KYC case remains open.
The operating question is simple: Why is this customer still not cleared?
The answer may sit across the customer record, identity documents, screening results, risk policy, workflow status and approvals. No single dataset is enough.
The problem is not access to data. It is the assembly of the right business context around the case.
That is the step-up from a data product to a context data product. Data products make trusted facts reusable. Context data products make a business situation reusable for AI and decision workflows.
At a glance
- Data products remain the foundation. They organise trusted data around an entity or domain.
- Context data products add the relationships, current state, rules, evidence and controls needed to understand a situation.
- The value appears when several AI workflows repeatedly reconstruct the same context.
- The goal is not another data platform. It is a reusable way to assemble context from existing data products and source systems.
Data products and context data products solve different reuse problems
A data product is designed around an entity or domain. In retail KYC, that entity may be the customer.
Its core question is: What do we reliably know?
It makes trusted facts reusable by adding agreed definitions, quality controls, ownership and standard methods of access. Those facts can support analytics, applications and AI systems.
A context data product is designed around a situation, task or decision. In retail KYC, that means the customer and the specific KYC case.
Its core question is: What is happening, and why?
It combines trusted facts with relationships, current state, applicable rules, evidence and controls. That assembled context can support AI assistants, agents and decision workflows.
The step-up is from a trusted entity to a trusted business situation.
Data products solved the first reuse problem
Data products addressed a familiar issue: teams should not repeatedly clean, reconcile and redefine the same business data.
A customer data product, for example, can provide a governed view of identity, profile, relationships and agreed definitions. It combines trusted attributes with quality controls, ownership and a standard way to consume the data.
Its core question is: “What do we reliably know about this customer?”
KYC exposes the next reuse problem
KYC is not only a customer-data question. It is a case question.
Assume the customer data product says that the customer is a UAE resident and a business owner. The document product shows valid identity documents. Screening returns a possible politically exposed person match. The workflow shows that compliance review is still pending.
The reason for the delay becomes visible only after these pieces are connected to the same KYC case.
The system must also know which policy applies, which check is outstanding and what the user is permitted to see or do.
A data product describes the entity. A context data product describes the situation around the entity.
Five building blocks of a KYC context data product
A practical KYC context data product has five building blocks. Each can be reused, but the underlying data does not necessarily have to be copied into a new store.
1. The anchor: The anchor defines the business situation being evaluated.
In this example, the anchor is not only the customer. It is the combination of the customer and the specific KYC case.
2. Trusted facts: These include identity, customer profile, submitted documents and risk information.
Where possible, they should come from governed data products or authoritative source systems rather than being recreated for each AI workflow.
3. Relationships and current state: The context must show how the facts connect and what is true now.
For a KYC case, this may include the relationship between the customer and submitted documents, the latest screening result, the approval status and the action that remains outstanding.
4. Applicable rules: The context must establish which policy, risk triggers and mandatory checks apply to the case.
These rules should not be left for the model to infer from a general collection of documents.
5. Evidence and controls: The assembled context should retain its sources, timestamps, permissions and approval requirements.
This makes the result traceable and helps ensure that the AI system remains within its authorised boundary.
The context product should assemble, not centralize
A context data product should not become another KYC database.
Some context can be prepared in advance. Other information should be retrieved from the authoritative system when the workflow runs.
Prepared context may include:
- Customer relationships
- Document metadata
- Policy indexes
- Stable reference data
Runtime context may include:
- The latest screening result
- The current case status
- The latest risk assessment
- An outstanding approval
The objective is reliable context assembly—not centralisation.
This distinction keeps the context layer smaller, fresher and easier to operate.
Why AI makes this step more important
An AI assistant can retrieve a KYC policy. That does not tell it why a particular customer is still pending.
It also needs the relevant customer facts, latest screening state, applicable rule, pending action and supporting evidence.
The same assembled context can support several workflows:
- Customer onboarding
- Periodic KYC refresh
- Compliance review
- Relationship-manager support
- Customer service
If each AI team reconstructs the same relationships, rules and controls, the enterprise has recreated the duplication that data products were intended to remove—only one layer higher.
Context data products extend the existing data-product model
The progression can be understood in five stages:
- Source systems record events and transactions.
- Governed data standardises facts, definitions and controls.
- Data products make trusted facts reusable.
- Context data products make business situations reusable.
- AI workflows use that context to reason, recommend or act.
Context data products depend on good data products. They do not replace them.
When is a context data product justified?
Not every AI workflow needs one. The useful test is repetition. A context data product becomes a reasonable investment when:
- Several workflows need the same cross-domain context.
- Different teams repeatedly rebuild the same relationships or policy logic.
- Current operational state must be combined with governed data.
- Evidence and access controls need to remain consistent across applications.
If one workflow needs the context, keep it local. If the same context keeps reappearing, productise the repeated part.
This helps avoid turning every AI use case into an enterprise platform initiative.
What technology leaders should take away
- Do not begin with an enterprise-wide context platform: Start with a small portfolio of priority AI workflows. Identify the business context that each workflow needs and look for genuine repetition.
- Keep trusted facts in existing data products: Do not duplicate customer, document or risk data merely to create an AI-ready layer. Reuse governed products and authoritative systems wherever possible.
- Productize only the repeated context: Relationships, applicable policies, live state, evidence and controls may justify reuse when multiple workflows need them in the same form.
- Make context ownership explicit: Someone must own how the context is assembled, how current it must be, which rules apply and which workflows are authorised to use it.
The enterprise AI question is therefore becoming broader than “Do we have the data?”
“The next question is whether the organisation can assemble the right context for the right situation, with the right evidence and controls.”
Data products make enterprise facts reusable. Context data products make those facts usable in a live business situation.
A practical starting point
Take two or three priority AI workflows.
Map the data products, source systems, applicable rules and live operational state that each workflow requires. Then identify the relationships, rules and controls that teams are repeatedly reconstructing.
That repeated context is the candidate for reuse.
