Южная Корея переписала правила работы с псевдонимизированными данными для AI: что бизнесу взять себе в процессы
В истории с Южной Кореей важно не то, что регулятор якобы "разрешил больше данных для AI". Это было бы слишком простое и неверное прочтение. На самом деле страна пытается сделать две вещи одновременно: оставить жесткую рамку для персональных данных и при этом убрать лишнюю бюрократию там, где бизнесу нужен внятный, рабочий режим для AI-разработки.
Поэтому новости про корейские правила полезны не только локальному рынку. Это хороший пример того, как privacy и AI governance можно собирать не в две параллельные папки, а в одну управляемую систему.
Что именно изменилось
Отправная точка здесь - руководство PIPC по обработке публично доступных персональных данных для AI development and services, выпущенное в 2024 году. В нем корейский регулятор объяснил, что публично доступные данные не превращаются автоматически в "ничьи", но при определенных условиях могут использоваться для AI-разработки на базе legitimate interest.
Следующий шаг - пересборка правил по работе с псевдонимизированной информацией. На официальной англоязычной странице PIPC по pseudonymization закреплено базовое правило: псевдонимизированные данные можно использовать без согласия для статистики, научных исследований и сохранения записей в общественных интересах, а объединение таких данных между разными контролерами должно происходить через designated specialized institution.
Весной 2026 года Южная Корея пошла дальше и полностью пересмотрела операционные guidelines, чтобы они лучше подходили под AI-workflow. Об этом писали и Seoul Economic Daily, и PPC Land: логика обновления сводится к снижению бумажной нагрузки, более понятной оценке рисков и адаптации правил под работу с неструктурированными наборами данных и современными AI-пайплайнами.
Что это не значит
Главная ошибка - решить, что теперь можно свободно тянуть любой массив данных в модель, если вы потом что-то "обезличите". Корейский подход устроен не так.
Во-первых, публично доступные данные все равно требуют оценки законности источника, цели использования и рисков для субъектов данных. Во-вторых, псевдонимизация не делает данные анонимными. Это по-прежнему персональные данные в специальном режиме обработки. В-третьих, объединение наборов данных и повторная идентификация остаются самой чувствительной зоной контроля.
Именно поэтому корейская логика полезна: она не романтизирует AI-разработку, а заставляет описывать реальные шаги обработки данных.
Что бизнесу стоит взять себе в процессы
Даже если вы не работаете в Южной Корее, из этого кейса можно забрать три практических правила.
Первое: разделяйте публично доступные данные, псевдонимизированные данные и анонимные данные не в презентации для руководства, а в реестре обработки. Если внутри компании все это называется просто "безопасными датасетами", вы уже создаете себе проблему.
Второе: принимайте решение об использовании данных на уровне сценария, а не на уровне абстрактной категории. Один и тот же набор может быть приемлем для внутренней аналитики и слишком рискован для model fine-tuning или внешнего AI-сервиса.
Третье: привязывайте privacy к жизненному циклу продукта. Корейские документы полезны как раз тем, что смотрят на данные не в отрыве от продукта, а по этапам: сбор, фильтрация, псевдонимизация, использование, контроль утечек, повторная оценка рисков.
Минимальный checklist для команды
Если переводить это в рабочий язык, то у команды должны быть ответы на пять вопросов:
- На каком правовом основании используется каждый источник данных?
- Какие поля действительно нужны модели или сервису, а какие тянутся "на всякий случай"?
- Где заканчивается псевдонимизация и начинается риск повторной идентификации?
- Кто утверждает объединение наборов данных и как это документируется?
- Как вы проверяете, что модель не воспроизводит чувствительные или лишние персональные сведения?
Если хотя бы на два вопроса ответа нет, значит AI governance пока декоративный.
Вывод
Южная Корея не делает ставку на лозунг "AI любой ценой". Ее подход интересен тем, что он пытается снять ненужное трение для бизнеса, но при этом не размыть зону ответственности. Для продуктовых, legal и compliance-команд это полезный ориентир: хороший режим работы с данными не тот, где меньше правил, а тот, где правила понятны и встраиваются в реальный процесс разработки.