Компания сначала просит ИИ написать сообщение. Потом хочет, чтобы он изучил товар, нашёл нужные сведения, ответил на вопрос и передал обращение менеджеру. На этом этапе качество отдельного текста перестаёт описывать качество всей системы.
Эволюция ИИ для бизнеса идёт от генерации ответа к выполнению связанной работы. В этой статье разбираем, какие различия уже существуют и чего разумно ожидать к 2027 году. Прогнозы ниже - редакционная оценка KUZKO, а не объявление о будущих возможностях продукта.
Модель, сценарий и агент решают разные задачи
Языковая модель получает входные данные и формирует ответ. Поиск по базе знаний добавляет ей подходящие материалы. Рабочий сценарий задаёт последовательность действий. Агентная система может выбирать следующие действия по результатам предыдущих шагов.
Такое различие между заранее заданными процессами и агентами проводит Anthropic в руководстве по построению агентных систем. Авторы рекомендуют начинать с простых решений и добавлять сложность по необходимости. Это инженерный подход разработчика моделей, а не независимая гарантия эффективности любой архитектуры.
Для бизнеса выбор начинается с повторяемости задачи. Подтверждение получения заявки обычно укладывается в понятный сценарий. Подготовка ответа по нескольким документам требует поиска и проверки источников. Длительное исследование с выбором направлений может потребовать большей самостоятельности. Одинаковая технология для этих задач не обязательна.
Доступ к актуальному источнику важнее красивой памяти
Представим условный сервис доставки. Агент правильно объясняет ассортимент, но обещает доставку в район, который компания больше не обслуживает. Текст грамотно написан, а задача выполнена плохо.
Чтобы исправить причину, нужно определить источник каждого существенного условия. Где хранится зона обслуживания? Кто меняет минимальный заказ? Откуда берётся стоимость? Как система узнаёт, что данные обновились? Пока на эти вопросы нет ответа, расширение самостоятельности увеличивает количество мест, где может появиться ошибка.
Подготовьте небольшую карту данных: условие, источник, ответственный, дата проверки. Для часто меняющихся значений полезен запрос к рабочей системе. Для устойчивых объяснений подходит проверенная база знаний. Если источник недоступен, агент должен сообщить об этом и передать вопрос, а не достроить недостающий факт.
Следующий этап - проверяемое выполнение
Наш прогноз на 2027 год: при выборе решений бизнес будет чаще спрашивать, можно ли подтвердить каждое выполненное действие. Запись «сообщение подготовлено» отличается от «сообщение отправлено», а «заказ создан» - от «заказ оплачен».
Хорошая история работы связывает запрос, действие и ответ внешней системы. Если попытка завершилась ошибкой, статус должен это отражать. Повтор после сбоя не должен создавать второй заказ или отправлять одно сообщение несколько раз. Эти требования пригодятся и простому сценарию, и самостоятельному агенту.
Практический пример: клиент просит консультацию во вторник. Система проверяет доступное время, получает выбор человека и подтверждает запись. Если календарь не ответил, в карточке остаётся запрос на согласование. Выдавать такую ситуацию за состоявшуюся запись нельзя.
Автономность нужно выбирать для каждого действия
Резюмирование разговора и изменение условий договора имеют разную цену ошибки. Поэтому полезнее обсуждать перечень разрешённых действий, чем спрашивать, полностью ли автономен агент.
| Действие | Разумный способ начать |
|---|---|
| Найти утверждённый ответ в справочнике | Показать ответ с источником |
| Уточнить задачу клиента | Использовать согласованные вопросы |
| Передать обращение менеджеру | Сохранить контекст и подтвердить передачу |
| Предложить нестандартную скидку | Получить решение ответственного |
| Изменить заказ или провести возврат | Проверить полномочия и подтверждение операции |
Это пример проектирования, а не список встроенных функций KUZKO. Конкретные возможности зависят от интеграций и прав доступа. Для каждого подключения заранее определите, кто может остановить работу и как разобрать спорную ситуацию.
Рост возможностей моделей не отменяет проверку на своей задаче
Исследования производительности быстро устаревают, если переносить их результаты на другие инструменты и процессы. В эксперименте METR с инструментами начала 2025 года опытные разработчики тратили на выбранные задачи больше времени при доступе к ИИ. Это результат конкретного исследования разработки, а не вывод обо всех профессиях.
В обновлении METR от февраля 2026 года авторы описали новые данные и проблемы отбора участников, из-за которых оценка текущего эффекта стала ненадёжной. Для руководителя здесь полезен способ мышления: проверять инструмент на актуальных задачах и учитывать, кто согласился участвовать в тесте.
Не сравнивайте время создания черновика с полным ручным циклом. В обоих вариантах нужно учитывать проверку, исправления и итоговое качество. Если сотрудник экономит десять минут на подготовке, но тратит пятнадцать на исправление фактов, это должно попасть в измерение.
Команда будет управлять исключениями
Наша оценка: по мере развития систем роль сотрудников будет всё чаще включать обновление источников, разбор нестандартных вопросов и контроль качества. Это прогноз организации работы, а не обещание сокращения штата.
Опишите исключения до запуска. Клиент оспаривает условия, источник противоречит договору, запрос касается неизвестной функции, человек просит связаться со специалистом. Для каждого случая нужен маршрут: кому передать вопрос, что сохранить и как проверить завершение.
Полезно регулярно читать выборку успешных и неуспешных диалогов. Неудачные ответы показывают пробелы в знаниях, а формально успешные могут скрывать повторное обращение по той же проблеме. Выборку стоит составлять по разным сценариям, а не только по самым удачным примерам.
Как проверить готовность к следующему уровню
Выберите один процесс и составьте несколько реальных типовых ситуаций без лишних персональных данных. Добавьте случай с устаревшим условием, отказом внешнего сервиса и просьбой передать вопрос человеку. Сначала проверьте систему на этих примерах.
После ограниченного запуска оцените, сколько задач завершено корректно, сколько потребовало исправления и во что обошёлся полный цикл. Увеличивать объём стоит после разбора причин ошибок. Переход к новой модели сам по себе не исправляет неясные полномочия и отсутствующие данные.
Посмотрите на сценарий общения в KUZKO
Ролик показывает механику настройки KUZKO. Это демонстрация продукта, а не доказательство результатов упомянутых исследований.
Для первого запуска подготовьте описание бизнеса, подтверждённые условия и цель общения. Создайте сценарий в KUZKO, изучите базу знаний для агента и тарифы. Дополнительные демонстрации доступны на YouTube, новости - в Telegram. Вопросы по применению можно задать команде.
