Sapan Pandya, senior programvareingeniør og seniormedlem i IEEE – intervjuserien

Sapan Pandya er senior programvareingeniør og seniormedlem i IEEE, med base i New Jersey og mer enn ti års erfaring med robuste, distribuerte transaksjonssystemer. Arbeidet hans omfatter transaksjonsintegritet, integrasjon mellom programvare og fysiske enheter, feilsøking i produksjonsmiljøer og validering av utrullinger i regulerte miljøer. Han har en mastergrad i informatikk fra Stevens Institute of Technology og bidrar til fagfellevurdering og teknisk forskning.

Pandyas forskning utforsker cybersikkerhet for kiosker, KI på kanten og KI-assistert pålitelighetsarbeid, mens erfaringen hans fra produksjonsmiljøer preger fokuset på dokumentasjon, transaksjonsutfall og operasjonelt ansvar. I dette intervjuet snakker han om idempotens, motstridende transaksjonsopplysninger, usikkerhet i gjenopprettingssystemer og kontrollene som må være på plass før KI-agenter kan handle på virksomhetskritisk infrastruktur. Han skiller mellom praktisk ingeniørerfaring og forskning basert på litteraturanalyser og kontrollerte eller syntetiske tester.

Karrieren din har vært preget av arbeid med programvarepålitelighet og distribuerte transaksjonssystemer. Hvordan har denne erfaringen formet forståelsen din av pålitelighet, og hvilke utfordringer har påvirket synet ditt på bruk av KI til å håndtere komplekse systemer?

Perspektivet mitt har endret seg fra å spørre om en komponent fungerer, til å spørre om kundens transaksjon er fullført og kan dokumenteres.

Tidligere i karrieren var mye av oppmerksomheten min rettet mot applikasjonens oppførsel: å validere inndata, håndtere svar og sørge for at grensesnittet fulgte den tiltenkte arbeidsflyten. Etter hvert som ansvarsområdene mine ble utvidet til også å omfatte systemintegrasjon, feilsøking i produksjonsmiljøer og validering av utrullinger, måtte jeg se utover de enkelte komponentene.

En tjeneste kan fullføre arbeidet sitt mens en annen tjeneste fortsatt venter på bekreftelse. Programvaren kan registrere en vellykket operasjon selv om en fysisk enhet ikke leverer det forventede resultatet. At hver enkelt komponent består testene, er ikke i seg selv noen garanti for at hele samhandlingen vil fungere som den skal.

Denne erfaringen har gjort meg særlig interessert i grensene mellom systemer. Hva vet hver enkelt komponent? Hva tar den for gitt? Hva skjer når disse forutsetningene ikke lenger stemmer?

Den påvirker også hvordan jeg tenker om KI. Det kan være svært nyttig å hjelpe ingeniører med å samle dokumentasjon, gjenkjenne mønstre og undersøke feil raskere. Men en forklaring på hva som sannsynligvis skjedde, er noe annet enn en bekreftet redegjørelse for hva som faktisk skjedde.

Jeg ønsker at KI skal redusere innsatsen som kreves for å undersøke et problem, uten å senke kravene til dokumentasjon for å løse det.

Du har understreket at teknisk korrekt kode ikke alltid garanterer at transaksjoner får riktig utfall. Kan du gi et konkret eksempel på en transaksjon som ser ut til å mislykkes på grunn av et tidsavbrudd, men som faktisk er fullført? Hva kan gå galt når systemet automatisk prøver operasjonen på nytt, og hvordan bør ingeniører forhindre doble transaksjoner?

Tenk deg en hypotetisk betaling på 50 dollar. Applikasjonen sender en forespørsel, betalingstjenesten registrerer den som vellykket, og svaret går tapt før det når applikasjonen.

Kunden får et tidsavbrudd selv om betalingen allerede er gjennomført. Hvis applikasjonen sender en ny betalingsforespørsel, kan kunden bli belastet på nytt.

Et tidsavbrudd forteller deg at svaret ikke kom fram i tide. Det forteller deg ikke om den underliggende transaksjonen ble gjennomført.

Et vanlig sikkerhetstiltak er idempotens: å gjøre det mulig å gjenta den samme logiske forespørselen uten at det oppstår en ny økonomisk effekt. Applikasjonen beholder en operasjonsidentifikator ved nye forsøk, og mottakertjenesten gjenkjenner den som den opprinnelige forespørselen, ikke som et nytt kjøp.

Det viktigste er ikke bare å legge ved en identifikator. Tjenesten må håndheve denne identiteten og bevare nok informasjon til å skille mellom en fullført operasjon og en som fortsatt pågår. En identifikator kan ikke beskytte en etterfølgende handling som ignorerer den.

Når utfallet fortsatt er usikkert, bør gjenopprettingsprosessen kontrollere den eksisterende transaksjonen og avstemme de relevante opplysningene, i stedet for straks å opprette en erstatning.

Jeg ville også satt grenser for nye forsøk og definert hva som skal skje når automatisk gjenoppretting ikke kan fastslå utfallet. Kunden trenger en tydelig status som viser at saken fortsatt behandles, og en vei til å få den løst – ikke gjentatte belastninger eller en behandlingsskjerm som aldri blir ferdig.

I distribuerte systemer kan en database, en backend-tjeneste og en fysisk kiosk rapportere motstridende opplysninger om den samme transaksjonen. Har du støtt på denne typen inkonsistens i produksjonsmiljøer, og hvordan ble den undersøkt og løst? Hvilken rolle kan KI eventuelt spille i å avstemme disse motstridende opplysningene?

Ja, undersøkelser av inkonsistens i transaksjonstilstander har vært en del av arbeidet mitt i produksjonsmiljøer. For å forklare resonnementet uten å diskutere en hendelse fra arbeidsplassen bruker jeg et hypotetisk eksempel.

Se for deg en generisk selvbetjent kasse. Betalingstjenesten registrerer et vellykket kjøp, skriveren melder at den har godtatt utskriftsjobben for kvitteringen, og deretter viser skjermen en feilmelding. Disse observasjonene kan beskrive ulike stadier i samhandlingen uten dermed å bevise at hele kjøpet mislyktes.

Jeg ville først rekonstruert hendelsesforløpet ved hjelp av transaksjons-ID-en og de relevante loggene fra tjenester og enheter. Deretter ville jeg fastslått hva hver observasjon faktisk viser. At en skriver godtar en utskriftsjobb, er ikke nødvendigvis bevis på at papiret nådde kunden. At en forespørsel er mottatt, er ikke nødvendigvis bevis på at den økonomiske virkningen ble gjennomført.

Løsningen avhenger av hvilket stadium som sviktet. Det kan være uhensiktsmessig å gjenta hele transaksjonen hvis det bare er utskriften som trenger oppfølging. Hvis de tilgjengelige bevisene ikke kan fastslå hva som skjedde, bør den berørte operasjonen holdes under kontroll mens noen undersøker saken.

En varig løsning må også ta tak i hvorfor avviket kunne oppstå, i stedet for bare å rette én post.

KI kan bidra til å sammenstille hendelser og avdekke manglende informasjon. Jeg ville bedt den presentere alternative forklaringer og bevisene som støtter hver av dem. Den bør bidra til å avgrense undersøkelsen, ikke løse motstridende opplysninger ved å velge den forklaringen som høres mest overbevisende ut.

Når KI-agenter går fra å diagnostisere produksjonshendelser til å anbefale eller utføre gjenopprettingstiltak, hvilke sikkerhetstiltak bør være på plass før et KI-system kan prøve en transaksjon på nytt, reversere den eller endre den? Hvordan kan deterministiske kontroller som idempotensnøkler, transaksjonslogger og avstemmingsmekanismer hindre KI i å forårsake ytterligere feil?

Jeg ville skilt mellom å foreslå en handling og å godkjenne og utføre den.

En KI-agent kan anbefale et nytt forsøk, men en separat kontroll bør avgjøre om det er tillatt. Den bør kontrollere transaksjonens nåværende tilstand, operasjonens identitet, agentens tillatelser og vilkårene for at handlingen skal være trygg.

Denne kontrollen må utføres når handlingen gjennomføres, ikke bare da modellen først undersøkte hendelsen. En annen prosess kan ha fullført transaksjonen i mellomtiden.

Verktøyene agenten har tilgang til, bør også være begrensede. Tillatelse til å hente status for en transaksjon er noe annet enn tillatelse til å reversere en betaling eller endre en økonomisk post. Agenten bør ikke kunne utvide sine egne fullmakter fordi løsningen den foretrekker, krever større tilgang.

Idempotens begrenser dupliserte virkninger. Logger bevarer historikken som trengs for å undersøke saken. Avstemming kontrollerer om relevante poster samsvarer. Ingen av disse tiltakene kan alene fastslå at en foreslått handling er hensiktsmessig.

Jeg ville også registrert hvilke bevis som ble brukt, anbefalingen, godkjenningsbeslutningen og det faktiske resultatet. Da blir det mulig å gjennomgå tiltaket i etterkant.

Disse kontrollene bør håndheves av testbar programvare utenfor modellen. Instrukser om at en agent skal være forsiktig, er nyttig veiledning, men de er ikke en mekanisme for godkjenning.

Se for deg et scenario der et KI-basert overvåkingssystem oppdager en tilsynelatende transaksjonsfeil og anbefaler å reversere operasjonen automatisk. Hvis transaksjonen faktisk ble gjennomført, men bekreftelsen ble forsinket, kan dette tiltaket skape et nytt problem. Hvordan bør ingeniørteam utforme KI-drevne gjenopprettingssystemer slik at de gjenkjenner usikkerhet og unngår å iverksette korrigerende tiltak på grunnlag av ufullstendig informasjon?

Systemet trenger en reell tilstand for «utfallet er ukjent». Ellers vil det sannsynligvis gjøre manglende informasjon om til en feilaktig beslutning om at transaksjonen mislyktes.

En forsinket bekreftelse er grunn til å undersøke saken, ikke automatisk grunn til å reversere en transaksjon. En reversering er en ny økonomisk operasjon med egne konsekvenser. Den krever en begrunnelse som er fastslått uavhengig, og riktig godkjenning.

Jeg ville delt responsen i to spor. Undersøkelsessporet kan hente status, samle inn manglende hendelser, sammenligne poster og varsle det ansvarlige teamet. Sporet for økonomiske handlinger forblir blokkert til vilkårene er oppfylt.

Dette hindrer at en KI-modells konfidensskår blir en erstatning for bevis knyttet til transaksjonen. En modell kan være svært sikker på en forklaring som bygger på ufullstendig informasjon.

Det må også finnes et tydelig tidspunkt for eskalering. Det er ikke en tilfredsstillende løsning for kunden å la en transaksjon stå uavklart på ubestemt tid. Noen må ha ansvar for den uavklarte saken og nok kontekst til å avgjøre hva som er det neste trygge steget.

Gjenopprettingsprosessen må derfor kunne si både «Jeg kan ennå ikke begrunne å endre denne transaksjonen» og «Dette må gjøres for å løse saken».

Det er bare nyttig å erkjenne usikkerhet hvis systemet også har en praktisk måte å håndtere den på.

Et av de viktigste spørsmålene knyttet til autonom KI er å avgjøre når menneskelig godkjenning fortsatt er avgjørende. Hvilke tiltak for gjenoppretting i produksjonsmiljøer mener du KI bør kunne utføre på egen hånd, og hvilke bør alltid kreve godkjenning fra et menneske? Hvordan bør organisasjoner trekke disse grensene når økonomiske transaksjoner, etterlevelse av regelverk eller kundenes tillit står på spill?

Jeg ville trukket grensen ut fra konsekvensene av å ta feil, ikke ut fra om en handling er merket «KI».

Undersøkelser uten skrivetilgang er et fornuftig utgangspunkt, forutsatt at agenten bare har tilgang til informasjon den har tillatelse til å bruke. Den kan samle inn diagnostiske logger, gruppere relaterte varsler og utarbeide et sammendrag av hendelsen uten å få lov til å endre den underliggende transaksjonen.

Enkelte forhåndsdefinerte gjenopprettingsrutiner kan også egne seg for automatisering når vilkårene deres er bekreftet uavhengig, og virkningene er begrensede.

Jeg ville krevd godkjenning fra et menneske når et foreslått inngrep faller utenfor en godkjent rutine, når opplysningene spriker og det økonomiske utfallet fortsatt er uavklart, eller når handlingen vil endre sikkerhetskontroller eller agentens egne tillatelser. Dette er beslutninger agenten ikke bør kunne godkjenne på egne vegne.

Det betyr ikke at en person må godkjenne hver eneste rutinemessige økonomiske operasjon. Regelstyrt behandling etter etablerte rutiner er noe annet enn å la en modell finne på en korrigering under en hendelse.

Menneskelig gjennomgang må også være reell. Et godkjenningsvindu bør vise dokumentasjonen som støtter forslaget, gjenværende usikkerhet, forventet virkning og tilgjengelige alternativer. Det gir liten ekstra beskyttelse å be noen godkjenne et selvsikkert formulert avsnitt uten denne konteksten.

Disse grensene bør fastsettes før systemet tas i bruk. Et driftsavbrudd er feil tidspunkt å avgjøre hvor mye myndighet et automatisert system bør ha.

Du har lang erfaring med feiltolerante backend-systemer, verktøy for observerbarhet og integrasjoner mellom programvaretjenester og fysisk maskinvare. Hva slags telemetri og dokumentasjon fra produksjonsmiljøet trenger en KI-agent for å kunne diagnostisere en hendelse pålitelig? Hvordan kan ingeniørteam skille mellom nyttige KI-genererte anbefalinger og plausible, men feilaktige konklusjoner som kan forverre et driftsavbrudd?

Jeg ville begynt med dokumentasjon som knytter kundens operasjon sammen på tvers av de involverte systemene: transaksjonsidentifikatorer, tjenestehendelser, varige tilstandsendringer, svar fra enheter og kommunikasjonsfeil.

Programvareversjoner og konfigurasjonsendringer er også viktige. En feil som oppstår etter en lansering, gir den som undersøker saken et nyttig spor, men tidspunktet alene beviser ikke årsakssammenheng.

Agenten må også forstå begrensningene ved dokumentasjonen. Logger kan være ufullstendige, oppføringer kan komme sent, og klokkene kan vise ulike tidspunkter. At en bekreftelse mangler, er ikke det samme som bevis på at ingen operasjon fant sted.

En nyttig diagnose bør skille mellom observasjoner og tolkninger. «Klienten registrerte et tidsavbrudd» er en observasjon. «Backend-systemet var utilgjengelig» er en forklaring som krever ytterligere støtte.

Jeg ville forventet at en anbefaling viser til oppføringene den bygger på, forklarer hva som fortsatt er ukjent, og angir hvilken ytterligere kontroll som kan bekrefte eller avkrefte konklusjonen.

Ingeniørene bør deretter kontrollere anbefalinger med vesentlige konsekvenser mot de opprinnelige oppføringene, i stedet for bare å stole på agentens sammendrag. Dette er spesielt viktig når et sammendrag komprimerer en lang eller motstridende hendelseshistorikk.

Standarden jeg ville lagt til grunn, er enkel: Kan en annen ingeniør følge dokumentasjonen og komme fram til en konklusjon som kan forsvares? Hvis forklaringen ikke tåler en slik kontroll, er den ikke klar til å brukes som grunnlag for en endring i produksjonsmiljøet.

I den publiserte forskningen din på motstandsdyktighet mot løsepengevirus i lotteri- og bettingkiosker evaluerte du et KI-støttet sikkerhetsrammeverk ved hjelp av et syntetisk miljø som simulerte 500 kiosker. Hva var de viktigste funnene, og hvilke begrensninger bør leserne være klar over når de tolker resultatene? Hvilken ytterligere validering ville være nødvendig før den foreslåtte arkitekturen tas i bruk i et aktivt produksjonsmiljø?

Jeg ønsket å undersøke motstandsdyktighet utover deteksjon: hvordan et terminalmiljø kunne begrense et angrep, oppdage det og gjenopprettes, samtidig som dokumentasjonen av det som hadde skjedd, ble bevart.

Det resulterende Resilient Security Framework kombinerte forebyggende kontroller, KI-støttet anomalideteksjon og definerte mekanismer for respons og gjenoppretting. KI-komponenten handlet om å oppdage mistenkelig atferd. Dette var ikke et forsøk på å la en språkmodellagent endre økonomiske transaksjoner på egen hånd.

Evalueringen brukte et syntetisk miljø som representerte 500 kiosker over en simulering på 72 timer, med atferdsemuleringer av løsepengevirusangrep, i stedet for en utrulling på 500 fysiske terminaler.

Sammenlignet med studiens referansegrunnlag, som bare brukte antivirus, gikk den gjennomsnittlige deteksjonstiden ned fra 52 til 31 minutter, og den gjennomsnittlige gjenopprettingstiden gikk ned fra 120 til 56 minutter.

Dette er resultater for det samlede rammeverket under de eksperimentelle forholdene. De bør ikke tilskrives kunstig intelligens alene eller betraktes som ytelsesgarantier for et produksjonsmiljø. Et nyttig funn var at tidligere deteksjon ikke i seg selv ga den samme forbedringen i gjenoppretting. Utformingen av inneslutning og gjenoppretting hadde også betydning.

Begrensningene er viktige. De simulerte arbeidsbelastningene, nettverksforholdene, angrepsmønstrene og grunnsikringstiltakene gjenspeiler ikke alle driftsmiljøer. Andre enheter og applikasjoner ville kreve ny validering.

Før løsningen tas i bruk i produksjon, ville jeg ønsket testing på representativ maskinvare, en uavhengig sikkerhetsvurdering, evalueringer over lengre tid og grundige målinger av falske alarmer og prosesseringsbelastning.

Jeg ville også testet gjenopprettingsprosessen mot legitim transaksjonsaktivitet. Det er ikke nok å gjenopprette et fungerende programvarebilde hvis prosessen fører til tap av informasjonen som trengs for å gjøre rede for gjennomførte transaksjoner.

Studien gir et grunnlag for videre testing. Å påvise sikker atferd i et reelt driftsmiljø er et eget trinn.

Perspektivet ditt kombinerer mange års erfaring med produksjonsutvikling og akademisk forskning på programvarepålitelighet og KI-drevet sikkerhet. Kan du skille mellom pålitelighetsmekanismene du personlig har implementert eller driftet i aktive produksjonssystemer, og tilnærmingene du har utforsket gjennom forskning eller simulert testing? Hvilke KI-drevne gjenopprettingsfunksjoner mener du allerede er praktiske i dag, og hvilke er fortsatt stort sett eksperimentelle?

Produksjonsarbeidet mitt har omfattet programvareutvikling og integrering, transaksjonsvalidering, feilsøking, testing og validering før lansering.

Den publiserte forskningen min er en egen del av arbeidet mitt, og hver studie må forstås ut fra metodene og begrensningene den selv beskriver.

Ransomware-artikkelen evaluerer et foreslått sikkerhetsrammeverk i et syntetisk testmiljø. Artikkelen min om edge-KI er en litteraturbasert analyse av intelligens på enheten og mulige anvendelser i betalingsterminaler. Artikkelen min i IEEE FeedForward undersøker en KI-assistert pålitelighetsarkitektur gjennom en kontrollert simulering, med blant annet overvåking, eskalering og reservefunksjoner.

Ingen av disse publikasjonene bør tolkes som bevis på at jeg har tatt i bruk en autonom KI-agent med myndighet over aktive finansielle transaksjoner.

Ved praktisk bruk ville jeg prioritert støtte som ingeniører kan granske: hendelsessammendrag knyttet til kilderegistreringer, sammenhenger mellom varsler og forslag til diagnostiske kontroller. Hvor nyttige disse er, må fortsatt måles i miljøet de skal brukes i.

Den vanskeligere utfordringen er gjenoppretting i situasjoner uten forhåndsdefinerte løsninger, der en modell velger og gjennomfører endringer under forhold man ikke hadde forutsett. Det krever langt sterkere dokumentasjon enn et nyttig diagnostikkforslag.

Jeg ser produksjonserfaringen min og forskningen som utfyllende: Den ene gir grunnlag for de driftsproblemene jeg kjenner, mens den andre utforsker tilnærminger som fortsatt må bevise sin verdi gjennom validering.

Etter hvert som KI-agenter blir bedre til å oppdage avvik, diagnostisere feil og koordinere gjenoppretting på tvers av distribuerte systemer, hvordan ser du for deg at forholdet mellom autonome systemer og menneskelige ingeniører vil utvikle seg? Hvilke tekniske sikkerhetstiltak, driftsdokumentasjon og ansvarlighetsmekanismer vil være nødvendige før organisasjoner trygt kan gi KI større myndighet over virksomhetskritisk produksjonsinfrastruktur?

Jeg forventer at KI vil overta mer av arbeidet med å sette sammen et helhetlig bilde av en hendelse. Ingeniører kan begynne med en nyttig tidslinje, berørte komponenter, ulike mulige forklaringer og manglende dokumentasjon, i stedet for å bruke så mye tid på å samle dette manuelt.

Det vil gi folk mer tid til beslutninger som krever forståelse av systemets forpliktelser og konsekvensene av å endre det.

Jeg ville utvidet myndigheten til å gjennomføre handlinger gradvis. En agent kunne først kjøres i skyggemodus og utarbeide anbefalinger uten å handle på dem. Teamene kunne sammenligne anbefalingene med vurderte utfall og teste hvordan agenten oppfører seg når informasjon mangler, er motstridende eller er utdatert.

Evalueringen bør omfatte feilaktige inngrep, problemer som ikke oppdages, unødvendig eskalering og gjenoppretting etter agentens egne feil. En rask anbefaling er ikke verdifull hvis den leder responsteamet i feil retning.

Større myndighet bør også fortsatt være betinget. En modelloppdatering eller en større systemendring kan gjøre tidligere testing ugyldig. Teamene må ha en måte å begrense eller trekke tilbake agentens tillatelser på hvis atferden ikke lenger oppfyller den nødvendige standarden.

Menneskelig ansvar forsvinner ikke etter hvert som automatiseringen forbedres. Noen må ha ansvaret for driftsreglene, dokumentasjonen som kreves før en endring, og prosessen for å undersøke feil.

Jeg ser for meg at ingeniører vil bruke mindre tid på å samle informasjon og mer tid på å definere, teste og vedlikeholde vilkårene for når automatiserte handlinger er berettiget.

Takk for et flott intervju. Lesere som ønsker å følge arbeidet hans med pålitelighet i distribuerte transaksjoner og ansvarlig KI-assistert gjenoppretting, kan ta kontakt med Sapan Pandya.