Sapan Pandya, senior mjukvaruingenjör och senior medlem i IEEE – intervjuserie

Sapan Pandya är senior mjukvaruingenjör och senior medlem i IEEE, bosatt i New Jersey, med mer än tio års erfarenhet av feltåliga distribuerade transaktionssystem. Hans arbete omfattar transaktionsintegritet, integration mellan programvara och fysiska enheter, felsökning i produktionsmiljöer och validering av driftsättningar i reglerade miljöer. Han har en masterexamen i datavetenskap från Stevens Institute of Technology och bidrar till sakkunniggranskning och teknisk forskning.

Pandya forskar om cybersäkerhet för kiosker, edge-AI och AI-assisterad tillförlitlighetsteknik. Hans erfarenhet från produktionsmiljöer ligger till grund för hans fokus på evidens, transaktionsutfall och operativt ansvar. I den här intervjun diskuterar han idempotens, motstridiga transaktionsposter, osäkerhet i återställningssystem och vilka skyddsåtgärder som krävs innan AI-agenter kan agera på verksamhetskritisk infrastruktur. Han skiljer mellan praktisk erfarenhet av ingenjörsarbete och forskning som bedrivs genom litteraturstudier samt kontrollerade eller syntetiska tester.

Din karriär har varit inriktad på programvarutillförlitlighet och distribuerade transaktionssystem. Hur har den erfarenheten format din syn på tillförlitlighet, och vilka utmaningar har påverkat ditt perspektiv på att använda AI för att hantera komplexa system?

Mitt perspektiv har förändrats: i stället för att fråga om en komponent fungerar frågar jag om kundens transaktion är slutförd och kan redovisas.

Tidigare i karriären låg mycket av mitt fokus på applikationens beteende: att validera indata, hantera svar och se till att gränssnittet följde det avsedda arbetsflödet. När mitt ansvar utökades till att omfatta systemintegration, felsökning i produktionsmiljöer och validering av driftsättningar behövde jag se bortom de enskilda komponenterna.

En tjänst kan slutföra sitt arbete medan en annan fortfarande väntar på bekräftelse. Programvara kan registrera att en åtgärd har lyckats, samtidigt som en fysisk enhet inte levererar det förväntade resultatet. Att varje komponent klarar testerna visar inte i sig att hela interaktionen kommer att fungera som den ska.

Den erfarenheten har gjort mig särskilt intresserad av gränssnitten mellan system. Vad vet varje komponent? Vad utgår den ifrån? Vad händer när dessa antaganden inte längre stämmer?

Det påverkar också hur jag ser på AI. Det finns ett verkligt värde i att hjälpa ingenjörer att sammanställa evidens, känna igen mönster och utreda fel snabbare. Men en förklaring av vad som sannolikt hände är inte detsamma som en verifierad redogörelse för vad som faktiskt hände.

Jag vill att AI ska minska arbetsinsatsen för att utreda ett problem utan att sänka kraven på den evidens som behövs för att lösa det.

Du har betonat att tekniskt korrekt kod inte alltid garanterar korrekta transaktionsutfall. Kan du beskriva ett konkret exempel där en transaktion verkar misslyckas på grund av en tidsgräns, trots att den faktiskt har slutförts? Vad kan gå fel när systemet automatiskt försöker utföra åtgärden igen, och hur bör ingenjörer förhindra dubbla transaktioner?

Tänk dig en hypotetisk betalning på 50 dollar. Applikationen skickar en begäran, betaltjänsten registrerar den utan problem och svaret går förlorat innan det når applikationen.

Kunden ser att tidsgränsen har överskridits trots att betalningen redan har genomförts. Om applikationen skickar en ny betalningsbegäran kan kunden debiteras en gång till.

En överskriden tidsgräns visar att svaret inte kom fram i tid. Den säger inte om den underliggande transaktionen lyckades.

Ett vanligt skydd är idempotens: att samma logiska begäran kan upprepas utan att skapa ytterligare en ekonomisk transaktion. Applikationen behåller samma åtgärdsidentifierare vid varje nytt försök, och den mottagande tjänsten känner igen begäran som den ursprungliga i stället för som ett nytt köp.

Det viktiga är inte bara att lägga till en identifierare. Tjänsten måste upprätthålla identiteten och bevara tillräckligt med information för att skilja en slutförd åtgärd från en som fortfarande pågår. En identifierare kan inte skydda en efterföljande åtgärd som inte tar hänsyn till den.

När utfallet fortfarande är osäkert bör återställningsförfarandet kontrollera den befintliga transaktionen och stämma av de relevanta posterna, i stället för att omedelbart skapa en ersättningstransaktion.

Jag skulle också begränsa antalet nya försök och definiera vad som ska hända när automatisk återställning inte kan fastställa utfallet. Kunden behöver en tydlig status om att ärendet väntar på behandling och en väg till en lösning, inte upprepade debiteringar eller en behandlingsskärm som aldrig tar slut.

I distribuerade system kan en databas, en backendtjänst och en fysisk kiosk rapportera motstridiga uppgifter om samma transaktion. Har du stött på den här typen av inkonsekvens i produktionsmiljöer, och hur utreddes och löstes den? Vilken roll skulle AI i så fall kunna spela när dessa motstridiga poster ska stämmas av?

Ja, utredning av inkonsekvenser i transaktionsstatus har varit en del av mitt arbete i produktionsmiljöer. För att förklara resonemanget utan att diskutera en incident på en arbetsplats använder jag ett hypotetiskt exempel.

Tänk dig en vanlig självbetjäningskassa. Betaltjänsten registrerar ett genomfört köp, skrivaren rapporterar att den har tagit emot utskriftsjobbet för kvittot och skärmen visar sedan ett felmeddelande. Observationerna kan beskriva olika steg i förloppet snarare än bevisa att hela köpet misslyckades.

Jag skulle först återskapa händelseförloppet med hjälp av transaktionsidentifieraren och relevanta loggar från tjänster och enheter. Sedan skulle jag fastställa vad varje observation faktiskt visar. Att en skrivare har tagit emot ett utskriftsjobb är inte nödvändigtvis ett bevis för att kunden fick ett kvitto. Att en begäran har tagits emot är inte nödvändigtvis ett bevis för att dess ekonomiska effekt har genomförts.

Lösningen beror på vilket steg som misslyckades. Det kan vara olämpligt att upprepa hela transaktionen om det bara är utskriftssteget som behöver åtgärdas. Om tillgängliga belägg inte räcker för att fastställa vad som har hänt bör den berörda åtgärden hållas under kontroll medan någon utreder saken.

En varaktig korrigering måste också åtgärda orsaken till att inkonsekvensen kunde uppstå, i stället för att bara rätta en enskild post.

AI skulle kunna hjälpa till att koppla samman händelser och identifiera vilken information som saknas. Jag skulle be den att presentera flera möjliga förklaringar och beläggen för var och en. Den bör hjälpa till att avgränsa utredningen, inte lösa motstridiga uppgifter genom att välja den förklaring som låter mest övertygande.

När AI-agenter går från att diagnostisera produktionsincidenter till att rekommendera eller utföra återställningsåtgärder, vilka skyddsåtgärder bör finnas innan ett AI-system får försöka igen, återföra eller ändra en transaktion? Hur kan deterministiska kontroller, som idempotensnycklar, transaktionsloggar och avstämningsmekanismer, förhindra att AI orsakar ytterligare fel?

Jag skulle skilja mellan att föreslå en åtgärd och att godkänna och utföra den.

En AI-agent kan rekommendera ett nytt försök, men en separat kontroll bör avgöra om det är tillåtet. Kontrollen bör granska transaktionens aktuella status, åtgärdens identitet, agentens behörigheter och under vilka förutsättningar åtgärden är säker.

Kontrollen måste göras när åtgärden utförs, inte bara när modellen först granskade incidenten. Under tiden kan en annan process ha slutfört transaktionen.

Agenten bör också bara ha tillgång till ett begränsat urval av verktyg. Behörighet att hämta en transaktionsstatus är inte detsamma som behörighet att återföra en betalning eller ändra en ekonomisk post. Agenten ska inte kunna utöka sina egna befogenheter bara för att den föredragna lösningen kräver större åtkomst.

Idempotens begränsar dubbla effekter. Loggar bevarar den historik som behövs för utredning. Avstämning kontrollerar att relevanta poster stämmer överens. Ingen av dessa åtgärder visar i sig att en föreslagen åtgärd är lämplig.

Jag skulle också dokumentera vilka belägg som användes, rekommendationen, beslutet om godkännande och det faktiska resultatet. Då går det att granska ingripandet i efterhand.

Dessa kontroller bör upprätthållas av testbar programvara utanför modellen. Instruktioner om att agenten ska vara försiktig är användbar vägledning, men de är ingen mekanism för att godkänna åtgärder.

Tänk dig att ett AI-baserat övervakningssystem upptäcker ett misstänkt transaktionsfel och rekommenderar att åtgärden återförs automatiskt. Om transaktionen i själva verket genomfördes men bekräftelsen dröjde, skulle ingripandet kunna skapa ett nytt problem. Hur bör utvecklingsteam utforma AI-drivna återställningssystem så att de kan hantera osäkerhet och undvika korrigerande åtgärder som grundar sig på ofullständig information?

Systemet behöver ett verkligt tillstånd för ”utfallet är okänt”. Annars riskerar det att tolka saknad information som ett felaktigt besked om att transaktionen misslyckades.

En försenad bekräftelse är skäl att utreda, inte automatiskt skäl att återföra en transaktion. En återföring är en ny ekonomisk åtgärd med egna konsekvenser. Den kräver en självständigt fastställd grund och rätt godkännande.

Jag skulle dela upp hanteringen i två spår. Utredningsspåret kan hämta status, samla in saknade händelser, jämföra poster och meddela det ansvariga teamet. Spåret för ekonomiska åtgärder förblir spärrat tills villkoren är uppfyllda.

Detta hindrar att en AI-modells konfidenspoäng får ersätta belägg för transaktionen. En modell kan vara mycket säker på en förklaring som bygger på ofullständig information.

Det behövs också en tydligt fastställd punkt för eskalering. Att låta en transaktion stå som väntande på obestämd tid är inte ett godtagbart resultat för kunden. Någon bör ansvara för det olösta ärendet och ha tillräcklig bakgrundsinformation för att avgöra nästa säkra steg.

Återställningsprocessen bör därför kunna säga både ”Jag kan ännu inte motivera att den här transaktionen ändras” och ”Så här behöver ärendet hanteras för att lösas”.

Det är bara meningsfullt att identifiera osäkerhet om systemet också har ett praktiskt sätt att hantera den.

En av de största frågorna kring autonom AI är att avgöra när mänskligt godkännande fortfarande är avgörande. Vilka åtgärder för återställning i produktionsmiljö anser du att AI bör få utföra självständigt, och vilka bör alltid kräva mänskligt godkännande? Hur bör organisationer fastställa dessa gränser när ekonomiska transaktioner, regelefterlevnad eller kundernas förtroende står på spel?

Jag skulle dra gränsen utifrån konsekvenserna av att ha fel, snarare än utifrån om en åtgärd betecknas som ”AI”.

En rimlig utgångspunkt är enbart läsande undersökningar, förutsatt att agenten bara har tillgång till behörig information. Den kan samla in diagnostiska loggar, gruppera relaterade aviseringar och sammanställa en incidentrapport utan att få ändra den underliggande transaktionen.

Vissa fördefinierade återställningsrutiner kan också lämpa sig för automatisering, om deras villkor verifieras oberoende och effekterna är begränsade.

Jag skulle kräva mänskligt godkännande när ett föreslaget ingripande ligger utanför en godkänd rutin, när uppgifter motsäger varandra och det ekonomiska utfallet fortfarande är oklart, eller när åtgärden skulle ändra säkerhetskontroller eller agentens egna behörigheter. Det är beslut som en agent inte bör få godkänna på egen hand.

Det betyder inte att varje rutinmässig ekonomisk transaktion måste godkännas av en person. Regelstyrd hantering enligt etablerade rutiner är något annat än att låta en modell hitta på en korrigering under en incident.

Mänsklig granskning måste också vara meningsfull. En godkännandeskärm bör visa beläggen, den kvarstående osäkerheten, den förväntade effekten och de tillgängliga alternativen. Att be någon godkänna ett självsäkert formulerat stycke utan den kontexten ger ett begränsat skydd.

Dessa gränser bör fastställas före driftsättning. Ett avbrott är fel tillfälle att avgöra hur stora befogenheter ett automatiserat system bör ha.

Du har arbetat mycket med feltoleranta backend-system, verktyg för observerbarhet och integrationer mellan programvarutjänster och fysisk hårdvara. Vilka typer av telemetri och belägg från produktionsmiljön skulle en AI-agent behöva för att kunna diagnostisera en incident på ett tillförlitligt sätt? Hur kan ingenjörsteam skilja mellan användbara AI-genererade rekommendationer och trovärdiga men felaktiga slutsatser som skulle kunna förvärra ett avbrott?

Jag skulle börja med belägg som kopplar samman kundens verksamhet i de berörda systemen: transaktionsidentifierare, tjänstehändelser, bestående tillståndsändringar, enhetssvar och kommunikationsfel.

Även programvaruversioner och konfigurationsändringar spelar roll. Ett fel som börjar efter en lansering ger den som utreder en användbar ledtråd, men tidsmässigt samband bevisar inte i sig ett orsakssamband.

Agenten behöver också förstå beläggens begränsningar. Loggar kan vara ofullständiga, poster kan komma fram sent och klockor kan visa olika tider. En utebliven bekräftelse är inte detsamma som ett bevis på att ingen åtgärd utfördes.

En användbar diagnos bör skilja mellan observationer och tolkningar. ”Klienten registrerade en timeout” är en observation. ”Backend-systemet var otillgängligt” är en förklaring som kräver ytterligare stöd.

Jag skulle förvänta mig att en rekommendation pekar ut de poster som ligger till grund för den, förklarar vad som fortfarande är okänt och anger vilken ytterligare kontroll som skulle bekräfta eller motbevisa slutsatsen.

Ingenjörerna bör sedan verifiera rekommendationer med betydande konsekvenser mot originalposterna i stället för att enbart förlita sig på agentens sammanfattning. Det är särskilt viktigt när en sammanfattning komprimerar en lång eller motsägelsefull händelsehistorik.

Den standard jag skulle använda är enkel: kan en annan ingenjör följa beläggen och komma fram till en välgrundad slutsats? Om förklaringen inte klarar den prövningen är den inte redo att ligga till grund för en ändring i produktionsmiljön.

I din publicerade forskning om motståndskraft mot utpressningsprogram i lotteri- och vadslagningskiosker utvärderade du ett AI-stött säkerhetsramverk i en syntetisk miljö som simulerade 500 kiosker. Vilka var de viktigaste resultaten, och vilka begränsningar bör läsarna känna till när de tolkar resultaten? Vilken ytterligare validering skulle behövas innan den föreslagna arkitekturen tillämpas i en aktiv produktionsmiljö?

Jag ville undersöka motståndskraft utöver detektering: hur en terminalmiljö kan begränsa en attack, upptäcka den och återhämta sig, samtidigt som beläggen för vad som hänt bevaras.

Det Resilient Security Framework som utvecklades kombinerade förebyggande kontroller, AI-stödd avvikelsedetektering samt definierade mekanismer för hantering och återställning. AI-komponenten handlade om att upptäcka misstänkt beteende. Det var inte ett experiment där en språkmodellsagent självständigt fick ändra ekonomiska transaktioner.

Utvärderingen använde en syntetisk miljö som representerade 500 kiosker under en simulering på 72 timmar, med beteendemässiga emuleringar av utpressningsprogramattacker, snarare än en driftsättning på 500 fysiska terminaler.

Jämfört med studiens baslinje med enbart antivirusprogram minskade den genomsnittliga detektionstiden från 52 till 31 minuter, och den genomsnittliga återställningstiden minskade från 120 till 56 minuter.

Det här är resultaten för det kombinerade ramverket under de experimentella förhållandena. De bör inte tillskrivas enbart AI eller betraktas som prestandagarantier för en verklig driftsmiljö. Ett viktigt resultat var att tidigare upptäckt i sig inte ledde till samma förbättring av återhämtningen. Även utformningen av begränsning och återhämtning hade betydelse.

Begränsningarna är viktiga. De simulerade arbetsbelastningarna, nätverksförhållandena, angreppsbeteendena och grundläggande skyddsåtgärderna motsvarar inte alla driftsmiljöer. Olika enheter och program skulle kräva ny validering.

Innan lösningen används i produktion skulle jag vilja se tester på representativ hårdvara, en oberoende säkerhetsbedömning, utvärderingar som pågår under längre tid och noggranna mätningar av falsklarm och bearbetningsbelastning.

Jag skulle också testa återställningsprocessen mot legitim transaktionsaktivitet. Det räcker inte att återställa en fungerande programvaruavbild om processen går miste om den information som behövs för att redovisa genomförda transaktioner.

Studien ger en grund för fortsatt testning. Att visa att lösningen fungerar säkert i en verklig driftsmiljö är ett separat steg.

Din syn präglas både av många års erfarenhet av produktionsutveckling och av akademisk forskning om programvarutillförlitlighet och AI-driven säkerhet. Kan du skilja mellan de tillförlitlighetsmekanismer som du själv har implementerat eller driftsatt i verkliga produktionssystem och de metoder som du har undersökt genom forskning eller simulerade tester? Vilka AI-drivna återställningsfunktioner anser du redan är praktiskt användbara i dag, och vilka är fortfarande till stor del experimentella?

Mitt produktionsarbete har omfattat programvaruutveckling och integration, validering av transaktioner, felsökning, testning och validering inför driftsättning.

Min publicerade forskning är en separat del av mitt arbete, och varje studie måste förstås utifrån de metoder och begränsningar som anges.

Uppsatsen om utpressningsprogram utvärderar ett föreslaget säkerhetsramverk i en syntetisk testmiljö. Min uppsats om AI på kantenheter är en litteraturbaserad analys av intelligens på enheten och dess möjliga tillämpning i transaktionsterminaler. Min artikel i IEEE FeedForward undersöker en AI-assisterad tillförlitlighetsarkitektur genom kontrollerad simulering, däribland övervakning, eskalering och reservbeteende.

Ingen av de publikationerna bör tolkas som belägg för att jag har driftsatt en autonom AI-agent med befogenhet att hantera verkliga finansiella transaktioner.

För praktisk användning skulle jag prioritera stöd som ingenjörer kan granska: incidentöversikter med länkar till källdokumentation, samband mellan olika larm och förslag på diagnostiska kontroller. Nyttan måste fortfarande mätas i den miljö där lösningarna ska användas.

Den svårare utmaningen är återställning i situationer som inte går att förutse, där en modell väljer och genomför ändringar under omständigheter som inte har förutsetts. Det kräver betydligt starkare belägg än ett användbart diagnostiskt förslag.

Jag ser min erfarenhet från produktion och min forskning som kompletterande: den ena ger en grund i de driftsproblem jag känner till, medan den andra undersöker metoder som fortfarande måste visa sitt värde genom validering.

Framöver, i takt med att AI-agenter blir bättre på att upptäcka avvikelser, diagnostisera fel och samordna återställning i distribuerade system, hur tror du att förhållandet mellan autonoma system och mänskliga ingenjörer kommer att utvecklas? Vilka tekniska skyddsåtgärder, driftsrelaterade belägg och mekanismer för ansvarsutkrävande skulle behövas innan organisationer tryggt kan ge AI större befogenheter över verksamhetskritisk produktionsinfrastruktur?

Jag tror att AI kommer att ta över mer av arbetet med att sammanställa en lägesbild av incidenter. Ingenjörer skulle kunna börja med en användbar tidslinje, berörda komponenter, tänkbara förklaringar och uppgifter som saknas, i stället för att lägga så mycket tid på att samla in materialet manuellt.

Det skulle ge människor mer tid åt beslut som kräver förståelse för systemets skyldigheter och följderna av att ändra det.

Jag skulle utöka befogenheterna att genomföra åtgärder gradvis. En agent skulle först kunna köras i skuggläge och ta fram rekommendationer utan att agera på dem. Team skulle kunna jämföra rekommendationerna med granskade utfall och testa hur agenten beter sig när information saknas, är motstridig eller inaktuell.

Utvärderingen bör omfatta felaktiga ingripanden, problem som inte upptäcks, onödig eskalering och återhämtning efter agentens egna misstag. En snabb rekommendation är inte värdefull om den leder insatsteamet i fel riktning.

Större befogenheter bör också vara villkorade. En modelluppdatering eller en större systemförändring kan göra tidigare tester ogiltiga. Team behöver kunna begränsa eller återkalla agentens behörigheter när dess beteende inte längre uppfyller den standard som krävs.

Människors ansvar försvinner inte när automatiseringen förbättras. Någon måste ansvara för driftsreglerna, vilka belägg som krävs för en ändring och processen för att utreda fel.

Jag tror att ingenjörer kommer att ägna mindre tid åt att samla in information och mer tid åt att definiera, testa och upprätthålla villkoren för när automatiserade åtgärder är motiverade.

Tack för den utmärkta intervjun. Läsare som vill följa hans arbete med tillförlitlighet i distribuerade transaktioner och ansvarsfull AI-assisterad återställning kan ta kontakt med Sapan Pandya.