Один AI-агент на всю компанию: как отделы дерутся за приоритет

Компании, которые в 2024–2025 годах внедрили корпоративных AI-агентов на базе GPT-4o, Claude или собственных сборок, столкнулись с проблемой, которой не было при пилотах на один отдел. Агент, который отлично отвечал команде поддержки, начинает обслуживать ещё и продажи, юристов и финансистов — и упирается в конфликт приоритетов: чей запрос важнее, по чьему регламенту отвечать и кто платит за токены. Это не баг конкретной модели, а следствие архитектуры, где один агент делит контекст, доступы и вычислительный бюджет между командами с разными целями.

Что вообще значит «общий агент»

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

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

Где именно возникают конфликты

1. Конфликт инструкций в системном промпте

Самый частый случай. Юристы добавляют правило «никогда не интерпретируй договор», маркетинг просит «объясняй условия простыми словами». Обе инструкции живут в одном промпте, и модель выбирает между ними непредсказуемо — чем длиннее промпт, тем сильнее она игнорирует его середину. Это не гипотеза, а известное свойство длинных промптов: инструкции в начале и конце выполняются надёжнее, чем в середине.

2. Конфликт за очередь и лимиты

У любой платной модели есть лимит запросов в минуту (RPM) и токенов в минуту (TPM) на уровне API-ключа или организации. Если финансовый отдел в конце квартала запускает массовую сверку через того же агента, что и поддержка, живые обращения клиентов встают в очередь за пакетными задачами. Формально агент работает — фактически поддержка получает ответы с задержкой в минуты.

3. Конфликт доступа к данным

Самый опасный. Если база знаний общая, продажник может через агента вытащить внутренний документ по зарплатам, потому что RAG не различает, кто спрашивает. Разграничение доступа на уровне векторной базы — отдельная инженерная задача, и по умолчанию её нет.

4. Конфликт за бюджет

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

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

Три способа развести приоритеты

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

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

Как задать приоритеты явно

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

1. Развести отделы по разным API-ключам или проектам провайдера, чтобы у каждого был свой лимит RPM/TPM.
2. Клиентские запросы (поддержка, продажи) пустить через отдельную очередь с высоким приоритетом, пакетные задачи (сверки, отчёты) — через низкоприоритетную.
3. Разметить каждый запрос тегом отдела для последующего разбора затрат.
4. Разграничить доступ к базе знаний по отделу на уровне метаданных векторной базы, а не полагаться на промпт.

Кому это пригодится, а кому нет

Стоит городить разделение, если:

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

Можно обойтись одним общим агентом, если:

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

Что в итоге

Конфликт приоритетов между отделами — это не про то, какая модель умнее, а про то, кто спроектировал доступы, очереди и биллинг. Модель здесь взаимозаменяема: те же грабли ждут и на GPT-4o, и на Claude, и на локальной сборке. Решение живёт слоем выше — в оркестрации, разграничении лимитов и явных правилах, чей запрос идёт первым. Начинать с одного агента нормально; главное — заранее понимать, на каком отделе он перестанет справляться в одиночку.

* RAG (retrieval-augmented generation) — подход, при котором модель перед ответом ищет релевантные фрагменты в базе документов и отвечает с опорой на них, а не только на то, что запомнила при обучении.