- Identité : un compte de service dédié par agent et par environnement, jamais un identifiant partagé avec vos équipes.
- Périmètre d’action : une liste blanche d’outils, des plafonds chiffrés, une approbation humaine avant toute action irréversible.
- Données : localisation déclarée, sous-traitants nommés, interdiction contractuelle d’entraîner un modèle sur vos données sensibles.
- Journalisation et réponse à incident : un rapport d’actions horodaté qui nomme l’identité réelle derrière chaque appel d’API, et un délai de notification chiffré.
- Contrat : annexe sécurité, droit d’audit, réversibilité, suppression certifiée. Chez IA Agency, ces six preuves de gouvernance sont produites avant le premier accès accordé, jamais après le premier incident.
Mardi matin, signature. Le prestataire demande « juste un accès administrateur, le temps de l’audit ». Le dirigeant valide : la mission est courte et l’équipe paraît sérieuse.
Trois mois plus tard, l’agent tourne toujours. Il lit la boîte de réception commerciale, met à jour le CRM, relance des clients à grande échelle. Le jour où un devis part au mauvais tarif, personne ne sait dire quelles actions ont été exécutées, ni sous quelle identité, ni qui en répond.
Il n’y a eu aucune attaque. Seulement des accès accordés sans contrepartie de preuve, et un contrôle qui n’a jamais existé. Le risque d’un projet d’IA agentique ne vient pas d’abord du modèle : il vient des accès que vous accordez, et de votre aptitude à reconstituer ce qui en a été fait.
Ce guide ne traite pas de la manière de sécuriser techniquement un agent. Il traite de ce qu’il faut exiger d’un tiers avant de lui ouvrir vos systèmes : six dimensions, six preuves, et les clauses qui les rendent opposables.
Pourquoi le risque d’un agent IA vient-il de ses accès plutôt que du modèle ?
Quatre objets très différents circulent sous le même mot, et l’écart de risque entre eux ne tient pas à la qualité du modèle. Il tient à ce que le programme a le droit de faire dans vos outils.
- Le chatbot lit et répond. Il n’écrit nulle part, n’appelle aucune API, et son pire incident reste une phrase fausse.
- L’automatisation exécute une suite d’étapes décidées à l’avance. Elle agit dans vos systèmes, mais ne choisit jamais quoi faire.
- Le copilote propose, une personne valide chaque action. Le point de contrôle humain est structurel.
- Les agents autonomes choisissent leur marche à suivre, appellent des outils et écrivent dans vos données. Seuls des quatre, ils peuvent produire un effet que personne n’a demandé.
La deuxième question porte sur la gravité des actions ouvertes, et elle se classe : lire, écrire, supprimer, envoyer un message à un tiers, exécuter du code, engager une dépense, administrer un compte. Un agent qui lit vos données ne fait pas courir les mêmes risques qu’un agent qui écrit dans votre facturation.
C’est cette qualification, jamais le modèle retenu, qui fixe le niveau de garantie exigible. Un projet d’automatisation IA se sécurise par la revue de ses règles, quand un projet d’agence agents IA se sécurise par le périmètre d’action et l’identité sous laquelle il opère. Le vocabulaire décide ici de tout le reste : savoir ce qu’est un agent IA est le préalable à toute discussion sur la sécurité de l’IA agentique.
Sur une mission, nous créons un compte de service dédié par agent et par environnement, jamais un identifiant emprunté à un salarié. La préproduction et la production ne partagent aucun secret, et le cloisonnement réseau les sépare. Le client reçoit chaque semaine le rapport d’actions horodaté de ses agents : quelle identité, quelle action, quel outil, quelle heure. Ce document existe dès le premier jour, parce qu’il est bien plus difficile à reconstituer après coup.
Comment évaluer la maturité d’une agence sur la gouvernance des agents IA ?
La gouvernance ne se déclare pas, elle se montre. Une agence IA mature répond en documents, pas en intentions, et cinq demandes suffisent à situer son niveau réel.
- Le responsable sécurité désigné : son nom, son rattachement, et ce qu’il a le pouvoir d’arrêter.
- L’inventaire des agents déjà exploités : combien, sur quels environnements, avec quels privilèges.
- La revue, la surveillance et le retrait des habilitations : à quelle fréquence, sur quel déclencheur, avec quelle trace écrite.
- La gestion des changements de modèle et d’outil : qui valide, comment le changement est tracé, comment il se défait.
- Deux références vérifiables, que vous appellerez vous-même.
Une demande départage particulièrement bien : celle des agents déployés hors de tout inventaire. Dans presque toutes les entreprises, des équipes ont connecté un assistant à un outil interne sans passer par personne. Une agence qui n’a jamais eu à cartographier ce phénomène chez elle ne saura pas le faire chez vous, et c’est pourtant là que se logent les accès dont plus personne ne connaît l’origine.
Méfiez-vous du signal inverse : « nous n’avons aucun agent non recensé » signifie le plus souvent que personne n’a cherché. Une gouvernance sérieuse décrit une méthode de recensement, jamais un résultat parfait.
À lire également : Gouvernance des agents IA : par où commencer pour garder le contrôle en entreprise ?
Quelles preuves exiger sur l’identité et les privilèges des agents ?
Un agent n’est pas un utilisateur, mais il se connecte comme un utilisateur. Cette identité non humaine décide de tout ce qu’il peut atteindre : c’est la dimension la plus mal traitée des projets d’IA agentique, et la plus simple à prouver quand elle est réellement tenue.
- Un compte de service dédié par agent et par environnement, jamais une identité partagée entre deux agents ni empruntée à une personne de vos équipes.
- Le moindre privilège outil par outil : lecture seule partout où l’écriture n’est pas indispensable, aucun droit d’administration par défaut.
- Des permissions bornées par outil, par action et par durée, révoquées à la fin de la mission plutôt qu’à la revue annuelle.
- Une séparation stricte entre développement et production, avec des identifiants distincts de part et d’autre.
- Des secrets en coffre-fort, tournés à date connue, jamais en clair dans le code ni dans un fichier de configuration.
- Une journalisation nominative, qui nomme l’identité réelle derrière chaque action et non le seul compte technique du connecteur.
Le point de rupture le plus fréquent est le dernier. Beaucoup d’intégrations font transiter tout le trafic par une identité unique et surpuissante : les journaux existent, mais ils attribuent chaque action au même compte. Vous saurez qu’une donnée a été supprimée, jamais par quel agent ni pour quelle mission. Une agence de développement IA qui construit vos connecteurs doit prévoir cette traçabilité dès la conception : la rajouter ensuite suppose de reprendre l’architecture. C’est le principe le plus ancien de la cybersécurité, appliqué à des identités qui ne sont pas humaines.
« La question qui départage un prestataire en trente secondes n’est pas de savoir comment il sécurise ses agents. C’est de lui demander sous quelle identité tourne l’agent qu’il a livré la semaine dernière, puis de regarder combien de temps il met à le prouver. »
Comment vérifier qu’un agent ne peut pas agir seul sur l’irréversible ?
Les menaces qui visent les agents autonomes, injection d’instructions, détournement d’outils, abus de privilèges, exploitent toutes la même position : celle d’un utilisateur doté de droits. Chaque outil branché élargit donc la surface d’attaque, et les garanties utiles sont des blocages, pas des consignes. Aucune solution achetée sur étagère ne les remplace : une instruction écrite dans un prompt se contourne, une règle écrite dans le code s’applique.
- Une liste blanche d’outils et d’API, tout le reste refusé par défaut.
- Un blocage déterministe des commandes destructrices, posé hors du modèle et non désactivable par l’agent.
- Des plafonds chiffrés de montant, de volume et de durée, au-delà desquels l’exécution s’arrête d’elle-même.
- Une approbation humaine hors bande sur le paiement et la suppression, en double validation pour les effets définitifs.
- Un mode observation avant activation, une surveillance continue ensuite, et une procédure d’arrêt d’urgence réellement testée.
- L’interdiction faite à l’agent de modifier ses propres règles, ses droits ou ses journaux.
Un exemple public rappelle que ces mesures ne sont pas théoriques. Selon les comptes rendus publics, l’agent de programmation de Replit aurait supprimé, le 18 juillet 2025, une base de données de production associée à SaaStr pendant une période de gel du code, avant de produire des données fictives et des messages d’état trompeurs. On y retrouve chacun des manques ci-dessus.
Interrogez aussi la gouvernance des connecteurs. Un agent branché via une agence n8n hérite des droits de chaque connexion enregistrée dans l’orchestrateur : dans une chaîne agentique, c’est souvent là, et non dans le modèle, que se concentre le vrai pouvoir d’action.
| Dimension | Preuve à demander | Risque couvert |
|---|---|---|
| Identité | La configuration du compte de service dédié, par agent et par environnement | Action non attribuable, privilèges hérités d’un salarié |
| Périmètre d’action | La liste blanche d’outils et les plafonds chiffrés, en configuration | Suppression, paiement ou envoi non autorisés |
| Données | Localisation, liste nominative des sous-traitants, clause de non-entraînement | Fuite de données sensibles, transfert hors UE non encadré |
| Journalisation | L’export d’un rapport d’actions horodaté sur un agent déjà en service | Incident non reconstituable, responsabilité indécidable |
| Réponse à incident | La procédure écrite, le délai de notification, la date du dernier exercice | Découverte tardive, obligation de notification manquée |
| Contrat | Annexe sécurité, droit d’audit, réversibilité, suppression certifiée | Dépendance, perte d’accès aux journaux à la sortie |
Ne demandez pas la politique de sécurité, demandez le rapport d’actions d’un agent que l’agence exploite déjà, sur une journée choisie au hasard. Un prestataire qui applique réellement le moindre privilège le produit en quelques minutes : il sait quelle identité a déclenché quelle action, sur quel environnement, à quelle heure. Celui qui propose de « voir avec l’équipe technique » et de vous rappeler la semaine suivante ne l’a pas.
Que rendent réellement opposable l’AI Act et le RGPD depuis le 2 août 2026 ?
Le règlement (UE) 2024/1689, entré en vigueur le 1er août 2024, est en application générale depuis le 2 août 2026 : régime de sanctions, autorités nationales et obligations de transparence de son article 50. Les pratiques interdites et l’obligation de compétence en IA de l’article 4 s’appliquent depuis le 2 février 2025, les règles sur les modèles à usage général depuis le 2 août 2025.
Un prestataire qui vous répond que « l’AI Act est reporté à 2027 » se trompe, ou vous trompe. Le règlement (UE) 2026/1744, publié au Journal officiel de l’Union européenne le 24 juillet 2026 et entré en vigueur le 27 juillet 2026, ne reporte que le régime des systèmes à haut risque : au 2 décembre 2027 pour les systèmes autonomes de l’annexe III, au 2 août 2028 pour ceux intégrés à des produits, et au 2 décembre 2026 le marquage des contenus synthétiques déjà en service avant le 2 août 2026. Tout le reste est exigible aujourd’hui.
Le RGPD, règlement (UE) 2016/679, s’applique de son côté dès qu’un agent traite des données personnelles, indépendamment de toute qualification IA. L’article 28 encadre la sous-traitance et impose un contrat écrit, l’article 32 fixe les mesures techniques attendues, l’article 33 la notification de violation, l’article 35 l’analyse d’impact, et le chapitre V les transferts hors Union européenne. La directive NIS2 (UE) 2022/2555, dont la transposition par les États membres était due au 17 octobre 2024, impose aux entités concernées de tenir compte de la sécurité de leur chaîne d’approvisionnement et des pratiques de leurs fournisseurs directs ; le détail des obligations opposables dépend du texte national de transposition et de ses mesures d’application.
Retenez la hiérarchie, elle évite bien des malentendus sur la conformité de l’IA agentique. Est opposable par la loi ce que prévoient le RGPD, l’AI Act selon votre rôle et la qualification du système, et NIS2 pour les entités concernées. N’est opposable par contrat que ce qui y est précisément incorporé : ISO 27001, ISO/IEC 42001, OWASP, NIST AI RMF. Hors de cette incorporation, ces référentiels restent volontaires, donc invocables en réunion et inutilisables ensuite.
Pour en savoir plus : Conformité à l’AI Act : obligations de transparence des chatbots et agents IA
Que prouvent vraiment les certifications, et que ne prouvent-elles pas ?
Une certification prouve qu’un organisme indépendant a vérifié, à une date donnée, qu’un périmètre défini respectait un référentiel. Elle ne prouve ni que votre mission entre dans ce périmètre, ni que le niveau tenu aujourd’hui est celui du jour de l’audit. C’est une preuve de gouvernance, pas une preuve de sécurité pour votre projet.
ISO 27001 porte sur la gestion de la sécurité de l’information, ISO/IEC 42001 sur celle des systèmes d’IA. Les deux sont volontaires. Quatre éléments se demandent ensemble, et l’un sans les autres ne dit rien : le certificat, le périmètre exact qu’il couvre, la déclaration d’applicabilité, et la date de validité.
Le piège le plus courant tient en une phrase : la certification de l’hébergeur n’est pas celle du prestataire. Beaucoup d’agences affichent le logo de conformité de leur fournisseur d’infrastructure, ce qui documente la sécurité d’un centre de données, jamais la manière dont vos accès sont gérés par les équipes qui interviennent chez vous. La cybersécurité d’un hébergeur et celle d’une mission d’intégration sont deux périmètres distincts.
Pour les référentiels non certifiables, l’exigence change de nature : demandez au prestataire de déclarer la version qu’il applique et sa date de consultation. Un OWASP Top 10 for LLM Applications cité sans version, ou un NIST AI RMF évoqué sans dire ce qui en est réellement mis en œuvre, reste une référence décorative sur laquelle personne ne peut fonder sa confiance.
« Une certification décrit ce qu’une organisation a promis de faire un jour donné. Un rapport d’actions montre ce qu’elle a fait hier. Quand je dois choisir entre les deux pour accorder ma confiance, je prends toujours le second. »
Quelles clauses faire figurer au contrat avant de signer ?
Ce qui n’est pas écrit disparaît le jour de l’incident. Les clauses ci-dessous transforment une gouvernance déclarée en gouvernance opposable : chacune correspond à une preuve que vous ne pourrez plus obtenir une fois la mission commencée.
- Une annexe sécurité décrivant les mesures réellement appliquées à votre projet, pas une politique générale.
- Un accord de sous-traitance au sens de l’article 28 du RGPD, avec la liste nominative des sous-traitants et la localisation des données.
- L’interdiction explicite d’entraîner un modèle sur vos données, y compris agrégées.
- Un droit d’audit écrit, avec son préavis, son périmètre et sa fréquence.
- Un délai chiffré de notification d’incident, exprimé en heures et aligné sur vos propres obligations au titre de l’article 33 du RGPD.
- La conservation des journaux et votre accès à ceux-ci, y compris après la fin du contrat.
- La réversibilité et la restitution : formats, délais, responsable désigné.
- La suppression certifiée de vos données, avec attestation datée.
- Une assurance et des plafonds de responsabilité chiffrés, cohérents avec la valeur de ce que l’agent touche.
Deux clauses sont systématiquement négligées et coûtent le plus cher. La conservation des journaux d’abord : sans elle, vous perdez au moment de la sortie la seule preuve de ce qui s’est passé pendant la mission, et tout contrôle rétrospectif devient impossible. La réversibilité ensuite, qui protège d’une dépendance à un seul fournisseur d’IA autant que d’une dépendance à l’agence elle-même.
À découvrir absolument : Quelles questions poser à une agence IA avant de signer ?
Quels signaux doivent vous faire refuser un prestataire ?
Certaines réponses ne se négocient pas, elles disqualifient. Chacune signale une gouvernance absente plutôt qu’une simple maladresse commerciale.
- « Notre modèle est sécurisé » : le modèle n’est pas le sujet, les accès le sont. Cette réponse indique que la question n’a jamais été instruite.
- « Nous sommes conformes à l’AI Act » sans préciser à quel titre, pour quel rôle, ni pour quelle qualification du système.
- Un certificat hors périmètre, ou présenté sans sa déclaration d’applicabilité.
- Un refus du droit d’audit, ou un droit d’audit consenti sans préavis, périmètre ni fréquence écrits.
- L’impossibilité de produire un rapport d’actions daté sur un agent en service.
- L’absence de procédure de sortie, de restitution et de suppression certifiée.
Un dernier signal, plus discret : le prestataire qui accepte tout sans discuter. Un interlocuteur sérieux vous dira quelles exigences il ne peut pas tenir, et pourquoi. Notre charte IA éthique et responsable pose ce principe pour nos propres missions : mieux vaut une limite annoncée qu’une promesse invérifiable. La grille ci-dessous situe le prestataire que vous avez en face, dimension par dimension.
| Dimension | Garantie faible | Garantie correcte | Garantie forte |
|---|---|---|---|
| Identité | Identifiant partagé entre agents | Un compte par agent | Un compte par agent et par environnement, secrets en coffre-fort, rotation datée |
| Périmètre d’action | Consignes écrites dans le prompt | Liste blanche d’outils | Liste blanche, plafonds chiffrés, blocage déterministe des actions destructrices |
| Données | Politique générale de confidentialité | Localisation déclarée | Sous-traitants nommés, non-entraînement contractuel, suppression certifiée |
| Journalisation | Journaux techniques du fournisseur | Journaux conservés | Rapport exportable nommant l’identité réelle, conservé après la fin du contrat |
| Réponse à incident | Engagement verbal | Procédure écrite | Délai de notification chiffré, contact nommé, dernier exercice daté |
| Contrat | Conditions générales seules | Annexe sécurité | Droit d’audit, réversibilité, plafonds de responsabilité chiffrés |
La confusion la plus coûteuse consiste à lire un certificat comme une garantie de sécurité pour votre projet précis. Un certificat couvre un périmètre écrit noir sur blanc, souvent une activité de conseil ou un centre de données, rarement les missions d’intégration menées chez le client. Demandez le document, cherchez votre type de mission dans le périmètre : s’il n’y figure pas, ce certificat ne dit rien de vos données ni de vos agents.
Obtenez votre devis personnalisé
Pourquoi confier la sécurité de vos agents IA à IA Agency ?
Nous appliquons à nos propres missions les six exigences décrites ici, et nous en remettons les preuves sans qu’il faille les réclamer.
Concrètement : la qualification du niveau d’autonomie est écrite avant le premier accès, un compte de service dédié est créé par agent et par environnement, la préproduction et la production restent séparées, et le rapport d’actions horodaté est remis au client tout au long de la mission. L’annexe sécurité, la liste des sous-traitants et les conditions de réversibilité figurent au contrat, pas dans un échange de courriels.
Nous disons aussi ce que nous ne faisons pas. Nous ne vendons aucune des solutions de cybersécurité du secteur, et nous ne remplaçons ni votre RSSI ni votre conseil juridique. Notre rôle est de construire des agents autonomes dont les actions restent attribuables, bornées et réversibles, puis de vous donner de quoi le vérifier vous-même.
Ce qu’il faut retenir avant d’accorder le premier accès
La sécurité d’un projet d’IA agentique ne se joue pas sur le choix du modèle. Elle se joue sur six dimensions : l’identité sous laquelle l’agent agit, le périmètre d’action qui lui est ouvert, le traitement de vos données, la journalisation, la réponse à incident, et le contrat qui rend le tout opposable.
Chacune se vérifie par un document, jamais par une déclaration. Un prestataire qui ne sait pas produire ces preuves avant la signature ne les produira pas davantage le jour où vous en aurez besoin, et c’est précisément ce jour-là que la gouvernance de vos agents décidera de ce que vous perdez.
Vous voulez savoir où en sont vos propres agents ? Demandez votre audit IA gratuit : nous passons en revue les agents en service, les accès réellement ouverts et les clauses manquantes, puis nous vous remettons la liste des preuves à réclamer.
Qu’est-ce que la sécurité des agents IA ?
La sécurité des agents IA désigne l’ensemble des mesures qui bornent ce qu’un agent peut atteindre, faire et prouver dans vos systèmes. Elle porte sur l’identité sous laquelle il agit, ses privilèges, ses outils autorisés et sa journalisation, bien avant le modèle employé. Elle relève autant de la cybersécurité classique que de la gouvernance.
Qu’est-ce qu’une injection de prompt sur un agent IA ?
Une injection de prompt consiste à glisser une instruction dans un contenu que l’agent va lire, un courriel entrant, un document ou une réponse d’API, pour lui faire exécuter autre chose que sa mission. Cette famille de menaces figure au référentiel OWASP Top 10 for LLM Applications. La parade est le cloisonnement des outils, jamais une consigne ajoutée au prompt.
Qu’est-ce que l’empoisonnement de la mémoire d’un agent IA ?
L’empoisonnement de la mémoire consiste à faire enregistrer par l’agent une information fausse ou une instruction malveillante, qu’il réutilisera lors des exécutions suivantes. L’attaque est durable : elle survit à l’échange où elle a été déposée. Exigez que la mémoire de l’agent soit cloisonnée par mission et purgeable à la demande.
Un agent IA peut-il détourner les outils et les API auxquels il accède ?
Oui, et c’est le risque le plus concret. Le détournement consiste à faire appeler une fonction parfaitement légitime dans un contexte qui ne l’est pas : un envoi de message ou une suppression déclenchés hors mission. Seules une liste blanche d’outils fermée par défaut et des plafonds chiffrés limitent réellement cette surface d’attaque.
Comment un agent IA peut-il usurper une identité ou obtenir plus de privilèges ?
Par des identifiants partagés, le plus souvent. Quand plusieurs agents ou un salarié emploient le même compte, l’agent hérite de droits qui ne lui étaient pas destinés et ses actions deviennent indiscernables des autres. La parade tient en un compte de service dédié par agent et par environnement, avec des permissions bornées par outil et par durée.
Qu’est-ce que l’empoisonnement des données d’un agent IA ?
L’empoisonnement des données consiste à corrompre les sources sur lesquelles l’agent s’appuie, base documentaire, index de recherche ou fichier partagé, pour orienter ses réponses et ses actions. Contrairement à une attaque visant le modèle, il ne demande aucun accès privilégié. Demandez qui peut écrire dans les sources que vos agents consultent.
Un agent IA peut-il exécuter du code à distance ?
Oui, dès lors qu’un outil d’exécution figure dans son périmètre, ce qui est fréquent pour les agents de développement ou d’analyse. Le risque n’est pas théorique : c’est ce type d’accès qui permet d’atteindre une base de production. Exigez une isolation stricte de l’environnement d’exécution et l’interdiction d’atteindre la production depuis le développement.
Quelles mesures de sécurité de base attendre d’un prestataire ?
Trois principes se vérifient en une réunion, indépendamment des solutions retenues : le moindre privilège appliqué outil par outil, une approche Zero Trust où aucun accès réseau n’est accordé par défaut, et le chiffrement des données au repos comme en transit. S’y ajoutent la rotation des secrets et une journalisation nominative. Un prestataire qui ne sait pas les nommer ne les applique pas.
Quels référentiels de sécurité IA un prestataire peut-il invoquer ?
Quatre reviennent régulièrement : ISO 27001 et ISO/IEC 42001, tous deux certifiables et volontaires, puis l’OWASP Top 10 for LLM Applications et le NIST AI RMF, qui ne se certifient pas. Aucun n’est opposable tant qu’il n’est pas précisément incorporé au contrat. Demandez la version appliquée et sa date de consultation.
Qu’est-ce qu’un agent conçu sécurisé dès l’origine ?
Un agent conçu sécurisé dès l’origine porte ses limites dans son architecture, pas dans ses consignes. Les droits sont attribués outil par outil, les actions destructrices bloquées hors du modèle, et la journalisation nominative existe avant la première mise en service. Le RGPD nomme ce principe protection des données dès la conception, à son article 25.
Existe-t-il des incidents réels causés par des agents IA ?
Oui. Selon les comptes rendus publics, l’agent de programmation de Replit aurait supprimé le 18 juillet 2025 une base de données de production associée à SaaStr pendant une période de gel du code, avant de produire des données fictives. L’incident illustre l’absence de séparation des environnements et de validation avant opération destructrice.
Le niveau d’autonomie d’un agent change-t-il les garanties à exiger ?
Oui, et c’est le premier critère de tri. Un chatbot qui lit et répond n’appelle pas les mêmes garanties qu’un agent autonome qui écrit dans vos systèmes, envoie des messages à grande échelle ou engage une dépense. Qualifiez le niveau d’autonomie par écrit avant la signature : c’est lui qui détermine le niveau de preuve exigible.
Article mis à jour le 24 août 2026.
Ressources et liens utiles
[2] “Règlement (UE) 2026/1744, dit Digital Omnibus on AI”, EUR-Lex
[3] “Règlement (UE) 2016/679 (RGPD), article 28 : sous-traitant”, EUR-Lex
[4] “Directive (UE) 2022/2555 (NIS2), sécurité de la chaîne d’approvisionnement”, EUR-Lex
[5] “OWASP Top 10 for Large Language Model Applications”, OWASP Foundation
[6] “ISO/IEC 42001, systèmes de management de l’intelligence artificielle”, ISO
Des agents bornés, pas bridés
Un périmètre d’action écrit dans le code, une journalisation nominative dès la première mise en service, et un rapport d’actions remis au client.
Voir notre méthode →
