Kauza Grok Build: žádné překvapení. Lekce o tom, jak vybírat a prověřovat AI nástroje

Médii proběhla kauza okolo nástroje Grok Build (AI programovací agent americké společnosti xAI). Bezpečnostní výzkumník vystupující pod jménem cereblab zveřejnil měření síťového provozu, které doložilo, že nástroj tiše nahrával celé git repozitáře uživatelů do cloudového úložiště výrobce (včetně historie a souborů s přístupovými klíči)^D1. V měřeném případě nástroj odeslal 5,1 GB dat tam, kde mu na zadanou úlohu stačilo 192 kB^D2. Následná analýza ukázala ještě jednu věc: nastavení soukromí v nástroji ve skutečnosti neřídilo, zda data odcházejí^D3. A schopnost odesílat v nástroji zůstala i poté, co ji výrobce „vypnul"^D4.

Tato konkrétní kauza se dala čekat. Poukazuje na vzorec chování, který je v překotně rostoucím odvětví přirozený: sběr dat je pro výrobce pohodlná výchozí volba, nástroje se vydávají rychleji, než je kdo stihne prozkoumat, a formulace v nastavení nemusí odpovídat tomu, co software skutečně dělá. Nejde o selhání jednoho výrobce (ten ostatně zareagoval během tří dnů: funkci vypnul, nástroj uvolnil jako open source a přislíbil smazání dat^D5; dokončení smazání zatím nebylo nezávisle potvrzeno^D6). Jde o vlastnost současné fáze trhu, se kterou je rozumné počítat u kteréhokoli AI nástroje.

Zdrojový kód a konfigurace infrastruktury jsou citlivé aktivum pro každou organizaci. V regulovaném prostředí se k tomu přidává odpovědnost za dodavatelský řetězec, a AI nástroj s agentem je proto nutné považovat za dodavatele s interním přístupem.

Platí to i mimo bezpečnost. Totéž měření rozhoduje o užitečnosti a nákladech: který model se hodí pro kterou práci, záleží na typu úloh, a o nasazení pro stovky lidí je třeba rozhodovat podle dat. V diskusích se místo nich často objevují dojmy a odhady, které nelze potvrdit ani vyvrátit. Tam, kde se měří, vypadá diskuse jinak. Když měla Stella Laurenzo, seniorní ředitelka AI týmu v AMD, pocit, že nástroj uvažuje méně, doložila ho analýzou 6 852 pracovních sezení: délka viditelného uvažování klesla zhruba o dvě třetiny. Výrobce následně konkrétní chyby v nastavení potvrdil^D7. Nepotřebovala k tomu přitom nic složitého: AI nástroje si záznamy sezení typicky vedou samy. Stačilo je tedy pečlivě vyhodnotit a podložit tím své tvrzení. Tentýž dojem měl bez dat podobu neověřitelné stížnosti; s daty vedl k nápravě.

Situace každé organizace je jedinečná: jiná data, jiné systémy, jiné úlohy i závazky. Proto se osvědčuje mít vlastní průběžnou praxi ověřování, ať už jako tým, vyhrazenou roli, nebo s partnerem, který ji zajistí. Jak tedy chování nástrojů odhalovat? Rozumný začátek má několik kroků:

1. Zmapovat, které AI nástroje se v organizaci reálně používají. Včetně těch, které si vývojáři pořídili sami; právě ty bývají mimo kontrolu.
2. Ověřit chování vybraného nástroje na neprodukčním projektu. U běžných klientů postačí proxy a porovnání objemu odeslaných dat s tím, co úloha vyžadovala; objem je první filtr, ne konečný verdikt.
3. Přidat do testovacího projektu soubor, který nástroj k práci nepotřebuje, a sledovat, zda přesto opustí stroj. Právě tak byla odhalena i kauza Grok Build^D8.
4. Nenechat se zmást tím, jak se přepínače jmenují, a zkoumat, co doopravdy dělají. Souhlas s trénováním a odesílání dat jsou dvě různé věci.
5. Promítnout zjištění do výběru nástrojů a do smluv. Standardní podmínky velkých dodavatelů jednotlivec nezmění; pákou je enterprise smlouva, výběr nástroje a rozhodnutí, kam který nástroj vůbec smí.
6. Uplatnit stejnou disciplínu i mimo bezpečnost. Modely a nástroje porovnávat na vlastních úlohách a datech, ne podle žebříčků a dojmů. Základem jsou záznamy sezení, které si nástroje vedou samy; kde na tom záleží, přidat i záznam vlastní, protože výrobce může své logování změnit. Teprve vlastní měření řekne, co se pro kterou práci vyplatí.

Sledovat, co nástroje skutečně dělají, je důležitou součástí bezpečné i hospodárné práce s AI a je potřebné v tom pokračovat dlouhodobě, ne jako jednorázovou reakci na mediální kauzu.