Sapan Pandya, inginer software senior și membru senior IEEE – Seria de interviuri

Sapan Pandya este inginer software senior și membru senior IEEE, stabilit în New Jersey, cu peste zece ani de experiență în sisteme distribuite reziliente de procesare a tranzacțiilor. Activitatea sa acoperă integritatea tranzacțiilor, integrarea software-ului cu dispozitivele fizice, depanarea sistemelor în producție și validarea implementărilor în medii reglementate. Are un masterat în informatică de la Stevens Institute of Technology și contribuie la evaluarea academică și la cercetarea tehnică.

Cercetarea lui Pandya explorează securitatea cibernetică a terminalelor de autoservire, inteligența artificială la marginea rețelei și ingineria fiabilității asistată de IA, iar experiența sa în producție îi influențează preocuparea pentru dovezi, rezultatele tranzacțiilor și responsabilitatea operațională. În acest interviu, discută despre idempotență, înregistrări contradictorii ale tranzacțiilor, incertitudinea din sistemele de recuperare și măsurile de control necesare înainte ca agenții IA să poată acționa asupra infrastructurii esențiale pentru misiuni critice. El face distincția între experiența practică de inginerie și cercetarea realizată prin analiza literaturii de specialitate și testare controlată sau sintetică.

Cariera dumneavoastră s-a concentrat pe fiabilitatea software-ului și pe sistemele distribuite de procesare a tranzacțiilor. Cum v-a influențat această experiență înțelegerea fiabilității și ce provocări v-au modelat perspectiva asupra utilizării IA pentru gestionarea sistemelor complexe?

Perspectiva mea s-a schimbat: nu mă mai întreb dacă o componentă funcționează, ci dacă tranzacția clientului s-a încheiat și poate fi justificată.

La începutul carierei, îmi concentram mare parte din atenție asupra comportamentului aplicației: validarea datelor de intrare, gestionarea răspunsurilor și verificarea faptului că interfața urma fluxul de lucru prevăzut. Pe măsură ce responsabilitățile mele s-au extins la integrarea sistemelor, depanarea în producție și validarea implementărilor, a trebuit să privesc dincolo de componentele individuale.

Un serviciu își poate încheia activitatea în timp ce alt serviciu încă așteaptă o confirmare. Software-ul poate înregistra o operațiune ca reușită, deși un dispozitiv fizic nu reușește să furnizeze rezultatul așteptat. Faptul că fiecare componentă trece testele nu demonstrează, de unul singur, că întreaga interacțiune se va desfășura corect.

Această experiență m-a făcut să fiu deosebit de interesat de limitele dintre sisteme. Ce știe fiecare componentă? Ce presupune? Ce se întâmplă când acele presupuneri nu mai sunt valabile?

Experiența îmi influențează și felul în care privesc IA. Este cu adevărat utilă pentru a-i ajuta pe ingineri să adune dovezi, să recunoască tipare și să investigheze mai rapid defecțiunile. Însă o explicație despre ce s-a întâmplat probabil nu este același lucru cu o relatare verificată a ceea ce s-a întâmplat de fapt.

Vreau ca IA să reducă efortul necesar investigării unei probleme, fără să coboare standardul probelor necesare pentru soluționarea ei.

Ați subliniat că un cod corect din punct de vedere tehnic nu garantează întotdeauna rezultate corecte ale tranzacțiilor. Ne puteți oferi un exemplu concret în care o tranzacție pare să eșueze din cauza unei expirări a timpului de așteptare, deși a fost finalizată? Ce poate merge prost când sistemul reîncearcă automat operațiunea și cum ar trebui inginerii să prevină tranzacțiile duplicate?

Să luăm exemplul ipotetic al unei plăți de 50 USD. Aplicația trimite o solicitare, serviciul de plăți o înregistrează cu succes, iar răspunsul se pierde înainte să ajungă la aplicație.

Clientul vede un mesaj de expirare a timpului de așteptare, deși plata a fost deja efectuată. Dacă aplicația trimite o nouă solicitare de plată, este posibil să îi debiteze din nou contul.

O expirare a timpului de așteptare indică faptul că răspunsul nu a sosit la timp. Nu indică dacă tranzacția propriu-zisă a fost finalizată cu succes.

O măsură de protecție frecventă este idempotența: posibilitatea de a repeta aceeași solicitare logică fără a genera un alt efect financiar. Aplicația păstrează același identificator al operațiunii la reîncercări, iar serviciul destinatar îl recunoaște ca identificatorul solicitării inițiale, nu al unei achiziții noi.

Important nu este doar să atașați un identificator. Serviciul trebuie să impună folosirea acelui identificator și să păstreze suficiente informații pentru a distinge o operațiune finalizată de una încă în desfășurare. Un identificator nu poate proteja o acțiune ulterioară care îl ignoră.

Când rezultatul rămâne incert, procesul de recuperare ar trebui să verifice tranzacția existentă și să reconcilieze înregistrările relevante, în loc să creeze imediat o tranzacție înlocuitoare.

Aș limita, de asemenea, numărul reîncercărilor și aș defini ce se întâmplă atunci când recuperarea automată nu poate stabili rezultatul. Clientul are nevoie de un statut clar, care să indice că operațiunea este în curs, și de o cale de soluționare, nu de debitări repetate sau de un ecran de procesare care nu se mai termină.

În sistemele distribuite, se poate întâmpla ca o bază de date, un serviciu backend și un terminal fizic de autoservire să raporteze informații contradictorii despre aceeași tranzacție. Ați întâlnit acest tip de inconsecvență în producție și cum a fost investigată și soluționată? Ce rol ar putea avea IA, dacă există vreunul, în reconcilierea acestor înregistrări contradictorii?

Da, investigarea inconsecvențelor privind starea tranzacțiilor a făcut parte din activitatea mea în producție. Pentru a explica raționamentul fără să discut despre un incident de la locul de muncă, voi folosi un exemplu ipotetic.

Să luăm în considerare o casă de marcat generică, cu autoservire. Serviciul de plată înregistrează o achiziție reușită, imprimanta raportează că a acceptat comanda de imprimare a bonului, iar apoi pe ecran apare o eroare. Aceste observații pot descrie etape diferite ale interacțiunii, fără să dovedească faptul că întreaga achiziție a eșuat.

Mai întâi, aș reconstitui succesiunea evenimentelor folosind identificatorul tranzacției și înregistrările relevante ale serviciilor și dispozitivelor. Apoi, aș stabili ce dovedește fiecare observație. Faptul că o imprimantă a acceptat o comandă nu dovedește neapărat că bonul a ajuns la client. Faptul că o solicitare a fost primită nu dovedește neapărat că efectul ei financiar a fost înregistrat.

Modul de rezolvare depinde de etapa care a eșuat. Repetarea întregii tranzacții ar putea fi nepotrivită dacă trebuie remediată doar etapa de emitere a bonului. Dacă dovezile disponibile nu permit stabilirea celor întâmplate, operațiunea afectată ar trebui să rămână sub control până când cineva investighează situația.

Remedierea pe termen lung trebuie să abordeze și motivul pentru care a fost posibilă această neconcordanță, nu doar să corecteze o singură înregistrare.

IA ar putea ajuta la corelarea evenimentelor și la identificarea informațiilor care lipsesc. I-aș cere să prezinte explicații alternative și dovezile care le susțin pe fiecare. Ar trebui să contribuie la restrângerea investigației, nu să rezolve neconcordanțele dintre înregistrări alegând explicația care pare cea mai convingătoare.

Pe măsură ce agenții IA trec de la diagnosticarea incidentelor din mediile de producție la recomandarea sau executarea unor acțiuni de recuperare, ce măsuri de protecție ar trebui să existe înainte ca un sistem IA să poată reîncerca, reversa sau modifica o tranzacție? Cum pot controalele deterministe, precum cheile de idempotență, jurnalele de tranzacții și mecanismele de reconciliere, să împiedice IA să provoace defecțiuni suplimentare?

Aș separa propunerea unei acțiuni de autorizarea și executarea acesteia.

Un agent IA ar putea recomanda o nouă încercare, însă un control separat ar trebui să stabilească dacă aceasta este permisă. Controlul ar trebui să verifice starea curentă a tranzacției, identitatea operațiunii, permisiunile agentului și condițiile în care acțiunea respectivă este sigură.

Această verificare trebuie efectuată în momentul executării acțiunii, nu doar atunci când modelul a analizat inițial incidentul. Între timp, un alt proces ar fi putut finaliza tranzacția.

Și instrumentele puse la dispoziția agentului ar trebui să fie limitate. Permisiunea de a prelua starea unei tranzacții este diferită de permisiunea de a reversa o plată sau de a modifica o înregistrare financiară. Agentul nu ar trebui să-și poată extinde propria autoritate doar pentru că soluția pe care o preferă necesită acces mai larg.

Idempotența limitează efectele duplicate. Jurnalele păstrează istoricul necesar pentru investigație. Reconcilierea verifică dacă înregistrările relevante concordă. Niciunul dintre aceste mecanisme, folosit singur, nu stabilește dacă o acțiune propusă este adecvată.

Aș înregistra, de asemenea, dovezile folosite, recomandarea, decizia de autorizare și rezultatul efectiv. Astfel, intervenția poate fi analizată ulterior.

Aceste controale ar trebui impuse prin software testabil, aflat în afara modelului. Instrucțiunile prin care i se cere unui agent să fie prudent sunt îndrumări utile, dar nu reprezintă un mecanism de autorizare.

Să luăm în considerare un scenariu în care un sistem de monitorizare bazat pe IA detectează o aparentă eșuare a unei tranzacții și recomandă reversarea automată a operațiunii. Dacă tranzacția a reușit, de fapt, dar confirmarea a întârziat, intervenția ar putea crea o nouă problemă. Cum ar trebui echipele de inginerie să proiecteze sisteme de recuperare bazate pe IA care să recunoască incertitudinea și să evite acțiunile corective bazate pe informații incomplete?

Sistemul are nevoie de o stare autentică „rezultat necunoscut”. În caz contrar, este probabil să transforme lipsa informațiilor într-o concluzie eronată că tranzacția a eșuat.

O confirmare întârziată este un motiv de investigare, nu automat un motiv de reversare a unei tranzacții. Reversarea este o altă operațiune financiară, cu propriile consecințe. Ea necesită un motiv stabilit în mod independent și autorizarea corespunzătoare.

Aș împărți răspunsul în două direcții. Pe direcția de investigare, sistemul poate prelua starea tranzacției, colecta evenimentele lipsă, compara înregistrările și notifica echipa responsabilă. Direcția acțiunilor financiare rămâne blocată până când sunt îndeplinite condițiile necesare.

Astfel, scorul de încredere al IA nu poate ține locul dovezilor despre tranzacție. Un model poate fi foarte sigur de o explicație construită pe baza unor informații incomplete.

Trebuie stabilit și un punct de escaladare. Menținerea unei tranzacții în așteptare pe termen nedefinit nu este un rezultat satisfăcător pentru client. Cineva ar trebui să fie responsabil de cazul nerezolvat și să dispună de suficient context pentru a stabili următorul pas sigur.

Prin urmare, procesul de recuperare ar trebui să poată spune atât „Nu pot justifica încă modificarea acestei tranzacții”, cât și „Iată ce trebuie făcut pentru a o rezolva”.

Recunoașterea incertitudinii este utilă doar dacă sistemul dispune de o modalitate practică de a o gestiona.

Una dintre cele mai importante întrebări legate de IA autonomă este să stabilim în ce situații aprobarea unui om rămâne esențială. Ce acțiuni de recuperare în mediul de producție credeți că ar trebui să poată executa IA în mod independent și care ar trebui să necesite întotdeauna autorizarea unei persoane? Cum ar trebui organizațiile să stabilească aceste limite atunci când sunt în joc tranzacții financiare, respectarea reglementărilor sau încrederea clienților?

Aș stabili limita în funcție de consecințele unei erori, nu în funcție de eticheta „IA” atribuită unei acțiuni.

O abordare rezonabilă este ca agentul să investigheze fără să poată modifica date, cu condiția să aibă acces doar la informații autorizate. Poate să colecteze înregistrări de diagnosticare, să grupeze alertele asociate și să pregătească un rezumat al incidentului, fără a putea modifica tranzacția propriu-zisă.

Unele proceduri de recuperare prestabilite pot fi, de asemenea, potrivite pentru automatizare, dacă sunt îndeplinite condițiile verificate independent, iar efectele lor sunt limitate.

Aș solicita autorizarea unei persoane dacă intervenția propusă nu se încadrează într-o procedură aprobată, dacă înregistrările se contrazic și rezultatul financiar rămâne neclar sau dacă acțiunea ar modifica măsurile de securitate ori permisiunile agentului. Un agent nu ar trebui să se autorizeze singur să ia astfel de decizii.

Asta nu înseamnă că fiecare operațiune financiară obișnuită necesită aprobarea unei persoane. Procesarea bazată pe reguli stabilite este diferită de a-i permite unui model să inventeze o corecție în timpul unui incident.

Și revizuirea de către o persoană trebuie să fie reală. Ecranul de aprobare ar trebui să prezinte dovezile justificative, incertitudinile rămase, efectele preconizate și alternativele disponibile. Dacă i se cere cuiva să aprobe un paragraf formulat cu încredere, fără acest context, protecția suplimentară este minimă.

Aceste limite ar trebui stabilite înainte de implementare. O întrerupere a serviciului nu este momentul potrivit pentru a decide câtă autoritate ar trebui să aibă un sistem automatizat.

Ați lucrat pe larg la sisteme backend tolerante la defecțiuni, instrumente de observabilitate și integrări între servicii software și echipamente fizice. De ce tip de telemetrie și dovezi din mediul de producție ar avea nevoie un agent IA pentru a diagnostica în mod fiabil un incident? Cum pot echipele de inginerie să distingă recomandările utile generate de IA de concluziile plauzibile, dar incorecte, care ar putea agrava o întrerupere a serviciului?

Aș începe cu dovezi care leagă operațiunea clientului de sistemele implicate: identificatori de tranzacție, evenimente din servicii, modificări persistente ale stării, răspunsuri ale dispozitivelor și eșecuri de comunicare.

Contează și versiunile software și modificările de configurare. O defecțiune care începe după o lansare oferă un indiciu util celui care investighează, dar simpla succesiune în timp nu dovedește o relație cauzală.

Agentul trebuie să înțeleagă și limitele dovezilor. Jurnalele pot fi incomplete, înregistrările pot sosi cu întârziere, iar ceasurile pot să nu fie sincronizate. Faptul că lipsește o confirmare nu dovedește că nu a avut loc nicio operațiune.

Un diagnostic util ar trebui să distingă observațiile de interpretări. „Clientul a înregistrat o expirare a timpului de așteptare” este o observație. „Serviciul backend nu era disponibil” este o explicație care necesită dovezi suplimentare.

M-aș aștepta ca o recomandare să indice înregistrările pe care se bazează, să explice ce rămâne necunoscut și să precizeze ce verificare suplimentară ar putea confirma sau infirma concluzia.

Apoi, inginerii ar trebui să verifice recomandările cu consecințe importante folosind înregistrările originale, nu doar să se bazeze pe rezumatul agentului. Acest lucru este cu atât mai important când rezumatul comprimă un istoric lung sau contradictoriu al evenimentelor.

Standardul pe care l-aș aplica este simplu: poate un alt inginer să urmărească dovezile și să ajungă la o concluzie justificată? Dacă explicația nu trece această verificare, nu este pregătită să stea la baza unei modificări în mediul de producție.

În cercetarea dumneavoastră publicată despre reziliența la ransomware a terminalelor de loterie și pariuri, ați evaluat un cadru de securitate asistat de IA, folosind un mediu sintetic care simula 500 de terminale. Care au fost cele mai importante rezultate și ce limitări ar trebui să aibă în vedere cititorii când le interpretează? Ce validări suplimentare ar fi necesare înainte de a aplica arhitectura propusă într-un mediu de producție real?

Am vrut să analizez reziliența dincolo de detectare: cum poate un mediu de terminale să limiteze un atac, să îl recunoască și să se recupereze, păstrând în același timp dovezile despre cele întâmplate.

Cadrul de securitate rezilientă rezultat a combinat măsuri preventive de control, detectarea anomaliilor asistată de IA și mecanisme definite de răspuns și recuperare. Componenta de IA se ocupa de detectarea comportamentului suspect. Experimentul nu a vizat permiterea unui agent bazat pe un model lingvistic să modifice independent tranzacții financiare.

Evaluarea a folosit un mediu sintetic care reprezenta 500 de terminale pe parcursul unei simulări de 72 de ore, cu simulări comportamentale ale atacurilor ransomware, nu o implementare pe 500 de terminale fizice.

Față de reperul studiului, bazat exclusiv pe antivirus, timpul mediu de detectare a scăzut de la 52 la 31 de minute, iar timpul mediu de recuperare a scăzut de la 120 la 56 de minute.

Acestea sunt rezultatele obținute de cadrul combinat în condițiile experimentale. Ele nu trebuie atribuite doar IA și nici considerate garanții de performanță într-un mediu real. O constatare utilă a fost că detectarea mai timpurie nu a dus, prin ea însăși, la aceeași îmbunătățire a recuperării. Au contat și măsurile de izolare și modul în care a fost conceput procesul de recuperare.

Limitările sunt importante. Sarcinile simulate, condițiile de rețea, comportamentul atacurilor și măsurile de apărare de bază nu reflectă toate mediile operaționale. Dispozitivele și aplicațiile diferite ar necesita o nouă validare.

Înainte de utilizarea în producție, aș dori testarea pe echipamente reprezentative, o evaluare de securitate independentă, evaluări desfășurate pe perioade mai lungi și măsurarea atentă a alarmelor false și a costurilor suplimentare de procesare.

Aș testa, de asemenea, procesul de recuperare în raport cu activitatea legitimă de tranzacționare. Nu este suficient să restaurezi o imagine funcțională a software-ului dacă, în acest proces, se pierd informațiile necesare pentru evidența tranzacțiilor finalizate.

Studiul oferă o bază pentru testări suplimentare. Demonstrarea unui comportament sigur într-un mediu operațional real este un pas separat.

Perspectiva dumneavoastră îmbină ani de experiență în ingineria sistemelor de producție cu cercetarea academică în domeniul fiabilității software și al securității bazate pe IA. Puteți distinge între mecanismele de fiabilitate pe care le-ați implementat personal sau le-ați operat în sisteme reale, aflate în exploatare, și abordările pe care le-ați explorat prin cercetare sau testare simulată? Ce capacități de recuperare bazate pe IA considerați că sunt deja practice astăzi și care rămân în mare parte experimentale?

Activitatea mea în producție a inclus dezvoltare și integrare software, validarea tranzacțiilor, depanare, testare și validarea versiunilor înainte de lansare.

Cercetarea mea publicată reprezintă o parte distinctă a activității mele, iar fiecare studiu trebuie înțeles în funcție de metodele și limitările declarate.

Lucrarea despre ransomware evaluează un cadru de securitate propus într-un mediu de testare sintetic. Lucrarea mea despre IA la periferie este o analiză bazată pe literatura de specialitate a inteligenței integrate în dispozitive și a posibilei sale aplicări în terminalele de tranzacții. Articolul meu din IEEE FeedForward examinează, prin simulare controlată, o arhitectură de fiabilitate asistată de IA, care include monitorizare, escaladare și comportament de rezervă.

Niciuna dintre aceste publicații nu trebuie interpretată ca dovadă că am implementat un agent IA autonom, cu autoritate asupra tranzacțiilor financiare reale.

Pentru utilizarea practică, aș prioritiza instrumentele de asistență pe care inginerii le pot inspecta: rezumate ale incidentelor asociate cu înregistrările-sursă, corelări între alerte și verificări de diagnostic sugerate. Utilitatea lor trebuie totuși măsurată în mediul în care vor funcționa.

Problema mai dificilă este recuperarea în situații neprevăzute, când un model alege și execută modificări în condiții care nu au fost anticipate. Pentru aceasta sunt necesare dovezi mult mai solide decât pentru o sugestie de diagnostic utilă.

Consider că experiența mea în producție și cercetarea mea se completează reciproc: prima stabilește problemele operaționale pe care le cunosc, iar cea de-a doua explorează abordări care trebuie să-și dovedească valoarea prin validare.

Privind spre viitor, pe măsură ce agenții IA devin tot mai capabili să detecteze anomalii, să diagnosticheze defecțiuni și să coordoneze recuperarea în sisteme distribuite, cum vedeți evoluția relației dintre sistemele autonome și inginerii umani? Ce măsuri tehnice de protecție, dovezi operaționale și mecanisme de responsabilizare ar fi necesare înainte ca organizațiile să poată acorda cu încredere IA o autoritate mai mare asupra infrastructurii de producție critice pentru misiune?

Mă aștept ca IA să preia o parte tot mai mare din munca necesară pentru a obține o imagine de ansamblu asupra unui incident. În loc să petreacă atât de mult timp adunând manual aceste informații, inginerii ar putea începe cu o cronologie utilă, componentele afectate, explicațiile concurente și dovezile care lipsesc.

Astfel, oamenii ar avea mai mult timp pentru deciziile care presupun înțelegerea obligațiilor sistemului și a consecințelor modificării acestuia.

Aș extinde treptat autoritatea de execuție. La început, un agent ar putea funcționa în mod umbră, formulând recomandări fără să acționeze în baza lor. Echipele ar putea compara aceste recomandări cu rezultatele evaluate și ar putea testa comportamentul agentului atunci când informațiile lipsesc, sunt contradictorii sau sunt depășite.

Evaluarea ar trebui să includă intervenții greșite, probleme nedetectate, escaladări inutile și recuperarea după propriile greșeli ale agentului. O recomandare rapidă nu este valoroasă dacă îndrumă echipa de intervenție în direcția greșită.

Autoritatea extinsă ar trebui să rămână, de asemenea, condiționată. O actualizare a modelului sau o modificare majoră a sistemului poate invalida testările anterioare. Echipele trebuie să aibă posibilitatea de a restrânge sau retrage permisiunile agentului atunci când comportamentul acestuia nu mai respectă standardul impus.

Îmbunătățirea automatizării nu elimină responsabilitatea umană. Cineva trebuie să răspundă de regulile de operare, de dovezile necesare pentru o modificare și de procesul de investigare a defecțiunilor.

Consider că inginerii vor petrece mai puțin timp adunând informații și mai mult timp definind, testând și menținând condițiile în care acțiunile automatizate sunt justificate.

Vă mulțumim pentru interviul excelent. Cititorii care doresc să-i urmărească activitatea în domeniul fiabilității tranzacțiilor distribuite și al recuperării responsabile asistate de IA pot lua legătura cu Sapan Pandya.