AI zvyšuje efektivitu. Ale zvyšuje také odolnost?

Nasazení umělé inteligence se dnes zpravidla hodnotí podle toho, co organizaci přináší, kolik času ušetří, kolik činností automatizuje, jak sníží náklady nebo o kolik zvýší produktivitu.

To jsou jistě důležité ukazatele, avšak vypovídají především o tom, jak organizace funguje za předpokladu, že AI funguje správně. Ovšem stejně důležitá je otázka, co se s organizací stane, když AI přestane fungovat tak, jak očekává. Organizace může být po zavedení AI sice výrazně efektivnější, ale zároveň méně odolná. A právě tento rozdíl nabývá s rostoucí závislostí na AI na významu.

Poznámka: V podstatě totéž jsem psal už u cloudových služeb a RPA. A nejinak tomu bude i u AI, která rovněž představuje významné business riziko. A pokud organizace nemá zavedenou odpovídající AI governance a toto riziko dosud neidentifikovala, může být velmi překvapena ve chvíli, kdy se některý z předpokladů, na kterých její fungování stojí, přestane naplňovat.

Efektivita a odolnost nejsou totéž

Automatizace přirozeně vede k odstraňování rezerv. Proces, který dříve vykonávalo dvacet lidí, mohou po nasazení AI zvládnout pouze tři pracovníci. Náklady klesnou, doba zpracování se podstatně zkrátí a produktivita výrazně vzroste. Z pohledu managementu jde jednoznačně o zásadní zlepšení. Jenže právě tím může organizace postupně ztrácet schopnost fungovat v okamžiku, kdy AI přestane být dostupná anebo se na její výstupy nebude možné spolehnout.

Původní personální kapacita už nemusí být součástí organizace. Manuální postupy se přestanou používat a lidé, kteří je ovládali, odejdou a znalosti se postupně vytratí. A upřímně: kolik organizací má knowledge management zavedený natolik dobře, aby byly jejich klíčové znalosti skutečně zdokumentované a přenositelné?

Výsledkem tak může být zajímavý paradox, kdy výkonnost na jedné straně roste, ale odolnost na straně druhé klesá. A to je jádro problému, který lze označit jako AI dependency risk neboli riziko vznikající závislostí organizace na umělé inteligenci. Z pohledu organizační odolnosti přitom nejde o jediný typ problému.

AI může být nedostupná → může fungovat, ale poskytovat špatné výsledky → může vytvořit společný bod selhání a spustit kaskádu → člověk ji nemusí skutečně kontrolovat → chyba se může extrémně rychle škálovat → organizace nemusí znát všechny technologické a procesní závislosti AI → zdánlivě alternativní řešení nemusí být skutečně nezávislým fallbackem → organizace může postupně ztratit schopnost fungovat bez AI → a navíc může být samotná AI cílem kybernetického útoku.

Následující scénáře ukazují, že zavedení AI není jen otázkou efektivity nebo produktivity, ale také změnou rizikového profilu a odolnosti celé organizace.

Jak může organizace kvůli AI selhat

1. AI není dostupná

Nejjednodušší variantou je klasický výpadek. AI služba, model, API, cloudová infrastruktura nebo jiný podpůrný systém není dostupný. Příčinou může být technická porucha, výpadek poskytovatele, síťový problém, kybernetický útok, chyba konfigurace nebo například omezení služby ze strany dodavatele.

Takový stav se relativně dobře rozpoznává. Jednoduše řečeno: služba nefunguje. A právě v tomto okamžiku může organizace zjistit, že bez ní již nedokáže vykonávat určitou činnost v potřebném rozsahu, kvalitě nebo čase.

Řešení:

Jedním z možných řešení může být vlastní provoz některých AI modelů. Dalším je odpovídající smluvní zajištění dostupnosti služby, ověření redundance poskytovatele a především existence skutečně použitelného alternativního způsobu zajištění dané činnosti.

2. AI funguje, ale poskytuje špatné výsledky

To může být podstatně závažnější situace. Model je dostupný. API odpovídá. Monitoring nehlásí žádný výpadek. AI přesto poskytuje chybné, zkreslené nebo neaktuální výsledky. Důvodem může být například změna vstupních dat, model drift, chyba v integraci, nevhodný kontext použití, manipulace se vstupy nebo chyba v samotném způsobu použití modelu.

Z pohledu organizační odolnosti je zde zásadní rozdíl. Při klasickém výpadku organizace většinou ví, že má problém. Při chybném fungování AI to vědět nemusí. Technicky funkční systém proto může být v některých případech nebezpečnější než systém, který se jednoduše zastaví.

Řešení:

Před zavedením AI do organizace je vhodné nejprve vytvořit alespoň základní předpoklady pro její řízené používání. Organizace by měla minimálně:

• mít zdokumentované procesy a jejich vlastníky, alespoň v rozsahu, kde bude AI nasazena,
• mít zajištěnou odpovědnost za kvalitu používaných dat,
• mít zdokumentované používané AI modely, jejich účel a vlastníky,
• mít nastavený způsob kontroly jejich výstupů a detekce odchylek.

Nejde samozřejmě o kompletní výčet. Jde ale o základ, bez kterého organizace obtížně pozná, zda AI stále funguje tak, jak očekává.

3. AI se může stát Single Point of Failure a zdrojem kaskádového selhání

Každý jednotlivý proces může při zavedení AI vypadat racionálně. AI pomůže zákaznické podpoře. AI pomůže bezpečnostnímu týmu. AI pomůže právníkům. AI pomůže analytikům. AI pomůže HR. AI pomůže managementu.

Pokud ale všechny tyto činnosti postupně začnou využívat stejný model, stejného poskytovatele nebo stejnou technologickou platformu, vzniká problém na úrovni celé organizace.

Jedno selhání už neovlivní pouze jeden proces, ale může zasáhnout několik kritických funkcí současně. Navíc je třeba počítat s tím, že výstup jednoho procesu bývá často vstupem procesu dalšího. Chybný, opožděný nebo nedostupný výstup AI se tak může přenést dál a vyvolat kaskádové selhání dalších navazujících procesů.

AI tak nemusí pouze zvyšovat riziko jednotlivých procesů, ale může změnit i samotný charakter incidentu: z původně lokální události se může stát událost systémová, která se prostřednictvím společných závislostí a navazujících procesů rozšíří napříč organizací. Z lokálně přijatelné závislosti se tím může stát koncentrační riziko a z AI nový Single Point of Failure.

Řešení:

Při nasazování AI proto nestačí hodnotit jednotlivé use cases izolovaně. Je nutné sledovat společné technologické, dodavatelské a procesní závislosti a vyhodnocovat také jejich agregovaný dopad na organizaci.

4. Human in the loop nemusí znamenat skutečnou kontrolu

Často se předpokládá, že riziko automatizace vyřeší přítomnost člověka. To však nemusí být pravda. Pokud člověk dlouhodobě pouze potvrzuje doporučení systému, může se postupně stát jen formální součástí procesu. Navenek stále existuje lidský dohled. Ve skutečnosti však může docházet k automatizačnímu biasu, kdy člověk doporučení AI přestane skutečně zpochybňovat.

Otázkou proto není jen, zda je v procesu zapojen člověk, ale především, zda je tento člověk ještě vůbec schopen rozpoznat, že se AI mýlí, a v případě potřeby ji rychle zastavit a její činnost převzít.

Řešení:

Stejně jako při zajišťování kontinuity činností je vhodné pravidelně ověřovat, zda je Human in the loop skutečně funkční. Nestačí tedy pouze evidovat, že lidská kontrola existuje. Je potřeba testovat, zda člověk chybu skutečně dokáže odhalit, správně ji vyhodnotit a v případě potřeby převzít rozhodování.

5. Chyba se může šířit mnohem rychleji

Jednou z hlavních výhod AI je rychlost a škálovatelnost. Stejná vlastnost však funguje také opačně.

Pokud AI rozhoduje správně, dokáže správné rozhodnutí aplikovat ve velkém měřítku. Pokud rozhoduje chybně, dokáže stejně rychle škálovat chybu. Jedna chyba člověka může ovlivnit jeden případ. Jedna systematická chyba automatizovaného modelu může během krátké doby ovlivnit tisíce nebo miliony případů.

Riziko tedy nespočívá pouze v pravděpodobnosti chyby. Důležitá je také rychlost jejího šíření, množství případů, které může zasáhnout, a především doba, za kterou ji organizace dokáže odhalit a zastavit. To lze označit jako AI decision amplification.

Řešení:

Organizace by měla mít nastavené mechanismy, které umožní včas rozpoznat systematickou odchylku, omezit rozsah jejího šíření a v případě potřeby automatizované rozhodování rychle zastavit.

AI je totiž do značné míry multiplikátor. Pokud jsou špatně nastavené procesy, AI jejich nedostatky škáluje. Pokud jsou nekvalitní data, AI škáluje důsledky jejich nekvality. Proto je vhodné nejprve „uklidit organizaci zevnitř“ a teprve potom její fungování ve velkém automatizovat.

6. Organizace nemusí znát všechny závislosti AI

AI model nemusí být hlavní příčinou problému. Může fungovat přesně tak, jak byl navržen. Selhat může něco, na čem je závislý.

Může jít například o vstupní data, datové zdroje, přístupová oprávnění a identity, API, integrační vrstvu, síťové připojení, cloudovou infrastrukturu, externí služby, další AI modely nebo procesy, které poskytují potřebné vstupy.

Organizace proto nemusí být závislá pouze na jednom AI modelu. Ve skutečnosti může být závislá na celém řetězci technologií, služeb, dat, dodavatelů a procesů potřebných k tomu, aby AI vůbec poskytovala použitelný výsledek.

Problém vzniká ve chvíli, kdy organizace tento řetězec vůbec nezná. Pak totiž nedokáže spolehlivě určit ani možné body selhání, jejich koncentraci nebo skutečný rozsah dopadu.

Řešení:

Je potřeba provést analýzu závislostí AI a zmapovat nejen samotný model, ale také všechny významné komponenty a služby, na kterých jeho fungování závisí. Součástí této analýzy by mělo být také řízení dodavatelů a identifikace společných bodů selhání.

7. Alternativní model nemusí být skutečný fallback

Častou odpovědí na závislost na jednom poskytovateli je druhý AI model. Jenže existence druhého modelu ještě neznamená skutečnou redundanci.

Alternativní model může běžet na stejné cloudové infrastruktuře. Může využívat stejné datové zdroje. Může být dostupný prostřednictvím stejného integračního prostředí. Může využívat stejného dodavatele některé kritické služby.

Nebo může být natolik odlišný, že na něj nelze kritický proces bez další přípravy jednoduše přepnout.

Redundance tedy není totéž jako odolnost.

Záložní řešení má význam pouze tehdy, pokud organizace ověřila, že funguje i při selhání primárního řešení a že na něj dokáže v požadovaném čase skutečně přejít.

Řešení:

Nestačí alternativní model pouze deklarovat. Je třeba ověřit jeho skutečnou nezávislost, technickou použitelnost, dostupnost potřebných dat, kapacitu a především dobu nutnou k přechodu.

A stejně jako u disaster recovery plánu platí: netestovaný fallback je pouze předpoklad.

8. Organizace může postupně ztratit schopnost fungovat bez AI

Tento problém nevzniká v jediném okamžiku. Nevznikne podpisem smlouvy s poskytovatelem ani spuštěním AI modelu. Vzniká postupně.

Nejdříve AI pouze pomáhá, potom část činnosti automatizuje. Následně se díky očekávaným úsporám sníží počet lidí. Manuální postupy se používají stále méně a původní kompetence tak začnou pomalu mizet.

Organizace může mít formálně popsaný fallback proces, ale nemusí už mít dostatek lidí, kteří jej dokážou skutečně použít. Vzniká tak další forma závislosti: AI competence erosion.

Nejde o to, že by AI něco přímo pokazila. Problém vzniká pomalu. Každý další rok automatizace může zmenšovat schopnost organizace převzít proces zpět.

Po několika letech tak může být organizace na AI výrazně závislejší než v okamžiku jejího zavedení, přestože neexistoval žádný konkrétní okamžik, kdy by někdo takové zvýšení závislosti formálně schválil.

Řešení:

Jedním ze základních opatření je knowledge management. Kritické znalosti a postupy musí být zdokumentované a pravidelně ověřované v praxi. Pokud má organizace deklarovaný manuální fallback, měla by současně vědět:

• kolik lidí jej dokáže vykonávat,
• jakou mají tito lidé kapacitu,
• jak dlouho trvá přechod do manuálního režimu,
• a zda jejich schopnost danou činnost vykonávat není pouze historickým předpokladem.

9. Kybernetické útoky mohou cílit přímo na AI

Samostatnou kategorií jsou útoky zaměřené přímo na AI modely a systémy, které je používají. Patří sem například prompt injection, manipulace vstupů, zneužívání nástrojů napojených na AI nebo snaha přimět model k provedení nežádoucí operace či zpřístupnění citlivých informací.

Trik s bílým textem v PDF je dnes pouze jedním z nejjednodušších příkladů.

Podvržené instrukce mohou být ukryté například ve webových stránkách, dokumentech, datech, e-mailech nebo jiných zdrojích, ke kterým má AI přístup.

S rostoucí mírou autonomie AI systémů přitom roste i význam těchto útoků. Jiná je totiž situace, kdy AI pouze navrhne odpověď člověku, a jiná, když může samostatně pracovat s e-mailem, soubory, databázemi, objednávkami nebo jinými systémy organizace.

Řešení:

AI musí být součástí standardního řízení kybernetických rizik. Je potřeba řídit oprávnění, přístupy k nástrojům a datům, validovat vstupy a výstupy, oddělovat důvěryhodné a nedůvěryhodné zdroje a průběžně vyhodnocovat nové způsoby útoků na AI systémy.

AI resilience test

U každého kritického procesu využívajícího AI si lze položit těchto deset otázek:

1. Které kritické procesy a funkce jsou na AI závislé?
2. Na kterých datech, systémech, API, poskytovatelích a infrastruktuře je tato AI sama závislá?
3. Které další procesy používají její výstupy a co se stane, pokud budou chybné nebo nedostupné?
4. Jak dlouho dokážou kritické procesy fungovat bez AI?
5. Existuje skutečně nezávislý a otestovaný alternativní model nebo poskytovatel?
6. Existuje použitelný manuální fallback?
7. Máme pro něj dostatek lidí a mají stále potřebné kompetence?
8. Jak dlouho trvá přechod na alternativní režim a jakou kapacitu v něm organizace skutečně zvládne?
9. Co se stane, pokud AI nevypadne, ale začne poskytovat chybné výsledky?
10. Dokážeme takovou chybu včas rozpoznat dříve, než se rozšíří do dalších procesů?

Pokud organizace na některé z těchto otázek neumí odpovědět, znamená to, že pravděpodobně nezná skutečný rozsah své závislosti na AI.

A teď upřímně: na kolik z těchto otázek dokážete odpovědět a tuto odpověď si také obhájit před vrcholovým managementem? Dokážete jej přesvědčit, že máte závislost organizace na AI skutečně pod kontrolou?

Závěr

AI může výrazně zvýšit produktivitu, snížit náklady a umožnit organizaci vykonávat činnosti, které by jinak nebyly ekonomicky proveditelné. To ale ještě není organizační odolnost. Odolnost se neprojevuje v okamžiku, kdy všechno funguje podle očekávání, ale ve chvíli, kdy některý z předpokladů přestane platit.

Při zavádění AI bychom se proto neměli ptát pouze, co díky AI dokážeme dělat rychleji a levněji, ale také co už bez AI nedokážeme dělat vůbec. A možná i co dalšího přestane fungovat, pokud selže právě tato AI? Právě rozdíl mezi těmito otázkami ukazuje, zda AI pouze zvyšuje efektivitu organizace, nebo zda současně vytváří novou kritickou závislost.

Poznámka: Pokud se ptáte, zda se dá toto riziko spočítat, tak dá. Právě zde může být tradiční hodnocení rizik velmi zavádějící. Jednotlivá rizika spojená se selháním AI mohou být z pohledu vlastníků procesů samostatně hodnocena jako přijatelná a každé z nich může být pod stanovenou tolerovanou úrovní.

Pokud jsou však tato rizika vzájemně závislá na stejném AI modelu, poskytovateli nebo infrastruktuře, případně jsou samotné procesy propojené tak, že výstup jednoho tvoří vstup dalšího, jejich možné škody se mohou při společném selhání kumulovat. Celkové agregované riziko organizace se tak může dostat nad tolerovanou úroveň, přestože žádné z jednotlivých rizik tuto hranici samo o sobě nepřekračuje. A to je přesně něco, co v klasické matici rizik neuvidíte.

V Clever Risk Quantifier™ lze naproti tomu jednotlivé scénáře agregovat, jejich možné škody sčítat a výslednou expozici zobrazit prostřednictvím Loss Exceedance Curve (LEC) společně s Risk Tolerance Curve (RTC). Teprve na této úrovni může být patrné, že problém nepředstavuje jedno konkrétní použití AI, ale společná závislost více procesů a možnost jejich současného nebo kaskádového selhání.

Pokud se vám líbí naše články, tak zvažte podporu naši práce – Naskenujte QR kód a přispějte libovolnou částkou.

Děkujeme!

Štítky: AI