Синтетические данные: что это и как создать безопасный набор

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

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

Ограничения деидентификации сверяйте с NIST SP 800-188. Для сильных гарантий приватности NIST рекомендует оценивать дифференциальную приватность в SP 800-226.

Определите конечную задачу

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

• Запишите объект проверки: решение, которое будет проверяться на искусственном наборе.
• Исключите ошибку: генератор оптимизируют на внешнее сходство без связи с бизнес-задачей.
• Выполните действие: записать модель, тест или сценарий, который должен пройти.
• Сохраните доказательство: карточка цели и критерий приёмки.

• Сделайте действие: записать модель, тест или сценарий, который должен пройти. Подтверждением будет карточка цели и критерий приёмки. Храните его рядом с версией данных, модели или настройки, иначе повторная проверка сравнит разные условия.
• Пример. команда создаёт обращения клиентов для теста маршрутизации, а не абстрактный текст Сначала прогоните один обычный и один пограничный случай. Если выводы расходятся, расширяйте тестовую выборку, а не усредняйте проблему.
• Мерой качества служит качество конечной модели на отложенной реальной выборке. Одного среднего числа мало: разбейте результат по типам входа и отдельно покажите редкие случаи, где ошибка дороже.
• Владелец — владелец продукта. Он фиксирует принятое решение, срок следующей проверки и условие остановки. Пункт закрыт только тогда, когда доказательство можно повторить.
• Итог для этапа «Определите конечную задачу» проверяют по связи с исходной задачей: изменение должно улучшать «качество конечной модели на отложенной реальной выборке», а материал «карточка цели и критерий приёмки» — объяснять, почему команда доверяет выводу о контуре «решение, которое будет проверяться на искусственном наборе».

Соберите паспорт исходных данных

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

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

• Практический ход — описать каждое поле и допустимое использование. Не ограничивайтесь снимком экрана: сохраните паспорт набора с владельцем, дату и входной пример, на котором проверка дала результат.
• Разбор ситуации. редкая категория встречается только у одного филиала и раскрывает его Такой пример стоит сохранить целиком: вход, ожидаемый результат, фактический ответ и решение человека после проверки.
• Считайте доля полей с подтверждённым источником. Сравнивайте одинаковые наборы до и после изменения; новая версия не должна выигрывать только из-за более удобной выборки.
• За результат отвечает владелец данных. Его задача — не собрать отчёт, а принять одно из трёх решений: запускать, исправлять или отказаться от сценария.
• Итог для этапа «Соберите паспорт исходных данных» проверяют по связи с исходной задачей: изменение должно улучшать «доля полей с подтверждённым источником», а материал «паспорт набора с владельцем» — объяснять, почему команда доверяет выводу о контуре «поля, происхождение, период и ограничения реального набора».

Выберите метод генерации

Для этого этапа заранее очертите связь между типом данных и способом получения новых примеров. Синтетический набор должен быть полезен для конкретной проверки, а не просто похож на исходную таблицу. Главная ловушка — сложную зависимость заменяют независимой случайной выборкой. Устное объяснение автора не считается контролем: другой специалист должен воспроизвести решение по сохранённым материалам. В разделе «Выберите метод генерации» выполните действие «сравнить правила, статистическую модель, симуляцию и генеративный подход» и сверьте его с доказательством «протокол выбора метода». Тогда риск «сложную зависимость заменяют независимой случайной выборкой» можно обсуждать на материале конкретного контура, а не как общее опасение.

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

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

Разделите обучение и проверку

Практическая граница шага — непересекающиеся данные для настройки и независимой оценки. Синтетический набор должен быть полезен для конкретной проверки, а не просто похож на исходную таблицу. Риск появляется, когда одни строки влияют и на генератор, и на контроль. Поэтому критерий приёмки записывают до эксперимента, а не подгоняют под уже красивый результат. В разделе «Разделите обучение и проверку» выполните действие «заморозить тестовую выборку до генерации» и сверьте его с доказательством «хеши и схема разбиения». Тогда риск «одни строки влияют и на генератор, и на контроль» можно обсуждать на материале конкретного контура, а не как общее опасение.

• Запишите объект проверки: непересекающиеся данные для настройки и независимой оценки.
• Исключите ошибку: одни строки влияют и на генератор, и на контроль.
• Выполните действие: заморозить тестовую выборку до генерации.
• Сохраните доказательство: хеши и схема разбиения.

• На этом этапе нужно заморозить тестовую выборку до генерации. Артефакт «хеши и схема разбиения» связывает вывод с фактическим экспериментом и позволяет вернуться к нему после обновления.
• Пример. редкая запись не должна одновременно обучать генератор и доказывать его безопасность Сначала прогоните один обычный и один пограничный случай. Если выводы расходятся, расширяйте тестовую выборку, а не усредняйте проблему.
• Мерой качества служит разница метрик на обучении и проверке. Одного среднего числа мало: разбейте результат по типам входа и отдельно покажите редкие случаи, где ошибка дороже.
• Владелец — специалист качества. Он фиксирует принятое решение, срок следующей проверки и условие остановки. Пункт закрыт только тогда, когда доказательство можно повторить.
• Итог для этапа «Разделите обучение и проверку» проверяют по связи с исходной задачей: изменение должно улучшать «разница метрик на обучении и проверке», а материал «хеши и схема разбиения» — объяснять, почему команда доверяет выводу о контуре «непересекающиеся данные для настройки и независимой оценки».

Проверьте статистическое сходство

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

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

• Сделайте действие: сравнить квантили, пропуски, корреляции и совместные распределения. Подтверждением будет отчёт по полям и сегментам. Храните его рядом с версией данных, модели или настройки, иначе повторная проверка сравнит разные условия.
• Разбор ситуации. средний чек совпал, но дорогие возвраты исчезли из синтетики Такой пример стоит сохранить целиком: вход, ожидаемый результат, фактический ответ и решение человека после проверки.
• Считайте максимальное отклонение по критичным сегментам. Сравнивайте одинаковые наборы до и после изменения; новая версия не должна выигрывать только из-за более удобной выборки.
• За результат отвечает аналитик данных. Его задача — не собрать отчёт, а принять одно из трёх решений: запускать, исправлять или отказаться от сценария.
• Итог для этапа «Проверьте статистическое сходство» проверяют по связи с исходной задачей: изменение должно улучшать «максимальное отклонение по критичным сегментам», а материал «отчёт по полям и сегментам» — объяснять, почему команда доверяет выводу о контуре «распределения, зависимости и редкие категории».

Измерьте полезность

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

• Запишите объект проверки: результат реальной задачи на синтетическом наборе.
• Исключите ошибку: красивый датасет ухудшает модель после запуска.
• Выполните действие: обучить или протестировать одинаковый процесс на двух наборах.
• Сохраните доказательство: парный эксперимент.

• Практический ход — обучить или протестировать одинаковый процесс на двух наборах. Не ограничивайтесь снимком экрана: сохраните парный эксперимент, дату и входной пример, на котором проверка дала результат.
• Контрольный сценарий: классификатор обращений сохраняет общую точность, но хуже распознаёт жалобы Он полезен именно тем, что показывает цену ошибки в рабочем процессе, а не только техническое отклонение.
• Для решения используйте показатель «точность и полнота по каждому классу». Рядом запишите защитную метрику, чтобы улучшение скорости или полноты не скрывало потерю точности и контроля.
• Роль «ML-инженер» подтверждает итог. При смене входных данных, модели или назначения эта проверка повторяется, даже если прежняя версия работала стабильно.
• Итог для этапа «Измерьте полезность» проверяют по связи с исходной задачей: изменение должно улучшать «точность и полнота по каждому классу», а материал «парный эксперимент» — объяснять, почему команда доверяет выводу о контуре «результат реальной задачи на синтетическом наборе».

Проверьте запоминание

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

• Запишите объект проверки: близость синтетических записей к исходным людям и событиям.
• Исключите ошибку: генератор воспроизводит уникальную строку почти дословно.
• Выполните действие: искать ближайшие реальные записи и редкие комбинации.
• Сохраните доказательство: отчёт сходства и порог блокировки.

• Рабочее решение: искать ближайшие реальные записи и редкие комбинации. После этого другой участник должен получить отчёт сходства и порог блокировки без устных подсказок автора настройки.
• Пример. искусственный клиент повторяет точный возраст, город, должность и сумму сделки Сначала прогоните один обычный и один пограничный случай. Если выводы расходятся, расширяйте тестовую выборку, а не усредняйте проблему.
• Мерой качества служит доля записей ближе установленного порога. Одного среднего числа мало: разбейте результат по типам входа и отдельно покажите редкие случаи, где ошибка дороже.
• Владелец — специалист приватности. Он фиксирует принятое решение, срок следующей проверки и условие остановки. Пункт закрыт только тогда, когда доказательство можно повторить.
• Итог для этапа «Проверьте запоминание» проверяют по связи с исходной задачей: изменение должно улучшать «доля записей ближе установленного порога», а материал «отчёт сходства и порог блокировки» — объяснять, почему команда доверяет выводу о контуре «близость синтетических записей к исходным людям и событиям».

Испытайте атаки на приватность

Здесь рабочей единицей становится возможность определить участие записи или восстановить атрибут. Синтетический набор должен быть полезен для конкретной проверки, а не просто похож на исходную таблицу. Главная ловушка — отсутствие имён принимают за доказательство безопасности. Устное объяснение автора не считается контролем: другой специалист должен воспроизвести решение по сохранённым материалам. В разделе «Испытайте атаки на приватность» выполните действие «провести membership и attribute inference на контролируемой выборке» и сверьте его с доказательством «результаты атаки и остаточный риск». Тогда риск «отсутствие имён принимают за доказательство безопасности» можно обсуждать на материале конкретного контура, а не как общее опасение.

• Запишите объект проверки: возможность определить участие записи или восстановить атрибут.
• Исключите ошибку: отсутствие имён принимают за доказательство безопасности.
• Выполните действие: провести membership и attribute inference на контролируемой выборке.
• Сохраните доказательство: результаты атаки и остаточный риск.

• На этом этапе нужно провести membership и attribute inference на контролируемой выборке. Артефакт «результаты атаки и остаточный риск» связывает вывод с фактическим экспериментом и позволяет вернуться к нему после обновления.
• Разбор ситуации. проверяющий угадывает, был ли конкретный клиент в исходном наборе Такой пример стоит сохранить целиком: вход, ожидаемый результат, фактический ответ и решение человека после проверки.
• Считайте преимущество атакующего над случайным выбором. Сравнивайте одинаковые наборы до и после изменения; новая версия не должна выигрывать только из-за более удобной выборки.
• За результат отвечает команда безопасности. Его задача — не собрать отчёт, а принять одно из трёх решений: запускать, исправлять или отказаться от сценария.
• Итог для этапа «Испытайте атаки на приватность» проверяют по связи с исходной задачей: изменение должно улучшать «преимущество атакующего над случайным выбором», а материал «результаты атаки и остаточный риск» — объяснять, почему команда доверяет выводу о контуре «возможность определить участие записи или восстановить атрибут».

Версионируйте генерацию

Для этого этапа заранее очертите код, параметры, исходная версия и случайное зерно. Синтетический набор должен быть полезен для конкретной проверки, а не просто похож на исходную таблицу. Риск появляется, когда набор нельзя повторить после найденной ошибки. Поэтому критерий приёмки записывают до эксперимента, а не подгоняют под уже красивый результат. В разделе «Версионируйте генерацию» выполните действие «сохранить конфигурацию и журнал запуска» и сверьте его с доказательством «манифест версии». Тогда риск «набор нельзя повторить после найденной ошибки» можно обсуждать на материале конкретного контура, а не как общее опасение.

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

• Сделайте действие: сохранить конфигурацию и журнал запуска. Подтверждением будет манифест версии. Храните его рядом с версией данных, модели или настройки, иначе повторная проверка сравнит разные условия.
• Контрольный сценарий: две выгрузки с одинаковым названием получены разными методами Он полезен именно тем, что показывает цену ошибки в рабочем процессе, а не только техническое отклонение.
• Для решения используйте показатель «доля воспроизводимых сборок». Рядом запишите защитную метрику, чтобы улучшение скорости или полноты не скрывало потерю точности и контроля.
• Роль «инженер данных» подтверждает итог. При смене входных данных, модели или назначения эта проверка повторяется, даже если прежняя версия работала стабильно.
• Итог для этапа «Версионируйте генерацию» проверяют по связи с исходной задачей: изменение должно улучшать «доля воспроизводимых сборок», а материал «манифест версии» — объяснять, почему команда доверяет выводу о контуре «код, параметры, исходная версия и случайное зерно».

Ограничьте применение

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

• Запишите объект проверки: разрешённые и запрещённые решения на синтетике.
• Исключите ошибку: искусственные записи незаметно используют для отчётности о реальных клиентах.
• Выполните действие: пометить набор и добавить правила в каталог.
• Сохраните доказательство: карточка ограничений.

• Практический ход — пометить набор и добавить правила в каталог. Не ограничивайтесь снимком экрана: сохраните карточка ограничений, дату и входной пример, на котором проверка дала результат.
• Пример. на синтетике можно нагрузочно тестировать, но нельзя считать фактическую выручку Сначала прогоните один обычный и один пограничный случай. Если выводы расходятся, расширяйте тестовую выборку, а не усредняйте проблему.
• Мерой качества служит число применений вне разрешённого контура. Одного среднего числа мало: разбейте результат по типам входа и отдельно покажите редкие случаи, где ошибка дороже.
• Владелец — владелец реестра. Он фиксирует принятое решение, срок следующей проверки и условие остановки. Пункт закрыт только тогда, когда доказательство можно повторить.
• Итог для этапа «Ограничьте применение» проверяют по связи с исходной задачей: изменение должно улучшать «число применений вне разрешённого контура», а материал «карточка ограничений» — объяснять, почему команда доверяет выводу о контуре «разрешённые и запрещённые решения на синтетике».

Запустите пилот

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

• Запишите объект проверки: один набор, одна задача и один критерий остановки.
• Исключите ошибку: команда сразу заменяет все реальные данные.
• Выполните действие: сравнить результат на ограниченном процессе.
• Сохраните доказательство: протокол пилота.

• Рабочее решение: сравнить результат на ограниченном процессе. После этого другой участник должен получить протокол пилота без устных подсказок автора настройки.
• Разбор ситуации. тестовая среда получает синтетические заявки, а прод продолжает работать на реальных Такой пример стоит сохранить целиком: вход, ожидаемый результат, фактический ответ и решение человека после проверки.
• Считайте разница результата и времени подготовки. Сравнивайте одинаковые наборы до и после изменения; новая версия не должна выигрывать только из-за более удобной выборки.
• За результат отвечает руководитель проекта. Его задача — не собрать отчёт, а принять одно из трёх решений: запускать, исправлять или отказаться от сценария.
• Итог для этапа «Запустите пилот» проверяют по связи с исходной задачей: изменение должно улучшать «разница результата и времени подготовки», а материал «протокол пилота» — объяснять, почему команда доверяет выводу о контуре «один набор, одна задача и один критерий остановки».

Карта контроля

Что изучить дальше

• обезличивание документа
• персональные данные в ИИ
• нейросеть для анализа данных
• аудит ИИ-систем
• политика использования ИИ
• фактчекинг текстов
• AI Governance

Чек-лист