Урок 7.3. Privacy, compliance и управление пользователем

Цель лекции

Объяснить требования к памяти в продуктах, где важны доверие, контроль пользователя и соответствие правилам.

Ожидаемый результат

Читатель понимает, что privacy и governance являются частью архитектуры памяти, а не надстройкой после релиза: consent, user-visible memory, edit/delete/export, data minimization, retention, tenant isolation, access control и auditability должны проектироваться заранее.

Зачем это нужно

Память агента меняет отношения пользователя с системой.

Обычный чат может забыть контекст после сессии. Агент с памятью может помнить:

• предпочтения;
• рабочие проекты;
• личные сведения;
• прошлые задачи;
• документы;
• customer data;
• ошибки и corrections;
• sensitive context;
• decisions и commitments.

Это полезно, но требует доверия. Пользователь должен понимать:

• что агент помнит;
• почему он это помнит;
• где это применяется;
• кто имеет доступ;
• как исправить ошибку;
• как удалить память;
• как ограничить использование;
• как экспортировать данные.

Privacy в memory systems - не только юридическая галочка. Это архитектурное свойство.

Основная идея

Пользователь должен иметь понятный контроль над тем, что агент помнит, почему он это помнит и как это удалить или исправить.

Memory layer должен поддерживать:

• explicit и implicit consent rules;
• user-visible memory;
• edit/correction flow;
• delete/forget flow;
• export;
• data minimization;
• retention windows;
• tenant isolation;
• access control;
• auditability.

Если эти возможности не заложены в representation, storage, indexes и summaries, позже добавить их будет сложно.

Ключевые термины

Consent

Consent определяет, что можно сохранять.

Формы:

• explicit: пользователь говорит "запомни";
• implicit: продуктовая настройка разрешает память для определенных сценариев;
• contextual: память нужна для выполнения текущей задачи;
• organization-level: администратор включает/ограничивает memory для workspace;
• denied: пользователь запрещает сохранение.

Примеры:

"Запомни, что я предпочитаю краткие финальные ответы."

Это явный consent для preference.

"Сегодня отвечай коротко."

Это не обязательно consent для long-term memory. Скорее session instruction.

"Вот медицинский документ, помоги его резюмировать."

Это consent на обработку в текущей задаче, но не автоматическое разрешение сохранять sensitive details навсегда.

Consent должен быть связан с scope, purpose и retention.

User-visible memory

Пользователь должен иметь возможность увидеть, что агент помнит.

User-visible memory может показывать:

• saved preferences;
• project facts;
• inferred facts;
• recent memories;
• memory source;
• created_at;
• last_used_at;
• scope;
• status;
• confidence;
• controls: edit/delete.

Пример UI/representation:

Saved memory:
- "Final edit reports should be concise."
Scope:
- Project: AI Agent Memory Guide
Source:
- User instruction, 2026-08-07
Actions:
- Edit | Delete | Limit scope

Visibility повышает trust и помогает исправлять ошибки. Скрытая память быстро вызывает ощущение, что система наблюдает без контроля.

Edit memory

Память может ошибаться. Пользователь должен иметь возможность исправить ее.

Пример:

User:
"Нет, я не хочу краткие объяснения. Кратким должен быть только финальный отчет."

Система должна:

• найти old memory;
• не просто добавить новый conflicting fact;
• split scope;
• mark old broad record superseded;
• сохранить correction source;
• обновить indexes и summaries.

Edit flow:

User correction
-> locate affected records
-> apply update policy
-> update active memory view
-> re-index
-> confirm change

User correction - один из самых надежных источников truth для user memory.

Delete memory

Delete memory - не просто убрать строку из одной таблицы.

Memory может существовать в:

• main record store;
• vector index;
• search index;
• graph edges;
• summaries;
• cache;
• event log;
• archive;
• object storage;
• derived records;
• shared memory.

Delete flow должен учитывать все copies and derivatives.

Возможные стратегии:

• soft delete;
• hard delete;
• tombstone;
• remove from active view;
• delete embeddings;
• invalidate cache;
• rebuild summary;
• remove graph edges;
• preserve minimal audit if policy permits.

Пример:

User:
"Удалить сохраненные предпочтения о стиле ответа."

Action:
- Delete user preference records.
- Remove from profile summary.
- Remove embeddings/search entries.
- Invalidate cached context.
- Keep deletion marker without preference content if needed.

Deletion нужно проектировать до запуска продукта.

Export memory

Export memory дает пользователю переносимость и прозрачность.

Экспорт может включать:

• preferences;
• project/user facts;
• saved summaries;
• reflections, если они относятся к пользователю;
• sources;
• timestamps;
• scopes;
• statuses.

Форматы:

• JSON;
• Markdown;
• CSV для простых таблиц;
• archive bundle.

Экспорт не должен раскрывать чужие данные. Если memory содержит shared/team/org records, нужно фильтровать по правам.

Пример:

Export:
- user_profile.json
- project_preferences.md
- memory_sources.csv

Data minimization

Data minimization означает: хранить только то, что нужно.

Плохой подход:

Сохранять весь transcript каждой сессии навсегда.

Лучше:

Сохранять scoped preferences, важные events, summaries и audit metadata
с ограниченным retention.

Минимизация снижает:

• privacy risk;
• breach impact;
• retrieval noise;
• storage cost;
• deletion complexity;
• user distrust.

Вопрос перед записью:

Нужно ли это хранить для будущей пользы, или достаточно текущей сессии?

Retention windows

Разные данные требуют разных сроков хранения.

Пример:

Retention должен быть machine-enforced, а не просто написан в policy document.

Нужны:

• expires_at;
• TTL jobs;
• archive jobs;
• deletion jobs;
• retention audit.

Tenant isolation

Tenant isolation защищает данные разных организаций, клиентов или workspace.

Обязательные элементы:

• tenant_id в memory record;
• tenant-aware indexes;
• permission filters before retrieval;
• tenant-aware cache keys;
• separation for derived summaries;
• audit by tenant;
• tests for boundary violations.

Пример опасного бага:

Vector query finds similar support ticket from another customer.
Context assembly inserts it because semantic score is high.

Правильное правило:

Tenant boundary beats semantic relevance.

Для sensitive enterprise systems иногда нужны physical separation или per-tenant indexes.

Access control

Access control определяет:

• кто может читать memory;
• кто может писать;
• кто может edit;
• кто может delete;
• кто может export;
• какие агенты могут видеть shared memory;
• какие roles видят internal notes;
• можно ли использовать memory в final answer.

Важно различать:

• read for backend processing;
• inject into prompt;
• reveal to user;
• share with another agent;
• include in export.

Пример:

Internal support note:
- readable by support role;
- not revealable to customer;
- may influence escalation decision;
- must not be quoted in final answer.

Access control должен быть частью retrieval и context assembly, а не только UI.

Auditability

Пользователь и команда должны понимать, как память повлияла на ответ.

Auditability отвечает:

• какая память была retrieved;
• какая память была injected;
• какие sources использовались;
• какие policies применились;
• почему запись была сохранена;
• кто ее изменил;
• когда она последний раз использовалась;
• почему она была удалена.

User-facing explanation может быть простой:

Я использовал сохраненное предпочтение: "финальные отчеты должны быть краткими".

Internal audit может быть детальнее:

memory_id: pref_123
source: user_instruction
scope: project
injected_at: ...

Audit trail не должен становиться новым источником privacy leak.

Privacy by design

Privacy нужно проектировать в memory layer с самого начала.

Компоненты:

• representation with scope/source/status;
• consent-aware write policy;
• PII/secrets filtering;
• permission-aware retrieval;
• context assembly restrictions;
• retention jobs;
• deletion propagation;
• user controls;
• audit;
• human review for high-risk records.

Если memory layer изначально хранит everything as text blobs, privacy controls будут поверхностными.

Схема user control lifecycle

User controls должны работать не только с main store, но и с indexes, summaries, cache, archive и derived records.

Мини-кейс: пользователь исправляет preference

Memory:

- User prefers short answers.
scope: all tasks

User correction:

"Короткими должны быть только финальные отчеты. Объяснения оставляй подробными."

Correct update:

Old:
- status: superseded

New:
- User prefers concise final reports.
- User prefers detailed explanations when learning architecture.

UI should show:

Updated memory:
- Concise final reports.
- Detailed architecture explanations.

Это повышает trust: пользователь видит, что correction реально изменила active memory.

Мини-кейс: enterprise support

Support agent работает с customer account.

Memory includes:

• public docs;
• account entitlement;
• internal support note;
• previous ticket summary;
• organization policy.

Privacy/compliance requirements:

• account data only for authorized users;
• internal notes not quoted to customer;
• retention for tickets follows policy;
• audit which memory influenced answer;
• delete or anonymize data after retention window;
• export only allowed customer-visible data.

В такой системе memory layer должен быть permission-aware на каждом этапе.

Типичные ошибки

Ошибка 1: добавлять user controls после релиза.

Если representation не поддерживает source/scope/status, controls будут неполными.

Ошибка 2: удалять только main record.

Embeddings, summaries, cache и derived records тоже нужно учитывать.

Ошибка 3: считать consent универсальным.

Consent имеет purpose, scope и retention.

Ошибка 4: показывать пользователю не всю active memory.

Скрытые active preferences подрывают доверие.

Ошибка 5: не разделять internal use и revealability.

Запись может помогать решению, но не должна цитироваться пользователю.

Ошибка 6: смешивать tenants в shared indexes.

Semantic relevance не отменяет access boundaries.

Ошибка 7: хранить больше "на всякий случай".

Data minimization - один из лучших способов снизить риск.

Краткое резюме

Privacy, compliance и user control являются частью архитектуры memory layer. Память должна быть видимой, исправляемой, удаляемой, экспортируемой и ограниченной по scope, purpose, permissions и retention.

Хорошая memory system поддерживает consent, data minimization, tenant isolation, access control, auditability и deletion propagation across stores, indexes, summaries, cache and archives.

Память без контроля может быть функционально удобной, но продуктово опасной: пользователь не будет доверять агенту, который помнит непонятно что и непонятно где.

Вопросы для самопроверки

1. Почему consent должен иметь scope и purpose?
2. Что должно быть видно пользователю в user-visible memory?
3. Почему delete memory сложнее, чем удалить строку из таблицы?
4. Чем access to memory отличается от permission to reveal memory?
5. Почему data minimization снижает не только privacy risk, но и retrieval noise?

Что дальше

Module 07 завершает блок рисков: мы разобрали failure modes, memory poisoning, security, privacy, compliance и user control. В следующем модуле мы перейдем к оценке качества памяти: какие метрики, тесты и бенчмарки помогают понять, работает ли memory layer лучше, чем кажется.