Dhivya Nagasubramanian, VP de la transformation et de l’innovation de l’IA – Série d’entretiens

Dhivya Nagasubramanian est VP de la transformation et de l’innovation de l’IA dans une grande institution financière américaine, où elle dirige la conception, le déploiement et la gouvernance des systèmes d’IA agents en production. Elle est l’auteur de Agentic AI for Engineers (Apress/Springer Nature), un guide pratique pour construire des systèmes d’IA autonomes qui peuvent être fiables en production. Depuis sa sortie, le livre a enregistré plus de 6 000 accès institutionnels sur SpringerLink, des détentions dans plus de 260 bibliothèques dans le monde entier, et une adoption dans les universités. Elle est titulaire d’un brevet délivré par l’USPTO dans le domaine de l’apprentissage automatique appliqué. Ses intérêts de recherche incluent la construction d’applications qui résistent aux attaques de jailbreak adverses et la contribution à des efforts industriels plus larges pour développer de meilleurs modèles de sécurité et de sûreté multiculturels. Elle est une experte et une panéliste très demandée dans de multiples conférences industrielles et universitaires.

Votre carrière a évolué de la consultation d’entreprise et de la science des données à la direction de la transformation de l’IA dans les services financiers. Comment ces expériences ont-elles façonné Agentic AI for Engineers, et quel écart récurrent entre la recherche en IA et le déploiement d’entreprise vous a convaincu que ce livre devait être écrit ?

J’ai commencé en 2008 en construisant des systèmes de comptabilité de portefeuille et de mesure de performance pour les plateformes bancaires. L’un de ces projets était un moteur conforme à GIPS pour calculer les rendements pondérés dans le temps, qui a été utilisé par des institutions financières dans plus de 80 pays. Ce travail m’a enseigné une leçon qui a façonné toute ma carrière. Dans la finance réglementée, la défaillance la plus dangereuse est un mauvais chiffre qui a l’air correct. Un calcul incorrect subtil est confié, rapporté et agi pendant des années, car rien ne semble cassé.

J’ai vu le même modèle à nouveau plus tard. J’ai trouvé un écart structurel dans le modèle de Markov d’un modèle d’attribution marketing largement utilisé. Le cadre a été utilisé par des centaines de milliers d’utilisateurs, et l’erreur a survécu pendant des années pour une raison : les sorties semblaient raisonnables. Lorsque je suis passé à la transformation de l’IA dans les services financiers, j’ai regardé les systèmes agents répéter ce modèle avec des enjeux beaucoup plus élevés. Un agent ne produit pas seulement un résultat incorrect. Il prend une action basée sur celui-ci.

L’écart qui m’a convaincu d’écrire le livre est que la recherche et le déploiement d’entreprise se soucient de choses différentes. La recherche mesure la capacité sur les références. Les entreprises dépendent de la façon dont un système se comporte sous l’ambiguïté, les données changeantes et la pression adverse. La plupart des écrits sur les agents s’arrêtent au stade de la démonstration. J’ai écrit Agentic AI for Engineers pour l’ingénieur qui doit mettre son nom sur un système qui fonctionnera avec une supervision limitée au sein d’une institution réglementée.

Le livre décrit le passage de l’automatisation à l’autonomie comme un nouveau mode de pensée pour l’ingénierie. Qu’est-ce qui sépare vraiment un agent d’IA autonome d’un flux de travail automatisé sophistiqué, et où les organisations sont-elles les plus susceptibles de confondre les deux ?

Je donne aux équipes un test simple. Pouvez-vous lister tous les chemins que le système peut prendre avant de l’exécuter ? Si oui, vous avez de l’automatisation. Il peut s’agir d’une automatisation très sophistiquée avec un modèle de langage à l’intérieur, mais c’est toujours de l’automatisation. Si le système décompose les objectifs, choisit les outils et décide de l’ordre des actions au moment de l’exécution en fonction du contexte que vous n’avez pas scripté, vous avez de l’autonomie. La différence n’a rien à voir avec le modèle que vous utilisez. Cela concerne le lieu où les décisions sont prises.

Les organisations confondent les deux dans les deux sens, mais une seule direction est coûteuse. Appeler un flux de travail LLM scripté agentic est principalement un problème de marketing. L’erreur coûteuse est l’inverse. Les équipes déployent une prise de décision autonome sous une gouvernance conçue pour l’automatisation déterministe. Leurs tests supposent la reproductibilité. Leur traçage des journaux d’activité suppose des modèles de défaillance connus. Leur traçage des audits suppose qu’il y a une règle traçable derrière chaque action. Aucune de ces hypothèses ne s’applique à un agent.

C’est le changement de mentalité que je plaide dans le livre. Avec l’automatisation, la principale question est de savoir si le système a été exécuté correctement. Avec l’autonomie, la question devient de savoir si le système a pris la bonne décision. Répondre à cela nécessite une instrumentation différente, des méthodes d’évaluation différentes et un niveau de prudence différent.

De nombreux systèmes d’IA agents présentent des performances impressionnantes dans les démonstrations mais luttent lorsqu’ils sont exposés à des utilisateurs réels, à des données changeantes et à des outils imprévisibles. Quels composants doivent être considérés comme obligatoires dans une architecture d’agent prête pour la production ?

L’honnête réponse est que la production nécessite tout ce que la démonstration vous permet de sauter. Une démonstration fonctionne parce que quelqu’un a contrôlé l’environnement. La production retire ce contrôle.

Dans le livre, je décris une architecture de référence à sept couches, mais voici les composants que je considère comme obligatoires. Des contrats d’outils avec des entrées typées et des autorisations explicites, de sorte que la portée de l’agent est limitée par la conception et non par l’espoir. Une gestion d’état qui survive aux interruptions et aux défaillances. Un traitement des défaillances structuré avec des chemins d’escalade définis. Un harnais d’évaluation qui s’exécute en continu, et non une seule fois avant le lancement. Et un traçage des audits qui enregistre les décisions et les raisons qui les motivent, et non seulement les actions prises.

Le composant que les équipes sautent le plus souvent est la vérification au moment de l’exécution. Il s’agit d’une couche qui vérifie chaque action par rapport à l’objectif déclaré de l’agent et aux politiques qui s’appliquent à celui-ci. L’infrastructure standard vous indique si un appel a réussi. La vérification demande si l’appel devait être effectué du tout. Elle ne prouve jamais sa valeur dans une démonstration, car rien n’a besoin d’être attrapé. En production, c’est la première chose que vous souhaiterez avoir.

Votre livre couvre la sécurité, l’alignement, les boucles de rétroaction, les tests, le débogage, l’évaluation et le déploiement. Comment les équipes d’ingénieurs doivent-elles combiner ces éléments en un processus d’assurance continue plutôt que de traiter la sécurité comme une revue finale avant le lancement ?

Une revue finale repose sur l’hypothèse que le système que vous avez examiné est le système qui sera exécuté. Pour l’IA agentic, cette hypothèse échoue de trois manières. Les modèles sous-jacents sont mis à jour. Les outils et les API sur lesquels l’agent dépend changent. Et les données et l’environnement dans lesquels l’agent opère continuent de changer. Une revue de sécurité unique décrit un système qui n’existe plus quelques mois plus tard.

L’assurance continue signifie fermer la boucle. Les évaluations comportementales s’exécutent dans l’intégration continue de la même manière que les tests unitaires, et elles bloquent chaque modification des invites, des outils et des modèles. La surveillance en temps réel alimente les traces de production dans les ensembles d’évaluation. Je décris quatre modèles de surveillance dans le livre, car aucun modèle unique ne couvre toute la surface de défaillance. Chaque incident produit un nouveau contrôle, de la même manière qu’un bogue devrait produire un test de régression. Et les tests adverses s’exécutent sur un calendrier régulier au lieu d’une seule fois avant le lancement.

Le côté organisationnel est aussi important que le côté technique. La sécurité ne peut pas être une équipe distincte qui se présente à la fin avec une liste de contrôle. Les ingénieurs qui construisent l’agent doivent posséder ses suites d’évaluation, ses invariants et sa conception d’escalade, car ils savent mieux que quiconque où le jugement du système est le plus faible.

Vous avez insisté sur la surveillance sémantique des appels d’outils d’agent. Qu’est-ce que la surveillance sémantique révèle qui ne peut pas être révélé par les journaux et les outils d’observabilité conventionnels, et comment peut-elle détecter quand un agent est techniquement fonctionnel mais poursuit l’objectif incorrect ?

Les outils d’observabilité conventionnels répondent à une question : l’appel a-t-il réussi ? Ils couvrent les codes d’état, les schémas, les latences et les taux d’erreur. Ils ne peuvent pas répondre à la question qui compte le plus pour les agents, qui est de savoir si l’appel devait se produire. Un appel d’outil peut être techniquement parfait et toujours être l’action incorrecte. Format correct, informations d’identification valides, réponse réussie, mauvaise chose à faire.

La surveillance sémantique évalue chaque action par rapport à l’objectif déclaré de l’agent et aux politiques qui s’appliquent à celui-ci. Dans le livre, je décris cela comme la définition d’invariants sémantiques sur les appels d’outils d’agent. Ce sont des propriétés qui doivent être maintenues quel que soit le chemin que l’agent prend. Un agent qui recherche un dossier client ne devrait jamais accéder à des dossiers en dehors de ce dossier. Un agent devrait signaler une discrepancy au-dessus d’un certain seuil, et non la résoudre lui-même. Lorsqu’un invariant est violé, vous attrapez le problème au moment de l’action au lieu de le faire dans un audit trimestriel.

C’est également la façon dont vous détectez la dérive d’objectif, que je considère comme la défaillance définie des systèmes agents. La dérive d’objectif ressemble à un agent qui termine chaque étape correctement selon les journaux tout en travaillant discrètement à l’objectif incorrect. Elle n’apparaît jamais dans un journal, car rien n’a échoué. La surveillance sémantique traite l’intention comme quelque chose que vous mesurez directement, et l’intention est là où les agents se trompent.

Lorsqu’un agent rencontre des instructions ambiguës, des politiques contradictoires, des outils indisponibles ou une confiance insuffisante, à quoi devrait ressembler un traitement de défaillance structuré ? Comment les développeurs peuvent-ils s’assurer que le système s’interrompt, escalade ou se rétablit au lieu d’improviser ?

Le problème à concevoir contre est que la plupart des agents n’ont qu’une seule façon de terminer une tâche, qui est de produire une réponse. Lorsque les instructions sont ambiguës ou que les politiques sont contradictoires, l’agent improvise. Non pas parce que le modèle est téméraire, mais parce que l’improvisation est le seul comportement que l’architecture permet. Un traitement de défaillance structuré signifie donner au système de meilleures options et les rendre plus faciles à atteindre qu’une réponse inventée.

En pratique, cela signifie que le refus et l’escalade sont conçus et testés avec le même soin que la réussite. Je recommande de définir des états de défaillance typés : instruction ambiguë, politique contradictoire, outil indisponible, confiance insuffisante. Chacun correspond à un comportement spécifique. Posez une question de clarification. Transférez à un humain avec le contexte complet attaché. Basculer en mode lecture seule. Réessayer dans des limites plus étroites. Ou arrêter. Les seuils de confiance doivent correspondre au risque de l’action spécifique. La barre pour la rédaction d’un résumé interne et la barre pour toucher un compte client ne devraient jamais être le même nombre.

Deux pratiques rendent cela réel. Premièrement, concevez le chemin d’escalade avant le chemin heureux. Si un humain recevra le transfert, décidez du contexte qu’il obtiendra et de l’autorité qu’il aura avant d’écrire la première invite. Deuxièmement, testez la défaillance de la même manière que vous testez les fonctionnalités. Injectez des instructions ambiguës. Désactivez les outils en staging. Alimentez l’agent avec des politiques contradictoires. Un système qui n’a jamais pratiqué la défaillance agira sans orientation la première fois qu’il se produira en production.

Les institutions financières doivent équilibrer l’expérimentation avec des exigences strictes en matière de confidentialité, de traçabilité, de risque de modèle et de conformité réglementaire. Où l’approbation humaine doit-elle rester obligatoire, et où les agents peuvent-ils être en toute sécurité dotés d’une plus grande autonomie opérationnelle ?

Ma règle est que l’approbation humaine devrait rester obligatoire pour toute action qui est irréversible, qui déplace de l’argent ou affecte le résultat d’un patient, qui implique des communications avec les clients portant un poids réglementaire, qui alimente des rapports réglementaires, ou qui modifie les outils, les politiques ou les autorisations de l’agent lui-même. Les agents peuvent prendre en toute sécurité plus d’autonomie dans le travail de lecture et de raisonnement : recherche, récupération, analyse de documents, triage, rédaction et réconciliations qui signalent les discrepancies pour examen humain au lieu de les résoudre.

L’erreur commune est d’exiger l’approbation humaine à chaque étape. Cela ne rend pas le système plus sûr. Cela recrée le processus manuel avec des étapes supplémentaires et forme les réviseurs à approuver sans réfléchir. Les approbations appartiennent aux véritables points de décision. Il devrait y en avoir peu, et chacun devrait être occupé par quelqu’un ayant une autorité réelle pour dire non.

Le autre principe est que l’autonomie devrait être gagnée plutôt que concédée. Commencez de manière étroite. Étendez-le à mesure que le système se prouve sous surveillance. Conservez les preuves. En termes de risque de modèle, votre environnement de contrôle devrait vous permettre de montrer à un régulateur non seulement ce que l’agent a fait, mais pourquoi vous étiez justifié pour lui donner ce niveau d’indépendance. Ce dossier est la véritable licence d’exploitation.

À travers votre travail sur les garde-fous et les normes de l’intelligence artificielle, vous contribuez à définir des règles pour des systèmes dont les capacités continuent de changer. Quels garde-fous peuvent être raisonnablement standardisés aujourd’hui, et quels domaines restent trop dépendants du contexte, de l’industrie ou de l’utilisation ?

Les garde-fous que nous pouvons standardiser aujourd’hui sont structurels. Ils exigent que certaines contrôles existent, soient documentés et puissent être inspectés. Limites de capacité et de permission documentées pour les systèmes autonomes. Mécanismes de surveillance humaine et d’escalade définis. Obligations de détection et de signalement d’incidents. Méthodes d’évaluation et exigences de preuve. Responsabilité claire tout au long du cycle de vie du système, de sorte que lorsque quelque chose se passe mal, la réponse à qui est responsable n’est jamais juste l’IA. Cela peut être standardisé car cela concerne l’existence et la qualité des contrôles, et non les valeurs spécifiques qu’ils prennent.

Ce que nous ne pouvons pas encore standardiser, ce sont les paramètres eux-mêmes. Les seuils de confiance spécifiques, les taxonomies de préjudice et les niveaux d’autonomie appropriés dépendent fortement du contexte. La tolérance de défaillance acceptable pour un agent de contenu marketing et pour un système qui touche des décisions cliniques ou financières ne sont pas deux points sur la même échelle. Ils appartiennent à des régimes différents, façonnés par le domaine, la juridiction et qui subit le préjudice lorsqu’il échoue.

Les contrôles financiers sont un modèle utile ici. Les exigences d’audit sont standardisées à l’échelle mondiale, mais la matérialité est toujours jugée dans le contexte. Les normes qui respectent cette division tendent à être adoptées. Les normes qui tentent de dicter des valeurs dépendantes du contexte tendent à être ignorées, et une norme de sécurité que personne ne suit ne protège personne.

Vos recherches récentes ont exploré la robustesse multiculturelle et la robustesse adverse dans l’évaluation de la sécurité de l’IA. Quels types de défaillances de modèles sont susceptibles d’être manqués par des références occidentales ou des références moyennes mondiales, et comment les entreprises doivent-elles évaluer les systèmes destinés à un déploiement multiculturel ?

Se concentrer uniquement sur les références moyennes peut manquer les défaillances qui comptent le plus. Un modèle peut afficher un score de sécurité global fort tout en échouant gravement pour un langage, un dialecte ou un contexte culturel spécifique, car ces défaillances disparaissent dans la moyenne. L’évaluation occidentale ajoute une autre cécité. Elle manque les préjudices qui sont spécifiques à la culture, tels que les expressions idiomatiques, les gestes et les contextes religieux ou régionaux où la même sortie est inoffensive dans une culture et nuisible dans une autre. Elle sous-teste également le code-switching, la translittération et les noms et entités non occidentaux. Il y a un angle adverse également. Les attaquants ne visent pas votre performance moyenne. Ils trouvent votre tranche la plus faible, et pour la plupart des modèles, cette tranche est un langage à faible ressource ou un contexte culturel sous-évalué.

C’est ce qui m’a amené à contribuer à la recherche sur les références de sécurité de l’IA multiculturelle. La découverte clé est simple. Juger la sécurité à travers les cultures nécessite des données d’évaluation et des jugements humains tirés de ces cultures. Vous ne pouvez pas évaluer le préjudice depuis l’extérieur du contexte dans lequel il se produit.

Pour les entreprises, je suggère trois règles. Évaluez chaque segment que vous servez, et n’acceptez jamais une moyenne comme preuve. Construisez des ensembles d’évaluation à partir de vos populations de clients réelles. Exécutez des tests adverses dans les langues que vos clients utilisent. Si vous servez des clients dans quarante pays et que vous n’évaluez que l’anglais, vous avez mesuré votre système pour le déploiement de quelqu’un d’autre.

Vous détenez également un brevet délivré par le Bureau des brevets et des marques des États-Unis dans l’apprentissage automatique appliqué. Quel problème essayiez-vous de résoudre, qu’est-ce que le processus vous a enseigné sur la transformation de la recherche en IA en innovation pratique, et quel défi non résolu de l’IA agentic vous intéresse le plus à relever ensuite ?

Le brevet qui a été récemment approuvé traite d’un problème d’échelle et de cohérence dans la revue de la qualité des services financiers – la revue de la qualité conventionnelle est manuelle, les réviseurs humains ne peuvent donc tester qu’un échantillon d’appels, et leurs évaluations varient d’une personne à l’autre. Mon approche achemine chaque question de qualité et de conformité vers la méthode la mieux adaptée pour y répondre, avec chaque décision enregistrée et traçable pour l’audit.

Vous pouvez voir les mêmes thèmes que j’ai décrits tout au long de cette interview. Acheminez chaque tâche vers l’outil le moins puissant qui peut la faire bien. Gardez les humains dans la boucle là où le jugement compte. Et rendez chaque décision automatisée traçable, car dans une institution réglementée, une réponse sans preuve n’est pas une réponse.

Le processus de brevet m’a enseigné que la discipline est dans les détails. Vous ne pouvez pas breveter une idée vague. Vous devez montrer exactement ce que votre méthode fait différemment, et exactement où elle s’applique. Cette précision forcée a rendu le travail sous-jacent meilleur.

Le défi non résolu qui me préoccupe le plus maintenant est la vérification au moment de l’exécution pour les systèmes multi-agents. Définir des invariants sémantiques pour un agent unique est faisable. Je sais, car nous le faisons en production. Lorsque les agents délèguent du travail à d’autres agents, le comportement devient émergent, et les défaillances se déplacent dans les handoffs. Une instruction est légèrement réinterprétée à chaque étape. Une politique s’applique à un agent mais pas à l’agent qu’il recrute. La vérification de l’interaction entre les agents, et non seulement des actions de chacun, est là où j’attends que la prochaine génération de défaillances silencieuses apparaisse. C’est le problème que je veux résoudre ensuite.

Merci pour cette grande interview, les lecteurs peuvent également commander son livre Agentic AI for Engineers.