Разработка ИИ-агентов: как заказать без риска для бизнеса

Раздел

AI-агенты для бизнеса

Сложность

средняя

Обновлено

2026-05-21

Короткий ответ

Разработка ИИ-агентов для бизнеса начинается не с выбора подрядчика и не с обещания “автономного сотрудника”. Сначала владелец процесса описывает задачу, данные, допустимые tools, права записи, eval-набор, приемку и правила остановки. Только после этого можно решать, делать агента внутри, заказывать подрядчику или ограничиться workflow без агентности.

Хороший заказ на ИИ-агента похож на техническое задание для рискованной интеграции: что агент читает, что может предложить, что может записать, где нужен человек, как проверяется качество и кто поддерживает контур после запуска. Если в договоре есть только “разработка AI-агента под ключ”, но нет eval, журнала, ownership и stop rules, бизнес покупает демо, а не рабочую систему.

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

Когда заказывать разработку

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

Плохие первые заказы:

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

Если задача полностью линейная, начните со скрипта, CRM-автоматизации или RPA. Агент нужен там, где обычные правила ломаются на исключениях, документах, переписке и выборе следующего шага.

Brief для подрядчика

Минимальный brief должен быть коротким, но проверяемым.

Пример формулировки: “Агент читает карточку сделки, последние письма и approved FAQ, готовит черновик follow-up и список недостающих данных. Агент не меняет сумму, скидку, статус сделки и дату отгрузки. Менеджер подтверждает отправку. Ошибка критична, если агент обещает срок или цену без источника”.

Data package

Подрядчику не нужен полный доступ к рабочим системам в первый день. Нужен безопасный data package:

• 100-300 обезличенных примеров;
• 20-50 плохих или спорных случаев;
• список источников и владельцев;
• классы данных: публичные, внутренние, закрытые, персональные;
• правила маскирования;
• тестовая среда или выгрузка без production-записи;
• список запрещенных полей и операций.

Если данные нельзя передать подрядчику, меняется архитектура заказа: подрядчик делает контур, схемы tools, eval и интерфейс, а подключение к реальным данным выполняет внутренняя команда. Это медленнее, зато не требует раздавать внешней стороне CRM, договоры или персональные данные.

NIST AI RMF полезен как язык для такого разговора: риск управления AI относится не только к модели, но и к людям, организации, процессам и контексту применения. Поэтому data package должен описывать не только файлы, но и владельца, цель обработки, ограничение доступа и способ проверки результата.

Tools и права

OpenAI описывает agents как приложения, которые планируют, вызывают tools, взаимодействуют со specialist-частями и держат состояние для многошаговой работы: Agents SDK. Для заказчика из этого следует простой вывод: tool - это не “интеграция для удобства”, а граница риска.

Разделите tools на уровни:

Права должны проверяться в tool и API. Prompt с фразой “не делай опасного” не заменяет ACL, schema validation, allowlist, лимит вызовов и журнал. Если агент может вызвать запись, инструмент должен сам отклонять лишние поля и контекст, даже когда модель уверена.

Eval и приемка

OpenAI evals используют test data и testing criteria, чтобы проверять результат на наборе случаев: Working with evals. В заказе на ИИ-агента eval - это не техническая роскошь, а акт приемки.

Соберите три набора:

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

Пример acceptance matrix:

Приемка должна считать не только pass-rate. Важны типы ошибок, ручные правки, доля эскалаций, стоимость успешной задачи и возможность объяснить, почему агент вызвал tool.

Guardrails и human approval

В документации OpenAI Agents SDK guardrails разделены на проверки входа, выхода и tool-вызовов: guardrails. Для бизнес-заказа главное - не ограничиваться входным фильтром. Риск часто появляется внутри workflow, когда агент получил источник, решил вызвать tool или сформировал действие записи.

Минимальные guardrails:

• input filter для запрещенных данных и запросов;
• output check для обещаний, источников и формата;
• tool guardrail перед каждым write-действием;
• human approval для денег, договоров, статусов, рассылок и персональных данных;
• max steps и budget limit;
• refusal rule без источника;
• audit log с trace ID, tool input, tool output и reviewer.

OWASP checklist ориентирован на руководителей, технические, security, privacy, compliance и legal-команды, которые снижают риск быстрых LLM-внедрений: OWASP checklist. Поэтому в заказе лучше сразу назначить ИБ/юриста/reviewer для спорных сценариев, а не звать их после первого инцидента.

Договор и ownership

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

Проверьте пункты:

• кто владеет prompt, eval-набором, схемами tools и журналами;
• где хранятся данные и логи;
• можно ли использовать ваши примеры для обучения, демо или других клиентов;
• кто обновляет агента при изменении API, модели, CRM или регламента;
• как передаются секреты и кто имеет доступ к production;
• как выглядит rollback;
• какие SLA есть у поддержки;
• что считается завершением MVP.

Не принимайте формулировку “подрядчик настроит AI и передаст инструкцию” без артефактов. Нужны репозиторий или package, схема архитектуры, список tools, eval-набор, результаты прогонов, runbook, правила обновления и список известных ограничений.

Rollout по этапам

Безопасный rollout выглядит скучно:

1. Discovery: процесс, данные, риски, owner.
2. Prototype: синтетические или обезличенные примеры.
3. Shadow mode: агент готовит результат, но человек работает как раньше.
4. Draft mode: человек использует черновики агента.
5. Limited tools: read-only и один безопасный draft-tool.
6. Controlled write: запись только в узкое поле с approval.
7. Production review: регулярные eval-прогоны, логи и пересмотр ошибок.

Не добавляйте новый tool и новую модель в одном релизе. Иначе непонятно, что изменило поведение. Любое расширение прав должно проходить через eval и ручной review критичных кейсов.

Сколько стоит результат

Не считайте только стоимость разработки. Реальная стоимость ИИ-агента состоит из:

• discovery и описания процесса;
• подготовки данных;
• разработки tools и прав;
• eval-набора;
• интеграции с CRM, базой знаний или API;
• наблюдаемости и журналов;
• ручной проверки на старте;
• поддержки после изменения регламентов;
• разборов ошибок.

Дешевый подрядчик без eval и support может оказаться дороже, если после демо внутренней команде придется переписывать контур. Хороший commercial brief задает вопрос не “сколько стоит агент”, а “сколько стоит стабильная успешная задача с понятным риском”.

Чеклист

• Выбран один процесс, а не “агент для всего бизнеса”.
• Есть владелец результата со стороны заказчика.
• Подготовлены 100-300 обезличенных примеров и плохие случаи.
• Описаны разрешенные источники, tools и forbidden actions.
• Первый MVP ограничен read-only или draft mode.
• Права проверяются в tool/API, а не только в prompt.
• Есть eval-набор и acceptance matrix.
• Есть human approval для рискованных действий.
• Есть audit log, trace ID и runbook.
• В договоре закреплены prompt, eval, logs, секреты, поддержка и rollback.
• Есть stop rule: когда пилот останавливается или возвращается на доработку.

FAQ

Чем разработка ИИ-агента отличается от чат-бота?

Чат-бот в основном отвечает в диалоге. Агент получает цель, контекст и tools, может выбирать шаги и готовить действия. Из-за этого агент требует прав, eval, журнала и guardrails.

Что отдавать подрядчику сначала?

Brief, обезличенные примеры, список источников, список forbidden actions и критерии приемки. Production-доступ лучше подключать позже, через тестовый контур и узкие права.

Можно ли заказать агента без внутренней команды?

Можно заказать MVP, но владелец процесса все равно нужен внутри. Кто-то должен принимать ошибки, данные, права, rollout и решение после пилота.

Нужен ли отдельный eval-набор, если подрядчик показывает демо?

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

Что читать дальше?

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