Синтетические тестовые данные: когда и кому они действительно нужны

Что такое тестовый контур?

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

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

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

Тонкости работы с синтетическими данными в России

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

Следствие простое и обидное: сгенерируете ИНН как двенадцать случайных цифр – на входном валидаторе отвалится примерно 90% записей. Вы будете тестировать не систему, а свой генератор. И узнаете об этом дня через три.

Правила, которые придётся написать самим
Атрибут	Как ломается по умолчанию	Как делать	Источник справочника
ИНН	Случайные цифры не проходят проверку контрольного разряда	Генерировать первые 9 (или 10) цифр, считать контрольные по весовым коэффициентам. Для юрлица — следить, чтобы первые две цифры соответствовали региону из адреса	Алгоритм ФНС, коды регионов
СНИЛС	То же самое плюс забывают про правило «остаток 100 или 101 даёт 00»	Веса 9…1 по девяти цифрам, остаток от деления на 101, особый случай для 100 и 101	Алгоритм СФР
КПП, ОГРН, БИК	Генерируются независимо от ИНН — и получается юрлицо из Владивостока с московским КПП	Генерировать связкой: регион — ИНН — КПП — БИК обслуживающего банка. Связность важнее правдоподобия отдельных полей	Справочник БИК, коды регионов
Номер карты	Алгоритм Луна соблюли, а БИН взяли реальный действующий — и получили номер, который может существовать	Луна плюс БИН из тестовых диапазонов платёжных систем. Никогда не используйте боевые БИН своего банка	Тестовые диапазоны платёжных систем
Номер телефона	Все записи вида +7 999 000-00-00, либо реальные существующие номера — и рассылка из тестового контура уходит живым людям	В России нет зарезервированного диапазона по аналогии с американскими 555. Берите неназначенные диапазоны из реестра нумерации и держите отдельный чёрный список	Реестр российской системы и плана нумерации (открытые данные Минцифры), выгрузки ЦНИИС
Адрес	Готовые локали склеивают случайный город со случайной улицей и случайным индексом. Валидатор адреса такое отбрасывает	Идти сверху вниз по иерархии ФИАС/ГАР: регион — город — улица — существующий дом — индекс этого дома	ФИАС / ГАР
Паспорт	Серия не соответствует региону выдачи, дата выдачи раньше даты рождения, возраст не бьётся с обязательной заменой в 20 и 45 лет	Серия = код региона + год выпуска бланка; проверять правило замены документа по возрасту	Коды регионов
ФИО	Транслит или короткие латинские строки. Ломается сортировка, ширина колонок, поиск	Кириллица, обязательно «ё», двойные фамилии, отчества на -оглы и -кызы, склонения в тех местах, где система их показывает	частотные словари имён
Даты и время	Всё в UTC либо всё в московском времени	Одиннадцать часовых поясов в одной таблице. Отдельно — исторические данные до 2014 года, где был переход на летнее время	tzdata
Календарь нагрузки	Равномерное распределение дат по году	Производственный календарь: провалы 1–8 января и 9 мая, пики перед праздниками, всплеск в дни зарплат (обычно 5-е и 20-е числа)	производственный календарь
Суммы и НДС	Нормальное распределение сумм и одна ставка НДС	Логнормаль плюс «магнит» на круглые суммы (1000, 5000). Ставки 20 / 10 / 0 в правильных пропорциях по видам товаров, банковское округление	—

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

Отдельно про кириллицу – здесь я как-то потерял два дня

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

Три кейса из практики

Три истории для понимания. Компании и цифры изменены из-за NDA, но ситуации повторяются от проекта к проекту.

Кейс первый: процессинг, эквайринг

Стенд был зелёный, но прод лёг через 40 минут после релиза

Что было?

Нагрузочный контур на 1,2 млрд транзакций. Данные сгенерировали честно, но равномерно: мерчантов раскидали поровну по 40 тыс. значений, даты распределили ровно по трём годам. Тесты показывали p99 в 180 мс, релиз выпустили. Через 40 минут после выкатки p99 на проде достиг 4,2 секунды, и дежурная смена откатывала всё вручную.

Что оказалось?

Два распределения оказались сломанными, и казалось, что это мелочи. А ещё была скошенность. В проде 0,4% мерчантов давали 61% трафика. На равномерных данных планировщик оценивал селективность как одну сорокатысячную и выбирал индексный доступ. В проде для горячих мерчантов эта оценка врала в сотни раз, и план запроса разваливался в чтение половины таблицы.

Профиль партиций. Данные равномерно распределены по трём годам, а в проде 70% объёма приходится на последние 90 дней. Горячая партиция на стенде была в 12 раз меньше реальной и целиком помещалась в память.

Что сделали?

Обучили копула-модель на срезе в 30 млн строк – заняло 40 минут, без GPU. Вытащили распределение мерчантов: закон Ципфа с показателем около 1,1, профиль по часам суток, долю возвратов, распределение сумм. Размножили до 1,3 млрд строк на восьми воркерах, добавили 900 записей из каталога патологий и, что оказалось важным, перемешали данные перед загрузкой.

Что стало?

Сравнение стендов «до» и «после»
Показатель	Прод	Стенд «до»	Стенд «после»
p99 на проблемном запросе	4 200 мс	180 мс	3 800 мс
Джини по мерчантам	0,81	0,02	0,79
Доля объёма в последних 90 днях	70%	8%	69%
Размер таблицы на диске	4,1 ТБ	1,6 ТБ	4,0 ТБ
Совпадение планов на топ-50 запросов	—	54%	94%

Дальше всё пошло легче: стенд стал ошибаться в ту же сторону, что и прод. Нашли три проблемных запроса, два переписали, к одному добавили индекс – p99 упал до 240 мс. Генерация 1,3 млрд строк заняла около четырёх часов.

Главный вывод: объём – самая простая и самая неважная характеристика нагрузочного датасета. Врут не терабайты. Врёт скошенность.

Кейс второй: медицинская информационная система

Модель запомнила семь наших маячков – значит, запомнила и пациентов

Что было?

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

Взяли локальную русскоязычную модель на 7 млрд параметров, дообучили на срезе из 2 млн протоколов, сгенерировали 12 млн новых. Метрики похожести – отличные, различимость 0,54. Врачи читали и говорили: выглядит как настоящее.

Что нашли?

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

Вылезло и второе: 0,6% сгенерированных протоколов содержат настоящие названия отделений и фамилии врачей. Их не считали персональными данными – зря. Фамилия врача + отделение + дата – это почти паспорт человека.

Что сделали?

Убрали дубликаты из обучающего среза через MinHash с порогом 0,8 – выкинули 11% записей, в основном шаблонные протоколы. Сократили обучение с 8 эпох до 2: похожесть почти не просела, а запоминание упало резко. Подняли температуру до 0,9, ограничили top-p до 0,92. Добавили пост-фильтр: если запись совпадает с обучающей на 8-грамму длиннее 60 символов – выбрасываем. Теряли около 0,4%, терпимо. Включили фамилии врачей и названия отделений в список замещаемых сущностей.

Что стало?

Маячки перестали появляться на трёх прогонах подряд. Качество поиска на синтетике осталось в пределах 4% от реальных данных – для регрессии годится. Проверка на маячки теперь живёт в CI и занимает восемь минут.

Вывод: без активной проверки на запоминание вы не узнаете, что модель плывёт. Метрики похожести этого не показывают – наоборот, чем сильнее модель запомнила, тем красивее у неё метрики.

Кейс третий: крупный ритейл, 11 систем

60% сквозных тестов падали не из-за багов

Что было?

11 систем: сайт, приложение, CRM, склад, доставка, лояльность, биллинг, поддержка, аналитика и две партнёрские интеграции. Каждая маскировала данные по-своему, со своим ключом. В итоге 8827 клиент в CRM не имел ничего общего с клиентом 8827 в биллинге. Простой сценарий – оформил заказ, оплатил, вернул часть, получил бонусы – разваливался на втором шаге. Команда сквозного тестирования тратила около 60% времени на разбор падений, вызванных не багами, а рассогласованием данных.

Отдельным удовольствием была подготовка окружения: заявка в ИБ, согласование, работа DBA, маскирование, выгрузка – 9 рабочих дней в среднем при двухнедельных спринтах.

Что сделали?

Ввели единый сервис идентичности: псевдоним считается детерминированно через HMAC-SHA256 от натурального ключа сущности с общей солью, соль лежит в защищённом хранилище. Один реальный клиент во всех 11 системах превращается в одного и того же синтетического – без обмена данными и без общей таблицы соответствий.

Второе решение не менее важное: генерировать не поля, а личность целиком. ФИО, телефон, адрес, документы, дата рождения, пол – один согласованный объект, который потом раскладывается по системам. Раньше каждая система генерировала своё, и получался клиент по имени Мария Петрович с мужским обращением в письмах.

Третье: срез вместо полной копии. Обошли граф из 340 таблиц и 1 100 внешних ключей, взяли связный подграф на 2,5% клиентов – 50 ГБ вместо 6 ТБ.

Что стало?

Что изменилось после перехода на синтетику
Показатель	Было	Стало
Падения сквозных тестов из-за данных	60%	4%
Подготовка окружения	9 рабочих дней	40 минут по кнопке
Объём тестового контура	6 ТБ × 14 команд	50 ГБ × 14 команд
Систем с реальными ПДн в тестовом контуре	11	0

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

Какие двенадцать ошибок поджидают вас по мере роста проекта?

Обучили генератор на полном проде в незащищённом контуре. Юридический риск: копия боевых данных всё равно побывала там, где не должна была.
Положили обезличенную копию рядом с исходной. Прямое нарушение приказа № 140 – совместное хранение запрещено. А это ровно то, что делает CREATE TABLE clients_masked AS SELECT … в той же базе.
Считали маскирование обезличиванием. Пока есть ключ обратимости, у вас на руках персональные данные. Самая частая и самая дорогая путаница из всех.
Мерили качество по средним. Среднее совпало, распределение развалилось. Смотрите перцентили, кардинальность и скошенность; среднее не смотрите вообще, оно обманет.
Забыли про NULL. В проде 12% пустых, в синтетике ноль. Ни одного падения на пустом значении не поймали – все сразу пришлось ловить уже на проде.
Не зафиксировали seed. Баг «воспроизводится через раз», вы проводите два дня расследований, и выясняется, что это не баг, а другой датасет.
Сгенерировали справочники. ОКВЭД, регионы, коды валют, МСС – это не ПДн, их копируют один в один. Синтетический справочник ломает соединения и половину бизнес-логики.
Убрали все дубли. В проде дубли есть, и система обязана их переваривать. Стерильные данные не проверяют то, ради чего писалась дедупликация.
Не проверили контрольные суммы. Девяносто процентов записей отваливаются на валидаторе, тесты «проходят» по трём процентам данных, и месяцами никто не замечает.
Оставили реальные «неперсональные» идентификаторы. Номер договора, полиса, обращения. По ним обычно есть публичная форма проверки статуса – это и есть та самая дополнительная информация из определения обезличивания.
Не поставили срок жизни датасета. Через год сорок терабайт «на всякий случай», и никто не помнит, где среди них выгрузка двухлетней давности с настоящими ПДн. Ставьте TTL сразу, потом не соберётесь.
Сделали данные чище прода. В боевой базе грязь, битые кодировки, «Ошибка» в поле «Город» и клиенты, зарегистрированные в 1970 году. Грязь надо воспроизводить намеренно и в правильной доле.

Инструменты: что выбрать с учётом российских реалий?

Ландшафт собран по слоям, а не по вендорам: вендоры меняются, слои – нет. Часть зарубежных платформ недоступна, а часть неприменима просто потому, что это SaaS – данные для обучения из периметра не выпускают. Открытые библиотеки при этом ставятся локально и работают у всех одинаково.

Стек инструментов по слоям
Слой	Международная практика	Что применимо в РФ	Комментарий
Поиск чувствительных данных и профилирование	Microsoft Presidio, ydata-profiling, Great Expectations, Soda	Всё перечисленное ставится локально; из коммерческих — «Гарда Data Masking» с ML-поиском ПДн, решения InfoWatch	Начните с открытых, коробочное берите, когда схема больше пары тысяч таблиц
Табличный синтез	SDV (GaussianCopula, CTGAN, TVAE, CopulaGAN), synthpop, Gretel, MOSTLY AI, Tonic, Syntho, Hazy, K2view	SDV и synthpop — локально, без ограничений. Из отечественного развивается сервис SyntData у Сбера	SaaS-платформы отпадают сами: данные для обучения наружу не выпустишь
Последовательности и временные ряды	PAR из SDV, TimeGAN, DoppelGANger	То же самое, всё открытое	Марковская цепь плюс распределение интервалов часто не хуже и в разы дешевле
Текст	Крупные LLM через API + Presidio для деидентификации	Только self-hosted модели с хорошим русским. Для NER — Natasha, Slovnet, DeepPavlov	Отправлять реальные ПДн во внешний API нельзя. Обучать на них — только локально
Правила и фикстуры	Faker, Mockaroo, Datafaker, dsdgen из TPC-DS	Faker с локалью `ru_RU`, Mimesis — плюс обязательная своя надстройка под контрольные суммы и справочники	Это тот слой, который вы всё равно допишете сами. Заложите на него две-три недели
Маскирование и подмена	Delphix, Informatica TDM, IBM Optim	«Гарда Data Masking», решения на `pgcrypto` и FF1	Помните: обратимое маскирование не выводит данные из-под 152-ФЗ
Масштабирование до терабайт	Spark, Trino, dbt	Spark, ClickHouse (`numbers_mt`, `generateRandom`, словари), Greenplum и его российские сборки, YTsaurus	ClickHouse на генерации плоских таблиц вне конкуренции по скорости
Оценка качества и приватности	SDMetrics, Anonymeter, TAPAS	Всё открытое, работает. Как рамка для отчётности — ПНСТ 1066-2026	Отчёт по ПНСТ — то, что теперь спрашивают на комитете вместо рассуждений
Оркестрация и доставка	Airflow, Dagster, Tonic Ephemeral	Airflow, NiFi, собственный сервис выдачи окружений	Цель — «данные по кнопке за минуты», а не «заявка в ИБ на девять дней»

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

Защита бюджета: четыре статьи, без которых расчёт не работает

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

Из чего складывается экономический эффект
Статья	Как считать	Пример: 14 команд, 24 спринта в год
1. Простой в ожидании данных	Дней ожидания × число команд × спринтов × стоимость дня команды	2 дня × 14 × 24 × 180 тыс. ₽ ≈ 121 млн ₽ в год
2. Дефекты, пропущенные из-за нерепрезентативных данных	Доля инцидентов прода, помеченных «на тесте не воспроизводилось» × средняя стоимость инцидента	18 инцидентов × 1,4 млн ₽ ≈ 25 млн ₽ в год
3. Хранение и сопровождение копий	Терабайты × число контуров × стоимость хранения и администрирования	6 ТБ × 14 × стоимость СХД и работ ≈ 8–12 млн ₽ в год
4. Хвостовой риск утечки	Вероятность × размер штрафа плюс репутационные потери. По 420-ФЗ для повторного нарушения — 1–3% годовой выручки, минимум 25 млн	Считается отдельно, но именно эта строчка снимает вопросы у правления
Затраты на внедрение	Команда 2–3 человека на квартал + инфраструктура + доработка под специфику	Ориентир: один квартал двух инженеров до первого рабочего домена

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

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

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

План на 90 дней с раскладкой по неделям

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

нед. 2

нед. 4

нед. 6

нед. 8

нед. 10

нед. 12

Инвентаризация

профиль и каталог ПДн

Контракты на данные

выбор пилотного домена

Каталог патологий

выгрузка багтрекера, разбор инцидентов

Пилот: генерация

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

Валидация и пороги

трое ворот в CI

Доставка по кнопке

seed, версии, TTL, CI/CD

Масштаб до ТБ

сверка с продом

План внедрения на 90 дней по неделям.

План внедрения на 90 дней
Недели	Что делаем	Что должно быть на выходе — иначе дальше не идём
1–2	Профилирование источников, классификация полей по содержимому, поиск косвенных идентификаторов	Профиль в формате JSON, зафиксированный по дате. Классификация ≥ 95% полей. Список «полей-помоек», требующих NER
3–4	Контракты на данные с потребителями. Выбор одного пилотного домена — самого болезненного, а не самого простого	YAML-контракт в репозитории, прошедший ревью потребителя. Согласованный с ИБ и юристами способ обработки: маскирование, синтез или гибрид
4–6	Сборка каталога патологий: выгрузка дефектов за 2–3 года, разбор постмортемов, границы схемы	Не менее 60 записей с ID, описанием, ссылкой на инцидент и целевой долей. Меньше 60 — вы плохо копали
6–8	Пилотная генерация: слепок, размножитель, правила под российские форматы, справочники as is	Датасет 1–10 ГБ, проходящий первые ворота. Воспроизводимый по seed побайтово
8–10	Валидация: все три группы метрик, калибровка порогов, сравнение планов запросов	Отчёт по качеству, пороги записаны в контракт, ворота стоят в CI и умеют ронять сборку
10–11	Доставка: сервис выдачи окружений, версионирование слепков, TTL, журналирование	Команда получает датасет по кнопке за минуты, без заявки в ИБ. Это главный видимый результат для бизнеса
11–12	Масштабирование до целевого объёма, нагрузочная сверка с продом	Совпадение планов на топ-50 запросов ≥ 90%. Размер таблиц на диске в пределах 5% от прода

Первый домен занимает квартал, и это нормально. Если вам обещают весь ландшафт за квартал — вам обещают первый домен и молчат про остальные.

Одна вещь, которую стоит сделать уже на первой неделе

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

Что почитать, если хотите ещё глубже разобраться теме

Только то, что реально открывал и к чему возвращался.

ПНСТ 1064-2026, 1065-2026, 1066-2026 «Синтез данных» – терминология, архитектура и методы, оценка качества. С 1 сентября 2026 года. Первый российский документ, на который можно сослаться в проектной документации¹.
Приказ Роскомнадзора № 140 от 19.06.2025 – требования и методы обезличивания. Читать целиком, включая часть про хранение и учёт: там больше подводных камней, чем в перечне методов².
NIST SP 800-188, «De-Identifying Government Datasets» (2023) – самый практичный зарубежный документ. Особенно разделы про валидацию и тест мотивированного нарушителя³.
Stadler, Oprisanu, Troncoso, «Synthetic Data – Anonymisation Groundhog Day», USENIX Security 2022 – холодный душ для всех, кто считает синтетику бесплатным решением приватности⁴.
Rocher, Hendrickx, de Montjoye, Nature Communications, 2019 – те самые 99,98%. Отличный аргумент в споре «мы же убрали ФИО»⁵.
Xu et al., «Modeling Tabular Data using Conditional GAN», NeurIPS 2019 – исходная работа по CTGAN, полезна ради понимания, почему таблицы тяжелее картинок⁶.
Шкала синтетических данных ONS (Bates, Špakulová, Dove, Mealor) – та самая, из второго раздела⁷.
Документация SDV⁸ и SDMetrics⁹, библиотеки Anonymeter¹⁰ и TAPAS¹¹ – практика по многотабличному синтезу и единственный известный мне способ проверить приватность, а не поверить в неё.

Три главных вывода

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

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

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

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

Проконсультироваться

ПНСТ 1064-2026. Синтез данных. Основные положения : предварительный национальный стандарт Российской Федерации : принят и введ. 01.09.2026 : срок действия до 01.09.2029. – Москва : Российский институт стандартизации, 2026. – Текст : электронный // Ассоциация больших данных : сайт. – URL: https://lib.rubda.ru/_images/files1/pnst_sintez_dannyh_arhitektura_processa_sinteza_dannyh_metody.pdf (дата обращения: 25.09.2026). ↩︎
ПНСТ 1065-2026. Синтез данных. Архитектура процесса синтеза данных. Методы синтеза : предварительный национальный стандарт Российской Федерации : принят приказом Росстандарта от 08.07.2026 № 32-пнст : введ. 01.09.2026 : срок действия до 01.09.2029. – Москва : Российский институт стандартизации, 2026. – 58 с. – Текст : электронный // Росстандарт : сайт. – URL: https://protect.gost.ru/gost/details/f09eb333-a40d-45a7-a789-2f53fe30de4e (дата обращения: 25.09.2026). ↩︎
ПНСТ 1066-2026. Синтез данных. Описание результатов процесса синтеза. Методика оценки качества : предварительный национальный стандарт Российской Федерации : принят приказом Росстандарта от 08.07.2026 № 33-пнст : введ. 01.09.2026 : срок действия до 01.09.2029. – Москва : Российский институт стандартизации, 2026. – 42 с. – Текст : электронный // Росстандарт : сайт. – URL: https://protect.gost.ru/gost/details/c6aef45e-9a6f-49b1-b128-c502a07eadae (дата обращения: 25.09.2026). ↩︎
Приказ Роскомнадзора от 19.06.2025 № 140 «Об утверждении требований к обезличиванию персональных данных и методов обезличивания персональных данных, за исключением случаев, указанных в пункте 9.1 части 1 статьи 6 Федерального закона от 27 июля 2006 г. № 152-ФЗ “О персональных данных”». – Зарегистрировано в Минюсте России 31.07.2025 № 83110. – Текст : электронный // Официальный интернет-портал правовой информации : сайт. – URL: http://publication.pravo.gov.ru/document/0001202508010002 (дата обращения: 25.09.2026). ↩︎
NIST Special Publication 800-188. De-Identifying Government Datasets: Techniques and Governance / National Institute of Standards and Technology. – Gaithersburg, MD : NIST, 2023. – 112 p. – DOI: 10.6028/NIST.SP.800-188. – Текст : электронный // NIST : сайт. – URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-188.pdf (дата обращения: 25.09.2026). ↩︎
Stadler, T. Synthetic Data – Anonymisation Groundhog Day / T. Stadler, B. Oprisanu, C. Troncoso // 31st USENIX Security Symposium (USENIX Security 22). – Boston, MA : USENIX Association, 2022. – P. 1451–1468. – Текст : электронный // USENIX : сайт. – URL: https://www.usenix.org/conference/usenixsecurity22/presentation/stadler (дата обращения: 25.09.2026). ↩︎
Rocher, L. Estimating the success of re-identifications in incomplete datasets using generative models / L. Rocher, J. M. Hendrickx, Y.-A. de Montjoye // Nature Communications. – 2019. – Vol. 10, article 3069. – DOI: 10.1038/s41467-019-10933-3. – Текст : электронный // Nature Communications : сайт. – URL: https://www.nature.com/articles/s41467-019-10933-3 (дата обращения: 25.09.2026). ↩︎
Synthetic Data Vault (SDV) : документация. – Текст : электронный // SDV : сайт. – URL: https://docs.sdv.dev/sdv (дата обращения: 25.09.2026). ↩︎
SDMetrics : документация. – Текст : электронный // SDV : сайт. – URL: https://docs.sdv.dev/sdmetrics (дата обращения: 25.09.2026). ↩︎
Anonymeter : библиотека для оценки рисков приватности синтетических данных. – Текст : электронный // PyPI : сайт. – URL: https://pypi.org/project/anonymeter/ (дата обращения: 25.09.2026). ↩︎
TAPAS : a Toolbox for Adversarial Privacy Auditing of Synthetic Data / F. Houssiau, J. Jordon, S. Cohen, O. Daniel, A. Elliott, J. Geddes, C. Mole, C. Rangel-Smith, L. Szpruch. – Текст : электронный // arXiv.org : сайт. – 2022. – URL: https://arxiv.org/abs/2211.06550 (дата обращения: 25.09.2026). ↩︎