Почему вашему ИИ-агенту нужен комплаенс-слой

В феврале 2024 года я подключил ИИ-агента к почте отдела бронирования одного клиента. Демо прошло отлично. Агент читал новые заявки, проверял календарь, создавал брони и отправлял подтверждения по SMS. Через три недели после запуска аудитор клиента прислал шесть вопросов о данных клиентов. На пять я ответил. Шестой требовал доказательств: какие записи агент открывал, кто одобрил каждое исходящее сообщение и когда удаляются переписки с номерами телефонов. Чёткого ответа у меня не было. Запуск встал на три недели, пока я перестраивал слой данных.

Аудит, который я однажды провалил

Клиент держал сервисную компанию на шестьдесят сотрудников и принимал около четырёхсот заявок на бронирование в неделю. Агент разбирал почту четырьмя инструментами: read_inbox, check_calendar, create_booking и send_sms. Я писал запросы и сырые выводы инструментов в одну таблицу Postgres под названием agent_logs в виде сырого текста. Половина строк осталась без session id. Номера телефонов и адреса почты лежали открытым текстом. Команда хранила всё подряд для возможного обучения модели.

Перед партнёрской сделкой пришёл внешний аудитор и задал три вопроса. Первый: перечислить каждую запись клиента, которую агент открыл 12 марта. Второй: показать, кто одобрил сорок SMS, отправленных агентом за неделю. Третий: назвать дату удаления переписок с номерами телефонов.

Мои ответы выглядели слабо. Чтения за 12 марта я восстановил по временным меткам, работа заняла два дня. У SMS не было поля одобрения, агент отправлял их по собственному решению. Дата удаления отсутствовала, я её нигде не задал. Сделка сдвинулась на месяц. Следующие две недели я скриптом удалял двенадцать тысяч сырых переписок и писал заметку о хранении на одну страницу. Клиент оставил меня в проекте.

Аудиторы просят записи. Намерения их не убеждают. Каждый агент теперь получает небольшой комплаенс-слой с первого дня, до касания клиентских данных. В слое три части.

Слой из трёх частей: журнал вызовов, срок хранения, очистка PII

Журнал вызовов инструментов

Каждый вызов инструмента попадает в таблицу Postgres под названием agent_audit. Колонки: id uuid, created_at timestamptz, tenant_id text, session_id text, actor text, tool_name text, args_hash text, args_redacted jsonb, result_code text, policy_decision text, delete_after date. Я храню SHA-256 хеш полных аргументов и отредактированную копию с заменой персональных данных метками. Сырой текст клиентов в таблицу не попадает. Нагрузку несут два индекса: по tenant_id с created_at и по session_id.

Actor принимает три значения: user, agent, approver. Каждое исходящее сообщение требует строку с actor approver или policy_decision auto_approved с номером правила. Инструмент отправки отказывается работать без такой строки. Когда аудитор спрашивает, каких записей коснулся агент, отвечает один запрос: фильтр agent_audit по session_id и сортировка по created_at.

Фиксированный срок хранения

Каждая строка несёт delete_after, значение по умолчанию равно created_at плюс тридцать дней. Задача pg_cron запускается каждую ночь в 03:00 и удаляет просроченные строки. Настройки клиента сокращают окно до семи дней для чувствительных переписок или продлевают бронирования до девяноста дней с письменной пометкой владельца данных. Значение по умолчанию остаётся тридцать дней. Удаление учитывается счётчиками по клиентам: сколько строк удалено, какая самая старая строка осталась. На вопрос аудита о сроках я показываю строку конфига и счётчики за прошлый месяц.

Конвейер очистки PII

Два прохода идут до записи на диск. Первый проход ищет регулярными выражениями адреса почты, номера телефонов, номера карт, IBAN и шаблоны национальных ID стран, где я работаю. Второй проход прогоняет текст через небольшую языковую модель, которая помечает имена, адреса улиц и даты рождения в свободном тексте, включая опечатки мимо регулярок. Очищенный текст уходит в журналы и память агента. Оригиналы уходят в шифрованное хранилище с TTL семь дней за break-glass доступом, каждое чтение пишет собственную строку аудита.

Перед каждым релизом я проверяю конвейер фиксированным набором из двухсот примеров. Класс regex обязан показать ноль пропусков. Класс модели обязан показать залогированную оценку качества для сравнения с прошлым релизом. Новый шаблон PII из продакшена становится новым тестом в тот же день.

Сколько стоит слой и сколько стоит утечка

На новом агенте слой строится два-три рабочих дня: полдня на таблицу аудита и индексы, полдня на задачу удаления и конфиг, день на конвейер очистки и набор из двухсот тестов, полдня на механизм одобрения и контрольный запрос. На существующем агенте с грязными журналами закладывайте полную неделю, включая перенос старых данных и удаление сырого архива. Текущие расходы малы: одна таблица, одна задача в cron и один вызов модели на входящее сообщение, цена в центах за тысячу сообщений по текущим тарифам.

Сравните со счётом, который заплатила сервисная фирма на сорок человек после инцидента слабее утечки: около $35,000 за юридическую проверку, уведомления клиентов и три недели переделок. Сотрудники тихо вернулись к ручному вводу, доверие к инструменту упало. Слой стоит около $2,500 времени разработки. Инцидент стоил в четырнадцать раз дороже, без учёта потерянного доверия.

Чек-лист, который можно скопировать

Прогоните список по текущему агенту на этой неделе. Отмечайте строки или заводите задачи.

1. Создайте agent_audit с одиннадцатью колонками выше и обоими индексами.
2. Дайте каждой сессии стабильный session_id с первого сообщения.
3. Логируйте каждый вызов инструмента. Тихих вызовов быть не должно.
4. Храните args_hash и отредактированные аргументы. Сырой текст клиентов в журнал не входит.
5. Проставьте delete_after в каждой строке. Держите тридцать дней по умолчанию.
6. Планируйте ночную задачу удаления. Сигнализируйте о пропущенном запуске.
7. Добавьте regex-проход очистки с тестом из двухсот примеров.
8. Добавьте модельный проход для имён и адресов.
9. Держите оригиналы в хранилище с TTL семь дней за break-glass доступом.
10. Разрешайте исходящие отправки только по строке одобрения.
11. Тренируйтесь ежемесячно: берите случайную сессию и отвечайте на три вопроса аудита быстрее десяти минут.
12. Ведите заметку о хранении на одну страницу: что хранится, где лежит, сколько живёт, кто одобряет изменения.

Я прогоняю проверку в первый понедельник каждого месяца. Она занимает двадцать минут. Она спасла бы мой запуск февраля 2024 года.