Consent, Appeal and Forgetting: Three Product Journeys to Design

In many AI products, rights exist in terms and conditions but disappear from the real journey. Users do not know when information becomes memory, how to correct a decision or what “delete” means. Consent, appeal and forgetting should be observable product functions.

Consent: a decision tied to purpose

A general choice at signup cannot explain every future use. Distinguish:

• data required to perform the request;
• retention for future context;
• sharing with a team or third party;
• analysis to improve the service;
• possible training use.

Ask at the moment the user can understand the action. A memory choice should appear when information is about to be remembered, with a clear scope and a real way to change the decision later.

Consent is not always the appropriate legal basis. Identify the applicable basis and obligations with competent advice rather than treating the word as a universal solution.

Appeal: correction with an owner

A “report” button is not a complete appeal path. Users need to know:

1. what can be challenged;
2. what information will be sent;
3. who reviews the request;
4. the expected response time;
5. how the data or decision will be corrected;
6. what happens to actions already triggered.

For a material recommendation, appeal may need to pause the next step. It should retain enough context for a person to understand the issue without making the user repeat everything.

Forgetting: several operations, not one button

Correction, expiration, unlinking, restriction and deletion have different effects. False information may need correction, old information deactivation, personal data deletion and a historical decision preservation in minimized form.

Map the copies: source, summary, search index, agent memory, trace, export and backup. Explain what disappears immediately, what takes time and what remains under a legitimate obligation.

Most importantly, forgotten information must not silently return in a future AI context.

A five-screen rights map

A practical journey includes:

• Before action: purpose, required data and limits.
• At memory time: preview, private or shared scope, retention.
• In settings: view, correct, export, restrict or delete.
• After an error: challenge with relevant context attached.
• After the request: track status and verify the effect.

This turns an abstract obligation into a testable experience.

Useful metrics

Track understanding, refusals, changed choices, appeal time, correction rate, complete deletions and information resurfacing after deletion. A low request count is not always success; the pathway may simply be hard to find.

Fact, inference and hypothesis

Direct fact: rights and obligations depend on legal context, data and purpose; an interface does not replace qualified analysis.

Inference: visible controls improve both operational compliance and the user's ability to delegate with confidence.

Hypothesis to test: a clear memory preview before confirmation reduces later deletion requests and increases durable use.

FAQ

Is consent required for every action?

No. Avoid consent fatigue and request a distinct choice when purpose, scope or risk materially changes.

Does deleting data erase all history?

Not necessarily. Some legitimate records may remain, but they should be minimized, protected and excluded from unjustified future use.

Is a support email enough for appeal?

Rarely. A visible path, transferred context, owner, status and expected time are needed.

Next step

Draw the rights map for one existing capability and test it with someone who has not read your policy. For a journey review, email contact@yumea.fr with the subject “AI RIGHTS.”