Год назад большинство компаний на OpenRouter использовали ИИ в нескольких командах. Теперь масштабы охватывают целые отделы. Количество пользователей OpenRouter в командах из 10 и более человек выросло в 70 раз, а средняя организация запускает в три раза больше активных ключей API, поскольку все больше задач переносится на агентов.

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

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

Чтобы начать работу, откройте страницу Guardrails в своем рабочем пространстве для настройки политик или ознакомьтесь с документацией по правилам Guardrail Policies.

Почему мы изменили Guardrails

Мы создали первую версию Guardrails для более ранних сценариев использования: несколько команд, горстка ключей API. Сегодня мы видим сотни или тысячи сотрудников, входящих в систему через SSO, агентов для написания кода на ноутбуках каждого инженера и команды платформ, отвечающих за все сопутствующие расходы.

Этот сдвиг отразился на том, о чем нас просили клиенты:

Бюджеты на каждого сотрудника с возможностью исключений. Командам требовался стандартный ежемесячный или еженедельный бюджет для всех, плюс повышенный — для тех, кому это необходимо. Имея лишь один защитный механизм на уровень бюджета, один из клиентов был готов создать отдельный механизм примерно для 1,200 своих сотрудников.
Настройки по умолчанию, начинающиеся с консервативных. Клиенты хотели, чтобы новые участники начинали с наиболее консервативных настроек, а со временем получали больше возможностей. Старая модель работала наоборот: настройки рабочего пространства по умолчанию были максимумом, который кто-либо мог получить, и любой другой механизм мог только ужесточить их.
Единое правило для множества рабочих пространств. Компании с несколькими бизнес-подразделениями хотели один раз настроить правила ZDR, провайдеров и регионов, вместо того чтобы копировать один и тот же механизм в каждое рабочее пространство.
Способ обработки запросов. Администраторы постоянно получали запросы на увеличение бюджета или предоставление доступа к новой модели для какого-либо проекта, и хотели, чтобы одобрение происходило быстро, без необходимости все перестраивать.

Некоторые клиенты уже создали собственные внутренние рабочие процессы поверх Guardrails. Сотрудник запрашивает больший бюджет или доступ к конкретной модели для проекта, объясняет причину, и администратор одобряет запрос. Благодаря раздельным типам политик и лимитам, установленным организацией, одобрение такого запроса сводится к одному изменению. Администратор просто назначает пользователю другую политику бюджета или доступа к моделям, и она автоматически остается в рамках ограничений организации.

Ограничения организации отделены от настроек рабочих пространств по умолчанию

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

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

На практике это выглядит так: администратор организации ограничивает рабочее пространство Engineering бюджетом в 2000 долларов в месяц на человека, разрешает использование только провайдеров с поддержкой ZDR и закрывает доступ к определенной дорогой модели. Администратор рабочего пространства устанавливает настройки по умолчанию для новых участников на уровне 200 долларов в месяц со стандартными для команды моделями. Новый инженер, который присоединяется к команде, автоматически получает эти 200 долларов по умолчанию. Старший инженер, руководящий проектом с агентами, может получить 1500 долларов в месяц и доступ к большему количеству моделей. Никто в рабочем пространстве не может превысить лимит в 2000 долларов в месяц или использовать провайдера без поддержки ZDR.

Бюджет, доступ к моделям и модерация — это отдельные политики

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

Бюджет устанавливает лимит расходов в долларах США, который сбрасывается ежедневно, еженедельно или ежемесячно.
Доступ к моделям и провайдерам контролирует, какие модели и провайдеры могут использоваться, а также требования ZDR и регионам данных.
Модерация контента охватывает защиту от внедрения промптов (prompt injection), обнаружение конфиденциальной информации и пользовательские фильтры контента.

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

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

Обратная совместимость

Вам не нужно ничего менять для сохранения текущей настройки. Существующие защитные механизмы сохраняют свои идентификаторы и обеспечивают соблюдение тех же правил, а API защитных механизмов и ресурсы Terraform работают как прежде. Каждый защитный механизм теперь также отображается как отдельные политики бюджета, доступа к моделям и модерации, поэтому вы можете переносить одно рабочее пространство за раз, когда будете готовы.

Если вы управляете защитными механизмами через API или Terraform, сначала прочтите руководство по миграции на политики Guardrail Policies, так как изменения, сделанные в панели управления, не синхронизируются обратно с вашей конфигурацией.

Начало работы

Чтобы попробовать новую систему, откройте страницу Guardrails в любом управляемом вами рабочем пространстве. Ваши существующие защитные механизмы уже будут там в виде отдельных политик. Хорошим первым шагом будет увеличение бюджета одного сотрудника без изменения остальных параметров. Администраторы организации могут устанавливать ограничения на уровне всей организации в разделе Workspace-wide guardrails. Подробную информацию по настройке см. в документации Guardrail Policies.

Часто задаваемые вопросы

Что такое OpenRouter Guardrails?

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

Могу ли я устанавливать разные бюджеты на ИИ для разных людей?

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

Являются ли бюджеты общими для всего рабочего пространства?

Нет. Каждый бюджет применяется к конкретному участнику или ключу API, а не формирует общий пул. Лимит в 100 долларов в месяц означает, что каждый человек может потратить до 100 долларов.

Что происходит с моими существующими защитными механизмами?

Они продолжают обеспечивать соблюдение тех же правил и сохраняют свои идентификаторы. Каждый из них теперь также отображается как до трех отдельных политик.

Нужно ли мне миграровать на новый API?

Нет. Существующие API защитных механизмов и ресурсы Terraform продолжают работать. Конечные точки новых политик находятся рядом с ними по адресу /api/v1/guardrails/policies.

Кто может управлять политиками Guardrails?

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