ИИ и персональные данные в Узбекистане: правила для разработчика и компании

Что считается персональными данными

Персональные данные — любая информация, которая относится к определённому физическому лицу или позволяет его идентифицировать. Очевидные примеры — ФИО, номер телефона, паспортные данные, ПИНФЛ, адрес, фотография. Но в ИИ-проектах персональные данные чаще всего оказываются там, где их никто специально не собирал.

Неочевидные места

• Переписка с клиентами в мессенджерах и чатах поддержки — в ней почти всегда есть имена, телефоны, адреса, иногда фото документов.
• Записи и расшифровки звонков: голос и содержание разговора связаны с конкретным человеком.
• Документы: договоры, анкеты, резюме, сканы удостоверений, справки.
• Логи приложений, где рядом с действием записан идентификатор пользователя, IP-адрес или номер устройства.
• Связка нескольких «безобидных» полей, по которой человека можно узнать: должность, филиал, дата рождения, редкая фамилия в небольшом городе.
• Промпты и ответы, которые ИИ-сервис сохраняет в своей истории: если туда попали данные клиента, они хранятся уже там.

Особые категории

Отдельно стоит относиться к данным о здоровье, биометрии (изображение лица для распознавания, отпечатки, голос как идентификатор), данным о детях. Требования к ним строже, а последствия ошибки — серьёзнее. Если ИИ-проект касается таких данных, юриста стоит подключать на этапе идеи, а не перед запуском.

Ключевые термины

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

Что требует закон: общие принципы и локализация

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

Для ИИ-проектов из этого следуют практические вопросы. Покрывает ли полученное согласие использование данных для анализа моделью? Совпадает ли новая цель — например, обучение модели на переписке — с той, ради которой данные собирали? Сможете ли вы удалить данные человека, если он попросит, когда они уже разошлись по логам, индексам поиска и обучающим наборам?

Локализация

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

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

Что это значит для ИИ-проектов

Большинство сильных облачных моделей работают на серверах за пределами Узбекистана. Каждый запрос к такому API — это передача текста за рубеж, а часто ещё и его хранение у провайдера на какой-то срок. Если в этом тексте есть персональные данные граждан, проект затрагивает и требования к локализации, и правила трансграничной передачи.

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

Рамка решения: какие данные куда

• Когда данные не содержат персональных сведений — публичные документы, агрегированная статистика, тексты без упоминания людей — их можно обрабатывать внешним сервисом, потому что требования о персональных данных их не касаются. Но проверьте это, а не предполагайте.
• Когда персональные данные есть, но для задачи не нужны — например, нужна тема обращения, а не имя клиента, — удаляйте их до отправки, потому что данные, которые не ушли, не могут утечь.
• Когда персональные данные нужны для результата, но модель может работать с метками — например, черновик ответа «Уважаемый [КЛИЕНТ_1]», — используйте псевдонимизацию с таблицей соответствия внутри страны, потому что наружу уходит текст без идентификаторов.
• Когда смысл задачи неотделим от персональных данных — сверка документов, распознавание лиц, анализ медицинских записей — обрабатывайте их моделью внутри страны, потому что обезличить их без потери смысла нельзя.
• Когда речь идёт об особых категориях или детях — по умолчанию только внутренняя обработка и обязательная консультация юриста, потому что цена ошибки здесь максимальна.

Что не стоит отправлять во внешние ИИ-сервисы

• Базы клиентов, учеников, пациентов, сотрудников — целиком или выгрузками.
• Сырые переписки, расшифровки звонков и письма клиентов без обезличивания.
• Сканы паспортов, ID-карт, договоров, медицинских документов.
• Биометрию: фотографии лиц для распознавания, образцы голоса.
• Любые данные детей.
• Логи и дампы баз, в которых есть идентификаторы пользователей.
• Скриншоты рабочих систем, на которых видны карточки клиентов.

Сотрудники и публичные чат-боты

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

Обезличивание и псевдонимизация на практике

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

Методы

• Удаление — поле или фрагмент просто вырезается. Подходит, когда эти сведения задаче не нужны.
• Замена метками — «Алишер» становится «[ИМЯ_1]», телефон — «[ТЕЛЕФОН_1]». Метки должны быть последовательными в пределах документа, чтобы модель понимала, где один и тот же человек.
• Обобщение — точная дата рождения заменяется возрастной группой, адрес — районом или городом.
• Шаблоны для структурированных идентификаторов: телефоны, ПИНФЛ, номера паспортов, карт, электронная почта ловятся регулярными выражениями надёжнее, чем моделью.
• Локальная модель распознавания именованных сущностей для свободного текста: имена, адреса, названия организаций.

Особенности местных текстов

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

Остаточный риск

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

Архитектура и выбор поставщика

• Модель внутри страны. Открытая модель на серверах в Узбекистане обрабатывает данные, не вынося их за пределы республики. Это самый прямой путь для задач, где без персональных данных не обойтись.
• Обезличивание на входе. Локальный сервис очищает текст, во внешнюю модель уходит только версия без идентифицирующих сведений, а реальные значения подставляются обратно уже у вас.
• Разделение задач. Внешний ИИ решает задачи, где персональные данные не нужны: генерация шаблонов, анализ агрегированной статистики, работа с публичными документами.
• Единый шлюз. Все обращения к моделям идут через один внутренний сервис, где применяются правила по данным и ведётся журнал. Так правила нельзя случайно обойти в отдельном приложении.

Вопросы к провайдеру ИИ-сервиса

1. 01Где физически обрабатываются и хранятся запросы и ответы?
2. 02Сколько хранятся журналы запросов и можно ли сократить этот срок?
3. 03Используются ли данные клиентов для обучения моделей, и можно ли это отключить договором или настройкой?
4. 04Кто у провайдера имеет доступ к содержимому запросов и при каких условиях?
5. 05Как провайдер уведомляет об инцидентах и изменениях условий?

Условия различаются между провайдерами и тарифами и со временем меняются, поэтому их нужно перепроверять, а не полагаться на однажды прочитанное.

Процесс для ИИ-проекта шаг за шагом

1. 01Инвентаризация. Опишите, какие данные попадут в модель: из каких систем, в каком виде, через какие сценарии — включая логи, вложения и историю диалогов.
2. 02Классификация. Разметьте поля и типы текста: без персональных данных, с персональными данными, особые категории.
3. 03Цели и основания. Сверьте цель ИИ-обработки с тем, на что получено согласие. Если цель новая, обсудите с юристом, нужно ли новое основание.
4. 04Минимизация. Уберите всё, что задаче не нужно, ещё до обезличивания.
5. 05Маршрут. Для каждого типа данных выберите: внешняя модель, внешняя модель после обезличивания или модель внутри страны.
6. 06Реализация. Встройте обезличивание и правила маршрутизации в шлюз, а не в каждое приложение отдельно.
7. 07Проверка. Прогоните фильтр на реальных образцах, посчитайте пропуски, доработайте.
8. 08Журнал и сроки. Определите, сколько хранятся логи запросов и где, кто имеет к ним доступ.
9. 09Юридическая проверка схемы до запуска и при каждом существенном изменении.

Удаление и отзыв согласия

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

Обучение моделей на персональных данных

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

Пример: условный учебный центр

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

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

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

Типичные ошибки и как их поймать

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

Чек-лист для компании

1. 01Составлен перечень персональных данных, которые попадают в ИИ-проект, включая логи и вложения.
2. 02Данные классифицированы, особые категории и данные детей выделены отдельно.
3. 03Цели ИИ-обработки сверены с законным основанием, как правило — согласием субъектов.
4. 04Базы с персональными данными граждан размещены на технических средствах в Узбекистане и зарегистрированы, как того требует закон.
5. 05Определено, какие данные никогда не уходят во внешние ИИ-сервисы.
6. 06Обезличивание выполняется на вашей стороне до отправки и проверено на реальных образцах.
7. 07Таблицы соответствия меток хранятся внутри страны с ограниченным доступом.
8. 08Все обращения к моделям идут через шлюз с журналом.
9. 09Определены сроки хранения логов и порядок удаления данных по запросу субъекта.
10. 10Условия провайдеров ИИ-сервисов изучены и периодически перепроверяются.
11. 11Сотрудникам даны разрешённые инструменты и понятные правила работы с публичными чат-ботами.
12. 12Схема проекта проверена юристом до запуска, а не после инцидента.

Итог

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