Агентный ИИ в клиниках: 95% пилотов без ROI

Почему 95% ИИ-пилотов не дают измеримого ROI: 4 сценария провала, схема оценка → пилот 12 недель → управление изменениями и применимость для РФ.

18 октября 2026 · 8 мин чтения

Агентный ИИ в клиниках масштабируется не силой модели, а доверием к ней: по анализу MIT, 95% корпоративных ИИ-пилотов не дают измеримого ROI, а работающая схема — оценка use case за 4 недели, пилот 12 недель, управление изменениями и масштабирование с критериями остановки.

Демо впечатляет, а через полгода агент перестаёт влиять на клинические решения

Автор колонки в MedCity News — Mykhailo Hentosh, Head of Engineering and Solutions в Binariks. Он описывает типовой сценарий: комитет больницы после убедительной демонстрации утверждает агентное ИИ-решение для операционной эффективности. Через шесть месяцев после запуска система формально работает, но на фактические клинические решения больше не влияет.

Причина — не в модели. Больницы ведут много ИИ-пилотов параллельно, чтобы автоматизировать процессы и освободить время персонала, и попадают в состояние, которое Hentosh называет pilot sprawl: организация уже не может сказать, какие агенты вообще остаются в активном использовании. В статье приводится широко цитируемый анализ MIT: 95% корпоративных ИИ-пилотов не приносят измеримого ROI. Ключевая деталь — провалы предсказуемы, а не случайны, то есть их можно планировать заранее.

Это переносит фокус с выбора модели на выбор последовательности внедрения. Ниже — четыре сценария, в которых проекты ломаются, и схема, которую автор противопоставляет им.

Четыре сценария провала агентных ИИ-проектов

Сценарий	Как выглядит в клинике	Чем заканчивается
The Big Bang	Долгая трансформация сразу по всем отделениям	Требования меняются до запуска, бюджет заканчивается раньше, чем пользователи видят ценность
Pilot Purgatory	Впечатляющее демо, затем работа с реальными пользователями и прерываниями	Провал в реальных рабочих процессах
Technology-First	Платформа построена до того, как определена задача	Use cases подгоняются под уже сделанные инвестиции
Governance Paralysis	Месяцы на проектирование надзора	Инициатива теряет темп, владельца и поддержку руководства

Общая ошибка всех четырёх, по Hentosh: «система спроектирована так, чтобы выглядеть умной, убедительной и даже эффектной, но не так, чтобы ей можно было доверять в реальном рабочем процессе здравоохранения». То, что блестит в демо, на практике часто оказывается «непрозрачным». Каждый дополнительный агент и каждый дополнительный шаг — ещё одна точка отказа. Сбой потребительского приложения — раздражение; сбой больничной системы — задержка критической помощи или пропущенное клиническое оповещение.

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

Слой оркестрации над ЭМК: диагноз верный, рецепт — неполный

В MedCity News Jonathan Bush утверждал, что слои оркестрации нужно строить над ЭМК. Hentosh соглашается с диагнозом: у электронной медкарты есть пределы. Но, по его опыту, предложенное решение не учитывает реальность клинических рабочих процессов.

После десяти лет проектов интеграции ЭМК и HL7 FHIR он видит это трение «чаще, чем почти любую проблему с моделью». Клиницисты отказываются даже от сильных движков триажа, потому что для работы нужно выйти из медкарты, открыть второй инструмент и затем вернуться, чтобы действовать. Проблема не в качестве вывода модели, а в разрыве контура.

Из этого следует практическое требование к архитектуре агента:

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

Последовательность внедрения: оценка → пилот → управление изменениями → масштабирование

Вместо улучшения модели Hentosh предлагает фиксированную последовательность с реальными decision gates между фазами и готовностью остановиться на любом шаге.

Оценка за 4 недели и пилот за 12 недель

Оценка идёт по трём осям: ценность (возврат), реализуемость (наличие данных и инфраструктуры) и персональная релевантность — полезность в повседневной работе конкретных людей. Результат фазы — readiness scorecard и решение go/no-go до того, как потрачены деньги.

Пилот длится около 12 недель и проводится на реальных пользователях и продуктивных данных, а не на презентации. Он должен делать одну чётко определённую и практическую вещь. Тест на ясность у автора такой: «Если вы не можете объяснить медсестре на этаже одним предложением, что именно делает этот ИИ-агент, у вас не один проект, а несколько».

Управление изменениями и масштабирование

Фазу управления изменениями часто пропускают, но, по Hentosh, «если никто не хочет пользоваться агентом, неважно, насколько он технически превосходен». Нужны обучение пользователей, встраивание в ежедневные процессы и проверка фактического adoption. Простые сигналы: как часто предложения принимают versus отклоняют; какую долю рекомендаций сотрудники реально открывают, а какую игнорируют.

Масштабирование начинается только после заранее определённых критериев и измеримых результатов — сэкономленное время за смену, частота ошибок, соблюдение регламента задачи, — а не после «всем понравился пилот». Нерешённые вопросы означают итерацию или остановку. Каждый успешно пройденный пилот даёт «чуть более широкий следующий охват, по одному use case за раз», чтобы ценность была видна к двенадцатой неделе, а не через пятнадцать месяцев.

Фаза	Длительность	Что проверяется	Критерий выхода
Оценка	4 недели	Ценность, реализуемость, персональная релевантность	Readiness scorecard, go/no-go
Пилот	~12 недель	Одна задача на реальных пользователях и продуктивных данных	Измеримые результаты, а не симпатии
Управление изменениями	Встроено в пилот	Фактическое принятие подсказок	Adoption, а не обучение «для галочки»
Масштабирование	После пилота	Время за смену, ошибки, соблюдение регламента	Расширение на один use case за шаг

Что даёт результат: минус треть времени на документацию и правило HTI-1

Один проект по документации, построенный по этой схеме, дал сокращение времени на последующую документацию примерно на треть и удвоение соблюдения запланированных контрольных приёмов (scheduled check-in compliance). AHA Market Scan сообщал о сопоставимом снижении времени на документацию на 27% в Intermountain Health.

Регуляторный контекст в США подталкивает отрасль к той же дисциплине: финальное правило HTI-1 требует строгой прозрачности алгоритмов в сертифицированном медицинском ИТ. Формулировка автора — «Evidence first, hype never»: сначала доказательства, потом хайп.

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

Применимость для РФ

Прямо переносится методическая часть: четыре фазы с decision gates, четыре недели оценки, двенадцать недель пилота, тест «объясни медсестре одним предложением», критерии масштабирования (время за смену, частота ошибок, соблюдение регламента) и метрики adoption — доля принятых и открытых подсказок. Это организационные практики, они не зависят от юрисдикции.

Не переносится напрямую регуляторная обвязка. Аналога HTI-1 в России нет: сертификация медицинского ПО идёт по другому контуру, а требования к прозрачности алгоритмов не оформлены как единое правило для сертифицированного медицинского ИТ. Работа с данными пациентов — спецкатегория по 152-ФЗ, с требованием локализации; прямой перенос US-практик, рассчитанных на HIPAA-контур, невозможен, HIPAA-эквивалента в РФ нет. Любые коммуникации о результатах пилотов регулируются ст. 24 ФЗ-38 «О рекламе» — это влияет на то, как клиника может публично описывать эффект.

Инфраструктурное ограничение — фрагментация ЭМК/МИС: интеграционные сценарии на HL7 FHIR доступны не во всех контурах, поэтому требование «вывод агента внутри карты, а не в отдельном окне» на практике упирается в API конкретной МИС. Часть ИИ-функций, влияющих на клинические решения, может подпадать под регулирование как медицинское изделие — это нужно проверять до пилота, а не после.

FAQ

Q: Сколько времени занимает пилот ИИ-агента в клинике по методике Hentosh? A: Оценка use case — около 4 недель с решением go/no-go, сам пилот — примерно 12 недель на реальных пользователях и продуктивных данных, после чего следуют управление изменениями и масштабирование по заранее заданным критериям.

Q: Что такое pilot sprawl простыми словами? A: Это состояние, когда в организации запущено столько параллельных ИИ-пилотов, что никто не может сказать, какие агенты ещё реально используются. Именно в нём Hentosh видит одну из главных причин отсутствия измеримого эффекта.

Q: Правда ли, что 95% ИИ-пилотов проваливаются? A: По цитируемому в статье анализу MIT, 95% корпоративных ИИ-пилотов не приносят измеримого ROI. Важнее формулировка автора: провалы предсказуемы и укладываются в четыре сценария — Big Bang, Pilot Purgatory, Technology-First и Governance Paralysis.

Q: Почему слоя оркестрации над ЭМК недостаточно? A: Потому что проблема чаще не в модели, а в разрыве рабочего процесса: врачу приходится выходить из медкарты, открывать второй инструмент и возвращаться, чтобы действовать. Даже сильные движки триажа забрасывают по этой причине, поэтому вывод агента должен появляться внутри существующей карты пациента.

Q: Как проверить, что ИИ-агента действительно используют, а не просто обучили? A: По двум метрикам: доля принятых подсказок против отклонённых и доля рекомендаций, которые сотрудники реально открывают, а не игнорируют. Обучение без роста этих показателей не считается внедрением.

Источник: MedCity News, 2026-10-14