Sapan Pandya, ingegnere software senior e membro senior dell’IEEE – Serie di interviste

Sapan Pandya è un ingegnere software senior e membro senior dell’IEEE che vive nel New Jersey, con oltre dieci anni di esperienza nei sistemi distribuiti resilienti per le transazioni. Il suo lavoro spazia dall’integrità delle transazioni all’integrazione tra software e dispositivi fisici, dalla risoluzione dei problemi in produzione alla convalida delle distribuzioni in ambienti regolamentati. Ha conseguito un master in informatica presso Stevens Institute of Technology e contribuisce alla revisione accademica e alla ricerca tecnica.

La ricerca di Pandya esplora la cybersicurezza dei chioschi self-service, l’IA edge e l’ingegneria dell’affidabilità assistita dall’IA; la sua esperienza in produzione orienta l’attenzione verso le evidenze, gli esiti delle transazioni e la responsabilità operativa. In questa intervista parla di idempotenza, registrazioni delle transazioni in conflitto, incertezza nei sistemi di ripristino e controlli necessari prima che gli agenti IA possano intervenire su infrastrutture critiche. Distingue l’esperienza pratica di ingegneria dalla ricerca condotta attraverso l’analisi della letteratura e test controllati o sintetici.

La sua carriera si è concentrata sull’affidabilità del software e sui sistemi distribuiti per le transazioni. In che modo questa esperienza ha influenzato la sua concezione dell’affidabilità e quali difficoltà hanno condizionato il suo punto di vista sull’uso dell’IA per gestire sistemi complessi?

Il mio punto di vista è passato dal chiedermi se un componente funziona al chiedermi se la transazione del cliente è stata completata e può essere contabilizzata.

All’inizio della mia carriera, gran parte della mia attenzione era rivolta al comportamento delle applicazioni: convalidare gli input, gestire le risposte e assicurarmi che l’interfaccia seguisse il flusso di lavoro previsto. Con l’ampliarsi delle mie responsabilità, che hanno incluso l’integrazione dei sistemi, la risoluzione dei problemi in produzione e la convalida delle distribuzioni, ho dovuto guardare oltre i singoli componenti.

Un servizio può aver terminato il proprio lavoro mentre un altro è ancora in attesa di conferma. Il software può registrare un’operazione come riuscita mentre un dispositivo fisico non riesce a fornire il risultato atteso. Il superamento dei test da parte di ciascun componente, da solo, non dimostra che l’intera interazione funzionerà correttamente.

Questa esperienza mi ha portato a interessarmi in particolare ai punti di intersezione tra i sistemi. Che cosa sa ciascun componente? Che cosa dà per scontato? Che cosa succede quando queste ipotesi non sono più valide?

Influisce anche sul mio modo di pensare all’IA. Aiutare gli ingegneri a raccogliere evidenze, individuare schemi e analizzare i guasti più rapidamente può essere davvero utile. Ma una spiegazione di ciò che probabilmente è accaduto è diversa da una ricostruzione verificata di ciò che è realmente successo.

Voglio che l’IA riduca il lavoro necessario per indagare su un problema senza abbassare il livello di evidenza richiesto per risolverlo.

Ha sottolineato che un codice tecnicamente corretto non garantisce sempre esiti corretti per le transazioni. Può descriverci un esempio concreto in cui una transazione sembra non riuscire a causa di un timeout, ma in realtà è stata completata? Che cosa può andare storto quando il sistema riprova automaticamente a eseguire l’operazione e come dovrebbero impedire gli ingegneri la duplicazione delle transazioni?

Consideriamo un pagamento ipotetico di 50 $. L’applicazione invia una richiesta, il servizio di pagamento la registra correttamente e la risposta va persa prima di raggiungere l’applicazione.

Il cliente visualizza un timeout, anche se il pagamento è già stato effettuato. Se l’applicazione invia una nuova richiesta di pagamento, potrebbe addebitare nuovamente il cliente.

Un timeout indica che la risposta non è arrivata in tempo. Non indica se la transazione sottostante è andata a buon fine.

Una misura di salvaguardia comune è l’idempotenza: consentire di ripetere la stessa richiesta logica senza generare un ulteriore effetto finanziario. L’applicazione mantiene lo stesso identificativo dell’operazione durante i tentativi successivi e il servizio ricevente lo riconosce come la richiesta originale, anziché come un nuovo acquisto.

L’aspetto importante non è semplicemente associare un identificativo alla richiesta. Il servizio deve far rispettare tale identificativo e conservare informazioni sufficienti a distinguere un’operazione completata da una ancora in corso. Un identificativo non può proteggere un’azione a valle che lo ignora.

Quando l’esito rimane incerto, la procedura di ripristino dovrebbe verificare la transazione esistente e riconciliare le registrazioni pertinenti, invece di crearne subito una sostitutiva.

Limiterei anche il numero di tentativi e definirei cosa fare quando il ripristino automatico non riesce a stabilire l’esito. Il cliente ha bisogno di uno stato chiaro di operazione in sospeso e di un percorso per risolvere il problema, non di addebiti ripetuti o di una schermata di elaborazione che resta aperta all’infinito.

Nei sistemi distribuiti, può accadere che un database, un servizio backend e un chiosco fisico riportino informazioni contrastanti sulla stessa transazione. Le è mai capitato di riscontrare questo tipo di incongruenza in produzione? Come è stata analizzata e risolta? Che ruolo potrebbe avere, eventualmente, l’IA nel riconciliare queste registrazioni in conflitto?

Sì, l’analisi delle incongruenze nello stato delle transazioni ha fatto parte del mio lavoro in produzione. Per spiegare il ragionamento senza parlare di un episodio verificatosi sul posto di lavoro, userò un esempio ipotetico.

Si consideri una generica cassa self-service. Il servizio di pagamento registra un acquisto completato con successo, la stampante segnala di aver accettato il processo di stampa della ricevuta e, subito dopo, sullo schermo compare un errore. Queste osservazioni potrebbero riferirsi a fasi diverse dell’interazione, senza dimostrare che l’intero acquisto non sia andato a buon fine.

Per prima cosa ricostruirei la sequenza usando l’identificativo della transazione e i registri pertinenti del servizio e dei dispositivi. Poi verificherei che cosa dimostra ciascuna osservazione. Il fatto che una stampante accetti un processo di stampa non dimostra necessariamente che la ricevuta sia arrivata al cliente. Allo stesso modo, il fatto che una richiesta sia stata ricevuta non dimostra necessariamente che il relativo effetto finanziario sia stato contabilizzato.

La soluzione dipende dalla fase in cui si è verificato il problema. Ripetere l’intera transazione potrebbe essere inappropriato se è necessario intervenire soltanto sulla fase di stampa. Se le prove disponibili non consentono di stabilire che cosa sia accaduto, l’operazione interessata dovrebbe rimanere sotto controllo mentre qualcuno svolge le verifiche.

La correzione definitiva deve inoltre affrontare il motivo per cui è stata possibile l’incoerenza, anziché limitarsi a correggere una singola registrazione.

L’IA potrebbe aiutare a correlare gli eventi e a individuare le informazioni mancanti. Le chiederei di presentare spiegazioni alternative e le prove a sostegno di ciascuna. Dovrebbe contribuire a circoscrivere l’indagine, non risolvere le incoerenze tra registrazioni scegliendo la spiegazione che sembra più convincente.

Man mano che gli agenti IA passano dalla diagnosi degli incidenti in produzione alla raccomandazione o all’esecuzione di azioni di ripristino, quali misure di sicurezza dovrebbero essere previste prima che un sistema di IA possa ripetere, annullare o modificare una transazione? In che modo i controlli deterministici, come le chiavi di idempotenza, i registri delle transazioni e i meccanismi di riconciliazione, possono impedire all’IA di causare ulteriori problemi?

Distinguerei tra la proposta di un’azione e la sua autorizzazione ed esecuzione.

Un agente IA potrebbe raccomandare di ripetere un’operazione, ma un controllo separato dovrebbe stabilire se è consentito farlo. Dovrebbe verificare lo stato corrente della transazione, l’identità dell’operazione, le autorizzazioni dell’agente e le condizioni in cui l’azione è sicura.

La verifica deve essere effettuata al momento dell’esecuzione dell’azione, non soltanto quando il modello ha esaminato per la prima volta l’incidente. Nel frattempo, un altro processo potrebbe aver completato la transazione.

Anche gli strumenti a disposizione dell’agente dovrebbero avere una portata limitata. L’autorizzazione a recuperare lo stato di una transazione è diversa da quella necessaria per annullare un pagamento o modificare una registrazione finanziaria. L’agente non dovrebbe poter ampliare autonomamente le proprie autorizzazioni perché la soluzione che preferisce richiede un accesso più ampio.

L’idempotenza limita gli effetti duplicati. I registri conservano la cronologia necessaria per svolgere le verifiche. La riconciliazione controlla la corrispondenza tra le registrazioni pertinenti. Nessuno di questi elementi, da solo, dimostra che un’azione proposta sia appropriata.

Registrerei inoltre le prove utilizzate, la raccomandazione, la decisione di autorizzazione e il risultato effettivo. In questo modo è possibile riesaminare l’intervento in un secondo momento.

Questi controlli dovrebbero essere applicati da software verificabile, esterno al modello. Le istruzioni che invitano un agente a prestare attenzione sono indicazioni utili, ma non costituiscono un meccanismo di autorizzazione.

Si consideri uno scenario in cui un sistema di monitoraggio basato sull’IA rileva un apparente errore di transazione e raccomanda di annullare automaticamente l’operazione. Se la transazione è stata effettivamente completata, ma la conferma è arrivata in ritardo, l’intervento potrebbe creare un nuovo problema. In che modo i team di ingegneria dovrebbero progettare sistemi di ripristino basati sull’IA affinché riconoscano l’incertezza ed evitino di intraprendere azioni correttive sulla base di informazioni incomplete?

Il sistema deve prevedere uno stato effettivo di «esito sconosciuto». In caso contrario, rischia di interpretare la mancanza di informazioni come prova di un errore, arrivando a una conclusione sbagliata.

Una conferma tardiva è un motivo per svolgere verifiche, non per annullare automaticamente una transazione. L’annullamento è a sua volta un’operazione finanziaria, con conseguenze proprie. Deve basarsi su una motivazione accertata in modo indipendente e disporre dell’autorizzazione appropriata.

Distinguerei la risposta in due percorsi. Quello investigativo può recuperare lo stato, raccogliere gli eventi mancanti, confrontare le registrazioni e avvisare il team responsabile. Il percorso relativo alle azioni finanziarie rimane bloccato finché non sono soddisfatte le condizioni previste.

In questo modo si evita che il punteggio di affidabilità dell’IA sostituisca le prove relative alla transazione. Un modello può essere molto sicuro di una spiegazione elaborata sulla base di informazioni incomplete.

È inoltre necessario definire un momento preciso per l’escalation. Lasciare una transazione in sospeso a tempo indeterminato non è una soluzione soddisfacente per il cliente. Qualcuno dovrebbe essere responsabile del caso irrisolto e disporre di un contesto sufficiente per determinare il passo successivo più sicuro.

Il processo di ripristino dovrebbe quindi poter dire sia «Non posso ancora giustificare una modifica a questa transazione» sia «Ecco che cosa occorre fare per risolvere il problema».

Riconoscere l’incertezza è utile soltanto se il sistema dispone di un modo concreto per gestirla.

Una delle questioni più importanti legate all’IA autonoma è stabilire quando l’approvazione umana rimanga essenziale. Quali interventi di ripristino in produzione ritieni che l’IA dovrebbe poter eseguire autonomamente e quali dovrebbero sempre richiedere l’autorizzazione di una persona? Come dovrebbero definire le organizzazioni questi limiti quando sono in gioco transazioni finanziarie, conformità normativa o fiducia dei clienti?

Stabilirei il limite in base alle conseguenze di un eventuale errore, non in base al fatto che un’azione sia etichettata come «IA».

Un ragionevole punto di partenza è un’indagine in sola lettura, a condizione che l’agente possa accedere soltanto alle informazioni autorizzate. Può raccogliere dati diagnostici, raggruppare avvisi correlati e preparare un riepilogo dell’incidente senza poter modificare la transazione sottostante.

Anche alcune procedure di ripristino predefinite possono prestarsi all’automazione, se le relative condizioni vengono verificate in modo indipendente e gli effetti sono limitati.

Richiederei l’autorizzazione di una persona quando un intervento proposto esula da una procedura approvata, quando i dati sono in conflitto e l’esito finanziario resta incerto, oppure quando l’azione modificherebbe i controlli di sicurezza o le autorizzazioni dell’agente stesso. Sono decisioni che un agente non dovrebbe autorizzare autonomamente.

Questo non significa che ogni normale operazione finanziaria debba essere approvata da una persona. L’elaborazione consolidata basata su regole è diversa dal permettere a un modello di inventare una correzione durante un incidente.

Anche la revisione umana deve essere sostanziale. Una schermata di approvazione dovrebbe mostrare le prove a supporto, le incertezze residue, gli effetti previsti e le alternative disponibili. Chiedere a qualcuno di approvare un paragrafo formulato con sicurezza, senza fornire questo contesto, offre ben poca protezione.

Questi limiti dovrebbero essere concordati prima della messa in produzione. Un’interruzione del servizio è il momento sbagliato per decidere quanta autorità dovrebbe avere un sistema automatizzato.

Hai maturato una vasta esperienza nei sistemi backend tolleranti ai guasti, negli strumenti di osservabilità e nelle integrazioni tra servizi software e hardware fisico. Di quali dati di telemetria e prove in produzione avrebbe bisogno un agente IA per diagnosticare un incidente in modo affidabile? Come possono i team di progettazione distinguere tra raccomandazioni utili generate dall’IA e conclusioni plausibili ma errate, che potrebbero aggravare un’interruzione del servizio?

Partirei da prove che colleghino l’operazione del cliente attraverso i sistemi coinvolti: identificativi delle transazioni, eventi dei servizi, modifiche persistenti allo stato, risposte dei dispositivi ed errori di comunicazione.

Contano anche le versioni del software e le modifiche alla configurazione. Un guasto che si verifica dopo un rilascio offre a chi indaga un indizio utile, ma la sola coincidenza temporale non dimostra un rapporto di causa-effetto.

L’agente deve anche comprendere i limiti delle prove. I log possono essere incompleti, i dati possono arrivare in ritardo e gli orologi possono non essere sincronizzati. La mancanza di una conferma non dimostra che non sia stata eseguita alcuna operazione.

Una diagnosi utile dovrebbe distinguere le osservazioni dalle interpretazioni. «Il client ha registrato un timeout» è un’osservazione. «Il backend non era disponibile» è una spiegazione che richiede ulteriori riscontri.

Mi aspetterei che una raccomandazione indicasse i dati su cui si basa, spiegasse che cosa resta ignoto e specificasse quale ulteriore verifica potrebbe confermare o smentire la conclusione.

Gli ingegneri dovrebbero poi verificare le raccomandazioni con conseguenze rilevanti consultando i dati originali, anziché affidarsi soltanto al riepilogo dell’agente. Questo è particolarmente importante quando il riepilogo condensa una cronologia degli eventi lunga o contraddittoria.

Il criterio che adotterei è semplice: un altro ingegnere può seguire le prove e arrivare a una conclusione difendibile? Se la spiegazione non supera questa verifica, non è pronta a guidare una modifica in produzione.

Nella tua ricerca pubblicata sulla resilienza al ransomware dei terminali per lotterie e scommesse, hai valutato un framework di sicurezza assistito dall’IA utilizzando un ambiente sintetico che simulava 500 terminali. Quali sono stati i risultati più importanti e quali limiti dovrebbero tenere presenti i lettori nell’interpretarli? Quali ulteriori verifiche sarebbero necessarie prima di applicare l’architettura proposta a un ambiente di produzione reale?

Volevo esaminare la resilienza oltre il rilevamento: come un ambiente di terminali potesse limitare un attacco, riconoscerlo e ripristinare il sistema preservando le prove di quanto accaduto.

Il Resilient Security Framework risultante combinava controlli preventivi, rilevamento delle anomalie assistito dall’IA e meccanismi definiti di risposta e ripristino. La componente di IA riguardava il rilevamento di comportamenti sospetti. Non si trattava di un esperimento volto a consentire a un agente basato su un modello linguistico di modificare autonomamente transazioni finanziarie.

La valutazione ha utilizzato un ambiente sintetico che rappresentava 500 terminali nell’arco di una simulazione di 72 ore, con emulazioni comportamentali di attacchi ransomware, anziché un’implementazione su 500 terminali fisici.

Rispetto al riferimento dello studio basato esclusivamente sull’antivirus, il tempo medio di rilevamento è sceso da 52 a 31 minuti e il tempo medio di ripristino da 120 a 56 minuti.

Questi sono i risultati ottenuti con il framework combinato nelle condizioni sperimentali. Non vanno attribuiti alla sola IA né considerati garanzie di prestazioni in un ambiente operativo reale. Un risultato interessante è che una rilevazione più tempestiva, da sola, non ha prodotto lo stesso miglioramento nei tempi di recupero. Anche la progettazione del contenimento e del ripristino ha avuto un ruolo.

È importante considerare i limiti dello studio. I carichi di lavoro simulati, le condizioni di rete, i comportamenti degli attacchi e le difese di riferimento non rappresentano tutti gli ambienti operativi. Dispositivi e applicazioni diversi richiederebbero nuove convalide.

Prima di un impiego in produzione, vorrei effettuare test su hardware rappresentativo, una valutazione indipendente della sicurezza, prove di durata maggiore e misurazioni accurate dei falsi allarmi e del sovraccarico di elaborazione.

Verificherei inoltre il processo di ripristino in rapporto alle normali attività di transazione. Ripristinare un’immagine software funzionante non basta se, durante il processo, si perdono le informazioni necessarie per contabilizzare le transazioni completate.

Lo studio costituisce una base per ulteriori test. Dimostrare che il sistema si comporta in modo sicuro in un ambiente operativo reale è un passaggio distinto.

La sua prospettiva unisce anni di esperienza nell’ingegneria dei sistemi in produzione alla ricerca accademica sull’affidabilità del software e sulla sicurezza basata sull’IA. Può distinguere i meccanismi di affidabilità che ha implementato personalmente o gestito in sistemi di produzione reali dagli approcci che ha esplorato attraverso la ricerca o test simulati? Quali funzionalità di ripristino basate sull’IA ritiene già praticabili oggi e quali sono ancora in gran parte sperimentali?

La mia attività in ambito produttivo ha incluso sviluppo e integrazione software, convalida delle transazioni, risoluzione dei problemi, test e convalida delle versioni.

La ricerca che ho pubblicato è una parte distinta del mio lavoro, e ogni studio va interpretato alla luce dei metodi e dei limiti dichiarati.

L’articolo sul ransomware valuta un framework di sicurezza proposto in un ambiente di test sintetico. Il mio articolo sull’IA all’edge è un’analisi basata sulla letteratura dell’intelligenza elaborata direttamente sul dispositivo e delle sue possibili applicazioni ai terminali per le transazioni. Il mio articolo per IEEE FeedForward esamina un’architettura di affidabilità assistita dall’IA tramite una simulazione controllata, che include monitoraggio, escalation e comportamento di ripiego.

Nessuna di queste pubblicazioni va interpretata come prova del fatto che abbia implementato un agente autonomo di IA autorizzato a intervenire su transazioni finanziarie reali.

Per gli impieghi pratici, darei la priorità a strumenti di supporto verificabili dagli ingegneri: riepiloghi degli incidenti collegati ai documenti di origine, correlazioni tra gli avvisi e controlli diagnostici suggeriti. La loro utilità deve comunque essere misurata nell’ambiente in cui verranno utilizzati.

La sfida più difficile è il ripristino a fronte di situazioni impreviste, in cui un modello sceglie ed esegue modifiche in condizioni non anticipate. Per questo occorre un livello di evidenze molto più elevato rispetto a quello necessario per un utile suggerimento diagnostico.

Considero complementari la mia esperienza in produzione e la mia attività di ricerca: la prima definisce i problemi operativi che conosco, mentre la seconda esplora approcci che devono ancora dimostrare, attraverso la convalida, di essere validi.

Guardando al futuro, man mano che gli agenti di IA diventeranno più capaci di rilevare anomalie, diagnosticare guasti e coordinare il ripristino nei sistemi distribuiti, come immagina che evolverà il rapporto tra sistemi autonomi e ingegneri? Quali garanzie tecniche, evidenze operative e meccanismi di responsabilizzazione sarebbero necessari perché le organizzazioni possano affidare con sicurezza all’IA maggiori responsabilità nelle infrastrutture di produzione mission-critical?

Mi aspetto che l’IA si occupi di una quota crescente del lavoro necessario per ricostruire il quadro di un incidente. Gli ingegneri potrebbero partire da una cronologia utile, dai componenti coinvolti, da spiegazioni alternative e dalle prove mancanti, anziché dedicare tanto tempo a raccogliere manualmente queste informazioni.

In questo modo, le persone avrebbero più tempo per prendere decisioni che richiedono di comprendere gli obblighi del sistema e le conseguenze delle modifiche.

Estenderei gradualmente l’autorità di esecuzione. Inizialmente, un agente potrebbe operare in modalità ombra, formulando raccomandazioni senza metterle in pratica. I team potrebbero confrontare tali raccomandazioni con gli esiti verificati e testare il comportamento dell’agente quando le informazioni sono mancanti, contraddittorie o obsolete.

La valutazione dovrebbe includere interventi errati, problemi non rilevati, escalation non necessarie e capacità di recupero dagli errori dell’agente stesso. Una raccomandazione rapida non è utile se indirizza la squadra di intervento nella direzione sbagliata.

Anche l’autorità più ampia dovrebbe restare subordinata a determinate condizioni. Un aggiornamento del modello o una modifica sostanziale del sistema potrebbero invalidare i test precedenti. I team devono poter ridurre o revocare le autorizzazioni dell’agente quando il suo comportamento non soddisfa più gli standard richiesti.

Con il miglioramento dell’automazione, la responsabilità umana non viene meno. Qualcuno deve essere responsabile delle regole operative, delle prove necessarie per autorizzare una modifica e del processo di indagine sui guasti.

Immagino che gli ingegneri dedicheranno meno tempo a raccogliere informazioni e più tempo a definire, testare e mantenere le condizioni che giustificano un intervento automatizzato.

Grazie per l’ottima intervista. I lettori che desiderano seguire il suo lavoro sull’affidabilità delle transazioni distribuite e sul ripristino responsabile assistito dall’IA possono entrare in contatto con Sapan Pandya.