Esports Integrity Commission (ESIC) 29. listopada predstavio je CPU v CPU Gold Standard, standard za automatizirana natjecanja čiji se rezultati koriste u ponudi klađenja. U takvim mečevima natjecateljima upravlja softver. Standard određuje kako operator mora evidentirati verzije programa i modela, kontrolirati promjene te sačuvati tragove na temelju kojih se može istražiti sporni rezultat.
Certifikat nije regulatorna dozvola za priređivanje klađenja. ESIC njime procjenjuje usklađenost s propisanim zahtjevima u obuhvaćenom proizvodu i poslovnim procesima. Ne jamči buduću usklađenost, rad bez prekida ni odsutnost sigurnosnih propusta. Iz certifikata se zato ne može zaključiti da je prijevara nemoguća ili da je ESIC legalizirao neki proizvod za klađenje.
Što se natječe u CPU protiv CPU meču?
Oznaka CPU protiv CPU ovdje opisuje natjecanje softverski upravljanih sudionika u igri, a ne usporedbu brzine dvaju procesora. Odluke može donositi lokalno postavljen model strojnog učenja, vanjski veliki jezični model (LLM) preko API-ja ili unaprijed definiran algoritam. Upotreba generativne umjetne inteligencije stoga nije uvjet za ovaj format.
To treba odvojiti od turnira na kojima igraju ljudi. ESIC već ima zaseban Gold Standard za esports proizvode namijenjene klađenju u kojima se natječu zaposleni igrači. Novi standard bavi se automatiziranim natjecanjem i sustavima koji upravljaju njegovim sudionicima. Također je odvojen od disciplinskih postupaka protiv igrača, poput slučaja NOMERCY o kojem smo ranije pisali.
Kod automatiziranog meča gledatelj iz samog prijenosa ne mora vidjeti da je promijenjena verzija modela, postavka ili korisnički račun s administratorskim ovlastima. Zato operator prije početka mora zabilježiti što točno pokreće meč, ograničiti promjene tijekom izvođenja i omogućiti naknadnu provjeru.
Tri vrste softvera, različite provjere
Za lokalni model koji organizacija trenira, posjeduje i sama postavlja standard traži kriptografski potpis i provjeru njegove valjanosti. Neuspjela provjera mora spriječiti pokretanje modela. Postavljanje odobravaju dvije ovlaštene osobe, a evidencija povezuje verziju, kriptografski sažetak datoteke i tim kojem je model dodijeljen u pojedinom meču. Verzija se prijavljuje prije početka i tijekom meča ostaje zaključana.
Kod vanjskog LLM-a operator ne može potpisati samu datoteku zatvorenog modela koji se izvršava kod pružatelja usluge. Umjesto toga mora koristiti pružatelja i model iz ESIC-ova odobrenog registra, točan datirani identifikator verzije i fiksiranu API pristupnu točku. Oznaka poput „latest”, koju pružatelj može preusmjeriti na noviji model, nije dopuštena. Minimalna verzija navedena u registru određuje prihvatljivost, ali ne zamjenjuje zaključavanje jedne konkretne verzije za meč.
Prije meča prijavljuju se i postavke koje utječu na odgovore modela, uključujući sistemsku uputu i parametre generiranja. Za svaki poziv važan za meč bilježe se identifikator modela koji vrati pružatelj, vrijeme, latencija, cijela uputa i odgovor te kriptografski sažetak odgovora. Ako se vraćeni identifikator ne podudara s prijavljenim, zaustavlja se taj ciklus odlučivanja. Tijekom meča zabranjeni su pregledavanje weba i dohvat vanjskog sadržaja.
Ilustrativno, sustav koji je prijavio jednu verziju LLM-a ne smije usred meča neprimjetno prijeći na drugu zato što je pružatelj promijenio zadanu postavku. Ti zapisi omogućuju provjeru korištene usluge i ulaznih podataka. Ne znače da se svaki odgovor vanjskog modela može savršeno ponoviti.
Za deterministički algoritam prijavljuju se točna verzija programa i kriptografski sažetak, koji također ostaju nepromijenjeni. Isti ulaz mora dati isti izlaz, osim izričito prijavljenih slučajnih komponenti sa zabilježenom početnom vrijednošću, odnosno seedom. Primjerice, dopuštena slučajnost mora biti dio dokumentiranog pravila, a ne skriveni dodatak. Ako ponašanje ovisi o identitetu ili svojstvima tima, taj odnos mora biti opisan i provjerljiv. Zabranjeni su neprijavljeni okidači, a pregled koda mora obuhvatiti i skrivene ili neaktivne grane programa.
Tko smije mijenjati sustav i što ostaje u zapisima?
Operator mora odvojiti okruženja za izradu, testiranje i produkcijski rad softvera. Svaka promjena koda traži prethodno odobren zahtjev od osobe izvan inženjerske funkcije i neovisni pregled. Postavljanje nove verzije traži dvostruko odobrenje i provjeru kriptografskog potpisa. Administratorski računi ne smiju biti zajednički, a pristup produkcijskim i osjetljivim sustavima zahtijeva višefaktorsku autentifikaciju.
Sam ciklus meča mora biti potpuno automatiziran, bez ručnog interveniranja. Sustav mora provjeravati tehničku ispravnost i logičku dosljednost podataka te automatski obustaviti rad kada se aktiviraju zaštite za anomalije. Ljudi i dalje održavaju infrastrukturu i istražuju incidente, prema dokumentiranim postupcima.
Centralizirani zapisi obuhvaćaju aplikacije, baze podataka, virtualne strojeve, sustave identiteta, vatrozide i pružatelje hostinga. Njihova je svrha povezati sporni rezultat s verzijom programa, pristupom sustavu ili promjenom konfiguracije. Standard traži i stalni sigurnosni nadzor, upravljanje ranjivostima te planove oporavka s tromjesečnim testiranjem obnove sustava.
Što obuhvaća 17 obveznih područja?
Objavljeni zahtjevi standarda raspoređeni su u 17 područja. Uz pravila za modele i izvođenje meča, obuhvaćaju i infrastrukturu, osoblje te prijavu sumnjivih događaja:
- Integritet modela i upravljanje modelima.
- Arhitektura aplikacije i kontrola postavljanja.
- Sigurno postavljanje i kontrola promjena koda.
- Identitet, kontrola pristupa i autentifikacija.
- Mrežna sigurnost prema modelu Zero Trust.
- Sigurnost mrežne komunikacije i API-ja.
- Sigurnost infrastrukture i smanjenje izloženosti napadima.
- Nadzor, zapisivanje događaja i mogućnost revizije.
- Upravljanje ključevima i kriptografske kontrole.
- Zaštita i povjerljivost podataka.
- Upravljanje konfiguracijom i infrastrukturom.
- Automatizirane operacije i integritet meča.
- Upravljanje ranjivostima i sustavom nakon postavljanja.
- Fizička sigurnost podatkovnih centara i usklađenost pružatelja usluga.
- Sigurnosne provjere osoblja i provjera identiteta i pozadine.
- Sigurnosne operacije i odgovor na incidente.
- Suradnja s ESIC-om i izvještavanje.
Što organizacija mora dokazati za certifikat?
Standard se odnosi na organizacije koje vode automatizirana CPU protiv CPU natjecanja i njihove rezultate daju tržištima klađenja. Za certifikaciju moraju dokazati usklađenost u svim obveznim područjima, uz kontrole primjenjive na konkretnu izvedbu, proći neovisnu reviziju i prihvatiti trajnu suradnju s ESIC-ovim nadzorom. Akreditirane organizacije moraju sudjelovati i u mreži Suspicious Betting Alert Network te prijavljivati sumnje povezane s integritetom.
ESIC na stranici novog programa navodi BETBY kao aktivnog nositelja certifikata. Na istoj stranici ograničava akreditaciju na procijenjene proizvode i operacije. Značajna neusklađenost može dovesti do suspenzije ili oduzimanja akreditacije, a sam standard podložan je daljnjim izmjenama.
Za čitanje takvog certifikata zato su bitna dva pitanja: koji su proizvod i operacije obuhvaćeni te je li akreditacija aktivna. Obveza poštovanja primjenjivih propisa o klađenju ostaje zasebna od ESIC-ove tehničke i operativne procjene.
Naslovna fotografija: Rémy / Unsplash. Ilustrativni prikaz procesora i matične ploče, ne opreme certificiranog operatora.
