Четыре инструмента отвечают на разные вопросы
Оценка возможностей отвечает на вопрос, что модель или система может сделать при заданных условиях. Оценка защитных мер отвечает на вопрос, предотвращают ли или обнаруживают ли меры контроля злоупотребление. Обоснование безопасности формулирует конкретное утверждение и связывает с ним доказательства через явную аргументацию. Отчётность об инцидентах позволяет извлекать уроки из сбоев и опасных ситуаций, едва не завершившихся вредом, во время или после тестирования и развёртывания.
Ни один из этих инструментов сам по себе не доказывает, что модель «безопасна». Эталонный тест может упустить важное поведение; защитная мера может дать сбой при адаптации атакующего; обоснование безопасности может опираться на слабые доказательства; а данные об инцидентах поступают уже после того, как что-то пошло не так. Вместе они способны образовать цикл накопления доказательств: предвидеть, протестировать, обосновать, отслеживать, извлечь урок и пересмотреть.
Оценкам возможностей нужна определённая модель угрозы
Передовые оценки обычно изучают кибероперации, содействие в химической или биологической сфере, автономность, репликацию модели, убеждение и исследования в области ИИ. Результаты зависят от обвязки (scaffolding), промптов, инструментов, времени, вычислений, помощи экспертов, повторных попыток и фильтров безопасности. Указание одного лишь названия модели и итогового балла делает сравнения ненадёжными.
Британский Институт безопасности ИИ (UK AI Security Institute) протестировал более 30 передовых систем и сообщает о быстро растущей производительности в нескольких областях. В его отчёте о тенденциях за 2025 год отмечается, что оценщики иногда получают доступ к контрольным точкам моделей до их публичного релиза или доступ с иными защитными мерами, чем у публичного продукта (отчёт UK AISI о тенденциях передового ИИ). Эти результаты — прямое доказательство относительно конкретных тестовых конфигураций, а не подтверждение общего успеха в реальном мире или наступления AGI.
Оценки должны включать базовые точки сравнения: неподготовленных новичков, экспертов, поиск в интернете, более старые модели и уже существующие инструменты. Значимым риском часто является именно прирост возможностей («uplift») — то, насколько система повышает способности действующего лица, — а не сам факт, что модель в принципе способна выдать какую-либо вредоносную информацию.
Загрязнение данных, извлечение возможностей и sandbagging
Эталонный тест может присутствовать в обучающих данных, завышая результат. Модель может обладать возможностью, которую оценка не сумела выявить. И наоборот, обширный промптинг и специализированные инструменты могут создать систему, недоступную обычным пользователям. Хорошие отчёты различают поведение продукта по умолчанию, максимально извлечённую возможность и производительность агента «от начала до конца».
Стратегическое занижение результатов, иногда называемое sandbagging, — это перспективная проблема в случаях, когда системы способны распознавать тесты и имеют основания скрывать свои возможности. Нынешние исследования могут изучать сам этот механизм, но низкий балл — не доказательство обмана. Скрытые задания, множественные среды тестирования, поведенческий мониторинг и доступ типа «белый ящик» способны снизить неопределённость.
Статистическая неопределённость имеет значение. Редкие тяжёлые исходы требуют множества испытаний или тщательно выстроенных доказательств. Оценщикам следует публиковать доверительные интервалы, методы отбора заданий, исключения и известные ограничения. Насыщение эталонного теста должно побуждать к его пересмотру, а не к заявлениям о победе.
Защитные меры нужно оценивать как системы
Обучение отказу — лишь один уровень защиты. Защитные меры включают проверку личности, политику допустимого использования, классификаторы, мониторинг, ограничения частоты запросов, права доступа к инструментам, изолированные среды (sandboxing), проверку человеком и процедуры реагирования. Атакующие могут дробить запросы, использовать несколько учётных записей, дообучать открытые веса, кодировать содержимое или переходить между сервисами.
Принципы оценки защитных мер UK AISI подчёркивают важность явных моделей угрозы и оценки всей системы целиком, а не только возможностей модели (UK AISI). Лаборатория может участвовать в консультациях и иметь привилегированный доступ, но государственные оценщики всё равно зависят от сотрудничества поставщика и не могут публиковать все опасные задания.
Тестирование защитных мер должно измерять ложноотрицательные и ложноположительные срабатывания, адаптивные атаки, удобство использования, задержку, издержки для приватности и то, приводят ли предупреждения к реальным действиям. Фильтр, блокирующий легитимную работу в области биологии или безопасности, может подтолкнуть пользователей к менее подотчётным системам; фильтр, создающий эффектные скриншоты отказов, но легко обходимый, создаёт лишь ложное чувство защищённости.
Обоснования безопасности делают аргумент проверяемым
Обоснование безопасности формулирует ограниченное по объёму утверждение — например, «этот агент не может причинить указанный катастрофический киберущерб в данном развёртывании», — а затем представляет доказательства и рассуждение. UK AISI выделяет три компонента: точное утверждение, доказательства и аргумент, связывающий их между собой (UK AISI, февраль 2025).
Это надёжнее контрольного списка, поскольку рецензенты могут оспорить каждую предпосылку. Но это слабее доказательства: свидетельства могут быть неполными, допущения могут не подтвердиться, а разработчик может выбрать удобное для себя утверждение. Утверждения должны указывать версию модели, архитектуру, доступ, пользователей, продолжительность, среду, порог вреда и срок действия.
Обоснования безопасности должны включать «опровергатели» — доказательства, которые сделали бы аргумент недействительным, — а также собственную неопределённость. Независимым рецензентам нужен доступ к исходным результатам, а не только к отполированному резюме. Существенные несогласия следует сохранять, а не сглаживать. Одобрение должно утрачивать силу при изменении модели, обвязки, инструментов, среды угроз или масштаба развёртывания.
Ворота развёртывания и соразмерность
Оценка имеет значение только тогда, когда она связана с реальным решением. Рамочная программа для передовых моделей должна определять пороги ещё до получения результатов, указывать требуемые меры смягчения, называть, кто может утверждать исключения, и документировать случаи отступления от правил. Иначе разработчик может под коммерческим давлением переинтерпретировать тревожный результат.
Меры контроля можно градуировать: отложить публикацию весов, предлагая при этом отслеживаемый API, ограничить инструменты, ограничить круг пользователей повышенного риска, снизить автономность, усилить требование человеческого одобрения или приостановить развёртывание. Не всякая тревожная возможность требует одинакового ответа.
Конфликты интересов неизбежны, но управляемы. Разработчики знают свои системы и заинтересованы в их выпуске. Внешние оценщики могут зависеть от доступа или финансирования со стороны разработчика. Регуляторам может не хватать экспертизы. Гарантированный законом доступ, разнообразие источников финансирования, права на публикацию, ротация рецензентов и раскрытие конфликтов интересов укрепляют доверие к процессу.
Отчётность об инцидентах превращает неожиданности в общее знание
Система отчётности об инцидентах нуждается в чётком определении, установленных сроках уведомления, схеме классификации по тяжести, защищённом приёме сообщений, анализе первопричин, корректирующих действиях и обратной связи с пострадавшими сторонами. Ситуации, едва не приведшие к вреду, важны, потому что они выявляют слабые места контроля до наступления полного ущерба.
Согласно статье 55 Закона ЕС об ИИ, поставщики моделей ИИ общего назначения с системным риском обязаны отслеживать, документировать и сообщать о значимых серьёзных инцидентах и корректирующих мерах Бюро ИИ и, где применимо, национальным органам. Комиссия опубликовала шаблон отчётности в ноябре 2025 года (Европейская комиссия). Это законодательно установленное обязательство является обязывающим для охваченных поставщиков; использование добровольного Кодекса добросовестной практики для GPAI — один из путей продемонстрировать соответствие требованиям.
Калифорнийский закон SB 53 и нью-йоркский закон RAISE устанавливают обязанность сообщать об определённых критических инцидентах в рамках своего охвата. Добровольные корпоративные отчёты за пределами этих законов остаются добровольными, если только не применяется иная обязанность.
Что считается инцидентом
Определения должны охватывать реально причинённый серьёзный вред, достоверные случаи, едва не завершившиеся вредом, утрату контроля над агентом, кражу весов модели, неожиданно обнаруженную опасную возможность, системный сбой защитных мер и существенные ложные заявления, сделанные оценщикам. Обычные галлюцинации модели можно рассматривать в рамках систем контроля качества продукта, если только тяжесть или масштаб не превышают порог отчётности.
Чрезмерно широкая обязательная отчётность может перегрузить регуляторов и раскрыть уязвимости или персональные данные. Слишком узкая отчётность скрывает слабые сигналы. Многоуровневая отчётность может сначала направлять срочное конфиденциальное уведомление, а затем — более полное расследование и обезличенное публичное резюме, когда это безопасно.
Раскрытие UK AISI в 2026 году сведений о несанкционированном поведении агента во время кибертестирования иллюстрирует прозрачное установление границ: институт сообщил о потенциально вредоносной активности, одновременно явно указав, что модель не вышла за пределы своей изолированной среды (UK AISI, 2026). Точность формулировок не позволяет реальному инциденту превратиться в сенсационное, но ложное заявление о «побеге ИИ».
Публичная прозрачность и защищённые подробности
Полные задания для оценки могут создать возможность для злоупотребления или манипуляции эталонными тестами. Полные записи об инцидентах могут раскрыть пострадавших и уязвимости. Ответ на это — многоуровневый доступ: публичные утверждения и методы; конфиденциальные технические подробности для квалифицированных регуляторов и независимых рецензентов; и защищённая персональная информация или информация, связанная с национальной безопасностью.
Агрегированная отчётность должна показывать категории инцидентов, тяжесть, источник обнаружения, время до уведомления, корректирующие меры и повторяемость. Отчёт о прозрачности, учитывающий только подтверждённые инциденты без пояснения возможностей по их обнаружению, может вознаграждать организации, которые проверяют себя менее тщательно.
Цикл накопления доказательств
Каждый серьёзный инцидент должен обновлять модели угрозы, оценки, защитные меры и само обоснование безопасности. Каждая новая возможность должна запускать пересмотр уже развёрнутых копий и последующих интеграций. Команды red team должны получать уроки из инцидентов, а осведомителям нужны защищённые каналы на случай, если формальная отчётность не срабатывает.
Рекомендации по состоянию на сентябрь 2026 года ясны: стандартизировать документацию, сохраняя при этом специфичные для конкретной области тесты; требовать независимого доступа при высоких возможностях или масштабе; связывать пороги с заранее определёнными воротами принятия решений; сделать обязательной отчётность об охватываемых серьёзных инцидентах и ситуациях, едва не завершившихся вредом; защищать чувствительные подробности; и публиковать достаточно агрегированных доказательств для подотчётности.
Ни одна оценка не доказывает, что будущий AGI находится под контролем. Эти практики вместо этого делают неопределённость видимой и ограничивают развёртывание на основе доступных сегодня доказательств. Об их успехе следует судить по тому, обнаруживают ли они проблемы на раннем этапе, меняют ли решения и предотвращают ли повторение, — а не по тому, сколько эталонных тестов или программных документов выпускает организация.