Sapan Pandya, senior software-engineer en senior lid van IEEE – interviewreeks

Sapan Pandya is senior software-engineer en senior lid van IEEE. Hij woont in New Jersey en heeft meer dan tien jaar ervaring met robuuste, gedistribueerde transactiesystemen. Zijn werk omvat transactie-integriteit, de integratie van software met fysieke apparaten, het oplossen van productieproblemen en het valideren van implementaties in gereguleerde omgevingen. Hij behaalde een masterdiploma in computerwetenschappen aan Stevens Institute of Technology en draagt bij aan wetenschappelijke peerreview en technisch onderzoek.

Pandya doet onderzoek naar cybersecurity voor kiosken, edge-AI en AI-ondersteunde betrouwbaarheidstechniek. Zijn ervaring met productiesystemen vormt de basis voor zijn aandacht voor bewijs, transactie-uitkomsten en operationele verantwoordelijkheid. In dit interview bespreekt hij idempotentie, tegenstrijdige transactiegegevens, onzekerheid in herstelsystemen en de maatregelen die nodig zijn voordat AI-agenten bedrijfskritieke infrastructuur kunnen aansturen. Hij maakt onderscheid tussen praktische ervaring met engineering en onderzoek op basis van literatuuranalyse en gecontroleerde of synthetische tests.

Je loopbaan draait om softwarebetrouwbaarheid en gedistribueerde transactiesystemen. Hoe heeft die ervaring je kijk op betrouwbaarheid gevormd, en welke uitdagingen hebben je perspectief op het gebruik van AI voor het beheren van complexe systemen beïnvloed?

Mijn perspectief is verschoven: ik vraag me niet langer alleen af of een component werkt, maar ook of de transactie van de klant is voltooid en verantwoord kan worden.

Eerder in mijn loopbaan richtte ik me vooral op het gedrag van applicaties: invoer valideren, reacties afhandelen en ervoor zorgen dat de interface de beoogde workflow volgde. Toen mijn verantwoordelijkheden zich uitbreidden naar systeemintegratie, het oplossen van productieproblemen en het valideren van implementaties, moest ik verder kijken dan afzonderlijke componenten.

Een service kan zijn werk afronden terwijl een andere service nog op bevestiging wacht. Software kan een bewerking als geslaagd registreren, terwijl een fysiek apparaat het verwachte resultaat niet levert. Dat elke component de tests doorstaat, bewijst op zichzelf niet dat de volledige interactie correct zal verlopen.

Door die ervaring ben ik bijzonder geïnteresseerd geraakt in de grenzen tussen systemen. Wat weet elke component? Waar gaat die van uit? Wat gebeurt er wanneer die aannames niet langer kloppen?

Die ervaring beïnvloedt ook mijn kijk op AI. Ingenieurs helpen bij het verzamelen van bewijsmateriaal, het herkennen van patronen en het sneller onderzoeken van storingen heeft echt meerwaarde. Maar een verklaring van wat er waarschijnlijk is gebeurd, is iets anders dan een geverifieerd verslag van wat er daadwerkelijk is gebeurd.

Ik wil dat AI de inspanning vermindert die nodig is om een probleem te onderzoeken, zonder de bewijsstandaard te verlagen die nodig is om het op te lossen.

Je hebt benadrukt dat technisch correcte code niet altijd tot de juiste transactie-uitkomsten leidt. Kun je een concreet voorbeeld geven van een transactie die door een time-out mislukt lijkt, maar in werkelijkheid al is voltooid? Wat kan er misgaan wanneer het systeem de bewerking automatisch opnieuw probeert, en hoe kunnen ingenieurs dubbele transacties voorkomen?

Neem een hypothetische betaling van $ 50. De applicatie verstuurt een verzoek, de betaaldienst verwerkt dit met succes en de reactie gaat verloren voordat die de applicatie bereikt.

De klant krijgt een time-outmelding, hoewel de betaling al heeft plaatsgevonden. Als de applicatie een nieuw betalingsverzoek indient, kan de klant nogmaals worden belast.

Een time-out betekent dat de reactie niet op tijd is aangekomen. Het zegt niet of de onderliggende transactie is geslaagd.

Een veelgebruikte beveiligingsmaatregel is idempotentie: hetzelfde logische verzoek kan opnieuw worden verstuurd zonder dat er een tweede financieel effect ontstaat. De applicatie behoudt bij nieuwe pogingen dezelfde bewerkings-ID en de ontvangende service herkent die als het oorspronkelijke verzoek, niet als een nieuwe aankoop.

Het gaat er niet alleen om een ID toe te voegen. De service moet die identiteit afdwingen en voldoende informatie bewaren om een voltooide bewerking te onderscheiden van een bewerking die nog bezig is. Een ID biedt geen bescherming voor een vervolgbewerking die er geen rekening mee houdt.

Als de uitkomst onzeker blijft, moet het herstelproces de bestaande transactie controleren en de relevante gegevens met elkaar in overeenstemming brengen, in plaats van meteen een vervangende transactie aan te maken.

Ik zou ook grenzen stellen aan het aantal nieuwe pogingen en vastleggen wat er gebeurt wanneer automatisch herstel de uitkomst niet kan vaststellen. De klant heeft een duidelijke statusmelding nodig dat de transactie in behandeling is, plus een manier om die af te handelen — geen herhaalde afschrijvingen of een verwerkingsscherm dat eindeloos blijft staan.

In gedistribueerde systemen kunnen een database, een backendservice en een fysieke kiosk tegenstrijdige informatie over dezelfde transactie melden. Ben je dit soort inconsistenties in productie tegengekomen, en hoe zijn ze onderzocht en opgelost? Welke rol zou AI eventueel kunnen spelen bij het met elkaar in overeenstemming brengen van deze tegenstrijdige gegevens?

Ja, het onderzoeken van inconsistenties in transactiestatussen hoorde bij mijn werk met productiesystemen. Om de redenering toe te lichten zonder een incident op het werk te bespreken, gebruik ik een hypothetisch voorbeeld.

Neem een generieke zelfbedieningskassa. De betaaldienst registreert een geslaagde aankoop, de printer meldt dat de afdrukopdracht voor de bon is geaccepteerd en vervolgens verschijnt er een foutmelding op het scherm. Die waarnemingen kunnen betrekking hebben op verschillende fasen van de interactie en bewijzen niet per se dat de aankoop in zijn geheel is mislukt.

Eerst zou ik de volgorde van gebeurtenissen reconstrueren aan de hand van het transactie-ID en de relevante gegevens van de diensten en apparaten. Vervolgens zou ik vaststellen wat elke waarneming bewijst. Dat een printer een opdracht accepteert, bewijst niet noodzakelijk dat de bon de klant heeft bereikt. Dat een verzoek is ontvangen, bewijst niet noodzakelijk dat het financiële gevolg ervan is verwerkt.

De oplossing hangt af van de fase waarin het is misgegaan. De volledige transactie opnieuw uitvoeren is mogelijk niet gepast als alleen de uitvoer aandacht nodig heeft. Als op basis van de beschikbare gegevens niet kan worden vastgesteld wat er is gebeurd, moet de betreffende handeling onder controle blijven terwijl iemand onderzoek doet.

Om herhaling te voorkomen, moet ook worden aangepakt waarom de inconsistentie kon ontstaan; alleen één registratie herstellen is niet genoeg.

AI kan helpen gebeurtenissen met elkaar in verband te brengen en ontbrekende informatie op te sporen. Ik zou het systeem vragen mogelijke verklaringen naast elkaar te zetten en voor elke verklaring het ondersteunende bewijs te tonen. Het moet helpen het onderzoek af te bakenen, niet tegenstrijdige registraties oplossen door de verklaring te kiezen die het overtuigendst klinkt.

Nu AI-agenten zich ontwikkelen van het diagnosticeren van productie-incidenten naar het aanbevelen of uitvoeren van herstelacties, welke waarborgen moeten er zijn voordat een AI-systeem een transactie opnieuw mag proberen, terugdraaien of wijzigen? Hoe kunnen deterministische maatregelen, zoals idempotentiesleutels, transactielogboeken en afstemmingsmechanismen, voorkomen dat AI extra fouten veroorzaakt?

Ik zou het voorstellen van een handeling scheiden van het goedkeuren en uitvoeren ervan.

Een AI-agent kan een nieuwe poging aanbevelen, maar een afzonderlijke controle moet bepalen of die is toegestaan. Die controle moet nagaan wat de huidige status van de transactie is, om welke handeling het gaat, welke bevoegdheden de agent heeft en onder welke voorwaarden de handeling veilig is.

Die controle moet plaatsvinden op het moment dat de handeling wordt uitgevoerd, niet alleen toen het model het incident voor het eerst onderzocht. Intussen kan een ander proces de transactie al hebben voltooid.

Ook moeten de beschikbare hulpmiddelen voor de agent beperkt zijn. Toestemming om de status van een transactie op te vragen is iets anders dan toestemming om een betaling terug te draaien of een financiële registratie te wijzigen. De agent mag zijn eigen bevoegdheden niet kunnen uitbreiden omdat de oplossing die hij verkiest meer toegang vereist.

Idempotentie beperkt dubbele effecten. Logboeken bewaren de geschiedenis die nodig is voor onderzoek. Afstemming controleert of relevante registraties met elkaar overeenkomen. Geen van deze maatregelen bepaalt op zichzelf of een voorgestelde handeling gepast is.

Ik zou ook vastleggen welk bewijs is gebruikt, welke aanbeveling is gedaan, welk besluit over de goedkeuring is genomen en wat het daadwerkelijke resultaat was. Zo kan de interventie achteraf worden beoordeeld.

Deze maatregelen moeten worden afgedwongen door software buiten het model die kan worden getest. Instructies aan een agent om voorzichtig te zijn, zijn nuttige richtlijnen, maar vormen geen mechanisme om handelingen goed te keuren.

Stel dat een AI-bewakingssysteem een vermeende mislukte transactie detecteert en aanbeveelt de handeling automatisch terug te draaien. Als de transactie in werkelijkheid is geslaagd, maar de bevestiging vertraging heeft opgelopen, kan die interventie een nieuw probleem veroorzaken. Hoe kunnen engineeringteams AI-gestuurde herstelsystemen zo ontwerpen dat ze onzekerheid herkennen en geen corrigerende handelingen uitvoeren op basis van onvolledige informatie?

Het systeem moet een echte status ‘uitkomst onbekend’ hebben. Anders zal het ontbrekende informatie waarschijnlijk ten onrechte als bewijs zien dat de transactie is mislukt.

Een vertraagde bevestiging is reden om onderzoek te doen, niet om automatisch een transactie terug te draaien. Een terugboeking is een nieuwe financiële handeling met eigen gevolgen. Daarvoor moet een afzonderlijke, onderbouwde reden bestaan en de juiste toestemming zijn verleend.

Ik zou de reactie opsplitsen in twee trajecten. In het onderzoekstraject kunnen de status worden opgevraagd, ontbrekende gebeurtenissen worden verzameld, registraties worden vergeleken en het verantwoordelijke team worden geïnformeerd. Het traject voor financiële handelingen blijft geblokkeerd totdat aan de voorwaarden is voldaan.

Zo wordt voorkomen dat een AI-betrouwbaarheidsscore in de plaats komt van bewijs over de transactie. Een model kan veel vertrouwen hebben in een verklaring die op onvolledige informatie berust.

Er moet ook een duidelijk escalatiemoment zijn. Een transactie voor onbepaalde tijd in behandeling laten, is geen bevredigende uitkomst voor de klant. Iemand moet verantwoordelijk zijn voor de onopgeloste zaak en voldoende context hebben om de volgende veilige stap te bepalen.

Het herstelproces moet daarom zowel kunnen zeggen: ‘Ik kan nog niet onderbouwen dat deze transactie moet worden gewijzigd’ als: ‘Dit moet er gebeuren om de zaak op te lossen’.

Onzekerheid herkennen is alleen nuttig als het systeem daar op een praktische manier mee kan omgaan.

Een van de belangrijkste vragen rond autonome AI is wanneer menselijke goedkeuring noodzakelijk blijft. Welke herstelacties in productie zou AI volgens u zelfstandig mogen uitvoeren, en voor welke acties zou altijd menselijke toestemming nodig moeten zijn? Hoe moeten organisaties deze grenzen vaststellen wanneer financiële transacties, naleving van regelgeving of het vertrouwen van klanten op het spel staan?

Ik zou de grens bepalen aan de hand van de gevolgen van een fout, en niet aan de hand van de vraag of een handeling als ‘AI’ wordt bestempeld.

Een onderzoek waarbij alleen gegevens worden ingezien, is een redelijk uitgangspunt, mits de agent uitsluitend toegang heeft tot geautoriseerde informatie. De agent kan diagnostische gegevens verzamelen, gerelateerde waarschuwingen groeperen en een incidentoverzicht opstellen, zonder de onderliggende transactie te mogen wijzigen.

Ook sommige vooraf vastgelegde herstelprocedures kunnen geschikt zijn voor automatisering, wanneer de voorwaarden ervan onafhankelijk worden gecontroleerd en de gevolgen beperkt zijn.

Ik zou menselijke toestemming vereisen wanneer een voorgestelde ingreep buiten een goedgekeurde procedure valt, wanneer gegevens elkaar tegenspreken en de financiële uitkomst onduidelijk blijft, of wanneer de handeling beveiligingsmaatregelen of de eigen bevoegdheden van de agent zou wijzigen. Dat zijn beslissingen waarvoor een agent zichzelf geen toestemming mag geven.

Dat betekent niet dat voor elke routinematige financiële handeling een mens goedkeuring moet geven. Verwerking volgens vastgestelde regels is iets anders dan een model tijdens een incident zelf een correctie laten bedenken.

Ook moet menselijke beoordeling inhoudelijk betekenisvol zijn. Een goedkeuringsscherm moet het onderliggende bewijs, de resterende onzekerheid, het verwachte effect en de beschikbare alternatieven tonen. Iemand zonder die context vragen om een overtuigend geformuleerde alinea goed te keuren, biedt weinig extra bescherming.

Deze grenzen moeten vóór de ingebruikname worden afgesproken. Tijdens een storing is het niet het juiste moment om te bepalen hoeveel bevoegdheid een geautomatiseerd systeem zou moeten hebben.

U hebt veel gewerkt aan fouttolerante backendsystemen, observability-tools en integraties tussen softwarediensten en fysieke hardware. Welke telemetriegegevens en welk bewijs uit productie heeft een AI-agent nodig om een incident betrouwbaar te diagnosticeren? Hoe kunnen engineeringteams onderscheid maken tussen nuttige, door AI gegenereerde aanbevelingen en aannemelijke maar onjuiste conclusies die een storing kunnen verergeren?

Ik zou beginnen met bewijs dat de werkzaamheden van de klant in de betrokken systemen met elkaar verbindt: transactie-ID’s, servicegebeurtenissen, blijvende statuswijzigingen, reacties van apparaten en communicatiestoringen.

Ook softwareversies en configuratiewijzigingen zijn van belang. Als een storing begint na een release, biedt dat onderzoekers een bruikbare aanwijzing, maar alleen de timing bewijst geen oorzakelijk verband.

De agent moet ook inzicht hebben in de beperkingen van het bewijs. Logbestanden kunnen onvolledig zijn, gegevens kunnen vertraagd binnenkomen en klokken kunnen van elkaar afwijken. Het ontbreken van een bevestiging is niet hetzelfde als bewijs dat er geen handeling heeft plaatsgevonden.

Een bruikbare diagnose moet waarnemingen scheiden van interpretaties. ‘De client heeft een time-out geregistreerd’ is een waarneming. ‘De backend was niet beschikbaar’ is een verklaring waarvoor aanvullend bewijs nodig is.

Ik verwacht dat een aanbeveling verwijst naar de onderliggende gegevens, uitlegt wat nog onbekend is en aangeeft welke aanvullende controle de conclusie zou bevestigen of weerleggen.

Vervolgens moeten engineers aanbevelingen met belangrijke gevolgen controleren aan de hand van de oorspronkelijke gegevens, in plaats van uitsluitend op de samenvatting van de agent te vertrouwen. Dat is vooral belangrijk wanneer een samenvatting een lange of tegenstrijdige gebeurtenisgeschiedenis sterk inkort.

De norm die ik zou hanteren is eenvoudig: kan een andere engineer het bewijs volgen en tot een verdedigbare conclusie komen? Als de uitleg die toets niet doorstaat, is deze nog niet geschikt om een wijziging in productie aan te sturen.

In uw gepubliceerde onderzoek naar de weerbaarheid tegen ransomware van loterij- en wedkiosken hebt u een AI-ondersteund beveiligingsraamwerk geëvalueerd in een synthetische omgeving waarin 500 kiosken werden gesimuleerd. Wat waren de belangrijkste bevindingen, en welke beperkingen moeten lezers in gedachten houden bij het interpreteren van deze resultaten? Welke aanvullende validatie zou nodig zijn voordat de voorgestelde architectuur in een live productieomgeving wordt toegepast?

Ik wilde de weerbaarheid breder onderzoeken dan alleen detectie: hoe een terminalomgeving een aanval kan beperken, deze kan herkennen en ervan kan herstellen, met behoud van bewijs van wat er is gebeurd.

Het daaruit voortgekomen Resilient Security Framework combineerde preventieve maatregelen, AI-ondersteunde anomaliedetectie en vastgelegde mechanismen voor respons en herstel. Het AI-onderdeel was gericht op het detecteren van verdacht gedrag. Dit was geen experiment waarbij een agent op basis van een taalmodel zelfstandig financiële transacties mocht aanpassen.

Bij de evaluatie werd een synthetische omgeving gebruikt die 500 kiosken gedurende een simulatie van 72 uur vertegenwoordigde, met gedragsmatige nabootsingen van ransomware-aanvallen. Er vond dus geen implementatie plaats op 500 fysieke terminals.

Vergeleken met de antivirusbaseline van het onderzoek daalde de gemiddelde detectietijd van 52 naar 31 minuten en de gemiddelde hersteltijd van 120 naar 56 minuten.

Dat zijn resultaten voor het gecombineerde raamwerk onder de experimentele omstandigheden. Ze mogen niet uitsluitend aan AI worden toegeschreven en evenmin worden beschouwd als prestatiegaranties voor een operationele omgeving. Een belangrijke bevinding was dat eerdere detectie op zichzelf niet tot dezelfde verbetering van het herstel leidde. Ook het ontwerp van de indamming en het herstel speelde een rol.

De beperkingen zijn belangrijk. De gesimuleerde workloads, netwerkomstandigheden, aanvalspatronen en basisbeveiligingen vertegenwoordigen niet elke operationele omgeving. Voor andere apparaten en toepassingen is nieuwe validatie nodig.

Voordat ik dit in productie zou gebruiken, zou ik tests op representatieve hardware, een onafhankelijke beveiligingsbeoordeling, evaluaties over langere perioden en een zorgvuldige meting van foutieve alarmen en verwerkingskosten willen zien.

Ik zou het herstelproces ook testen met legitieme transacties. Het herstellen van een werkende software-image is niet voldoende als daarbij informatie verloren gaat die nodig is om voltooide transacties te verantwoorden.

De studie biedt een basis voor verder onderzoek. Aantonen dat het systeem zich veilig gedraagt in een echte operationele omgeving is een afzonderlijke stap.

Uw perspectief combineert jarenlange ervaring met softwareontwikkeling voor productieomgevingen met academisch onderzoek naar softwarebetrouwbaarheid en door AI aangestuurde beveiliging. Kunt u onderscheid maken tussen de betrouwbaarheidsmechanismen die u persoonlijk hebt geïmplementeerd of beheerd in actieve productiesystemen en de benaderingen die u via onderzoek of gesimuleerde tests hebt verkend? Welke mogelijkheden voor door AI aangestuurd herstel zijn volgens u nu al praktisch toepasbaar, en welke zijn grotendeels nog experimenteel?

Mijn werk in productieomgevingen omvatte softwareontwikkeling en -integratie, transactievalidatie, probleemoplossing, testen en validatie van releases.

Mijn gepubliceerde onderzoek is een afzonderlijk onderdeel van mijn werk. Elke studie moet worden beoordeeld op basis van de beschreven methoden en beperkingen.

Het artikel over ransomware beoordeelt een voorgesteld beveiligingsraamwerk in een synthetische testomgeving. Mijn artikel over edge-AI is een literatuurstudie naar intelligentie op apparaten en de mogelijke toepassing daarvan in betaalterminals. Mijn artikel voor IEEE FeedForward onderzoekt een door AI ondersteunde betrouwbaarheidsarchitectuur aan de hand van gecontroleerde simulaties, waaronder bewaking, escalatie en terugvalgedrag.

Geen van die publicaties mag worden opgevat als bewijs dat ik een autonome AI-agent heb ingezet die bevoegd is om live financiële transacties uit te voeren.

Voor praktisch gebruik zou ik voorrang geven aan ondersteuning die engineers kunnen controleren: incidentoverzichten die gekoppeld zijn aan brongegevens, verbanden tussen waarschuwingen en voorgestelde diagnostische controles. De bruikbaarheid daarvan moet nog wel worden gemeten in de omgeving waarin ze worden ingezet.

De moeilijkere uitdaging is herstel bij onvoorziene situaties, waarbij een model onder niet eerder verwachte omstandigheden wijzigingen kiest en uitvoert. Daarvoor is veel sterker bewijs nodig dan voor een nuttige diagnostische suggestie.

Ik zie mijn productie-ervaring en onderzoek als complementair: het ene vormt de basis voor mijn inzicht in operationele problemen, terwijl het andere benaderingen verkent die hun waarde nog door validatie moeten bewijzen.

Hoe ziet u, met het oog op de toekomst en naarmate AI-agenten beter worden in het detecteren van afwijkingen, het diagnosticeren van storingen en het coördineren van herstel in gedistribueerde systemen, de verhouding tussen autonome systemen en menselijke engineers veranderen? Welke technische waarborgen, operationele bewijzen en verantwoordingsmechanismen zijn nodig voordat organisaties AI met vertrouwen meer bevoegdheden kunnen geven over bedrijfskritieke productie-infrastructuur?

Ik verwacht dat AI een groter deel van het werk op zich neemt dat nodig is om een beeld van een incident samen te stellen. Engineers zouden kunnen beginnen met een bruikbare tijdlijn, de getroffen componenten, mogelijke verklaringen en ontbrekend bewijsmateriaal, in plaats van zoveel tijd te besteden aan het handmatig verzamelen van die informatie.

Daardoor zouden mensen meer tijd hebben voor beslissingen die inzicht vereisen in de verplichtingen van het systeem en de gevolgen van wijzigingen.

Ik zou de bevoegdheid om handelingen uit te voeren stapsgewijs uitbreiden. Een agent zou eerst in de schaduwmodus kunnen werken en aanbevelingen doen zonder ernaar te handelen. Teams zouden die aanbevelingen kunnen vergelijken met beoordeelde uitkomsten en kunnen testen hoe de agent reageert wanneer informatie ontbreekt, tegenstrijdig of verouderd is.

Bij de evaluatie moet worden gekeken naar onjuiste ingrepen, gemiste problemen, onnodige escalaties en herstel na fouten van de agent zelf. Een snelle aanbeveling is niet waardevol als die het responsteam de verkeerde kant op stuurt.

Meer bevoegdheden moeten bovendien voorwaardelijk blijven. Een modelupdate of ingrijpende systeemwijziging kan eerdere testresultaten ongeldig maken. Teams moeten de bevoegdheden van de agent kunnen beperken of intrekken wanneer zijn gedrag niet langer aan de vereiste norm voldoet.

Menselijke verantwoordelijkheid verdwijnt niet naarmate de automatisering toeneemt. Iemand moet verantwoordelijk zijn voor de operationele regels, het bewijs dat voor een wijziging vereist is en het proces voor het onderzoeken van storingen.

Ik verwacht dat engineers minder tijd besteden aan het verzamelen van informatie en meer aan het vaststellen, testen en onderhouden van de voorwaarden waaronder geautomatiseerd handelen gerechtvaardigd is.

Bedankt voor het geweldige interview. Lezers die zijn werk op het gebied van de betrouwbaarheid van gedistribueerde transacties en verantwoord herstel met behulp van AI willen volgen, kunnen contact opnemen met Sapan Pandya.