Le caractère « privé » doit être vérifiable. Pour tester cette affirmation rapidement, cessez de parler du produit en général et suivez un travail réel, de son entrée jusqu’au résultat.
Définir le périmètre
Pour une application individuelle, le périmètre peut être un seul appareil. Pour une organisation, il peut s’agir d’un poste de travail, d’un réseau de serveurs ou d’un environnement Kubernetes. Consignez ce périmètre avant de comparer les fonctionnalités.
Recensez ensuite tous les chemins qui le franchissent : téléchargement du modèle, identité, droits d’utilisation, diagnostics, télémétrie facultative et tout modèle cloud tiers.
Tester séparément chaque parcours de modèle
Un produit peut prendre en charge à la fois un modèle local et un fournisseur cloud facultatif. Ce sont des parcours de données distincts, avec des opérateurs et des conditions différents. Une réponse générale sur le produit ne remplace pas une réponse propre à chaque parcours.
L’interface doit signaler tout changement de périmètre avant l’envoi du contenu. Le parcours local utile doit rester compréhensible à lui seul.
Rendre visibles les responsabilités opérationnelles
L’inférence locale ou sur site ne supprime pas la nécessité de sécuriser les terminaux, de contrôler les accès, d’effectuer des sauvegardes, de gouverner les modèles ou de définir des règles d’utilisation. Elle change l’entité qui exploite le périmètre.
C’est la valeur concrète de l’IA privée : le client peut placer le système dans un environnement de contrôle qu’il maîtrise déjà.