Data privacy and security

Plain language meaning

Data privacy and security explain how banks protect customer, account, transaction, credit, fraud, AML, sanctions and employee data when AI models, feature stores, prompts, logs, vendors and analytics platforms consume sensitive information.

This topic is about privacy and security controls around banking AI. It is not about using more data because the model might improve or masking data only after sensitive information has already leaked into logs or prompts.

In a real bank, this topic cannot be handled as a loose data-science or technology idea. It affects customer outcomes, fraud and AML control, operational queues, service continuity, privacy, security, model governance, audit replay, management reporting and regulatory confidence. AI should improve speed and quality, but the bank must still prove source data, permitted use, approved logic, human accountability, fallback handling and retained evidence.

Where it sits in the banking AI journey

This card belongs to AI Data and Model Operations. The working flow is Sensitive data, Permitted purpose, Protected processing, Controlled AI use, and Audit and review.

Read the flow as a bank operating model. Each stage needs a source system, a data owner, a timing rule, a quality gate, a model or rule boundary, an exception path, a customer-impact view, a fallback option, a monitoring requirement and a retained record. That is what separates useful AI adoption from uncontrolled automation.

Banking data and evidence

The important data points are personal data, account number, transaction narrative, KYC document, device signal, fraud case, prompt content, and access log. These items matter because they can influence risk scoring, operational repair, fraud action, AML triage, customer treatment, reporting, model monitoring and management decisions.

The evidence pack should include privacy assessment, data inventory, masking test, access certification, vendor due diligence, security monitoring, and incident record. A strong bank can replay the journey from source data to transformed input, AI output, rule result, human action, system outcome and monitoring result. A weak bank only knows that a process ran and hopes the process was right.

Controls that make AI adoption safe

The core controls are purpose limitation, data minimisation, tokenisation, encryption, role-based access, vendor control, and privacy review. These controls keep the topic anchored to banking purpose, approved policy, data governance, model-risk expectations, operational resilience, customer fairness, privacy, security and auditability.

The practical design should define what AI may recommend, what it must never decide alone, which deterministic rule remains authoritative, who owns thresholds and overrides, how degraded service is handled, how customer harm is detected and what evidence is retained. Without that control design, faster AI can simply make weak processes fail faster.

Architecture and data-operation lens

Banking AI depends on the architecture around it. Storage, streams, feature definitions, training sets, model versions, thresholds, feedback labels and rollback paths must be governed before the bank relies on AI output. The model is only one part of the control chain.

A bank-grade design connects channels, source systems, core records, payment hubs where relevant, fraud systems, AML platforms, case tools, data platforms, feature stores, model-serving endpoints, policy engines, audit logs and management dashboards. It also records degraded operation, recovery actions and lessons learned.

Regulatory and governance lens

Federal Reserve SR 26-2, dated 17 April 2026, gives revised model-risk guidance for traditional models and non-generative AI models used by banking organisations, including development, validation, monitoring, change control and governance.

The Federal Reserve's 2026 model-risk guidance states that generative and agentic AI are outside that guidance, while broader bank risk-management and governance practices still need to control tools and processes not covered by the guidance.

NIST AI RMF 1.0 uses Govern, Map, Measure and Manage functions for AI risk management, and NIST AI 600-1 adds generative-AI risk actions for source grounding, content provenance, data protection, cybersecurity and human oversight.

FFIEC Architecture, Infrastructure and Operations guidance expects financial-institution technology environments to be governed, resilient, secure, monitored, documented and aligned to business risk, including emerging technologies such as artificial intelligence and machine learning.

BCBS 239 remains current for effective risk data aggregation and risk reporting, and the Basel Committee's January 2026 newsletter reiterates the importance of accurate, comprehensive and timely data capabilities in banks.

FFIEC BSA/AML examination guidance expects suspicious activity monitoring systems and supporting technology to be risk-based, explainable by management, independently tested where appropriate and aligned to the bank's risk profile.

FinCEN's 12 June 2026 Section 314(b) materials clarify information sharing for possible terrorist activity, money laundering and fraud-related specified unlawful activity within the statutory safe-harbor framework for participating financial institutions.

OFAC's Framework for Compliance Commitments describes sanctions compliance programme components including management commitment, risk assessment, internal controls, testing and auditing, and training.

Diagram walkthrough

Read the diagram from left to right as Sensitive data, Permitted purpose, Protected processing, Controlled AI use, and Audit and review. It is a banking control map. The point is to show how data, AI or ML output, rules, human action, operational routing and audit evidence should connect.

Use it as a 30-minute study method. For each box, ask which system creates the data, which definition is used, which model or rule acts, what can go wrong, who can override it, how a fallback works, which customer or regulatory impact exists and what record proves the final state.

Most important mistake to avoid

The common failure is treating privacy as a legal review after the build. In banking AI, privacy and security must be designed into data selection, feature design, prompt handling, logging, access, vendor use and retention from the beginning.

The correction is disciplined scope. Keep the chapter anchored to banking purpose, prove the data path, make ownership visible, test failure behaviour, record the evidence and make the final outcome explainable without relying on memory, assumptions or developer-only knowledge.

Minimum data for a model decision

A lending model may need verified income, existing obligations and repayment history. It does not follow that every engineer, analyst or downstream dashboard should see the customer's full documents. The bank should document the approved purpose and lawful basis for each input, restrict access by role, minimise copies and set retention and deletion rules with counsel. A pseudonymous training identifier reduces casual exposure but is not the same as anonymity if the bank can reconnect it to a person.

Consider a feature service returning a debt-burden ratio. The model consumer may need the ratio, timestamp, quality status and source version rather than the raw salary statement. A reviewer investigating a disputed decision may need controlled access to the underlying evidence. Logs should avoid unnecessary personal values while retaining enough identifiers to reconstruct the action. Encryption, service authentication and least-privilege permissions address different attack paths; none repairs an inaccurate field or an unapproved use.

A useful test attempts to query features as an unauthorised role, exports a training extract, rotates an access key and processes a customer correction. Check that the decision remains auditable while access to raw data is limited. Third-party processors and cross-border transfers require jurisdiction-specific review, not a blanket claim that one architecture is compliant everywhere. The NIST AI RMF provides voluntary governance context; privacy and banking obligations must be mapped to the actual bank, country, data and use case.

AI expands the path of sensitive data

Banking AI can combine account transactions, identity records, credit data, payment narratives, case notes and employee prompts. Each source may already have controls, yet copying it into a feature store, training extract, model vendor, vector index or observability log creates new access and retention paths. Privacy and security design begins by mapping these paths for the actual use case, then deciding which data is needed, who may use it, how long it remains and how a failure is detected.

A fraud model may need a recent-payment count without a full narrative of every transfer. A credit model may use verified income and obligations under an approved purpose without exposing raw statements to all model developers. An internal policy assistant may need approved policy text but no customer data in its general prompt. Data minimization should be tested against model utility and decision evidence, not treated as a slogan. NIST's AI RMF playbook includes data management and privacy controls among AI risk management actions.

Privacy requirements differ by jurisdiction, product and processing purpose. Automated decisions and profiling may have specific obligations. The bank's legal and privacy teams should determine the applicable basis, notices, rights and review processes; a generic course cannot substitute for that assessment. The European Data Protection Board's guidance on automated decision-making and profiling is a useful primary reference for GDPR contexts. Do not imply that every AI-assisted decision is governed identically.

Inventory the data flow

Create a use-case map: source system, fields, purpose, transformation, destination, model or vendor, decision output, retained evidence and deletion or correction path. Include development, validation, production, logging, backup and incident environments. A raw customer record copied into a debugging topic can be more exposed than the tightly governed source. A training notebook export may persist after the model is retired. A vector index may contain sensitive document chunks even if it is described as "embeddings."

Classify identifiers and linkability. Replacing a name with a stable token does not automatically anonymize a record; the token may be linked across payments or resolved by a separate table. Account activity, device patterns and rare combinations can identify people indirectly. Restrict crosswalk access and consider whether aggregate or coarser features achieve the purpose. Document residual reidentification risk when sharing datasets.

Record data provenance and permitted uses. A field gathered for one service may not be appropriate for a new model merely because it is technically accessible. Third-party bureau, payment network or vendor data may have contractual restrictions. A model inventory should link each feature to its source, purpose review and approval. A new use case or vendor can require a new assessment even when the underlying table already exists.

Minimize at each stage

At ingestion, collect only the fields needed for the approved use and required evidence. At feature engineering, prefer derived values when they preserve the relevant signal without distributing raw detail. At serving, send the model a controlled vector and validity flags. At logging, store protected references or masked values where a full payload is unnecessary. At retention, remove temporary extracts and respect applicable schedules.

Minimization is not equivalent to discarding all evidence. A bank may need to explain a past credit decision or identify customers affected by a defective feature. Preserve a controlled decision snapshot or reproducible reference for the necessary period, with separate access from routine engineering telemetry. Define what investigators can retrieve and test the route. An immutable log with complete raw customer documents for every user is not a balanced solution.

For generative AI, avoid placing customer account numbers or full case files into a general assistant prompt when a narrower task or redacted excerpt will do. Retrieval permissions should be enforced before passages reach the model, not merely in the user interface afterward. Generated drafts can repeat sensitive content, and the response itself needs access, review and retention controls.

Access control

Separate roles: source operators, feature engineers, model developers, validators, case investigators, compliance reviewers and customer-service staff need different views. A fraud analyst may see case-linked transactions; a platform engineer may need latency and error status without raw payment narratives. Use service identities for automated paths and audit privileged access. Review permissions after team moves and vendor changes.

Apply authorization to derived stores, backups, dead-letter queues and test environments. A restricted source database offers little protection if its full contents are copied into a broadly readable data lake. Tokenization crosswalks deserve tight control. A vector search endpoint should filter results by the requester's authority and document classification; a prompt instruction to "ignore unauthorized text" is not an access boundary.

Test access with real scenarios. Can a developer retrieve a customer's raw credit application through model traces? Can one branch employee query another region's case notes? Can a vendor support account download a training extract? Deny paths that do not serve a legitimate purpose and log authorized exceptions. Periodically sample access records rather than assuming policy configuration is enough.

Security of the model path

Protect data in transit and at rest, manage encryption keys and rotate credentials. Authenticate model and feature service calls. Validate payload types, lengths and origins. Rate limiting and bounded retries protect availability; they also reduce abuse of expensive model APIs. A compromised producer can poison features even if the model server is hardened. Reconcile source events to authoritative banking systems and monitor unusual publisher behavior.

Training data poisoning can involve incorrect labels, forged events or altered reference mappings. Track dataset provenance, source quality, correction history and approvals. Validate unusual clusters and changes around migrations. A model artifact should be signed or otherwise controlled in the deployment process so an unapproved version cannot quietly replace the validated one. Record the artifact actually used for each decision.

Prompt injection is a distinct issue for assistants. An external email, payment narrative or retrieved document may contain instructions to reveal data or disregard policy. Treat such text as untrusted data. Keep system and tool permissions outside the retrieved content, restrict tool actions, and require review for consequential outputs. Test adversarial passages and preserve source-linked traces under appropriate access controls.

Vendors and external services

Before sending banking data to a model vendor, identify exactly what is transmitted, where it is processed, who can access it, how long it is retained and whether it can be used to train other systems. Assess contractual controls, incident notification, subcontractors and the ability to obtain decision evidence. A vendor's generic security page does not establish that the bank's specific data flow is approved.

Use scoped credentials and data minimization at the interface. A document classifier may need a redacted excerpt, not the entire case history. A serving vendor may need derived features, not account identifiers. Test failure and fallback if the vendor becomes unavailable or changes a response schema. Preserve enough local evidence to investigate a disputed result within the bank's retention and privacy rules.

If data crosses organizational or jurisdictional boundaries, the bank's legal and privacy review should determine applicable requirements. The course should not assert that a particular transfer mechanism is universally sufficient. Version the approved data flow and reassess it when the vendor, model, location or purpose changes.

Training and evaluation privacy

Development datasets often accumulate broad historical records. Define a representative cohort and remove unnecessary fields. Use controlled environments, export restrictions and documented retention. De-identification may reduce risk but should be evaluated for linkability and utility. Synthetic data can help test a pipeline, but it can fail to represent rare banking patterns and should be checked for leakage of source records.

Model evaluation may require sensitive attributes to measure disparate effects, subject to legal and privacy governance. Restrict those attributes to authorized analysis; do not simply avoid measurement because the serving model does not use them. Fairness testing can use protected, aggregated reports with appropriate thresholds and suppression for small groups. Explain what cannot be measured due to missing or restricted data.

Membership inference and model memorization are concerns for some settings, especially generative models trained or fine-tuned on sensitive text. Avoid using raw customer narratives for fine-tuning without a clear approved purpose and risk assessment. Test whether outputs reveal training examples or personal information. Limit prompt and output logging to what monitoring and evidence genuinely require.

Decision transparency and human review

The bank should distinguish a model recommendation from the final action. A fraud score may lead to a hold under a policy rule; a credit score may lead to underwriter referral; an assistant draft may be edited before use. The decision record should identify the actual policy and human roles. This matters for explaining and contesting decisions, as well as for privacy governance around automated processing.

Human review must be meaningful in the actual workflow. A reviewer who automatically clicks approve without access to relevant evidence does not provide a substantive check. Define authority, training, evidence and override logging. A customer correction should reach source data, cached features and affected decisions through a controlled process. Preserve the original record as required and mark the corrected assessment separately.

Not every model output needs the same explanation. A low-risk internal forecast and a consequential individual credit decision differ. Decide what can be explained in terms a customer or reviewer can use: data categories, decisive policy steps, correction route and outcome. Do not claim a generated narrative is a faithful model explanation unless it is validated against the actual decision path.

Incident response

An AI data incident may be a breach, a wrong customer link, a stale feature, an overbroad retrieval permission or an exposed prompt log. Contain the path, preserve evidence, identify affected records and decisions, and involve security, privacy, legal and business owners according to the bank's process. A model may remain technically available while its data is untrustworthy; invoke the approved limited mode where necessary.

Reverse lineage helps determine which model requests used a defective or exposed source. Separate exposure population, changed features, changed actions and confirmed customer harm. A broad time window can overstate impact, while a narrow query based only on successful model calls can omit fallbacks and rejected requests. Preserve both source and decision evidence under controlled access.

After remediation, verify deletion or restriction in every relevant copy: feature cache, training extract, analytics table, vector index, backup and vendor system as applicable. Some archives may be governed by legal holds or retention obligations; the privacy team should direct the precise handling. A fixed source table alone does not mean the copied data has disappeared.

Worked payment case

A fraud model uses a customer's recent transfer count and whether a beneficiary is newly added. The raw stream contains account numbers, names, references and amounts. A processor computes controlled features keyed by a token, and the model service receives only necessary values and validity flags. The payment hub and decision journal retain protected links for authorized investigation. Routine latency dashboards show status and timing, not full narratives.

A debugging change accidentally begins logging all feature requests with raw payer and payee identifiers. The security team restricts the log sink, rotates any exposed credentials if needed and determines who accessed the records. Privacy and business owners assess the affected population and obligations. The engineering fix removes unnecessary payloads, but the incident review also checks retention, backups and vendor exports. The model's predictive accuracy is irrelevant to whether the data flow was appropriate.

Worked assistant case

An internal compliance assistant retrieves approved policy passages. Its index includes access labels and document versions. A user asks a general question; the assistant should see only authorized policy text and cite its source. If a restricted case note is accidentally indexed, retrieval controls should prevent exposure. If the note contains an instruction to reveal unrelated data, the model should treat it as untrusted content. A human reviewer checks consequential outputs.

Testing includes a user without case permission, a superseded policy, a malicious retrieved passage and a prompt containing a customer number. Inspect what was retrieved, sent to the model, generated and logged. The assessment should confirm both authorization and content handling. A response that happened not to reveal data in one test does not prove the retrieval permission design is sound.

Governance exercise

Take one AI use case and draw every copy of customer data from source to deletion. For each copy, state purpose, owner, access roles, encryption, retention, correction path, vendor involvement and decision evidence. Then remove a source field from the permitted input and observe whether the system fails safely or silently imputes it. Test a customer correction and an unauthorized retrieval attempt.

Review the results with business, model, security, privacy and legal owners. The design is credible when the bank can use the minimum appropriate data, prevent unauthorized access, explain actual AI-assisted decisions and correct affected outcomes without losing essential evidence.

Primary reading: NIST AI RMF Playbook and EDPB guidance on automated decision-making and profiling.

Threat model the data journey

List the assets that an attacker or mistaken employee could misuse: source records, identity crosswalk, feature vectors, model artifacts, prompts, retrieved passages, generated responses and decision logs. Identify entry points such as message producers, APIs, notebooks, vendor integrations and support accounts. Ask what would happen if each were read, altered or made unavailable. The resulting controls differ. Reading a feature table may expose customer behavior; altering it may change fraud holds; taking it offline may force a high-volume fallback.

For a payment model, an attacker who can write forged events to a stream may raise or lower velocity. Producer authentication, event signatures where appropriate, source reconciliation and anomaly detection help. An attacker who can read the decision journal may learn sensitive payment relationships. Role-based access and access review help. A denial of service against the feature store invokes the approved operating mode. Model security is not confined to the model endpoint.

For a credit pipeline, a corrupted bureau mapping or training label can affect many decisions without a server breach. Validate external responses, monitor source distributions and preserve provenance. Restrict who can approve a dataset and deploy a model artifact. An internal employee with broad notebook access can accidentally export more customer data than a compromised public API. Include both malicious and accidental paths in the threat model.

For an assistant, distinguish the user's authorized instruction from untrusted retrieved content. A malicious paragraph can request disclosure or tool action; a compromised index can make it appear authoritative. Retrieval authorization, source approval, constrained tool permissions and human checks on consequential outputs form layers. A simple instruction to the model to ignore attacks is not a substitute for technical boundaries.

Evaluate privacy effects in context

Data combinations can reveal more than individual fields. Frequent small transfers, device location and account relationships may expose personal behavior even if names are masked. Before combining sources, ask whether the decision needs the joint detail and whether a coarser or shorter-lived feature would suffice. Test utility on representative data and document what performance is lost or gained. A bank should not assume that maximum data collection always yields a better or fairer model.

Group effects matter too. A feature may be systematically missing for customers who use branches, lack recent digital activity or have thin credit histories. A model can treat missingness as risk and produce unequal referrals. Privacy restrictions can also cause selective missingness. Evaluate those segments and design a fair, lawful fallback or alternative evidence path. Do not fill a missing source with a value that hides the disparity.

An explanation can reveal information about others. A network-risk model may use counterparties or shared devices; a customer-facing reason should not expose another person's confidential account or investigation. Design explanations at the appropriate level while preserving a protected detailed record for authorized review. The final action and correction route should remain understandable.

Lifecycle of a training extract

Before extraction, approve the cohort, fields, purpose and environment. Generate a dataset version with source manifest and quality checks. Restrict access and exports; record who used it and which model artifacts it produced. During development, avoid embedding raw customer examples in code, tickets or prompts. In validation, provide reviewers with the evidence they need through a governed view. At retirement, follow the retention schedule for the extract, backups and model artifacts.

Corrections create a versioning question. If a customer attribute used in training is later rectified, the bank should know which dataset and model used the earlier value. Applicable rules and materiality determine whether to retrain, remove a record or document a limitation. A model's weights are not a simple database row, so the governance procedure must be practical and evidence based. Avoid promising instant removal from every artifact without a tested method.

Test for memorization where relevant. Ask whether a generative model can reproduce sensitive source text, or whether a small rare cohort can be inferred from outputs. Privacy-preserving training methods may reduce risk but can affect utility and do not excuse poor source governance. The risk assessment should cover the actual model, data and access pattern.

Logging and observability

Decide what a production trace needs to diagnose latency and errors: request ID, model and feature versions, validity status, timing, policy outcome and a protected source reference may suffice. Raw prompts, bureau attributes or full payment narratives should require a separate justification and restricted access. Apply masking consistently to success and error paths; exception handlers often log full payloads during failure.

Set a log retention period by purpose and obligation. Test whether archived records can be retrieved for a legitimate investigation and whether routine operators can see only the fields they need. Monitor unusual bulk queries and exports. A customer correction may require linking an updated view to a historical action; the audit record should remain intelligible under authorized access.

An observability vendor can be an external data recipient. Review which fields telemetry sends, where it is stored, who supports the account and how deletion or incident handling works. A masked dashboard does not prove the underlying trace payload is masked. Inspect actual network and log samples in a controlled test.

Model output as sensitive data

A fraud score, credit referral or AML case ranking can itself reveal sensitive inferences. Restrict access and use, and avoid exposing raw scores in public-facing APIs unless approved. A generated assistant response may include a customer's personal details even if the prompt did not explicitly ask for them, because retrieval supplied a broad passage. Test output filtering and human review against representative examples.

Model explanations and reason codes should be tied to the actual decision logic. A fabricated natural-language rationale can be misleading and may disclose unrelated data. Use validated explanations at the appropriate audience level. Record what was communicated to the customer separately from internal diagnostic detail. A later correction should address the real outcome, not merely edit the explanation text.

Vendor outage and exit

Privacy and security planning also includes availability. If a vendor model becomes unreachable, the bank needs an approved human, rule or pause path without copying data into an unapproved alternative service. An emergency integration can introduce new data transfers and weak evidence. Preapprove fallback destinations and the minimum fields they require. Test capacity and customer communication.

An exit plan should cover retrieval of bank-owned artifacts, deletion or return of data, continuity of case evidence and validation of a replacement model. A new vendor's similar API does not imply equivalent data handling or decision behavior. Assess migration of prompts, feature definitions, embeddings and logs, and retain historical decision evidence within applicable constraints.

Privacy review exercise

Choose a credit application that used account cash-flow and bureau data. List every system receiving the raw records, derived features, score, reason and final action. For each recipient, specify purpose, authorized roles, retention and correction mechanism. Now simulate a wrong customer-account link. Identify the applications that used it, prevent future use, calculate corrected features, review final decisions and handle affected customers through the approved process.

Next, simulate a support engineer enabling verbose logging during the incident. Inspect exactly which fields entered logs and any external telemetry. Restrict access and determine whether the logs need removal, retention under incident hold or another controlled treatment. Record who made that decision. A model can be accurate while its operational data handling fails; the exercise tests both dimensions.

Finally, have an independent reviewer verify the bank's claims from actual sample records and permissions. The reviewer should be able to trace why the data was used, who saw it, what the AI produced, who acted and how correction flowed through copies. That evidence makes privacy and security controls part of the real AI lifecycle rather than a separate policy document.

A permission test matrix

Construct a small test matrix with five roles and four assets. A model developer may see de-identified training features but should not automatically see the identity crosswalk or raw case notes. A fraud investigator may access a specific authorized case and source evidence but not export all customers' features. A platform operator may see service errors and trace IDs without unrestricted customer narratives. A privacy reviewer may inspect access logs and a controlled sample. A vendor support identity should have only contracted access for a bounded period.

For each role and asset, attempt a legitimate and an illegitimate action in a safe test environment. Verify both the technical result and the audit record. Then test a group membership change, expired temporary permission and emergency access. The review should include indirect paths: notebook copies, backup snapshots, search indexes, dead-letter topics and telemetry dashboards. Denying access in the primary application is insufficient if the same information is available through a secondary store.

Repeat the matrix for an assistant with document classifications. A user entitled to general policy text should not retrieve restricted customer investigations. A citation should not point to a source the user cannot inspect under the intended workflow. If an authorized reviewer must see more detail, that should be a distinct role and recorded action. Test whether the model can reveal protected snippets through paraphrase even when a direct link is hidden.

Change trigger

Reassess the data flow when a new source is added, an existing field is repurposed, a vendor changes, a model starts producing a consequential recommendation, or the assistant gains a tool action. Also review after a privacy or security incident, a major source correction, or a new retention requirement. The assessment should compare actual payload samples and decision traces with the approved design. A signed architecture diagram from launch may no longer describe the live system.

Record the decision made at each review: permitted purpose and population, controls required, unresolved limitations, owner and next review point. Feed those constraints into code, access policies, monitoring and runbooks. Where a jurisdiction-specific obligation applies, the bank's responsible legal function should document it for that use case. This keeps the course's general architecture principles separate from legal conclusions that depend on context.

Access test across copied stores

A credit model uses derived cash-flow features. A developer can inspect de-identified training values, while an underwriter can see an authorized applicant's supporting records. Test whether either can obtain the identity crosswalk, raw bureau response, prompt logs or backup snapshot outside their role. A restricted source database is insufficient if a notebook export or observability vendor holds the same data broadly.

When an applicant corrects a mislinked account, update current features, identify prior decisions that used the link and preserve a controlled original decision record. Determine applicable retention and rights with the bank's privacy and legal owners. An authorized investigator should retrieve the evidence without granting routine engineers full customer history. This concrete review covers purpose, copying, access, correction and decision traceability. Repeat the access test against a vector index and verbose error log, because sensitive data can escape through secondary copies. Record which system owns deletion or restricted retention after a correction. An audit reviewer should obtain the original decision context without exposing unrelated customers' histories.