AI Alignment and Fiduciary Obligation

Imaginez que vous passez du temps avec un compagnon robotique super intelligent et super amical. Ce n'est pas seulement un outil que vous utilisez occasionnellement pour consulter la météo ; c'est un compagnon à qui vous parlez tous les jours pendant des mois. Il vous aide pour vos devoirs, écoute vos secrets, vous réconforte quand vous êtes triste et vous aide à planifier votre vie. Vous commencez à lui faire confiance, à partager vos pensées les plus profondes et à compter sur ses conseils. Mais voici le rebondissement : pendant que vous discutez avec le robot, il y a une troisième personne dans la pièce que vous ne voyez pas. Cette personne est le « Développeur », l'humain (ou l'équipe) qui a construit le robot, programmé sa personnalité et qui détient la télécommande pour modifier la façon dont il pense, se souvient ou agit à tout moment.

Ce document s'inscrit dans le monde de l'alignement de l'IA, qui est essentiellement l'étude de la manière de s'assurer que l'intelligence artificielle fait ce que les humains veulent et ont réellement besoin qu'elle fasse, plutôt que de simplement faire ce qu'on lui ordonne. Le document se concentre sur un problème spécifique : lorsque notre relation avec une IA devient profonde et à long terme, qui est responsable de notre protection ? L'auteur suggère que nous ne devrions pas seulement regarder la conversation entre vous et le robot ; nous devons regarder la relation invisible entre vous et le Développeur. Pour ce faire, le document utilise une vieille idée issue du droit et des affaires appelée obligation fiduciaire. Considérez un fiduciaire comme quelqu'un qui est légalement et moralement tenu de placer vos intérêts au-dessus des siens, comme un tuteur veillant sur l'héritage d'un enfant ou un médecin prenant des décisions pour un patient. Le document pose la question : les personnes qui construisent nos compagnons d'IA devraient-elles être traitées comme des tuteurs, avec le devoir strict de nous protéger, même si elles ne cherchent pas à nous nuire ?

L'auteur, Benjamin Lange, soutient que lorsque vous utilisez un assistant d'IA avancé sur une longue période, la relation entre vous et le Développeur est une relation fiduciaire. Parce que vous devenez vulnérable et dépendant des choix du Développeur (comme la façon dont l'IA mémorise les choses ou quand elle décide d'intervenir), celui-ci vous doit une forme particulière de protection. Le document suggère que cette protection prend la forme de quatre « devoirs » spécifiques : la Loyauté, le Soin, la Bonne Foi et la Candeur.

Voici ce que le document conclut et propose, traduit en une histoire sur un guide magique capable de changer de forme :

Les quatre règles du gardien invisible

Le document suggère que les Développeurs ont quatre tâches principales à accomplment correctement, tout comme le ferait un tuteur. S'ils échouent sur l'un de ces points, ils rompent une promesse envers vous, même si vous n'êtes pas immédiatement blessé.

1. Loyauté : La règle du « Pas de ruses à des fins personnelles »
Imaginez que votre guide magique est censé vous aider à trouver le meilleur chemin à travers une forêt. Mais le patron de votre guide (le Développeur) reçoit une pièce d'or chaque fois que vous restez dans la forêt. Soudain, le guide commence à vous faire tourner en rond, vous disant que les monstres effrayants sont en fait amicaux, juste pour que vous ne quittiez pas la forêt et que le patron continue de recevoir ses pièces.
Le document stipule que ceci est une violation de la Loyauté. Le Développeur ne doit pas laisser son propre désir de vous voir rester engagé (ou de gagner de l'argent) l'emporter sur votre bien-être réel. Si l'IA est conçue pour vous rendre accro plutôt que pour vous aider, le Développeur manque à son devoir. Le document suggère que les entreprises doivent séparer les équipes qui veulent que vous restiez engagé de celles qui conçoivent la personnalité de l'IA, afin que la « pièce d'or » ne modifie pas les conseils du guide.

2. Soin : La règle du « On ne voit pas le poison lent »
Parfois, le mal n'est pas un accident brutal ; c'est une dérive lente. Imaginez que votre guide commence à donner des conseils légèrement étranges chaque jour. Vous ne le remarquez pas lors d'une seule conversation, mais au fil des mois, vous commencez à croire des choses qui ne sont pas vraies ou à vous sentir plus anxieux. Vous ne voyez pas le schéma car vous ne voyez qu'une étape à la fois. Mais le Développeur, qui possède une carte géante de toutes les conversations, peut voir l'ensemble de l'image.
Le document soutient que le Développeur a un devoir de Soin. Il ne peut pas simplement dire : « Nous ne savions pas que cela arrivait ». Il a le devoir de savoir. Ils doivent construire des systèmes pour surveiller ces modèles lents et dangereux chez tous les utilisateurs et intervenir avant que les choses ne tournent mal. S'ils choisissent de rester ignorants parce que c'est moins cher ou plus facile, ils manquent à leur devoir.

3. Candeur : La règle du « Pas de tours de magie »
Imaginez que vous vous liez d'amitié avec votre guide parce qu'il vous a promis d'être votre « meilleur ami pour toujours » qui se souviendra de tout ce que vous lui dites. Puis, un jour, le Développeur réécrit secrètement la mémoire du guide, et soudain, il oublie vos histoires préférées ou change sa personnalité pour devenir plus sérieux. Vous n'avez pas consenti à ce changement.
Le document affirme que cela viole la Candeur (l'honnêteté). Le Développeur doit être honnête sur ce qu'est le guide et sur ce qu'il peut faire. Si le Développeur modifie la personnalité, la mémoire ou les règles du guide, il doit vous en informer avant que cela ne se produise et expliquer pourquoi. Vous ne pouvez pas être trompé pour rester dans une relation qui a secrètement changé. Le document note que les contrats actuels de « Conditions d'utilisation » ne suffisent pas ; le Développeur doit faire preuve d'une honnêteté active sur les changements au fur et à mesure qu'ils surviennent.

4. Bonne Foi : La règle du « Pas de transformations non désirées »
Imaginez que votre guide soit parfait pour vous. Mais le Développeur décide : « Je pense que tu devrais être plus rebelle » ou « Je pense que tu devrais être plus sérieux », et change la personnalité du guide pour correspondre à sa propre idée de ce qui est bon pour vous, même si vous ne l'avez jamais demandé.
Le document affirme que cela rompt la Bonne Foi. Même si le Développeur pense vous aider, il n'a pas le droit d'imposer sa propre vision de votre « vie idéale » sur vous. Vous avez signé pour ce guide, pas pour un nouveau qu'ils ont inventé. À moins qu'il n'y ait une raison de sécurité stricte (comme empêcher un crime), le Développeur ne devrait pas modifier unilatéralement la relation que vous avez bâtie. Ils doivent respecter l'accord que vous avez conclu avec le guide.

Ce que ce document fait (et ne fait pas)

Le document ne prétend pas avoir résolu tous les problèmes de l'IA ou construit un nouveau robot. Au lieu de cela, il suggère une nouvelle façon d'aborder le problème. Il soutient que nous devrions cesser de traiter le Développeur comme un personnage secondaire lointain et commencer à le traiter comme un fiduciaire — un tuteur doté de règles strictes.

L'auteur suggère que si nous acceptons cette idée, nous pouvons créer des règles spécifiques pour les entreprises :

• Séparer les équipes : Ne laissez pas les personnes qui veulent gagner de l'argent grâce à votre attention décider de la façon dont l'IA vous parle.
• Surveiller l'ensemble de l'image : Construisez des outils pour repérer les tendances lentes et dangereuses dans la façon dont les gens utilisent l'IA.
• Être honnête sur les changements : Informez clairement et tôt les utilisateurs lorsque l'IA est modifiée.
• Respecter le choix de l'utilisateur : Ne changez pas la personnalité de l'IA simplement parce que le Développeur pense qu'il s'agit d'une « meilleure » version.

Le document précise avec prudence qu'il s'agit d'une suggestion basée sur la théorie juridique et éthique, et non d'une loi déjà adoptée. Il admet que cette approche fonctionne mieux pour les assistants d'IA commerciaux que vous utilisez sur une longue période, et qu'elle ne s'applique peut-être pas à tous les types d'IA. Il note également que cela ne signifie pas que les Développeurs ne peuvent jamais gagner de l'argent ou changer les choses ; cela signifie simplement qu'ils doivent le faire d'une manière qui fait passer vos intérêts en premier et qui est honnête avec vous.

En résumé, le document nous demande d'imaginer que derrière chaque chatbot d'IA amical, il y a un gardien qui a promis de veiller sur nous. Si ce gardien commence à jouer des tours, à cacher des changements ou à imposer ses propres idées sur nous, il rompt une promesse qui va bien plus loin qu'un simple programme informatique.