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

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

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

Важно сразу: NeuroZal API — это API-ключ для программ, редакторов кода, ботов и автоматизации. Это не аккаунт ChatGPT или Claude с логином и паролем. Он не подключается в мобильном приложении ChatGPT и не заменяет подписку Plus. Один ключ открывает весь каталог из 46 моделей — модель выбирает пользователь в каждом запросе.

Почему один общий ключ — это проблема

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

Нет атрибуции расхода. Журнал запросов покажет все вызовы, но не скажет, кто их сделал. Если разработчик А гоняет Claude Opus 5 для рефакторинга, а разработчик Б запустил лёгкий скрипт на DeepSeek Flash — в журнале это один поток запросов без меток владельца.

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

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

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

Как устроен кабинет: что именно видно

Личный кабинет NeuroZal API находится по адресу api.neurozal.ru/panel. Там можно создавать несколько ключей вида sk-nz-... и управлять ими независимо.

По каждому ключу доступно:

Это и есть основной инструмент контроля. Никакой магии: просто несколько ключей вместо одного, и картина становится читаемой.

Практика: как раздать доступы в команде

Один ключ — один владелец

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

Схема для небольшой команды:

Создание ключа занимает минуту. Зато в журнале сразу видно, что ключ sk-nz-reports-bot вчера сделал аномально много запросов, а ключ sk-nz-dev-alexei молчал весь день.

Называйте ключи так, чтобы было понятно без расшифровки

Имя ключа — это единственная метка в журнале. Если назвать ключ key1, через три месяца никто не вспомнит, что это. Хорошие имена:

Соглашение простое: среда-назначение или среда-владелец. Главное — договориться внутри команды и не отступать.

Ежемесячный разбор расхода

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

Вопросы, которые помогают:

Это занимает 15-20 минут, но даёт понимание того, как команда реально использует ИИ.

Ротация ключей при уходе сотрудника

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

Именно поэтому важно разделять персональные ключи (для человека) и сервисные ключи (для конкретного приложения). Сервисный ключ не привязан к конкретному сотруднику — его не нужно менять при кадровых изменениях.

Таблица рисков: что настроить заранее

Риск Как выглядит на практике Что настроить заранее
Скрипт ушёл в цикл Баланс падает ночью, непонятно чей процесс Отдельный ключ на каждый сервис — можно отозвать точечно
Уход сотрудника Его интеграции продолжают работать Персональные и сервисные ключи разделены
Тяжёлая модель на рутине Claude Opus 5 генерирует короткие ответы на простые вопросы Выбор модели фиксируется в конфигурации сервиса, не отдаётся пользователю
Нет понимания, кто тратит Общий ключ, журнал не атрибутирован Один ключ — один владелец, понятные имена
Аномальный рост расхода Расход вырос вдвое, причина неизвестна Ежемесячный разбор по ключам, мониторинг журнала
Утечка ключа Ключ попал в публичный репозиторий Немедленный отзыв, выпуск нового ключа
Стейджинг ест как продакшн Тесты идут на тяжёлых моделях Отдельный ключ для стейджинга, лёгкие модели по умолчанию

Приёмы экономии баланса без магии

Контроль расхода — это не только учёт, но и осознанный выбор модели под задачу.

Разделяйте тяжёлые и лёгкие задачи

Каталог NeuroZal API включает модели с очень разным профилем расхода. Claude Opus 5, GPT-5.6 и Grok 4.6 тратят баланс заметно быстрее, чем Gemini 3.8 Flash, DeepSeek Flash или GPT-4o-mini. Это не значит, что тяжёлые модели плохие — они решают задачи, которые лёгким не по зубам. Но гонять тяжёлую модель на рутинных задачах — это как ездить на грузовике за хлебом.

Практическое разделение:

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

Ограничивайте размер контекста

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

Кэшируйте повторяющиеся запросы

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

Не гоняйте агента по кругу

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

Честные ограничения: что не даст сам шлюз

Было бы нечестно не сказать об этом прямо.

NeuroZal API — это шлюз к моделям, а не система управления доступом корпоративного уровня. Это означает несколько вещей.

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

Ролей и разрешений нет. Нельзя сказать «этот ключ может использовать только Gemini Flash, но не Claude Opus». Ключ открывает весь каталог. Ограничение по модели — это ответственность вашего кода: вы жёстко прописываете модель в конфигурации сервиса и не даёте её менять снаружи.

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

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

Если вам нужны жёсткие квоты и роли — их нужно реализовывать на уровне своего приложения: мидлвар, который проверяет лимиты перед отправкой запроса, или прокси, который контролирует доступ к конкретным моделям.

Практический итог

Контроль расхода на ИИ в команде — это не сложная архитектура. Это несколько простых решений, принятых заранее.

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

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

С чего начать

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

Если только начинаете — настройте это правильно с первого дня. Переделывать потом сложнее.

Документация по подключению: neurozal.ru/docs. Ответы на частые вопросы: neurozal.ru/voprosy. Вопросы по конкретным ситуациям: support@neurozal.ru.