Сегодня ИИ-агентами называют почти всё.

Отдельный чат с длинной инструкцией. Модель, в которую загрузили несколько документов. Помощника, которому дали имя и попросили отвечать «как аналитик». Автоматический сценарий, запускающийся по расписанию. Иногда полноценную систему, которая получает данные, выполняет работу и передаёт результат в бизнес-процесс.

Все эти решения могут быть полезными. Но устроены они по-разному и требуют разного управления.

Проблема начинается тогда, когда между ними не видят разницы.

Компания создаёт чат, загружает в него методологию и называет ИИ-аналитиком. От него начинают ждать самостоятельной работы, устойчивого качества и ответственности за результат. Или наоборот, сразу строят сложную систему через API, не определив, какую роль она должна исполнять, какие решения готовить и где обязана остановиться.

В первом случае возможности инструмента переоценивают. Во втором автоматизируют ещё не спроектированную работу.

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

Начинать нужно с трёх вопросов:

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

Среда определяет, где и с помощью чего идёт работа.

Роль определяет, какую работу агент имеет право выполнять и ради какого результата.

Границы определяют, что он делает сам, что только предлагает и где обязан остановиться.

Только вместе эти три элемента создают управляемого ИИ-исполнителя.

Почему отдельный чат ещё не агент

Представьте обычную работу с моделью.

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

Результат может быть очень качественным.

Но перед следующим анализом вам снова придётся:

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

Инициатором процесса остаётесь вы. Вы же собираете контекст, работаете оператором, контролёром и интегратором.

Модель помогает выполнить отдельную работу, но не исполняет устойчивую роль внутри процесса.

Поэтому отдельный чат это ещё не полноценный агент.

Это не значит, что чат бесполезен или что так с ИИ работать неправильно. Наоборот, именно с него часто начинается проектирование будущего агента. В чате удобно проверять гипотезы, собирать методологию, находить ошибки, формировать требования и наблюдать за тем, как модель понимает задачу.

Но стадию важно называть корректно.

Чат это среда взаимодействия с моделью. Агент это уже спроектированный механизм исполнения работы.

Что превращает модель в ИИ-агента

ИИ-агент появляется не тогда, когда мы написали особенно длинный промпт или подключили модель через API.

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

Получить входные данные - проверить условия - выполнить установленную последовательность действий - применить инструменты и методологию - сформировать результат - передать его адресату - остановиться или запросить решение человека.

У полноценного агента есть:

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

Он не ждёт, пока человек каждый раз заново объяснит всю конструкцию. Конструкция уже стала частью его работы.

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

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

Но здесь нужно важное уточнение.

Не всякая автоматизация через API является агентом.

Если система просто отправляет один и тот же запрос модели и сохраняет ответ, это автоматизированный сценарий. Он бывает полезен, но сам по себе ещё не создаёт агентную роль.

API это способ соединения компонентов. Он позволяет передавать данные, вызывать модель, запускать инструменты и возвращать результат. Но API не определяет:

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

Это определяет роль.

Среда: где может работать ИИ-агент

Агент не обязательно начинается с отдельной дорогой разработки. Он может развиваться в нескольких средах.

Чат с моделью

Подходит для первых экспериментов:

• проверки возможностей;
• разовых задач;
• анализа отдельных файлов;
• поиска подходящего формата;
• подготовки первых инструкций;
• знакомства команды с ИИ.

Контекст здесь в основном собираете вы, а работа запускается вручную.

Рабочее пространство или ИИ-коворкинг

Следующий уровень это постоянная среда, в которой можно:

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

В такой среде уже можно собрать агентную конструкцию, особенно пока роль проектируется и развивается.

Этот этап часто недооценивают.

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

Агентная платформа

Готовые платформы добавляют:

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

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

Собственная сборка через API

Здесь агент становится частью инфраструктуры компании. Он может:

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

Это уже производственный уровень.

Но переходить к API нужно не потому, что «настоящие агенты работают только так». Переход оправдан тогда, когда проверенную роль пора встроить в регулярный поток данных и решений.

Из практики. Как роль прошла все четыре среды

ИИ-наставник для менеджеров начинался в обычном чате. Там собиралась методология, проверялись формулировки, накапливались вопросы, на которых он ошибался.

Дальше пилот. Сервис с жёстким лимитом запросов в месяц. Лимит оказался полезен: он заставил считать реальную частоту обращений раньше, чем появился счёт за них.

Затем постоянная среда. У роли появились системный промпт, база знаний из методических документов и банк из 33 разобранных вопросов. Только на этом этапе конструкция приобрела устойчивую агентную роль, хотя технически всё ещё оставалась относительно простой.

И лишь потом масштабирование на платформу с оплатой по потреблению, а доставка результата менеджерам через бота. Менеджер не заходит в модель и не пишет промпт. Он задаёт вопрос там, где работает.

Отдельно про выбор среды. Одну из платформ мы отклонили не по функциональности, а потому что команда клиента находится в разных входах по VPN и вход в коворкинг давала сильный риск блокировки. Риск блокировки организации целиком перевесил всё остальное. Среду выбирают под ограничения, а не под витрину возможностей.

Коворкинг или API: что выгоднее

Универсального ответа нет.

Иногда готовая рабочая среда выгоднее собственного решения. Например, если анализ проводится раз в неделю, данные можно безопасно загрузить вручную, а результат всё равно обсуждается руководителем, сложная интеграция может не окупиться.

Коворкинг позволяет быстрее начать:

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

При этом надо учитывать скрытую стоимость ручной работы:

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

API становится оправданным, когда:

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

Сравнивать нужно не только цену обращения к модели.

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

Поэтому правильный путь часто выглядит так.

Через API автоматизируют уже спроектированную роль, а не сырой эксперимент.

Коворкинг удобен, чтобы накопить организационное знание. API нужен, чтобы это знание устойчиво исполнялось в рабочем процессе.

Почему возможностей агента недостаточно

Представьте, что ваш агент уже умеет:

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

Технически он готов выполнять десятки видов работы.

Сегодня его просят проанализировать продажи. Завтра изменить классификацию. Послезавтра подобрать новые пороги. Затем предложить цены. Потом пересобрать план и определить, какие товары выводить из ассортимента.

Каждый раз это разные люди, и каждый спрашивает про своё.

Каждый запрос выглядит логичным продолжением предыдущего.

Постепенно агент превращается в универсального цифрового сотрудника, чьи обязанности определяет последний пользователь, написавший запрос.

Проблема здесь не в качестве модели. Проблема в том, что возможности агента начали подменять его роль.

Технология действительно позволяет создать новый срез, изменить период, предложить показатель, подобрать порог и смоделировать действие. Но способность выполнить операцию не даёт права вводить её результат в систему управления.

Поэтому агента проектируют не от вопроса «что умеет модель». Его проектируют от роли.

Что такое роль ИИ-агента

Роль определяет устойчивое место исполнителя в организации. Она отвечает на вопросы:

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

Например, роль ИИ-аналитика можно определить так.

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

Из определения уже видны границы.

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

Среда даёт агенту возможности. Роль ограничивает применение этих возможностей интересами системы управления.

Из практики. Одна модель, но два разных продукта

В какой-то момент возник логичный вопрос. У нас есть ИИ-наставник, который объясняет менеджерам коды и разбирает недельные сводки. Аналитику клиента нужен помощник по тем же данным. Модель одна, данные пересекаются. Почему не сделать одного универсального помощника на всех?

Решение было обратным. Это два разных продукта, и объединять их нельзя.

У наставника объект работы это готовая размеченная сводка, потребитель это менеджер, продукт это объяснение «почему товар попал в этот список».

У аналитического помощника объект работы подготовленные данные и результаты расчётного слоя, а продукт проверяемая аналитическая интерпретация, гипотезы и выводы.. Разные входы, разные критерии качества, разная цена ошибки.

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

Технически объединение было возможно. Управленчески это создало бы роль, у которой нет ни одного чёткого потребителя.

Роль нельзя расширять новым запросом

Это один из самых сложных моментов в реальной работе.

Кто-то из команды пишет агенту:

Раздели товары по другому принципу и считай проблемными все позиции ниже нового порога.

Для модели такой запрос несложен. Она выполнит его за несколько минут.

Но управленчески внутри одного предложения скрыты три разных действия.

1. Создание нового аналитического среза.
2. Изменение методологии оценки.
3. Изменение управленческой границы, после которой компания должна действовать.

Первое может находиться внутри роли аналитика. Второе относится к роли методолога. Третье остаётся решением руководителя или владельца процесса.

Поэтому новый запрос не должен автоматически расширять полномочия агента.

Что может сделать ИИ-аналитик

Он может:

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

Например.

При действующем пороге в проблемную группу входят 420 SKU. При тестовом пороге 15% группа увеличивается до 610 SKU. На добавленные позиции приходится 27% продаж категории. Расчёт экспериментальный и не должен использоваться как рабочее правило до проверки методологом и утверждения владельцем решения.

Агент способен провести такую работу. Но объявить новый порог действующим он не может.

Что делает методолог

Методолог проверяет аналитическую конструкцию:

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

Методолог отвечает на вопрос, корректна ли новая аналитическая логика.

Что делает руководитель

Руководитель или владелец решения оценивает управленческие последствия:

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

Руководитель отвечает на другой вопрос. Готовы ли мы применять эту логику в бизнесе и отвечать за последствия.

Получается последовательность.

Возможность пересчитать всё по новым правилам это способность модели. Право менять правила это устройство управления.

Новый срез или новая методология

Эти понятия важно различать.

Если агент берёт утверждённый показатель и показывает его по категории, бренду, менеджеру, площадке, схеме поставки, складу или согласованному периоду, то это новый срез внутри действующей методологии.

Если же меняется:

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

то это уже изменение аналитической или управленческой системы.

Правильно спроектированный агент должен различать эти случаи до выполнения запроса. Он должен уметь определить:

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

Зрелость агента определяется не количеством вопросов, на которые он способен ответить. Она определяется тем, насколько точно он понимает границы своей роли и умеет остановиться там, где начинается чужая ответственность.

Как на самом деле создаются границы

Недостаточно написать в системной инструкции «не меняй методологию без разрешения».

Такое ограничение существует только в тексте. Сотрудник сформулирует запрос иначе, документы будут противоречить друг другу, а модель примет новое условие за часть задачи.

Граница роли должна быть не пожеланием, а рабочей конструкцией. Она создаётся несколькими слоями.

Паспорт роли

Паспорт фиксирует:

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

Паспорт не должен быть формальным описанием. Он становится основанием для инструкций, доступов, контрольных тестов и маршрута работы.

Реестр действующей методологии

Агенту нужен не абстрактный «контекст компании», а управляемый набор правил:

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

Агент работает только по действующей версии.

Если в базе лежат три похожих документа и неизвестно, какой актуален, система уже потеряла управляемость. Модель не должна выбирать действующую методологию по названию файла, дате изменения или сходству текста.

Матрица полномочий

Каждое действие относится к одному из трёх уровней.

Агент выполняет самостоятельно

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

Агент может предложить и протестировать

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

Результат при этом маркируется как экспериментальный.

Агент не может вводить самостоятельно

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

Такая матрица превращает общее требование «работай осторожно» в конкретную систему полномочий.

Рабочий и экспериментальный режимы

Агенту можно дать свободу исследования, не давая свободы изменения рабочей системы. Для этого разделяются два режима.

В рабочем режиме используются только:

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

Результаты этого режима могут поступать в регулярное управление.

В экспериментальном режиме агент может:

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

Но экспериментальные результаты не запускают рабочие действия и всегда имеют явную маркировку.

Свобода исследования не должна означать свободу изменения действующей системы.

Процедура изменения правил

Если агент, аналитик или руководитель предлагает новое правило, оно проходит установленный маршрут.

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

При этом фиксируется:

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

Без этого агент будет постоянно «улучшать» методологию, а компания быстро потеряет возможность воспроизводить собственные результаты.

Из практики. Как выглядит такой маршрут на реальном изменении

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

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

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

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

Финальная приёмка это прогон на боевом срезе. В последний раз это было 2309 строк, и результат сверялся построчно с ожидаемым, пока числа не сошлись.

Ни один из этих шагов не про модель. Все они про то, что менять правила можно только по процедуре.

Технические ограничения

Регламент должен поддерживаться системой.

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

При отсутствии актуальной версии работа останавливается. При конфликте правил агент не выбирает удобный вариант, а создаёт эскалацию.

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

Из практики. Три случая, где граница держалась не на инструкции

Один документ на одну тему. В базе знаний роли нельзя держать две версии одного руководства. Поиск процитирует случайную, и вы даже не узнаете, какую именно. Никакая инструкция «используй актуальную версию» это не лечит, потому что модель не может отличить актуальную от похожей. Лечится только тем, что старые версии физически уходят в архив в тот же день.

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

Роль исполняется буквально, и это нормально. В нашем расчёте ответственного за задачу сначала определяло действие классификатора. Но два особых случая переопределяли действие уже после этого, и часть задач уровня плана уходила менеджеру по рекламе. Наставник честно копировал поле «ответственный» и складывал их не в ту зону.

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

Условия остановки

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

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

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

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

Способность остановиться это не ограничение возможностей агента. Это признак правильно спроектированной роли.

Из чего состоит полноценный ИИ-агент

Теперь можно собрать конструкцию целиком.

Роль. Определяет назначение, объект, функции, результат, потребителя и владельца ответственности.

Методология. Содержит правила, определения, классификаторы, пороги, исключения и последовательность работы.

Данные. Определяют источники, структуру, период, полноту, допустимость и владельцев качества.

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

Модель. Интерпретирует запрос, связывает результаты, формирует гипотезы, задаёт уточняющие вопросы, объясняет и адаптирует представление под получателя.

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

Права и ограничения. Определяют, что агент выполняет, что предлагает, что требует согласования и что недоступно ему технически.

Рабочий маршрут. Задаёт последовательность действий от получения входа до передачи результата.

Контроль качества. Включает приёмочные тесты, контрольные примеры, критерии правильного ответа, аудит, журнал ошибок и переаттестацию после изменений.

Эскалация. Определяет условия остановки, получателя вопроса и необходимый формат передачи.

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

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

Формула ИИ-агента

Полноценный ИИ-агент это не отдельная модель и не длинная инструкция.

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

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

Затем, если частота работы, объём данных и количество ручных переносов это оправдывают, проверенная роль переносится в API-сборку и становится частью регулярного процесса.

Главный вопрос при создании агента звучит не «какую модель выбрать» и даже не «что она умеет».

Главный вопрос другой.

Какое место агент занимает в системе управления? Что он получает, что делает, что имеет право изменить, где обязан остановиться, кому передаёт результат и кто отвечает за решение?

Следующий шаг: ИИ-агент-аналитик

Теперь можно перейти от общего устройства к конкретной роли.

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

В следующей статье разберём ИИ-агента-аналитика как полноценную управленческую конструкцию:

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

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