Почему обычной маскировки недостаточно, зачем нужна обратимость, как сохранить смысл чисел и почему суммы нельзя просто заменить случайными? Написали обработку, которая действительно заменяет персональные и платёжные реквизиты перед отправкой в модель и затем умеет расшифровать ответ обратно.
В прошлой статье мы разбирали, как передать копию базы 1С подрядчику без реальных персональных данных.
Но есть более локальный сценарий: базу передавать не нужно, а вот отдельную выгрузку хочется отдать нейросети на анализ.
Например, попросить:
разобрать дебиторскую задолженность;
найти аномалии;
сгруппировать контрагентов;
объяснить расхождения;
рассчитать график платежей.
Проблема в том, что в такой выгрузке будут ФИО, ИНН, счета, телефоны и реальные суммы.
ООО "Альфа" Иванов Сергей Петрович ИНН 7701234567 р/с 40702810... Долг: 8 587 500,00
Просто копировать это в ChatGPT, Claude или YandexGPT нельзя. Можно заранее заменить реквизиты вручную. Но тогда возникает другая проблема: как потом читать ответ модели и понимать, кто скрывается за выдуманными именами и цифрами?
Поэтому здесь нужна не просто маскировка, а обратимая псевдонимизация текста.
Схема выглядит так:
1С | v выгрузка | v псевдонимизация | v нейросеть | v ответ модели | v обратная замена | v ответ с настоящими данными
Обработка работает только с тем текстом, который пользователь ей передал. Самостоятельно во внешние сервисы она ничего не отправляет.
Почему случайной замены недостаточно
Возьмем таблицу:
Контрагент Менеджер Долг ООО "Вектор" Иванов И.И. 1 200 000 ООО "Сфера" Иванов И.И. 800 000 ООО "Альфа" Петров П.П. 300 000
Если каждое вхождение Иванов И.И. заменить независимо, модель решит, что первые две строки относятся к разным менеджерам.
Поэтому действует простое правило:
одно исходное значение получает один и тот же псевдоним во всей выгрузке.
Это сохраняет связи, группировки и смысл данных. В реальной выгрузке 1С чувствительных значений гораздо больше, чем ФИО.
Обработка ищет:
ФИО и организации;
ИНН, ИИН, БИН;
ОГРН, ОГРНИП, КПП;
банковские счета, БИК, IBAN;
номера карт;
паспортные данные и СНИЛС;
телефоны и email;
даты рождения и адреса;
автомобильные номера;
денежные суммы.
При этом задача не сводится к простым регулярным выражениям.
Например, ИНН можно проверять по контрольной сумме, банковскую карту — по алгоритму Луна, а email заменять адресом на example.com.
Псевдоним желательно делать не просто случайным, а структурно похожим на оригинал.
Например:
ИНН 7707083893
превращается не в набор случайных цифр, а в другой номер с корректной контрольной суммой. Это полезно, если данные потом обрабатывает не только нейросеть, но и промежуточный парсер или другой инструмент.
Самая интересная часть — суммы
С ФИО все просто:
Иванов -> Соколов ООО "Вектор" -> ООО "Горизонт"
С деньгами сложнее. Если оставить реальные суммы — чувствительные финансовые данные уйдут наружу. Если заменить каждую сумму случайным числом — модель потеряет пропорции:
1 000 000 -> 832 451 2 000 000 -> 174 992 5 000 000 -> 681 357
После такой замены уже нельзя корректно определить, кто должен больше, посчитать доли или найти выбросы. Поэтому все денежные суммы в одной сессии умножаются на один секретный коэффициент.
Условно:
k = 1.73 1 000 000 -> 1 730 000 2 000 000 -> 3 460 000 5 000 000 -> 8 650 000
Абсолютные значения изменились, но сохранились:
отношения;
доли;
порядок;
динамика;
выбросы.
Это позволяет модели анализировать данные почти так же, как исходные.
Почему это позволяет восстановить даже новые расчеты модели
Допустим, мы передали модели измененную сумму и попросили рассчитать ежемесячный платеж. Ответ содержит число, которого раньше вообще не было:
Ежемесячный платеж: 858 870
Обычный словарь замен здесь не поможет: такого значения в нем нет. Но если все денежные значения были умножены на один коэффициент, результат можно преобразовать обратно тем же правилом. Именно поэтому после обратной обработки восстанавливаются не только исходные суммы, но и часть значений, которые модель рассчитала сама. Это одна из главных причин использовать коэффициент, а не случайную замену чисел.
Почему нельзя умножать вообще все числа
Потому что:
НДС 20%
после такой обработки может превратиться, например, в:
НДС 34,6%
и модель сделает неверный вывод.
Поэтому специально не меняются:
проценты;
количества;
даты документов;
номера договоров;
артикулы и коды;
версии платформы;
счета учета вида
20.01.1.
Идея в том, чтобы изменить только то, что действительно нужно скрыть, и максимально сохранить смысл исходных данных.
Обратимость
После анализа модель возвращает ответ уже с псевдонимами:
ООО "Орион" имеет максимальную задолженность. Соколов А.А. отвечает за 42% просроченных платежей.
Обработка прогоняет этот текст через словарь в обратную сторону:
ООО "Орион" -> ООО "Альфа" Соколов А.А. -> Иванов И.И.
И пользователь читает ответ уже с настоящими именами и реквизитами. Без этого псевдонимизация решает только половину задачи.
Где хранить словарь замен
Можно было бы сохранять его в отдельный файл:
mapping.json
Но такой файл фактически является ключом к деанонимизации.
Его можно потерять, случайно отправить вместе с выгрузкой или оставить в общей папке. Поэтому словарь сохраняется средствами самой 1С в стандартном хранилище настроек и привязывается к пользователю. Обработку можно закрыть, перезапустить 1С и вернуться к ответу модели позже. Если словарей несколько, нужный определяется по совпадениям псевдонимов в тексте ответа.
Как выглядит рабочий сценарий
Исходная выгрузка:
Контрагент: ООО "Альфа" Менеджер: Иванов Сергей Петрович ИНН: 7707083893 Долг: 8 587 500,00 Срок просрочки: 94 дня
После обработки:
Контрагент: ООО "Орион" Менеджер: Соколов Алексей Андреевич ИНН: 7721000120 Долг: 13 645 537,50 Срок просрочки: 94 дня
Этот текст можно отправить модели, например с запросом:
Найди основные риски по дебиторской задолженности и предложи график погашения.
После получения ответа он вставляется обратно в обработку, и настоящие имена, реквизиты и суммы возвращаются.
Где заканчивается автоматика
Здесь есть несколько важных ограничений. Во‑первых, это не DLP‑система. Инструмент работает только с тем текстом, который пользователь ему дал. Во‑вторых, гарантированно найти вообще все чувствительные данные невозможно.
Например:
Клиент красный-47
может быть внутренним обозначением конкретного человека, но универсальный алгоритм об этом не узнает. Поэтому результат перед отправкой все равно нужно проверять глазами. Есть и еще одно ограничение: если модель сама изменила формат числа или округлила его:
8 587 500,00 -> около 8,6 млн
точные копейки восстановить уже невозможно. Их просто больше нет в тексте.
Почему это именно псевдонимизация
Если существует словарь:
Соколов -> Иванов ООО "Орион" -> ООО "Альфа"
данные остаются обратимыми. Поэтому речь идет именно о псевдонимизации, а не о полной анонимизации. Это сделано сознательно: без обратимости мы не смогли бы вернуть настоящие данные в ответ нейросети.
Совместимость
Технические требования здесь довольно мягкие:
платформа 1С 8.3.14 и выше;
любая конфигурация, включая самописную;
управляемые формы;
файловая и клиент‑серверная база;
тонкий и толстый клиент;
достаточно прав на чтение.
Обработка не изменяет данные информационной базы и использует платформенные методы.
Две задачи — два разных сценария
В прошлой статье мы решали задачу:
база -> псевдонимизация -> копия подрядчику
Здесь задача другая:
выгрузка -> псевдонимизация -> нейросеть -> ответ -> обратная замена
То есть иногда нужно защищать целую копию базы, а иногда — только небольшой фрагмент данных перед конкретной операцией.
Что в итоге
На первый взгляд задача звучит просто:
Как отправить таблицу из 1С в нейросеть, не отправив реальные ФИО и реквизиты?
Но на практике мало просто заменить Иванова на Петрова.
Нужно:
сохранять связи между одинаковыми значениями;
генерировать структурно корректные реквизиты;
не ломать числа, которые важны для анализа;
скрывать суммы с сохранением пропорций;
уметь преобразовывать обратно результаты расчетов модели;
хранить словарь соответствий без ручной работы пользователя;
понимать границы автоматического распознавания.
И главный принцип здесь тот же, что и в случае с копией базы:
Псевдонимизация полезна только тогда, когда после нее данные сохраняют свойства, ради которых мы хотим их анализировать.
Для ФИО это связи. Для реквизитов — структура. Для денежных значений — пропорции. Для ответа нейросети — возможность пройти весь путь обратно и снова увидеть реальные данные.
