Персональные данные в облачном ИИ: как организовать работу с учётом GDPR и HIPAA

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

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

Эта статья объясняет подход и не является индивидуальным юридическим заключением. После её прочтения вы сможете составить схему движения персональных данных, понять, какие документы нужны, и подготовить конкретные вопросы для юриста и поставщика. Нормативные акты и позиции регуляторов описаны по исследованию от 11.10.2026.

Когда применяются GDPR и HIPAA

GDPR. Регламент ЕС 2016/679 действует не только внутри ЕС. Статья 3 распространяет его на обработку в контексте деятельности учреждения контролёра или обработчика в ЕС — независимо от того, где физически происходит обработка. Он также применяется к компаниям без учреждения в ЕС, если обработка связана с предложением товаров или услуг людям в ЕС либо с отслеживанием их поведения в ЕС.

Для украинской компании это означает, что регистрация в Украине сама по себе не исключает GDPR. Онлайн-сервис, целенаправленно работающий с клиентами в Польше или Румынии, может подпадать под регламент. Применимость к конкретному процессу следует анализировать с юристом по критериям статьи 3, а не определять общим правилом.

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

HIPAA. Это законодательство США в сфере медицинской информации. Рекомендации Министерства здравоохранения и социальных служб США (HHS) по облачным вычислениям адресованы covered entities (организациям системы здравоохранения, определённым законом) и их business associates (деловым партнёрам), которые работают с электронной защищённой медицинской информацией — ePHI.

Поэтому не следует объявлять HIPAA обязательным для каждой украинской клиники. Само по себе использование американского облачного сервиса не определяет применимость закона: она зависит от статуса организации по правилам США, и её нужно подтвердить с юристом. При этом медицинские данные остаются чувствительными независимо от HIPAA. Если к процессу применяется GDPR, сведения о здоровье относятся к специальным категориям по статье 9.

Начните разговор с юристом с четырёх вопросов:

1. Есть ли у компании учреждение в ЕС, в контексте деятельности которого обрабатываются данные?
2. Предлагает ли компания товары или услуги людям в ЕС либо отслеживает их поведение в ЕС?
3. Является ли компания covered entity или business associate по правилам США?
4. Какие ещё правовые режимы применяются к процессу, в том числе украинские?

Ответы определят, какие разделы ниже обязательны для вас, а какие полезны как хорошая практика.

Составьте схему движения данных

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

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

Составляйте схему для одного конкретного сценария, а не для «ИИ в компании» в целом. У чат-бота поддержки, анализа звонков и генерации напоминаний разные данные, получатели и сроки хранения.

Документы и роли

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

Далее — ключевые требования к ИИ-процессу, если на него распространяется GDPR.

• Основание обработки, статья 6. Обработка законна только при наличии одного из оснований, перечисленных в статье: например, согласия, исполнения договора, юридической обязанности или законного интереса. Договор с поставщиком не создаёт это основание за вас.
• Специальные категории, статья 9. К ним, в частности, относятся данные о здоровье. Их обработка запрещена, если не применяется одно из исключений, определённых статьёй.
• Договор с обработчиком, статья 28. Обработчик действует по документированным инструкциям контролёра. Для привлечения другого обработчика нужно предварительное конкретное или общее письменное разрешение. При общем разрешении контролёра уведомляют о запланированных изменениях, чтобы он мог возразить. Соглашение об обработке данных часто называют DPA (Data Processing Agreement).
• Безопасность, статья 32. Контролёр и обработчик внедряют технические и организационные меры, соответствующие риску. Среди примеров статья называет псевдонимизацию и шифрование.
• Оценка воздействия, статья 35. Если обработка, вероятно, создаёт высокий риск для прав людей, до её начала проводят оценку воздействия на защиту данных (DPIA).
• Международные передачи, статья 44 и последующие. Для передачи в третьи страны или международные организации применяются условия главы V. При практической оценке учитывают Европейскую экономическую зону (ЕЭЗ): в неё входят страны ЕС, Исландия, Лихтенштейн и Норвегия. Передача за пределы ЕЭЗ требует соответствующего механизма защиты.

Для HIPAA ключевой документ другой. Согласно рекомендациям HHS, если covered entity или business associate привлекает облачного провайдера, который от её имени создаёт, получает, хранит или передаёт ePHI, с провайдером заключают BAA (Business Associate Agreement). Провайдер считается business associate даже тогда, когда хранит только зашифрованные данные и не имеет ключа к ним. Помимо договора, HHS требует анализа рисков.

Главная мысль: договор с обработчиком не заменяет основание обработки, минимизацию, собственные меры безопасности и оценку передачи данных. Это один из нескольких необходимых элементов.

Минимизация до отправки запроса

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

Перед подключением ИИ задайте вопрос: какой минимум данных нужен модели именно для этой задачи? Типовые приёмы:

• убрать поля, не влияющие на результат;
• заменить имя и контакты внутренним идентификатором;
• передавать не весь документ, а только нужный фрагмент;
• агрегировать данные, если не требуется уровень отдельного человека;
• хранить таблицу соответствия «идентификатор → человек» в собственной системе и не передавать её ИИ-сервису.

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

Аналогичная логика касается самих моделей. Европейский совет по защите данных (EDPB) в заключении 28/2024 не предлагает автоматически считать анонимной модель, обученную на персональных данных. Оценка зависит от вероятности извлечь персональные данные из модели или получить их с помощью запросов. Если компания планирует дообучать модель на данных клиентов, это отдельное решение, требующее отдельной оценки.

Учебный пример: напоминание пациенту о приёме

Этот пример вымышлен. Он иллюстрирует минимизацию и не является заключением о законности конкретной обработки.

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

Вариант А. В ИИ-сервис отправляют полную медицинскую карту пациента вместе с контактами, чтобы «у модели был весь контекст».

Вариант Б. В запрос передают внутренний идентификатор пациента, дату и время приёма и тип разрешённого канала связи. ИИ создаёт шаблон текста. Имя, номер телефона или email подставляет уже система клиники, она же отправляет сообщение.

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

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

Вторая таблица показывает, почему одного решения недостаточно. Она разделяет три уровня, которые часто смешивают фразой «мы всё закрыли».

Защита и проверка поставщика

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

Доступы. Кто со стороны поставщика и интегратора имеет доступ к данным и в каких случаях. Кто в вашей компании имеет доступ к API-ключам, настройкам и журналам. Ключи следует хранить в одном контролируемом месте, а не в переписке.

Регионы. Где обрабатываются и хранятся данные. Есть ли передача за пределы ЕЭЗ или международной организации и какой механизм по главе V GDPR применяется. Географию проверяйте для всего маршрута, включая привлечённых поставщиков.

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

Инциденты. Как и в какие сроки поставщик сообщает об инциденте, кто в вашей компании получает уведомление и что происходит дальше. Эти условия должны быть в договоре, а не только в маркетинговом описании.

Субобработчики. Список привлечённых поставщиком компаний, вид письменного разрешения и порядок уведомления об изменениях. Статья 28(2) допускает конкретное или общее предварительное разрешение. При общем разрешении должна быть возможность возразить против добавления или замены обработчика.

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

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

Что включить в решение о запуске

После проверок оформите решение письменно. Не как общее разрешение «использовать ИИ», а как запись о конкретном процессе. Рекомендуем включить такие поля:

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

Что сделать в ближайшее время:

1. Выберите один процесс, в котором персональные данные уже попадают или будут попадать в ИИ.
2. Составьте для него схему данных по этапам: от сбора до удаления.
3. Обсудите с юристом четыре вопроса о применимости GDPR, HIPAA и других режимов.
4. Сократите набор полей в запросе до минимума, необходимого для задачи.
5. Соберите договоры (DPA, при необходимости BAA) и ответы поставщика о доступах, регионах, хранении и инцидентах.
6. Оформите решение о запуске с владельцем, остаточными рисками и датой пересмотра.

Нормально, если после этого остаются открытые вопросы к поставщику. Лучше точно знать, чего именно вы не знаете, чем полагаться на общее заявление о безопасности.

Часто задаваемые вопросы