Обезличивание данных 1С: от выгрузки для нейросети до копии базы подрядчику

Обезличивание данных 1С встречается в двух разных задачах, и путать их дорого. Первая: отдать выгрузку чат-модели и получить осмысленный ответ, не сливая наружу ФИО и суммы. Вторая: отдать подрядчику или тестировщику копию боевой базы целиком. Механизм в обеих один, а грабли разные, и вторая задача ломается ровно там, где первая работает.

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

Задача первая: выгрузка для чат-модели

Задача звучит заманчиво: скормить нейросети выгрузку из 1С и спросить, кто ваш крупнейший должник, какая доля выручки приходится на топ-контрагента, где аномалия в оборотах. Модель это умеет. Проблема в том, что в выгрузке лежат ФИО, БИН, названия организаций, реальные суммы, и отправлять их наружу, в чужой сервис, нельзя ни по здравому смыслу, ни по регламенту безопасности многих компаний.

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

Короткая версия этого разбора, про легенду обезличивания и почему “удалить ФИО” не спасает, лежит на Инфостарте.

Почему “просто удалить” не работает

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

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

Обратимость: обезличили, спросили, расшифровали ответ

Схема из трёх шагов:

1. Перед отправкой проходим выгрузку и заменяем чувствительное на маркеры: ООО Ромашка становится, скажем, ORG_014, ФИО становится PERSON_003, суммы масштабируются на секретный коэффициент. Соответствие маркер → настоящее значение остаётся у вас, наружу не уходит.
2. Отправляем в модель обезличенный текст и вопрос. Модель считает, ищет, сравнивает, ей для этого настоящие имена и не нужны, ей нужна структура и относительные величины.
3. Ответ модели приходит с маркерами: “наибольшая доля у ORG_014, это 54,2 %”. Прогоняем ответ через тот же словарь в обратную сторону, и ORG_014 превращается обратно в реальное название, а масштабированные суммы в настоящие.

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

Первый урок: коэффициент масштабирования обязан быть больше единицы

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

При обратном пересчёте вы делите на коэффициент. Если коэффициент меньше единицы, деление это умножение на большое число, и любая ошибка округления, накопленная по пути (модель округлила процент, где-то потерялся знак), домножается на 1/k и раздувается. При k = 0,2 ошибка растёт в пять раз. Результат уезжает, и вы этого даже не заметите, потому что цифры выглядят правдоподобно.

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

Второй урок: один прогон через живую модель стоит десятков синтетических тестов

Обезличиватель мы покрыли автотестами: генерируем данные, обезличиваем, расшифровываем обратно, проверяем, что вернулось исходное. Тесты прошли десятки раз подряд, всё зелёное.

А потом мы прогнали связку через живой ChatGPT на настоящей обезличенной выгрузке. Модель нашла правильного контрагента, посчитала его долю выручки в 54,2 %, после расшифровки доля осталась та же, имя и суммы настоящие. И вот тут вылез дефект, который автотест не видел за 72 прогона: значение 54,2 в ответе модели выглядело как денежная сумма, попадало под правило обратного пересчёта и делилось на коэффициент. Процент превращался в мусор.

Автотест этого не поймал по простой причине: он проверял то, что мы придумали проверить, а придумать “модель вернёт процент, который спутается с суммой” мы не догадались. Живая модель повела себя так, как синтетика не воспроизводила.

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

То же самое повторилось на масштабе целой базы. Про это вторая половина статьи.

Что можно и нельзя скормить

Подход рассчитан на табличные выгрузки: остатки, обороты, реестры документов, где есть колонки с именами, БИН, суммами. Их он обезличивает и расшифровывает надёжно.

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

Как это выглядит на практике

Собирать словарь замен, масштабировать суммы, разбирать ответ модели обратно руками каждый раз это отдельная морока, где легко ошибиться на обеих границах. Мы собрали обработку “Анонимизатор выгрузки 1С PRO”: она обезличивает выгрузку 1С перед отправкой в чат-модель и расшифровывает ответ обратно, с учётом обоих уроков выше (коэффициент больше единицы, защита от спутывания процентов с суммами). Наружу не уходит ни одного настоящего значения.

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

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

Задача вторая: копия боевой базы уезжает наружу

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

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

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

Почему затирание полей не подходит

Очевидные пути перебираются первыми, и все четыре отпадают.

Вариант	Почему не сработало
Пустая или демо-база	Половина задач вслепую не решается: ни объёмов, ни грязи, ни краевых случаев
Доступ к боевой через VPN	Данные всё равно перед глазами, плюс администрирование доступов и чужое неудобное окружение
Ручная зачистка полей	Повторять на каждую копию, ломается ссылочность, и главное - необратимо
Синтетическая генерация	Трудоёмко, и синтетика не воспроизводит те самые краевые случаи, из-за которых баги и возникают

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

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

Первая дыра: поле, которое никто не искал

Класс данных движок сначала определяет по имени реквизита: нашёл в имени ИНН, значит, нужно правило. Первым двум базам этого хватило.

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

Отчёт не соврал: всё, что заменил, перечислил честно. Строки “что я не понял” в нём просто нет.

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

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

Вторая дыра: восемь миллионов кодов, похожих на ИНН

Здесь тот же механизм ошибся в обратную сторону, и всплыло это на оценке времени. До запуска сканер честно выдал прогноз: десятки таблиц, около ста часов работы. Четверо суток. Больше срока нас занимало, откуда столько набралось.

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

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

На этом месте пришлось принять решение, которое нас до сих пор не устраивает.

// Слишком строго - пропустим настоящие персональные данные: в живых базах
// номер с опечаткой не редкость, а он всё равно остаётся номером человека.
// Слишком мягко - обезличим товарные коды.
//
// Разводим по длине. 12 цифр - формат ИНН физлица, посторонние коды такой
// длины встречаются редко, берём даже с несошедшейся суммой.
// 10 цифр - формат ИНН юрлица, но именно в эту длину попадают товарные
// и складские коды, поэтому здесь требуем контрольную сумму.
Если СтрДлина(Цифры) = 12 Тогда
	Возврат Истина;
КонецЕсли;

Возврат КонтрольнаяСуммаСходится(Цифры);

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

Уязвимость у такого решения обнаружилась скоро, причём с неожиданной стороны. Любая торговая база держит в справочнике штрихкодов сотни тысяч кодов UPC-A, а это ровно двенадцать цифр. Так что предположение о редкости посторонних кодов такой длины разбивается о первую же розничную конфигурацию. Выключателя для подмены двенадцатизначных мы так и не сделали, и, похоже, напрасно.

Третья дыра: двадцать четыре тысячи имён на пятьдесят восемь тысяч человек

Эту никто не принял за ошибку. Выглядело так, будто “что-то сломалось”: справочник физлиц пошёл вшестеро медленнее, и скорость так и не вернулась.

На деле ничего не ломалось, просто кончился словарь. Набор, из которого генератор складывал ФИО, конечен: 30 фамилий, 20 имён и 20 отчеств. Сочетаний выходит двенадцать тысяч на пол и двадцать четыре тысячи на всю базу, а живых людей в справочнике 58 124.

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

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

Урок не только про словари: правдоподобная синтетика сама по себе инженерная задача. Словарь мы расширили, а при исчерпании к имени теперь дописывается заметный номер (“Ковалёв Алексей Фёдорович 2”), без тихих дублей. Вид искусственный, зато людей снова можно отличить друг от друга.

Общий диагноз: имя реквизита врёт

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

• ИдентификационныйКодЛичности: по названию персональные данные в нём не угадать;
• справочник товарных кодов: по названию тоже ничего не скажешь, но формат значений сошёл за ИНН;
• справочник новостей: в имени реквизита стоит “ИНН”, хотя хранится там идентификатор записи;
• НаименованиеПолное контрагента-юрлица: по имени ждёшь ФИО, а лежит там название организации. Из двух компаний синтетика сделала граждан с обычными фамилиями.

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

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

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

Двадцать две секунды: грабля не про данные

Дольше всего пришлось отлаживать историю, где данные были ни при чём.

Прогон завершился, но с красным вердиктом: файлы соответствий “не найдены”. Обработка сама показала пользователю путь, и именно по нему их не оказалось. Сами файлы были целы и лежали рядом, в каталоге с разницей в 22 секунды: ...154420 на экране против ...154442 на диске.

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

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

С тем же связан главный инвариант, к которому мы пришли не сразу. Пара “исходное значение - псевдоним” попадает в журнал раньше, чем фиксируется транзакция, записывающая псевдоним в базу. Порядок нарочно такой: обрыв оставит в журнале соответствий лишние строки, а их при возобновлении уберёт дедупликация. Противоположный случай, когда псевдоним уже в базе, а в журнале о нём ни строчки, исправить нечем. Полной гарантии здесь не бывает: у буферизации файла и журнала транзакций СУБД свои законы, а в клиент-серверной схеме они к тому же на разных машинах. Но сторону ошибки мы выбрали осознанно, и этим полдела уже сделано.

Чего обезличивание не закрывает в принципе

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

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

Встроенным языком журнал регистрации не почистить. Никак. Администратор делает это руками: останавливает сервер и удаляет файлы журнала. Оговорюсь: журнал лежит в каталоге кластера отдельными файлами, внутри базы его нет, поэтому ни бэкап СУБД, ни выгрузка dt его не содержат. Риск появляется, только если копию отдают целым каталогом, и тогда вместе с ней к получателю уедут имена живых пользователей и их действия. Что вообще накапливается в этом журнале и как его разгрузить, разобрано отдельно: журнал регистрации 1С разросся.

Практический минимум при передаче базы наружу

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

И отвечать за утечку будет владелец базы, кто бы её ни потерял. Насколько аккуратен подрядчик, тут неважно: разбираться придётся вам. Поэтому всё решается до передачи, выбором того, что вообще отправится наружу.

1. Файл соответствий никогда не едет вместе с копией: ни в общем архиве, ни следующей посылкой.
2. Пароль к нему нигде не записан. Забыли пароль, и обратного хода больше нет.
3. Копию до отправки открывают и осматривают глазами.
4. Для каждой новой копии прогон делается заново: прежний файл соответствий к ней не подходит.
5. Прямой ход и возврат запускаются только в монопольном режиме и при выключенных регламентных заданиях. Если кто-то изменит объект между ходами, восстановить его будет нечем.

Инструмент, которым всё это делалось, вынесен в отдельную публикацию: Анонимизатор базы данных PRO. Он работает по всей базе, в отличие от “Анонимизатора выгрузки” из первой половины статьи, который обезличивает одну таблицу перед отправкой в чат.

Кстати, чувствительной бывает и структура доступа: список сотрудников с их ролями - тоже персональные данные. Если вы разбираете права через чат-модель (как в нашем аудите прав доступа 1С через нейросеть), обезличивание имён пользователей перед отправкой - тот же самый приём.