Когда система, использующая большую языковую модель (LLM), начинает работать с реальными данными или принимать значимые решения, формулировка «в большинстве случаев работает» больше не является приемлемым критерием. Материал Stack Overflow Blog в рамках четвёртого уровня модели зрелости систем LLM предлагает встраивать безопасность и управление непосредственно в архитектуру посредством четырёх взаимосвязанных практик: многоуровневых защитных механизмов, контроля персональных данных на каждой границе системы, защищённого от подделки журнала аудита и памяти с чётко ограниченной областью действия.
Несколько защитных механизмов вместо одной точки защиты
Материал критикует практику использования единственного фильтра для выходных данных модели и предлагает сделать каждый защитный механизм небольшим программным контрактом, который можно независимо тестировать и упорядочивать. Запросы проходят через слои, проверяющие входные данные и попытки внедрения инструкций, ограничения заземления и формат выходных данных, очистку результатов от нарушений политики или персональных данных, затем соответствие бизнес-правилам, привлечение вторичного оценщика для случаев, которые выглядят правильными, но являются ошибочными, и, наконец, оценку уверенности и определение того, будет ли решение исполнено или потребует передачи на рассмотрение человеку.
Основное правило — «отказ с остановкой»: если защитный механизм вышел из строя или стал недоступен, запрос нельзя пропускать автоматически. Каждую блокировку также следует регистрировать как эксплуатационный сигнал: внезапный рост показателя может означать атаку, ухудшение версии или ошибку развёртывания. Материал подчёркивает, что фактические ограничения должны делать недопустимые выходные данные непредставимыми, а не ограничиваться текстовыми инструкциями, которые модель может обойти.
Персональные данные обрабатываются на границах
Каждый переход между компонентами системы представляет собой границу безопасности: поступление данных, их отправка модели, запись в журналы или журнал решений и передача другой службе. Материал рекомендует централизованную классификацию чувствительности, при этом неизвестные поля по умолчанию следует считать персональными данными, а затем удалять, маскировать или токенизировать данные перед пересечением каждой границы.
В журнале решений не следует хранить полную конфиденциальную полезную нагрузку, чтобы подтвердить, на чём было основано решение. Альтернативой является отредактированное резюме с keyed hash-хешем, вычисленным с помощью HMAC и отдельного ключа для каждого арендатора. Материал отмечает, что использование обычного SHA-256 с данными с низкой энтропией, такими как адрес электронной почты или номер карты, делает обратное угадывание возможным. Также необходимо принять каноническое и стабильное представление JSON, например спецификацию JCS, чтобы повторное хеширование давало тот же результат.
Журнал аудита, который подтверждает историю, а не просто хранит записи
Материал различает эксплуатационные журналы, пригодные для отладки и допускающие ротацию либо отсутствие структурированности, и журнал аудита, предназначенный только для добавления и фиксирующий каждое решение и его причину. Такой журнал включает идентификатор решения, арендатора, полномочия, версии модели и промпта, решение, уровень уверенности и маршрут маршрутизации, а также отредактированное резюме и хешированные входные данные.
Исправления не изменяют предыдущую запись, а создают новую запись со ссылкой на заменяемую запись. Для обнаружения вмешательства записи связываются цепочкой хешей, а последовательность номеров и её полнота проверяются. Однако сама по себе цепочка не препятствует удалению хвоста или полной реконструкции журнала; поэтому материал предлагает подписывать записи и периодически публиковать контрольные точки во внешнем хранилище. Добавление также должно выполняться под блокировкой, чтобы две одновременные операции записи не создали две ветви цепочки.
Классифицированная память и граница между поставляемыми и приобретаемыми данными
В многотенантных системах память становится вопросом управления данными, а не просто функциональной возможностью. Материал предлагает отдельные категории, такие как общие знания арендатора, пространство агента, временный контекст рабочего процесса, журнал аудита, семантические знания и разговор пользователя. Для каждой категории задаются область доступа, политика чувствительности и ключ разбиения, принудительно применяемый на уровне самого хранилища данных; при этом запрещаются любые чтение или запись между арендаторами, а разговор пользователя изолируется от агентов, принимающих решения для других пользователей.
Материал также проводит различие между исходными данными, которые поставляет команда, например промптами, правилами, наборами тестов и данными заземления, и эксплуатационными данными, которые система приобретает во время работы, например памятью, сигналами отклонений и контекстом сеансов. Первые должны управляться версиями и быть недоступными для изменения во время работы, тогда как вторые можно очищать в определённых пределах без удаления журнала аудита. Любое новое поведение, выведенное из эксплуатационных данных, должно пройти проверку и тестирование до включения в последующий выпуск; согласно материалу, обучение должно быть ближе к запросу на изменение программного обеспечения, чем к неотслеживаемому побочному эффекту.
Почему эти практики важны?
Практическая ценность предложения заключается не в отдельном инструменте, а в распределении доверия между независимыми уровнями. Очистка выходных данных не заменяет проверку бизнес-правил, журнал аудита не оправдывает хранение исходных данных, а память не становится безопасной просто благодаря использованию векторной базы данных. Открытые вопросы, всё ещё требующие инженерного решения, включают определение подходящих категорий данных для каждой системы, настройку политик хранения и доступа, определение случаев, требующих проверки человеком, и доказательство того, что очистка памяти не удаляет входные данные, необходимые для принятия решения.