Sapan Pandya, senior softwareingeniør og seniormedlem af IEEE – interviewserie

Sapan Pandya er senior softwareingeniør og seniormedlem af IEEE med base i New Jersey og mere end ti års erfaring med robuste, distribuerede transaktionssystemer. Hans arbejde spænder over transaktionsintegritet, integration mellem software og fysiske enheder, fejlfinding i produktionsmiljøer og validering af implementeringer i regulerede miljøer. Han har en kandidatgrad i datalogi fra Stevens Institute of Technology og bidrager til fagfællebedømmelse og teknisk forskning.

Pandya forsker i cybersikkerhed for kiosker, edge-AI og AI-understøttet pålidelighedsteknik, mens hans erfaring fra produktionsmiljøer præger hans fokus på dokumentation, transaktionsresultater og operationelt ansvar. I dette interview taler han om idempotens, modstridende transaktionsregistreringer, usikkerhed i gendannelsessystemer og de kontrolforanstaltninger, der skal være på plads, før AI-agenter kan handle på missionskritisk infrastruktur. Han skelner mellem praktisk ingeniørerfaring og forskning baseret på litteraturanalyse samt kontrollerede eller syntetiske tests.

Din karriere har haft fokus på softwares pålidelighed og distribuerede transaktionssystemer. Hvordan har den erfaring formet din forståelse af pålidelighed, og hvilke udfordringer har påvirket dit syn på brugen af AI til at styre komplekse systemer?

Mit perspektiv har ændret sig fra at spørge, om en komponent fungerer, til at spørge, om kundens transaktion er gennemført og kan gøres rede for.

Tidligere i min karriere fokuserede jeg i høj grad på applikationens adfærd: at validere input, håndtere svar og sikre, at brugergrænsefladen fulgte det tilsigtede workflow. Efterhånden som mit ansvar blev udvidet til også at omfatte systemintegration, fejlfinding i produktionsmiljøer og validering af implementeringer, måtte jeg se ud over de enkelte komponenter.

En tjeneste kan have afsluttet sit arbejde, mens en anden tjeneste stadig venter på bekræftelse. Software kan registrere, at en handling er gennemført, selvom en fysisk enhed ikke leverer det forventede resultat. At hver enkelt komponent består sine tests, er ikke i sig selv bevis på, at hele samspillet fungerer korrekt.

Den erfaring har gjort mig særligt interesseret i grænsefladerne mellem systemer. Hvad ved hver komponent? Hvad tager den for givet? Hvad sker der, når de antagelser ikke længere holder?

Den præger også min tilgang til AI. Det kan være meget værdifuldt at hjælpe ingeniører med at samle dokumentation, genkende mønstre og undersøge fejl hurtigere. Men en forklaring på, hvad der sandsynligvis skete, er ikke det samme som en verificeret redegørelse for, hvad der rent faktisk skete.

Jeg ønsker, at AI skal mindske den indsats, det kræver at undersøge et problem, uden at sænke kravene til den dokumentation, der skal til for at løse det.

Du har understreget, at teknisk korrekt kode ikke altid sikrer korrekte transaktionsresultater. Kan du give et konkret eksempel på en transaktion, der ser ud til at være mislykket på grund af en timeout, selvom den faktisk er gennemført? Hvad kan gå galt, når systemet automatisk prøver handlingen igen, og hvordan bør ingeniører forhindre dobbelte transaktioner?

Forestil dig en hypotetisk betaling på 50 $. Applikationen sender en anmodning, betalingstjenesten registrerer den korrekt, men svaret går tabt, før det når frem til applikationen.

Kunden får vist en timeout, selvom betalingen allerede er gennemført. Hvis applikationen sender en ny betalingsanmodning, kan kunden blive opkrævet igen.

En timeout fortæller dig, at svaret ikke nåede frem inden for tidsfristen. Den fortæller dig ikke, om den underliggende transaktion blev gennemført.

En almindelig beskyttelsesmekanisme er idempotens: at gøre det muligt at gentage den samme logiske anmodning uden at skabe en ny økonomisk virkning. Applikationen bevarer en operationsidentifikator ved gentagne forsøg, og den modtagende tjeneste genkender den som den oprindelige anmodning i stedet for et nyt køb.

Det afgørende er ikke blot at tilføje en identifikator. Tjenesten skal håndhæve identiteten og bevare tilstrækkelige oplysninger til at skelne mellem en gennemført handling og en, der stadig er under behandling. En identifikator kan ikke beskytte en efterfølgende handling, hvis den ignorerer den.

Hvis udfaldet fortsat er usikkert, bør gendannelsesforløbet kontrollere den eksisterende transaktion og afstemme de relevante registreringer i stedet for straks at oprette en erstatningstransaktion.

Jeg ville også sætte grænser for antallet af gentagne forsøg og fastlægge, hvad der skal ske, når automatisk gendannelse ikke kan fastslå udfaldet. Kunden har brug for en tydelig status om, at betalingen afventer, og en vej til at få sagen løst – ikke gentagne opkrævninger eller en behandlingsskærm, der aldrig forsvinder.

I distribuerede systemer kan en database, en backendtjeneste og en fysisk kiosk rapportere modstridende oplysninger om den samme transaktion. Er du stødt på denne type uoverensstemmelse i produktionsmiljøer, og hvordan blev den undersøgt og løst? Hvilken rolle kan AI eventuelt spille i afstemningen af disse modstridende registreringer?

Ja, undersøgelse af uoverensstemmelser i transaktionsstatus har været en del af mit arbejde i produktionsmiljøer. For at forklare tankegangen uden at omtale en konkret hændelse på en arbejdsplads vil jeg bruge et hypotetisk eksempel.

Forestil dig en almindelig selvbetjeningskasse. Betalingstjenesten registrerer et gennemført køb, printeren melder, at den har modtaget kvitteringsjobbet, og derefter viser skærmen en fejl. Observationerne kan beskrive forskellige faser af forløbet uden dermed at bevise, at hele købet mislykkedes.

Jeg ville først rekonstruere forløbet ved hjælp af transaktions-id’et og de relevante registreringer fra tjenester og enheder. Derefter ville jeg fastslå, hvad hver observation viser. At en printer modtager et job, er ikke nødvendigvis et bevis på, at kunden har fået papiret. At en anmodning er modtaget, er ikke nødvendigvis et bevis på, at dens økonomiske virkning er blevet gennemført.

Løsningen afhænger af, hvilken fase der mislykkedes. Det kan være uhensigtsmæssigt at gentage hele transaktionen, hvis det kun er udskrivningen, der kræver opmærksomhed. Hvis de foreliggende oplysninger ikke kan fastslå, hvad der skete, bør den berørte handling forblive under kontrol, mens nogen undersøger sagen.

En varig løsning skal også tage fat på, hvorfor uoverensstemmelsen kunne opstå, i stedet for blot at rette en enkelt registrering.

AI kan hjælpe med at sammenholde hændelser og finde manglende oplysninger. Jeg ville bede systemet fremlægge alternative forklaringer og den dokumentation, der understøtter hver af dem. Det bør hjælpe med at afgrænse undersøgelsen, ikke løse modstridende registreringer ved at vælge den forklaring, der lyder mest overbevisende.

Efterhånden som AI-agenter går fra at diagnosticere produktionshændelser til at anbefale eller udføre genopretningshandlinger, hvilke sikkerhedsforanstaltninger bør være på plads, før et AI-system kan forsøge en transaktion igen, tilbageføre den eller ændre den? Hvordan kan deterministiske kontroller som idempotensnøgler, transaktionslogfiler og afstemningsmekanismer forhindre AI i at skabe yderligere fejl?

Jeg ville adskille det at foreslå en handling fra det at godkende og udføre den.

En AI-agent kan anbefale et nyt forsøg, men en separat kontrol bør afgøre, om det er tilladt. Kontrollen bør undersøge transaktionens aktuelle status, handlingens identitet, agentens tilladelser og betingelserne for, at handlingen er sikker.

Kontrollen skal foretages, når handlingen udføres, ikke kun da modellen først undersøgte hændelsen. En anden proces kan have gennemført transaktionen i mellemtiden.

Agenten bør også kun have adgang til et begrænset sæt værktøjer. Tilladelse til at hente en transaktionsstatus er ikke det samme som tilladelse til at tilbageføre en betaling eller ændre en økonomisk registrering. Agenten bør ikke kunne udvide sine egne beføjelser, fordi dens foretrukne løsning kræver større adgang.

Idempotens begrænser dobbelte virkninger. Logfiler bevarer den historik, der er nødvendig for at undersøge sagen. Afstemning kontrollerer, om de relevante registreringer stemmer overens. Ingen af disse forhold fastslår i sig selv, om en foreslået handling er hensigtsmæssig.

Jeg ville også registrere den anvendte dokumentation, anbefalingen, godkendelsesbeslutningen og det faktiske resultat. Det gør det muligt at gennemgå indgrebet efterfølgende.

Disse kontroller bør håndhæves af software uden for modellen, som kan testes. Instruktioner om, at en agent skal være forsigtig, er nyttig vejledning, men de udgør ikke en godkendelsesmekanisme.

Forestil dig et scenarie, hvor et AI-overvågningssystem registrerer en tilsyneladende transaktionsfejl og anbefaler automatisk at tilbageføre transaktionen. Hvis transaktionen faktisk blev gennemført, men bekræftelsen blev forsinket, kan indgrebet skabe et nyt problem. Hvordan bør udviklingsteams designe AI-drevne genopretningssystemer, så de kan håndtere usikkerhed og undgå at iværksætte korrigerende handlinger på grundlag af ufuldstændige oplysninger?

Systemet skal have en reel status for »ukendt udfald«. Ellers risikerer det at fortolke manglende oplysninger som et fejlagtigt grundlag for at erklære en fejl.

En forsinket bekræftelse er grund til at undersøge sagen, ikke automatisk grund til at tilbageføre en transaktion. En tilbageførsel er endnu en økonomisk handling med sine egne konsekvenser. Den kræver en selvstændigt fastslået begrundelse og den rette godkendelse.

Jeg ville opdele håndteringen i to forløb. Undersøgelsesforløbet kan hente status, indsamle manglende hændelser, sammenligne registreringer og underrette det ansvarlige team. Forløbet for økonomiske handlinger forbliver blokeret, indtil betingelserne er opfyldt.

Det forhindrer, at en AI-konfidensscore bliver en erstatning for dokumentation om transaktionen. En model kan være meget sikker på en forklaring, der bygger på ufuldstændige oplysninger.

Der skal også være et fastlagt tidspunkt for eskalering. Det er ikke en tilfredsstillende løsning for kunden at lade en transaktion stå som afventende på ubestemt tid. En bestemt person bør have ansvaret for den uafklarede sag og have tilstrækkelig kontekst til at afgøre, hvad det næste sikre skridt er.

Genopretningsprocessen skal derfor kunne sige både »Jeg kan endnu ikke begrunde, at denne transaktion skal ændres« og »Her er, hvad der skal ske for at løse sagen«.

Det er kun nyttigt at erkende usikkerhed, hvis systemet også har en praktisk måde at håndtere den på.

Et af de største spørgsmål i forbindelse med autonom AI er at afgøre, hvornår menneskelig godkendelse fortsat er afgørende. Hvilke handlinger til genopretning af produktionen mener du, at AI bør have lov til at udføre selvstændigt, og hvilke bør altid kræve menneskelig godkendelse? Hvordan bør organisationer fastlægge disse grænser, når der er finansielle transaktioner, overholdelse af regler eller kundernes tillid på spil?

Jeg ville trække grænsen ud fra konsekvenserne af at tage fejl snarere end ud fra, om en handling betegnes som „AI“.

Undersøgelse med skrivebeskyttet adgang er et rimeligt udgangspunkt, forudsat at agenten kun har adgang til godkendte oplysninger. Den kan indsamle diagnosticeringsdata, gruppere relaterede alarmer og udarbejde en opsummering af hændelsen uden at få lov til at ændre den underliggende transaktion.

Nogle på forhånd fastlagte genopretningsprocedurer kan også egne sig til automatisering, når betingelserne for dem verificeres uafhængigt, og deres virkninger er begrænsede.

Jeg ville kræve menneskelig godkendelse, når et foreslået indgreb falder uden for en godkendt procedure, når oplysningerne er modstridende, og det finansielle resultat stadig er uafklaret, eller når handlingen vil ændre sikkerhedskontrollerne eller agentens egne tilladelser. Det er beslutninger, som en agent ikke bør kunne godkende på egne vegne.

Det betyder ikke, at en person skal godkende enhver rutinemæssig finansiel transaktion. Regelbaseret behandling efter fastlagte procedurer er noget andet end at lade en model finde på en korrektion midt i en hændelse.

Menneskelig gennemgang skal også være meningsfuld. En godkendelsesskærm bør vise den dokumentation, der ligger til grund, den resterende usikkerhed, den forventede effekt og de tilgængelige alternativer. Det giver kun ringe beskyttelse at bede nogen godkende et overbevisende formuleret afsnit uden den kontekst.

Disse grænser bør aftales inden implementeringen. Et nedbrud er det forkerte tidspunkt at beslutte, hvor stor myndighed et automatiseret system bør have.

Du har arbejdet indgående med fejltolerante backend-systemer, værktøjer til observerbarhed og integrationer mellem softwaretjenester og fysisk hardware. Hvilke telemetridata fra produktionen og hvilken dokumentation skulle en AI-agent have for pålideligt at kunne diagnosticere en hændelse? Hvordan kan ingeniørteams skelne mellem nyttige anbefalinger fra AI og plausible, men forkerte konklusioner, der kan forværre et nedbrud?

Jeg ville begynde med dokumentation, der forbinder kundens drift på tværs af de berørte systemer: transaktions-id’er, hændelser i tjenester, varige tilstandsændringer, enhedssvar og kommunikationsfejl.

Softwareversioner og konfigurationsændringer er også vigtige. En fejl, der opstår efter en udgivelse, giver den, der undersøger sagen, et nyttigt spor, men tidspunktet alene beviser ikke årsagssammenhæng.

Agenten skal også forstå dokumentationens begrænsninger. Logfiler kan være ufuldstændige, registreringer kan ankomme med forsinkelse, og systemernes ure kan vise forskellige tidspunkter. Manglende kvittering er ikke det samme som bevis for, at ingen handling fandt sted.

En nyttig diagnose bør skelne mellem observationer og fortolkninger. „Klienten registrerede en timeout“ er en observation. „Backend-systemet var utilgængeligt“ er en forklaring, der kræver yderligere belæg.

Jeg ville forvente, at en anbefaling henviser til de registreringer, den bygger på, forklarer, hvad der fortsat er ukendt, og angiver, hvilken yderligere kontrol der kan bekræfte eller afkræfte konklusionen.

Ingeniører bør derefter kontrollere anbefalinger med væsentlige konsekvenser op imod de oprindelige registreringer i stedet for udelukkende at stole på agentens opsummering. Det er især vigtigt, når en opsummering sammenfatter en lang eller modstridende hændelseshistorik.

Den standard, jeg ville anvende, er enkel: Kan en anden ingeniør følge dokumentationen og nå frem til en velbegrundet konklusion? Hvis forklaringen ikke kan bestå den prøve, er den ikke klar til at føre til en ændring i produktionen.

I din publicerede forskning i modstandsdygtighed over for ransomware i lotteri- og bettingkiosker evaluerede du et AI-understøttet sikkerhedsrammeværk i et syntetisk miljø, der simulerede 500 kiosker. Hvad var de vigtigste resultater, og hvilke begrænsninger bør læserne være opmærksomme på, når de fortolker dem? Hvilken yderligere validering ville være nødvendig, før den foreslåede arkitektur blev anvendt i et produktionsmiljø?

Jeg ville undersøge modstandsdygtighed ud over selve detektion: hvordan et terminalmiljø kunne begrænse et angreb, opdage det og genoprette driften, samtidig med at dokumentationen for det hændte blev bevaret.

Det resulterende Resilient Security Framework kombinerede forebyggende kontroller, AI-understøttet anomalidetektion samt fastlagte mekanismer til håndtering og genopretning. AI-komponenten handlede om at opdage mistænkelig adfærd. Der var ikke tale om et forsøg, hvor en agent baseret på en sprogmodel selvstændigt ændrede finansielle transaktioner.

Evalueringen blev udført i et syntetisk miljø, der repræsenterede 500 kiosker over en simulation på 72 timer, med adfærdsmæssige simuleringer af ransomwareangreb frem for en implementering på tværs af 500 fysiske terminaler.

Sammenlignet med undersøgelsens baseline, der kun anvendte antivirus, faldt den gennemsnitlige detektionstid fra 52 til 31 minutter, og den gennemsnitlige genoprettelsestid faldt fra 120 til 56 minutter.

Det er resultater for den samlede ramme under de eksperimentelle forhold. De bør ikke tilskrives AI alene eller betragtes som garantier for ydeevnen i et driftsmiljø. Et nyttigt resultat var, at tidligere detektion ikke i sig selv medførte den samme forbedring af genopretningen. Udformningen af både inddæmning og genopretning havde også betydning.

Begrænsningerne er vigtige. De simulerede arbejdsbelastninger, netværksforhold, angrebsadfærd og grundforsvar repræsenterer ikke alle driftsmiljøer. Forskellige enheder og applikationer ville kræve ny validering.

Før brug i produktion ville jeg ønske test på repræsentativ hardware, en uafhængig sikkerhedsvurdering, længerevarende evalueringer og omhyggelige målinger af falske alarmer og behandlingsomkostninger.

Jeg ville også teste genoprettelsesprocessen med legitime transaktionsaktiviteter. Det er ikke nok at gendanne et fungerende softwareimage, hvis processen medfører tab af de oplysninger, der er nødvendige for at registrere gennemførte transaktioner.

Undersøgelsen danner grundlag for yderligere test. At påvise sikker adfærd i et reelt driftsmiljø er et særskilt skridt.

Dit perspektiv forener mange års teknisk arbejde i produktionsmiljøer med akademisk forskning i softwarepålidelighed og AI-drevet sikkerhed. Kan du skelne mellem de pålidelighedsmekanismer, du personligt har implementeret eller drevet i aktive produktionssystemer, og de tilgange, du har undersøgt gennem forskning eller simulerede test? Hvilke AI-drevne genoprettelsesfunktioner mener du allerede er praktisk anvendelige i dag, og hvilke er stadig overvejende eksperimentelle?

Mit produktionsarbejde har omfattet softwareudvikling og -integration, validering af transaktioner, fejlfinding, test og validering af udgivelser.

Min publicerede forskning er en særskilt del af mit arbejde, og hver undersøgelse skal forstås ud fra de metoder og begrænsninger, der er angivet.

Artiklen om ransomware evaluerer en foreslået sikkerhedsramme i et syntetisk testmiljø. Min artikel om edge-AI er en litteraturbaseret analyse af intelligens på enheder og dens mulige anvendelse i betalingsterminaler. Min artikel i IEEE FeedForward undersøger en AI-assisteret pålidelighedsarkitektur gennem kontrolleret simulering, herunder overvågning, eskalering og adfærd ved overgang til en reservefunktion.

Ingen af disse publikationer bør læses som dokumentation for, at jeg har implementeret en autonom AI-agent med beføjelse til at håndtere aktive finansielle transaktioner.

I praktisk brug ville jeg prioritere hjælp, som ingeniører kan efterprøve: hændelsesoversigter med henvisninger til kilderegistreringer, sammenhænge på tværs af alarmer og forslag til diagnostiske kontroller. Nytten skal stadig måles i det miljø, hvor løsningerne skal fungere.

Den sværere udfordring er åben genopretning, hvor en model vælger og udfører ændringer under forhold, der ikke var forudset. Det kræver langt stærkere dokumentation end et nyttigt diagnostisk forslag.

Jeg ser min produktionserfaring og min forskning som komplementære: Den ene giver grundlag for de driftsmæssige problemer, jeg kender, mens den anden undersøger tilgange, der stadig skal bevise deres værdi gennem validering.

Hvis vi ser fremad, hvordan forestiller du dig så, at forholdet mellem autonome systemer og menneskelige ingeniører vil udvikle sig, efterhånden som AI-agenter bliver bedre til at opdage afvigelser, diagnosticere fejl og koordinere genopretning på tværs af distribuerede systemer? Hvilke tekniske sikkerhedsforanstaltninger, driftsmæssig dokumentation og ansvarlighedsmekanismer vil være nødvendige, før organisationer trygt kan give AI større beføjelser over forretningskritisk produktionsinfrastruktur?

Jeg forventer, at AI vil overtage mere af arbejdet med at sammenstille et overblik over en hændelse. Ingeniører vil kunne begynde med en nyttig tidslinje, berørte komponenter, mulige forklaringer og manglende dokumentation i stedet for at bruge så meget tid på at indsamle materialet manuelt.

Det vil give folk mere tid til beslutninger, der kræver forståelse for systemets forpligtelser og konsekvenserne af at ændre det.

Jeg ville gradvist udvide agentens beføjelser til at udføre handlinger. Først kunne en agent køre i skyggetilstand og komme med anbefalinger uden at handle på dem. Teams kunne sammenligne anbefalingerne med gennemgåede resultater og teste, hvordan agenten reagerer, når oplysninger mangler, er modstridende eller forældede.

Evalueringen bør omfatte fejlagtige indgreb, oversete problemer, unødvendig eskalering og genopretning efter agentens egne fejl. En hurtig anbefaling er ikke værdifuld, hvis den leder indsatsteamet i den forkerte retning.

Større beføjelser bør også fortsat være betingede. En modelopdatering eller en større systemændring kan gøre tidligere test ugyldige. Teams har brug for en måde at begrænse eller trække agentens tilladelser tilbage på, når dens adfærd ikke længere lever op til den krævede standard.

Menneskers ansvar forsvinder ikke, efterhånden som automatiseringen bliver bedre. Nogen skal være ansvarlig for driftsreglerne, den dokumentation, der kræves for at foretage en ændring, og processen for at undersøge fejl.

Jeg ser for mig, at ingeniører bruger mindre tid på at indsamle oplysninger og mere tid på at fastlægge, teste og vedligeholde de betingelser, der gør automatiserede handlinger berettigede.

Tak for et godt interview. Læsere, der ønsker at følge hans arbejde med pålidelighed i distribuerede transaktioner og ansvarlig AI-understøttet gendannelse, kan komme i kontakt med Sapan Pandya.