Обезличивание данных для ИИ в браузере: разбор Docx Anonymizer

Независимый разработчик выложил Docx Anonymizer — расширение для Chrome, которое выполняет обезличивание данных для ИИ прямо на компьютере: имена и организации в договоре маскируются до того, как текст попадёт в публичный чат. Расширение не делает ни одного сетевого запроса. Этим оно и отличается от облачных сервисов обезличивания, которые сами получают оригинал документа.

Почему договор вообще оказывается в публичном чате?

Потому что так быстрее. Юристу или менеджеру нужен разбор рисков договора за минуту, а корпоративного ИИ-сервиса нет или им неудобно пользоваться. Автор проекта, который публикуется на Habr под ником argmaster-dev, приводит три примера масштаба проблемы. Источники у всех трёх раскрыты слабо.

• 38–57% сотрудников, по зарубежным опросам, признают, что вставляли конфиденциальные данные в публичные нейросети, причём часто с личных аккаунтов, о которых работодатель не знает. Названий опросов, стран и размеров выборок в статье нет.
• В 30 раз, по телеметрии ГК «Солар», в 2025 году вырос объём корпоративных данных, которые уходят в публичные нейросети, в том числе юридических документов. Методику автор не приводит.
• Летом 2026 года, по словам автора, суд первой инстанции в Москве признал законным увольнение директора по продажам за разглашение коммерческой тайны. Среди прочего она загружала внутренние отчёты в DeepSeek. Во взыскании «золотого парашюта» на 5 млн ₽ суд отказал. Номер дела не назван, поэтому для собственной аргументации судебный акт придётся найти по картотеке.

Третий пример важнее первых двух. Обычно этот риск обсуждают в терминах штрафов по 152-ФЗ. Но увольнение за разглашение коммерческой тайны прямо предусмотрено подп. «в» п. 6 ч. 1 ст. 81 ТК РФ — при условии, что в компании введён режим тайны, а сотрудник имел к ней допуск.

Иначе говоря, утечка в нейросеть касается не только персональных данных. Она ведёт к трудовым и гражданским спорам и затрагивает отчёты, цены и ноу-хау.

Почему облачное обезличивание данных для ИИ само становится каналом утечки

Облачный сервис обезличивания получает документ целиком, до маскирования, поэтому для компании он ещё один внешний получатель данных. По ст. 3 152-ФЗ обработка персональных данных — это не только хранение, но и сбор, использование, передача и само обезличивание. Отправка договора в сторонний сервис «подчистить ФИО» уже сама по себе может считаться передачей третьему лицу.

Поэтому автор с самого начала поставил жёсткие условия. Расширение не делает сетевых запросов, не использует сервер и телеметрию, код открыт для проверки. Устанавливать его можно и без Chrome Web Store: вопрос публикации там автор оставил открытым.

Docx Anonymizer написан на JavaScript. Он перехватывает текст на странице ИИ-чата и маскирует его до отправки. Отдельное приложение и цикл «экспортировал, почистил, вставил» автору не подошли: сотрудники в спешке всё равно обходят его стороной.

У такой архитектуры есть оговорка, о которой нельзя забывать. «Без сети и телеметрии» описывает конкретную сборку, а не проект навсегда. Если расширение попадёт в Web Store, обновления могут поменять код, разрешения и сетевое поведение. Открытый репозиторий тоже не доказывает, что установленный пакет собран из того же кода. Для корпоративного использования нужна проверенная и закреплённая версия с контролем обновлений.

Можно ли вычистить стороны договора регулярными выражениями?

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

У правил нашлись два вида ошибок. Ложные срабатывания безобидны, ведь данные никуда не уходят: например, «Алиса AI» распознавалась как имя. Пропуски серьёзнее. В письмах, презентациях и коммерческих предложениях нет формулы «в лице генерального директора», и правило просто не срабатывает.

Для защиты от утечки это худший вариант ошибки: лишняя маска портит ответ модели, а пропущенное название компании уходит в чат. Поэтому в продукте появилась нейросеть. Без контекста нельзя понять, что «Ромашка» в середине абзаца — контрагент, а не цветок.

Как русская NER-модель поместилась в расширение браузера

Автор взял rubert-tiny2, компактный русский BERT под лицензией MIT, дообучил его и сжал до ONNX-файла на 30 МБ. Модель работает в одном потоке WASM внутри воркера расширения, без GPU. Холодный старт занимает около 0,3 с, договор на 20 страниц обрабатывается примерно за 1,7 с. Бюджет задали заранее: всё расширение не больше 75 МБ, модель не больше 45 МБ.

Обучение шло на игровом ноутбуке с 8 ГБ дискретной видеопамяти и 16 ГБ ОЗУ. В первом раунде качество распознавания организаций (ORG) упёрлось в F1 0,71–0,74 при планке 0,75. Подбор learning rate, числа эпох, label smoothing и размера батча не помог.

Плато преодолели дистилляцией. Учитель xlm-roberta-base достиг 0,805 по ORG, а ученик rubert-tiny2 обучался на жёстких метках вместе с мягкими вероятностями учителя и вышел на 0,76.

Конвейер выглядит так: обучение, экспорт в ONNX (opset 17), квантование в int8, сверка с PyTorch и калибровка порога уверенности на 0,7. Условие сверки: прогнозы int8-версии должны совпадать с исходной моделью минимум на 99% токенов.

Стандартный quantize_dynamic дал только 98,1%: на всю таблицу эмбеддингов он использует один общий масштаб, и выбросы одного вектора портят соседние. Автор собрал построчное uint8-квантование эмбеддингов из стандартных операторов Gather, Cast, Mul и Add. Совпадение выросло до 99,7%, точность упала на 0,3%.

Набор операторов выбран ради переносимости: такая модель запустится в ONNX Runtime, TFLite, TensorRT или на голом CPU в браузере, а в перспективе и на телефоне. Файл уменьшился со 111 до 30 МБ, примерно в 3,7 раза. Это близко к теоретическим 4× при конвертации float32 в uint8 и подтверждает, что основной вес модели приходится на эмбеддинги.

Почему организации даются модели тяжелее, чем фамилии

У названий юрлиц нет устойчивой формы. Это и кавычки трёх видов, и капс, и аббревиатуры, и названия продуктов, которые выглядят как компании. Модель, обученная только на WikiANN (по 20 тыс. предложений на русском и английском), этого разнообразия не видела и на договорах давала ORG 0,23.

Автор добавил 10% синтетики по шаблонам: правовые формы с тремя стилями кавычек, ФИО в четырёх падежах, инициалы до и после фамилии, «ИП» перед именем вне границ сущности. Добавились и отрицательные примеры вроде «Заказчик» и названий должностей. Итог первого раунда на тесте WikiANN ru: PER 0,915, ORG 0,760, LOC 0,862, на английском PER 0,81.

Но на реальном коммерческом предложении 46 из 49 находок модели оказались «организациями», и почти все были ложными: заголовки капсом («ВХОДИТ», «05 Цены»), аббревиатуры ЭДО и MVP, Word и Excel. Во втором раунде данные собрали так:

• WikiANN ru/en, по 20 тыс. предложений;
• factRuEval-2016 с двойным весом: около 4 900 предложений новостей и аналитики не из Википедии, лицензия MIT;
• около 35% синтетики по десяти деловым жанрам (КП, письма, счета и УПД, инструкции, резюме, переписка в чатах, акты сверки, презентации и др.), сгенерированной с помощью Claude.

Около трети синтетики составили предложения вообще без сущностей, размеченные как «не сущность»: капс, аббревиатуры, продукты, должности. Все имена из тестового корпуса из синтетики удалили, чтобы не завысить оценку. Nerus, RuREBus, NEREL, WikiNEuRal и MultiCoNER пока не использовали — в основном из-за неясных лицензий.

* Автор не уточняет, как собран тестовый набор деловых жанров. Если это та же синтетика от Claude, что и в обучении, скачок с 0,47 до 0,99 может быть завышен: модель проверяют на текстах того же генератора и тех же шаблонов. Удаление имён из синтетики от этого не страхует.

Показательнее строка factRuEval: это реальные новости, и ORG там вырос с 0,412 до 0,704. Размер, скорость и формат пакета не изменились, поэтому код расширения между версиями не трогали, сменилась только модель. F1 считается по размеченной выборке и не говорит, найдутся ли все стороны в вашем договоре. Для утечки достаточно одного пропуска.

Что маскирование не закрывает, даже если работает идеально

Маскирование скрывает имена и названия, но не делает документ безопасным и не означает соответствия 152-ФЗ. Автор сам перечисляет ограничения:

• ORG остаётся самым хрупким классом, и на незнакомых жанрах возможны пропуски. Если для вас важно скрывать названия организаций, результат нужно проверять вручную;
• PDF с текстовым слоем обрабатывается, сканы не поддерживаются;
• инструмент не заменяет внутреннюю политику использования ИИ и, по словам автора, «не индульгенция».

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

Есть и требования, которые маскирование одного запроса не затрагивает вообще. Ч. 5 ст. 18 152-ФЗ требует, чтобы запись, систематизация, накопление и хранение персональных данных граждан РФ при сборе велись в базах на территории РФ. Это вопрос всей схемы работы с данными, а не одного промпта.

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

Что проверить, прежде чем пускать такой инструмент в компанию

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

1. Пути утечки. Перехват ввода на странице не обязательно покрывает загрузку файла, drag-and-drop, историю чата и подключённые к ИИ плагины. Проверьте каждый путь отдельно.
2. Сборка. Сравните установленный пакет с репозиторием argmaster-dev/docx-anonymizer на GitHub: manifest, permissions и host_permissions, Content Security Policy, наличие fetch/XHR/WebSocket, загрузку внешних WASM/ONNX, механизм обновления. Закрепите проверенную версию.
3. Пилот на своих документах. Разметьте вручную 30–50 реальных документов разных жанров и считайте прежде всего пропуски, а не ложные срабатывания. В отчёт включите примеры пропущенных фрагментов.
4. Политика. Составьте разрешённый список ИИ-сервисов, классификацию данных, которые туда нельзя отправлять даже обезличенными, и порядок действий, если документ уже ушёл. На этот случай сохраняйте URL сервиса, время, аккаунт, идентификатор чата и состав документа.
5. Технические контроли. Локальный инструмент работает в связке с DLP/CASB и журналированием, а не вместо них.
6. Режим коммерческой тайны. Убедитесь, что он формально введён и сотрудники с ним ознакомлены. Без этого история с DeepSeek для работодателя могла закончиться иначе.

Соответствует ли схема работы с ИИ 152-ФЗ, покажет независимый аудит соответствия 152-ФЗ. Если у вас собственный ИИ-ассистент или RAG по внутренним документам, его стоит отдельно проверить на утечки через промпты: это задача для пентеста LLM-приложений.

Что пока неизвестно

Главное для корпоративного внедрения: независимого аудита сборки нет. Цифры о масштабе shadow AI в статье не подкреплены источниками — нет названий опросов, методики «Солара» и номера судебного дела. Не раскрыт и состав тестового набора деловых жанров, на котором получено 0,99.

Автор планирует добавить Nerus и NEREL, если разберётся с их лицензиями, и подтянуть английский, где PER пока 0,81. Он принимает issue и pull request, в том числе с документами, на которых модель ошибается, и с новыми жанрами синтетики. Компаниям с англоязычными контрактами стоит дождаться этих улучшений или заложить ручную проверку.

Частые вопросы

Уходит ли текст договора на сервер автора расширения?

По архитектуре нет: расширение не делает сетевых запросов, не использует сервер и телеметрию. Это свойство конкретной сборки, поэтому компании нужна проверенная и закреплённая версия с контролем обновлений.

Можно ли после обезличивания загружать договор в ChatGPT без проверки?

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

Заменяет ли Docx Anonymizer политику использования ИИ?

Нет, автор прямо называет инструмент «не индульгенцией». Политика определяет разрешённые сервисы, запрещённые классы данных и порядок действий при утечке, а расширение — только один из технических контролей.

Работает ли обезличивание на скане PDF?

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

Чем локальное обезличивание лучше облачного?

Облачный сервис получает документ до маскирования, то есть становится ещё одним получателем данных. По ст. 3 152-ФЗ такая передача уже считается обработкой персональных данных. Локальное расширение маскирует текст на устройстве, и оригинал никуда не уходит.

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