Роли и доступы в LLM-платформе: минимальный набор прав

Где возникает риск без ролей

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

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

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

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

Служба безопасности чаще страдает не от нехватки полномочий, а от нехватки следов. Если команда не ведет аудит действий, ИБ видит только последствия: вырос трафик, изменились настройки, появились новые токены. Причину приходится искать вручную. Даже если платформа хранит аудит-трейлы и логи в одном месте, общий доступ все портит: под одним именем могут работать сразу несколько человек.

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

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

Какие зоны доступа стоит разделить

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

Сначала отделите секреты от всего остального. API-ключи провайдеров, внутренние service accounts, токены для CI и интеграций должны жить в своем контуре. Человек может работать с моделями, тестировать промпты и смотреть метрики, но не должен читать, экспортировать или перевыпускать секреты без отдельного права. Это заметно снижает риск тихой утечки.

Доступ к списку моделей и доступ к маршрутизации - тоже разные вещи. Большинству команд достаточно видеть, какие модели доступны, сколько они стоят, какая у них задержка и лимиты. А вот менять fallback, приоритеты провайдеров, prompt caching, балансировку и правила для продового трафика должна узкая группа. Один неверный переключатель легко меняет и счет, и поведение приложения.

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

Для российских команд это не бюрократия. Если платформа работает с персональными данными и хранит логи в РФ, как RU LLM, доступ к сырым журналам и доступ к audit trail лучше развести сразу, а не после первой проверки.

Биллинг и лимиты тоже стоит вынести в отдельный блок. Закупкам и финансам нужны суммы, квоты, ставки, инвойсы и история списаний. Им не нужны API-ключи, тексты промптов или детальные трассировки. Руководителю команды можно дать право ставить месячный лимит на проект, не открывая ему платежные документы по всем подразделениям.

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

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

Что дать разработчикам

Разработчику не нужен полный доступ ко всей LLM-платформе. Ему нужен набор прав, который помогает писать, тестировать и поддерживать сервис, но не дает трогать чужие проекты, деньги и журналы контроля.

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

На практике разработчику обычно хватает четырех групп прав:

• создавать и отзывать API-ключи только для своих сервисов и тестовых окружений;
• смотреть каталог моделей, лимиты, квоты и ошибки запросов по своим проектам;
• проверять совместимость SDK, промптов и маршрутов после смены base_url;
• запускать evaluation на тестовых данных без боевых персональных данных.

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

Работу с ключами лучше ограничить рамками конкретного сервиса. Если backend-команда ведет чат-бот для поддержки, ей не нужен доступ к ключам аналитического сервиса или внутреннего помощника юристов. Так риск утечки ниже, а разбор инцидентов проще.

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

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

Что разработчику точно не нужно: счета, акты, тарифные условия провайдеров, договоры, B2B-инвойсы и журналы безопасности на уровне всей компании. Эти права почти никогда не помогают писать код, но часто создают лишний риск.

Небольшой пример. Команда мобильного банка подключает новый сценарий через единый OpenAI-совместимый эндпоинт. Разработчик создает отдельный ключ для тестового сервиса, смотрит ошибки запросов, гоняет evaluation на обезличенных примерах и проверяет, что старый SDK работает без правок. На этом набор прав можно остановить.

Что дать аналитикам

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

Минимальный набор прав выглядит так:

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

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

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

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

Чего давать не стоит: изменение маршрутов моделей, лимитов, правил хранения, маскирования и любых настроек, которые влияют на прод. Аналитик не должен создавать ключи, видеть секреты, включать новые модели или менять retention логов. Это уже зона разработчиков, администраторов и ИБ.

Если платформа поддерживает аудит-трейлы и маскирование PII, доступ для аналитиков можно сделать широким по метрикам и узким по данным. Это разумный компромисс: команда получает понятную картину по расходам и качеству, а чувствительная часть системы остается закрытой.

Что дать службе безопасности

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

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

Второе право - проверка маскирования PII и сроков хранения логов. ИБ не обязана читать содержимое всех промптов. Ей важнее понимать, что персональные данные маскируются, что логи живут ровно столько, сколько разрешено политикой, и что удаление или архивирование идут по правилам. Для платформ вроде RU LLM это особенно удобно: аудит-трейлы, маскирование PII и метки AI-Law встроены в каждый запрос, поэтому ИБ может проверять контрольные точки без доступа к лишним данным.

Обычно этой роли хватает такого набора:

• read-only доступ к аудит-трейлам запросов и админ-действий;
• просмотр списка активных API-ключей, сервисов и окружений;
• просмотр статуса маскирования PII и настроек хранения логов;
• согласование списка разрешенных моделей для команд и окружений;
• просмотр истории изменений политик доступа.

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

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

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

Что дать закупкам

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

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

Для ежедневной работы закупкам обычно нужны такие права:

• просмотр расходов по моделям, провайдерам, командам и проектам;
• просмотр лимитов, истории пополнений, закрывающих документов и счетов;
• сверка B2B-инвойсов в рублях с фактическим потреблением;
• просмотр прогноза затрат на месяц или квартал;
• экспорт агрегированных отчетов без содержимого запросов.

Эти данные лучше показывать в укрупненном виде. Закупкам полезно знать, что проект А вырос с 80 000 до 140 000 рублей в месяц после перехода на другую модель. Им не нужно видеть, какой промпт отправлял разработчик и какой ответ вернула модель.

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

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

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

Если платформа работает через единый API-шлюз, как RU LLM, этой роли особенно полезны отчеты по провайдерам, командам и B2B-инвойсам в рублях. Для закупок это уже достаточный уровень доступа.

Как собрать матрицу прав по шагам

Матрица прав начинается не с названий ролей, а с обычного рабочего дня. Разработчик выпускает сервис в тест, аналитик смотрит ответы модели, служба безопасности проверяет логи и маскирование PII, закупки следят за лимитами и счетами. Когда вы записываете именно эти действия, лишние доступы видны сразу.

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

Дальше идите по простому порядку:

1. Выпишите действия, которые люди делают каждый день. Не "администрирование платформы", а конкретные вещи: создать ключ для сервиса, посмотреть ошибки по запросам, проверить месячный расход.
2. Привяжите каждое действие к объекту доступа. "Посмотреть ошибки" связано с логами, "поднять лимит" - с квотами, "сменить модель" - с настройками проекта.
3. Дайте чтение только там, где без него работа реально встанет. Если аналитик строит отчеты по качеству, ему не нужен доступ к ключам. Если закупки контролируют бюджет, им не нужны промпты и ответы с данными клиентов.
4. Назначьте отдельно владельца ключей и владельца лимитов. Это разные риски. Один человек не должен и выпускать продовые ключи, и бесконтрольно поднимать квоты.
5. Проверьте матрицу на одном пилотном сервисе. Так быстро видно, где права мешают работе, а где их слишком много.

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

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

В платформах вроде RU LLM такой подход особенно удобен: можно проверить права на одном проекте, не меняя SDK, код сервиса и привычные промпты. Это снижает риск ошибки, пока вы доводите матрицу до рабочего состояния.

Пример для команды из четырех ролей

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

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

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

Служба безопасности проверяет другое. Она открывает журналы аудита, смотрит, кто менял ключи, кто повышал лимиты и какие запросы система пометила как содержащие PII. Если платформа умеет маскировать PII и хранить аудит внутри РФ, как RU LLM, служба безопасности может сверить, что правила реально сработали, а не просто включены в настройках.

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

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

Где чаще ошибаются

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

Самый частый промах - полный доступ к логам "на всякий случай". В логах могут лежать тексты запросов, ответы моделей, служебные поля, метки по проектам и части пользовательских данных. Аналитику обычно не нужны сырые логи целиком. Ему хватает агрегатов, метрик качества и выборки без чувствительных полей. Разработчику тоже редко нужен доступ ко всем логам компании. Обычно ему достаточно логов своего сервиса и своего окружения.

Вторая ошибка - один API-ключ на несколько сервисов. Так часто делают, чтобы быстрее стартовать. Потом никто не может понять, какой сервис сжег бюджет, кто отправил проблемный запрос и где сломалась интеграция. Один сервис, одно окружение, один ключ. Иначе аудит превращается в догадки.

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

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

Еще одна слабая точка - никто не фиксирует, кто утвердил новую модель. Потом служба безопасности спрашивает, кто разрешил модель без нужных ограничений по данным или без проверки юридических условий, а ответа нет. Даже если платформа хранит аудит-трейлы, как RU LLM, команда должна заранее решить, кто подает запрос на новую модель, кто согласует и в каком проекте она доступна.

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

Что проверить перед запуском и что делать дальше

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

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

Короткий чек перед запуском

• Сверьте для каждой роли три действия: чтение, изменение, выгрузка.
• Оставьте полный доступ к логам и PII очень узкому кругу людей.
• Проверьте, что платформа пишет аудит-трейлы и для запросов, и для действий администратора.
• Разведите бюджеты, лимиты и инвойсы отдельно от API-ключей.
• Убедитесь, что удаление, экспорт и смена ролей требуют отдельного подтверждения.

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

Если вы работаете через RU LLM, логично начать с того, что уже есть в платформе: аудит-трейлы по запросам, маскирование PII, хранение логов и бэкапов в РФ, биллинг и поддержка внутри страны. Это убирает часть ручной работы на старте. Дальше отдельно проверьте, кто видит немаскированные данные, кто может выпускать новые API-ключи и кто утверждает расходы.

После запуска

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

Раз в месяц полезно делать короткую сверку:

• кто получил новую роль;
• кто не использовал доступ 30-60 дней;
• кто видит сырые логи и зачем ему это сейчас.

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