Outlook
Part of How to read the customer data platform outlook from dated UK evidence and buyer scenarios
Scoping AI tasks inside a customer data platform before anyone approves one
Scope CDP AI applications for one England data journey, with human authority, provenance, rights, security, accessibility and rollback controls.
Customer data platforms AI applications should begin as bounded buyer hypotheses. No product, model or account was supplied for this article, so it documents possible tasks rather than claiming present capability.
The buyer journey is an England membership record moving through an identity decision, correction and suppression state to an approved destination. CRM, warehouse or lake, identity resolution, preference management, tag or device access, analytics, activation, clean room and managed integration remain separate. Adding AI to one does not change the authority for another.
What to take away
- Start each AI task as a bounded buyer hypothesis, not an approved product or supplier feature.
- Keep decision authority with the human owner even when a model drafts, orders or flags output.
- Write a release card covering purpose, data, model version, evidence and rollback before testing.
- Test failure paths such as prompt injection, revoked access, suppression and rollback, not just the happy path.
- Pause the application when outputs lack traceable inputs or rollback cannot restore a known state.
Four candidate tasks, none approved
Documentation assistant: A model could draft a plain-language description of a source field or transformation. The human data steward compares every statement with the versioned schema and rejects unsupported text. The source record remains authoritative.
Four candidate AI tasks
Task
- Documentation assistant
- Draft field description
- Duplicate triage
- Order suspected duplicates
- Anomaly flagging
- Flag volume or field change
- Draft explanation
- Explain identity or audience rule
Human authority
- Documentation assistant
- Steward rejects unsupported text
- Duplicate triage
- Must not merge; owner records
- Anomaly flagging
- Prompt to investigate, not evidence
- Draft explanation
- Reviewer checks inputs and version
Duplicate triage: A model could order suspected duplicates for review. It must not merge them. The fixture includes similar people who must stay separate, a documented duplicate and conflicting attributes. The identity owner records the reason for each final decision.
Anomaly flagging: A model could flag a changed volume, missing field or failed suppression transfer. The output is a prompt to investigate, not evidence of an incident or causal diagnosis.
Draft explanation: A model could prepare an explanation of an identity or audience rule for a human reviewer. The reviewer needs the actual inputs, rule or model version, uncertainty and route for correction. Fluency is not accuracy.
These are buyer scenarios. They are not documented supplier features or 2027 predictions.
Use a release card for each task
Write down the purpose, permitted source fields, prohibited data, affected people, model and prompt version, output, acceptance evidence and decision authority. Include the manual baseline, error types, security owner, accessible alternative, retention, audit record and rollback version. Production action stays off during testing.
Release card contents
- Purpose and permitted source fields
- Prohibited data and affected people
- Model and prompt version
- Output and acceptance evidence
- Decision authority and manual baseline
- Security owner and accessible alternative
- Retention, audit record and rollback version
The ICO's AI and data protection risk toolkit offers questions about rights and freedoms, accuracy, fairness, transparency, security and minimisation. The ICO marks this material as under review because of the Data (Use and Access) Act. A named privacy and legal reviewer must therefore check the current law and updated guidance against the actual facts.
The ICO separately records that all DUAA data-protection provisions are now in force, while its final automated-decision guidance was still in its publication programme when checked. Do not describe an announced guidance update as current final guidance.
Test the failure, not just the happy path
The NCSC's AI secure-operation guidance covers behaviour monitoring, input monitoring and version-aware updates. For this journey, test fabricated but realistic records, contested fields, prompt injection in free text, a revoked privileged account, refusal of tracking, suppression, deletion and rollback.
Store enough evidence to investigate without copying unnecessary personal data into logs. Record who can see prompts, outputs and training-related information, where suppliers or subprocessors receive data, and how an export will be restored. The DSIT AI Cyber Security Code of Practice is voluntary guidance, not assurance that a configured service is secure.
Accessibility needs its own test. A reviewer should operate the task using the buyer's required keyboard, screen-reader and zoom journeys, including error recovery. Privacy, security or functional success cannot compensate for an inaccessible administrative control.
Stop conditions
Pause the application if its output lacks traceable inputs, two people are wrongly joined, a correction fails to propagate, suppression is reversed, the manual route disappears, an affected person cannot challenge a material result, access revocation fails or rollback cannot restore a known state. The owner then records containment, evidence and the condition for a controlled restart.
The next step is one release card and one fictional fixture. Until named reviewers approve the evidence, the task remains a proposal on publication hold.
Before you act
- Write a release card for each candidate task.
- Keep production action off during testing.
- Name a privacy and legal reviewer to check current law.
- Test fabricated records, contested fields and prompt injection.
- Check keyboard, screen-reader and zoom journeys for reviewers.
- Record stop conditions, containment and restart requirements.
Common questions
What four AI tasks does the article propose for a customer data platform?
It lists a documentation assistant, duplicate triage, anomaly flagging and draft explanation. Each is a buyer scenario, not a documented supplier feature or prediction. A model may draft, order or flag, but the human steward, identity owner or reviewer keeps decision authority and the source record stays authoritative.
What should a release card record for each AI task?
It should record the purpose, permitted source fields, prohibited data and affected people. It also covers the model and prompt version, output, acceptance evidence and decision authority. Further items include the manual baseline, error types, security owner, accessible alternative, retention, audit record and rollback version.
When should an AI application be paused?
Pause if output lacks traceable inputs, two people are wrongly joined, a correction fails to propagate, suppression is reversed or the manual route disappears. Also pause if an affected person cannot challenge a material result, access revocation fails or rollback cannot restore a known state. The owner records containment, evidence and restart conditions.
