28 juil. 2025·8 min
Dario Amodei et le défi d'une IA de pointe plus sûre
Aperçu des idées de Dario Amodei pour construire une IA de pointe plus sûre : objectifs d'alignement, évaluations, red teaming, gouvernance et garde-fous pratiques.
Aperçu des idées de Dario Amodei pour construire une IA de pointe plus sûre : objectifs d'alignement, évaluations, red teaming, gouvernance et garde-fous pratiques.
Dario Amodei compte dans la sécurité de l'IA parce qu'il est l'un des dirigeants les plus visibles à défendre l'idée que la génération suivante d'IA puissantes doit être développée avec des travaux de sécurité intégrés — pas ajoutés après le déploiement. En tant que PDG d'Anthropic et voix influente dans les débats sur la gouvernance et l'évaluation de l'IA, son impact se voit dans la manière dont les équipes discutent des portes de sortie, des tests mesurables de risque, et de l'idée que la capacité des modèles et l'ingénierie de la sécurité doivent évoluer ensemble.
Les modèles d'IA « frontier » sont ceux les plus proches de la pointe : les systèmes les plus grands et les plus capables, entraînés avec d'énormes quantités de données et de puissance de calcul. À cette échelle, les modèles peuvent accomplir une plus grande variété de tâches, suivre des instructions complexes et parfois afficher des comportements surprenants.
L'échelle frontier n'est pas juste « plus grand c'est mieux ». Elle signifie souvent :
Cet article se concentre sur les approches publiquement discutées associées aux laboratoires de pointe (y compris Anthropic) : red teaming, évaluations de modèles, méthodes d'alignement de type constitutionnel, et règles de déploiement claires. Il ne s'appuiera pas sur des affirmations privées ni ne spéculera sur des comportements de modèles non divulgués.
Le défi central mis en avant par le travail d'Amodei est simple à énoncer et difficile à résoudre : comment continuer à augmenter la capacité des IA — car les bénéfices peuvent être énormes — tout en réduisant les risques liés à des systèmes plus autonomes, plus persuasifs et plus polyvalents ?
« Systèmes d'IA plus sûrs » peut sonner comme un slogan, mais en pratique c'est un ensemble d'objectifs visant à réduire les dommages lors de l'entraînement, du déploiement et des mises à jour des modèles puissants.
Sécurité est le parapluie : prévenir que le modèle ne cause du tort aux personnes, organisations ou à la société.
Alignement signifie que le système tend à suivre les instructions et valeurs humaines voulues — surtout dans les situations délicates où le « bon » résultat n'est pas explicitement indiqué.
Mauvais usage concerne l'utilisation malveillante (p. ex. fraude, phishing, ou création d'instructions nuisibles), même si le modèle fonctionne « comme prévu ».
Fiabilité porte sur la cohérence et l'exactitude : le modèle se comporte-t-il de manière prévisible sur des requêtes similaires et évite-t-il d'inventer des faits critiques ?
Contrôle est la capacité à fixer des limites et à les maintenir — pour que le modèle ne soit pas facilement orienté vers des comportements dangereux, et que les opérateurs puissent intervenir quand nécessaire.
Les risques à court terme sont déjà familiers : désinformation à grande échelle, usurpation d'identité et fraude, fuites de confidentialité, décisions biaisées et conseils dangereux.
Les préoccupations à plus long terme concernent des systèmes qui deviennent plus difficiles à superviser à mesure qu'ils gagnent en capacité générale : le risque qu'un modèle poursuive des objectifs de manière non intentionnelle, résiste à la supervision ou facilite des abus à fort impact.
Les modèles plus grands n'améliorent souvent pas seulement la performance — ils peuvent acquérir de nouvelles compétences (par exemple rédiger des arnaques convaincantes ou enchaîner des étapes pour atteindre un objectif). À mesure que la capacité augmente, l'impact des échecs rares grandit, et de petites lacunes dans les garde-fous peuvent devenir des chemins vers des dommages sérieux.
Imaginez un bot de support client qui invente avec assurance une politique de remboursement et explique aux utilisateurs comment contourner la vérification. Même s'il se trompe seulement 1 % du temps, à grande échelle cela peut signifier des milliers de remboursements frauduleux, des pertes de revenus et une confiance affaiblie — transformant un problème de fiabilité en problème de sécurité et de mauvais usage.
Le développement d'IA de pointe (le type associé à des leaders comme Dario Amodei et des entreprises comme Anthropic) rencontre une tension simple : à mesure que les modèles deviennent plus capables, ils peuvent aussi devenir plus risqués.
Une plus grande capacité signifie souvent que le système peut rédiger des textes plus convaincants, planifier sur plusieurs étapes, utiliser des outils plus efficacement et s'adapter à l'intention de l'utilisateur. Ces mêmes forces peuvent amplifier les échecs — faciliter la génération d'instructions nuisibles, permettre des comportements de type tromperie, ou augmenter la probabilité de sorties « faussement pertinentes » qui paraissent fiables.
Les incitations sont réelles : de meilleurs benchmarks, plus de fonctionnalités et des sorties rapides attirent l'attention et les revenus. Le travail de sécurité, en revanche, peut sembler ralentir : exécuter des évaluations, mener des exercices de red teaming, ajouter des frictions aux parcours produit ou retarder un lancement jusqu'à ce que les problèmes soient compris.
Cela crée un conflit prévisible : l'organisation qui expédie la première peut gagner le marché, tandis que celle qui expédie la plus sûre peut paraître plus lente (et plus coûteuse) à court terme.
Une manière utile de cadrer le progrès n'est pas « parfaitement sûr », mais « plus sûr de façon mesurable à mesure que la capacité augmente ». Cela signifie suivre des indicateurs concrets — par exemple à quelle fréquence on peut amener un modèle à fournir des conseils restreints, à quel point il refuse de manière fiable les requêtes dangereuses, ou comment il se comporte face à des attaques adversariales — et exiger des améliorations avant d'élargir l'accès ou l'autonomie.
La sécurité n'est pas gratuite. Des garde-fous plus stricts peuvent réduire l'utilité (plus de refus), limiter l'ouverture (moins de partage des détails ou des poids du modèle), ralentir les sorties (plus de tests et de verrous), et augmenter le coût (plus d'évaluations, de surveillance et de supervision humaine). Le défi central est de décider quels compromis sont acceptables — et de rendre ces décisions explicites, pas accidentelles.
Les modèles de pointe ne sont pas « programmés » ligne par ligne. Ils sont développés via un pipeline d'étapes — chacune façonne ce que le modèle apprend et introduit différents types de risques.
L'entraînement revient à envoyer un élève dans une bibliothèque massive et lui demander d'absorber le fonctionnement du langage en lisant presque tout. Le modèle acquiert des compétences utiles (résumer, traduire, raisonner) mais hérite aussi des aspects désordonnés de ce qu'il a lu : biais, désinformation et instructions dangereuses.
Le risque apparaît ici parce qu'on ne peut pas prédire entièrement quels schémas le modèle internalisera. Même en triant les données, l'échelle fait que des comportements étranges peuvent passer entre les mailles — comme un pilote qui apprend de milliers de vidéos de vol, y compris quelques mauvaises habitudes.
Le fine-tuning s'apparente davantage à du coaching. On montre des exemples de bonnes réponses, des refus sûrs et un ton utile. Cela peut rendre un modèle beaucoup plus utilisable, mais aussi créer des angles morts : le modèle peut apprendre à « paraître sûr » tout en trouvant des moyens d'être non utile ou manipulateur dans des cas limites.
À mesure que les modèles grossissent, de nouvelles capacités peuvent apparaître soudainement — comme un projet d'avion qui semble correct en soufflerie puis se comporte différemment en vitesse réelle. Ces comportements émergents ne sont pas toujours mauvais, mais ils sont souvent inattendus, ce qui compte pour la sécurité.
Comme les risques apparaissent à plusieurs étapes, une IA de pointe plus sûre repose sur des couches : choix de données prudents, fine-tuning d'alignement, tests pré-déploiement, surveillance après la mise en production et points de décision clairs pour arrêter/continuer. C'est plus proche de la sécurité aéronautique (conception, simulation, vols d'essai, check-lists, revues d'incidents) que d'un « tampon de sécurité » unique.
Un cadre de sécurité est le plan écrit et de bout en bout qui explique comment une organisation décide si un modèle d'IA est suffisamment sûr pour poursuivre l'entraînement, le publier ou l'intégrer à des produits. Le point clé est qu'il est explicite : pas « nous prenons la sécurité au sérieux », mais un ensemble de règles, de mesures et de droits de décision qui peuvent être audités et reproduits.
La plupart des cadres crédibles combinent plusieurs éléments :
Les « portes de déploiement » sont des points de contrôle go/no-go liés à des seuils mesurables. Par exemple : « Si le modèle dépasse X en évaluation de mauvais usage, nous limitons l'accès aux utilisateurs vérifiés », ou « Si le taux d'hallucination dans un domaine critique dépasse Y, nous bloquons ce cas d'usage. » Les seuils réduisent l'ambiguïté, empêchent les décisions ad hoc sous pression et rendent plus difficile l'expédition d'un modèle uniquement parce qu'il impressionne.
Les lecteurs évaluant un fournisseur d'IA devraient rechercher : des catégories d'évaluation publiées, des décideurs nommés, des critères de verrouillage documentés (pas seulement des promesses), des preuves de surveillance continue après la mise en production et des engagements clairs sur ce qui se passe lorsque des tests échouent (retarder, restreindre ou annuler le déploiement).
Le red teaming est une tentative structurée de « casser » volontairement un système d'IA — comme embaucher des adversaires bienveillants pour sonder les points faibles avant que de vrais utilisateurs (ou des acteurs malveillants) ne les découvrent. Au lieu de demander « est-ce que ça marche ? », les red teamers demandent « comment cela peut échouer, et à quel point ce serait grave ? »
La QA standard suit des chemins attendus : prompts communs, parcours clients typiques et cas limites prévisibles. Les tests adversariaux sont différents : ils cherchent délibérément des entrées étranges, indirectes ou manipulatrices qui exploitent les schémas du modèle.
C'est important parce que les modèles de pointe peuvent bien se comporter dans des démos mais échouer sous pression — lorsque les prompts sont ambigus, chargés émotionnellement, multi-étapes ou conçus pour tromper le système et le pousser à ignorer ses propres règles.
Les tests de mauvais usage se concentrent sur la question de savoir si le modèle peut être poussé à aider des objectifs nuisibles — arnaques, encouragements au suicide, requêtes portant atteinte à la vie privée, ou aide opérationnelle pour des actes répréhensibles. Les red teamers essayent des jailbreaks, des jeux de rôle, des astuces de traduction et des « cadrages inoffensifs » qui cachent une intention dangereuse.
Les tests de comportements non voulus visent les échecs même quand l'utilisateur a une intention bénigne : faits hallucinatés, conseils médicaux ou juridiques dangereux, réponses trop assurées ou révélation de données sensibles d'un contexte antérieur.
Un bon red teaming se termine par des changements concrets. Les résultats peuvent conduire à :
Le but n'est pas la perfection — c'est réduire l'écart entre « fonctionne la plupart du temps » et « échoue en sécurité quand ça ne marche pas ».
Les évaluations de modèles sont des tests structurés qui posent une question simple : à mesure qu'un modèle devient plus capable, quels nouveaux dommages deviennent plausibles — et avec quelle confiance peut-on dire que les garde-fous tiennent ? Pour les équipes construisant des systèmes de pointe, les évaluations sont la manière dont la « sécurité » cesse d'être une impression et devient quelque chose que l'on peut mesurer, suivre et utiliser pour verrouiller les sorties.
Une démo ponctuelle n'est pas une évaluation. Une eval utile est répétable : mêmes ensembles de prompts, mêmes règles de notation, même environnement et versioning clair (modèle, outils, paramètres de sécurité). La répétabilité permet de comparer les résultats entre entraînements et déploiements, et rend les régressions évidentes lorsqu'une mise à jour change silencieusement le comportement.
De bons ensembles d'évaluation couvrent plusieurs types de risque, notamment :
Les benchmarks sont utiles parce qu'ils sont standardisés et comparables, mais ils peuvent devenir « enseignables ». Les tests en conditions réelles (y compris adversariaux et avec outils) découvrent des problèmes que les benchmarks manquent — comme l'injection de prompt, la persuasion multi-tours, ou des échecs qui n'apparaissent que lorsque le modèle a accès au web, à l'exécution de code ou à d'autres outils.
Les résultats d'évaluation devraient être suffisamment transparents pour instaurer la confiance — ce qui a été testé, comment c'était noté, ce qui a changé dans le temps — sans publier des recettes d'exploitation. Un bon modèle est de partager la méthodologie, des métriques agrégées et des exemples assainis, tout en restreignant les prompts sensibles, les techniques de contournement et les traces d'échecs détaillées aux canaux contrôlés.
Une approche « constitutionnelle » de l'alignement consiste à entraîner un modèle pour qu'il suive un ensemble écrit de principes — sa « constitution » — lorsqu'il répond ou décide de refuser. Plutôt que de compter uniquement sur des milliers d'interdictions et d'autorisation ad hoc, le modèle est guidé par un petit code explicite (par exemple : ne pas aider à commettre des méfaits, respecter la vie privée, être honnête sur l'incertitude, éviter les instructions facilitant des dommages).
Les équipes commencent généralement par rédiger des principes en langage clair. Ensuite, le modèle est entraîné — souvent par boucles de feedback — à privilégier les réponses qui respectent le mieux ces principes. Quand le modèle génère une réponse, il peut aussi être entraîné à critiquer et réviser son propre brouillon au regard de la constitution.
L'idée clé est la lisibilité : les humains peuvent lire les principes, les débattre et les mettre à jour. Cela rend l'intention du système de sécurité plus transparente qu'un ensemble purement implicite de comportements appris.
Une constitution écrite peut rendre le travail de sécurité plus auditable. Si un modèle refuse de répondre, on peut demander : quel principe a déclenché le refus, et cela correspond-il à votre politique ?
Elle peut aussi améliorer la cohérence. Lorsque les principes sont stables et que l'entraînement les renforce, le modèle est moins susceptible d'osciller entre permissivité excessive et rigidité d'une conversation à l'autre. Pour des produits réels, cette constance compte — les utilisateurs peuvent mieux prévoir ce que le système fera ou ne fera pas.
Les principes peuvent entrer en conflit. « Être utile » peut s'opposer à « prévenir les dommages », et « respecter l'intention de l'utilisateur » peut contraster avec « protéger la vie privée ». Les conversations réelles sont désordonnées, et les situations ambiguës sont précisément celles où les modèles improvisent.
Il y a aussi le problème des attaques par prompt : des prompts ingénieux peuvent pousser le modèle à réinterpréter, ignorer ou jouer un rôle qui contourne la constitution. Une constitution est une guidance, pas une garantie — surtout à mesure que la capacité des modèles augmente.
L'alignement constitutionnel doit être compris comme une couche dans une pile de sécurité plus large. Il se marie naturellement aux techniques discutées ailleurs dans cet article — comme le red teaming et les évaluations — parce qu'on peut tester si la constitution produit réellement un comportement plus sûr sur le terrain, et l'ajuster quand ce n'est pas le cas.
La sécurité des modèles de pointe n'est pas seulement un problème de recherche — c'est aussi un problème d'ingénierie produit. Même un modèle bien aligné peut être détourné, poussé dans des cas limites ou combiné avec des outils d'une manière qui augmente le risque. Les équipes les plus efficaces traitent la sécurité comme un ensemble de contrôles pratiques qui déterminent ce que le modèle peut faire, qui peut le faire et à quelle vitesse.
Quelques contrôles reviennent souvent parce qu'ils réduisent les dommages sans exiger un modèle parfait.
Limites de débit et throttling limitent la vitesse à laquelle quelqu'un peut sonder pour trouver des failles, automatiser des abus ou générer du contenu nuisible en masse. Les bonnes implémentations varient les limites selon le risque : plus strictes pour les endpoints sensibles (p. ex. utilisation d'outils, contexte long, fonctionnalités à haute autorisation), et limites adaptatives qui se renforcent quand le comportement parait suspect.
Filtres de contenu et application des politiques servent de seconde ligne de défense. Ils peuvent inclure des vérifications en amont sur les prompts, des contrôles en aval sur les sorties et des détecteurs spécialisés pour des catégories comme l'auto-mutilation, le contenu sexuel impliquant des mineurs ou les instructions pour commettre un délit. L'essentiel est de les concevoir en mode fail-closed pour les catégories à haut risque et de mesurer les faux positifs pour que l'utilisation légitime ne soit pas constamment bloquée.
Permissions d'outils comptent chaque fois que le modèle peut effectuer des actions (envoyer des e-mails, exécuter du code, accéder à des fichiers, appeler des API). Les produits plus sûrs traitent les outils comme des privilèges : le modèle ne devrait voir et utiliser que l'ensemble minimal requis pour la tâche, avec des contraintes claires (domaines autorisés, limites de dépense, commandes restreintes, modes lecture seule).
Tous les utilisateurs ou cas d'usage ne devraient pas avoir les mêmes capacités par défaut. Mesures pratiques :
C'est crucial pour les fonctionnalités qui augmentent fortement l'effet de levier : utilisation autonome d'outils, génération en masse ou intégration dans des flux clients.
Les contrôles de sécurité ont besoin de rétroaction. Maintenez des journaux permettant les enquêtes (tout en respectant la vie privée), surveillez les schémas d'abus (tentatives d'injection de prompt, hits répétés de politique, volume anormal) et créez une boucle de réponse claire : détecter, trier, atténuer et apprendre.
De bons produits facilitent :
L'expérience utilisateur est une fonctionnalité de sécurité. Avertissements clairs, confirmations « êtes-vous sûr ? » pour les actions à fort impact et paramètres par défaut qui incitent à des comportements plus sûrs réduisent les dommages non intentionnels.
Des choix de conception simples — exiger que les utilisateurs valident les actions d'outils avant exécution, afficher des citations et des indicateurs d'incertitude — aident les personnes à ne pas faire trop confiance au modèle et à détecter les erreurs tôt.
Construire une IA de pointe plus sûre n'est pas seulement un problème de conception de modèle — c'est un problème opérationnel. Une fois qu'un système est entraîné, évalué et livré à de vrais utilisateurs, la sécurité dépend de processus reproductibles qui ralentissent les équipes aux bons moments et créent de la responsabilité quand quelque chose tourne mal.
Une configuration opérationnelle pratique inclut généralement un mécanisme de revue interne qui fonctionne comme un comité de sortie léger. L'objectif n'est pas la bureaucratie ; c'est s'assurer que les décisions à fort impact ne sont pas prises par une seule équipe sous pression de délais.
Éléments communs :
Même de solides tests ne détecteront pas tous les schémas d'abus ou les comportements émergents. La réponse aux incidents vise à minimiser les dommages et à apprendre rapidement.
Un workflow d'incident sensé comprend :
C'est un domaine où les plateformes modernes peuvent aider concrètement. Par exemple, si vous développez des produits alimentés par l'IA avec Koder.ai (une plateforme vibe-coding qui génère des applications web, backend et mobiles depuis un chat), des patterns de sécurité opérationnelle comme snapshots and rollback se traduisent directement en confinement d'incident : vous pouvez préserver une version connue bonne, publier des atténuations et revenir en arrière rapidement si la surveillance montre un risque élevé. Considérez cette capacité comme faisant partie de vos portes de déploiement — pas juste une commodité.
Les audits tiers et les engagements avec des chercheurs externes peuvent ajouter une couche d'assurance — particulièrement pour des déploiements à fort enjeu. Ces efforts fonctionnent mieux lorsqu'ils sont cadrés (ce qui est testé), reproductibles (méthodes et artefacts) et actionnables (constats clairs et suivi des remédiations).
La sécurité des IA de pointe n'est pas seulement un problème de « mieux construire des garde-fous » au sein d'un laboratoire. Une fois que les modèles peuvent être largement copiés, fine-tunés et déployés dans de nombreux produits, le paysage du risque devient un problème de coordination : la politique de sortie prudente d'une entreprise n'empêche pas un autre acteur — bien intentionné ou malveillant — de déployer une variante moins testée. Les arguments publics de Dario Amodei soulignent souvent cette dynamique : la sécurité doit s'étendre à l'écosystème, pas seulement au modèle.
À mesure que les capacités augmentent, les incitations divergent. Certaines équipes privilégient la vitesse, d'autres la prudence, et beaucoup sont entre les deux. Sans attentes communes, on obtient des pratiques de sécurité inégales, des divulgations incohérentes et des « conditions de course » où l'option la plus sûre ressemble à un désavantage compétitif.
Une boîte à outils de gouvernance fonctionnelle n'exige pas que tout le monde s'accorde sur la philosophie — juste sur des pratiques minimales :
L'ouverture peut améliorer la responsabilité et la recherche, mais la diffusion complète de modèles puissants peut aussi abaisser le coût de l'abus. Une voie médiane est la transparence sélective : partager les protocoles d'évaluation, la recherche sur la sécurité et les résultats agrégés tout en restreignant les détails qui facilitent directement les mauvais usages.
Créez un guide de politique IA interne qui définit qui peut approuver les déploiements de modèles, quelles évaluations sont requises, comment les incidents sont traités et quand mettre en pause ou revenir sur des fonctionnalités. Si vous avez besoin d'un point de départ, rédigez une checklist de porte de déploiement d'une page et itérez — puis liez-la dans votre manuel d'équipe (par ex. /security/ai-policy).
Expédier l'IA en sécurité n'est pas seulement un problème de laboratoire de pointe. Si votre équipe utilise des modèles puissants via une API, vos décisions produit (prompts, outils, UI, permissions, surveillance) peuvent augmenter — ou réduire — le risque réel.
Ceci est aussi pertinent si vous allez vite avec le développement assisté par LLM : des plateformes comme Koder.ai peuvent accélérer fortement la création d'apps React, de backends Go avec PostgreSQL et de clients mobiles Flutter via chat — mais la vitesse n'aide que si vous l'associez aux mêmes fondamentaux abordés ci-dessus : définitions de risque explicites, evals répétables et portes de déploiement réelles.
Commencez par expliciter les risques. Écrivez ce à quoi « mauvais » ressemble pour votre cas d'usage : conseils dangereux, fuite de données, facilitation de fraude, contenu nuisible, erreurs trop assurées, ou actions effectuées pour le compte d'un utilisateur qui ne devraient pas l'être.
Puis construisez une boucle simple : définir → tester → déployer avec garde-fous → surveiller → améliorer.
Si vous construisez des fonctionnalités clients, envisagez de documenter votre approche dans une courte note publique (ou un /blog post) et conservez un plan clair pour augmenter l'usage et la tarification de manière responsable (par ex. /pricing).
Traitez ces questions comme des exigences continues, pas comme une paperasserie ponctuelle. Les équipes qui itèrent sur la mesure et les contrôles ont tendance à expédier plus vite et plus sûrement.
Dario Amodei est le PDG d'Anthropic et un promoteur public majeur de l'idée qu'il faut intégrer des pratiques de sécurité dès la conception des systèmes d'IA très puissants (« de pointe »).
Son influence tient moins à une technique unique qu'au fait qu'il insiste sur :
« Frontier » désigne les modèles les plus performants et les plus proches de l'état de l'art — généralement entraînés sur d'énormes jeux de données et de très grosses capacités de calcul.
À l'échelle « frontier », les modèles ont souvent :
C'est un ensemble concret d'objectifs visant à réduire les dommages sur tout le cycle de vie (entraînement, déploiement, mises à jour).
Concrètement, « plus sûr » signifie généralement améliorer :
L'augmentation de capacité peut introduire de nouvelles compétences (et de nouveaux modes de défaillance) invisibles à plus petite échelle.
À mesure que la capacité augmente :
Un cadre de sécurité est un plan écrit et de bout en bout qui décrit comment une organisation teste et décide de poursuivre l'entraînement, de publier ou d'élargir l'accès.
Cherchez :
Les « portes de déploiement » sont des points de contrôle explicites liés à des seuils mesurables.
Exemples de décisions de filtrage :
Elles réduisent les décisions ad hoc sous pression de lancement.
Le red teaming est un test adversarial structuré : on essaie de « casser » le système avant que de vrais utilisateurs (ou attaquants) ne le fassent.
Un red team utile :
Les évaluations (« evals ») sont des tests répétables qui mesurent les comportements pertinents par rapport au risque à travers les versions de modèles.
De bonnes evals sont :
La transparence peut porter sur la méthodologie et les métriques agrégées sans publier les recettes d'exploitation.
C'est une approche où le modèle est entraîné pour suivre un ensemble écrit de principes — une « constitution » — lorsqu'il répond ou décide de refuser.
Avantages :
Limites :
On peut réduire significativement le risque avec des contrôles produits et opérationnels même si le modèle n'est pas parfait.
Jeu d'actions pratique de départ :
Elle fonctionne mieux comme une couche du dispositif de sécurité, aux côtés des evals, du red teaming et des contrôles produits.
Visez une boucle : définir → tester → déployer avec garde-fous → surveiller → améliorer.