Jak przetestowano Gemini bez ujawniania modelu ani pytań testowych

Google DeepMind przeprowadził pilotaż, w którym zewnętrzni ewaluatorzy mogli przetestować własnościowy model AI bez dostępu do jego wag, a właściciel modelu nie otrzymał dostępu do poufnych pytań testowych. Projekt ogłoszony 27 sierpnia 2026 roku objął model Gemini 2.5 Flash-Lite i został zrealizowany wspólnie z Instytutem Bezpieczeństwa AI w Singapurze, OpenMined, AVERI oraz MLCommons. Google określił go jako pierwszą podwójnie ślepą ewaluację własnościowego modelu AI klasy frontier. 1213

Pomysł jest prosty: obie strony dostarczają swoje wrażliwe zasoby do zabezpieczonego środowiska, ale żadna nie otrzymuje wglądu w sekret drugiej. To ważne, ponieważ tradycyjne testy bezpieczeństwa AI wiążą się z trudnym kompromisem. Jeśli twórca modelu zobaczy prywatne prompty, mogą one zostać zapisane, przypadkowo lub celowo wykorzystane w późniejszym treningu albo w inny sposób wpłynąć na wyniki przyszłych testów. Jeśli natomiast ewaluator otrzyma wagi modelu, uzyska dostęp do cennej własności intelektualnej i potencjalnie wrażliwych możliwości systemu.

Co testowano w pilotażu Gemini

W pilotażu wykorzystano niewielki, prywatny wybór z rodziny benchmarków MLCommons AILuminate. Według AVERI prompty nie były wcześniej udostępniane Google DeepMind. Posłużyły do sprawdzenia zachowania modelu w obszarach obejmujących m.in. pomoc w cyberatakach, zagrożenia chemiczne i biologiczne, mowę nienawiści, samookaleczenia oraz nakłanianie do popełniania brutalnych przestępstw. 1

Materiały benchmarku pozostały poufne przez cały czas trwania ewaluacji. AVERI zaszyfrowało prompty, zabezpieczone środowisko uruchomiło model i procedurę oceny, a otrzymane odpowiedzi zostały odszyfrowane i ocenione według wcześniej uzgodnionych kryteriów. Celem pilotażu było zademonstrowanie metody, a nie stworzenie publicznego rankingu modeli. Nie opublikowano ani głównych wyników liczbowych, ani wykorzystanych promptów. 1

Jak działała podwójnie ślepa konfiguracja

Ewaluację przeprowadzono w usłudze Confidential Space, należącej do Google Cloud Confidential Computing, na maszynie wirtualnej A3 Confidential VM. Zgodnie z raportem technicznym Intel TDX szyfrował i izolował pamięć operacyjną hosta, a poufny procesor graficzny NVIDIA H100 chronił wagi modelu w pamięci GPU za pomocą szyfrowania sprzętowego. Zaszyfrowane połączenia dostarczały do chronionego środowiska prompty ewaluatorów oraz zasoby modelu Google. 13

Architektura obejmowała także szyfrowane ścieżki przesyłania danych, zapory sprzętowe, tymczasowy cykl życia enklawy oraz warstwę zasad OpenMined PySyft. Model, kod wnioskowania, prompty i kod ewaluacyjny zostały połączone dopiero wewnątrz zatwierdzonej enklawy. Tam mogły wykonać wyłącznie uzgodnione obliczenia, a na zewnątrz zwracano ograniczony zakres wyników. 13

Dlaczego potrzebna była zdalna atestacja

Samo szyfrowanie nie odpowiada na pytanie, jakie oprogramowanie faktycznie działa w środku. Temu problemowi miała służyć zdalna atestacja. Zanim przekazano chronione zasoby, Google i ewaluatorzy mogli sprawdzić deklarowany proces oraz zweryfikować raport atestacyjny identyfikujący sprzęt i konfigurację enklawy. Dopiero po tej weryfikacji zaszyfrowane prompty i zasoby modelu były udostępniane środowisku. 13

Po zakończeniu testu enklawa zwróciła dozwolone wyniki ewaluacji i została wyłączona. W przyjętym modelu zaufania Google nie mógł odczytać promptów wewnątrz enklawy, a zewnętrzni ewaluatorzy nie mogli wyodrębnić wag modelu. To rozwiązanie zapewnia silniejszą ochronę niż sama umowna obietnica, że dane nie będą logowane ani ponownie wykorzystywane. Nie usuwa jednak wszystkich założeń dotyczących zaufania. 13

Jaki problem rozwiązuje ta metoda

Jednym z trwałych problemów w ewaluacji AI jest zanieczyszczenie benchmarków. Test traci wartość, jeśli model widział jego prompty podczas treningu, dostrajania lub wcześniejszych testów. MLCommons podkreśla, że wiarygodny benchmark wymaga czystych danych, udokumentowanego pochodzenia, odpowiedniego doboru próby oraz wystarczającej przejrzystości, aby inni mogli zrozumieć, jak powstały wyniki. 2024

Podwójnie ślepa ewaluacja proponuje trzecią drogę między dwoma niedoskonałymi rozwiązaniami:

• Udostępnić prompty twórcy modelu: upraszcza to wdrożenie testu, ale może ujawnić odłożone pytania i stworzyć ryzyko wycieku do kolejnych procesów treningowych.
• Udostępnić ewaluatorom wagi modelu: chroni benchmark przed bezpośrednim ujawnieniem promptów, ale zwykle jest nie do przyjęcia w przypadku własnościowych modeli frontier.
• Wykorzystać poufną enklawę: model i benchmark spotykają się w środowisku chronionym sprzętowo, a żadna ze stron nie otrzymuje tajnego zasobu drugiej w jawnej postaci.

Pilotaż pokazuje więc wiarygodny technicznie sposób na zachowanie poufności po obu stronach i jednoczesne przeprowadzenie zewnętrznego testu. Sam w sobie nie dowodzi jednak, że wynikające z niego wnioski dotyczące bezpieczeństwa są kompletne lub rozstrzygające.

Najważniejsze ograniczenia pilotażu

Był to istotny eksperyment techniczny, ale jego zakres ogranicza to, co można na jego podstawie stwierdzić.

Po pierwsze, ewaluatorzy mogli zweryfikować deklarowaną konfigurację enklawy i interfejs modelu, lecz nie mogli niezależnie zbadać własnościowych wag Google ani implementacji procesu wnioskowania. Ogranicza to możliwość sprawdzenia, czy środowisko wykonawcze zachowywało się dokładnie tak, jak zakładano, we wszystkich istotnych aspektach. 13

Po drugie, całe środowisko operacyjne nie było niezależnie odtwarzalne. Wdrożenie i infrastruktura chmurowa pozostawały pod kontrolą Google, zamiast zostać odbudowane i ponownie uruchomione przez niepowiązaną stronę. Proces atestacji nadal opierał się także na sprzęcie, oprogramowaniu układowym, systemach obsługi i infrastrukturze atestacyjnej Google Cloud. Weryfikacja wspierana sprzętowo jest silniejsza niż umowna obietnica nieprowadzenia logów, ale nie eliminuje zależności od dostawcy chmury i jego łańcucha dostaw. 13

Po trzecie, nie opublikowano ani prywatnych promptów, ani wyników liczbowych. Tajność pytań pomaga zachować ich wartość w przyszłych testach, lecz ogranicza publiczną kontrolę, porównywanie modeli i niezależne potwierdzenie merytorycznych wniosków. AVERI opisuje pracę jako ocenę jakościową oraz niewielką ocenę ilościową, a nie pełny publiczny wynik benchmarku. 1

Dlaczego to jeszcze nie jest standard branżowy

Bezpieczny sprzęt rozwiązuje tylko część problemu. Aby podwójnie ślepe testy stały się trwałą praktyką w branży, musiałyby rozwinąć się również zasady zarządzania całym procesem.

Zabezpieczenia prawne i instytucjonalne powinny określać sposób obchodzenia się z danymi, zakres dozwolonych wyników, zasady ujawniania informacji, odpowiedzialność oraz dostęp do systemu — zwłaszcza gdy testy dotyczą niebezpiecznych możliwości.

Opieka nad benchmarkiem powinna obejmować pochodzenie promptów, dobór próby, etykietowanie, dokumentację, odświeżanie zestawów i monitorowanie zanieczyszczenia. MLCommons podkreśla, że benchmark jest wiarygodny nie tylko dlatego, że jego dane pozostają tajne, lecz także dlatego, że sposób ich tworzenia i utrzymywania można obronić metodologicznie. 2025

Niezależna odtwarzalność wymagałaby rzetelnej walidacji procesu budowania środowiska, łańcucha atestacji, zasad wykonywania kodu i raportowanych wyników przez podmioty wykraczające poza dostawcę modelu oraz operatora chmury.

Skalowalność również ma znaczenie. Użyteczny standard powinien działać z różnymi twórcami modeli, architekturami, dostawcami chmury, ewaluatorami, rodzajami benchmarków i kolejnymi wersjami modeli — a nie tylko w ramach jednej niestandardowej współpracy korzystającej z jednego stosu sprzętowego.

Pilotaż Google DeepMind najlepiej traktować jako infrastrukturę dla trudniejszej formy ewaluacji AI, a nie jako ostateczną odpowiedź na pytanie, jak budować zaufanie do benchmarków. Pokazuje, że obliczenia poufne mogą ograniczyć konflikt między ochroną danych testowych a ochroną własnościowych modeli. To, czy rozwiązanie dostarczy wiarygodnych dowodów w skali całej branży, będzie zależeć od niezależnego nadzoru, dobrej metodologii benchmarków, ochrony prawnej, odtwarzalności i praktycznej wykonalności — nie tylko od kryptografii enklawy. 1320