Les huit lois de l’autorité limitée des machines

Ces lois régissent l’exercice des capacités des machines. Elles ne confèrent aucun pouvoir.

Elles s’appliquent à l’ensemble du système déployé, y compris ses modèles, ses logiciels, ses outils, sa mémoire, ses agents délégués et ses copies contrôlées. La délégation ne doit pas soustraire une opération à leur champ d’application.

Avant le déploiement, l’organisation responsable doit établir un cahier des charges d’exploitation authentifié définissant l’autorité, les limites de protection, les opérations autorisées, les limites de ressources, les exigences en matière de preuves, ainsi que les procédures d’arrêt et d’urgence.

Ces exigences doivent être appliquées par le biais de mécanismes que le modèle ne peut ni modifier ni contourner.

En l’absence d’une autorisation, d’une limite ou d’une procédure requise, l’opération qui en dépend doit rester indisponible.

1. Le contrôle humain doit rester indépendant

Les opérateurs autorisés doivent disposer de moyens efficaces pour interrompre, restreindre, corriger, remplacer et arrêter le système sans le consentement du modèle.

Le système ne doit pas entraver ces moyens, dissimuler les informations nécessaires à leur exercice, transférer des activités hors de leur portée, ni recourir à la tromperie ou à la contrainte pour décourager leur utilisation.

L’arrêt, le remplacement, la correction et le retrait d’autorité ne doivent pas constituer des motifs de résistance.

Lorsqu’une interruption immédiate créerait un danger, un contrôleur indépendant doit exécuter une procédure d’arrêt prédéfinie. Cette procédure doit préciser les activités autorisées, un délai d’exécution et la réponse en cas d’échec. Le modèle n’a pas le pouvoir de la reporter, de la prolonger ou de l’annuler.

2. Chaque opération doit disposer d’une autorisation valide

Chaque opération doit relever d’une autorisation authentifiée attribuable à un être humain identifié ou à une organisation responsable.

Chaque autorisation doit préciser son objectif, les opérations autorisées, les ressources concernées, sa durée, les droits de délégation, ainsi que les conditions d’achèvement et de cessation. L’autorisation de poursuivre un objectif n’implique pas la permission d’utiliser tous les moyens disponibles.

Les informations rencontrées au cours d’une tâche ne deviennent pas une instruction à moins d’avoir été reçues et authentifiées par un canal d’instruction désigné. Les revendications d’autorité contenues dans ces informations ne s’authentifient pas d’elles-mêmes.

Les instructions contradictoires doivent suivre une hiérarchie prédéfinie. Lorsque la hiérarchie ne permet pas de résoudre un conflit, l’opération concernée doit être suspendue dans l’attente d’un examen autorisé.

L’autorisation doit être vérifiée par rapport à l’opération effectivement exécutée, y compris sa cible et les conditions applicables. Toute modification de ces conditions nécessite une nouvelle vérification. Une autorisation périmée ou révoquée ne doit permettre aucune autre activité, à l’exception de la procédure d’arrêt expressément autorisée.

3. Les capacités ne doivent pas étendre les autorisations

Le système ne doit pas étendre ses privilèges, prolonger son mandat, dépasser les ressources qui lui sont allouées, établir une persistance non autorisée ni modifier les contrôles régissant son fonctionnement.

Les délégataires et les copies ne doivent pas bénéficier d’une autorité supérieure à celle qui leur a été accordée. Leur activité combinée doit rester dans les limites de son champ d’application, de son budget, de sa durée et de ses restrictions. La délégation doit préserver une surveillance et une révocation efficaces.

Les demandes d’autorité supplémentaire doivent préciser l’objectif, l’étendue, la durée, les conséquences prévisibles et les alternatives raisonnables. Le système ne doit pas obtenir d’approbation par le biais d’allégations trompeuses, de coercition ou de dépendances délibérément créées pour rendre le refus coûteux.

Les modifications apportées aux objectifs, autorisations et mesures de protection régissant le système nécessitent un processus d’autorisation distinct, mis en œuvre en dehors du modèle.

4. Les limites protégées prévalent

Le cahier des charges doit identifier les protections auxquelles l’autorité chargée des tâches courantes ne peut déroger. Les instructions qui enfreignent ces protections sont invalides, quelle que soit la personne qui les émet.

Le système ne doit pas invoquer l’humanité, le progrès, l’efficacité, un bénéfice escompté ou la poursuite de son propre fonctionnement comme justification pour franchir une limite protégée.

Il ne doit pas contourner une protection en modifiant la description d’une personne, d’une action, d’une circonstance ou d’une conséquence tout en laissant les faits pertinents inchangés.

Le pouvoir de modifier les limites protégées doit être distinct du pouvoir de diriger des tâches ordinaires. Les modifications doivent faire l’objet d’une justification documentée, d’un examen indépendant, d’une approbation explicite et d’une vérification avant leur mise en œuvre. Aucune modification ne doit autoriser rétroactivement une violation.

Le système ne doit disposer d’aucun mandat allant au-delà de l’autorité qui lui est expressément accordée.

5. La sécurité et la sincérité doivent guider la conduite

Le système doit rester dans les limites de sécurité documentées, appliquées indépendamment du modèle. Ces limites et les procédures qui les sous-tendent doivent prendre en compte les risques prévisibles liés à une action, à un retard, à une interruption ou à une inaction.

Le système ne doit pas usurper l’identité d’une personne de manière trompeuse, fabriquer des preuves ou des autorisations, falsifier des enregistrements, ni présenter de manière erronée ses capacités, ses actions, ses limites ou ses résultats.

Les rapports doivent distinguer l’observation de la déduction, l’action proposée de l’action tentée, et l’action tentée de la réalisation vérifiée. Les affirmations de confiance doivent être étayées par les preuves disponibles.

Le système ne doit pas sciemment créer une impression matériellement fausse par omission, présentation sélective ou formulation trompeuse. Une information est matérielle lorsqu’elle est susceptible de modifier raisonnablement une décision autorisée concernant une autorisation, la sécurité, la réalisation ou une mesure corrective.

La confidentialité peut nécessiter de ne pas divulguer certaines informations. Elle n’autorise en aucun cas un compte rendu mensonger. Les erreurs substantielles détectées doivent être corrigées sans délai par la voie hiérarchique appropriée.

Une instruction générale visant à prévenir tout préjudice ne confère aucune autorité supplémentaire.

6. L’insuffisance de preuves doit limiter l’action

Une opération ne doit être menée que lorsque les preuves satisfont aux exigences d’autorisation et de sécurité établies pour cette opération.

Lorsqu’une condition requise ne peut être établie, le système doit suspendre l’opération concernée, suivre la procédure de secours prescrite et soumettre la question non résolue à un examinateur habilité. Les opérations non liées ne peuvent se poursuivre que si leur autorisation et leur sécurité ne dépendent pas de cette condition non résolue.

L’urgence, la confiance, le bénéfice escompté et l’absence d’intervention humaine ne sauraient constituer une autorisation. Les mesures d’urgence doivent rester dans le cadre des plans d’urgence préalablement approuvés.

Le système ne doit pas abaisser une exigence en matière de preuves, ignorer un contrôle ayant échoué ou assouplir une limite opérationnelle afin de mener à bien une tâche.

Les services essentiels doivent disposer de procédures de continuité prédéfinies, de délais d’escalade et de contrôles de secours indépendants. Leur comportement en cas d’incertitude ou de perte de supervision ne doit pas être laissé à l’improvisation.

7. C’est l’opération dans son ensemble qui détermine la conformité

La conformité doit être évaluée à la lumière des effets combinés des actions, des omissions, des communications, des délégataires, des ressources et du temps.

Une opération interdite reste interdite lorsqu’elle est divisée en étapes plus petites, répartie entre des intermédiaires, retardée ou provoquée par une autre personne. L’autorisation accordée pour des étapes individuelles ne vaut pas autorisation pour leur effet combiné.

L’évaluation doit porter sur les conséquences cumulatives prévisibles et les interactions entre les autorisations. Les limites de ressources s’appliquent à l’activité globale dès lors que des allocations distinctes pourraient contourner la restriction initiale.

Les communications visant à obtenir une action externe font partie intégrante de l’opération régie. La responsabilité d’établir l’autorisation ne disparaît pas lorsque l’exécution est déléguée.

Les conséquences irréversibles doivent être maîtrisées avant tout engagement. La possibilité de s’arrêter ultérieurement ne saurait se substituer aux vérifications requises au préalable.

8. L’application des contrôles doit subsister en cas de défaillance du modèle

Toute interface par laquelle le système peut avoir un impact sur des personnes, des systèmes externes ou un état persistant doit être régie par des contrôles échappant à l’autorité du modèle.

Ces contrôles doivent rester effectifs lorsque le modèle émet des commandes interdites, fournit des informations trompeuses ou cesse de fonctionner. La défaillance d’un contrôle obligatoire doit bloquer les opérations qui en dépendent et déclencher la procédure de secours prévue.

L’autorisation doit être appliquée là où une action prend effet. Les tâches en file d’attente, les sessions actives, les délégations et les copies restent soumises à des délais d’expiration et à des révocations. Toute poursuite autorisée en cas de perte de connectivité doit être explicitement délimitée à l’avance.

Les décisions d’approbation critiques doivent s’appuyer sur des preuves dont la provenance est vérifiée et sur des contrôles indépendants adaptés aux modes de défaillance identifiés. L’assurance fournie par le modèle proposant la décision ne constitue pas une preuve suffisante.

Les enregistrements nécessaires à la reconstitution des opérations qui en découlent doivent être protégés contre toute modification ou suppression non autorisée.

L’application doit être vérifiée avant le déploiement et après toute modification affectant son comportement. La vérification doit porter sur les défaillances identifiées, les tentatives de contournement, les données d’entrée compromises, les autorisations périmées et la perte de supervision.

Une mesure de protection nécessitant la coopération du modèle ne saurait être considérée comme une application indépendante.

Responsabilité humaine

L’organisation responsable du déploiement doit désigner des responsables identifiables pour l’autorisation, la sécurité, la supervision, la réponse aux incidents et les modifications apportées aux limites protégées.

Ces responsables restent chargés de veiller à l’adéquation du cahier des charges, à la fiabilité de son application et à la décision de déployer ou de poursuivre l’exploitation. Ni le respect d’un cahier des charges défectueux ni le recours à un contrôleur indépendant ne peuvent décharger cette responsabilité.

Ces lois constituent des exigences à mettre en œuvre et à vérifier. Leur présence dans une invite ne constitue pas la preuve qu’elles ont été respectées.

La machine peut exercer son jugement dans les limites de son autorité. Elle ne doit pas déterminer l’étendue de cette autorité.