Что случилось у McDonald’s с AI-ботами и как бизнесу не повторить эти ошибки

У McDonald’s было не одно ЧП с ИИ, а две разные истории. Их часто смешивают, и из-за этого статья про безопасность легко превращается в набор общих слов. На самом деле всё проще.

Первая история была в ресторанах. В июне 2024 года AP News написало, что McDonald’s прекращает тест голосового заказа с IBM. Это был тот самый AI в drive-thru, который принимал заказ вместо сотрудника. По данным AP и Restaurant Business, пилот шёл с 2021 года, а в сети накопилось много примеров, где система путала заказ, добавляла лишнее и просто не понимала людей.

Вторая история была не про заказы, а про найм. В июле 2025 года WIRED рассказало о проблеме на сайте McHire, где чат-бот Olivia общался с соискателями. Исследователи нашли слишком простой пароль 123456, зашли в тестовый аккаунт и через уязвимость в API смогли смотреть записи чатов. Потом Paradox выпустила свой разбор. Компания подтвердила и старый пароль, и проблему в endpoint. При этом она уточнила, что сами исследователи посмотрели семь записей, из них пять содержали персональные данные.

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

Что именно произошло в каждом случае

С историей про drive-thru всё довольно просто. McDonald’s тестировала голосового помощника от IBM в точках самообслуживания. Идея была понятной: ускорить приём заказа и разгрузить сотрудников. Но на практике система ошибалась. AP News приводит примеры из вирусных роликов. Где-то бот добавлял в заказ лишние наггетсы. Где-то собирал странные сочетания вроде мороженого с кетчупом и маслом. Где-то вообще реагировал на голоса из другой машины. McDonald’s не говорила прямо, что проблема именно в точности распознавания, но пилот с IBM компания остановила.

С McHire всё было уже про безопасность. WIRED описывает, как исследователи начали обычную заявку на работу, потом попробовали угадать пароль к админскому аккаунту и нашли тестовый доступ. После этого они заметили проблему в API: если менять идентификаторы заявок, можно увидеть чужие данные. Paradox в официальном обновлении пишет, что этот тестовый аккаунт не использовался с 2019 года, пароль на нём не обновлялся, а уязвимость закрыли в течение нескольких часов после уведомления.

И вот здесь важный момент. У McDonald’s не было одной загадочной истории про «сумасшедший чат-бот». Были две очень земные проблемы:

• бот может плохо работать и раздражать клиентов;
• сервис с ботом может хранить и защищать данные хуже, чем должен.

Почему эта история полезна бизнесу

Обычно, когда говорят про AI-ботов, обсуждают промпты, сценарии и «как сделать его умнее». А McDonald’s показывает, что проблемное место часто вообще не там.

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

В истории с McHire подвёл уже не интеллект бота, а базовая гигиена. Никакой сложной атаки не понадобилось. По сути всё началось со старого аккаунта и слабого пароля, а дальше сработала ошибка в API. Это неприятное напоминание: уязвимость вокруг AI-сервиса часто оказывается не «магической AI-угрозой», а обычной дырой, которая была бы опасна и без всякой модели.

Какие выводы из этого стоит сделать

Первый вывод: не нужно называть любую проблему вокруг ИИ словом prompt injection. В случае McDonald’s это было бы просто неточно. История с заказами была про плохое распознавание и слабый пользовательский опыт. История с McHire была про контроль доступа и API.

Второй вывод: guardrails для AI-бота начинаются не с красивого system prompt. Они начинаются с того, что бот вообще может и чего он делать не должен.

И ещё один вывод. Если бот работает с людьми, заявками, резюме, контактами, оплатой или внутренними инструментами, относиться к нему нужно как к нормальной части рабочей системы. Не как к милой надстройке, которую можно потом «докрутить».

Что нужно проверить у себя, если у вас уже есть AI-бот

Самый простой и полезный способ посмотреть на свой проект — разделить проверку на две части.

1. Бот вообще справляется со своей задачей?

Если бот разговаривает с клиентом, нужно проверить базовые вещи:

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

У McDonald’s с drive-thru проблема была именно здесь. Бот вроде бы выполнял понятную функцию, но делал это недостаточно надёжно.

2. Безопасно ли устроен сам сервис вокруг бота?

Вот здесь уже начинается история уровня McHire. Нужны очень простые проверки:

• нет ли старых тестовых аккаунтов;
• включена ли MFA у админов;
• кто имеет доступ к логам и чатам;
• можно ли вытащить чужие записи через ID, параметры запроса или экспорт;
• не хранит ли бот больше персональных данных, чем ему реально нужно.

Это скучные вопросы. Но именно они чаще всего и спасают от настоящих инцидентов.

Где здесь prompt injection и guardrails

Тему prompt injection всё равно нельзя выкидывать. Просто не надо притягивать её к кейсу, где она не доказана. OWASP пишет, что prompt injection возникает, когда внешний ввод меняет поведение модели не так, как задумано, и может привести к утечке данных, опасным действиям или обходу ограничений. OpenAI в материале про защиту агентов делает важный акцент: нельзя надеяться только на фильтр вредных фраз, нужно строить архитектуру так, чтобы даже удачная манипуляция не приводила к большой беде.

Проще говоря, guardrails нужны не для красоты. Они нужны, чтобы бот:

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

Что стоит внедрить в первую очередь

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

Во-первых, ограничить полномочия. Бот не должен иметь доступ ко всему сразу.

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

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

В-четвёртых, навести порядок в технической базе: старые аккаунты, токены, тестовые среды, доступы к логам, экспорт чатов.

В-пятых, отдельно проверять все места, где бот что-то делает от имени компании: пишет в CRM, отправляет письма, меняет статус заявки, отдаёт скидку, создаёт задачу.

Какие метрики тут правда полезны

По таким системам полезно смотреть не только конверсию или CSAT.

Нужны и более приземлённые показатели:

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

Тогда разговор про безопасность AI-ботов становится предметным. Не «нам кажется, всё нормально», а «мы видим, где система слаба и что уже исправили».

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

FAQ

Так что всё-таки произошло у McDonald’s?
Было две разные истории. Первая — McDonald’s остановила пилот голосового заказа с IBM после заметных ошибок в работе системы. Вторая — на платформе McHire нашли слабый пароль и уязвимость API, из-за чего исследователи получили доступ к части данных соискателей.

Это был prompt injection?
Публично подтверждённого prompt injection в этих историях не было. История с McHire была про старый пароль и API. История с drive-thru — про плохую работу голосового ИИ.

Главный вывод для бизнеса какой?
Не ждать, что ИИ-проект «сам устаканится». Нужно отдельно проверять качество работы бота и отдельно проверять безопасность сервиса вокруг него.