Почему компании возвращают сотрудников после внедрения нейросетей

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

Где автоматизация дала сбой

В подборке «Ведомостей» описан пример Klarna: после внедрения ИИ-ассистента компания заморозила найм в службе поддержки, а численность персонала сократилась. Бот справлялся с типовыми запросами, но сложные обращения снижали удовлетворённость клиентов. Позже компания возобновила найм и перешла к гибридной модели: нейросеть обрабатывает стандартные вопросы, сотрудники подключаются к нестандартным ситуациям.

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

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

Не отменять ИИ, а менять ему роль

В материале также приводится пример Ford. Компания вернула около 350 опытных инженеров, способных выявлять дефекты до выхода деталей на производственную линию, но продолжила использовать ИИ и автоматизацию в другой роли. В частности, были запущены новые автоматизированные тесты для выявления очевидных проблем безопасности.

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

Что проверить перед масштабированием

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

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

Если результат внедрения нужно объяснить команде или клиентам, пригодится ясная подача по принципу структуры вирусного треда: сначала конкретная задача, затем решение и его ограничения. Главный вывод для бизнеса прост: автоматизацию стоит масштабировать по подтверждённому эффекту, а не по обещанию, что нейросеть заменит целую функцию.