Согласование новой LLM-модели не требует полного аудита

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

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

Аудируйте изменение, а не знакомое окружение

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

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

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

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

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

Четыре объекта контроля получают разные паспорта

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

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

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

Статус тоже храните у объекта, а не в переписке. Практичный набор включает draft, review, approved_conditional, approved и blocked. Рядом нужны дата решения, срок действия, имя владельца, список условий и идентификаторы приложенных доказательств. Слово approved без области допуска создает ложное разрешение на любой сценарий.

NIST AI RMF делит работу с риском на Govern, Map, Measure и Manage и отдельно предупреждает, что эти функции не образуют универсальный последовательный чек-лист. Для шлюза это полезная поправка: управление и роли живут на уровне платформы, контекст описывается в сценарии, измерения относятся к версии модели, а меры реагирования связывают все объекты. Копировать весь перечень NIST в заявку на каждую модель не нужно. Нужно показать, какой объект отвечает за ожидаемый результат каждой применимой проверки.

Поставщик проходит проверку до существенного изменения

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

Для персональных данных не принимайте формулу «сервер находится в РФ» как полное заключение. Часть 5 статьи 18 Федерального закона № 152-ФЗ устанавливает требования к записи, систематизации, накоплению, хранению, уточнению и извлечению персональных данных граждан России с использованием баз данных в России при сборе через интернет. Команда должна отдельно установить, какие операции выполняет каждый участник, возникает ли трансграничная передача, на каком основании идет обработка и что попадает в логи. Это правовой анализ конкретного потока, а не свойство названия модели.

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

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

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

Модель получает технический, а не безусловный допуск

Паспорт модели доказывает ее идентичность, проверенные возможности и известные ограничения в фиксированной тестовой среде. Он не дает разрешения отправлять модели любые данные и принимать ее ответы в любом процессе. Это различие прекращает спор, в котором ML-команда показывает высокий балл качества, а юрист отвечает вопросом о персональных данных: оба говорят о разных объектах.

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

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

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

Одна из самых дорогих ошибок выглядит буднично. Команда тестирует новую модель на ста примерах поддержки, получает лучшее качество и заменяет алиас в шлюзе. Через неделю выясняется, что модель чаще заключает JSON в поясняющий текст. Парсер берет пустой объект, система подставляет значения по умолчанию, а оператор видит формально успешную обработку. Это не «галлюцинация», а непроверенный контракт между моделью и кодом. Тест результата без теста формы ответа такой сбой не поймает.

Сценарий определяет допустимый риск

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

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

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

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

Условие допуска формулируйте так, чтобы его мог проверить шлюз или прикладной сервис. «Использовать ответственно» не проверяется. «Разрешить только группе support_l2, маскировать поля phone и email, запретить инструменты записи, хранить тело запроса семь дней, отправлять пять процентов трафика» уже похоже на исполнимую политику. Конкретные сроки и доли выбирает риск-владелец для своего процесса, а не автор общего регламента.

У каждого решения есть один владелец

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

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

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

Для каждого условия назначьте того, кто его закрывает, того, кто проверяет, и дату. Формулировка «доработать мониторинг до запуска» должна превратиться в задачу с проверяемым результатом: метрика создана, порог указан, оповещение доставлено дежурной смене, тестовое нарушение видно в журнале. Пока доказательства нет, статус остается условным или заблокированным.

Разделяйте консультирование и принятие риска. ML-инженер может объяснить ограничение модели, но не должен единолично принимать юридический риск обработки данных. Юрист может определить условие договора, но не подтверждает устойчивость JSON-ответа. Такая граница не замедляет решение. Она прекращает бесконечные возвраты заявки человеку, который не мог дать нужное подтверждение.

Пакет изменения собирает машина

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

Минимальная запись может выглядеть так:

{
  "change_id": "llm-2026-041",
  "platform_baseline": "gateway-3.8",
  "provider_ref": "provider-ru-07",
  "model_id": "vendor/model-2026-04",
  "use_case": "support_reply_draft",
  "data_classes": ["internal", "masked_personal"],
  "tools": [],
  "decision": "approved_conditional",
  "conditions": {
    "traffic_percent_max": 5,
    "human_review": "required",
    "blocked_fields": ["passport_number"],
    "expires_at": "2026-08-31"
  },
  "evidence": {
    "eval_report_sha256": "<sha256>",
    "provider_review": "pr-118"
  },
  "owners": {
    "model": "ml-platform",
    "use_case": "support-operations",
    "risk": "service-owner"
  }
}

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

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

Запрос к каталогу допуска перед отправкой трафика может возвращать короткий ответ:

{
  "allowed": false,
  "reason_codes": ["MODEL_VERSION_NOT_EVALUATED"],
  "required_action": "attach_eval_report",
  "decision_ref": "llm-2026-041"
}

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

Условный допуск ограничивает неизвестность

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

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

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

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

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

Полный аудит возвращается при смене границы доверия

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

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

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

В RU LLM модели проходят через единый OpenAI-совместимый эндпоинт, а маскирование PII и аудит-трейлы встроены в запросы; это позволяет зафиксировать общие платформенные контроли отдельно от допуска конкретной модели и сценария. При выборе внешнего маршрута или модели на собственной GPU-инфраструктуре команда все равно должна записать фактический путь обработки в паспорте изменения.

Создайте матрицу влияния: строки содержат типы изменений, столбцы четыре паспорта, а ячейка указывает reuse, review или invalidate. Утверждает матрицу тот же орган, который принимает архитектурные исключения. Тогда инициатор заранее знает пакет, а аудитор видит, почему часть доказательств была унаследована.

Скорость измеряют временем до обоснованного решения

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

Установите срок обслуживания для каждой проверки, но запускайте их параллельно только при достаточных входных данных. Юрист может изучать условия поставщика, пока ML-команда прогоняет тесты модели, а владелец сценария описывает данные и последствия. Финальное решение собирается после закрытия обязательных зависимостей, не после последовательного хождения документа по почте.

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

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

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

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

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

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

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

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