Explainable AI for Customer Decisions: Reason Codes, Model Lineage, and What Auditors Ask

Explainable AI for marketing and customer decisions means being able to show, for any individual decision, which inputs, model version and policy produced it, in terms the affected person, a reviewer and a regulator can follow, whether it comes from a customer data platform (CDP), a model or an agent. In practice that is reason codes, feature attributions, versioned policy snapshots and an audit trail keyed to a decision ID.

Who this is for: DPOs, model-risk and compliance teams, and architects who need to decide how much explainability each type of customer decision requires. You will get what regulators and auditors actually ask, the main techniques, an audit-trail design, a decision-type table and a checklist. Part of the AI hub.

What regulators and auditors actually ask

Few auditors ask whether a system is explainable in the abstract. They ask five concrete questions about a sample of decisions:

1. What was decided, about whom, and when?
2. Which data, model version and policy produced it?
3. What were the main factors, in terms a person can understand?
4. Who or what approved it, and could anyone override it?
5. Can you reproduce it, and show that consent and the legal basis were in place?

The legal sources below translate those questions into duties.

GDPR Article 22 and the right to meaningful information

Article 22(1) gives people the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significantly affects them. Exceptions exist for contract necessity, authorizing law and explicit consent, and in the contract and consent cases the controller must provide at least human intervention, a chance to express a view and a way to contest the decision. Special-category data is restricted further 1. Article 15(1)(h) adds that an access request covers the existence of such decision-making and meaningful information about the logic involved and its significance and consequences 2; Recital 71 refers to a right to obtain an explanation of the decision reached 3.

Courts have made this concrete:

• C-634/21 SCHUFA (7 December 2023). The automated creation of a credit score is itself an automated individual decision when a third party, such as a bank, draws strongly on it to decide on a contract 4.
• C-203/22 Dun & Bradstreet Austria (27 February 2025). The controller must explain the procedure and principles actually applied to reach the specific result, in a concise, transparent, intelligible and accessible form. Communicating a complex formula or algorithm is not enough, and complexity is no excuse. Where a controller invokes trade secrets, the information goes to the supervisory authority or court, which balances the interests case by case 56.
• Uber (Dutch DPA, announced August 2026). A fine of EUR 824,990,000 for unlawful automated decision-making and insufficient information on profiling, concerning automatic deactivation of driver accounts between 2018 and 2022. The EDPB's notice records that Uber has appealed 7.

Ordinary segmentation reviewed by staff usually sits outside Article 22. Credit, pricing, eligibility, account restrictions and fraud-driven suspensions can sit inside it. Settle the classification with your DPO before launch.

EU AI Act: logging, human oversight and explanation

Marketing segmentation and personalization are not high-risk per se. The Act's Annex III lists creditworthiness and credit scoring (excluding fraud detection), risk assessment and pricing for life and health insurance, eligibility for essential public benefits, employment, and emotion recognition 11. Regulation (EU) 2026/1744, in force since 27 July 2026, set the application date for Annex III high-risk obligations at 2 December 2027 12. For those systems:

See the EU AI Act guide for marketing and customer decisioning.

US credit decisions: ECOA, Regulation B and FCRA

For credit, Regulation B requires an adverse action notice with either the specific reasons or the right to request them. The reasons must be specific, indicate the principal reasons, and "relate to and accurately describe the factors actually considered or scored"; stating that internal policies were applied is insufficient, and more than four reasons is unlikely to help the applicant 18. The Fair Credit Reporting Act adds notice duties when a consumer report contributed, including the credit score used and details of the reporting agency, plus rights to a free report and to dispute 19.

Explainability techniques and what each one gives you

NIST's report on explainable AI sets four principles: a system should deliver evidence or reasons for outputs (explanation), in terms the intended consumer can understand (meaningful), that correctly reflect how the output was produced (explanation accuracy), and it should operate only within the conditions it was designed for (knowledge limits) 24. Three practical consequences follow.

• Generate explanations from logged reasons, not from narration. A language model that writes a plausible rationale after the fact is not an explanation unless it is built from the recorded reason codes or attributions. Accuracy is the principle most often lost.
• Write for the audience. A customer, reviewer, data scientist and regulator need different explanations; the ICO's guidance is organized the same way 10.
• Record knowledge limits. Log when an input is outside the training range or confidence is low and route the case to a person.

Our editorial position: prefer simpler, interpretable models for decisions with legal effects, and add attributions rather than depend on them.

Audit trail design for customer decisions

Give every decision an ID at the moment it is made and carry it through every downstream message and action. The record should hold:

Four design rules matter more than the field list. Make the ledger append-only and tamper-evident (hash-chained or write-once). Keep personal data out of it, holding references to a protected store, so erasure does not break the chain. Make decisions replayable: the same inputs, model version and policy version give the same outcome. Set retention to the longest applicable rule; the AI Act sets a six-month floor for high-risk logs, and sector rules may require more. PrivyCDP's AI operational layer records every AI-assisted action in an append-only audit ledger; map your required decision fields to it during design. Agent-specific fields are covered in running AI agents on customer data.

Mapping decision types to explainability levels

Levels used here: L1 decision log (ID, inputs hash, model and policy version, outcome); L2 L1 plus ranked reason codes; L3 L2 plus attributions, a reviewer workflow with override authority, and an explanation available on request; L4 L3 plus validation evidence, a formal notice and explanation procedure, fairness testing, retention rules and a regulator-ready pack.

For how decisions are computed in real time, see real-time decisioning.

A checklist for explainable customer decisions

1. Inventory customer decisions and classify each by effect: informational, commercial, or legal or similarly significant.
2. Set an explainability level per decision type, signed off by the DPO.
3. Assign a decision ID at the point of decision and propagate it downstream.
4. Log inputs hash, model version and hash, policy version and outcome for every decision.
5. Produce reason codes from the model or rules, with a versioned catalogue mapping codes to customer language.
6. Add attributions for complex models and test their stability; document the background data.
7. Define human review: who, with what information, with authority to override; log overrides.
8. Record consent, legal basis and suppression state at decision time.
9. Keep a model card and validation evidence for every version.
10. Make the ledger append-only, separate personal data from it, and test replay.
11. Set retention to the longest applicable rule, at least six months for high-risk logs.
12. Prepare response procedures for access requests, adverse-action notices and AI Act explanation requests, and test each with a sample decision.
13. Monitor drift and fairness, with triggers for re-validation.
14. Audit yourself: pick 20 decisions at random and reconstruct each end to end.

---

If you want to test how your decision fields map to an append-only audit ledger, the PrivyCDP team can run a ledger mapping session against your highest-risk decision types, starting from your security and deployment requirements. More guidance is in the AI hub and the AI governance policy template.