Защищает ли маскирование PII банковскую тайну?

Маскирование PII на LLM-шлюзе снижает вероятность прямой утечки, но само по себе не защищает банковскую тайну. Фильтр может убрать ФИО и телефон, оставив номер счета, сумму, время операции, назначение платежа и содержимое вложения. Для закона и для атакующего этого часто достаточно.

Я не разрешаю банковским командам считать запрос безопасным только потому, что детектор заменил несколько строк на токены. Сначала надо определить, какие сведения нельзя выпускать из контура, затем проследить весь запрос от клиентского приложения до логов провайдера. Маскирование занимает одно место в этой цепочке. Оно не заменяет классификацию, ограничение маршрутов, контроль вложений, договорные условия и архитектурную изоляцию.

Маскирование PII отвечает не на тот вопрос

Маскирование PII ищет и скрывает заранее определенные признаки человека. Банковская тайна охватывает другой объект защиты, поэтому успешная замена персональных идентификаторов еще ничего не доказывает.

Статья 26 закона «О банках и банковской деятельности» требует хранить тайну об операциях, счетах и вкладах клиентов и корреспондентов. Она не сводит эти сведения к имени физического лица. В область риска попадают операции юридических лиц, реквизиты счетов и детали сделок. Банк также может установить режим тайны для иных сведений, если это не противоречит федеральному закону.

В 152-ФЗ обезличивание определено как действия, после которых без дополнительной информации нельзя установить принадлежность персональных данных конкретному человеку. Это более строгая операция, чем типичная подстановка [NAME_1], но даже доказанное обезличивание по 152-ФЗ не дает автоматического вывода о банковской тайне. Документ о платеже может потерять связь с физлицом и по-прежнему раскрывать операцию компании, счет или коммерчески чувствительный маршрут денег.

На практике смешивают четыре разных действия:

• редактирование удаляет фрагмент без возможности вернуть его;
• маскирование заменяет значение шаблоном для текущего запроса;
• токенизация хранит связь между исходным значением и токеном в отдельном хранилище;
• обезличивание должно выдерживать проверку на повторную идентификацию с доступной дополнительной информацией.

Разница влияет на решение об архитектуре. Если приложению после ответа модели нужно восстановить ФИО, перед нами обратимое преобразование. Если одинаковый клиент получает одинаковый токен в нескольких запросах, модель или оператор сервиса может связать его историю. Называть такой поток обезличенным без модели атакующего нельзя.

Статья 19 152-ФЗ требует правовых, организационных и технических мер защиты от доступа, копирования, предоставления и других неправомерных действий. Один фильтр на входе выполняет лишь часть технической меры. Он не отвечает, кто видит исходный запрос до фильтра, куда попадает резервная копия и может ли администратор прочитать таблицу соответствий.

Банковская тайна остается после удаления имени

Косвенные идентификаторы часто восстанавливают клиента точнее, чем ошибочно написанное ФИО. Набор из отделения, времени, суммы, редкого назначения платежа и должности получателя можно сопоставить с выпиской, заявкой поддержки или публичной закупкой.

Особенно опасны данные малых групп. Фраза «единственный валютный платеж филиала в Норильске за вчера» не содержит классического PII, однако сотрудник с доступом к операционному календарю сразу найдет клиента. То же происходит с необычной суммой, единственным отказом антифрода в смене или датой крупной сделки. Детектор сущностей видит обычные слова и числа, а человек видит запись в знакомой системе.

Реквизиты требуют отдельной политики. Номер счета, номер карты, БИК, корреспондентский счет, идентификатор транзакции, код авторизации, номер договора и назначение платежа нельзя складывать в одну категорию «цифры». У каждого поля свой формат, контекст и последствие раскрытия. Последние четыре цифры карты иногда допустимы в шаблоне ответа, но сочетание этих цифр с точным временем, суммой и торговой точкой снова делает операцию узнаваемой.

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

Полезнее классифицировать не отдельные символы, а утверждения. «Клиент Петров» содержит прямой идентификатор. «Заемщик из единственного моногорода просрочил второй платеж» содержит квазиидентификатор и событие. «ООО Ромашка перечислило 84 731 206 рублей поставщику» описывает конкретную операцию. Политика должна учитывать субъект, действие, реквизит, сумму, время и возможность связать их с внутренним источником.

Я использую простой тест: сможет ли сотрудник с обычным служебным доступом найти исходную запись за несколько минут. Если да, замена ФИО не снизила риск до приемлемого уровня. Этот тест не заменяет юридическую оценку, но хорошо вскрывает ложное чувство безопасности на архитектурном ревью.

Вложения обходят текстовый фильтр

Шлюз защищает только те части запроса, которые он разобрал до отправки модели. Если приложение передает PDF, скан, изображение, архив, аудио или ссылку на объектное хранилище вне проверяемого канала, текстовый фильтр контролирует оболочку, а не данные.

Распространенная поломка выглядит так. Чат отправляет сообщение «проверь платежное поручение» и файл. Шлюз маскирует текст сообщения, не находит PII и ставит зеленую метку. Затем клиентская библиотека кодирует файл как часть мультимодального запроса либо модель получает временный адрес файла через инструмент. В платежном поручении остаются счета, ИНН, подписи, назначение и сумма. В журнале шлюза все выглядит чисто, потому что проверенный фрагмент действительно был чистым.

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

У запроса есть и другие каналы:

• системный промпт с примерами реальных обращений;
• история диалога, которую клиент автоматически добавляет снова;
• результаты инструментов, включая поиск по внутренней базе;
• имя файла, метаданные и временный адрес загрузки;
• трассировки, сообщения об ошибках и отладочные дампы.

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

Архивы и защищенные паролем документы лучше блокировать до распаковки в выделенной песочнице. Ограничение размера, числа файлов, глубины архива и времени обработки защищает сам слой проверки от истощения ресурсов. Если бизнесу нужен формат, который анализатор не понимает, этот формат должен идти в локальный маршрут или в ручной процесс.

Регулярное выражение не понимает операцию

Регулярные выражения хорошо ловят значения со стабильной формой и контрольной суммой. Они плохо распознают смысл, вариант записи и связь между полями. Поэтому regex нужен как быстрый слой, а не как единственный судья.

Номер счета можно разбить пробелами, вставить неразрывный пробел, передать как текст на изображении или назвать «наш расчетный». Сумма 84731206 похожа на любое целое число. Назначение платежа может раскрыть договор и контрагента без единого формального идентификатора. Детектор имен ошибается на названиях организаций и редких фамилиях, а словарь не знает новые внутренние коды.

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

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

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

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

Обратимые токены требуют собственного контура доверия

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

Хранилище токенов размещают внутри банковского контура. Доступ к нему дают отдельному сервису с узкими операциями tokenize и detokenize, а не всем приложениям, которые вызывают модель. Сервис проверяет цель, пользователя, класс поля и идентификатор процесса. Каждое обратное преобразование попадает в неизменяемый аудит.

Одинаковые токены во всех системах облегчают корреляцию. Лучше ограничивать область стабильности: один процесс, один диалог либо один тип документа. Тогда [CLIENT_A7F2] в обращении поддержки не связывается с тем же человеком в антифрод-запросе. Случайные токены должны иметь достаточное пространство, а сервис обязан отлавливать коллизии.

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

Есть поля, которые нельзя безопасно восстановить после свободной генерации. Если модель получила токен счета и написала новый платежный текст, приложение не должно слепо подставлять номер обратно во все места, где встретило похожую строку. Разбирайте ответ по ожидаемой схеме, проверяйте допустимые поля и разрешайте детокенизацию только в конкретном пути объекта.

Срок жизни соответствия должен следовать задаче, а не сроку хранения общего лога. Для разового резюме он может закончиться после выдачи ответа. Для длительного процесса нужен обоснованный срок и владелец. Удаление таблицы соответствий не отменяет риск, если исходник уже попал в трассировку до токенизации.

Локальный контур нужен, когда смысл нельзя отделить

Отдельный локальный контур нужен, если задача модели зависит от тех сведений, которые политика запрещает передавать дальше. Попытка замаскировать их либо ломает результат, либо оставляет достаточно контекста для восстановления.

К таким задачам относятся разбор платежных поручений, объяснение конкретной блокировки, анализ цепочки транзакций, подготовка ответа по спорной операции и работа с полным кредитным досье. Модели нужны участники, последовательность, суммы и документы. Если убрать связи, она перестает решать задачу. Если сохранить связи, поток остается чувствительным.

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

Есть пограничные случаи, где шлюз и удаленная модель допустимы. Например, модель правит стиль заранее очищенного шаблона, классифицирует синтетические обращения или суммирует агрегат, в котором проверена достаточная группа. Здесь приложение отсекает вложения, отправляет только разрешенные поля и не дает модели инструментов для доступа к банковским системам.

Для RU LLM можно выбирать между маршрутизацией запросов через единый OpenAI-совместимый шлюз и размещенными на собственной GPU-инфраструктуре open-weight моделями в российских ЦОДах. Это не отменяет классификацию: банк все равно должен закрепить для каждого маршрута допустимые классы данных, хранение логов и доступные инструменты.

Решение удобно принимать по двум осям: обратимость данных и необходимая модели связность. Необратимо агрегированные данные с низкой связностью допускают более широкий маршрут. Обратимые токены требуют управляемого хранилища. Полные документы и связанные операции уходят в локальный контур. Неизвестный формат или неизвестная категория всегда закрывают маршрут до разбора.

Политика должна управлять всем запросом

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

Ниже сокращенный фрагмент, который можно адаптировать к своему шлюзу. Он не привязан к конкретному продукту, зато показывает обязательную логику отказа:

policy: bank-secret-v3
default: deny
inputs:
  text:
    normalize: true
    detectors: [account, card, person, company, transaction]
  attachments:
    allow: [pdf, png, jpeg]
    require_extraction: true
    on_parse_error: deny
  history:
    rescan_full: true
routes:
  external:
    allow_classes: [public, synthetic, aggregated]
    tools: deny
    request_logging: metadata_only
  local:
    allow_classes: [confidential, bank_secret]
    tools: allowlisted
output:
  scan: buffered
  on_secret: block

Здесь default: deny важнее длинного списка детекторов. Новый тип вложения, новое поле SDK или неизвестный инструмент не проходит по умолчанию. rescan_full закрывает ошибку, при которой клиент повторно добавляет старую историю после проверки. metadata_only означает заранее заданный набор технических полей, а не обещание «не писать тело» при сохраненном дампе ошибки.

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

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

На выходе лучше требовать JSON Schema там, где ответ запускает действие. Схема ограничивает места, в которых допустимы токены и реквизиты, но не очищает текст автоматически. Свободное поле comment по-прежнему может содержать весь исходный документ, поэтому для него нужен фильтр или полный запрет.

Кэш и RAG создают новые копии секрета

Prompt caching, семантический кэш и RAG надо включать в схему обработки как отдельные хранилища. Запрос может пройти маскирование на основном маршруте, а исходный документ уже окажется в индексе, кэше клиента или очереди подготовки контекста.

Prompt caching сохраняет повторно используемый префикс запроса для экономии вычислений. Если системный промпт содержит реальные примеры обращений либо приложение ошибочно включает в стабильный префикс историю клиента, секрет живет дольше одного вызова. Команда должна знать, на какой стороне создается кэш, как изолируются арендаторы, что попадает в ключ, сколько хранится запись и можно ли удалить ее адресно. Фраза «провайдер не обучает модель на запросах» не отвечает ни на один из этих вопросов.

Семантический кэш опаснее тем, что ищет похожие запросы, а не точное совпадение. Ответ для одной операции может вернуться другой, если векторное расстояние оказалось достаточно малым, а фильтр области доступа потерялся. Ключ кэша должен включать арендатора, пользователя или роль, процесс, класс данных, версию политики и набор разрешений. Для банковской тайны безопаснее вовсе не кэшировать ответы с конкретными операциями, чем пытаться подобрать универсальный порог сходства.

RAG добавляет этапы разбиения документа, построения embeddings, хранения фрагментов и выдачи найденного контекста. Embedding нельзя считать гарантированно обезличенным только потому, что человек не читает его как текст. Он производен от исходного документа, используется для поиска этого документа и иногда допускает атаки на принадлежность или реконструкцию признаков. Поэтому векторный индекс наследует класс защиты источника, пока отдельная оценка не докажет другое.

Контроль доступа применяют до поиска и после него. До поиска система ограничивает коллекции и строки по полномочиям вызывающего процесса. После поиска она снова проверяет каждый фрагмент, потому что ошибка индексации могла поместить документ не в тот раздел. Инструкция в промпте «не показывай чужие данные» не заменяет фильтр доступа: модель уже получила эти данные в контексте.

Удаление также должно проходить по всему графу производных данных. Если банк удалил документ или отозвал доступ, надо убрать фрагменты, embeddings, записи семантического кэша, временные файлы и задания повторной индексации. Полезно хранить техническую связь source_id -> chunk_id -> embedding_id -> cache_entry, не записывая секрет в сам журнал. Без такой связи команда не сможет подтвердить удаление и будет вынуждена очищать весь индекс.

При изменении политики старые записи нельзя автоматически считать соответствующими новой версии. Кэш, созданный до запрета определенного класса, продолжит отдавать результат без нового вызова шлюза. Версия политики входит в ключ, а устаревшие записи инвалидируются. Для RAG нужна повторная классификация источников либо закрытие коллекции до миграции.

Аудит должен доказывать путь данных

Аудит нужен не для накопления копий секретов, а для ответа на конкретные вопросы: какая политика сработала, что она проверила, какой маршрут выбрала и кто одобрил исключение. Лог с полным телом запроса ради расследования создает вторую неконтролируемую базу банковской тайны.

Храните идентификатор запроса, версию политики, классы срабатываний, хеш артефакта, результат разбора каждой части, выбранный маршрут, модель, разрешенные инструменты и итог действия. Для хеша нужна документированная схема канонизации, иначе один и тот же JSON даст разные значения из-за порядка полей. Сам секрет в журнале не нужен.

Статья 19 152-ФЗ прямо говорит об установлении правил доступа, регистрации и учете действий с персональными данными. Это хороший минимум для проектирования доказательств, но банковскому процессу надо добавить решение о маршруте и историю исключений. Положение Банка России № 821-П регулирует защиту информации при переводах денежных средств. Его требования нельзя заменить отчетом детектора PII, потому что объект контроля шире одного текстового поля.

Исключение оформляют на срок, процесс и категорию данных. Запись «разрешить команде риска» слишком широка. Нужны владелец, причина, компенсирующие меры, дата окончания и тест, после которого исключение убирают. Постоянный bypass быстро становится самым популярным маршрутом.

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

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

Граница строится по последствиям пропуска

Банк может использовать маскирование PII как один слой, если данные уже классифицированы, все части запроса разобраны, косвенные идентификаторы проверены, маршрут ограничен, а журналы не создают новую копию секрета. Формулировка «мы маскируем PII» без этих условий описывает функцию, а не защиту банковской тайны.

Ответственность также не переезжает к поставщику вместе с запросом. Часть 5 статьи 6 152-ФЗ сохраняет ответственность оператора перед субъектом, когда обработку поручают другому лицу. Договор должен определить операции, цели, конфиденциальность, меры защиты, уведомление об инцидентах, удаление и подтверждение исполнения. Для банковской тайны юристы отдельно проверяют основание и режим передачи, а команда безопасности сверяет договор с техническим маршрутом.

Хорошая граница запрещает то, чего система пока не умеет доказуемо обработать. Неизвестное вложение блокируется. Новый инструмент не получает доступ автоматически. Токен нельзя восстановить вне утвержденного поля. Запрос с полной связной операцией идет в локальную модель, даже если детектор уверенно закрасил имя.

Самая полезная первая проверка для действующего шлюза проста: поместите разные синтетические маркеры во все каналы одного запроса и проследите их до резервных копий. Если команда не может показать судьбу каждого маркера, она пока не знает границу обработки. Маскирование в такой схеме дает удобную зеленую метку, но не дает основания выпускать банковскую тайну из контура.