← Resources
USECASE · 2026-03-12
Приватный AI для здравоохранения: HIPAA-совместимые воркспейсы без облачной привязки
HIPAA-совместимый AI не требует отправки PHI стороннему провайдеру модели. Воркспейс с on-device-first подходом и опциональным BYOK cloud fallback, audit-логами, RBAC и подписанным BAA там, где затрагивается облако, может удовлетворить большинство требований covered entity.
Что HIPAA реально требует от AI-ассистента
*Эта статья — общие рекомендации, а не юридический или compliance-совет; последнее слово за privacy officer вашей covered entity.*
HIPAA написан вокруг данных, а не инструмента, который их читает, поэтому AI-ассистент трактуется как любой другой workforce-член или business associate, имеющий дело с защищённой медицинской информацией. Privacy Rule управляет разрешёнными использованиями и раскрытиями PHI и стандартом minimum-necessary. Security Rule требует административных, физических и технических safeguards, включая контроль доступа, audit controls, целостность, безопасность передачи и документированный анализ рисков. Breach Notification Rule устанавливает обязанность уведомлять затронутых лиц, HHS и в более крупных инцидентах — СМИ, когда незащищённое PHI раскрыто без авторизации.
Недавние нормотворческие сигналы HHS показывают, что AI-системы, создающие, получающие, поддерживающие или передающие ePHI, должны инвентаризироваться и анализироваться на риски как любой другой актив, с шифрованием in transit и at rest, multi-factor authentication и своевременным реагированием на инциденты. Обязательство не меняется от того, что сущность, читающая карту, — это модель.
Где ChatGPT, Copilot и Gemini недотягивают для PHI
Из коробки потребительские тарифы ChatGPT, Microsoft Copilot и Google Gemini не подходят для PHI. Бесплатные и стандартные подписки не идут с Business Associate Agreement, и промпты могут сохраняться или использоваться для улучшения модели по дефолтным условиям.
Нюанс, который стоит держать в голове: каждый вендор предлагает enterprise-конфигурации, которые можно подвести под BAA. OpenAI подписывает BAA для API и для ChatGPT Enterprise или Edu через sales-managed аккаунты. Microsoft предлагает покрытие BAA для Azure OpenAI Service и определённых тенантов Microsoft 365 Copilot, хотя GitHub Copilot и другие потребительские поверхности исключены. Google поддерживает BAA для Gemini внутри подходящих тиров Workspace, но явно исключает NotebookLM и поверхность Gemini-in-Chrome.
Практический риск — workforce drift. Клиницист, вставляющий summary выписки в вкладку бесплатного чат-бота в браузере, по умолчанию совершает раскрытие за пределами любого BAA, независимо от того, что говорит enterprise-контракт.
On-device-first архитектура: локальная модель + opt-in BYOK
Архитектура, минимизирующая риски HIPAA, инвертирует обычный SaaS-паттерн. Дефолтная модель работает на устройстве пользователя, обычно — квантованная open-weights LLM, обслуживаемая локально, так что промпты и генерации никогда не покидают endpoint. Когда клиницисту нужна более сильная reasoning-модель, воркспейс может упасть к облачному провайдеру, используя собственный API-ключ организации, под BAA этого провайдера, с явным opt-in на запрос или на воркспейс.
Это паттерн, стоящий за osFoundry: локальный llama.cpp runtime — first-class дефолт, и любой облачный вызов — это bring-your-own-key против вендора, с которым covered entity независимо заключила контракт. Между клиницистом и моделью нет общего multi-tenant inference pool.
Выгода для compliance конкретна. Нагрузки, которые можно обработать локально, никогда не генерируют событие раскрытия в облаке. Нагрузки, требующие облачной ёмкости, отслеживаются, атрибутируются и подпадают под BAA, который covered entity уже проверила.
Audit, RBAC, DLP и minimum-necessary на практике
Технические safeguards — то, где большинство AI-пилотов проваливают первый внутренний аудит. Четыре контроля делают основную работу.
Audit-логи должны фиксировать, кто запромптил, какая модель ответила, какие источники данных были подключены и что было возвращено, с tamper-evident хранением и окном retention, соответствующим вашей политике хранения записей. RBAC должен связывать доступ к моделям, доступ к датасетам и доступ к инструментам с должностной ролью, чтобы аккаунт front desk не мог запрашивать онкологический корпус, а billing-роль — триггерить генератор клинических заметок.
DLP принадлежит границе промпта. Pattern- и classifier-based редакция идентификаторов до любого облачного вызова программно обеспечивает стандарт minimum-necessary, а не одним обучением. Per-workspace резидентность данных не даёт данным одной практики смешиваться с другой.
Ничего из этого не является AI-специфическим изобретением, но вместе именно это позволяет privacy officer подписать согласие на касание моделью карты.
Три workflow: intake-заметки, prior auth, операционный Q&A
Intake и visit-заметки — наиболее ценная локальная нагрузка. Клиницист диктует, локальная модель набрасывает структурированную заметку, и ничего не покидает устройство, пока клиницист не подпишет и EHR не получит зафиксированную запись через свой существующий интерфейс. Латентность приемлема на современном ноутбуке, и PHI-поверхность ограничена устройством.
Prior authorization выигрывает от retrieval. Модель собирает черновик письма из карты пациента и опубликованных медицинских политик плательщика с цитатами. Если для составления вызывается более сильная облачная модель, выписка из карты деидентифицируется на границе промпта и реидентифицируется на устройстве после возврата ответа.
Операционный Q&A по HR-политикам, billing-кодам и SOP редко нуждается в PHI вообще и может полностью работать на локальных или облачных моделях с PHI-блокирующим DLP. Такое разделение нагрузок держит самый высокорисковый трафик на устройстве, а самый низкорисковый — в облаке.
BAA и vendor risk: что спросить у любого AI-вендора
Перед подписанием пройдите короткий список. Подпишет ли вендор BAA, покрывающий именно ту поверхность продукта, которую вы будете использовать, а не sibling-продукт? Какие конкретно эндпоинты, модели и консоли в scope и какие письменно исключены? Какой дефолт retention для промптов, completions, эмбеддингов и fine-tuning артефактов и можно ли его выставить в ноль?
Запросите список субпроцессоров и механизм уведомления при его изменении. Подтвердите шифрование in transit и at rest, постановку key management и доступность customer-managed keys. Требуйте сроки уведомления о breach, позволяющие вам выполнить ваше 60-дневное обязательство по уведомлению пациентов с запасом.
Запросите свежий SOC 2 Type II и любую аттестацию HITRUST, частоту pen-testing и runbook реагирования на инциденты. Наконец, письменно подтвердите, что вендор не будет обучать общие модели на данных вашего тенанта.
Пилотный rollout за 30 дней
Первая неделя — scoping. Privacy officer, клинический спонсор и IT выбирают два-три workflow, рисуют data-flow диаграмму и обновляют анализ рисков. Определите, какие шаги могут быть только локальными, а какие требуют облака, и подтвердите покрытие BAA для любой облачной поверхности.
Вторая неделя — provisioning. Поднимите воркспейс с RBAC-ролями, замапленными на должности, включите audit-логирование в ваш SIEM, настройте DLP-правила редакции на границе промпта и загрузите локальную модель на пилотные устройства. Задокументируйте план отката.
Третья неделя — supervised пилот с пятью-десятью клиницистами. Отслеживайте сэкономленное время, error rate против human-reviewed gold set и любые DLP-триггеры. Проведите промежуточный обзор с privacy officer.
Четвёртая неделя — go/no-go. Обновите политику и обучающие материалы, финализируйте AI-use disclosure пациентам там, где применимо, и решите критерии расширения для следующей когорты.
Frequently asked questions
- Полностью ли запуск модели on-device снимает необходимость в BAA?
- Для самого локального инференса — да, потому что никакое PHI не раскрывается третьей стороне. Вы всё равно должны учесть роль software-вендора. Если локальный runtime, shell воркспейса или любой management plane может получать PHI через телеметрию, логи или support-сессии, вендор действует как business associate, и BAA уместен. Безопасный паттерн — письменно подтвердить, что вендор не получает PHI с устройства по умолчанию, и отключить любую опциональную телеметрию, которая может нести контент. Облачные fallback'и всегда требуют BAA с провайдером облачной модели.
- Можно ли вообще использовать ChatGPT, Copilot или Gemini в HIPAA-workflow?
- Да, но только в тех конкретных enterprise-конфигурациях, которые вендор согласился покрыть BAA, и только для поверхностей, явно названных в этом соглашении. OpenAI покрывает API и определённые тенанты ChatGPT Enterprise или Edu. Microsoft покрывает Azure OpenAI Service и подходящие тенанты Copilot. Google покрывает Gemini в подходящих тирах Workspace, исключая NotebookLM и Gemini in Chrome. Бесплатные и стандартные потребительские тарифы не покрыты. Более сложная проблема — поведение workforce: блокировка потребительских поверхностей на сетевом или browser-уровне имеет значение не меньше, чем контракт.
- Чем audit-логи AI отличаются от традиционного доступа к EHR?
- Традиционные audit-логи EHR фиксируют доступ к записи по пользователю, времени и действию. AI audit-логи должны фиксировать промпт, модель и версию, найденный контекст, ответ, пользователя, воркспейс и любые инструменты, которые модель вызвала. Они также должны фиксировать решения cloud-роутинга при использовании BYOK fallback. Храните их рядом с EHR-логами по той же политике retention, в tamper-evident хранилище, и подавайте в тот же SIEM, который ваша security-команда уже мониторит, чтобы AI-активность была частью нормального incident response, а не параллельным силосом.
- А что насчёт изменений Security Rule 2026?
- Недавнее нормотворчество HHS переводит несколько ранее addressable safeguards в обязательные, с усиленным акцентом на шифрование, multi-factor authentication, инвентарь активов, включающий AI-системы, обрабатывающие ePHI, и более жёсткие сроки отчётности об инцидентах. Трактуйте любого AI-ассистента как in-scope актив для анализа рисков, документируйте data flows и подтвердите, что ваш runbook реагирования на инциденты может уложиться в более короткие окна уведомления. Координируйте с privacy officer точные даты вступления в силу и переходные ожидания, применимые к вашей организации, поскольку позиция по enforcement и любые продления могут сдвигаться после публикации.
Sources