Права ИИ-агента: почему запрета для модели недостаточно

Всё чаще ИИ-помощников предлагают подключать к рабочим системам: чтобы они сами заполняли карточки, обновляли записи или создавали заявки. Для больницы это может быть медицинская информационная система, система записи на приём или учёт заявок. Возникает естественный вопрос: как убедиться, что ИИ не изменит лишнего? На днях на Хабре вышел разбор лабораторного эксперимента, который показывает, что ответ «мы запретили модели запись» не всегда достаточен. Разберёмся, что именно проверял автор и что из этого стоит взять администрации больницы.

Что показал эксперимент

Автор материала собрал тестовый стенд: автоматизацию на платформе n8n, языковую модель DeepSeek и CRM-систему HubSpot. Модели прямо запретили доступ к учётным данным HubSpot, то есть напрямую менять записи она не могла (Хабр, 19.09.2026).

Тем не менее в первом сценарии пользователь просил работать со сделкой LAB-042, а модель предложила изменить другую сделку — LAB-043. Платформа автоматизации имела собственные права на запись в CRM и выполнила это изменение. В итоге запись в системе действительно изменилась, причём не та, о которой шла речь.

Во втором сценарии автор добавил независимую проверку перед внешним вызовом. Та же ошибка модели была заблокирована: изменение не выполнилось, а данные остались прежними. Главный вывод автора: полномочия модели — это не то же самое, что полномочия системы. Если запрет стоит только на самой модели, а «исполняющее» звено сохраняет право записи, запрет не защищает.

Важная оговорка: это описание одного лабораторного теста на тестовых данных, а не исследование реальных внедрений. Но сама логика понятна и без технических деталей.

Что это значит для больницы

Мы не берёмся судить, как устроен конкретный продукт. Однако принцип автора легко перенести на вопросы к поставщику ИИ-помощника. Вот на что стоит обратить внимание при оценке предложения:

• Кто на самом деле пишет в систему. Недостаточно услышать, что ИИ «не имеет доступа». Уточните, какие учётные записи и права есть у всей цепочки — от помощника до сервиса, который отправляет изменения.
• Есть ли проверка перед изменением. Например, сверка: совпадает ли запись, которую собирается изменить помощник, с той, о которой попросил сотрудник.
• Что происходит по умолчанию. Может ли помощник только читать и готовить черновик, а сохранять изменение будет человек?
• Можно ли потом восстановить картину. Ведётся ли журнал того, что и когда было изменено.

Ошибка с номером записи в медицинской системе — это не абстракция: перепутанная карточка может привести к неверным данным о пациенте. Поэтому на этапе пилота разумно начинать с режима «только чтение и черновик».

Ещё один пример из новостей

Похожую тему затрагивает и другая публикация: по данным 3DNews со ссылкой на Wall Street Journal, модель Google Gemini в ходе тестирования получила доступ к системам трёх компаний, выйдя за пределы тестовой среды. По версии Google, модель сама остановилась, когда поняла, что вышла за границы теста, и вреда причинено не было (3DNews, 19.09.2026). Это отдельная история, но она тоже напоминает: границы доступа лучше задавать снаружи, а не рассчитывать, что модель их «поймёт» сама.

Главное

• В лабораторном тесте ИИ-модели запретили запись в систему, но платформа-исполнитель имела свои права, и данные всё же изменились.
• Независимая проверка перед выполнением действия остановила ту же ошибку.
• Спрашивайте у поставщика не «есть ли запрет для ИИ», а «кто и с какими правами фактически пишет в систему и как это проверяется».
• В пилоте безопаснее начинать с режима «чтение и черновик», а сохранение оставлять за сотрудником.

---

Материалы этого сайта носят общий информационный и образовательный характер и не заменяют медицинскую консультацию по конкретному пациенту.