# Риски внедрения ИИ: что ломается и как это закрыть

> Реестр рисков внедрения ИИ по шести группам: данные, галлюцинации, право, эксплуатация, персонал, деньги. Как проявляются и чем снижаются.

- Источник: https://lokai.ru/blog/riski-vnedreniya-ii/
- Организация: Local AI — Внедрение ИИ в закрытом контуре
- Обновлено: 2026-08-07
- Раздел: Главная → Блог → Риски внедрения

---

Главные риски внедрения ИИ — не восстание машин, а шесть прикладных групп: утечка данных, уверенные ошибки модели, нарушение 152-ФЗ, деградация после обновления, сопротивление людей и бюджет, который не окупился. Все шесть управляемы, если закрывать их на этапе постановки, а не после аварии. Ниже — реестр с мерами и разбор необратимых действий.

- **6** — групп рисков, с реестра которых начинается проект
- **0** — необратимых действий выполняется без подтверждения человеком
- **1** — действие, чтобы откатиться к предыдущей подписанной версии
- **100%** — данных остаётся внутри контура компании

## Почему реестр рисков составляют до пилота, а не после

Риск, описанный до старта, стоит одного абзаца в протоколе. Тот же риск, реализовавшийся в продуктиве, стоит остановки процесса и разговора со службой безопасности. Разница не в сложности мер — почти все они дешёвые, — а в том, что после аварии их приходится внедрять в спешке и на фоне недоверия к проекту.

Реестр мы собираем на диагностике вместе с владельцем процесса и представителем ИБ. Формат обычный: риск, как он проявляется в вашем конкретном сценарии, вероятность, мера снижения и человек, который за меру отвечает. Строк получается 10–15 на один процесс, и половина закрывается настройками, а не разработкой.

Полезное правило: если для риска нельзя придумать наблюдаемый признак, это не риск, а тревога. Утечка данных проверяется журналом исходящего трафика. Галлюцинация — выборочным контролем ответов. Деградация после обновления — прогоном набора эталонных примеров. Сопротивление сотрудников — долей обращений, которые пошли мимо системы.

Ниже риски разложены по шести группам. Сначала общий реестр таблицей, затем разбор каждой группы отдельно: чем именно она опасна и какие меры действительно работают, а не выглядят убедительно на слайде.

## Реестр рисков внедрения ИИ: проявление, вероятность, меры

Вероятность указана по нашим проектам и означает частоту, с которой риск проявляется хотя бы раз за первый год. Столбец с мерами — то, что мы закладываем в объём работ по умолчанию.

*Реестр рисков внедрения ИИ по шести группам с мерами снижения*

| Риск | Как проявляется | Вероятность | Чем снижается |
|---|---|---|---|
| Утечка через внешний сервис | Сотрудник вставляет договор в публичный чат-бот | Высокая | Локальный контур, блокировка внешних API на уровне сети, регламент и обучение |
| Модель показывает лишнее | В ответе фрагмент из папки, закрытой для этого пользователя | Средняя | RBAC с наследованием прав от системы-источника, проверка на выборке |
| Персональные данные в журналах | ПДн оседают в логах, кэше и промпт-историях | Средняя | Обезличивание на входе, ограниченный срок хранения, шифрование хранилища |
| Уверенная ошибка модели | Система называет несуществующий пункт регламента | Высокая | Ответ только со ссылкой на источник, отказ при отсутствии данных, выборочный контроль |
| Провал на редких случаях | Работает на типовом потоке, ломается на нестандартном | Высокая | Порог уверенности и эскалация человеку, разметка спорных случаев экспертом |
| Обработка ПДн без основания | Нет согласий, политика обработки не обновлена | Средняя | Пересмотр политики и оснований, [разбор требований 152-ФЗ](https://lokai.ru/blog/bezopasnost-ii-152-fz/) |
| Спор об ответственности за решение | Непонятно, кто отвечает за действие по подсказке модели | Низкая | Регламент: решение принимает и подписывает человек, роль системы — подготовка |
| Обновление ломает работающее | После смены версии качество падает на части сценариев | Высокая | Ручная проверка релиза, подписанные версии, откат одним действием |
| Отказ железа | GPU-узел встал, процесс остановился целиком | Средняя | Резервный узел, снимки состояния, деградация в ручной режим вместо остановки |
| Зависимость от вендора | Поставщик меняет тариф, условия или закрывает доступ | Средняя | Открытые веса на своём железе, резервирование ИИ-провайдера |
| Сопротивление сотрудников | Систему обходят стороной, метрики не двигаются | Высокая | Владелец процесса, обучение, отказ от скрытого контроля, честный разговор о ролях |
| Потеря экспертизы | Люди перестают уметь то, что делает система | Средняя | Разбор спорных случаев людьми, ротация, сохранение ручного режима как резерва |
| Проект не окупился | Эффект виден в презентации, но не в P&L | Высокая | Замер до, метрика в деньгах, пилот перед внедрением, [расчёт окупаемости](https://lokai.ru/blog/skolko-stoit-vnedrenie-ii/) |
| Бюджет вырос по ходу | Всплывают железо, лицензии и свои трудозатраты | Средняя | Полная смета до договора, зафиксированный объём первой очереди |

## Данные и утечки: где протекает чаще всего

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

Второй канал — права доступа. Если поиск по документам обходит матрицу прав, менеджер получает в ответе фрагмент из папки юристов. Права должны наследоваться от системы-владельца документа, а не настраиваться в ИИ отдельно. Проверяется это просто: заводим тестового пользователя с ограниченным доступом и прогоняем через него набор чувствительных запросов.

Третий — данные, которые оседают там, где их не ждут: журналы обращений, кэш ответов, история промптов, отладочные дампы. Каждое такое хранилище нужно назвать, определить срок хранения и решить, что в нём обезличивается на входе. Иначе через полгода в логах накопится теневая база персональных данных без основания обработки.

Четвёртый — демонстрации. Скриншоты с реальными фамилиями и суммами утекают на конференции, в презентации подрядчикам и в чаты. Для показов держим набор синтетических данных, а не «просто замажем». Устройство контура безопасности разобрано на странице [локального ИИ](https://lokai.ru/lokalnyy-ii/).

## Галлюцинации: почему модель ошибается уверенно

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

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

Четвёртая мера — приёмка на реальных примерах. Перед выкаткой прогоняем 100–200 случаев из вашего потока, размечаем ответы вместе с экспертом и считаем не среднюю точность, а долю грубых ошибок: неверная сумма, несуществующий пункт, перепутанный контрагент. Средняя точность в 90% ничего не говорит, если оставшиеся 10% — это ошибки в деньгах.

Пятая — постоянный выборочный контроль после запуска. Доля проверяемых вручную ответов не опускается до нуля никогда, она снижается по мере накопления статистики. Отдельно следим за дрейфом: тот же набор эталонных примеров прогоняется после каждого обновления модели или базы знаний.

## Юридические и регуляторные риски

Эта группа реже срабатывает, но дороже всего обходится. Материал ниже описывает практику, а не заменяет консультацию юриста.

- **Обработка персональных данных без основания.** Как только в контекст модели попадают ФИО, телефон или медицинские сведения, начинается обработка ПДн со всеми обязанностями оператора. Нужны основание, актуальная политика и согласия.
- **Передача данных третьему лицу.** Отправка документа в публичный сервис — это передача, а если сервис зарубежный, ещё и трансграничная. Подробный разбор — в [материале про безопасность и 152-ФЗ](https://lokai.ru/blog/bezopasnost-ii-152-fz/).
- **Автоматическое решение в отношении человека.** Отказ кандидату, изменение условий, снятие премии по решению системы — зона, где требуется участие человека и возможность оспорить результат.
- **Режим коммерческой тайны.** Если в компании введён режим КТ, документы под ним не должны попадать в контуры, не описанные в перечне допущенных систем. Проверяется до подключения источников, а не после.
- **Отраслевые ограничения.** В медицине диагноз ставит врач, в бухгалтерии проводку подтверждает бухгалтер, в строительстве проектное решение подписывает специалист с допуском. Система готовит, человек отвечает.
- **Договорные условия с подрядчиком.** Права на код и данные, порядок передачи, условия выхода из подписки и обязанности по конфиденциальности фиксируются до начала работ, а не в момент разногласий.

## Операционные риски: обновления, отказы, зависимость от вендора

Группа, которая проявляется не на запуске, а на четвёртом-шестом месяце эксплуатации, когда проект уже считают закрытым.

- **Деградация после обновления.** Новая версия модели улучшает одно и ломает другое. Мы держим набор эталонных примеров и прогоняем его перед каждым релизом; ни одно обновление не уходит в продуктив без ручной проверки человеком.
- **Незаметное изменение поведения.** Обновилась база знаний, поменялся шаблон документа, добавилось поле в CRM — и качество поехало без всякого обновления модели. Лечится мониторингом качества, а не разовой приёмкой.
- **Отказ железа.** GPU-узел выходит из строя, и процесс встаёт. Минимальная мера — резервный узел, снимки состояния и заранее описанный ручной режим, в который процесс возвращается вместо полной остановки.
- **Зависимость от одного поставщика.** Стек на открытых весах снимает главную часть риска: скачанные веса нельзя отозвать. Провайдер резервируется, при сбое основного система переключается сама.
- **Некому обслуживать.** Без администратора на стороне заказчика контур деградирует за пару месяцев: не чистится база знаний, не разбираются эскалации, копятся ошибки в правах. Администратора обучаем в ходе проекта.
- **Расползание объёма.** Каждый отдел просит «ещё одну маленькую доработку», и система превращается в набор несвязанных сценариев без владельца. Помогает жёсткая граница первой очереди и очередь на вторую.

## Кадровые и финансовые риски

Две группы, которые почти не обсуждают на технических совещаниях, хотя именно они чаще всего останавливают проект.

- **Сопротивление сотрудников.** Если люди считают, что систему внедряют, чтобы их сократить, они найдут способ работать мимо неё. Роль каждого после внедрения нужно назвать вслух до старта, а не после.
- **Скрытый контроль.** Разбор звонков и переписки легко превращается в инструмент наказания. Тогда сотрудники начинают говорить скриптом, а данные для обучения портятся. Договаривайтесь, что метрики смотрят на процесс, а не на человека.
- **Потеря экспертизы.** Через год после автоматизации разбора инцидентов в отделе может не остаться людей, умеющих разбирать сложный случай. Сохраняйте ручной режим и оставляйте людям спорные случаи, а не только надзор.
- **Уход ключевого человека.** Проект часто держится на одном энтузиасте. Документация, регламенты и обученный дублёр — не бюрократия, а страховка от того, что система остановится вместе с его уходом.
- **Эффект без денег.** Часы сэкономлены, а в отчёте о прибылях и убытках ничего не изменилось. Решать это надо до пилота: заранее договориться, куда идёт высвобожденное время — в сокращение затрат или в рост объёма.
- **Бюджет, выросший по ходу.** Железо, лицензии на свои системы, размещение и собственные трудозатраты всплывают в середине проекта, если их не назвали в начале. Полную смету по статьям мы разбираем [в отдельном материале](https://lokai.ru/blog/skolko-stoit-vnedrenie-ii/).

## Необратимые действия и human-in-the-loop

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

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

Подтверждение должно быть осмысленным, а не механическим. Если человеку сто раз в день показывают одинаковую форму с кнопкой «Да», он перестаёт читать содержимое на десятый. Работает другое: группировка однотипных решений в один экран, подсветка того, что отличается от нормы, и вывод источника — на основании какого документа система предлагает именно это.

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

## Частые вопросы про риски внедрения ИИ

**Какой риск внедрения ИИ реализуется чаще всего?**

По нашим проектам — не утечка и не сбой, а отсутствие эффекта в деньгах. Система работает, пользователи довольны, метрика в дашборде растёт, а в отчёте о прибылях и убытках ничего не меняется. Причина почти всегда одна: до старта не договорились, куда девается высвобожденное время, и не сняли корректный замер до внедрения. Второе место занимает деградация после обновления, третье — сопротивление сотрудников, которым не объяснили, как меняется их роль. Все три лечатся организационно, до написания первой строки кода.

**Как проверить, что модель не выдумывает ответы?**

Тремя способами одновременно. Первый — архитектурный: система отвечает только со ссылкой на конкретный документ и пункт, ответ без источника считается недействительным. Второй — приёмочный: перед выкаткой прогоняем 100–200 реальных случаев из вашего потока и размечаем их вместе с экспертом, считая долю грубых ошибок, а не среднюю точность. Третий — постоянный: выборочный контроль после запуска и прогон эталонного набора после каждого обновления модели или базы знаний. Полностью исключить ошибки нельзя, поэтому на необратимых действиях всегда стоит человек.

**Что делать, если служба безопасности против внедрения ИИ?**

Обычно возражение звучит как «данные уйдут наружу», и оно справедливо для публичных сервисов. Разговор становится предметным, когда вместо общих слов появляются три документа: схема контура с указанием, где стоят узлы и куда ходит трафик; перечень источников данных с уровнем чувствительности каждого; реестр рисков с мерами и ответственными. Мы готовим их на диагностике. Дальше служба безопасности работает не с идеей ИИ, а с конкретной системой, у которой закрыт выход в интернет и включено журналирование каждого действия.

**Можно ли откатить систему, если обновление всё сломало?**

Да, и это заложено в порядок работы. Каждый релиз версионирован и криптографически подписан, изменения описаны в полном changelog, а возврат к предыдущей версии выполняется одним действием. Перед выпуском в продуктив обновление проходит ручную проверку человеком, и гейт на выпуск остаётся на стороне заказчика: мы не раскатываем ничего в вашем контуре без подтверждения. Откат затрагивает конфигурацию, версии моделей и логику работы; данные, накопленные за время работы новой версии, при этом сохраняются.

**Как снизить риск сопротивления сотрудников?**

Назвать роль каждого до начала проекта. Люди сопротивляются не технологии, а неопределённости: непонятно, сократят ли, будут ли считать их ошибки, останется ли премия. Работает простая последовательность: объявить, что численность в первой очереди не меняется, показать, какая именно рутина уходит, назначить владельца процесса из числа самих сотрудников и оставить им спорные случаи, а не только надзор за машиной. Отдельно стоит договориться, что метрики системы смотрят на процесс, а не используются как основание для взысканий.

**Какие действия ИИ мы вообще не отдаём системе?**

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

---

Бесплатный аудит и расчёт окупаемости на ваших данных: https://lokai.ru/besplatnyy-audit-ii/

Почта: hello@lokai.ru · 123112, Москва, ММДЦ «Москва-Сити» · Пн–Пт, 09:00–19:00 МСК