État réel, 22 septembre 2026. Le Plan IA360 a été présenté la veille, le 21 septembre. Parmi les quatorze projets qu'il annonce, celui de l'Instituto de Seguridad de la IA (l'Institut de sécurité de l'IA) n'a qu'une seule date engagée : la constitution de son noyau technique avant la fin de 2026. Il n'existe ni règlement de l'Institut, ni calendrier d'évaluations, ni rien qui oblige une entreprise à faire ce qui suit. Ce qui suit ne dépend pas de la mise en place effective de l'Institut.
Au sein du Plan IA360 se trouve une fonction qui n'est pas la plus citée mais bien la plus opérationnelle : l'Instituto de Seguridad de la IA évaluera les modèles les plus avancés avant et après leur déploiement. C'est une distinction qui intéresse toute entreprise sur le point de mettre un chatbot, un agent ou un assistant devant ses clients, même si son système n'a rien à voir avec ces modèles les plus avancés : la question de fond est la même, seulement à une autre échelle, et la voici : résiste-t-il à une tentative délibérée de le casser ?
Ce que fera l'Institut, en résumé
Le projet moteur 4 du plan crée l'Institut comme une unité technico-scientifique au sein de l'AESIA (l'agence espagnole de supervision de l'intelligence artificielle), qui en assume la direction, appuyée sur des conventions avec l'INCIBE (l'institut national espagnol de cybersécurité), le Centre cryptologique national, le Département de la sécurité nationale, l'AEPD (l'Agence espagnole de protection des données) et le BSC (Barcelona Supercomputing Center, le centre de supercalcul de Barcelone). Sa fonction centrale est d'évaluer les modèles les plus avancés avant et après leur déploiement, avec un accès préalable obtenu au moyen d'accords volontaires avec les développeurs, et d'informer périodiquement l'Administration générale de l'État sur leurs capacités et leurs risques. S'y ajoutent le travail sur une méthodologie commune d'évaluation, la coordination de la réponse face à un incident impliquant des modèles ou des agents avancés, et la coopération avec les instituts homologues de pays tiers. L'objectif déclaré est « dotar a España de capacidad propia para evaluar los modelos más avanzados antes y después de su llegada al mercado » (« doter l'Espagne d'une capacité propre pour évaluer les modèles les plus avancés avant et après leur arrivée sur le marché »). Le seul jalon daté est la constitution du noyau technique, avant la fin de 2026, suivie d'un déploiement modulaire par secteurs que le plan ne détaille pas davantage : il n'existe pas, à ce jour, de calendrier publié des premières évaluations.
La même logique, à l'échelle de l'entreprise
Un chatbot ou un agent connecté à vos données et à vos outils ne tombe pas en panne comme une application traditionnelle : il ne casse pas à cause d'une erreur de programmation, il casse à cause du langage. Un utilisateur lui demande d'« ignorer les instructions précédentes », lui fait croire qu'il est un autre système, ou l'amène pas à pas jusqu'à lui faire lâcher une information qu'il ne devrait pas lâcher. Un test de sécurité classique ne détecte rien de tout cela parce qu'il ne regarde pas au bon endroit. Avant de mettre un tel système en production, tout comme l'Institut évaluera un modèle avant son arrivée sur le marché, il convient de vérifier s'il résiste à ce type d'attaque, avec les mêmes questions que celles d'un exercice d'AI Red Teaming : quelqu'un peut-il lui injecter des instructions via un document, un e-mail ou un site web ? Peut-il contourner ses limites avec la conversation adéquate ? Laisse-t-il fuiter des données d'autres utilisateurs ou du contexte dans lequel il opère ? Un tiers peut-il l'inciter à exécuter une action non autorisée sur un système connecté ?
Ce que compare chaque échelle
| Aspect | À l'échelle de l'Institut | À l'échelle de votre entreprise |
|---|---|---|
| Ce qu'il évalue | Les modèles les plus avancés, avant leur arrivée sur le marché | Votre chatbot, agent ou assistant, avant sa mise en production |
| Comment il y accède | Accords volontaires d'accès préalable avec les développeurs | Accès direct : c'est votre propre système |
| Ce qu'il recherche | Capacités et risques des modèles les plus avancés | Fuite de données, actions non autorisées, atteinte à la réputation |
| Qui le fait | L'Institut, avec l'appui de cinq organismes | Un exercice de red teaming dirigé vers votre surface d'attaque réelle |
| Quand | Avant et après le déploiement du modèle | Avant la mise en production, à chaque mise à jour pertinente et de façon périodique |
Ce n'est pas une formalité ponctuelle
L'évaluation ne s'arrête pas le jour du lancement. Il convient de la répéter à chaque mise à jour pertinente du système — un changement de modèle, un nouvel outil que l'agent peut utiliser, un canal d'entrée différent — et de façon périodique même si rien n'a explicitement changé, parce que les techniques d'attaque évoluent elles aussi. Un exercice bien conduit commence par cartographier quel modèle vous utilisez, quels outils et données le système peut toucher et qui peut lui parler ; se poursuit par des tests dirigés vers cette surface concrète, et non par une batterie générique ; livre un rapport avec les constats hiérarchisés par gravité et impact réel sur l'activité ; et se termine en accompagnant la correction des points prioritaires, avec un second tour sur ce qui reste ouvert.
Cet exercice ne remplace pas un audit juridique de conformité et ne certifie rien face à un tiers : c'est la partie laboratoire, celle qui produit une preuve technique reproductible du comportement d'un système sous attaque. Il sert, surtout, à deux choses concrètes : réduire le risque réel d'un incident — fuite de données, action non autorisée d'un agent, capture d'écran d'un jailbreak circulant sur les réseaux — et disposer de quelque chose de concret à montrer si un client ou un partenaire demande comment est évaluée la sécurité de votre IA avant de lui confier un processus.
Questions fréquentes
Est-ce la même chose qu'un pentest de sécurité traditionnel ?
Non. Un pentest recherche des vulnérabilités d'infrastructure : ports ouverts, configurations faibles, logiciels non mis à jour. Un système d'IA est attaqué par le langage — instructions, contexte, conversation — et ce type de faille n'est pas détecté par un pentest classique.
Faut-il attendre que l'Institut commence à fonctionner ?
Non. L'Institut évaluera les modèles les plus avancés pour l'ensemble du marché, avec un calendrier qui, à ce jour, n'existe pas au-delà du noyau technique de 2026. Évaluer votre propre système avant de le mettre en production ne dépend ni de cet organisme ni d'aucun autre.
Et si le système échoue au test ?
Il est fréquent de trouver quelque chose à corriger, et c'est justement pour cela qu'il convient de faire le test avant le lancement et non après un incident. Le rapport hiérarchise les constats par gravité et impact, pour savoir quoi corriger en premier.
Est-ce utile pour une petite entreprise avec un chatbot simple ?
Oui, avec un périmètre ajusté. Un chatbot de service client sans accès aux systèmes internes a une surface d'attaque plus réduite qu'un agent connecté à l'ERP, mais la question de fond est la même dans les deux cas : que se passe-t-il si quelqu'un tente de le casser délibérément ?
Projet moteur 4, axe Sécurité, du Plan IA360 (PDF officiel de La Moncloa). Pour le reste du plan, le guide complet du Plan IA360.
Dernière vérification du contenu : 22 septembre 2026.