Agents IA en air gap : ce qu'exige vraiment le zéro egress

Toute conversation de déploiement sérieuse avec une institution soucieuse de sécurité atteint le même point de contrôle, et c'est l'équipe réseau qui le tient, pas l'équipe data : « Qu'est-ce que cela doit atteindre ? » La plupart des produits d'IA d'entreprise répondent par une liste - API du modèle, serveur de licences, endpoint de télémétrie, canal de mise à jour - puis négocient les entrées vraiment nécessaires. DataQube est construit pour que la négociation soit inutile : la plateforme elle-même n'atteint rien, et la seule dépendance qui a réellement besoin d'un modèle - le modèle - tourne là où vous le décidez.

Deux clarifications honnêtes avant la technique. D'abord, l'air gap total est un mode d'exploitation pris en charge, pas le seul : la plupart des clients choisissent des modèles frontier commerciaux dans leur empreinte cloud existante - leur propre tenant, sous conditions de zéro rétention de données, dans des accords que leur équipe sécurité a déjà examinés. Ensuite, le plafond air gap façonne tout de même le produit. Concevoir pour le cas le plus dur est la raison pour laquelle les cas plus simples restent propres : une plateforme sans télémétrie, sans rappel de licence et sans canal de mise à jour se comporte à l'identique, que l'endpoint du modèle soit de l'autre côté du cluster ou de l'autre côté de leur cloud. Cet article porte sur ce plafond - ce qu'il exige vraiment.

Où tourne le modèle : votre curseur, pas le nôtre

L'endpoint du modèle est de la configuration, et la configuration couvre un spectre. À une extrémité : un endpoint compatible OpenAI dans votre propre tenant cloud - les modèles frontier que vos équipes connaissent déjà, avec zéro rétention de données en vigueur, c'est-à-dire que les prompts et les sorties ne sont ni stockés ni utilisés pour l'entraînement, et que le trafic ne quitte jamais les accords que vous gouvernez déjà. C'est là qu'atterrissent la plupart des clients, parce que cela achète la qualité frontier sans créer une seule nouvelle relation de données.

À l'autre extrémité : un déploiement totalement en air gap, avec un service d'inférence dans le cluster sur vos propres GPU, servant des modèles à poids ouverts que vous avez choisis et validés. Aucune route vers l'extérieur - la configuration des réseaux fermés, et le mode que le reste de cet article met à l'épreuve.

Ce que les deux extrémités partagent, c'est la propriété qui compte pour un auditeur : le choix du modèle est sous votre contrôle des changements. Une montée de version du modèle est un ticket de changement - testé, approuvé, réversible -, pas un fournisseur qui échange silencieusement les poids sous une API. Quand quelqu'un demande « quel modèle, exactement, a produit les chiffres du trimestre dernier, et qui l'a approuvé ? », la réponse est dans votre historique de changements - dans les deux cas.

Livraison : un seul chemin approuvé pour tout

Faire entrer du logiciel dans un réseau sans internet est un problème logistique résolu - toute institution en air gap opère déjà un chemin d'artefacts approuvés avec un miroir de registre derrière. L'obligation de conception du fournisseur est de n'avoir besoin que de ce chemin, pour chaque artefact, sans exceptions qui surgissent plus tard :

Une release, ce sont des images de conteneurs, des charts de déploiement, des poids de modèles quand nous en fournissons - et la licence, délibérément ennuyeuse : un fichier signé, validé localement contre notre clé publique, sans serveur de licences, sans appel d'activation, avec des renouvellements par simple échange de fichier sur le même chemin. Rien dans l'ensemble ne s'attend à télécharger quoi que ce soit d'autre : zéro egress signifie que toute la fermeture des dépendances - jusqu'aux artefacts encombrants comme les moteurs de navigateur - apparaît au moment du build et part épinglée, au lieu d'arriver par un téléchargement que personne n'a examiné. L'épinglage par digest rend tout le chemin digne de confiance : ce que votre équipe a examiné à la frontière tourne octet pour octet à l'intérieur, et les digests du registre de déploiement répondent « qu'est-ce qui tourne exactement » pour tout audit, pour toujours. Les builds reproductibles ferment la boucle - un digest en production se rattache à une release source sans nous croire sur parole.

Support sans tunnel

La question qui suit la livraison : « Quand quelque chose casse, comment nous aidez-vous si vous ne pouvez pas vous connecter ? » Elle mérite une réponse concrète, car « on trouvera » est la manière dont naissent les exceptions d'accès distant.

Notre réponse a trois volets. D'abord, les journaux d'audit et de diagnostic sont structurés et exportables par conception - les mêmes enregistrements qui servent la conformité servent le support, et ils ne contiennent jamais de données, d'identifiants ni d'informations personnelles, si bien que les exporter via un processus de revue est praticable. Ensuite, les builds reproductibles font qu'un problème signalé contre un digest est un problème reproductible dans notre labo : nous exécutons les mêmes octets, pas une supposition. Enfin, les correctifs voyagent par le chemin d'artefacts comme toute release - selon votre calendrier de changements, pas le nôtre.

Cette dernière clause est un vrai coût, alors elle doit être sur la table. Le zéro egress nous a fait renoncer à des choses que les fournisseurs aiment : les mises à jour automatiques silencieuses (les clients montent de version délibérément, à leur rythme), l'analytique d'usage (nous apprenons de partenaires de conception et d'exercices, pas de télémétrie) et le débogage à distance (les journaux doivent être assez bons - ce qui les y oblige). Nous considérons chacun de ces échanges comme une fonctionnalité déguisée en coût - chacun supprime un canal que votre revue de sécurité devrait sinon modéliser.

La check-list pour tout fournisseur qui revendique l'air gap

« Compatible air gap » va de « réellement conçu pour » à « a marché une fois en démo avec le Wi-Fi coupé ». Cinq questions séparent les extrémités de cette plage. Où le modèle peut-il tourner - et entièrement à l'intérieur est-il une réponse prise en charge, pas un point de roadmap ? Les licences appellent-elles un jour vers l'extérieur, ne serait-ce qu'une fois ? Chaque artefact d'une release peut-il être mis en miroir et vérifié par digest - y compris les encombrants, comme les moteurs de navigateur et les poids de modèles ? Que reçoit exactement le support quand quelque chose casse, et une réponse implique-t-elle un tunnel ? Et la question de synthèse que l'équipe réseau posera de toute façon : qu'est-ce que la plateforme elle-même doit atteindre ?

Nos réponses sont sur la page sécurité, et le spectre de déploiement - du tenant cloud avec zéro rétention de données jusqu'à l'air gap total - est exactement ce pour quoi existe l'offre Sovereign de notre page tarifs. Une démo tourne très bien internet débranché - c'est un peu le but.