Память и приватность: что агент о вас запоминает
🤔 Зачем это читать
Поддержка год хвалит нового AI-ассистента: он помнит каждого клиента в лицо. Клиент пишет «у меня та же проблема, что в марте» — и агент сразу: «да, по вашему договору № такому-то, на карту, оканчивающуюся на 4417, мы тогда вернули 12 000 ₽». Удобно до восторга. А потом приходит запрос из надзорного органа: где и на каком основании вы храните паспортные данные и номера карт клиентов? И выясняется, что «где-то у вендора», а основания никто не оформлял. Удобство мгновенно превращается в штраф и заголовок в новостях.
Знакомо ощущение? Или другой вариант: вам предложили готовую «память от поставщика» — подключаешь, и агент сам всё запоминает, своих инженеров держать не надо. Подписали. Через год захотели сменить поставщика — а вся накопленная история клиентов лежит у него, выгрузить толком нельзя, и уйти стало дороже, чем остаться.
Оба раза боль одна: память — это не только удобство, это ответственность и привязка. Если агент что-то помнит — значит, это где-то лежит. А раз лежит — встают два неудобных вопроса, которые в эйфории от демо никто не задаёт: что туда вообще можно класть по закону и кому ты отдаёшь ключ от этого хранилища.
Ты уже знаешь из темы 6.2 — Короткая и длинная память, что долгая память агента — это отдельное хранилище, которое живёт между разговорами. Здесь мы не про то, как она устроена, а про то, как оценить конкретное решение: что в эту память безопасно положить, а что — мина, и держать ли её у себя или отдать вендору. Это навык владельца, а не повара, и без него «удобная память» однажды прилетает счётом.
Задержись на 10 секунд. Вспомни хоть один сервис, который про тебя слишком много помнит — банк, маркетплейс, доставка. Что именно он знает: имя? адрес? карту? здоровье? Где это всё, по-твоему, лежит и кто к нему имеет доступ? Подержи это чувство «а они вообще имеют право?» в голове — ровно его мы и переведём в рабочий вопрос к концу страницы.
📕 Память агента — это книга постоянных гостей
Давай вернёмся на кухню. В хорошем ресторане у администратора есть книга постоянных гостей — туда записывают то, что помогает обслуживать лучше: «столик 12 любит у окна», «господин Петров не ест острое», «эта пара отмечает годовщину в мае». Официант заглянул — и встретил гостя как родного. Это ровно то, что делает долгая память агента: помнит контекст про клиента между визитами, чтобы каждый раз не начинать с нуля.
Польза очевидна. Но именно из-за этой книги у владельца появляются две новые головные боли, которых не было, пока он просто кормил людей. И обе — не про вкус блюд, а про закон и про доверие.
Первая: что вообще можно записывать в эту книгу. «Любит у окна» — пожалуйста. А вот номер паспорта гостя, его диагноз, который он обронил за ужином, или скан его карты — это уже не «предпочтения», это персональные данные. На них есть закон, и хранить их «просто так, на всякий случай» нельзя.
Вторая: где эта книга лежит и кто к ней подходит. Лежит ли она в твоём сейфе — или ты отдал её на хранение соседней фирме, которая обслуживает заодно и твоих конкурентов? Можешь ли ты её вообще забрать, если захочешь сменить подрядчика?
Разберём обе по очереди — это и есть весь сегодняшний навык.
🔒 Что нельзя записывать: персональные данные
Сначала про закон — без него всё остальное повиснет в воздухе. Есть понятие персональные данные (любая информация, по которой можно узнать конкретного человека: ФИО, телефон, адрес, паспорт, номер карты, данные о здоровье). Их защищают законы: в России это 152-ФЗ (закон «О персональных данных»), в Европе — GDPR (General Data Protection Regulation, общий регламент защиты данных ЕС). Если ты предлагаешь услуги людям, находящимся в ЕС, — GDPR касается и тебя, даже если ты сидишь в Москве.
Суть для нетехнаря в трёх правилах, без юридических кружев:
- Нельзя хранить «на всякий случай». Под каждый кусок персданных нужна причина и согласие человека. Нет причины — не клади в книгу. «Вдруг пригодится» — это не причина.
- Бери минимум. Чтобы узнать заказчика в лицо, агенту хватит «постоянный клиент, любит доставку к вечеру». Паспорт и номер карты для этого не нужны — а лежат они как пороховая бочка.
- Знай, где это физически лежит. По 152-ФЗ персданные россиян сначала должны записываться и храниться на серверах в России — зарубежное облако само по себе этого не закрывает. «Память где-то у вендора» — не ответ, который примет проверка.
Полезный приём — мысленно делить всё, что агент хочет запомнить, на три корзины.
Почему именно «памяти агента не место»? Потому что память — самое «болтливое» хранилище в системе. Её содержимое регулярно достают и снова подкладывают агенту «перед глаза», она попадает в логи, её видит модель, а иногда — и сам клиент в ответе. Чем чувствительнее данные, тем меньше им место в таком проходном дворе. Номер карты живёт в защищённой платёжной системе, а не в заметках официанта.
🏠 Где лежит книга: своя память или вендорская
Теперь второй вопрос — и здесь нет «правильного» ответа, есть осознанный выбор. Память агенту можно устроить двумя путями, и это классическая развилка build vs buy (сделать своё или купить готовое).
Купить готовую (managed-память, то есть «под ключ» от вендора). Поставщик даёт сервис: подключаешь — агент сам всё запоминает, хранилище, поиск по смыслу, обслуживание — на их стороне. Своих инженеров под это держать почти не надо.
Сделать свою. Хранилище памяти стоит в твоём контуре, на твоих серверах или в твоём облаке. Сам решаешь, что хранить, сколько и где, сам и обслуживаешь.
Выбор — это размен, и вот честные две чаши весов:
Заметь связку: оба вопроса — что хранить и где хранить — сходятся в одной точке. Чем меньше чувствительного ты вообще кладёшь в книгу, тем спокойнее тебе отдавать её хранение вендору. Если в памяти только «любит вечернюю доставку» — ну и пусть лежит у поставщика, утечка не страшна. А если ты зачем-то сложил туда паспорта — теперь любой вынос наружу превращается в катастрофу, и «своя память» из роскоши становится почти обязательной.
# фильтр-привратник на входе в книгу гостей
если запись == персональные_данные:
если нет(согласие) или нет(причина_хранить):
не_класть_в_память() # нельзя по 152-ФЗ / GDPR
если запись в [паспорт, карта, здоровье, чужая_тайна]:
не_класть_в_память() # место в защищённой системе, не в «болтливой» памяти
если хранилище == вендорское и данные == чувствительные:
пересмотреть_выбор() # наружу + lock-in — взвесить «свою»
Прежде чем трогать тренажёр — реши сам. Представь, что у твоего агента поддержки появилась память. Прикинь две вещи. Первая: из всего, что агент мог бы запомнить про клиента, что ты точно не дашь ему хранить — и почему? Вторая: если данные клиентов чувствительные, ты скорее отдашь память вендору «под ключ» ради скорости — или построишь свою ради контроля? Подержи оба решения в голове и проверь чутьё на ситуациях ниже.
🎮 Решает владелец: что в память, и где её держать
Пять ситуаций из жизни AI-проекта. В каждой ты — владелец, который принимает решение. Выбирай вариант, который лучше всего бережёт и клиентов, и компанию. Это не про «знать закон наизусть», а про чутьё: где удобство тащит за собой риск. Жми — и сразу разбор. В одном из кейсов попрошу не просто выбрать, а назвать свой критерий — по нему ты и взвешиваешь, а не угадываешь.
📖 Ключевые понятия
- Персональные данные
- Любая информация, по которой можно узнать конкретного человека: ФИО, телефон, адрес, паспорт, номер карты, данные о здоровье. Их хранение и обработку регулируют законы (в России — 152-ФЗ, в Европе — GDPR), и просто так «на всякий случай» класть их в память агента нельзя.
- 152-ФЗ и GDPR
- Законы о защите персональных данных: 152-ФЗ — российский, GDPR (General Data Protection Regulation) — европейский. Требуют согласия, причины и понятного срока хранения; 152-ФЗ к тому же требует, чтобы персданные россиян сначала записывались и хранились на серверах в России. GDPR касается тебя, если ты предлагаешь услуги людям, находящимся в ЕС, даже когда сам ты в России.
- Память — «болтливое» хранилище
- Содержимое памяти агента регулярно достают и подкладывают модели «перед глаза», оно попадает в логи и иногда в ответы клиенту. Поэтому чувствительное (карты, паспорта, здоровье) хранят в защищённых системах, а не в памяти агента.
- Managed-память (готовая, от вендора)
- Память «под ключ»: хранилище и обслуживание — на стороне поставщика. Экономит инженерию и время на старте, но данные уходят наружу и появляется привязка (lock-in) — забрать накопленную историю и сменить поставщика потом бывает дорого или невозможно.
- Build vs buy памяти
- Развилка «сделать своё или купить готовое» применительно к памяти. Своя память — данные дома и без привязки, но дороже в работе. Вендорская — быстро и дёшево, но наружу и lock-in. Чем чувствительнее данные и строже закон, тем сильнее выбор смещается к своей.
🛡️ Частые заблуждения
«Чем больше агент про клиента помнит, тем лучше сервис — пусть знает всё»
До определённого предела — да, а дальше каждый лишний кусок персданных в памяти превращается в риск: утечка, штраф по 152-ФЗ или GDPR, удар по репутации. Хороший сервис — это «помнит ровно нужное», а не «помнит всё». Минимум данных бережёт и клиента, и тебя.
«Раз память у вендора, то и за сохранность данных отвечает вендор, не я»
Перед клиентом и законом отвечаешь ты — это твои клиенты и твои данные, ты их собрал. Вендор лишь хранит. Если оттуда утекли паспорта, объясняться с проверкой и клиентами придётся тебе. Поэтому вопрос «где и как это хранится» — твой, а не «их проблема».
«Готовая память от вендора всегда выгоднее — зачем городить своё»
На старте дешевле, спору нет. Но в цену входит вынос данных наружу и привязка: когда захочешь уйти, накопленная история клиентов может остаться у поставщика, и уход выйдет дороже, чем то, что ты сэкономил. Выгода считается на годы вперёд и с учётом чувствительности данных, а не по чеку первого месяца.
🧠 AI-чутьё (AI Judgment)
Удобство памяти = ответственность: что хранить и кому отдать
Мысль, которую стоит унести с этой страницы: каждое «как удобно, что агент это помнит» — это и строчка ответственности, и вопрос, кому ты отдал ключ. Восторг от демо («он узнаёт клиентов!») заслоняет два неудобных вопроса, и твоя работа как владельца — задать их раньше, чем их задаст проверка.
Рабочая рамка — два вопроса к любому решению про память агента. Первый: «Что именно мы кладём в память — и можем ли мы это хранить по закону, есть ли согласие и причина?». Если там паспорта и карты «на всякий случай» — стоп, переделать. Второй: «Где это лежит и сможем ли мы это забрать?» — про вендора, про границу, про lock-in. Чем чувствительнее данные, тем меньше их клади и тем серьёзнее думай про «свою» память.
И помни про связку: эти два вопроса не отдельные, они тянут друг друга. Меньше чувствительного в памяти — спокойнее отдавать хранение вендору. Сложил туда лишнего — и теперь обязан строить свою крепость. Самый дешёвый способ снизить риск приватности — не «защитить хранилище получше», а с самого начала не класть в память то, чему там не место.
🎯 Практика
Одно задание на десять минут, чтобы навык стал твоим, а не книжным.
- Возьми любой свой реальный процесс, где AI-агент мог бы помнить клиентов (поддержка, продажи, доставка, запись на услугу). Выпиши 5-7 вещей, которые агенту было бы удобно про клиента запоминать.
- Прогони каждую через три корзины из схемы: класть смело / только с основанием и согласием / в память агента — нет. Будь честным: «номер карты» и «жалобы на здоровье» почти наверняка уедут в красную корзину.
- Теперь по тому, что осталось в зелёной и жёлтой корзинах, ответь себе на два вопроса: эти данные ты спокойно отдашь хранить вендору — или хочешь держать у себя? И если завтра захочешь сменить поставщика — сможешь ли забрать накопленное? Ответы запиши. Это и есть твоё первое решение по приватности памяти — на бумаге, но по-настоящему.
Помнишь сервис из начала, который про тебя слишком много помнит? Теперь ты смотришь на него глазами владельца: какие из его записей про тебя — в красной корзине, и забрал бы он их обратно у своего вендора, если бы захотел. Чувство «а они вообще имеют право?» только что стало рабочим вопросом, который ты умеешь задавать.