Три ИИ-инцидента: архитектурные ошибки, а не вина моделей

Автор, проектирующий системы на LLM, разобрал три ИИ-инцидента, произошедших из-за архитектурных ошибок, а не из-за самих моделей. Первый: Deloitte Australia подготовила правительственный отчёт с помощью ИИ; текст прошёл внутренние ревью, но никто не заметил вымышленные источники, потому что ревьюеры полагались на беглость текста, а LLM генерирует связный текст даже при ложных утверждениях. Архитектурное решение — обязательная проверка каждого утверждения через механизм citations с верификацией кода, а не просто просьба к модели «не выдумывать». Второй инцидент: сеть камер Flock в Миннесоте пометила автомобиль журналиста как угнанный из-за того, что при вводе номера в базу опустили две мелкие цифры (34 03 DTM → 34 DTM), а распознавание камер не считывало эти цифры, в итоге десятки машин с похожим номером вызывали алерты. Полицейские блокировали журналиста на парковке. Ошибка на трёх границах: невалидированный ввод, частичное совпадение как точное, и human-in-the-loop существовал только в политике, а не в коде. Решение — строгая схема для распознанных номеров с паттерном и флагом читаемости, а также обязательная человеческая проверка как ветка кода. Третий инцидент: основатель SaaS обнаружил, что его месячная выручка упала до $38 из-за того, что сгенерированный моделью GPT 5.6 Sol код за 7 секунд отменил все подписки. Виновником стала cron-задача, обработавшая пустую очередь удаления как «удалить всё». Автор выделяет три принципа: контроль — в детерминированном коде, а не в промпте; вероятностные компоненты нельзя ставить на места, требующие детерминизма; строгость контролей зависит от цены ошибки.