Как контролировать расходы на ИИ по отделам: система без лишних трат

Почему расходы на ИИ растут незаметно

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

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

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

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

Три главных причины неконтролируемого роста расходов

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

Первое — отсутствие видимости по отделам. Когда вся трата собирается в одном счёте, невозможно понять, какой отдел использует ИИ активнее всего. Маркетинг может считать, что они экономят, потому что используют дешёвые модели, но при этом запускают сотни экспериментов. Техническая команда может использовать ИИ редко, но каждый запрос требует большого контекста. Без разбивки по отделам вы не видите, где прячется основная трата.

Второе — незнание реальной стоимости использования. Люди мыслят категориями запросов и ответов. Один запрос — одна операция. Но на самом деле цена одного запроса может варьироваться в десять раз в зависимости от того, какую модель вы использовали, сколько токенов в контексте, кэшировалась ли информация. Сотрудник видит, что запрос выполнился, но не видит, что за этим стоит 10 000 токенов, а не 100.

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

Что видимо и что скрыто в счётах на ИИ

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

Токены разных моделей стоят по-разному

Токен — это не абсолютная единица. Один токен в GPT-4 обходится дороже, чем один токен в GPT-4o mini, примерно в 20 раз. Это значит, что если сотрудник выполняет ту же задачу, но на более дорогой модели, его труд обходится вам в разы дороже.

Но это ещё не всё. Разные провайдеры считают токены по-разному. У одного 1000 токенов может соответствовать примерно 750 словам, у другого — примерно 600. Это значит, что видимый объём работы может быть одним и тем же, но счёт совершенно различный.

Сдаёшь в контекст (входные токены) одни токены. Получаешь ответ (выходные токены) — совершенно другие. И стоимость выходных часто выше входных. Если вы просто смотрите на общее количество токенов, вы упускаете детали, которые влияют на управление расходами.

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

Контекст и кэш съедают половину бюджета

Вот скрытая часть ледяной горы. Чем больше информации вы кладёте в контекст (в промпт перед вопросом), тем дороже этот запрос. Это логично: больше информации — больше токенов. Но люди часто недооценивают, насколько это может быть существенно.

Представьте задачу: извлечь информацию из документа. Документ объёмный, допустим, 20 страниц. Вы не можете быть уверены, в какой части лежит ответ, поэтому сунуть весь документ в контекст — логичное решение. Этот документ — это может быть 50 000 токенов. Ваш фактический вопрос — 100 токенов. Вы оплачиваете ответ на 100 токенов, но контекст стоит в 500 раз больше.

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

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

Большинство людей не думают о кэше. Они отправляют запросы, как приходит в голову. И упускают возможность сэкономить 20-30% расходов на уже существующие процессы.

Количество запросов не равно реальным затратам

Это частая ошибка при построении прогнозов. Менеджер смотрит: в прошлом месяце было 10 000 запросов, стоило 500 долларов. Значит, один запрос стоит 0,05 доллара. Если в этом месяце будет 15 000 запросов, стоимость должна быть 750 долларов.

На практике часто получается иначе. 15 000 запросов стоят 1500 долларов. Или даже больше. Почему? Потому что характер запросов может измениться. В апреле запросы были простые, короткие, на дешёвой модели. В мае появилась задача, которая требует GPT-4, большого контекста и нескольких попыток. Количество запросов выросло на 50%, но расходы выросли на 200%.

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

Как распределить бюджет между отделами

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

Модель оплаты: за место или за использование

Первое решение, которое нужно принять, касается того, как вы будете распределять расходы на ИИ. Есть два основных подхода.

Per-seat модель: каждый сотрудник платит фиксированную сумму в месяц. Например, 30 долларов за человека, независимо от того, использует ли он ИИ вообще или запускает 1000 запросов. Это просто администрировать, предсказуемо для бюджета, но может привести к перепотреблению. Если сотрудник знает, что он уже оплачен, то логически использовать его по максимуму, даже если это неэффективно.

Usage-based модель: платят только те, кто использует. Чем больше использует, тем больше платит. Это справедливо, стимулирует экономию, но усложняет администрирование и создаёт непредсказуемость. Отдел маркетинга может внезапно израсходовать весь квартальный бюджет за неделю.

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

Выбор модели зависит от вашей культуры и целей. Если вы хотите стимулировать использование (например, вы только начинаете с ИИ), per-seat может быть лучше. Если хотите контролировать расходы, usage-based даёт больше рычагов.

Установка лимитов для каждой команды

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

При установке лимитов нужно учитывать несколько факторов:

• Сколько людей в отделе
• Какие задачи они решают с помощью ИИ
• Какие модели им нужны (дешёвые или дорогие)
• Как часто они используют ИИ (ежедневно или раз в неделю)

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

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

Предотвращение дублирования инструментов между отделами

Когда отделы независимы в выборе инструментов, часто получается так: маркетинг подписывается на ChatGPT Plus, продажи берут Claude Pro, IT использует API OpenAI, HR экспериментирует с Gemini. Каждый за своё платит, каждый получает разный уровень доступа, разные возможности.

На первый взгляд, это даёт гибкость. На практике это создаёт:

• Множественные точки оплаты, которые сложно отслеживать
• Несогласованность в подходах (одни используют дорогие модели, другие дешёвые)
• Дублирование функционала (несколько инструментов делают одно и то же)
• Повышенные риски безопасности (данные разбросаны по разным провайдерам)

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

Например, список может выглядеть так: основной инструмент — ChatGPT Pro для организации (все отделы используют через единый аккаунт), вспомогательный — Claude API для технических интеграций, специальный — Gemini для определённого проекта (с отдельной санкцией). Каждый отдел выбирает из этого списка, но не может просто взять и подписаться на что-то ещё.

Это проще администрировать, дешевле (большие объёмы часто дают скидки), безопаснее (данные в одном месте) и проще отслеживать (вся трата в одном счёте, разбитая по отделам).

Система мониторинга и контроля

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

Инструменты для отслеживания расходов в реальном времени

Большинство провайдеров ИИ предоставляют встроенную аналитику. OpenAI показывает использование и расходы в интерфейсе. Anthropic предоставляет детальные логи. Google Gemini имеет свои инструменты.

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

Для эффективного контроля нужны либо специализированные инструменты мониторинга (которые интегрируются с провайдерами и собирают данные в одно место), либо внутренняя система логирования, которая фиксирует каждый запрос и стоимость.

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

На русском рынке специализированных решений мало. Часто приходится использовать универсальные платформы мониторинга (которые отслеживают расходы на облачные сервисы вообще) или писать собственное решение.

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

Что проверять в ежемесячном отчёте

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

Вот что должно быть в каждом месячном отчёте:

• Общая сумма расходов за месяц и сравнение с прошлым месяцем
• Разбивка по отделам с указанием доли каждого отдела в общих расходах
• Разбивка по моделям (какая модель сколько стоила)
• Топ-10 самых дорогих дней (когда были пики и почему)
• Топ-10 самых активных пользователей (кто потребляет больше всего)
• Соотношение входящих и исходящих токенов (баланс между контекстом и генерацией)
• Доля кэшированных токенов (если кэширование используется)
• Отделы, которые превысили свои лимиты или приближаются к ним

Но сами по себе цифры мало что говорят. Нужен анализ. Например, если расходы выросли на 40%, это проблема? Не всегда. Может быть, отдел продаж начал использовать ИИ для подготовки коммерческих предложений, и это привело к росту конверсии на 20%. Тогда рост расходов оправдан. Но если расходы выросли просто потому, что кто-то решил экспериментировать с дорогой моделью без видимого результата, это проблема.

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

Наблюдаемость расходов важнее красивого графика

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

Наблюдаемость — это не про визуализацию. Это про возможность быстро ответить на вопросы: что происходит, почему это происходит, что будет, если мы ничего не изменим.

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

Практический пример. Вы видите, что расходы на GPT-4 выросли в два раза. Без логирования вы не знаете, кто виноват. С логированием вы смотрите и видите: два человека из отдела маркетинга начали использовать GPT-4 для генерации черновиков статей. Раньше они использовали GPT-3.5. Вы идёте к ним, спрашиваете, почему они переключились. Оказывается, кто-то сказал, что GPT-4 лучше пишет. Вы проверяете результаты. Разницы почти нет. Вы возвращаете их на GPT-3.5 или переводите на GPT-4o mini. Проблема решена.

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

Как снизить стоимость правильно

Контроль расходов — это не только про мониторинг. Это ещё и про оптимизацию. Но оптимизация не должна быть самоцелью. Снижать расходы ради снижения бессмысленно, если это ухудшает результаты.

Подбор дешёвой модели под задачу

Разные задачи требуют разного уровня интеллекта. Написать сложный аналитический текст — это одна задача. Переформулировать предложение — другая. Первая требует GPT-4 или аналога. Вторая отлично решается моделью в 10-20 раз дешевле.

Проблема в том, что люди часто используют одну модель для всех задач. Они нашли что-то, что работает, и используют это везде. Это удобно, но дорого.

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

Вот примеры задач и подходящих моделей:

Задача	Подходящая модель	Почему
Генерация длинного аналитического текста	GPT-4, Claude Opus	Требуется глубокое понимание и связность
Извлечение данных из структурированного текста	GPT-4o mini, GPT-3.5	Простая задача, не требует сложных рассуждений
Перевод текста	GPT-4o mini, Claude Haiku	Шаблонная задача с чёткими правилами
Суммаризация документа	GPT-4o, Claude Sonnet	Нужно понимание контекста, но не глубокий анализ
Генерация кода	GPT-4, Claude Opus	Требуется точность и понимание контекста
Ответы на простые вопросы клиентов	GPT-4o mini, GPT-3.5	Шаблонные ответы на основе базы знаний

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

Переход на дешёвую модель может сэкономить 70-80% расходов на конкретную задачу. Но если качество ухудшится, эта экономия обернётся потерями. Поэтому тестирование обязательно.

Оптимизация промптов и контекста

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

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

Вот несколько принципов оптимизации промптов:

• Убирайте избыточные объяснения. Модель не нуждается в мотивации или вежливости. Если инструкция занимает 500 слов, а можно сказать то же самое в 100, используйте 100.
• Структурируйте промпт. Используйте маркированные списки, нумерацию, чёткие разделы. Модель лучше понимает структурированный текст.
• Не повторяйте информацию. Если вы уже упомянули что-то один раз, не нужно повторять снова.
• Используйте переменные. Если промпт содержит данные, которые меняются от запроса к запросу (например, имя клиента или номер заказа), выделяйте их в отдельные переменные. Так проще управлять и тестировать.

Но самая большая оптимизация касается контекста. Часто в контекст попадает информация, которая не нужна для ответа на вопрос. Например, вы хотите извлечь дату из документа. Вы суёте весь документ в контекст. Документ содержит 50 страниц, а дата находится на первой. Вы оплачиваете обработку всех 50 страниц.

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

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

Проверка качества вместе с расчётом экономии

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

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

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

Ручная проверка — это когда человек смотрит на результаты и оценивает их. Это медленнее, но часто точнее, особенно для задач, где качество субъективно (например, генерация маркетинговых текстов).

Процесс оптимизации выглядит так:

1. Выбираете процесс, который хотите оптимизировать
2. Фиксируете текущее качество (автоматически или вручную)
3. Вносите изменение (например, переходите на дешёвую модель)
4. Проверяете качество после изменения
5. Если качество не ухудшилось, оставляете изменение. Если ухудшилось, откатываете или ищете другой подход

Без этой системы оптимизация превращается в лотерею. Вы не знаете, помогли ли ваши действия или навредили.

Политика использования ИИ: как её составить

Политика использования — это документ, который объясняет сотрудникам, как правильно использовать ИИ в организации. Это не просто список запретов. Это руководство, которое помогает людям принимать правильные решения.

Политика должна отвечать на несколько вопросов:

• Какие инструменты разрешены для использования
• Какие задачи можно решать с помощью ИИ, а какие нельзя
• Какие данные можно передавать в ИИ, а какие нельзя
• Какие модели использовать для каких задач
• Как запрашивать доступ к новому инструменту или увеличение лимита
• Кто отвечает за контроль расходов и качества

Вот как может выглядеть структура типовой политики:

Разрешённые инструменты. Перечислите все инструменты, которые организация одобрила для использования. Укажите, для каких задач каждый инструмент предназначен. Например: ChatGPT Enterprise для работы с текстом и коммуникации, Claude API для технических интеграций, GitHub Copilot для разработки кода.

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

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

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

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

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

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

Типичные ошибки при управлении расходами на ИИ

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

Фокус на средней стоимости вместо распределения. Компания смотрит на среднюю стоимость запроса и думает, что всё под контролем. Но на самом деле 10% запросов могут стоить в 10 раз больше остальных, и именно эти 10% формируют львиную долю расходов. Средняя стоимость не показывает реальную картину. Нужно смотреть на распределение: сколько запросов дешёвых, сколько дорогих, где пики.

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

Отсутствие обратной связи с пользователями. Когда система контроля работает сверху вниз (финансовый департамент следит за расходами, но не общается с теми, кто использует ИИ), она неэффективна. Люди не понимают, почему их ограничивают, и сопротивляются. Нужна обратная связь: объяснять, почему лимиты установлены так, показывать, сколько стоят их запросы, обсуждать, как можно оптимизировать.

Установка слишком жёстких лимитов. Когда лимиты слишком низкие, сотрудники либо перестают использовать ИИ вообще (и теряют выгоду), либо ищут обходные пути (используют личные аккаунты, что создаёт риски безопасности). Лимиты должны быть реалистичными. Лучше установить лимит выше и отслеживать, используется ли он полностью, чем установить слишком низкий и создать конфликт.

Попытка оптимизировать всё сразу. Оптимизация — это постепенный процесс. Если попытаться оптимизировать все процессы одновременно, это создаст хаос. Лучше выбрать один-два процесса, которые дают наибольшую экономию, оптимизировать их, проверить результаты, и потом переходить к следующим.

Отказ от дорогих моделей там, где они действительно нужны. Экономия ради экономии вредна. Если задача требует GPT-4, а вы переводите её на GPT-3.5 ради экономии, результат будет хуже. Это может привести к потерям, которые превысят экономию на модели. Нужно различать, где можно экономить без потери качества, а где нельзя.

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

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

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

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

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

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

Поэтому для агентов нужен финансовый периметр — жёсткие ограничения, которые предотвращают неконтролируемый рост расходов.

Вот несколько принципов установки финансового периметра для агентов:

• Установите дневной и месячный лимит расходов для каждого агента отдельно
• Настройте автоматическую остановку, если лимит превышен
• Логируйте каждое действие агента с указанием стоимости
• Настройте алерты, если агент начинает потреблять аномально много (например, в два раза больше обычного за день)
• Используйте дешёвые модели по умолчанию, дорогие только для сложных случаев
• Тестируйте агентов на ограниченной выборке перед запуском в полном объёме

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