L’option souveraine — sur quel ordinateur, selon quelles lois
Agents at Work — CC BY 4.0Vous avez créé un agent. Voici une question que le développeur ne vous a jamais posée : sur quel ordinateur fonctionne-t-il réellement, et à quelles lois vos données sont-elles soumises lorsqu’elles s’y trouvent ?
Pour la plupart des gens, la réponse honnête est « celle d’une très grande entreprise, située dans un autre pays, et soumise aux lois de ce pays » — et ils n’y ont jamais réfléchi, car l’outil fonctionne, tout simplement. Cette leçon a pour but de vous faire y réfléchir, car pour certaines tâches effectuées par un agent, la réponse influe sur ce que vous devriez créer.
Le compromis, dit franchement
Il y a ici un véritable compromis, et prétendre le contraire n’aide personne.
- Un outil public de pointe — les grands modèles hébergés aux États-Unis — est, à l’heure actuelle, généralement l’option la plus performante. C’est aussi celle où vos données échappent à votre contrôle : elles reposent sur une infrastructure appartenant à une entreprise soumise à la juridiction d’un autre pays. En vertu de la loi américaine CLOUD , les autorités américaines peuvent accéder aux données détenues par des fournisseurs américains, quel que soit l’endroit où elles se trouvent physiquement dans le monde. Pour la plupart des tâches courantes, ce compromis est acceptable et vous l’accepteriez en toute connaissance de cause.
- Une option souveraine — un modèle fonctionnant sur votre propre machine, ou sur une infrastructure hébergée en Nouvelle-Zélande ou dans l’UE que vous contrôlez — vous permet de garder la garde de vos données. Vos données restent sous votre contrôle et relèvent de votre législation. Le coût est réel lui aussi : cette solution peut être moins performante, plus fastidieuse à mettre en place, et elle n’aura pas le raffinement des grands outils publics.
Aucune des deux n’est « la bonne réponse ». L’important est de faire ce choix en toute connaissance de cause, en fonction de ce que l’agent manipule — ce qui correspond au Pilier 3 : les avantages de l’IA à la base, appliqués à l’infrastructure plutôt qu’aux instructions.
Quand la garde doit l’emporter
Revenez à la question des données du niveau 1. Plus l’agent traite d’informations personnelles d’autrui — candidats, patients, membres, whānau — plus l’aspect « garde » de la décision prend de l’importance. « C’est plus pratique sur l’outil public » est une réponse peu convaincante lorsque ce que vous lui fournissez est une pile de vies d’autres personnes, conservées en confiance.
C’est également là que l’obligation te Tiriti cesse d’être abstraite. Si un agent venait à traiter des informations concernant ou appartenant à Māori — des individus, whānau, hapū, iwi —, la question de savoir à qui appartiennent l’infrastructure et la gouvernance n’est pas une simple note de bas de page technique ; c’est une obligation de souveraineté des données (le niveau 4 aborde cela de manière appropriée). Un agent envoyant discrètement ces données à l’étranger vers un modèle public est précisément le genre de décision qui ne devrait pas être prise par défaut.
Le même schéma, une base différente
La bonne nouvelle, c’est que rien de ce que vous avez appris ne change. Le modèle de construction de la dernière leçon — périmètre, critères, garde-fous, test — est identique, que le modèle s’exécute sur un outil public ou sur une infrastructure souveraine. La conception de l’agent ne tient pas compte de l’endroit où l’inférence a lieu. Ainsi, l’option souveraine ne nécessite pas de compétences différentes ; il s’agit du même agent, ancré dans un environnement que vous contrôlez.
C’est la direction vers laquelle tend notre propre travail — le Village existe pour être l’extrémité souveraine de ce spectre : le même type d’agent, fonctionnant sur une infrastructure relevant de la juridiction néo-zélandaise et européenne plutôt que à l’étranger. Il faut reconnaître que cette extrémité du spectre est plus récente et moins aboutie que les outils publics bien rodés ; la démo est un point de départ, pas un produit fini. Mais sa raison d’être réside précisément dans cette leçon : pour que « garder la garde » ne signifie pas nécessairement « se passer d’agent ».
La démarche de développement
Pour l’agent que vous allez développer, posez-vous la question que l’outil ne pose jamais :
- À quoi touche-t-il —à mes données, ouà celles d’autres personnes détenues en fiducie ?
- Où l’inférence a-t-elle lieu — sur quel ordinateur, sous quelle juridiction ?
- La sensibilité des données justifie-t-elle le compromis entre fonctionnalités — « public et performant » ou « souverain et sous mon contrôle » ?
Parfois, la réponse est l’outil public, choisi en toute connaissance de cause. Parfois, c’est une infrastructure souveraine, car la sécurité de la conservation prime sur le raffinement pour ces données. La mauvaise réponse est celle que vous n’avez jamais réellement formulée.
Prenons l’exemple de l’agent que vous construiriez. Si ses données étaient soudainement soumises aux lois d’un autre pays dès demain — visibles par les autorités de ce pays, selon leurs règles — cela vous dérangerait-il ? Votre réponse vous indique à quelle extrémité du spectre se situe cet agent en particulier.
Suivant
Niveau 4 : mettre l’agent en service, le surveiller pendant son exécution, la loi à laquelle vous êtes réellement soumis, et les obligations que vous avez envers les personnes qui se trouvent de l’autre côté.
Partagé librement, en toute bonne foi. Si cela vous a été utile, un koha destiné à couvrir les coûts de développement et de fonctionnement est le bienvenu.
Laissez un koha →