Sapan Pandya, Senior Software Engineer und IEEE Senior Member – Interviewreihe

Sapan Pandya ist Senior Software Engineer und IEEE Senior Member. Er lebt in New Jersey und verfügt über mehr als zehn Jahre Erfahrung mit ausfallsicheren verteilten Transaktionssystemen. Seine Arbeit umfasst die Integrität von Transaktionen, die Integration von Software und physischen Geräten, die Fehlersuche im Produktivbetrieb sowie die Validierung von Bereitstellungen in regulierten Umgebungen. Er hat einen Masterabschluss in Informatik vom Stevens Institute of Technology und wirkt an wissenschaftlichen Begutachtungen und technischer Forschung mit.

Pandyas Forschung befasst sich mit der Cybersicherheit von Kiosksystemen, Edge-KI und KI-gestützter Zuverlässigkeitstechnik. Seine Erfahrung im Produktivbetrieb prägt zugleich seinen Fokus auf belastbare Nachweise, Transaktionsergebnisse und operative Verantwortlichkeit. In diesem Interview spricht er über Idempotenz, widersprüchliche Transaktionsaufzeichnungen, Unsicherheiten in Wiederherstellungssystemen und die Kontrollen, die erforderlich sind, bevor KI-Agenten auf geschäftskritische Infrastruktur zugreifen können. Dabei unterscheidet er zwischen praktischer Ingenieurserfahrung und Forschung auf Grundlage von Literaturanalysen sowie kontrollierten oder synthetischen Tests.

Ihre berufliche Laufbahn war auf Softwarezuverlässigkeit und verteilte Transaktionssysteme ausgerichtet. Wie hat diese Erfahrung Ihr Verständnis von Zuverlässigkeit geprägt, und welche Herausforderungen haben Ihre Sicht auf den Einsatz von KI zur Steuerung komplexer Systeme beeinflusst?

Meine Perspektive hat sich verändert: Statt zu fragen, ob eine Komponente funktioniert, frage ich heute, ob die Transaktion des Kunden vollständig abgeschlossen ist und sich nachvollziehbar verbuchen lässt.

Zu Beginn meiner Laufbahn konzentrierte ich mich vor allem auf das Verhalten von Anwendungen: Eingaben zu validieren, Antworten zu verarbeiten und sicherzustellen, dass die Benutzeroberfläche dem vorgesehenen Ablauf folgte. Als ich zunehmend Verantwortung für die Systemintegration, die Fehlersuche im Produktivbetrieb und die Validierung von Bereitstellungen übernahm, musste ich über einzelne Komponenten hinausblicken.

Ein Dienst kann seine Arbeit abschließen, während ein anderer noch auf eine Bestätigung wartet. Eine Software kann einen Vorgang als erfolgreich verbuchen, obwohl ein physisches Gerät das erwartete Ergebnis nicht liefert. Dass jede einzelne Komponente die Tests besteht, belegt für sich genommen nicht, dass das Zusammenspiel aller Komponenten korrekt funktioniert.

Diese Erfahrung hat mein besonderes Interesse an den Schnittstellen zwischen Systemen geweckt. Was weiß jede Komponente? Was setzt sie voraus? Was geschieht, wenn diese Voraussetzungen nicht mehr erfüllt sind?

Sie prägt auch meine Sicht auf KI. Es ist durchaus sinnvoll, Ingenieure dabei zu unterstützen, Belege zusammenzutragen, Muster zu erkennen und Fehler schneller zu untersuchen. Eine Erklärung dafür, was wahrscheinlich geschehen ist, ist jedoch etwas anderes als ein verifizierter Nachweis dessen, was tatsächlich geschehen ist.

Ich möchte, dass KI den Aufwand für die Untersuchung eines Problems verringert, ohne die Anforderungen an die Belege zu senken, die für dessen Behebung nötig sind.

Sie haben betont, dass technisch korrekter Code nicht immer korrekte Transaktionsergebnisse garantiert. Können Sie uns anhand eines konkreten Beispiels erläutern, wie eine Transaktion wegen einer Zeitüberschreitung fehlgeschlagen zu sein scheint, obwohl sie tatsächlich abgeschlossen wurde? Was kann schiefgehen, wenn das System den Vorgang automatisch erneut ausführt, und wie sollten Entwickler doppelte Transaktionen verhindern?

Nehmen wir eine hypothetische Zahlung über 50 $. Die Anwendung sendet eine Anfrage, der Zahlungsdienst verbucht sie erfolgreich, doch die Antwort geht verloren, bevor sie die Anwendung erreicht.

Der Kunde sieht eine Zeitüberschreitung, obwohl die Zahlung bereits erfolgt ist. Sendet die Anwendung eine neue Zahlungsanfrage, wird dem Kunden möglicherweise ein zweites Mal Geld abgebucht.

Eine Zeitüberschreitung sagt lediglich aus, dass die Antwort nicht rechtzeitig eingetroffen ist. Sie sagt nicht aus, ob die zugrunde liegende Transaktion erfolgreich war.

Eine gängige Schutzmaßnahme ist Idempotenz: Dieselbe logische Anfrage kann wiederholt werden, ohne eine weitere finanzielle Wirkung auszulösen. Die Anwendung behält bei erneuten Versuchen dieselbe Vorgangskennung bei, und der empfangende Dienst erkennt die Anfrage als ursprüngliche Anfrage und nicht als neuen Kauf.

Entscheidend ist nicht, einfach nur eine Kennung hinzuzufügen. Der Dienst muss diese Identität durchsetzen und genügend Informationen speichern, um einen abgeschlossenen von einem noch laufenden Vorgang unterscheiden zu können. Eine Kennung schützt nicht vor einer nachgelagerten Aktion, die sie ignoriert.

Bleibt das Ergebnis ungewiss, sollte der Wiederherstellungsprozess die bestehende Transaktion prüfen und die relevanten Einträge abgleichen, statt sofort einen Ersatzvorgang anzulegen.

Außerdem würde ich die Anzahl der Wiederholungsversuche begrenzen und festlegen, was geschieht, wenn sich das Ergebnis durch eine automatische Wiederherstellung nicht feststellen lässt. Der Kunde braucht einen eindeutigen Status wie „Ausstehend“ und einen Weg zur Klärung – keine wiederholten Abbuchungen und keinen endlosen Ladebildschirm.

In verteilten Systemen können eine Datenbank, ein Backend-Dienst und ein physischer Kiosk widersprüchliche Angaben zu derselben Transaktion liefern. Sind Sie in der Produktion schon auf solche Inkonsistenzen gestoßen, und wie wurden sie untersucht und behoben? Welche Rolle könnte KI gegebenenfalls beim Abgleich dieser widersprüchlichen Einträge spielen?

Ja, die Untersuchung von Inkonsistenzen beim Transaktionsstatus gehörte zu meiner Arbeit im Produktivbetrieb. Um die Vorgehensweise zu erläutern, ohne einen Vorfall am Arbeitsplatz zu besprechen, verwende ich ein hypothetisches Beispiel.

Betrachten wir eine gewöhnliche Selbstbedienungskasse. Der Zahlungsdienst verbucht einen erfolgreichen Kauf, der Drucker meldet, dass er den Druckauftrag für den Beleg angenommen hat, und anschließend erscheint auf dem Bildschirm eine Fehlermeldung. Diese Beobachtungen können verschiedene Phasen des Vorgangs beschreiben, ohne zu belegen, dass der gesamte Kauf fehlgeschlagen ist.

Zunächst würde ich anhand der Transaktionskennung sowie der relevanten Dienst- und Gerätedaten den Ablauf rekonstruieren. Anschließend würde ich ermitteln, was sich aus den einzelnen Beobachtungen tatsächlich ableiten lässt. Dass ein Drucker einen Auftrag angenommen hat, belegt nicht zwangsläufig, dass der Beleg beim Kunden angekommen ist. Dass eine Anfrage eingegangen ist, bedeutet nicht zwangsläufig, dass ihre finanzielle Wirkung verbucht wurde.

Wie der Vorfall zu beheben ist, hängt davon ab, in welcher Phase der Fehler aufgetreten ist. Die gesamte Transaktion zu wiederholen, könnte unangemessen sein, wenn lediglich die Ausgabe Aufmerksamkeit erfordert. Lässt sich anhand der verfügbaren Informationen nicht feststellen, was geschehen ist, sollte der betroffene Vorgang kontrolliert bleiben, während jemand den Sachverhalt untersucht.

Eine nachhaltige Korrektur muss auch der Frage nachgehen, warum die Inkonsistenz überhaupt möglich war, statt lediglich einen einzelnen Datensatz zu berichtigen.

KI könnte dabei helfen, Ereignisse miteinander zu verknüpfen und fehlende Informationen zu erkennen. Ich würde sie bitten, verschiedene mögliche Erklärungen und die Belege für jede davon aufzuzeigen. Sie sollte die Untersuchung eingrenzen helfen, widersprüchliche Datensätze aber nicht auflösen, indem sie einfach die überzeugendste Erklärung auswählt.

Wenn sich KI-Agenten von der Diagnose von Vorfällen im Produktivbetrieb dahin gehend weiterentwickeln, Wiederherstellungsmaßnahmen zu empfehlen oder auszuführen: Welche Schutzvorkehrungen sollten getroffen werden, bevor ein KI-System eine Transaktion wiederholen, rückgängig machen oder ändern darf? Wie können deterministische Kontrollen wie Idempotenzschlüssel, Transaktionsprotokolle und Abstimmungsmechanismen verhindern, dass KI zusätzliche Fehler verursacht?

Ich würde die Empfehlung einer Maßnahme klar von ihrer Genehmigung und Ausführung trennen.

Ein KI-Agent könnte eine Wiederholung empfehlen, doch eine separate Kontrolle sollte darüber entscheiden, ob diese zulässig ist. Sie sollte den aktuellen Status der Transaktion, die Identität des Vorgangs, die Berechtigungen des Agenten und die Bedingungen prüfen, unter denen die Maßnahme sicher ist.

Diese Prüfung muss zum Zeitpunkt der Ausführung der Maßnahme stattfinden und darf nicht nur erfolgen, wenn das Modell den Vorfall erstmals untersucht. In der Zwischenzeit könnte ein anderer Prozess die Transaktion bereits abgeschlossen haben.

Auch die dem Agenten verfügbaren Werkzeuge sollten eng begrenzt sein. Eine Transaktion abfragen zu dürfen, ist nicht dasselbe wie eine Zahlung rückgängig zu machen oder einen Finanzdatensatz zu ändern. Der Agent sollte seine eigenen Befugnisse nicht ausweiten können, nur weil seine bevorzugte Lösung weitergehenden Zugriff erfordert.

Idempotenz begrenzt doppelte Auswirkungen. Protokolle bewahren den Verlauf, der für eine Untersuchung benötigt wird. Ein Abgleich prüft, ob die relevanten Datensätze übereinstimmen. Keine dieser Maßnahmen belegt für sich genommen, dass eine vorgeschlagene Maßnahme angemessen ist.

Außerdem würde ich die verwendeten Belege, die Empfehlung, die Genehmigungsentscheidung und das tatsächliche Ergebnis protokollieren. So lässt sich der Eingriff im Nachhinein überprüfen.

Diese Kontrollen sollten durch testbare Software außerhalb des Modells durchgesetzt werden. Anweisungen, die einen Agenten zu sorgfältigem Vorgehen auffordern, sind zwar hilfreiche Leitlinien, ersetzen aber keinen Genehmigungsmechanismus.

Angenommen, ein KI-Überwachungssystem erkennt einen mutmaßlichen Transaktionsfehler und empfiehlt, den Vorgang automatisch rückgängig zu machen. Wurde die Transaktion tatsächlich erfolgreich abgeschlossen, aber die Bestätigung verspätet übermittelt, könnte dieser Eingriff ein neues Problem verursachen. Wie sollten Entwicklungsteams KI-gestützte Wiederherstellungssysteme so konzipieren, dass sie Unsicherheit erkennen und keine Korrekturmaßnahmen auf Grundlage unvollständiger Informationen ergreifen?

Das System braucht einen echten Status „Ausgang unbekannt“. Andernfalls läuft es Gefahr, fehlende Informationen fälschlich als Beleg für einen Fehlschlag zu werten.

Eine verspätete Bestätigung ist ein Grund für eine Untersuchung, nicht automatisch ein Grund, eine Transaktion rückgängig zu machen. Eine Rückbuchung ist ein weiterer finanzieller Vorgang mit eigenen Folgen. Sie erfordert eine unabhängig festgestellte Begründung und die entsprechende Genehmigung.

Ich würde die Reaktion in zwei Abläufe unterteilen. Im Untersuchungsablauf können der Status abgefragt, fehlende Ereignisse erfasst, Datensätze verglichen und das zuständige Team benachrichtigt werden. Der Ablauf für finanzielle Maßnahmen bleibt gesperrt, bis die dafür geltenden Bedingungen erfüllt sind.

So wird verhindert, dass ein KI-Konfidenzwert an die Stelle von Transaktionsbelegen tritt. Ein Modell kann von einer Erklärung sehr überzeugt sein, obwohl diese auf unvollständigen Informationen beruht.

Außerdem muss ein klar definierter Eskalationspunkt vorgesehen sein. Eine Transaktion auf unbestimmte Zeit offen zu halten, ist für den Kunden keine zufriedenstellende Lösung. Jemand sollte für den ungeklärten Fall verantwortlich sein und über genügend Kontext verfügen, um den nächsten sicheren Schritt festzulegen.

Der Wiederherstellungsprozess sollte daher sowohl sagen können: „Ich kann eine Änderung an dieser Transaktion noch nicht rechtfertigen“ als auch: „Das muss geschehen, um den Fall zu klären.“

Unsicherheit zu erkennen, ist nur dann hilfreich, wenn das System auch praktisch mit ihr umgehen kann.

Eine der größten Fragen im Zusammenhang mit autonomer KI ist, wann die Zustimmung eines Menschen weiterhin unerlässlich ist. Welche Maßnahmen zur Wiederherstellung des Produktionsbetriebs sollte KI Ihrer Meinung nach eigenständig ausführen dürfen, und für welche sollte stets eine menschliche Genehmigung erforderlich sein? Wie sollten Unternehmen diese Grenzen festlegen, wenn Finanztransaktionen, die Einhaltung gesetzlicher Vorschriften oder das Vertrauen der Kunden auf dem Spiel stehen?

Ich würde die Grenze danach ziehen, welche Folgen ein Fehler hätte, und nicht danach, ob eine Maßnahme als „KI“ bezeichnet wird.

Eine Untersuchung mit ausschließlich lesendem Zugriff ist ein sinnvoller Ausgangspunkt, sofern der Agent nur auf autorisierte Informationen zugreifen kann. Er kann Diagnoseprotokolle sammeln, zusammengehörige Warnmeldungen gruppieren und eine Zusammenfassung des Vorfalls erstellen, ohne die zugrunde liegende Transaktion ändern zu dürfen.

Auch einige vordefinierte Wiederherstellungsverfahren können sich für die Automatisierung eignen, wenn ihre Bedingungen unabhängig überprüft werden und ihre Auswirkungen begrenzt sind.

Ich würde eine menschliche Genehmigung verlangen, wenn ein vorgeschlagener Eingriff außerhalb eines genehmigten Verfahrens liegt, wenn sich widersprechende Aufzeichnungen vorliegen und das finanzielle Ergebnis ungeklärt bleibt oder wenn die Maßnahme Sicherheitskontrollen oder die Berechtigungen des Agenten selbst verändern würde. Solche Entscheidungen sollte ein Agent nicht selbst genehmigen dürfen.

Das bedeutet nicht, dass jede routinemäßige Finanztransaktion von einer Person genehmigt werden muss. Eine regelbasierte Verarbeitung nach etablierten Vorgaben ist etwas anderes, als einem Modell zu erlauben, während eines Vorfalls eigenständig eine Korrektur zu erfinden.

Auch eine menschliche Prüfung muss sinnvoll sein. Auf einem Genehmigungsbildschirm sollten die zugrunde liegenden Belege, die verbleibende Unsicherheit, die erwarteten Auswirkungen und die verfügbaren Alternativen angezeigt werden. Jemanden ohne diesen Kontext um die Genehmigung eines selbstsicher formulierten Absatzes zu bitten, bietet kaum zusätzlichen Schutz.

Diese Grenzen sollten vor der Einführung vereinbart werden. Ein Ausfall ist der falsche Zeitpunkt, um darüber zu entscheiden, wie viel Befugnis ein automatisiertes System haben sollte.

Sie haben umfangreiche Erfahrung mit fehlertoleranten Backend-Systemen, Werkzeugen für die Beobachtbarkeit und Integrationen zwischen Softwarediensten und physischer Hardware. Welche Telemetriedaten und Belege aus dem Produktionsbetrieb bräuchte ein KI-Agent, um einen Vorfall zuverlässig zu diagnostizieren? Wie können Entwicklungsteams hilfreiche, von KI erzeugte Empfehlungen von plausibel klingenden, aber falschen Schlussfolgerungen unterscheiden, die einen Ausfall verschlimmern könnten?

Ich würde mit Belegen beginnen, die den Ablauf des Kundenvorgangs über die beteiligten Systeme hinweg nachvollziehbar machen: Transaktionskennungen, Dienstereignisse, dauerhafte Zustandsänderungen, Gerätereaktionen und Kommunikationsfehler.

Auch Softwareversionen und Konfigurationsänderungen sind wichtig. Beginnt ein Fehler nach einer Veröffentlichung, ist das ein nützlicher Hinweis für die Untersuchung; der zeitliche Zusammenhang allein beweist jedoch keine Ursache.

Der Agent muss außerdem die Grenzen der Beweislage kennen. Protokolle können unvollständig sein, Aufzeichnungen verspätet eintreffen und Uhren voneinander abweichen. Eine fehlende Bestätigung beweist nicht, dass kein Vorgang stattgefunden hat.

Eine hilfreiche Diagnose sollte Beobachtungen von Interpretationen trennen. „Der Client hat eine Zeitüberschreitung protokolliert“ ist eine Beobachtung. „Das Backend war nicht verfügbar“ ist eine Erklärung, die weiterer Belege bedarf.

Eine Empfehlung sollte meiner Meinung nach die zugrunde liegenden Aufzeichnungen benennen, erläutern, was weiterhin unbekannt ist, und angeben, welche zusätzliche Prüfung ihre Schlussfolgerung bestätigen oder widerlegen würde.

Anschließend sollten Ingenieure folgenreiche Empfehlungen anhand der Originalaufzeichnungen überprüfen, statt sich allein auf die Zusammenfassung des Agenten zu verlassen. Das ist besonders wichtig, wenn eine Zusammenfassung eine lange oder widersprüchliche Ereignisgeschichte stark verkürzt.

Der Maßstab, den ich anlegen würde, ist einfach: Kann ein anderer Ingenieur den Belegen folgen und zu einer vertretbaren Schlussfolgerung gelangen? Hält die Erklärung dieser Prüfung nicht stand, sollte sie noch keine Änderung im Produktionsbetrieb auslösen.

In Ihrer veröffentlichten Forschung zur Widerstandsfähigkeit von Lotterie- und Wettterminals gegen Ransomware haben Sie ein KI-gestütztes Sicherheitskonzept in einer synthetischen Umgebung bewertet, die 500 Terminals simulierte. Was waren die wichtigsten Ergebnisse, und welche Einschränkungen sollten Leser bei ihrer Interpretation berücksichtigen? Welche zusätzlichen Validierungen wären nötig, bevor die vorgeschlagene Architektur in einer aktiven Produktionsumgebung eingesetzt werden könnte?

Ich wollte die Widerstandsfähigkeit über die Erkennung hinaus untersuchen: Wie sich eine Terminalumgebung gegen einen Angriff abschirmen, ihn erkennen und sich davon erholen könnte, während die Belege für den Vorfall erhalten bleiben.

Das daraus hervorgegangene Resilient Security Framework vereinte präventive Kontrollen, KI-gestützte Anomalieerkennung sowie klar definierte Reaktions- und Wiederherstellungsmechanismen. Die KI-Komponente diente der Erkennung verdächtigen Verhaltens. Es handelte sich nicht um ein Experiment, bei dem ein Sprachmodell-Agent eigenständig Finanztransaktionen ändern durfte.

Für die Evaluierung kam eine synthetische Umgebung zum Einsatz, die 500 Terminals über einen Simulationszeitraum von 72 Stunden abbildete. Dabei wurden Ransomware-Angriffe im Verhalten nachgeahmt; die Lösung wurde nicht auf 500 physischen Terminals eingeführt.

Im Vergleich zur ausschließlich auf Antivirensoftware gestützten Basislinie der Studie sank die mittlere Erkennungszeit von 52 auf 31 Minuten und die mittlere Wiederherstellungszeit von 120 auf 56 Minuten.

Das sind Ergebnisse des kombinierten Frameworks unter den Versuchsbedingungen. Sie sollten weder allein der KI zugeschrieben noch als Leistungsgarantie für den Einsatz in einer realen Umgebung verstanden werden. Eine wichtige Erkenntnis war, dass eine frühere Erkennung für sich genommen nicht dieselbe Verbesserung bei der Wiederherstellung bewirkte. Auch die Gestaltung von Eindämmung und Wiederherstellung spielte eine Rolle.

Die Einschränkungen sind wichtig. Die simulierten Arbeitslasten, Netzwerkbedingungen, Angriffsverhaltensweisen und Basismaßnahmen zur Abwehr bilden nicht jede Betriebsumgebung ab. Für andere Geräte und Anwendungen wären neue Validierungen erforderlich.

Vor einem Einsatz in der Produktion würde ich Tests auf repräsentativer Hardware, eine unabhängige Sicherheitsbewertung, längerfristige Untersuchungen sowie eine sorgfältige Messung von Fehlalarmen und Verarbeitungsaufwand verlangen.

Außerdem würde ich den Wiederherstellungsprozess anhand legitimer Transaktionsaktivitäten testen. Ein funktionsfähiges Software-Image wiederherzustellen, reicht nicht aus, wenn dabei Informationen verloren gehen, die zur Erfassung abgeschlossener Transaktionen benötigt werden.

Die Studie bildet eine Grundlage für weitere Tests. Nachzuweisen, dass sich das System in einer realen Betriebsumgebung sicher verhält, ist ein separater Schritt.

Ihre Perspektive vereint langjährige Erfahrung in der Produktionsentwicklung mit akademischer Forschung zu Softwarezuverlässigkeit und KI-gestützter Sicherheit. Können Sie unterscheiden, welche Zuverlässigkeitsmechanismen Sie persönlich in realen Produktionssystemen implementiert oder betrieben haben und welche Ansätze Sie im Rahmen von Forschung oder simulierten Tests untersucht haben? Welche KI-gestützten Wiederherstellungsfunktionen halten Sie bereits heute für praxistauglich, und welche sind Ihrer Ansicht nach noch weitgehend experimentell?

Zu meiner Arbeit in der Produktion gehörten Softwareentwicklung und -integration, Transaktionsvalidierung, Fehlerbehebung, Tests und die Validierung von Releases.

Meine veröffentlichten Forschungsarbeiten sind ein eigenständiger Teil meiner Arbeit. Jede Studie muss im Kontext ihrer angegebenen Methoden und Einschränkungen betrachtet werden.

Die Arbeit zu Ransomware bewertet ein vorgeschlagenes Sicherheitsframework in einer synthetischen Testumgebung. Meine Arbeit zu Edge-KI ist eine literaturgestützte Analyse von Intelligenz direkt auf dem Gerät und ihrer möglichen Anwendung auf Transaktionsterminals. Mein Artikel für IEEE FeedForward untersucht anhand kontrollierter Simulationen eine KI-gestützte Zuverlässigkeitsarchitektur, einschließlich Überwachung, Eskalation und Ausweichverhalten.

Keine dieser Veröffentlichungen sollte als Beleg dafür verstanden werden, dass ich einen autonomen KI-Agenten eingesetzt habe, der befugt war, in Echtzeit über Finanztransaktionen zu entscheiden.

Für die praktische Anwendung würde ich Unterstützung priorisieren, die Ingenieure überprüfen können: mit Quelldatensätzen verknüpfte Vorfallzusammenfassungen, Zusammenhänge zwischen Warnmeldungen und vorgeschlagene Diagnosetests. Wie nützlich diese Unterstützung ist, muss jedoch in der jeweiligen Einsatzumgebung gemessen werden.

Die größere Herausforderung ist eine offene Wiederherstellung, bei der ein Modell unter nicht vorhergesehenen Bedingungen Änderungen auswählt und ausführt. Dafür sind deutlich höhere Nachweise erforderlich als für einen nützlichen Diagnosevorschlag.

Ich betrachte meine Erfahrung in der Produktion und meine Forschung als sich ergänzend: Die eine vermittelt mir ein Verständnis der betrieblichen Probleme, während die andere Ansätze untersucht, die sich erst durch Validierung bewähren müssen.

Wie wird sich Ihrer Ansicht nach das Verhältnis zwischen autonomen Systemen und menschlichen Ingenieuren entwickeln, wenn KI-Agenten immer besser darin werden, Anomalien zu erkennen, Fehler zu diagnostizieren und die Wiederherstellung verteilter Systeme zu koordinieren? Welche technischen Schutzmaßnahmen, betrieblichen Nachweise und Rechenschaftsmechanismen wären erforderlich, bevor Unternehmen der KI mit gutem Grund mehr Befugnisse für geschäftskritische Produktionsinfrastrukturen übertragen könnten?

Ich gehe davon aus, dass KI zunehmend dabei helfen wird, ein Gesamtbild eines Vorfalls zusammenzustellen. Ingenieure könnten ihre Arbeit mit einer aussagekräftigen Zeitleiste, den betroffenen Komponenten, möglichen Erklärungen und fehlenden Nachweisen beginnen, statt viel Zeit darauf zu verwenden, diese Informationen manuell zusammenzutragen.

So hätten die Mitarbeitenden mehr Zeit für Entscheidungen, bei denen es darauf ankommt, die Verpflichtungen des Systems und die Folgen von Änderungen zu verstehen.

Ich würde die Ausführungsbefugnisse schrittweise erweitern. Ein Agent könnte zunächst im Schattenmodus arbeiten und Empfehlungen ausgeben, ohne sie umzusetzen. Teams könnten diese Empfehlungen mit geprüften Ergebnissen vergleichen und testen, wie sich der Agent verhält, wenn Informationen fehlen, widersprüchlich oder veraltet sind.

Die Bewertung sollte fehlerhafte Eingriffe, übersehene Probleme, unnötige Eskalationen und die Behebung von Fehlern des Agenten selbst umfassen. Eine schnelle Empfehlung ist nicht hilfreich, wenn sie das Einsatzteam in die falsche Richtung lenkt.

Auch weitergehende Befugnisse sollten an Bedingungen geknüpft bleiben. Eine Modellaktualisierung oder eine größere Systemänderung kann frühere Testergebnisse ungültig machen. Teams benötigen eine Möglichkeit, die Berechtigungen des Agenten einzuschränken oder zu entziehen, wenn sein Verhalten den erforderlichen Standard nicht mehr erfüllt.

Mit zunehmender Automatisierung entfällt die Verantwortung der Menschen nicht. Jemand muss die Betriebsregeln, die erforderlichen Nachweise für Änderungen und das Verfahren zur Untersuchung von Fehlern verantworten.

Ich kann mir vorstellen, dass Ingenieure weniger Zeit mit dem Sammeln von Informationen und mehr Zeit damit verbringen werden, die Bedingungen festzulegen, zu testen und aufrechtzuerhalten, unter denen automatisierte Maßnahmen gerechtfertigt sind.

Vielen Dank für das großartige Interview. Leserinnen und Leser, die seine Arbeit zur Zuverlässigkeit verteilter Transaktionen und zur verantwortungsvollen KI-gestützten Wiederherstellung verfolgen möchten, können mit Sapan Pandya Kontakt aufnehmen.