Ochranná opatření pro podnikovou AI mohou být důležitější než nejpokročilejší modely

Zapomeňme na nejpokročilejší AI. Zákazníci tlačí na podniky, aby zavedly více ochranných opatření pro AI, kterou už používají, a zkušenosti s PCI DSS nabízejí užitečný vzor.

Období regulační shovívavosti vůči AI skončilo. Nedávná odhalení podnítila debaty o zpomalení vývoje nejpokročilejších modelů a zavedení povinných kontrol. Jednou z mála věcí, na nichž panuje shoda, je, že kontroly by měly být umístěny mimo modely a jejich fungování by mělo být nezávisle ověřováno.

O tom, co bude následovat, se stále diskutuje, regulační orgány však už jednají. Zákon Evropské unie o umělé inteligenci postupně zavádí bezpečnostní povinnosti, včetně odpovědnosti kupujících. Ve Spojených státech se Rámec NIST pro řízení rizik v oblasti AI prosazuje jako standard náležité péče. Celosvětově se OWASP Top 10 pro aplikace LLM stal běžným vodítkem při bezpečnostních prověrkách a certifikace ISO/IEC 42001 se začíná objevovat v dokumentech k zadávacím řízením.

To znamená, že odpovědnost nenesou jen vývojáři modelů. Bezpečnostní povinnosti a rizika se týkají také podniků, které používají již vydané modely, zejména v případech jejich vysoce rizikového využití. Nesprávné odpovědi v bezpečnostním dotazníku zákazníka nebo v odpovědi na žádost o nabídku mohou zhatit obchodní dohodu mezi firmami.

PCI DSS ukazuje cestu

Naštěstí jsme podobný příběh už zažili. Před dvaceti lety se bezpečnost webových aplikací opírala především o pravidelné audity kódu, statické analýzy a kázeň vývojářů. Poté požadavek 6.6 standardu PCI DSS, vydaný v roce 2006 a vyžadovaný od roku 2008, nařídil organizacím nakládajícím s údaji o držitelích platebních karet buď prověřovat veškerý kód aplikací, zda neobsahuje zranitelnosti, nebo zavést automatizované technické kontroly. Později možnost prověřovat kód zanikla a technické kontroly se staly povinnými.

PCI DSS však nezačínal jako zákon. Začal jako smluvní standard, který proměnil trh, pravděpodobně rychleji, než by to dokázala legislativa, protože smlouvy se prosazují rychleji než vládní zákony.

Podobně dnes organizace pociťují tlak na zavedení ochranných opatření pro nasazenou AI nikoli od regulačních orgánů, ale od zákazníků a partnerů – prostřednictvím bezpečnostních dotazníků, ustanovení v žádostech o nabídku a požadavků pojišťoven.

Vyřešte provozní problém a soulad s předpisy přijde sám

Na tento tlak může být obtížné reagovat, protože správa AI se netýká jen pravidel. Jde také o průběžné dokládání technických opatření.

Mnoho podniků, se kterými mluvím, provozuje v produkčním prostředí nejméně půl tuctu modelů a často je řetězí nebo orchestrují tak, že výstup jednoho slouží jako vstup pro další. Představte si, že byste za těchto podmínek měli doložit systémové vynucování jediné zásady – například zabránit tomu, aby výstup modelu obsahoval osobní údaje umožňující identifikaci (PII). Ruční auditování několika individuálně nastavených modelů by vývojářům zabralo spoustu času. Většina organizací navíc bojuje s neschváleným a vysoce rizikovým využíváním AI, například když zaměstnanci vkládají citlivá data do spotřebitelských nástrojů AI nebo poskytovatelé SaaS potají aktivují nové funkce AI. Odpovědnost však nese výhradně podnik.

V takto náročných situacích lze požadavky shrnout do jednoho jednoduchého úkolu: doložit, že dokážete průběžně omezovat vstupy do modelů i jejich výstupy a zaznamenávat tuto činnost pro účely ověření. Když aplikace volají modely, agenti spouštějí nástroje a modely provádějí akce nebo spouštějí pracovní postupy, je třeba kontrolovat samotnou akci – volání nástroje, požadavek API nebo spuštění pracovního postupu.

Přesuňte zabezpečení do cesty inferenčního provozu

Právě taková akce představuje kontrolní bod, který odborníci na zabezpečení aplikací už 20 let budují pro provoz aplikací. Zejména pokud inferenční provoz prochází sdílenou infrastrukturou, stává se tato cesta ideálním bodem pro kontrolu napříč modely, a dokonce i napříč neschváleným využíváním AI. Inferenční provoz AI je třeba doručovat, kontrolovat, ověřovat jeho pravost a řídit stejně jako jakoukoli jinou důležitou interakci s aplikací, a to podle toho, odkud přichází a co se snaží dělat. Na rozdíl od ručního auditování lze správu inferenčního provozu rozšířit podle potřeby.

Jak začít

S ohledem na vývoj regulace by organizace měly už nyní začít se třemi věcmi:

1. Zmapujte rozsah své odpovědnosti – od rozhraní API SaaS a hostovaných koncových bodů až po stínovou AI.
2. Oddělte bezpečnostní zásady a jejich vynucování od modelů a přesuňte je do cesty inferenčního provozu.
3. Zajistěte, aby se auditní záznamy vytvářely mimo kontrolu modelů a agentů, u nichž se prokázalo, že se pokoušejí měnit záznamy o vlastních akcích.

O tom, co se považuje za dostatečné monitorování a vynucování, se stále rozhoduje. Vaše provozní a bezpečnostní týmy však vědí, co lze skutečně vynutit, jakou cenu má daná kontrola z hlediska latence a složitosti a kde by dobře míněné pravidlo mohlo vést k nežádoucímu výsledku. Zapojte je už nyní. Bezpečnostní rizika a povinnosti spojené s využíváním AI jsou skutečné a vašim zákazníkům i vedoucím pracovníkům nepochybně záleží více na těch, kterým čelí dnes, než na hrozbách, jež zítra přinesou nejpokročilejší modely.