Sapan Pandya, seniorní softwarový inženýr a seniorní člen IEEE – série rozhovorů

Sapan Pandya je seniorní softwarový inženýr a seniorní člen IEEE z New Jersey s více než desetiletými zkušenostmi s odolnými distribuovanými transakčními systémy. Ve své práci se věnuje integritě transakcí, integraci softwaru s fyzickými zařízeními, řešení problémů v produkčním prostředí a ověřování nasazení v regulovaných prostředích. Získal magisterský titul v oboru informatiky na Stevens Institute of Technology a věnuje se odbornému recenzování a technickému výzkumu.

Pandya se ve svém výzkumu zabývá kybernetickou bezpečností samoobslužných kiosků, edge AI a inženýrstvím spolehlivosti s podporou AI. Jeho zkušenosti z produkčního prostředí přitom utvářejí jeho zaměření na důkazy, výsledky transakcí a provozní odpovědnost. V tomto rozhovoru hovoří o idempotenci, rozporných záznamech o transakcích, nejistotě při obnově systémů a kontrolních mechanismech, které je třeba zavést, než budou moci agenti AI zasahovat do kritické infrastruktury. Rozlišuje mezi praktickými inženýrskými zkušenostmi a výzkumem založeným na analýze literatury a kontrolovaném či syntetickém testování.

Ve své kariéře se zaměřujete na spolehlivost softwaru a distribuované transakční systémy. Jak tyto zkušenosti ovlivnily vaše chápání spolehlivosti a které výzvy utvářely váš pohled na využití AI při správě komplexních systémů?

Můj pohled se posunul od otázky, zda komponenta funguje, k otázce, zda je transakce zákazníka dokončena a lze ji řádně vyúčtovat.

Na začátku kariéry jsem se soustředil především na chování aplikací: ověřování vstupů, zpracování odpovědí a kontrolu, zda rozhraní dodržuje zamýšlený pracovní postup. Jak se rozšiřovala moje odpovědnost o integraci systémů, řešení problémů v produkčním prostředí a ověřování nasazení, musel jsem se dívat dál než na jednotlivé komponenty.

Jedna služba může dokončit svou práci, zatímco jiná stále čeká na potvrzení. Software může zaznamenat úspěšnou operaci, i když fyzické zařízení nedokáže poskytnout očekávaný výsledek. To, že každá komponenta projde testy, samo o sobě nezaručuje, že celé vzájemné působení bude fungovat správně.

Díky těmto zkušenostem mě zvlášť zajímají rozhraní mezi systémy. Co která komponenta ví? Co předpokládá? Co se stane, když tyto předpoklady přestanou platit?

Ovlivňuje to také můj pohled na AI. Pomáhat inženýrům shromažďovat důkazy, rozpoznávat vzorce a rychleji vyšetřovat selhání má skutečnou hodnotu. Vysvětlení toho, co se pravděpodobně stalo, se ale liší od ověřeného popisu toho, co se skutečně stalo.

Chci, aby AI usnadňovala vyšetřování problémů, aniž by snižovala nároky na důkazy potřebné k jejich vyřešení.

Zdůrazňujete, že technicky správný kód nezaručuje vždy správný výsledek transakce. Můžete uvést konkrétní příklad, kdy se zdá, že transakce kvůli vypršení časového limitu selhala, přestože byla ve skutečnosti dokončena? Co se může pokazit, když systém operaci automaticky zopakuje, a jak mají inženýři předcházet duplicitním transakcím?

Představme si hypotetickou platbu ve výši 50 $. Aplikace odešle požadavek, platební služba jej úspěšně zaznamená, ale odpověď se k aplikaci nedostane, protože se cestou ztratí.

Zákazníkovi se zobrazí informace o vypršení časového limitu, přestože platba již proběhla. Pokud aplikace odešle nový platební požadavek, může zákazníkovi částku naúčtovat znovu.

Vypršení časového limitu znamená, že odpověď nedorazila včas. Neříká však, zda se samotná transakce zdařila.

Jedním z běžných ochranných opatření je idempotence: možnost opakovat stejný logický požadavek, aniž by vznikl další finanční dopad. Aplikace při opakovaných pokusech zachovává identifikátor operace a přijímající služba jej rozpozná jako původní požadavek, nikoli jako nový nákup.

Podstatné není pouze připojit identifikátor. Služba musí jeho jedinečnost vynucovat a uchovávat dostatek informací k rozlišení dokončené operace od té, která stále probíhá. Identifikátor nedokáže ochránit navazující akci, která jej ignoruje.

Pokud výsledek zůstává nejistý, měl by postup obnovy ověřit existující transakci a uvést příslušné záznamy do souladu, nikoli okamžitě vytvářet náhradní transakci.

Omezil bych také počet opakovaných pokusů a stanovil, co se má stát, když automatická obnova nedokáže výsledek zjistit. Zákazník potřebuje jasnou informaci, že transakce čeká na dokončení, a možnost jejího dořešení, nikoli opakované strhávání částky nebo nekonečně se zobrazující obrazovku zpracování.

V distribuovaných systémech se může stát, že databáze, backendová služba a fyzický kiosek uvádějí o téže transakci rozporné informace. Setkal jste se s takovou nesrovnalostí v produkčním prostředí? Jak se vyšetřovala a řešila? Jakou roli by případně mohla při slaďování těchto rozporných záznamů hrát AI?

Ano, vyšetřování nesrovnalostí ve stavech transakcí bylo součástí mé práce v produkčním prostředí. Abych vysvětlil svůj postup, aniž bych rozebíral konkrétní incident z pracoviště, uvedu hypotetický příklad.

Představme si běžnou samoobslužnou pokladnu. Platební služba zaznamená úspěšný nákup, tiskárna oznámí, že přijala úlohu k vytištění účtenky, a na obrazovce se poté zobrazí chyba. Tato pozorování mohou popisovat různé fáze interakce, a nemusí tedy dokazovat, že celý nákup selhal.

Nejprve bych pomocí identifikátoru transakce a příslušných záznamů služeb a zařízení rekonstruoval její průběh. Poté bych zjistil, co jednotlivá pozorování skutečně dokazují. To, že tiskárna přijala tiskovou úlohu, nutně neznamená, že se účtenka dostala k zákazníkovi. Ani přijetí požadavku nutně nedokazuje, že se jeho finanční dopad promítl do záznamů.

Řešení závisí na tom, která fáze selhala. Opakovat celou transakci může být nevhodné, pokud je třeba řešit pouze její výstupní fázi. Pokud dostupné důkazy neumožňují zjistit, co se stalo, měla by dotčená operace zůstat pod kontrolou, dokud ji někdo neprošetří.

Trvalá náprava musí také řešit, proč k nesrovnalosti vůbec mohlo dojít, a ne pouze opravit jeden záznam.

Umělá inteligence by mohla pomoci propojit události a odhalit chybějící informace. Požádal bych ji, aby předložila několik možných vysvětlení a důkazy, které každé z nich podporují. Měla by pomoci zúžit okruh možností při vyšetřování, nikoli vyřešit rozporné záznamy tím, že zvolí vysvětlení, které zní nejpřesvědčivěji.

Jaká ochranná opatření by měla být zavedena, než systém umělé inteligence bude moci opakovat, stornovat nebo měnit transakce, když se agenti umělé inteligence posouvají od diagnostiky provozních incidentů k doporučování nebo provádění nápravných kroků? Jak mohou deterministické mechanismy, jako jsou idempotentní klíče, transakční protokoly a postupy párování záznamů, zabránit tomu, aby umělá inteligence způsobovala další selhání?

Oddělil bych navržení kroku od jeho schválení a provedení.

Agent s umělou inteligencí může doporučit opakování operace, ale o tom, zda je to povoleno, by měl rozhodovat samostatný kontrolní mechanismus. Měl by ověřit aktuální stav transakce, totožnost operace, oprávnění agenta a podmínky, za nichž je daný krok bezpečný.

Tato kontrola se musí provést při vykonání kroku, nejen ve chvíli, kdy model incident poprvé posoudil. Mezitím mohl transakci dokončit jiný proces.

Rozsah nástrojů dostupných agentovi by měl být také omezený. Oprávnění zjistit stav transakce se liší od oprávnění stornovat platbu nebo změnit finanční záznam. Agent by si neměl být schopen rozšířit vlastní oprávnění jen proto, že jeho preferované řešení vyžaduje širší přístup.

Idempotence omezuje duplicitní účinky. Protokoly uchovávají historii potřebnou k prošetření. Párování ověřuje, zda si příslušné záznamy odpovídají. Žádný z těchto mechanismů sám o sobě nedokazuje, že je navrhovaný krok vhodný.

Zaznamenával bych také použité důkazy, doporučení, rozhodnutí o schválení a skutečný výsledek. Díky tomu lze zásah následně přezkoumat.

Tyto kontroly by měl vynucovat testovatelný software mimo samotný model. Pokyny, aby agent postupoval obezřetně, jsou užitečným vodítkem, ale nenahrazují mechanismus schvalování oprávnění.

Představme si situaci, kdy monitorovací systém s umělou inteligencí zaznamená zdánlivé selhání transakce a doporučí její automatické stornování. Pokud transakce ve skutečnosti proběhla úspěšně, ale potvrzení se opozdilo, mohl by takový zásah způsobit nový problém. Jak by měly technické týmy navrhovat systémy obnovy řízené umělou inteligencí tak, aby rozpoznaly nejistotu a nepřijímaly nápravná opatření na základě neúplných informací?

Systém musí mít skutečný stav „výsledek neznámý“. Jinak hrozí, že chybějící informace vyhodnotí jako selhání, přestože k němu nedošlo.

Opožděné potvrzení je důvodem k prošetření, nikoli automaticky důvodem ke stornování transakce. Storno je další finanční operace s vlastními důsledky. Musí pro něj existovat důvod zjištěný nezávislým posouzením a příslušné oprávnění.

Reakci bych rozdělil do dvou postupů. V rámci vyšetřování lze zjistit stav, doplnit chybějící události, porovnat záznamy a informovat odpovědný tým. Finanční operace zůstane zablokována, dokud nebudou splněny stanovené podmínky.

Tím se zabrání tomu, aby skóre spolehlivosti umělé inteligence nahrazovalo důkazy o transakci. Model si může být velmi jistý vysvětlením, které vychází z neúplných informací.

Musí být také stanoven okamžik, kdy se případ předá k řešení. Nechat transakci neomezeně dlouho čekat není pro zákazníka přijatelné. Za nevyřešený případ by měl někdo nést odpovědnost a mít k dispozici dostatek souvislostí, aby mohl určit další bezpečný krok.

Proces obnovy by proto měl umět říct jak „Zatím nemohu odůvodnit změnu této transakce“, tak „Toto je třeba udělat, aby se situace vyřešila“.

Rozpoznání nejistoty je užitečné pouze tehdy, když má systém praktický způsob, jak ji zvládnout.

Jednou z nejzásadnějších otázek spojených s autonomní umělou inteligencí je určit, kdy zůstává nezbytné schválení člověkem. Které kroky při obnově produkčního provozu by podle vás měla mít AI povoleno provádět samostatně a které by měly vždy vyžadovat souhlas člověka? Jak by měly organizace tyto hranice stanovit, když jde o finanční transakce, dodržování předpisů nebo důvěru zákazníků?

Hranici bych stanovil podle důsledků případné chyby, nikoli podle toho, zda je daný úkon označen jako „AI“.

Rozumným výchozím bodem je analýza bez možnosti zápisu, pokud má agent přístup pouze k oprávněně dostupným informacím. Může shromažďovat diagnostické záznamy, seskupovat související upozornění a připravovat souhrn incidentu, aniž by mohl měnit samotnou transakci.

K automatizaci se mohou hodit také některé předem definované postupy obnovy, pokud jsou jejich podmínky nezávisle ověřeny a jejich dopady omezené.

Souhlas člověka bych vyžadoval, pokud navrhovaný zásah nespadá do schváleného postupu, pokud jsou záznamy v rozporu a finanční výsledek zůstává nevyjasněný nebo pokud by daný úkon změnil bezpečnostní opatření či vlastní oprávnění agenta. O takových rozhodnutích by agent neměl rozhodovat sám.

To neznamená, že každý běžný finanční úkon musí schvalovat člověk. Zavedené zpracování podle pravidel se liší od toho, když modelu dovolíme během incidentu vymyslet nápravu.

Lidská kontrola musí být také smysluplná. Schvalovací obrazovka by měla zobrazovat podklady, přetrvávající nejistotu, očekávaný dopad i dostupné alternativy. Požádat někoho o schválení sebejistě formulovaného odstavce bez těchto souvislostí přináší jen malou ochranu.

Tyto hranice by měly být dohodnuty ještě před nasazením. Výpadek není vhodnou chvílí k rozhodování, jak velké pravomoci má automatizovaný systém mít.

Rozsáhle jste se věnoval backendovým systémům odolným vůči poruchám, nástrojům pro observabilitu a integracím mezi softwarovými službami a fyzickým hardwarem. Jaké provozní telemetrické údaje a důkazy by agent AI potřeboval, aby dokázal spolehlivě diagnostikovat incident? Jak mohou technické týmy odlišit užitečná doporučení vytvořená AI od věrohodně znějících, ale chybných závěrů, které by mohly výpadek zhoršit?

Začal bych důkazy, které propojují provoz zákazníka napříč dotčenými systémy: identifikátory transakcí, události služeb, trvalé změny stavu, odezvy zařízení a selhání komunikace.

Důležité jsou také verze softwaru a změny konfigurace. Pokud se porucha objeví po vydání nové verze, poskytuje to vyšetřování užitečnou stopu, samotná časová souvislost však příčinu nedokazuje.

Agent musí také rozumět omezením dostupných důkazů. Protokoly mohou být neúplné, záznamy mohou dorazit se zpožděním a jednotlivé hodiny nemusí být synchronizované. Chybějící potvrzení není totéž jako důkaz, že k žádné operaci nedošlo.

Užitečná diagnóza by měla oddělovat pozorování od interpretací. „Klient zaznamenal vypršení časového limitu“ je pozorování. „Backend nebyl dostupný“ je vysvětlení, které vyžaduje další podklady.

Očekával bych, že doporučení uvede záznamy, o které se opírá, vysvětlí, co zůstává neznámé, a upřesní, jaká další kontrola by jeho závěr potvrdila, nebo vyvrátila.

Technici by pak měli důležitá doporučení ověřovat podle původních záznamů, nikoli spoléhat pouze na souhrn od agenta. To je zvlášť důležité, když souhrn zestručňuje dlouhou nebo rozpornou historii událostí.

Uplatňoval bych jednoduché měřítko: dokáže jiný technik na základě důkazů postupovat a dospět k obhajitelnému závěru? Pokud vysvětlení touto zkouškou neprojde, není připravené k tomu, aby vedlo ke změně v produkčním prostředí.

Ve svém publikovaném výzkumu odolnosti loterijních a sázkových kiosků vůči ransomwaru jste vyhodnocoval bezpečnostní rámec s podporou AI v syntetickém prostředí simulujícím 500 kiosků. Jaká byla nejdůležitější zjištění a jaká omezení by měli čtenáři při interpretaci výsledků vzít v úvahu? Jaké další ověření by bylo nutné před nasazením navržené architektury do živého produkčního prostředí?

Chtěl jsem zkoumat odolnost nejen z hlediska detekce, ale také toho, jak může prostředí terminálů omezit útok, rozpoznat ho a obnovit provoz při zachování důkazů o tom, co se stalo.

Výsledný Resilient Security Framework spojoval preventivní opatření, detekci anomálií s podporou AI a definované mechanismy reakce a obnovy. Složka AI se zaměřovala na odhalování podezřelého chování. Nešlo o experiment, v němž by agent založený na jazykovém modelu samostatně upravoval finanční transakce.

Vyhodnocení proběhlo v syntetickém prostředí představujícím 500 kiosků během 72hodinové simulace; použity byly behaviorální emulace ransomwarových útoků, nikoli nasazení na 500 fyzických terminálech.

Ve srovnání se základní variantou studie, která používala pouze antivirus, klesla průměrná doba detekce z 52 na 31 minut a průměrná doba obnovy ze 120 na 56 minut.

Jde o výsledky kombinovaného rámce za experimentálních podmínek. Nelze je připisovat samotné AI ani je považovat za záruku výkonnosti v živém provozu. Jedním z užitečných zjištění bylo, že dřívější detekce sama o sobě nepřinesla stejné zlepšení obnovy. Důležitý byl také způsob navržení zadržení útoku a obnovy.

Omezení jsou důležitá. Simulované zátěže, síťové podmínky, průběh útoků a výchozí obranná opatření nereprezentují všechna provozní prostředí. Různá zařízení a aplikace by vyžadovaly nové ověření.

Před nasazením do produkčního prostředí bych požadoval testování na reprezentativním hardwaru, nezávislé posouzení zabezpečení, delší hodnocení a pečlivé měření falešných poplachů a režijní zátěže zpracování.

Proces obnovy bych také testoval při běžném provozu transakcí. Obnovení funkčního obrazu softwaru nestačí, pokud se při tom ztratí informace potřebné k zaúčtování dokončených transakcí.

Studie poskytuje základ pro další testování. Prokázat bezpečné chování v reálném provozním prostředí je samostatný krok.

Vaše zkušenosti spojují dlouholetou práci na produkčních systémech s akademickým výzkumem spolehlivosti softwaru a zabezpečení využívajícího umělou inteligenci. Můžete rozlišit mezi mechanismy spolehlivosti, které jste osobně implementoval nebo provozoval v živých produkčních systémech, a přístupy, kterými jste se zabýval ve výzkumu nebo při simulovaném testování? Které možnosti obnovy využívající umělou inteligenci jsou podle vás už dnes prakticky použitelné a které zůstávají převážně experimentální?

V rámci své produkční práce jsem se věnoval vývoji a integraci softwaru, ověřování transakcí, řešení problémů, testování a ověřování vydání.

Publikovaný výzkum je samostatnou součástí mé práce a každou studii je třeba posuzovat s ohledem na její deklarované metody a omezení.

Studie o ransomwaru hodnotí navržený bezpečnostní rámec v syntetickém testovacím prostředí. Můj článek o umělé inteligenci na okraji sítě je analýzou odborné literatury zaměřenou na inteligenci přímo v zařízení a její možné využití v platebních terminálech. Můj článek pro IEEE FeedForward zkoumá architekturu spolehlivosti podporovanou umělou inteligencí prostřednictvím řízené simulace, která zahrnuje monitorování, eskalaci a záložní chování.

Žádnou z těchto publikací nelze chápat jako důkaz, že jsem nasadil autonomního agenta umělé inteligence s pravomocí zasahovat do živých finančních transakcí.

Při praktickém využití bych upřednostnil pomoc, kterou mohou inženýři kontrolovat: souhrny incidentů propojené se zdrojovými záznamy, souvislosti mezi upozorněními a navrhované diagnostické kontroly. Jejich užitečnost je stále třeba měřit v prostředí, v němž budou fungovat.

Obtížnější je otevřená obnova, při níž model volí a provádí změny za okolností, se kterými se předem nepočítalo. Ta vyžaduje mnohem přesvědčivější důkazy než užitečný diagnostický návrh.

Produkční zkušenosti a výzkum se podle mě vzájemně doplňují: první mi pomáhají porozumět provozním problémům, zatímco druhý zkoumá přístupy, které si své místo musí teprve zasloužit ověřením.

Jak se podle vás bude vyvíjet vztah mezi autonomními systémy a lidskými inženýry, až budou agenti umělé inteligence stále schopnější odhalovat anomálie, diagnostikovat selhání a koordinovat obnovu napříč distribuovanými systémy? Jaká technická ochranná opatření, provozní důkazy a mechanismy odpovědnosti by byly nutné, než by organizace mohly s jistotou svěřit umělé inteligenci větší pravomoci nad kritickou produkční infrastrukturou?

Očekávám, že umělá inteligence převezme větší část práce spojené se sestavováním přehledu o incidentu. Inženýři by mohli začínat s užitečnou časovou osou, seznamem zasažených komponent, možnými konkurenčními vysvětleními a chybějícími důkazy, místo aby tolik času trávili jejich ručním shromažďováním.

Lidé by tak měli více času na rozhodnutí, která vyžadují porozumění závazkům systému a důsledkům jeho změn.

Rozšiřoval bych pravomoci k provádění změn postupně. Agent by mohl nejprve pracovat ve stínovém režimu a vytvářet doporučení, aniž by podle nich jednal. Týmy by mohla tato doporučení porovnávat s posouzenými výsledky a testovat, jak se agent chová, když informace chybějí, jsou rozporné nebo zastaralé.

Hodnocení by mělo zahrnovat nesprávné zásahy, přehlédnuté problémy, zbytečnou eskalaci a nápravu chyb samotného agenta. Rychlé doporučení nemá cenu, pokud zásahový tým nasměruje špatným směrem.

Rozsáhlejší pravomoci by navíc měly být podmíněné. Aktualizace modelu nebo zásadní změna systému mohou zneplatnit dřívější testování. Týmy musí mít možnost omezit nebo odebrat agentovi oprávnění, pokud jeho chování přestane splňovat požadovaný standard.

S rostoucí mírou automatizace odpovědnost lidí nezaniká. Někdo musí odpovídat za provozní pravidla, důkazy požadované pro změnu a postup při vyšetřování selhání.

Představuji si, že inženýři budou méně času věnovat shromažďování informací a více času vymezování, testování a udržování podmínek, za nichž je automatizovaný zásah oprávněný.

Děkujeme za skvělý rozhovor. Čtenáři, kteří chtějí sledovat jeho práci v oblasti spolehlivosti distribuovaných transakcí a odpovědné obnovy s podporou AI, mohou navázat kontakt se Sapan Pandya.