Бюджеты, роли и аудит: четыре контура управляемости

Слово «контроль» в ИИ-системе часто сводят к одной панели. На практике разные механизмы отвечают на разные вопросы. Бюджеты ограничивают потребление. RBAC определяет, кто читает и изменяет ресурсы. Одобрения ставят выбранные рискованные вызовы на паузу. Аудит сохраняет историю действий. Если смешать эти задачи, команда может видеть красивый график расходов и одновременно пользоваться ключом с избыточными правами.

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

Бюджет: что именно ограничивается

Экран бюджета позволяет задать дневные и месячные пороги токенов и стоимости, а также RPM. Важная семантика: значение 0 означает отсутствие ограничения. Пустой на вид ноль нельзя воспринимать как «запрещено». Перед запуском установите осознанные значения или явно задокументируйте, почему ограничение снимается.

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

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

RBAC: кто может что сделать

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

Для автоматизации используйте API-ключ с ограниченной областью. Задача, которой нужен только chat, не должна получать admin:write. Сохраните владельца ключа, назначение и дату пересмотра. При смене интеграции старые учётные данные отзываются, а не остаются «на всякий случай».

Проверьте отрицательный путь: пользователь без права записи не меняет ресурс; ключ только для чтения не вызывает POST; скрытая вкладка не становится доступной через прямой URL; смена роли влияет на новую сессию. Отказ должен быть понятным и записываться без утечки секрета.

Одобрения: остановка конкретного риска

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

Аудит: история с тарифным условием

Журнал аудита помогает расследовать изменения и чувствительные операции. Официальная документация относит его доступность к Business и выше; RBAC и white-label тоже требуют подходящего тарифного права. Проверяйте активную лицензию конкретного инстанса. Старый тарифный скриншот или упоминание функции не подтверждает тарифное право сейчас.

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

Моделируемая матрица

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

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

Моделируемый сценарий превышения лимита

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

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

Тарифная ошибка 402 отличается от бюджетной 429 и запрета 403. Первая говорит о недоступном праве плана, вторая — о достигнутом лимите, третья — о полномочиях пользователя. Интерфейс и инструкция дежурного должны вести к разным владельцам; предложение «повторить позже» подходит не каждому случаю.

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

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

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

Чек-лист владельца

Назовите источник тарифа и дату проверки. Установите ненулевые осознанные пороги либо явно примите отсутствие ограничения. Разделите роли чтения и записи, выдайте автоматизации минимальные области доступа, поместите выбранные побочные эффекты под одобрение. Затем проверьте 402, 403 и 429 как разные пользовательские пути.

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

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

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