MHMDA для ИИ-инструментов в сфере здравоохранения: когда LLM-проверка симптомов, ИИ-чат-бот по психическому здоровью или ИИ-тренер по фитнесу становятся регулируемым субъектом
Если ваш ИИ-продукт (искусственный интеллект, ИИ / AI) отвечает на вопросы о здоровье, велнесе, симптомах, психическом здоровье, фертильности, сне или медикаментах для пользователей из Вашингтона, MHMDA (My Health My Data Act) распространяется на вас независимо от того, был ли вход «медицинской» записью. Закон относит выводы (inferences) к Consumer Health Data. LLM, который принимает обычные подсказки и выдаёт гипотезу о состоянии здоровья, генерирует Consumer Health Data «на лету». Уже одно это затягивает ИИ-инструменты в Chapter 19.373 RCW, с автоматическим мостом к Consumer Protection Act по RCW 19.373.090. Этот хаб - практическая карта соответствия для ИИ-продуктов в сфере здравоохранения: сфера действия, отдельная политика конфиденциальности, двухслойное согласие, контракты с поставщиками и процессорами (OpenAI, Anthropic, сторонние API), риск обучающих данных и запрет на geofence.
Проблема выводов (inference): почему «мы просто ИИ-ассистент» не освобождает от MHMDA
Самый частый пропущенный момент при операторской проверке ИИ-продуктов в сфере здравоохранения состоит в том, что RCW 19.373.010 определяет Consumer Health Data как «персональную информацию, которая связана или разумно может быть связана с потребителем и которая идентифицирует прошлое, настоящее или будущее физическое или психическое состояние здоровья потребителя», и это определение прямо включает «любую информацию, выведенную или экстраполированную из информации, не относящейся к здоровью». LLM, который принимает запрос «я уже две недели чувствую усталость и тревогу, что со мной может быть?» и возвращает список правдоподобных объяснений, экстраполирует состояние здоровья из входных данных, не относящихся к здоровью. Этот вывод - Consumer Health Data. Сам запрос также является Consumer Health Data, как только модель классифицировала его как медицинский и система сохранила эту классификацию. Продукт может быть универсальным чат-ботом, ботом службы поддержки, который иногда отвечает на вопросы о здоровье, или ИИ-тренером по фитнесу, делающим выводы о качестве сна на основе данных о ЧСС. Все три попадают внутрь RCW 19.373.010 по основанию выводов.
Восемь страниц, одна карта соответствия
- Соответствие MHMDA для ИИ-проверки симптомов: сфера действия, риск выводов, противопоказания для прямой триажной службы потребителю.
- Соответствие MHMDA для ИИ-чат-ботов по психическому здоровью: категория продукта с наивысшим риском по RCW 19.373.010, включая выводы об эмоциональном состоянии.
- Соответствие MHMDA для ИИ-тренеров по фитнесу: как выводы о шагах, ЧСС, сне и восстановлении пересекают линию Consumer Health Data.
- Политика конфиденциальности для медицинских данных ИИ: отдельная политика, требуемая RCW 19.373.020, переписанная для ИИ-входов, использования моделей, обучения и сторонних API.
- Сценарий согласия для ИИ-инструмента в сфере здравоохранения: построение двухслойного режима согласия из RCW 19.373.030 в реальном UX.
- Контракты с поставщиками и процессорами ИИ в сфере здравоохранения: OpenAI, Anthropic, Azure OpenAI и нижестоящие ИИ-API как процессоры по RCW 19.373.060.
- Юридический чек-лист для стартапа в сфере ИИ-здравоохранения: чек-лист стадии основателя, привязанный к MHMDA, плюс ИИ-специфические риски, о которых спросят инвесторы.
- Анализатор MHMDA для ИИ-инструмента в сфере здравоохранения (интерактивный калькулятор).
Пять ИИ-специфических крючков соответствия по Chapter 19.373 RCW
1. Выводы (inferences) - это Consumer Health Data. RCW 19.373.010 охватывает «информацию, выведенную или экстраполированную из информации, не относящейся к здоровью». Если ваша модель классифицирует запрос пользователя как близкий к медицинскому, генерирует вероятностное объяснение или сохраняет классификацию как метаданные, этот вывод - Consumer Health Data. Универсальная SaaS-позиция («мы не собираем медицинские данные, мы просто чат-продукт») не выдерживает основания выводов.
2. Запросы и логи разговоров - это собранные данные. Как только пользователь вводит запрос о симптоме, паттерне сна, настроении, медикаменте или фертильности, и система сохраняет этот запрос, это сбор Consumer Health Data по RCW 19.373.030. Утвердительное согласие на сбор требуется до хранения, а отдельное согласие требуется для любой передачи третьим сторонам.
3. Использование запросов для обучения модели - это событие передачи с высоким аудит-риском. Если условия вашего провайдера с OpenAI, Anthropic или другим поставщиком моделей позволяют провайдеру использовать переданные данные для улучшения моделей, такая договорённость является передачей Consumer Health Data. RCW 19.373.030(1)(b) требует отдельного согласия на передачу, отличного от согласия на сбор. Большинство потребительских SaaS-условий не показывают опцию отказа от обучения на уровне пользователя, и это пробел в соответствии.
4. Сторонние ИИ-API - это процессоры. Когда ваше приложение отправляет запрос пользователя из Вашингтона в OpenAI, Anthropic, Azure OpenAI или любой внешний API модели, этот поставщик обрабатывает Consumer Health Data от вашего имени. RCW 19.373.060 требует обязывающего договора, который устанавливает инструкции по обработке, ограничивает допустимые действия и обязывает процессора помогать в исполнении ваших обязательств. Стандартные условия обслуживания API обычно не удовлетворяют этим требованиям на лицевой стороне; требуется письменное приложение DPA или поставщик, публикующий приложение, учитывающее MHMDA.
5. Adtech и аналитика внутри продукта - это отдельная поверхность риска. Если ваш ИИ-продукт загружает Google Analytics, Meta Pixel, Mixpanel или любой сторонний SDK, который наблюдает за запросами пользователей или метаданными сессий, эти SDK могут передавать выведенные медицинские данные. Запрет на geofence по RCW 19.373.080 запрещает любую виртуальную границу в радиусе 2 000 футов от медицинского учреждения, используемую для идентификации потребителей, ищущих медицинские услуги, сбора Consumer Health Data или отправки уведомлений. Конфигурации adtech, нацеленные на радиусы вокруг медицинских учреждений, категорически вне меню.
Почему «мы не подпадаем под HIPAA» не является защитой
HIPAA охватывает covered entities (планы здравоохранения, клиринговые центры, провайдеров, передающих медицинскую информацию электронно в HIPAA-транзакциях) и их business associates. Большинство ИИ-продуктов в сфере здравоохранения находятся за периметром HIPAA: это приложения прямого потребителя, не провайдеры. MHMDA был разработан, чтобы закрыть этот пробел. Исключение в RCW 19.373.100 относится к данным, а не к субъекту в целом. Велнес-приложение, не подпадающее под HIPAA, не может ссылаться на HIPAA-исключение. Поставщик телемедицины, подпадающий под HIPAA для клинических PHI, не может распространить это покрытие на маркетинговые пиксели на публичной посадочной странице.
Что я проверяю, когда приходит ИИ-продукт в сфере здравоохранения
- Сфера действия: обслуживаете ли вы пользователей из Вашингтона и доходит ли вывод вашей модели когда-либо до уровня вывода о состоянии здоровья по RCW 19.373.010?
- Политика конфиденциальности: отдельная Consumer Health Data Privacy Policy по RCW 19.373.020, заметно связанная с главной страницей способом, выдерживающим мобильное свёртывание?
- UX согласия: два утвердительных согласия по RCW 19.373.030, причём согласие на передачу отлично от согласия на сбор?
- Стек поставщиков: условия API с OpenAI, Anthropic, Azure OpenAI или любым внешним поставщиком моделей, плюс письменное приложение для процессора по RCW 19.373.060?
- Экспозиция обучающих данных: использует ли договор по умолчанию вашего провайдера переданные данные для обучения моделей, и доводится ли это до пользователей с отдельным согласием на передачу?
- Аналитика и adtech: любой SDK, который может наблюдать за запросами, близкими к медицинским; любая кампания с geofence в радиусе 2 000 футов от медицинского учреждения по RCW 19.373.080.
Практическая заметка Сергея
Большинство ИИ-основателей, которых я проверяю, приходят убеждёнными, что MHMDA не применяется, потому что они «не медицинский продукт». Основание выводов в RCW 19.373.010 - то, что их ловит. Как только пользователь из Вашингтона печатает «я в последнее время в тревоге» и модель возвращает структурированный ответ, система обрабатывает Consumer Health Data. Самый быстрый способ провести триаж - запустить Анализатор MHMDA для ИИ-инструмента в сфере здравоохранения, затем прислать мне URL политики конфиденциальности, скриншоты UX согласия и ваш контракт с ИИ-провайдером. Письменная адвокатская консультация за $240 - правильная отправная точка; за ней следуют scope-меморандум за $499, меморандум плюс формулировки DPA за $900 или меморандум плюс составленная отдельная политика за $1,500, если пробелы существенны.
Образовательный ресурс. Сергей Токмаков - адвокат штата Калифорния (CA Bar #279869), в настоящее время добивающийся допущения в Washington State Bar. Ничто на этой странице не создаёт отношения «адвокат - клиент» и не является юридической консультацией по праву штата Вашингтон. Проверка MHMDA для ИИ-продуктов в сфере здравоохранения является регуляторной консультативной работой по калифорнийской лицензии. Связанные материалы: хаб MHMDA штата Вашингтон; Анализатор сферы действия MHMDA; Проверка пробелов в политике конфиденциальности; Руководство по SaaS-условиям штата Вашингтон.