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

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

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

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

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

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

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

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

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

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

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

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

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

• Обработка персональных данных без основания. Как только в контекст модели попадают ФИО, телефон или медицинские сведения, начинается обработка ПДн со всеми обязанностями оператора. Нужны основание, актуальная политика и согласия.
• Передача данных третьему лицу. Отправка документа в публичный сервис — это передача, а если сервис зарубежный, ещё и трансграничная. Подробный разбор — в материале про безопасность и 152-ФЗ.
• Автоматическое решение в отношении человека. Отказ кандидату, изменение условий, снятие премии по решению системы — зона, где требуется участие человека и возможность оспорить результат.
• Режим коммерческой тайны. Если в компании введён режим КТ, документы под ним не должны попадать в контуры, не описанные в перечне допущенных систем. Проверяется до подключения источников, а не после.
• Отраслевые ограничения. В медицине диагноз ставит врач, в бухгалтерии проводку подтверждает бухгалтер, в строительстве проектное решение подписывает специалист с допуском. Система готовит, человек отвечает.
• Договорные условия с подрядчиком. Права на код и данные, порядок передачи, условия выхода из подписки и обязанности по конфиденциальности фиксируются до начала работ, а не в момент разногласий.

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

• Сопротивление сотрудников. Если люди считают, что систему внедряют, чтобы их сократить, они найдут способ работать мимо неё. Роль каждого после внедрения нужно назвать вслух до старта, а не после.
• Скрытый контроль. Разбор звонков и переписки легко превращается в инструмент наказания. Тогда сотрудники начинают говорить скриптом, а данные для обучения портятся. Договаривайтесь, что метрики смотрят на процесс, а не на человека.
• Потеря экспертизы. Через год после автоматизации разбора инцидентов в отделе может не остаться людей, умеющих разбирать сложный случай. Сохраняйте ручной режим и оставляйте людям спорные случаи, а не только надзор.
• Уход ключевого человека. Проект часто держится на одном энтузиасте. Документация, регламенты и обученный дублёр — не бюрократия, а страховка от того, что система остановится вместе с его уходом.
• Эффект без денег. Часы сэкономлены, а в отчёте о прибылях и убытках ничего не изменилось. Решать это надо до пилота: заранее договориться, куда идёт высвобожденное время — в сокращение затрат или в рост объёма.
• Бюджет, выросший по ходу. Железо, лицензии на свои системы, размещение и собственные трудозатраты всплывают в середине проекта, если их не назвали в начале. Полную смету по статьям мы разбираем в отдельном материале.

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

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

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

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