Региональный медицинский оператор в США: примерно 12 стационаров и амбулаторных учреждений, около 2800 врачей в штате. Внутренние клинические руководства, справочники лекарственных взаимодействий и внутренние протоколы были разбросаны по SharePoint, трём устаревшим интранетам и библиотеке стороннего поставщика клинической информации. Чтобы ответить на один вопрос, врач обычно искал в двух-трёх системах, и среднее время ответа на вопрос по протоколу составляло от 4 до 7 минут. За смену это складывалось в заметную когнитивную нагрузку.
ИТ-директор и директор по медицинской информации хотели проверить, может ли управляемый AI-ассистент заменить разрозненный поиск одним интерфейсом запроса с опорой на источники. Условие, не подлежавшее обсуждению, это HIPAA: никакие данные пациентов не попадают в языковую модель, никакие PHI не попадают в журналы, и ни один облачный сервис поставщика не обрабатывает корпус без договора Business Associate, который это покрывает.
Сам корпус клинических знаний не является PHI, но запросы врачей на практике содержали идентификаторы пациентов, потому что вопросы были привязаны к конкретному случаю. Система должна была полностью удерживать PHI вне контекста модели и при этом понимать смысл вопроса о конкретном случае.
Врачи не принимают ассистента, который уверенно выдаёт неверные ответы, и обсуждать тут нечего. Ссылка на источник и работа с неопределённостью должны были войти в структуру ответа с самого начала, а не добавляться позже.
База знаний для поиска включала PDF, страницы интранета, сканы документов с протоколами и клинический API стороннего поставщика. Частота обновления различалась: от ежедневной у лекарственных взаимодействий до ежемесячной у внутренних протоколов.
Применена четырёхэтапная методика Slavin AI. Работа заняла 14 недель на этапах с первого по третий, плюс сопровождение четвёртого этапа до завершения внедрения.
Область сузили до неэкстренных запросов по протоколам, то есть исключили поддержку клинических решений в реальном времени, которая при любом разумном толковании попадает в категорию высокого риска. Базовый уровень: среднее время ответа от 4 до 7 минут, измеренное на выборке из 40 сессий наблюдения за работой врачей. Классификация риска: ограниченный по рамке EU AI Act, поскольку у оператора есть и европейские учреждения, и регулирование по HIPAA в американском праве.
Генерация с опорой на поиск (RAG) и приватное векторное хранилище в собственном облачном контуре оператора. Языковая модель размещена у поставщика, но под договором Business Associate, покрывающим путь данных. Удаление PHI происходит на шлюзе запросов: любой запрос, содержащий шаблон номера медицинской карты, даты рождения, номера социального страхования или имени пациента, очищался до попадания в модель, а удалённые идентификаторы сохранялись непрозрачными метками, чтобы врач, которому нужно продолжение по конкретному случаю, получил его в отдельном процессе с участием человека.
Базовый набор из 12 контролей адаптирован под HIPAA. Конкретно: каждый запрос, каждый ответ и каждый источник поиска записывались в журнал, пригодный для HIPAA и отделённый от журналов продакшена. Откат был реализован флагом конфигурации со временем срабатывания 30 секунд. Ответственным назначен директор по медицинской информации, эскалация на директора по безопасности. В мониторинг входила доля отказов при низкой уверенности, с целевым значением выше 5% на запросах вне области, чтобы подтверждать, что система отказывается, а не выдумывает.
Разработку вела собственная платформенная команда оператора, с еженедельными архитектурными разборами. Были введены две контрольные точки governance: на четвёртой неделе (проверка данных и удаления PHI) и на седьмой (проверка мониторинга и отката). Готовность к продакшену подтверждена на восьмой неделе с двумя задокументированными остаточными рисками: закрепление версии модели у поставщика, который тогда не поддерживал стабильные версии (компенсировано еженедельными регрессионными тестами), и задержка обновления корпуса у стороннего клинического API, признанная ниже порога клинической значимости.
Сокращение на 42% по запросам о протоколах: с базовых 4-7 минут до медианы 2-4 минуты. Измерено по тому же протоколу наблюдения за работой 40 врачей, что и базовый уровень на первом этапе.
Ноль случаев за 9 месяцев работы в продакшене. Доля срабатываний очистки на шлюзе: около 11% запросов вызвали хотя бы одно удаление, и это признано признаком клинической значимости, а не долей ложных срабатываний, которую надо подавлять.
67% целевых врачей активны ежемесячно в течение 90 дней после запуска пилота. Использование добровольное, не предписанное.
Пройден с первого раза. Аудитор отдельно отметил документацию о происхождении данных и об откате как образцовую.
7% в устойчивом режиме. Выше целевых 5%, то есть в пограничных случаях система отказывалась, а не выдумывала.
100% ответов уходили минимум с одной ссылкой, открываемой в корпусе. Точность ссылок выборочно проверена на уровне 96%.
Оценочный контур второго этапа опирался на эталонный набор, собранный врачами на третьей неделе этого же этапа. Задним числом видно, что эту работу следовало начинать на первом этапе: оценочный контур оказался самым дорогим результатом второго этапа, а давление сроков сжало окна врачебной проверки. В дальнейших работах черновик эталонного набора начинается уже на обследовании.
Поставщик тогда не поддерживал стабильные версии, и мы приняли как временную меру еженедельные регрессионные тесты. Через три месяца обновление модели у поставщика ухудшило качество на определённом классе запросов о лекарственных взаимодействиях. Обнаружили в течение 24 часов благодаря регрессионному набору, но случай подтвердил: закрепление версии стоило бы смены поставщика.
Ежедневная, еженедельная и ежемесячная частота обновления у разных источников привела к тому, что векторное хранилище иногда возвращало слегка устаревшее содержание. Порог клинической значимости не был превышен, но описание окна устаревания по каждому источнику должно было стать результатом третьего этапа, а не добавляться задним числом.
Управляющая компания средней величины, AI-ассистент для комплаенс-офицеров, рост пропускной способности проверки в 3,1 раза со ссылками на источники аудиторского качества.
Читать кейс
Европейский промышленный производитель, извлечение данных из документов контроля качества поставщиков, 78% обрабатывается автоматически от начала до конца, окупаемость за 8 месяцев.
Четырёхэтапная модель работы, по которой сделан этот проект.
К странице методики
Разбор архитектуры покажет уровень регуляторных требований, самое рискованное архитектурное решение и стоит ли вообще идти дальше обследования.