Как создать ИИ-агента для бизнеса

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

Ниже — практический маршрут от идеи до эксплуатации. Он подходит для агента по заявкам, внутренним знаниям, поддержке, документам и другим многошаговым сценариям. Конкретная архитектура меняется, но требования к цели, доступам, наблюдению и безопасному откату остаются.

Шаг 1. Сформулируйте результат

Фраза «создать ИИ-помощника отделу продаж» слишком широка. Её нельзя однозначно проверить. Рабочая цель выглядит так: «по новому обращению определить категорию, извлечь имя, контакт и задачу, запросить недостающее, создать черновик карточки и передать менеджеру». Отдельно перечисляются запреты: не обещать цену, не отправлять договор, не менять существующую сделку.

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

Шаг 2. Зафиксируйте текущий процесс

До разработки измерьте, как задача выполняется сейчас. Сколько обращений приходит, какие поля чаще пропускают, сколько времени занимает обработка, где возникают ошибки? Без исходной линии нельзя понять, улучшил ли агент процесс. Иногда аудит показывает, что проблему дешевле решить формой с обязательными полями или обычной интеграцией.

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

Шаг 3. Подготовьте данные и знания

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

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

Шаг 4. Спроектируйте инструменты

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

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

Шаг 5. Выберите архитектуру

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

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

Шаг 6. Подготовьте контрольные проверки до пилота

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

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

Шаг 7. Соберите прототип

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

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

Шаг 8. Запустите ограниченный пилот

Пилот получает небольшую долю задач или работает в режиме подсказки. Сотрудник видит предложение агента, исправляет его и отмечает причину. Эти данные полезнее общей оценки «нравится / не нравится». Отдельно измеряйте время проверки: если оно сопоставимо с ручным выполнением, экономии нет.

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

Шаг 9. Подготовьте эксплуатацию

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

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

Критерии приёмки ИИ-агента

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

Сколько времени и денег закладывать

Цена зависит от числа интеграций, качества данных, требуемых прав, набора контрольных проверок и требований к доступности. Диалоговый ассистент на материалах компании проще многошагового агента, который пишет в CRM и обрабатывает исключения. Текущий стартовый формат Za IT и факторы сметы разобраны в статье сколько стоит ИИ-агент.

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

Самостоятельная разработка или подрядчик

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

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

Вывод

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