Почему корпоративный ИИ ломается после развертывания – и что с этим делать

Предупреждение: проблема не в модели

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

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

Позже аудит показал, что 71,4% отзывов пользователей были отрицательными. Вместо того, чтобы исправить основные проблемы, ответом было добавление предупреждений. Чат-бот даже оставался в “бета-версии” более двух лет, прежде чем был закрыт.

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

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

От пилота к производству: где все разваливается

Создание пилота довольно простое – выберите случай использования, выберите модель, подготовьте данные, найдите спонсора. Запуск системы в производство – это совсем другая лига.

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

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

Европа делает это более заметным, чем большинство регионов. Регуляции, такие как Закон об ИИ ЕС, GDPR и NIS2, не замедляют внедрение – они показывают, могут ли организации эксплуатировать системы ИИ под реальными ограничениями.

В 2025 году 55% крупных предприятий ЕС уже использовали ИИ. Внедрение уже происходит в масштабе. Проблема заключается в том, что происходит после развертывания.

В этот момент начинают возникать основные операционные вопросы. И часто никто не может ответить на них: кто несет ответственность за выводы ИИ и автономные решения? Что происходит, когда система ведет себя неожиданным образом? И кто поймает это, прежде чем ущерб достигнет СМИ?

Ответственность лежит на компании, а не на технологии. Чат-бот Air Canada дал клиенту неверную информацию о тарифах на прощание. Клиент полагался на нее и позже был отказан в возврате денег. Трибунал постановил, что авиакомпания была ответственна – чат-бот не был отдельной сущностью.

Та же проблема, но с другой стороны: система McHire McDonald’s раскрыла конфиденциальные данные почти 64 000 заявителей. Причина не была в сложной атаке – административный вход использовал “admin” и “123456”. Система казалась передовой. Неудача была элементарной.

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

Кто на самом деле несет риск ИИ? Никто.

Это ядро проблемы, и, парадоксально, это то, что обсуждается меньше всего. IT управляет инфраструктурой. Юристы занимаются соблюдением правил. Бизнес-команды продвигают случаи использования. Но никто не несет ответственность за общий риск ИИ.

Это создает две непосредственные проблемы. Решение “продолжить” замедляется – потому что никто не хочет взять на себя ответственность. И решение “остановить” также замедляется – потому что никто не знает, кто может.

Данные отражают это. Менее 10% случаев использования ИИ доходят от пилота до производства, и большинство организаций борются за достижение измеримого бизнес-эффекта. В то же время многие уже развертывают ИИ – но согласно отчету о зрелости управления, только 7% имели хорошо структурированное и последовательно применяемое управление.

Почему это происходит так последовательно? Потому что большинство рамок и корпоративных политик определяют, что должно произойти – не кто несет ответственность, когда это имеет значение. Когда система начинает производить неверные выводы в полночь в пятницу, вопрос не является теоретическим. Кто действует? И кто имеет полномочия решить?

Это только ухудшается с масштабом. Одна система может быть управляема неформально. Когда у вас есть тридцать, ответственность фрагментируется по командам, и никто не имеет полной картины.

Commonwealth Bank of Australia предоставляет ясный пример. Банк заменил 45 работников службы поддержки клиентов на ИИ-боты, ожидая, что спрос уменьшится. Он не уменьшился. Объем звонков увеличился, менеджеры стали обрабатывать переполнение, и банку пришлось нанять обратно всех 45 сотрудников. Когда их спросили, они не смогли продемонстрировать, что автоматизация уменьшила рабочую нагрузку.

Никто не проверил предположения до развертывания. Никто не нес ответственность за результат, когда эти предположения не оправдались. Это то, что выглядит как вакуум ответственности на практике.

Иметь правила недостаточно. Вам нужен механизм

Большинство организаций не缺уют политики. Они не имеют систем, которые работают, когда что-то идет не так.

Политика определяет, что должно произойти. Механизм определяет, что на самом деле происходит – когда модель производит неверные выводы, когда поставщик меняет что-то на фоне или когда система начинает вести себя неожиданным образом.

Эта разница становится видимой в производстве – когда решения должны приниматься в реальных условиях.

Эти неудачи следуют последовательной динамике. В каждом случае появляются одни и те же операционные пробелы – просто в разных формах.

Ответственность идет первой

Каждая развернутая система ИИ требует явного владельца – одного человека, а не команды или отдела, с полномочиями одобрить, приостановить и закрыть ее.

Без этого ни быстрое развертывание, ни безопасное вмешательство не возможны. Как видно на примере Commonwealth Bank, отсутствие ясной ответственности приводит напрямую к операционной неудаче.

Данные и юридическая ясность часто отсутствуют

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

Действие итальянского регулятора против DeepSeek в 2025 году иллюстрирует это явно. Проблема не была в качестве модели – это была невозможность объяснить, как обрабатываются личные данные. Результатом стала внезапная дисфункция сервиса для европейских пользователей.

Тестирование редко отражает реальное использование

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

Чат-бот MyCity является ясным примером. Базовые краевые случаи – вокруг трудового законодательства, дискриминации в сфере жилья или правил оплаты – не были обнаружены до развертывания. Как только система была представлена реальным пользователям, эти неудачи стали публичными сразу же.

Тестирование не только о производительности – это об идентификации того, где система неудачно перед пользователями, регуляторами или журналистами.

Вмешательство неясно или слишком медленно

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

Zillow Offers демонстрирует это в масштабе. Система использовала алгоритм для определения цен и покупки домов. Когда рынок охладился в 2021 году, система продолжала покупать по завышенным ценам. Не было механизма для обнаружения дрейфа вовремя, и не было ясного решения для остановки. Результатом стали убытки более 880 миллионов долларов и закрытие всего отдела.

Мониторинг не является владением

Мониторинг часто сводится к панелям, но это не то, что предотвращает неудачи.

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

Deloitte Australia показывает, что происходит, когда этого нет. Правительственный отчет включал вымышленные цитаты и неверные юридические ссылки, потому что никто не был явно ответственным за проверку выводов до доставки. Результатом стала частичная возврат денег и ущерб репутации.

Агентный ИИ: что грядет, будет еще труднее

Генеративный ИИ производит выводы. Агентный ИИ совершает действия. Это меняет риск полностью.

Вместо одного ответа для оценки, одна инструкция может запустить цепочку решений по системам – вызовы API, доступ к данным, транзакции, обновления – часто без вмешательства человека на каждом шаге.

Когда что-то идет не так, проблема уже не в точности. Это отслеживаемость. Какой шаг вызвал проблему? Какие данные были использованы? Кто авторизовал действие? Во многих случаях эти вопросы трудно ответить после факта.

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

Ранние сигналы уже указывают в этом направлении. Gartner прогнозирует, что более 40% проектов агентного ИИ будут отменены к 2027 году – не из-за ограничений модели, а потому что организации борются за контроль над затратами, рисками и результатами. Это та же закономерность, которую мы видим с генеративным ИИ после развертывания. Только ставки выше.

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

Эксплуатируйте это – или потеряйте

ИИ больше не является ограничением. Модели широко доступны, способны и все более коммодитируются. Реальный дифференциатор не в том, может ли организация построить ИИ – а в том, может ли она эксплуатировать его надежно, когда он уже запущен.

Это то место, где происходят большинство неудач – в том, как системы эксплуатируются, а не в том, как они строятся. Организации, которые преуспеют, не будут теми, у которых есть наиболее передовые модели. Они будут теми, у которых есть наиболее ясные операционные структуры вокруг них.

Это можно проверить直接. Возьмите свою наиболее важную систему ИИ и ответьте на три вопроса:

• Кто может ее закрыть?
• Как вы знаете, когда она неудачно?
• Что происходит, когда она неудачно?

Если эти ответы неясны, система не готова к производству.

Модель может быть. Организация не готова.