La question des données, avant tout
Agents at Work — CC BY 4.0Il existe une habitude qui, plus que tout autre élément de ce cours, vous évitera bien des ennuis, et elle doit être appliquée dès le tout début de la création d’un agent, et non à la fin. Avant de réfléchir à ce que l’agent va faire, demandez-vous ce qu’il va toucher: quelles données sont en jeu, où vont-elles, et qui peut y accéder une fois qu’elles ne sont plus entre vos mains ? C’est là tout l’enjeu du Pilier 3 — à qui appartiennent les données, et à qui revient la décision — et c’est la seule habitude qui m’a épargné le plus de soucis.
Vous connaissez déjà cette question grâce à « Travailler avec Claude » — la question de la garde, posée avant de coller quoi que ce soit dans un chatbot. Les agents lui donnent encore plus d’importance, pour deux raisons.
Pourquoi un agent fait monter les enches
Premièrement, un agent ne voit pas seulement ce que vous lui remettez. Connectez-le à vos systèmes — le disque partagé, la boîte de réception, la base de données clients — et il peut accéder aux données de lui-même, bien au-delà de ce que vous pourriez jamais coller à la main. Tout ce que vous connectez constitue le rayon d’action.
Deuxièmement, il agit sans surveillance. Lorsque vous collez un CV dans un assistant, au moins vous êtes là. Un agent qui trie les candidatures pendant la nuit manipule les informations personnelles d’autres personnes alors que personne ne regarde. La question de la responsabilité cesse d’être une vérification ponctuelle au clavier et devient une caractéristique de l’ensemble du système : à quoi cet outil a-t-il accès, que transmet-il, et où cela aboutit-il ?
Ce que dit réellement la loi (Nouvelle-Zélande)
Pas besoin d’être juriste, mais trois points de la loi sur la protection de la vie privée vont changer votre façon de développer :
- La consigne compte. Le commissaire à la protection de la vie privée a clairement indiqué que votre obligation de sécurité s’étend aux informations que vous saisissez dans un outil d’IA. Saisir les coordonnées d’un client ou d’un candidat dans un LLM public — susceptible de conserver ces données ou de s’en servir pour son apprentissage — n’est pas une zone d’ombre ; c’est précisément ce que vise le principe de sécurité. (C’est pourquoi « on a juste collé les CV dans ChatGPT » est la phrase qui devrait faire sauter le recruteur.)
- Ne collectez que ce qui est nécessaire. Vous ne devriez pas fournir à un agent des informations d’identification dont la tâche n’a pas besoin. Si la tâche consiste à « trier par compétences », elle n’a pas besoin du nom, de la photo ou de la date de naissance.
- La destination de ces données a son importance. Transmettre des informations personnelles à un autre service — en particulier à l’étranger — peut constituer une divulgation pour laquelle vous devez justifier d’une raison valable. La question de savoir si une configuration donnée franchit cette ligne est véritablement un terrain glissant, et c’est précisément pour cela que vous devez en décider avant d’activer l’agent, et non après.
Il s’agit ici d’informations générales, et non de conseils juridiques — mais le principe est simple : la question des données est une question juridique, et pas seulement une question de courtoisie.
Remarque concernant les données Māori
Si votre agent est amené à traiter des informations concernant des personnes Māori, whānau, hapū ou iwi, considérez cela comme nécessitant une concertation, et non une décision unilatérale. La souveraineté des données Māori — le principe selon lequel les données Māori relèvent de la la gouvernance Māori — est une obligation en vigueur, et ce sont les personnes auxquelles elles appartiennent qui sont seules à décider de ce qui constitue une utilisation appropriée. Un agent qui récupère discrètement ces données pendant la nuit est précisément le genre de décision qui ne devrait pas être prise par défaut.
La discipline
Avant de connecter un agent à quoi que ce soit ou de le diriger vers une pile de fichiers, notez trois lignes :
- À qui appartiennent cesdonnées — à moi, ou à quelqu’un qui me les a confiées ?
- Où vont-elles une fois que l’agent les a récupérées — quels services, quelle infrastructure, quelles lois ?
- Qu’est-ce qui me rassurerait: les anonymiser, les conserver sur des outils que je contrôle, ou tout simplement ne pas transmettre ces données en particulier ?
Si vous ne pouvez pas répondre à ces questions, vous n’êtes pas prêt à développer l’agent — vous êtes prêt à avoir la discussion qui déterminera si vous devriez le faire.
Imaginez le premier agent que vous construiriez réellement. Dressez la liste de tous les endroits auxquels il devrait avoir accès. Maintenant : lesquels d’entre eux contiennent les informations d’autres personnes— et de qui auriez-vous besoin d’obtenir l’autorisation avant qu’un agent puisse les lire sans surveillance ?
Où cela mène-t-il ?
La sixième question du triage — « à qui appartiennent les données, à qui revient la décision ? » — s’avère être le pivot autour duquel s’articule tout le cours. C’est pourquoi le Recruteur est notre cas le plus marquant, pourquoi le principe « d’indifférence à l’identité » est un principe de conception du niveau 2, et pourquoi certaines tâches restent du ressort de l’humain, quelle que soit l’ingéniosité des outils. Le niveau 1 portait sur la prise de décision. Ensuite, au niveau 2, nous commençons à concevoir : définir le périmètre d’action d’un agent afin qu’il ne puisse accéder qu’à ce qu’il doit, et mettre en place le point de contrôle où une personne prend la décision.
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.
Laisser un koha →