Dhivya Nagasubramanian, VP of KI-Transformation und Innovation – Interview-Serie

Dhivya Nagasubramanian ist VP of KI-Transformation und Innovation bei einer großen US-amerikanischen Finanzinstitution, wo sie die Gestaltung, Bereitstellung und Governance von Produktions-KI-Systemen leitet. Sie ist die Autorin von Agentic KI für Ingenieure (Apress/Springer Nature), einem praktischen Leitfaden für den Bau autonomer KI-Systeme, die in der Produktion vertrauenswürdig sind. Seit ihrer Veröffentlichung hat das Buch über 6.000 institutionelle Zugriffe auf SpringerLink verzeichnet, ist in über 260 Bibliotheken weltweit verfügbar und wird an Universitäten eingesetzt. Sie ist Inhaberin eines vom USPTO erteilten Patents im Bereich angewandter Machine Learning. Ihre Forschungsinteressen umfassen den Bau von Anwendungen, die gegenüber adversarialen Jailbreak-Angriffen resistent sind, und die Beteiligung an branchenweiten Bemühungen, bessere Modelle für multikulturelle Sicherheit und Sicherheit zu entwickeln. Sie ist eine gefragte Expertin und Panelistin auf verschiedenen Industrie- und akademischen Konferenzen.

Ihre Karriere hat sich von der Unternehmensberatung und der Datenwissenschaft zur Leitung der KI-Transformation in den Finanzdienstleistungen entwickelt. Wie haben diese Erfahrungen Agentic KI für Ingenieure geprägt, und welche wiederkehrende Lücke zwischen KI-Forschung und Unternehmensbereitstellung hat Sie davon überzeugt, dass dieses Buch geschrieben werden musste?

Ich begann 2008 mit dem Bau von Portfolio-Controlling- und Leistungsmeßsystemen für Bankplattformen. Eines dieser Projekte war ein GIPS-konformes Engine für die Berechnung von time-weighted Returns, das von Finanzinstituten in über 80 Ländern verwendet wurde. Diese Arbeit hat mir eine Lektion gelehrt, die meine gesamte Karriere geprägt hat. In regulierten Finanzen ist der gefährlichste Fehler ein falsche Zahl, die richtig aussieht. Eine subtil falsche Berechnung wird jahrelang vertraut, gemeldet und umgesetzt, weil nichts kaputt erscheint.

Ich sah das gleiche Muster später wieder. Ich fand eine strukturelle Lücke im Markov-Modell eines weit verbreiteten Marketing-Attributionsmodells. Das Framework wurde von Hunderttausenden von Nutzern verwendet, und der Fehler hatte jahrelang überlebt, weil die Ausgaben vernünftig aussahen. Als ich mich in die KI-Transformation in den Finanzdienstleistungen einarbeitete, beobachtete ich, wie agentic-Systeme dieses Muster mit viel höheren Einsätzen wiederholten. Ein Agent produziert nicht nur ein falsches Ergebnis. Er nimmt aufgrund dessen eine Aktion vor.

Die Lücke, die mich davon überzeugt hat, das Buch zu schreiben, ist, dass Forschung und Unternehmensbereitstellung unterschiedliche Dinge betreffen. Forschung misst die Fähigkeit anhand von Benchmarks. Unternehmen hängen von der Art und Weise ab, wie ein System unter Ambiguität, veränderten Daten und adversarialen Druck verhält. Die meisten Schriften über Agenten hören beim Demo-Stadium auf. Ich habe Agentic KI für Ingenieure für den Ingenieur geschrieben, der seinen Namen auf ein System setzen muss, das mit begrenzter Aufsicht innerhalb einer regulierten Institution läuft.

Das Buch beschreibt den Wechsel von Automation zu Autonomie als eine neue Ingenieursmentalität. Was trennt wirklich einen autonomen KI-Agenten von einer anspruchsvollen automatisierten Arbeitsabfolge, und wo sind Organisationen am wahrscheinlichsten, die beiden zu verwechseln?

Ich gebe Teams einen einfachen Test. Können Sie jeden Pfad auflisten, den das System nehmen kann, bevor Sie es ausführen? Wenn ja, haben Sie Automation. Es kann sehr anspruchsvolle Automation mit einem Sprachmodell darin sein, aber es ist immer noch Automation. Wenn das System Ziele zerlegt, Werkzeuge auswählt und die Reihenfolge der Aktionen zur Laufzeit basierend auf Kontexten bestimmt, die Sie nicht skripten, haben Sie Autonomie. Der Unterschied hat nichts mit dem verwendeten Modell zu tun. Es kommt darauf an, wo die Entscheidungen getroffen werden.

Organisationen verwechseln die beiden in beide Richtungen, aber nur eine Richtung ist teuer. Ein skripteter LLM-Workflow als agentic zu bezeichnen, ist hauptsächlich ein Marketingproblem. Der kostspielige Fehler ist das Gegenteil. Teams bereitstellen echte autonome Entscheidungsfindung unter Governance, die für deterministische Automation konzipiert wurde. Ihre Tests gehen von Wiederholbarkeit aus. Ihre Überwachung geht von bekannten Fehlermustern aus. Ihre Prüfungsspur geht davon aus, dass es eine nachvollziehbare Regel hinter jeder Aktion gibt. Keine dieser Annahmen gilt für einen Agenten.

Das ist die Mentalitätsänderung, für die ich in dem Buch plädiere. Bei Automation ist die Hauptfrage, ob das System korrekt ausgeführt wurde. Bei Autonomie wird die Frage, ob das System richtig entschieden hat. Darauf zu antworten, erfordert andere Instrumente, andere Bewertungsmethoden und ein anderes Maß an Vorsicht.

Viele agentic KI-Systeme erweisen sich in Demonstrationen als beeindruckend, aber sie haben Schwierigkeiten, wenn sie realen Benutzern, veränderten Daten und unvorhersehbaren Werkzeugen ausgesetzt sind. Welche Komponenten sollten in einer produktionsreifen Agentenarchitektur als obligatorisch betrachtet werden?

Die ehrliche Antwort ist, dass die Produktion alles benötigt, was man in einer Demonstration überspringen kann. Eine Demonstration funktioniert, weil jemand die Umgebung kontrolliert hat. Die Produktion nimmt diese Kontrolle weg.

In dem Buch beschreibe ich eine siebenstufige Referenzarchitektur, aber diese sind die Komponenten, die ich als obligatorisch betrachte. Werkzeugverträge mit typisierten Eingaben und expliziten Berechtigungen, so dass der Zugriff des Agenten durch Design und nicht durch Hoffnung begrenzt ist. Zustandsverwaltung, die Unterbrechungen und Ausfälle übersteht. Strukturierte Fehlerbehandlung mit definierten Eskalationspfaden. Eine Bewertungshülle, die kontinuierlich läuft, nicht nur einmal vor dem Start. Und eine Prüfungsspur, die Entscheidungen und die zugrunde liegende Begründung aufzeichnet, nicht nur die Aktionen.

Die Komponente, die Teams am häufigsten überspringen, ist die Laufzeitüberprüfung. Dies ist eine Schicht, die jede Aktion gegen das erklärte Ziel des Agenten und die anwendbaren Richtlinien überprüft. Standard-Infrastruktur sagt Ihnen, ob ein Aufruf erfolgreich war. Überprüfung fragt, ob der Aufruf überhaupt gemacht werden sollte. Es beweist seinen Wert nie in einer Demonstration, weil in einer Demonstration nichts gefangen werden muss. In der Produktion ist es das Erste, was Sie sich wünschen würden.

Ihr Buch behandelt Sicherheit, Ausrichtung, Rückkopplungsschleifen, Tests, Debugging, Bewertung und Bereitstellung. Wie sollten Ingenieur-Teams diese Elemente in einen kontinuierlichen Gewährleistungsprozess kombinieren, anstatt Sicherheit als eine endgültige Vor-Launch-Überprüfung zu behandeln?

Eine endgültige Überprüfung basiert auf der Annahme, dass das System, das Sie überprüft haben, das System ist, das läuft. Für agentic KI ist diese Annahme auf drei Arten falsch. Die zugrunde liegenden Modelle werden aktualisiert. Die Werkzeuge und APIs, auf die der Agent angewiesen ist, ändern sich. Und die Daten und die Umgebung, in der der Agent operiert, ändern sich ständig. Eine einmalige Sicherheitsüberprüfung beschreibt ein System, das einige Monate später nicht mehr existiert.

Kontinuierliche Gewährleistung bedeutet, den Kreis zu schließen. Verhaltensbewertungen laufen in CI (kontinuierliche Integration) genauso wie Einheitstests, und sie sperren jeden Change an Prompts, Werkzeugen und Modellen. Laufzeitüberwachung füttert Produktionsspuren zurück in die Bewertungssätze. Ich beschreibe vier Überwachungsmuster im Buch, weil kein einzelnes Muster die gesamte Fehlerfläche abdeckt. Jedes Ereignis produziert einen neuen Check, genauso wie jeder Bug einen Regressions-Test produzieren sollte. Und adversarialer Test läuft auf einem regelmäßigen Zeitplan statt nur einmal vor dem Start.

Die organisatorische Seite ist ebenso wichtig wie die technische Seite. Sicherheit kann nicht ein separates Team sein, das am Ende mit einer Checkliste erscheint. Die Ingenieure, die den Agenten bauen, sollten die Bewertungssuiten, die Invarianten und die Eskalationsgestaltung besitzen, weil sie besser als jeder andere wissen, wo das Urteilsvermögen des Systems am schwächsten ist.

Sie haben semantische Überwachung von Agenten-Werkzeugaufrufen betont. Was zeigt semantische Überwachung, das herkömmliche Protokolle und Überwachungstools nicht können, und wie kann sie erkennen, wenn ein Agent technisch funktionsfähig ist, aber das falsche Ziel verfolgt?

Herkömmliche Überwachbarkeit beantwortet eine Frage: War der Aufruf erfolgreich? Es deckt Statuscodes, Schemata, Latenz und Fehlerquoten ab. Es kann die Frage nicht beantworten, die für Agenten am wichtigsten ist, nämlich, ob der Aufruf hätte stattfinden sollen. Ein Werkzeugaufruf kann technisch perfekt sein und dennoch die falsche Aktion sein. Richtiges Format, gültige Anmeldeinformationen, erfolgreiche Antwort, falsche Sache zu tun.

Semantische Überwachung bewertet jede Aktion gegen das erklärte Ziel des Agenten und die anwendbaren Richtlinien. Im Buch beschreibe ich dies als Definition semantischer Invarianten über Agenten-Werkzeugaufrufe. Diese sind Eigenschaften, die unabhängig vom Pfad, den der Agent nimmt, gelten müssen. Ein Agent, der einen Kundenfall recherchiert, sollte niemals Aufzeichnungen außerhalb dieses Falls zugreifen. Ein Agent sollte eine Abweichung über einem bestimmten Schwellenwert kennzeichnen, niemals selbst auflösen. Wenn eine Invariante verletzt wird, fangen Sie das Problem im Moment der Aktion statt in einer quartalsweisen Prüfung.

Das ist auch, wie Sie Zielverschiebung erkennen, die ich als den definierenden Fehler von agentic-Systemen betrachte. Zielverschiebung sieht aus wie ein Agent, der jeden Schritt korrekt ausführt, während er stillschweigend auf das falsche Ziel hinarbeitet. Es erscheint nie in einem Protokoll, weil nichts fehlgeschlagen ist. Semantische Überwachung behandelt Absicht als etwas, das direkt gemessen wird, und Absicht ist, wo Agenten falsch liegen.

Wenn ein Agent unsichere Anweisungen, widersprüchliche Richtlinien, nicht verfügbare Werkzeuge oder unzureichende Zuversicht trifft, wie sollte strukturierte Fehlerbehandlung aussehen? Wie können Entwickler sicherstellen, dass das System pausiert, eskaliert oder sich erholen kann, anstatt zu improvisieren?

Das Problem, gegen das zu entwerfen ist, ist, dass die meisten Agenten nur eine Möglichkeit haben, eine Aufgabe zu beenden, nämlich eine Antwort zu liefern. Wenn Anweisungen unsicher sind oder Richtlinien widersprechen, improvisiert der Agent. Nicht, weil das Modell rücksichtslos ist, sondern weil Improvisation das einzige Verhalten ist, das die Architektur zulässt. Strukturierte Fehlerbehandlung bedeutet, dem System bessere Optionen zu geben und sie einfacher zu machen als eine erfundene Antwort.

In der Praxis bedeutet das, dass Ablehnung und Eskalation mit der gleichen Sorgfalt wie Erfolg entworfen und getestet werden. Ich empfehle, typisierte Fehlerzustände zu definieren: unsichere Anweisung, widersprüchliche Richtlinie, nicht verfügbares Werkzeug, unzureichende Zuversicht. Jeder davon entspricht einem bestimmten Verhalten. Stellen Sie eine klärende Frage. Übergeben Sie an einen Menschen mit vollständigem Kontext. Wechseln Sie in den schreibgeschützten Betrieb. Wiederholen Sie innerhalb engerer Grenzen. Oder stoppen Sie. Zuversichtsschwellen sollten dem Risiko der spezifischen Aktion entsprechen. Die Latte für die Erstellung einer internen Zusammenfassung und die Latte für die Berührung eines Kundenkontos sollten niemals die gleiche Zahl sein.

Zwei Praktiken machen dies real. Zuerst entwerfen Sie den Eskalationspfad, bevor Sie den glücklichen Pfad entwerfen. Wenn ein Mensch die Übernahme erhält, entscheiden Sie, welchen Kontext er erhält und welche Autorität er hat, bevor Sie den ersten Prompt schreiben. Zweitens testen Sie Fehler genauso wie Funktionen. Injizieren Sie unsichere Anweisungen. Deaktivieren Sie Werkzeuge in der Staging-Umgebung. Füttern Sie dem Agenten widersprüchliche Richtlinien. Ein System, das nie gefehlerhaft getestet wurde, wird ohne Anleitung handeln, wenn es zum ersten Mal in der Produktion passiert.

Finanzinstitute müssen Experimentieren mit strengen Anforderungen an Datenschutz, Prüfbarkeit, Modellrisiko und regulatorische Konformität in Einklang bringen. Wo sollte menschliche Genehmigung verpflichtend bleiben, und wo können Agenten sicher eine größere operative Autonomie erhalten?

Meine Regel ist, dass menschliche Genehmigung für jede Aktion verpflichtend bleiben sollte, die irreversibel ist, die Geld bewegt oder das Ergebnis eines Patienten beeinflusst, die Kundenkommunikation mit regulatorischem Gewicht umfasst, die regulatorische Berichterstattung speist oder die Werkzeuge, Richtlinien oder Berechtigungen des Agenten ändert. Agenten können sicher mehr Autonomie in Lese- und Vernunftarbeit übernehmen: Forschung, Abruf, Dokumentenanalyse, Triage, Erstellung und Abstimmung, die Abweichungen für menschliche Überprüfung kennzeichnen, anstatt sie selbst zu lösen.

Der häufige Fehler ist, menschliche Genehmigung bei jedem Schritt zu verlangen. Das macht das System nicht sicherer. Es rekonstruiert den manuellen Prozess mit zusätzlichen Schritten und trainiert Rezensenten, um zu rubbeln. Genehmigungen gehören an echte Entscheidungspunkte. Es sollte wenige davon geben, und jede sollte von jemandem besetzt werden, der tatsächliche Autorität hat, Nein zu sagen.

Das andere Prinzip ist, dass Autonomie verdient und nicht gewährt werden sollte. Fangen Sie eng an. Erweitern Sie, wenn das System sich unter Überwachung bewährt. Bewahren Sie die Beweise. In Bezug auf Modellrisiken sollte Ihre Kontrollumgebung es Ihnen ermöglichen, einem Regulator nicht nur zu zeigen, was der Agent getan hat, sondern warum Sie berechtigt waren, ihm dieses Maß an Unabhängigkeit zu gewähren. Diese Aufzeichnung ist die eigentliche Betriebslizenz.

Durch Ihre Arbeit an KI-Sicherheits- und Standardsvorhaben helfen Sie dabei, Regeln für Systeme zu definieren, deren Fähigkeiten weiterhin ändern. Welche Sicherheitsvorkehrungen können realistischerweise heute standardisiert werden, und welche Bereiche hängen noch zu sehr von Kontext, Branche oder Einsatzfall ab?

Die Sicherheitsvorkehrungen, die wir heute standardisieren können, sind strukturell. Sie erfordern, dass bestimmte Kontrollen existieren, dokumentiert sind und überprüft werden können. Dokumentierte Fähigkeits- und Berechtigungsgrenzen für autonome Systeme. Definierte menschliche Aufsichts- und Eskalationsmechanismen. Meldepflichten für Ereignisse und Bewertungsmethoden. Klare Rechenschaftspflicht über den gesamten Systemlebenszyklus, so dass die Antwort auf die Frage, wer verantwortlich ist, wenn etwas schiefgeht, nie nur die KI ist. Diese können standardisiert werden, weil sie die Existenz und Güte der Kontrollen betreffen, nicht die spezifischen Werte, die sie annehmen.

Was wir noch nicht standardisieren können, sind die Einstellungen selbst. Spezifische Zuversichtsschwellen, Schadens taxonomien und angemessene Autonomiegrade hängen stark vom Kontext ab. Die akzeptable Fehlertoleranz für einen Marketing-Inhaltsagenten und für ein System, das klinische oder finanzielle Entscheidungen berührt, sind nicht zwei Punkte auf der gleichen Skala. Sie gehören zu verschiedenen Regimen, die von der Domäne, der Gerichtsbarkeit und davon bestimmt werden, wer den Schaden trägt, wenn etwas schiefgeht.

Finanzkontrollen sind ein nützliches Modell hier. Prüfanforderungen sind global standardisiert, aber Materialität wird immer im Kontext beurteilt. Standards, die diesen Unterschied respektieren, neigen dazu, angenommen zu werden. Standards, die kontextabhängige Werte diktieren, neigen dazu, ignoriert zu werden, und ein Sicherheitsstandard, dem niemand folgt, schützt niemanden.

Ihre jüngste Forschung hat sich mit multikultureller und adversarialer Robustheit in der KI-Sicherheitsbewertung befasst. Welche Arten von Modellfehlern werden wahrscheinlich von westlich-zentrierten oder global durchschnittlichen Benchmarks verpasst, und wie sollten Unternehmen Systeme für multikulturelle Bereitstellung bewerten?

Das Betrachten von durchschnittlichen Benchmarks kann die Fehler verpassen, die am wichtigsten sind. Ein Modell kann eine starke Gesamtsicherheitspunktzahl aufweisen, während es für einen bestimmten Sprach-, Dialekt- oder kulturellen Kontext schlecht abschneidet, weil diese Fehler in den Durchschnitt verschwinden. Westlich-zentrierte Bewertung fügt einen weiteren blinden Fleck hinzu. Sie verpasst Schäden, die kulturspezifisch sind, wie Idiome, Gesten und religiöse oder regionale Kontexte, in denen die gleiche Ausgabe in einer Kultur harmlos und in einer anderen schädlich ist. Sie testet auch Code-Switching, Transliteration und nicht-westliche Namen und Entitäten nicht ausreichend. Es gibt auch einen adversarialen Winkel. Angreifer zielen nicht auf Ihre durchschnittliche Leistung ab. Sie finden Ihren schwächsten Schnitt, und für die meisten Modelle ist dieser Schnitt eine Sprache mit geringen Ressourcen oder ein kultureller Kontext, der nicht ausreichend bewertet wird.

Das ist, was mich dazu gebracht hat, mich an die multikulturelle KI-Sicherheitsbenchmark-Forschung zu beteiligen. Die Kernfeststellung ist einfach. Die Beurteilung von Sicherheit über Kulturen hinweg erfordert Bewertungsdaten und menschliche Urteile, die aus diesen Kulturen stammen. Sie können Schaden nicht aus dem Kontext beurteilen, in dem er auftritt.

Für Unternehmen schlage ich drei Regeln vor. Bewerten Sie jeden Segment, den Sie bedienen, und akzeptieren Sie nie einen Durchschnitt als Beweis. Bauen Sie Bewertungssätze aus Ihren tatsächlichen Kundenpopulationen auf. Führen Sie adversarialen Test in den Sprachen durch, die Ihre Kunden verwenden. Wenn Sie Kunden in vierzig Ländern bedienen und nur in Englisch bewerten, haben Sie Ihr System für jemand anderes bereitgestellt.

Sie sind auch Inhaberin eines vom United States Patent and Trademark Office erteilten Patents im Bereich angewandter KI. Welches Problem versuchten Sie zu lösen, was hat der Prozess Sie gelehrt, KI-Forschung in praktische Innovation umzusetzen, und welche ungelöste agentic-KI-Herausforderung interessiert Sie am meisten, die Sie als Nächstes angehen möchten?

Das Patent, das kürzlich genehmigt wurde, behandelt ein Skalierungs- und Konsistenzproblem in der Qualitätssicherung von Finanzdienstleistungen – herkömmliche Aufrufbewertung ist manuell, so dass menschliche Rezensenten nur einen Bruchteil der Aufrufe bewerten können, und ihre Bewertungen variieren von Person zu Person. Mein Ansatz leitet jede Qualität- und Compliance-Frage an die Methode weiter, die am besten geeignet ist, um sie zu beantworten, wobei jede Entscheidung protokolliert und für die Prüfung nachvollziehbar ist.

Man kann die gleichen Themen sehen, die ich in diesem Interview beschrieben habe. Leiten Sie jede Aufgabe an das schwächste Werkzeug weiter, das sie gut erledigen kann. Halten Sie Menschen in der Schleife, wo Urteilsvermögen zählt. Und machen Sie jede automatisierte Entscheidung nachvollziehbar, weil in einer regulierten Institution eine Antwort ohne Beweis keine Antwort ist.

Was der Patentprozess mich gelehrt hat, ist, dass die Disziplin in den Details liegt. Sie können keine vage Idee patentieren. Sie müssen genau zeigen, was Ihre Methode anders macht, und genau, wo sie angewendet wird. Diese erzwungene Präzision hat die zugrunde liegende Arbeit besser gemacht.

Die ungelöste Herausforderung, die mich am meisten interessiert, ist die Laufzeitüberprüfung für Multi-Agenten-Systeme. Die Definition semantischer Invarianten für einen einzelnen Agenten ist machbar. Ich weiß, weil wir es in der Produktion tun. Wenn Agenten Arbeit an andere Agenten delegieren, wird das Verhalten emergent, und die Fehler bewegen sich in die Übergaben. Eine Anweisung wird bei jedem Schritt ein wenig umgedeutet. Eine Richtlinie gilt für einen Agenten, aber nicht für den Agenten, den er rekrutiert. Die Überprüfung der Interaktion zwischen Agenten, nicht nur ihrer Aktionen, ist, wo ich erwarte, dass die nächste Generation stiller Fehler auftauchen wird. Das ist das Problem, an dem ich als Nächstes arbeiten möchte.

Vielen Dank für das großartige Interview, Leser können auch ihr Buch Agentic KI für Ingenieure bestellen.