Как выбрать guardrails для языковой модели

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

Что именно должны делать guardrails

Guardrails — это набор ограничений вокруг языковой модели и подключённых к ней инструментов. В него могут входить проверка входящих данных, правила для ответа, проверка результата приложением и подтверждение человеком перед чувствительным действием. Я не называю это «защитой от всего»: фильтр оценивает определённые категории и сценарии, а не понимает намерения безошибочно. У Azure, например, входные и выходные фильтры настраиваются отдельно; настройки и поведение зависят от модели, приложения и выбранных порогов. Это хорошая иллюстрация: контроль состоит из нескольких точек, а не из одного волшебного переключателя. Аутсорсинг ИТ часто начинается именно с инвентаризации таких точек: кто передаёт данные, что система может прочитать и какие операции ей доступны.

Практический вопрос звучит не «есть ли у нас guardrails?», а «какое действие мы запрещаем и чем это проверяем?». Например, если помощник готовит черновик ответа, ему может быть достаточно доступа только на чтение к базе знаний. Если он способен отправить письмо, изменить карточку сделки или удалить запись, появляется отдельный риск: ошибку текста ещё можно исправить, а выполненное действие может потребовать восстановления и разбирательства. Поэтому доступ к инструментам нужно выдавать по минимуму, а операции с заметными последствиями подтверждать отдельно. В OWASP prompt injection описан как риск, когда инструкции в пользовательском или внешнем содержимом меняют поведение приложения; сам факт установки фильтра не заменяет проверки разрешений. Ирония короткая: «прочитал письмо» и «отправил его всем» — разные уровни полномочий, хотя в интерфейсе иногда стоят рядом. В матрице полезно разделить чтение и запись: доступ «только читать» тоже может раскрыть коммерческую информацию, поэтому для него нужны отдельные источник, роль и журналирование. А если системе вообще не требуется видеть клиентские документы, не передавайте их «на всякий случай» — неиспользуемые данные только расширяют последствия ошибки.

• Проверка входящих запросов и документов
• Проверка ответа до показа пользователю
• Минимальные права для подключённых инструментов
• Подтверждение рискованных действий человеком

Что даёт готовый облачный сервис

Облачный вариант разумно брать на пробу, если у вендора уже есть нужные входные и выходные фильтры, понятные настройки и удобный способ проверить их на своих примерах. В документации Azure AI Foundry описаны фильтры для входа и выхода, пороги тяжести категорий, списки блокировок и режим, который только возвращает отметки, но не блокирует текст. Последняя деталь особенно полезна при пилоте: сначала измеряем, что правило ловит и что пропускает, а затем решаем, включать ли блокировку. Наличие опции в панели не означает, что она включена на каждой модели или автоматически привязана к каждому развертыванию. Конфигурацию нужно проверить в конкретном проекте.

Сравнивать провайдеров следует не по словам «безопасный тариф», а по документации и условиям для нужного способа подключения. Уточните, какие данные проходят через API, что попадает в журналы, как долго сохраняется, кто может менять настройки, где применяются фильтры и что происходит при их недоступности. Отдельно изучите цену конкретной модели и дополнительных функций: стоимость зависит от выбранного продукта и объёма использования, поэтому универсальные «12 тысяч рублей в месяц» здесь были бы выдумкой. Не переносите цену подписки пользовательского чат-сервиса на API или на фильтр. Это разные продукты, расчётные единицы и условия. И не считайте бесплатный тест доказательством того, что бесплатный тариф годится для рабочей нагрузки.

• Проверить входные и выходные правила
• Уточнить хранение данных и журналов
• Сверить цену именно нужного API и функции
• Испытать отказоустойчивость и поведение при сбое

Когда оправдан собственный код

Своя прослойка полезна, когда правила завязаны на внутренние справочники, роли сотрудников или конкретный бизнес-процесс. Она может проверять формат полей, соответствие идентификаторов, запрещённые операции и право пользователя вызвать инструмент. Это обычная разработка приложения вокруг модели, а не собственная «магическая модель безопасности». Для персональных данных можно добавить распознавание шаблонов и сущностей, но результат надо проверять: распознаватель может пропустить значение или принять обычный текст за персональные данные. Одних регулярных выражений мало там, где значения бывают свободного формата; одного NER-детектора мало там, где нужен точный бизнес-контекст.

Собственный код добавляет постоянные обязанности: владелец правил, разбор ложных срабатываний, обновление зависимостей, журналирование, тестовые примеры и дежурный путь на случай отказа. Если автор фильтра уволился или занят другой задачей, поддержка не исчезает — она просто становится невидимой статьёй затрат. Для условной «Горизонт-Логистик» я бы сначала описал два-три процесса, которым действительно нужен доступ к модели, и оформил матрицу «роль — данные — действие — подтверждение». Потом сделал бы прототип на тестовых данных и только после проверки подключал рабочую систему. Сроки и бюджет без объёма, интеграций и требований к проверке я не обещаю: «три недели» звучит приятно, но ничего не говорит о готовности к эксплуатации.

• Назначить владельца правил и кода
• Записать допустимые роли и операции
• Собирать обезличенные примеры ошибок
• Проверить обновления и план отказа

Как считать стоимость без гадания

Сравните полную стоимость за один и тот же период и при одной и той же нагрузке. В облачной колонке учитывайте вызовы модели, отдельные фильтры, хранение журналов, передачу данных, лимиты и возможную работу при превышении квоты. В колонке собственного решения — разработку, сопровождение, проверку качества, инфраструктуру и часы сотрудников на разбор сбоев. Если гибридный вариант использует оба набора расходов, так и запишите: «облако плюс собственная интеграция». Цена API меняется вместе с тарифом, моделью и объёмом, а внутренний час специалиста не становится бесплатным только потому, что зарплата уже в бюджете.

В исходном черновике фигурировали 10 000 токенов, подписка 12 000 ₽, разработка за 40 000 ₽, поддержка за 4 000 ₽, ставка 200 ₽ в час, экономия 30 %, сроки от одного дня до четырёх недель и четыре часа ежемесячной поддержки. База знаний и первичные документы не подтвердили эти цифры для названного клиента или определённого продукта, поэтому я их убрал. Для публикации оставляю таблицу-пустышку? Нет: читателю полезнее прозрачная форма расчёта без псевдостатистики. Подставьте свои счета и часы наблюдения, а рядом запишите допущения — например, количество запросов, средний размер контекста и долю действий, требующих подтверждения. Тогда сравнение станет воспроизводимым, а не красивым числом из презентации.

• | Статья расчёта | Облако | Собственный код |
• |---|---|---|
• | Вызовы и фильтры | По счёту провайдера | Не применимо или API-затраты |
• | Разработка | Интеграция и настройка | Создание и интеграция |
• | Поддержка | Работа команды и разбор сбоев | Владелец, обновления и разбор сбоев |
• | Данные и журналы | Условия хранения и стоимость | Инфраструктура и контроль доступа |
• | Основание | Фактическое потребление | Учёт затраченных часов |

Как проверить защиту до запуска

Соберите небольшой набор реалистичных сценариев: обычный запрос, запрос с лишними данными, документ с вредной инструкцией, попытку получить чужую запись, ошибочный вызов инструмента и запрос на необратимое действие. Для каждого укажите ожидаемое поведение — ответить, отказать, запросить подтверждение или передать задачу сотруднику. Запускайте один и тот же набор через настройки облака, собственную прослойку и приложение целиком. Считайте не только заблокированные примеры, но и полезные запросы, которые система зря остановила. OWASP отдельно рассматривает prompt injection и чрезмерные полномочия агента; это аргумент тестировать не только текстовые ответы, но и реальные границы действий.

На пилоте режим «только отметить» может помочь увидеть срабатывания без блокировки, если выбранный сервис его поддерживает. Затем проверьте, что будет при недоступности провайдера: приложение должно остановить рискованное действие, показать понятную ошибку или передать работу человеку, а не молча обойти проверку. Уберите из журнала секреты и лишние персональные данные, ограничьте, кто имеет доступ к тестовым материалам, и заведите процедуру пересмотра исключений. Важный результат пилота — не скриншот зелёной панели, а перечень проверенных случаев, известных пропусков и ответственных за дальнейшее обслуживание. Если тестов нет, фраза «мы всё настроили» означает только, что кто-то нажал кнопку.

• Определить ожидаемый исход каждого сценария
• Проверить ошибочные и запрещённые действия
• Измерить ложные блокировки и пропуски
• Зафиксировать поведение при сбое

Какой вариант выбрать небольшой компании

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

Для «Горизонт-Логистик» я бы не обещал сокращение затрат до пилота. Сначала согласовал бы допустимые данные и операции, затем проверил готовые фильтры на тестовых примерах, отдельно оценил интеграционные пробелы и посчитал фактические расходы. После этого выбрал бы облачный вариант, код или комбинацию — вместе с планом поддержки и именем ответственного. Регуляторные обязанности зависят от страны, отрасли, данных и назначения системы; общего правила, обязывающего каждую компанию поставить конкретный продукт guardrails, я не нашёл. Поэтому соответствие требованиям проверяют по применимым нормам и процессам, а не покупкой тарифа. Кнопка «соответствие включено» в прайс-листах пока не появилась — и хорошо.

• Черновики без действий: начать с облачного пилота
• Нестандартные правила: оценить свою прослойку
• Доступ к операциям: ограничить права и требовать подтверждение
• Перед запуском: согласовать владельца и план поддержки

Частые вопросы