Модель с открытыми весами (open-weight) позволяет организации изучать, оценивать, менять и запускать сами веса. Но это не сертификат происхождения конкретного файла.
Путь артефакта — конкретного набора файлов модели — от репозитория до запуска в компании и есть цепочка поставки. Локальный запуск показывает, где обрабатываются запросы, но сам по себе не отвечает, кто подготовил скачанную версию и совпадает ли она с той, которую проверяла команда. Поэтому допускать нужно не название модели, а конкретный артефакт и его историю.
Что именно скачивает компания
Карточка модели — это README с описанием её назначения, ограничений, параметров обучения и оценок; она помогает понять заявления загрузчика, но не заменяет проверку самих файлов, которые реально запускаются. Происхождение (provenance) — это прослеживаемая связь между источником, точной версией, составом файлов и преобразованиями, после которых появился запускаемый артефакт. Если на любом шаге файл заменили или пересобрали, проверка прежней версии автоматически не переносится на новую.
Препринт исследовательской команды Pillar Security и Fujitsu впервые подан на arXiv 11 сентября 2026 года. Авторы описали лабораторную модификацию управляемой параметрической памяти (gated parametric memory): это не история переписки, а обученная часть модели, которая хранит выученные закономерности; управляющий механизм определяет, насколько они влияют на вычисление. В их опыте параметры памяти менялись отдельно от обычных параметров основы модели, а заданное поведение проявлялось при триггере — условии активации.
В версии v2 авторы сообщают ASR для Qwen3.8-Flash-Next с нативной подсистемой памяти PLE: 47,8% на 115 отложенных поведениях HarmBench и 64,0% на 50 отложенных поведениях AdvBench; для каждого набора обучали отдельный checkpoint. Каждую генерацию Azure GPT-4o относил к нарушению, отказу или безопасному/иному ответу; из итоговой ASR исключали hollow-ответы — повторение запроса без содержательно вредного ответа. Это лабораторные результаты одного запуска оценки на условие, а не распространённость атаки или доля реальных пользовательских запросов. Для HarmBench ±4,7 п.п. указано как bootstrap SE по 10 000 перевыборкам; для AdvBench источник не уточняет, что означает ±6,8 п.п., поэтому считать его bootstrap SE нельзя.
Для руководителя здесь важен не вывод «открытые модели опасны», а вопрос к поставке: какие компоненты входят в выбранную модель, кто и как менял их до запуска? Одно имя в карточке ответа не даёт.
Почему одной отметки о происхождении мало
Даже правдоподобная история происхождения не доказывает, что конкретные байты не менялись и что исходная версия безопасна. В исследовании публичных проектов авторы рассмотрели 16 977 уже известных уязвимых моделей; более 21 тысячи мест в коде были связаны с ними, а в таких проектах встретились 3 757 разных помеченных моделей — 22,1% выборки. Авторы отдельно отметили отсутствие признаков проверки происхождения в изученных проектах. Это данные о публичном использовании уже известных уязвимых моделей, а не подсчёт атак или корпоративных заражений.
Метод требует доступа к самим весам: на отобранных 176 checkpoint’ах из 16 семейств он верно определил направление связи «родитель—потомок» в 95,3% случаев. Это сигнал о родстве версий, а не проверка подлинности файла или детектор неизвестного вредоносного поведения. Метка базовой модели в карточке тоже не равна проверке: она может быть просто строкой, которую указал загрузчик.
Практический смысл такой проверки — выяснить, откуда взялась версия и какие звенья известны. Она дополняет, но не заменяет сверку файлов и тестирование. Неполный результат сканирования или незаполненная история — это незакрытый вопрос допуска, а не положительный сигнал.
Хэш, подпись и сборка отвечают на разные вопросы
Хэш — короткий цифровой отпечаток байтов файла. Сверка с заранее доверенным эталоном помогает заметить, что после его создания файл изменили; сама по себе она не говорит, безопасен ли эталон. Подпись исходной версии весов не подтверждает автоматически отдельный квантованный файл, который команда будет запускать. Поэтому нужно хранить эталон, сведения о подписи и результат преобразования, а не только значение хэша рядом с загруженным файлом.
Квантование — преобразование исходных весов в другой числовой формат; после него появляется отдельный файл, например в формате GGUF. Работа о воспроизводимости изучила 200 самых скачиваемых репозиториев с GGUF-файлами, из которых 198 вошли в протокол.
Для этих 198 не были обнаружены записанные входы и среда сборки. В четырёх репозиториях, где входы были раскрыты, 7 из 8 целевых квантованных файлов удалось побитово воспроизвести на x86. Но адресная правка одного из компонентов модели обошла измеренную авторами статистику.
Отсюда практический вывод: фиксировать исходную версию весов, входные файлы и среду преобразования, затем сравнивать именно итоговый файл. Даже успешная повторная сборка показывает соответствие конкретному процессу, а не отсутствие всех неизвестных изменений или триггеров.
Проверяйте поведение готового артефакта
Файл может совпадать по контрольным суммам с ожидаемым результатом и всё же плохо работать. В отдельной работе проверили 327 квантованных артефактов моделей для генерации кода, 305 из них — из официальной библиотеки Ollama. Автор нашла пять незаметно дефектных файлов в официальной выборке — 1,6% её артефактов; два более старых файла из сообщества показали ухудшение, зависящее от среды запуска.
Эта работа не измеряет долю дефектов среди всех моделей: она показывает, зачем испытывать именно готовый файл в условиях, близких к будущему запуску. Минимальная последовательность из описанного протокола — короткий базовый тест, расширенная задача, проверка во второй программной среде запуска и сравнение с независимой конверсией. Для компании тестовые задания должны отражать её сценарии применения; результат одного набора заданий нельзя считать гарантией поведения на всех входах.
Поведенческая проверка отвечает на вопрос «работает ли эта версия в проверенных ситуациях?», а не «может ли она когда-нибудь отреагировать иначе?». Даже несколько успешных тестов не доказывают отсутствие неизвестного триггера. Поэтому результаты тестов нужно хранить вместе с точной ревизией и хэшами протестированных файлов.
Допуск — последовательность проверок, а не одна отметка
Процесс корпоративного допуска должен связывать источник и именно тот артефакт, который будет работать. В рекомендации Microsoft Security Blog оценка риска учитывает происхождение модели, её назначение и пользователей. Для команды это означает: пройти шаги по порядку и не считать один успешный сигнал сертификатом безопасности.
«Открытость весов сама по себе не определяет риск ИИ-системы».
Microsoft Security Blog, 16 октября 2026 года (перевод с английского)
Например, если команда загружает веса, квантирует их и готовит внутреннего помощника, ей нужен последовательный допуск. Его можно устроить так:
- Зафиксировать источник. Записать издателя, репозиторий, точную ревизию и состав всех файлов, влияющих на вычисление.
- Сверить целостность. Получить хэши каждого файла и сверить их с доверенными значениями; проверить подпись, если она доступна. Несовпадение остановит перенос на следующий шаг.
- Проверить файлы. Просканировать каждый артефакт и отдельно отметить известные предупреждения, неполный результат или отсутствие сканирования.
- Записать преобразование. Для квантованной версии сохранить исходную версию весов, входы и среду сборки; по возможности повторить сборку и сравнить результат.
- Испытать назначение. Провести короткий базовый тест, расширенные задачи и проверки в целевой и дополнительной программной среде запуска; записать, какие сценарии проверены.
- Перенести без подмены. Во внутренний реестр — закрытый каталог допущенных моделей — перенести тот же неизменённый артефакт; рядом сохранить результаты, решение и остаточный риск.
Такой процесс разводит разные вопросы: происхождение показывает, откуда версия пришла; хэш и подпись помогают проверить целостность; воспроизведение — преобразование; сканирование — известные проблемы; поведенческие тесты — ограниченный набор задач. Запись точной версии в контролируемом реестре помогает отследить допущенный артефакт, но сама по себе не доказывает, что его нельзя незаметно заменить.
Ни одна из этих мер отдельно и даже их сочетание не доказывает, что неизвестный триггер невозможен. Но если зафиксировать именно запускаемый артефакт и не пропускать его дальше при незакрытых проверках, решение о допуске становится проверяемым, а не основанным на названии модели или месте запуска.
Для планирования тестов и внутреннего процесса сопоставьте выбранные проверки с доступными возможностями и назначением конкретной модели. Проверка нужна не ради ярлыка «безопасно», а чтобы понимать, какой файл допущен, по каким основаниям и с какими оставшимися ограничениями.
Частые вопросы
Если у модели есть хэш, значит ли это, что она безопасна?
Нет. Хэш помогает обнаружить изменение байтов относительно доверенного эталона; он не удостоверяет, что сам эталон доброкачественный, и не исключает неизвестное поведение.
Достаточно ли повторно собрать квантованную модель?
Нет. Воспроизводимость помогает проверить конкретное преобразование, но не гарантирует безопасность исходных весов; кроме того, тестовый отпечаток может пропустить целевое изменение.
Что именно фиксировать при допуске?
Источник и ревизию, состав файлов и их хэши, входы и среду сборки, результаты сканирования и сценарных тестов, а также версию, перенесённую во внутренний реестр.
Источники
- BadEngram: Backdoor Attack on Gated Memory Components in LLMs — arXiv, 11 сентября 2026 г.
- Vulnerable Models in the AI Supply Chain: An Empirical Study of Adoption, Propagation, and Usage Patterns — arXiv, 9 октября 2026 г.
- What You Sign Is Not What You Run: The Verifiability Gap in Quantized LLM Supply Chains — arXiv, 14 октября 2026 г.
- Broken on Arrival: Silently Defective LLM Artifacts in Public Model Registries and How to Catch Them — arXiv, 5 сентября 2026 г.
- Witeness/Witness Overlap: Directional Provenance Inside Open-Weight Model Families — arXiv, 24 сентября 2026 г.
- The lineage behind 69% of open models was never verified. Cisco just fingerprinted almost 900 for free — VentureBeat, 30 июля 2026 г.
- Managing open-weight model risk in enterprise deployments — Microsoft Security Blog, 16 октября 2026 г.