RePerspective Labs

INSIGHT

Deep Dive

Information Rights When AI Uses Context and Memory

Deciding what an AI service may remember and how changed permissions reach its uses and copies

Shashi Sethi

October 28, 2026

13 min

Executive summary

Persistent memory can help an AI service carry useful context between customer contacts. It also creates information that the organization must keep accurate, use for legitimate purposes, restrict when permissions change, and dispose of when no longer needed. Permission to retrieve a record does not settle those later responsibilities. Through a hypothetical insurer's complaint service, this Insight follows an incorrect summary and a subsequent withdrawal of representative authorization across context, memory, suppliers, outputs, and retained copies. The leadership decision is whether the value of continuity justifies a form of memory the organization can maintain, correct, and retire with evidence.

The question

What should the service remember between contacts

The appeal of persistent memory is continuity. Staff may spend less time reconstructing a case, and customers may have less to repeat. Those are benefits to test. They do not establish how much information should remain available, who may receive it, or how long it should be kept.

A summary can carry forward an error. An accurate account of yesterday's permission can be an unsafe basis for today's disclosure. Removing either from the source screen may leave copies in memory, retrieval material, a supplier request, or an unfinished draft.

The executive choice is whether to continue persistent memory after a pilot, narrow what it contains, or rebuild context from governed records at each contact. That choice includes the continuing work needed to change information use after it has begun.

My perspective

I would authorize persistent memory only where its contribution survives the cost of keeping it legitimate. The organization should be able to change what the service may use while preserving the records it must retain. That requires funded responsibilities and evidence from affected uses, including those outside its direct technical control.

Shashi Sethi

The approach

A complaint service with a continuing obligation

Consider a hypothetical FCA-authorized general insurer operating from England. A UK retail customer complains about a delay in handling a home-insurance claim. Assume the complaint falls within the applicable FCA complaints rules. The insurer is the controller of the personal information; an external commercial inference supplier acts as processor for submitted customer content under an appropriate agreement. Supplier training or improvement use is not authorized in this example. It excludes special-category information and automated final decisions about coverage or compensation. It assumes documented lawful bases for the specified processing purposes, without assuming that the customer's representative authorization supplies those bases.

The service is in a limited pilot. It may Recommend responses; an authorized complaint handler retains the decision and customer communication. The leadership question is whether to continue case-specific memory beyond that pilot. The proposed benefit is less repeated case assembly, not a measured result.

At the first contact, the governed authorization record permits a representative to handle this complaint. A generated summary incorrectly broadens that permission to all policy matters. The summary is retained in case memory and later included in a supplier request and a draft awaiting review. Separately, a handler has sent a complaint update after checking the actual authorization record.

At a later contact, the verified customer challenges the broad summary, withdraws the representative's complaint authorization, requests direct contact, and asks for unnecessary working copies to be removed. There are now two distinct issues: a summary that was wrong when created, and a permission that was valid within its original scope until withdrawn.

Follow each use beyond the source record

Four forms of information have different jobs. Approved knowledge explains applicable complaint policy. Authoritative business records establish case facts, recorded authorization, and completed business events. Assembled context is the selected material supplied for a particular task. Persistent memory retains information for a later task. A generated statement does not acquire business authority through repeated use.

The Enterprise Knowledge Backbone addresses whether knowledge is dependable and applicable. A further question follows even when it is: may this service use it for this purpose, with this recipient, for this duration? In the UK case, purpose limitation, minimization, accuracy, and storage limitation are legal principles, not settings supplied by a retrieval tool. [1]

The operating design below is illustrative. The paths branch, feed later work, and leave copies in different places.

Information use across an AI-enabled operation

Information use across an AI-enabled operationGoverned records and approved knowledge feed context. Context branches to memory, tools and an external supplier, and drafts. Memory feeds later context after source and permission checks. A human decision and current authorization from governed records are required before communication. Logs and copies arise across branches; corrections reach every affected use. Governed records Approved knowledge Assembled context for this task Persistent case memory Drafts and recommendations Approved tools and external supplier Human decision and current authorization Approved output or business record Recheck sources and permissions Approved request Results Review Current authorization from governed records Copies across branches Logs backups exports and supplier copies Separate purposes access and retention Correction or authorization change Apply to every affected use and retained copy; record unresolved exposure
Governed records and approved knowledgeCase facts, recorded authorization and applicable policy.
Assembled context for this taskSelected information, source references and qualifications.

Context can branch into these uses:

Persistent case memoryInformation justified for later case continuity. Feeds later context only after rechecking sources and permissions.
Approved tools and external supplierApproved request; returned results feed drafts and recommendations.
Drafts and recommendationsPrepared from context and returned results; awaiting review.
Human decision before communicationEstablish current authorization from governed records. Remembered prose does not supply it.
Approved output or business recordIssued or recorded only within the confirmed authority.
Copies can arise across every branchLogs, backups, exports and supplier copies have separate purposes, access and retention.
Correction or authorization changeApply to every affected use and retained copy. Owners verify completion and record unresolved exposure.
Figure 1. Information can branch into memory, tools, supplier processing, and outputs. Memory feeds later context only after relevant source and permission checks. Logs and retained copies can arise across the operation; a correction or permission change must reach every affected use.

At the source boundary, the authorized handler and service identity need the complaint facts, relevant correspondence, applicable policy, and authorization scope and dates. They do not need an unrestricted customer file. Current authorization must be established from governed records at the point of use and checked again before disclosure. If it cannot be established, hold the disclosure and route the case to the designated handler.

Context assembly should preserve the source references and qualifications needed to understand the answer. Its local working copy can be discarded when the task ends. Sending it to a model, saving a draft, or writing it into memory creates separate copies with separate retention conditions; calling the original context transient does not make those copies transient.

For persistent memory, retain only information justified by continuity in this complaint. The Operating owner defines that use with the Data owner and privacy function; the Technology owner implements access, expiry, and correction. Remove working memory at case closure or earlier loss of need unless a specific preservation requirement applies. Current authorization should be obtained through a reference to the governed record, rather than entrusted to remembered prose. Retrieval indexes and caches must inherit the relevant purpose and access restrictions and be invalidated when their supporting information changes.

Tools and supplier requests need their own boundaries. A drafting supplier may need a relevant passage and case reference without needing unrelated correspondence or every identifier. The approved payload, processing locations, subprocessors, retention, and permitted reuse must match the actual arrangement. Operational inference, disclosure to the representative, and supplier use for training or improvement are different uses. One permission does not authorize all three.

Outputs remain drafts until an authorized person decides what may be issued or recorded. Before an AI Agent Acts explains the separate enforcement of action authority. AI Agents and Systems of Record addresses dependable business changes. Neither a plausible recommendation nor a stored memory supplies that authority.

Correct the error and apply the withdrawal separately

The incorrect summary requires a review beginning when it first entered use. Compare its claim with the original, narrower authorization. Find the drafts, recommendations, disclosures, and other summaries that relied on it. The already-sent complaint update may remain valid because the handler independently checked the governed record and stayed within its scope. Another output that used the broader claim requires examination even if it predates the customer's withdrawal.

The withdrawal has a different effective point. Update the governed authorization record and stop further disclosure to the representative on that basis. Cancel queued sends and invalidate in-flight work that assumes the former recipient remains authorized. Rebuild any continuing task with current information. Review disclosures from the withdrawal's effective time through the time each affected consumer actually applied it. Earlier, properly authorized disclosure does not become improper simply because authorization later ends.

Keep both timelines: what was true and permitted when, and when each system learned and enforced the change. Where the record of downstream use is incomplete, widen the review and state the uncertainty. Correct affected issued communications through the approved route, recording any exposure that cannot be reversed. Do not report an absence of evidence as proof that no affected output exists.

For this UK case, Article 16 provides a right to rectification of inaccurate personal data; contested accuracy can also engage restriction while it is verified under Article 18. [2] The operating response should keep the disputed summary out of further reliance while the appropriate functions resolve it.

On a narrow screen, scroll across the table to compare the two changes and completion evidence.

Two changes, separate responses
Affected placeCorrect the false summaryApply the later withdrawalOwner and completion evidence
Governed recordsPreserve the original scope; record the derived error and its correction.Record the end of authorization and current contact route.Data owner and custodian: verified scope, effective time, and versions.
Context and memoryReplace the false claim; remove unnecessary copies.Invalidate affected work; obtain current authorization from records.Technology owner: affected objects, execution checks, and later-use tests.
Indexes and cachesDelete or rebuild affected derived entries.Invalidate cached permission information.Technology owner: identified entries and checks in each consuming service.
Drafts and issued outputsReview reliance from the summary's first use.Cancel pending sends; review disclosures after withdrawal.Operating owner: reviewed outputs, recipients, delivery times, and remedies.
External supplierIdentify affected submissions; request the applicable correction, restriction, or deletion.Stop obsolete or unnecessary new submissions; assess ongoing processor use separately.Supplier management with Privacy and Technology: response, exceptions, dates, and unresolved exposure.
Logs and retained copiesLink corrections to accurate event history; remove redundant content where permitted.Restrict reuse; apply disposal schedules and justified preservation.Records management, Security, and Technology: disposition records and restoration checks.

Privacy coordinates the customer's rights response and required recipient notifications. Article 19 requires communication of qualifying rectification, erasure, or restriction to recipients, unless impossible or disproportionate, and information about those recipients if the individual requests it. [3] An acknowledgment from a recipient records a step; it does not establish that every downstream copy has been corrected or deleted.

Preserve the required record without preserving every use

The customer's request should produce a reasoned disposition of information, not a single deletion flag. Ending representative authorization does not itself end the insurer's separate basis for handling the complaint. Correcting the summary does not require rewriting the accurate history of what happened.

For the assumed complaint, FCA DISP 1.9.1R requires the complaint record and measures taken for its resolution to be retained for three years from receipt. [4] UK GDPR erasure rights have exceptions where processing is necessary for a legal obligation or legal claims. [5] These are bounded reasons to retain particular information, not a blanket instruction to keep every prompt, draft, or memory object.

Records management determines the schedule and disposal process with Legal on applicable obligations and holds. The Operating owner identifies the material needed for the complaint record. The Technology owner implements the distinction between that protected record and material available to the assistant. A record kept for an obligation should not automatically remain available for operational reuse. If a retention requirement changes, revise the schedule and affected copies without silently extending the permitted purpose.

Logs should capture the events needed to reconstruct use and change: case and execution references, source versions, recipients, approvals, and outcomes. Security and records specialists must define their purposes, access, and retention; preserving full prompts by default can create unnecessary copies.

Backups require an explicit disposition too. ICO guidance recognizes that, for a valid erasure request without an exemption, backup data may remain pending overwrite but must be put beyond use and handled under an established schedule. [6] Restoration should reapply relevant restrictions and deletions before information returns to service. Evidence must distinguish live deletion, deferred backup disposal, justified retention, and unverified copies.

A supplier promise needs a service boundary

The external supplier received information before the customer made the request. Supplier management must connect the affected submissions to the applicable agreement, service configuration, and response process. Withdrawal of the representative's authorization is not automatically cancellation of all processor use. The false content, unnecessary copies, and continuing processing purpose each need their own disposition.

UK GDPR Article 28 addresses processor instructions, assistance with rights, subprocessors, and return or deletion at the end of the relevant services. [7] The contract and operating arrangements must turn those responsibilities into a usable route for this service. A public policy alone does not establish the organization's contractual position or prove completion.

Dated supplier example, checked October 28, 2026. Anthropic's commercial documentation states a default of no training on inputs and outputs, with qualifications including feedback or other opt-in use. Its API retention page describes deletion within 30 days, subject to stated exceptions and model-specific requirements; its paid API deletion page says ad hoc deletion is unsupported. These are service-policy statements, not universal supplier conditions or a finding about this hypothetical insurer's contract. [8]

If the supplier cannot provide the required handling, narrow the submitted information or change the arrangement before relying on it. If local memory is corrected but the supplier has only acknowledged the request, supplier disposal remains unverified, with an owner, deadline, and remaining exposure. Deleting a source, chat, or index entry cannot by itself establish removal from a supplier's backups, logs, or a trained model. If training or improvement use occurred, investigate that use separately rather than promising that a local deletion reverses it.

Fund the form of memory the operation can sustain

The Outcome owner must compare the benefit of continuity with the recurring work it creates. Include review, correction, recipient changes, supplier follow-up, retention administration, and support. Less repeated assembly is useful only if the service still reaches an acceptable complaint outcome without shifting unmanageable work to specialists or the receiving team.

The Operating owner coordinates containment and affected casework. The Data owner maintains authoritative facts and permissions; the Knowledge owner maintains approved policy meaning and applicability. The Technology owner implements and verifies changes. Privacy handles rights, Legal determines legal questions, records management governs preservation and disposal, Security addresses access and disclosure incidents, and supplier management pursues contractual performance. The Control lead coordinates requirements and evidence within its mandate. These duties require capacity; they do not merge into a general knowledge role.

For this hypothetical, I would Narrow persistent memory while the false authorization summary and affected uses are resolved. Retain only justified case continuity, with governed-record checks for permission and human control of communication. If the service cannot maintain that boundary, Redesign it to assemble more context afresh. That choice still requires control over supplier copies, outputs, and logs.

Evidence for continuing memory should include a completed change exercise: a later contact uses the corrected information; a queued disclosure is blocked; a stale consumer is found and repaired; required history remains available only for its justified purposes; and supplier or backup limits remain explicit. Controls by Design provides the broader control discipline. The leadership judgment is whether the demonstrated benefit warrants this continuing commitment.

Leadership takeaway

Before continuing persistent memory, ask the Operating owner and Technology owner to demonstrate one correction and one authorization withdrawal after information has already been used. Require them to show which uses stopped, what was corrected, which earlier outputs were reviewed, what was deleted, and what remains with a stated reason and owner.

Then compare that operating burden with the benefit of remembering between contacts. Continue only the scope supported by evidence and capacity. Narrow the information retained where a smaller memory is sufficient; redesign the service where the organization cannot reliably change its uses.

The commitment is to maintain legitimate information use for as long as the service carries the information. Retention, correction, and disposal belong in the decision to keep memory.

Sources and further reading

Primary sources checked October 28, 2026. The case and proposed operating responses are illustrative editorial judgments, not legal advice, compliance certification, or validated business results.

  1. UK GDPR, Article 5, especially 5(1)(b)-(e) and 5(3). Law: purposes, minimization, accuracy, storage, and the separate requirement for lawful processing.
  2. UK GDPR, Article 16 and Article 18. Law: rectification and restriction.
  3. UK GDPR, Article 19. Law: notification to recipients, including its qualification.
  4. FCA Handbook, DISP 1.1.3R and 1.9.1R. Regulatory rules: application and complaint-record retention for the stated case.
  5. UK GDPR, Article 17, especially 17(1) and 17(3)(b), (e). Law: qualified erasure rights and exceptions.
  6. ICO, Right to erasure, backup-systems section. Regulatory guidance, marked under review following the Data (Use and Access) Act; read with current legislation.
  7. UK GDPR, Article 28, especially 28(3)(a), (d), (e), (g), and (h). Law: processor arrangements and evidence.
  8. Anthropic Privacy Center, model training (August 18, 2026), organizational data retention (July 1, 2026), and paid API deletion (March 16, 2026). Supplier service policies; check the actual model, endpoint, configuration, and agreement.