How to fix data quality issues in customer records with an AI agent

Mechanical fixes can run on their own; everything else is a proposal. At depth 3 the agent can standardise formats, correct invalid values and fill gaps from another system of record, keeping before and after values. Merging duplicates, changing names or dates of birth, and anything that relies on unverified information are held for a named data steward.

What is the process, and who owns it?

Customer records degrade: duplicates from separate onboarding channels, addresses that were never updated, names typed three ways, missing fields that rules require, phone numbers in the wrong format. Bad records cause failed payments, misdirected letters, wrong screening results and poor service. Data protection law adds a duty: GDPR Article 5, and the UK equivalent, require personal data to be accurate and kept up to date.

The data owner for customer data owns the rules: which fixes are allowed and from which sources. Data stewards in operations approve held fixes. The agent finds problems and applies approved, low-risk corrections. The broader question of how poor data affects agents themselves is covered in how do you handle data quality problems for AI agents?

What are the steps, and at what depth?

1. Person, data owner: writes the fix rules: which issues the agent may correct, from which sources, and which must be held.
2. Agent, depth 1: scans records for issues: duplicates, invalid formats, missing required fields, conflicts between systems, values failing reference checks.
3. Agent, depth 3: standardises formats: phone numbers, postcodes, capitalisation, date formats. The meaning does not change.
4. Agent, depth 3: fills gaps from a sealed source, such as a missing date of birth present in the core banking record, recording the source of the new value.
5. Agent, depth 2: proposes merges of likely duplicates, showing the evidence: matching identifiers, shared addresses, account history.
6. Agent, depth 2: proposes changes to identity data such as names and dates of birth, with the source and any supporting document.
7. Agent, depth 2: drafts customer contact where only the customer can confirm the right value, such as an out-of-date address.
8. Person, data steward: approves or rejects every held fix.
9. Person, data quality analyst: samples automatic fixes each week.

What stays with a person, and why?

Merges. Merging two records combines accounts, history and consents. Merging two different people with the same name is hard to undo and can expose one person's data to another.

Identity data. A name or date of birth change can affect screening, credit and fraud checks. It needs a source someone can stand behind.

Anything from unverified information. A new address mentioned in an email is declared or external information. It should prompt contact with the customer, not overwrite a record.

Sensitive flags. Deceased, vulnerability and fraud markers have consequences beyond data quality and belong to the teams that own them.

The same discipline applies to staff data; how to let an AI agent update employee records in your HRIS uses a similar split.

Which controls matter, and what evidence do they leave?

Before and after values. Every change stores the old value, the new value and the source. Evidence: a change record that allows exact reversal.

Source strength rules. A value from a weaker source never overwrites one from a stronger source. A customer's sealed ledger record is not replaced by an emailed form. Evidence: provenance on each change.

Held fixes with reasons. Evidence: approvals and rejections with the steward's name.

Throttled runs. Bulk fixes run in batches, with a pause to sample before the next. Evidence: batch logs and sample results.

Downstream notice. Systems fed from the customer record are told of significant changes. Evidence: notification logs.

What should you measure?

• Issues found and fixed, by type.
• Fixes reversed after sampling or complaint.
• Held fixes by type and decision.
• Duplicate merges later split. The target is none.
• Downstream failures such as returned mail and failed payments, before and after.

Where does it usually go wrong?

Bulk fixes run unchecked. A rule that looked right on a sample changes thousands of records wrongly overnight. Run in batches and sample.

The agent trusts the newest value. Newer is not always better. A recent value from an external source should not beat an older sealed one.

Fuzzy matching merges strangers. Similar names at the same address may be relatives, not duplicates. Require more than one strong identifier.

Fixes are not visible. Staff see a changed record with no explanation and change it back. Show the source and reason on the record.

Consent and preference fields are treated as data. Marketing consents and contact preferences record a customer's choice. The agent should never fill or standardise them from other records; only the customer can set them.

Where Pryme fits

In Pryme, every value reaching the agent carries its provenance class, so a sealed value is never replaced by a declared or external one without a person's approval. Each fix is filed with its before and after values in an append-only record. The deployment path is set out in deploying an AI agent: train, shadow, certify, widen.