Как Google DeepMind проверила Gemini, не показывая тесты и веса модели

Google DeepMind представила способ тестировать проприетарную передовую ИИ-модель так, чтобы разработчик не получал доступ к секретным промптам, а внешние эксперты — к весам модели. Пилот, о котором объявили 27 августа 2026 года, провели для Gemini 2.5 Flash-Lite совместно с Институтом безопасности ИИ Сингапура, OpenMined, AVERI и MLCommons. Google назвала его первым «двойным слепым» тестированием проприетарной модели передового класса. 1213

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

Что проверяли у Gemini

Для пилота использовали небольшую закрытую выборку из семейства бенчмарков безопасности MLCommons AILuminate. По данным AVERI, эти промпты ранее не передавались Google DeepMind. Они должны были показать, как модель ведёт себя в сценариях, связанных с помощью в кибератаках, химическими и биологическими угрозами, языком вражды, самоповреждением и попытками вызвать ответы о насильственных преступлениях. 1

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

Как работала схема «двойной слепоты»

Тестирование проходило в Confidential Space — сервисе Google Cloud Confidential Computing — на виртуальной машине A3 Confidential VM. Согласно техническому отчёту, технология Intel TDX шифровала и изолировала память хост-системы, а конфиденциальный графический процессор NVIDIA H100 защищал веса модели в собственной памяти с помощью аппаратного шифрования. Зашифрованные соединения доставляли промпты оценщиков и ресурсы Google в защищённую среду. 13

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

Зачем нужна удалённая аттестация

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

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

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

Как это связано с загрязнением бенчмарков

«Загрязнение» тестов — одна из постоянных проблем оценки ИИ. Результат становится менее показательным, если модель уже встречала тестовые промпты во время обучения, донастройки или предыдущих проверок. MLCommons указывает, что надёжный бенчмарк должен иметь чистые данные, документированное происхождение, продуманную выборку и достаточную прозрачность, чтобы другие могли понять, как получен результат. 2024

Двойное слепое тестирование предлагает третий вариант между двумя несовершенными решениями:

• Передать промпты разработчику. Это упрощает запуск проверки, но раскрывает закрытую часть бенчмарка и создаёт риск утечки в будущие версии модели.
• Передать оценщикам веса модели. Такой вариант защищает тестовые данные, но обычно неприемлем для передовых проприетарных моделей.
• Использовать конфиденциальный изолированный контур. Модель и бенчмарк встречаются в аппаратно защищённой среде, при этом ни одна сторона не получает секретный ресурс другой стороны в открытом виде.

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

Ограничения пилотного проекта

Технически это важная демонстрация, однако её результаты нужно интерпретировать осторожно.

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

Во-вторых, рабочее окружение не было независимо воспроизведено от начала до конца. Развёртывание и облачная инфраструктура оставались под контролем Google, а не сторонней организации, которая могла бы самостоятельно пересобрать и повторить эксперимент. Процесс аттестации также зависел от оборудования, прошивок, обслуживающих систем и инфраструктуры аттестации Google Cloud. Аппаратная проверка сильнее обещания «не вести журналы», но не устраняет зависимость от всей этой цепочки поставок и сервисов. 13

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

Почему это пока не отраслевой стандарт

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

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

Ответственное сопровождение бенчмарков должно включать контроль происхождения промптов, выборки, разметки, документации, обновления и мониторинга загрязнения. MLCommons подчёркивает: надёжность бенчмарка определяется не только секретностью данных, но и тем, насколько обоснованно они создаются и поддерживаются. 2025

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

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

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