Local Is Not a Sufficient Privacy Boundary: Governing OS-Integrated On-Device AI

Résumé Technique : Le local n'est pas une frontière de confidentialité suffisante : Gouverner l'IA intégrée au système d'exploitation (OS)

Énoncé du problème
L'intégration de systèmes d'IA directement dans les systèmes d'exploitation (OS) modifie fondamentalement le paysage de la confidentialité. Alors que les récits publics et industriels traitent souvent « l'exécution sur l'appareil » comme une garantie de confidentialité suffisante, cet article soutient que l'inférence locale ne traite que de la localisation du calcul, et non de l'étendue du risque de confidentialité. Dans les déploiements intégrés à l'OS, l'unité d'analyse pertinente passe des frontières isolées des applications à une couche de médiation au niveau de la plateforme. Cette couche peut accéder, combiner et agir sur des signaux provenant de l'ensemble de l'environnement de l'utilisateur (fichiers, e-mails, calendriers, notifications, capteurs).

Le problème central est que l'exécution locale ne limite pas intrinsèquement :

1. L'assemblage de contexte : La quantité de contexte que le système rassemble ou la manière dont il combine des sources de données disparates (ex: fusionner des métadonnées de calendrier avec des brouillons de documents).
2. La persistance de l'état dérivé : La durée pendant laquelle les informations déduites (embeddings, résumés, faits) persistent après l'interaction.
3. L'autorisation d'action : Les outils que l'assistant peut invoquer ou la manière dont il route les requêtes.
4. La dérive de gouvernance : Comment les propriétés de confidentialité changent après les mises à jour du système, les changements de drapeaux de fonctionnalités (feature flags) ou les modifications de politiques.

Par conséquent, la confidentialité dans ce contexte ne peut être réduite à un attribut de déploiement (local vs cloud), mais doit être traitée comme un problème de responsabilité institutionnelle impliquant un flux d'informations contraint, une autorité bornée et une gouvernance auditable.

Méthodologie
L'étude utilise une synthèse structurée bornée et une analyse de documents publics. Elle intègre cinq courants de littérature adjacents : la protection de la vie privée dès la conception (privacy-by-design), la modélisation des menaces de confidentialité, les systèmes de permissions mobiles/OS, la gouvernance/audit de l'IA, et la sécurité des agents LLM.

Les auteurs identifient six « surfaces de médiation » comme catégories de sensibilisation : l'assemblage de contexte, la persistance de la mémoire, la délégation d'action, la télémétrie, le routage de repli (fallback) et le changement post-déploiement. Ces concepts sont cartographiés sur quatre éléments (actif, frontière de confiance, mode de défaillance, contrôle) pour construire un cadre de travail.

La méthodologie comprend :

1. Modélisation des menaces : Définir un fournisseur de plateforme semi-digne de confiance et identifier les modes de défaillance au-delà des attaques manifestes (ex: opacité, dérive institutionnelle).
2. Typologie des fonctionnalités : Distinguer cinq types de fonctionnalités (API de modèle local, index sémantique ambiant, couche assistant/outil, repli vers un cloud privé, capture gérée par l'entreprise) pour assurer des limites d'évaluation précises.
3. Évaluation basée sur la documentation : Appliquer une grille d'audit à quatre niveaux à la documentation publique de trois plateformes contemporaines : Apple Intelligence/Foundation Models, Android AICore/Gemini Nano, et Microsoft Recall. L'évaluation se concentre sur les preuves publiques inspectables plutôt que sur la vérification de l'implémentation.

Principales contributions
Le document présente quatre contributions primaires :

1. Modèle de menace centré sur l'OS : Un modèle axé sur les préjudices de confidentialité émergeant de l'accès au contexte, de la mémoire, de l'invocation d'outils, de la télémétrie, du comportement de repli et de la gouvernance de version. Il traite le fournisseur de plateforme comme un acteur semi-digne de confiance dont les paramètres par défaut et les processus de mise à jour sont des sujets légitimes d'audit.
2. Taxonomie des risques de confidentialité en six parties : Une séquence de cycle de vie des risques où l'IA locale peut tout de même devenir invasive :
   • Expansion de l'accès : Élargissement du périmètre d'entrée à travers les applications cloisonnées.
   • Assemblage et effondrement du contexte : Combinaison des contextes personnels et professionnels, violant l'intégrité contextuelle.
   • Amplification de l'inférence : Dérivation de traits sensibles à partir de fragments triviaux.
   • Persistance et usage secondaire : Rétention des états dérivés (embeddings, résumés) permettant de futures violations ou réutilisations.
   • Divulgation actionnable : Présentation d'inférences sensibles au mauvais moment ou à la mauvaise partie via des actions d'outils.
   • Dérive de gouvernance : Perte de recours pour l'utilisateur suite à des mises à jour ou des changements de politique.
3. Cadre de confidentialité par l'architecture (Privacy-by-Architecture) : Un cadre de contrôle multicouche cartographiant les risques aux points d'application :
   • Courtier de contexte (Context Broker) : Décide de l'éligibilité de la source en fonction de la tâche, de la sensibilité et de la provenance avant la récupération.
   • Gestionnaire de mémoire (Memory Manager) : Distingue les prompts transitoires de la mémoire durable, imposant le lien avec la source et la propagation de la suppression.
   • Courtier d'outils et de repli (Tool and Fallback Broker) : Médiatise les actions sortantes et le routage distant, exigeant des vérifications de provenance et bloquant les divulgations hors périmètre.
   • Gouvernance de version (Release Governance) : Assure la responsabilité par des journaux d'audit, des tests de régression et des voies de retour en arrière après les mises à jour.
4. Grille d'audit à quatre niveaux : Un système de notation (0 : Absent à 3 : Robuste) pour évaluer les affirmations de confidentialité basées sur des preuves concrètes (ex: cartes de flux de données, manifestes de contexte, journaux de refus) plutôt que sur des déclarations de politique. Il distingue les affirmations nominales des contrôles opérationnels.

Résultats
L'application de la grille à la documentation d'Apple, Android et Microsoft révèle plusieurs conclusions critiques :

• Les affirmations de localité dépendent des frontières : Les affirmations d'exécution locale sont plus fortes pour les API étroites orientées applications (ex: Android AICore) mais plus faibles pour les systèmes de capture ambiante (ex: Microsoft Recall) où le stockage local crée des risques distincts de rétention et de forensique.
• Les index persistants créent de nouvelles surfaces : Les index locaux (comme Recall) soulèvent des questions de confidentialité concernant la rétention, l'accès par co-utilisateur et la gouvernance en milieu de travail, qui sont distinctes de l'inférence du modèle.
• La transparence du repli est un contrôle de gouvernance : Bien que le reporting sur le Private Cloud Compute (PCC) existe, des scores robustes exigent une provenance de source inspectable et des règles de blocage, et non seulement des journaux de routage.
• Transfert de responsabilité : Les API locales destinées aux développeurs transfèrent la responsabilité en aval ; l'isolation de la plateforme peut être forte, mais la limitation de l'usage au niveau de l'application et le recours de l'utilisateur restent souvent non documentés ou faibles.

La comparaison souligne que « sur l'appareil » n'est pas une architecture monolithique ; différentes frontières de fonctionnalités nécessitent des preuves et des contrôles différents.

Signification
Le papier affirme que sa signification réside dans le recadrage de la confidentialité pour l'IA intégrée à l'OS, passant d'un attribut technique de déploiement à un problème de gouvernance. Il soutient que traiter le « local » comme un raccourci pour la fiabilité risque de réduire le discours sur la confidentialité à des arguments symboliques de lieu de déploiement, déplaçant potentiellement le fardeau de la protection sur les utilisateurs.

En traitant le système d'exploitation comme un acteur de gouvernance, le cadre fournit un mécanisme pour :

• Traduire les principes abstraits de confidentialité en contrôles techniques concrets (ex: courtiers de contexte, gestionnaires de mémoire).
• Rendre les affirmations de confidentialité auditables et contestables pour les chercheurs, les régulateurs et les administrateurs d'entreprise.
• Adresser les dynamiques de pouvoir spécifiques des fournisseurs de plateformes qui structurent ce que les applications peuvent accéder et comment les paramètres par défaut façonnent l'expérience utilisateur.

Les auteurs soulignent que la confidentialité significative dans l'IA sur l'appareil dépend de flux d'informations contraints, d'une autorité bornée, d'un contrôle utilisateur visible et d'une gouvernance auditable à travers le cycle de vie du système d'exploitation, plutôt que de l'endroit où le calcul se produit simplement. Ce travail sert de cadre conceptuel et évaluatif plutôt que de certification de l'implémentation spécifique d'un fournisseur.