Во многих компаниях внутренняя техподдержка тратит часы не на сложные инциденты, а на повторяющиеся вопросы о статусе задач, ходе обработки и готовности данных. Сотрудник пишет в чат, инженер открывает несколько систем, делает серию ручных проверок и только потом отвечает, что именно уже завершилось, а где процесс застрял. Пока команда ходит по кругу между сообщением, логами и панелью мониторинга, время дорогих специалистов уходит на рутину.
5 августа AWS опубликовала кейс Mobileye: компания внедрила ИИ-агента на Amazon Bedrock AgentCore для внутренних запросов в поддержку и сократила время ответа на 90%. Смысл истории не в модном названии технологии, а в очень прикладной перестройке внутренней поддержки: рутинные вопросы о статусе перестают отрывать инженеров от основной работы, а бизнес получает более быстрый и предсказуемый сервис для сотрудников.
Что именно тормозило внутреннюю техподдержку
В кейсе Mobileye описана очень узнаваемая проблема. Поток обработки дорожных записей генерировал массу однотипных обращений от инженеров и команд данных: обработалась ли сессия, где искать результат, почему статус не обновился, какой этап уже завершён. По данным AWS, около 66% таких запросов были рутинными статусными тикетами.
Главный тормоз был не в том, что ответов не существовало, а в том, что они были размазаны по нескольким внутренним системам. Чтобы ответить на один запрос, инженеру приходилось проходить до 15 кликов: найти нужную сессию, сверить данные в разных инструментах, проверить логи и только потом собрать ответ для коллеги. В результате специалисты тратили время на навигацию между системами вместо того, чтобы разбирать реальные сбои и улучшать сам процесс.
Для компаний, которые развивают внутренние инструменты и интеграции, это важный сигнал. Узкое место часто находится не в отсутствии данных, а в том, что сотруднику нужен человек-посредник, который умеет быстро собрать ответ из нескольких разрозненных источников.
Что построила Mobileye
Mobileye развернула ИИ-агента на Amazon Bedrock AgentCore и направила его на самый дорогой тип внутренней рутины: статусные вопросы, которые раньше вручную обрабатывали инженеры. В источнике подчёркивается, что классические сценарии автоматизации — скрипты, жёсткие регламенты и правила — здесь не справлялись, потому что запросы отличались по формулировке и требовали контекстного понимания.
- Агент принимает запрос о конкретной сессии или процессе и понимает, что именно хочет узнать сотрудник.
- Дальше он собирает контекст из связанных систем вместо ручного обхода человеком.
- На выходе сотрудник получает готовый статус без долгого ожидания ответа от инженера.
- По данным AWS, время ответа сократилось на 90%, а точность превысила 95%.
Особенно важно, что кейс не остановился на одном помощнике. После запуска Mobileye превратила подход в платформу самообслуживания, чтобы другие команды тоже могли поднимать собственных ИИ-агентов под похожие внутренние задачи. То есть речь уже не о разовом эксперименте, а о повторяемом контуре, который можно масштабировать на соседние процессы.
С практической точки зрения это ближе не к чат-боту «для красоты», а к рабочему слою автоматизации бизнес-процессов, где агент снимает рутинную прослойку между сотрудником и несколькими техническими системами.
Где такой сценарий даёт эффект быстрее всего
1. Внутренние сервисные столы и техническая поддержка сотрудников.
Когда большая часть обращений — это запросы на статус, подтверждение обработки или поиск причины задержки, ИИ-агент быстро снимает рутину с дорогих специалистов.
2. Операции, где данные размазаны по нескольким системам.
Если человеку нужно сводить информацию из логов, панелей мониторинга, очередей задач и внутренних инструментов, автоматический сбор ответа даёт эффект быстрее, чем очередная ручная инструкция.
3. Команды с узким инженерным ресурсом.
Когда экспертов немного, особенно больно тратить их время на повторяющиеся уточнения. В таких местах ИИ-агент становится способом вернуть инженеров к более сложной работе.
4. Компании, которые хотят собрать цифровой внутренний сервис, а не просто ещё один бот в чате.
Если бизнес уже двигается в сторону цифровых продуктов для сотрудников, такой сценарий хорошо ложится на внутренние порталы, сервисные кабинеты и единые точки входа в поддержку.
Поэтому кейс Mobileye интересен далеко не только автопрому. Он показывает типовой шаблон: есть повторяющиеся внутренние вопросы, есть несколько систем-источников, есть дефицит времени у специалистов — значит, агент может собирать ответ быстрее и стабильнее, чем ручная маршрутизация через чат.
Какие ограничения важно учесть
- Нельзя автоматизировать хаос без нормальных источников данных. Если статусы в системах сами по себе ненадёжны, агент будет лишь быстрее распространять путаницу.
- Нужны границы доступа. Внутренний агент не должен без разбора видеть все логи, очереди и чувствительные данные сотрудников.
- Нужно разделять статусные запросы и реальные инциденты. Если в один поток свалить всё подряд, поддержка потеряет приоритеты.
- Важно заранее определить точку эскалации. Сотрудник должен понимать, когда ответ агента достаточен, а когда нужен инженер.
Хороший результат в кейсе Mobileye связан не только с моделью, но и с тем, что команда выбрала узкий, дорогой и повторяемый сценарий. Это правильная логика для внедрения: сначала снимать однотипную рутину, а не пытаться сразу отдать агенту всю техподдержку.
Что проверить до запуска
- Какие обращения действительно повторяются чаще всего. Лучше начинать с запросов про статус, готовность, местоположение результата и стандартные отклонения.
- Из каких систем должен собираться ответ. Нужен список источников, где хранится актуальный статус, а не только описание желаемого процесса.
- Какие роли и права доступа у агента допустимы. Важно заранее ограничить чувствительные зоны и зафиксировать правила эскалации.
- Как вы будете измерять эффект. Например: время ответа, доля рутинных обращений без участия инженера, нагрузка на службу поддержки, точность ответа и скорость решения сложных инцидентов.
- Можно ли потом тиражировать сценарий в соседние команды. Самый сильный эффект появляется там, где после первого удачного кейса бизнес получает повторяемую модель для других внутренних сервисов.
Если эти условия выполнены, ИИ-агент перестаёт быть демонстрацией возможностей и становится реальным операционным инструментом. Именно это и делает кейс Mobileye сильным: компания не просто ускорила ответы по внутренним тикетам, а построила основу для более предсказуемой поддержки сотрудников внутри сложной технической среды.
Частые вопросы
Какую проблему Mobileye решала в этом кейсе?
Компания хотела убрать рутинные статусные запросы, которые отнимали время у инженеров. До запуска агента сотрудники задавали вопросы о ходе обработки, а специалисты вручную собирали ответ из нескольких систем.
Почему не хватило обычных скриптов и правил?
Потому что запросы отличались по формулировке и требовали контекста. Жёсткие сценарии хорошо работают на полностью предсказуемых шагах, но хуже справляются, когда сотрудник задаёт вопрос по-разному и ожидает собранный ответ по нескольким источникам.
Где такой подход полезен за пределами кейса Mobileye?
Во внутренних сервисных столах, инженерных операциях, поддержке сотрудников, обработке стандартных запросов по статусу и в командах, где ответ приходится собирать из нескольких систем.
С чего лучше начать внедрение?
С одного повторяющегося сценария, где много ручных проверок и понятный источник статусов. Обычно лучший старт — поток однотипных внутренних вопросов, которые отвлекают экспертов, но редко требуют сложного анализа.
Обсудить статью со своим ИИ-ассистентом
Скопируйте эту статью в Markdown: заголовок, ссылка и вся структура текста уже будут готовы для Cursor, Claude, ChatGPT или любого другого агента.
Готово для вставки в ИИ-ассистент.