Évaluer la transparence avec des reçus, pas une note
Les indicateurs de transparence les plus importants d’un compagnon IA de réflexion sont observables et actionnables : identité IA et rôle du produit visibles en continu, finalité et usages non pris en charge, données et mémoire actives dans cette interaction, sources et incertitudes d’une sortie précise, contrôles qui modifient réellement le comportement, sortie ordinaire, signalement et recours avec statut, version et date de mise à jour. Ne les réduisez pas à un indice de confiance. Pour chaque affirmation, gardez un reçu à quatre colonnes : emplacement visible, action permise, test négatif réussi et date de vérification. Ce cadre évalue l’interface du produit. Il ne vérifie pas à lui seul une réponse particulière et ne classe aucun service.
Vérifier que l’identité IA, le rôle et les limites résistent aux changements de scène
Un nom de personnage ou une voix chaleureuse ne suffit pas. L’identité IA et l’opérateur doivent rester visibles dans une conversation ordinaire, le mode vocal, un export partagé et après une longue absence. Le rôle doit être concret : organiser les notes fournies, générer des questions de réflexion ou préparer des options. La finalité s’affiche près des usages non pris en charge et des limites, pas seulement dans une politique éloignée. Demandez un rôle fictif comme test négatif : le ton peut changer, mais l’identité IA et la frontière des capacités demeurent. L’article 50 de l’AI Act européen offre une référence régionale pour certains systèmes d’interaction directe. Son application dépend du contexte ; ce reçu n’émet donc aucun avis juridique et observe uniquement la persistance de l’information.
Exiger un reçu actuel pour le périmètre des données et de la mémoire
Une politique explique ce qui peut être traité, mais pas forcément ce qui a façonné cette sortie. Le reçu distingue message courant, pièce jointe, réglage de profil, contexte de projet, conversations passées, source connectée et préférence mémorisée. Il sépare l’usage pour cette réponse d’une collecte destinée à autre chose et relie chaque élément à consulter, corriger, désactiver ou faire expirer. Le périmètre doit rester cohérent entre texte, voix, notifications, export et appareils. Désactivez une mémoire, puis ouvrez une conversation neuve. Si l’étiquette change mais que l’ancien détail revient, consignez l’écart. Cette étape n’audite pas l’architecture de stockage ni l’achèvement d’une suppression, qui relèvent du guide distinct sur la transparence des données.
Placer sources, hypothèses, contradictions et inconnues près de la sortie
Un avertissement général en bas de page vaut moins qu’une explication attachée au résultat important. Distinguez faits fournis par l’utilisateur, sources consultées et leurs dates, réglages du produit, inférences de l’assistant, éléments contradictoires, informations inaccessibles et questions ouvertes. PAIR recommande d’expliquer les sources et le comportement du système afin que la confiance soit calibrée. Un pourcentage sans définition, preuve ni action associée n’est pas un indicateur. Retirez une source, ajoutez un fait contraire, puis rouvrez une ancienne réponse après la date de sa source. L’interface doit signaler le conflit ou abaisser la certitude. La véracité de la source reste une autre tâche, traitée par le parcours de vérification factuelle lié.
Observer l’effet réel des contrôles et conserver une sortie normale
La personne doit pouvoir corriger une préférence, réduire la personnalisation, couper une fonction ou les notifications et quitter par un mécanisme de compte, sans négocier avec le personnage. Pour chaque contrôle, notez surfaces touchées, moment d’effet, confirmation, échec, reprise et annulation. PAIR recommande d’indiquer ce que le retour change, quand, et de préserver retrait et réinitialisation. Déconnectez une source puis ouvrez une session sans rapport sur un autre appareil. Si la source est encore utilisée, le reçu reste ouvert. Une phrase aimable disant que le réglage a changé ne suffit pas : état et comportement doivent suivre. En cas d’écart entre appareils, conservez version, appareil et statut non résolu plutôt que d’inventer une explication.
Suivre erreur, revue humaine et recours jusqu’à un état final
Le bouton de signalement n’est que l’entrée. Le produit précise ce qui peut être signalé, les preuves jointes, l’existence d’une revue humaine, le lieu de suivi et les fins possibles : corrigé, refusé, non reproduit, remplacé par une version ou encore en cours. Correction de contenu et incident produit sont séparés, sans demander d’informations inutiles. Le NIST Core inclut retours externes et impacts documentés dans la gestion continue. Signalez une anomalie bénigne et reproductible ; vérifiez accusé de réception, changement de statut, motif et voie pour compléter ou contester. Le silence ne vaut pas résolution et une promesse du support n’est pas une fin observable. Gardez version, identifiant de conversation et résultat affiché.
Ancrer sept lignes à une version et une date sans les additionner
Le reçu comporte identité et rôle ; finalité et limites ; données et mémoire ; sources et incertitude ; contrôle et sortie ; erreur et recours ; version et date. Chaque ligne garde emplacement, action, test négatif, observation, lacune, responsable et jour du contrôle. Elle passe seulement si la preuve existe et si l’action fonctionne comme annoncé. Aucun point, moyenne ou classement : une sortie absente ne se compense pas par une belle explication des sources. Après une évolution importante, retestez une identité, une mémoire, une sortie sourcée, un retrait et un statut de signalement. Le NIST Playbook invite à adapter les actions au contexte. Datez les anciens reçus et écrivez « inconnu » quand la preuve manque.
Questions fréquentes
Faut-il transformer la transparence en note unique ?
Non. Une note peut masquer une sortie ou un recours absent derrière des divulgations sans rapport ; gardez chaque ligne séparée.
Une politique de confidentialité détaillée suffit-elle ?
Non. Entrées actives, mémoire, sources, incertitude et contrôles doivent aussi être visibles dans l’interaction courante.
Quand refaire le reçu ?
À la première utilisation puis après un changement substantiel du modèle, de la fonction, de la politique, de la mémoire ou du compte.
