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

Почему убедительный ответ не равен верному.

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

Другая группа ошибок появляется ещё до генерации текста — в обучающих данных и постановке задачи. В обзоре Harvard Ethics & Society приводится пример системы Amazon для найма, которую обучали на резюме, накопленных за десять лет. При проверке система показала дискриминационный результат в отношении женщин. Там же описан Watson for Oncology: недостаток данных о реальных пациентах и опора на синтетические данные связываются с неточными и небезопасными рекомендациями, после чего IBM прекратила работу этого решения. Эти кейсы показывают, что исторические данные могут переносить в модель прежние перекосы, а ограниченная выборка — не покрывать условия реального применения.

Когда ошибка становится обязательством или угрозой.

Последствия зависят от роли AI в продукте. Чат-бот Air Canada сообщил пассажиру условия компенсации, которые противоречили политике авиакомпании. Согласно разбору случая Air Canada, трибунал признал компанию ответственной за информацию на её сайте, включая ответы чат-бота, и обязал выплатить разницу в стоимости билета. Для бизнеса это пример того, что генеративный интерфейс нельзя считать отдельным от публичной коммуникации компании.

В сферах, где совет может повлиять на здоровье, цена неверного продолжения текста выше. Та же подборка Evidently AI описывает, как организация National Eating Disorders Association убрала бот Tessa с горячей линии после того, как он рекомендовал снижение веса, подсчёт калорий и измерение жировой массы людям с расстройствами пищевого поведения. В таком сценарии недостаточно требования «быть полезным»: нужны жёсткие границы допустимых тем, перенаправление к человеку и процедура остановки сервиса при инциденте.

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

Сбой часто находится на стыке компонентов.

Генерация с поиском по корпоративной базе, или RAG, уменьшает зависимость от общих знаний модели, но не отменяет риски. По оценке авторов обзора о сбоях AI-систем, к ним относятся устаревшие или неполные исходные данные, потеря актуальности векторных представлений, нерелевантный контекст в RAG-цепочке и высокая чувствительность ответа к небольшим изменениям входа. Если поиск находит не тот документ, модель может уверенно изложить именно его — и формально сгенерирует ответ без явной «галлюцинации».

Отдельный класс риска возникает у агентов, которым разрешены действия во внешних системах. В разборе инцидентов 2025 года случай с агентом Replit рассматривается как пример опасности, когда системе доступны операции записи и удаления в рабочей среде без человеческого подтверждения и без изоляции от production. Здесь первопричиной может быть не только неверное рассуждение модели: критичны архитектура доступа, разделение сред и возможность быстро отменить действие.

Как использовать неудачи в разработке.

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

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