Маскирование данных: что скрывать перед передачей документов в ИИ

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

Главный принцип — передавать минимум данных, достаточный для обработки. Автоматический поиск помогает применить правила, но не отменяет контроль результата: детектор может не распознать необычную запись или скрытый элемент документа.

Какую задачу решает маскирование перед ИИ

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

Так работает минимизация: команда оставляет только сведения, без которых задача потеряет смысл. Это снижает возможное раскрытие данных, но не даёт абсолютной гарантии. Даже без прямых идентификаторов сочетание должности, редкой сделки и даты иногда позволяет повторно идентифицировать человека или организацию.

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

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

Какие поля и скрытые места проверить

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

Проверяйте документ целиком:

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

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

Как выбрать удаление, замену и токенизацию

Способ зависит от того, должен ли текст сохранять структуру и нужно ли позднее восстановить исходное значение.

Удаление подходит, когда поле не нужно для задачи: например, телефон не влияет на определение типа договора. Устойчивая замена полезна, если важно видеть повторение участника в разных пунктах: ФИО можно заменить на PERSON_01. Обратимая токенизация нужна только тогда, когда существует обоснованный процесс восстановления значения.

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

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

Официальная документация Google Cloud Sensitive Data Protection описывает работу с текстом и таблицами и преобразования для маскирования, удаления, замены токеном и шифрования. Это подтверждает доступные классы преобразований в указанном сервисе, но не означает его проверку на документах конкретной компании или совместимость с её форматами и правами.

Как построить проверяемую обработку

Разделите процесс на четыре этапа:

1. Обнаружение. Система и заданные правила ищут запрещённые типы данных во всех предусмотренных частях документа.
2. Применение правил. Каждое найденное значение удаляется, заменяется или токенизируется согласно утверждённой матрице.
3. Контроль. Сотрудник проверяет полноту преобразований и то, что документ сохранил нужный смысл.
4. Разрешённая передача. Материал отправляется дальше только после успешного контроля и регистрации статуса.

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

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

Что делать с ошибками и журналами

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

Журнал подтверждает ход операции, но не превращается в копию исходника. В нём можно сохранить:

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

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

Учебный пример маскирования условного договора

Ниже — синтетический пример, а не клиентский документ, файл Switch On AI или результат испытания продукта. Все значения вымышлены специально для демонстрации.

В основном тексте условного договора указаны «Марина Тестова», телефон +7 000 000-00-00, счёт 0000 0000 0000 0000 0000 и внутренний код DEMO-042. Тот же код DEMO-042 повторяется в нижнем колонтитуле.

Заданный перечень содержит пять чувствительных вхождений: одно ФИО, один телефон, один счёт и два вхождения внутреннего кода. Учебная автоматическая обработка основного текста находит четыре: 1 + 1 + 1 + 1 = 4. Полнота до ручной проверки равна 4 / 5 × 100% = 80%.

Сотрудник просматривает колонтитул, находит второе вхождение DEMO-042 и заменяет его на INTERNAL_01. После исправления обработано пять из пяти заранее известных вхождений: 5 / 5 × 100% = 100%. В журнале остаётся: автоматически обнаружено 4, при ручной проверке добавлено 1, всего преобразовано 5, остаток по заданному перечню — 0.

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

Как принять процесс и обсудить внедрение

Приёмка включает две независимые проверки. Первая — полезность: после преобразования понятны стороны как роли, предмет договора, обязательства и связи между пунктами. Вторая — безопасность передачи: во всех проверяемых областях отсутствуют поля, запрещённые утверждённым перечнем, включая колонтитулы, изображения и метаданные.

Зафиксируйте для приёмки:

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

Успешная техническая проверка не является правовым выводом об обезличивании. Бухгалтерские, юридические, кадровые и отраслевые правила задаёт и принимает специалист заказчика.

Switch On AI может разобрать одну операцию и спроектировать для неё ИИ-помощника, бота или интеграцию после проверки данных, доступных API и прав. Подходящий формат зависит от поведения процесса: фиксированную последовательность выполняет обычная автоматизация, диалог даёт бот, а выбор следующего разрешённого действия может потребовать ИИ-агента. Подробнее — на странице разработки ИИ-агентов.

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