Livre blancGouverner les agents IA en production : politiques, approbations humaines et arrêt d'urgence.Lire le livre blanc
NavinAI Platform

Guide · Souveraineté

Déployer une IA souveraine sur site

D'une brique seule à un cluster entièrement isolé du réseau : les cinq topologies de déploiement de Navin Enterprise AI, la chaîne GitOps avec images signées et les paquets système avec archives hors ligne pour Debian, Ubuntu, la famille RHEL et Arch Linux.

Publié le 3 min de lecture

Navin Enterprise AI est une plateforme auto-hébergée et multi-tenant. La même plateforme se déploie selon cinq topologies, pour que chaque organisation choisisse jusqu'où elle isole ses données et ses modèles.

Cinq topologies

  • Brique seule : Control Plane, PostgreSQL et un composant, par exemple la gateway LiteLLM, avec authentification par clés API.
  • SaaS mutualisé : un cluster, plusieurs tenants isolés par la RLS, OpenFGA et des namespaces Cilium.
  • Tenant dédié : un namespace ou un cluster par grand compte, avec son montage OpenBao et son pool GPU.
  • Souverain sur site : un cluster isolé du réseau, uniquement des modèles locaux (vLLM), un miroir Harbor et Argo CD depuis un Git interne.
  • Hybride : vLLM local pour les données restreintes, fournisseurs distants autorisés par politique pour les autres classifications.

Isolé du réseau dès la conception

Dans la topologie souveraine, l'inférence tourne sur vLLM dans le cluster et LiteLLM reste la gateway unique vers les modèles. Les images viennent d'un miroir Harbor et Argo CD déploie depuis un dépôt Git interne. Toutes les topologies sont livrées par Argo CD à partir de charts Helm, avec des images signées par Cosign, l'admission Kyverno et des sauvegardes Velero.

Installation par paquets système

Hors Kubernetes, les trois produits Navin sont livrés en paquets DEB, RPM et pacman avec des services systemd, pour Debian et Ubuntu, la famille RHEL (Red Hat Enterprise Linux, Rocky Linux, AlmaLinux, Oracle Linux, CentOS Stream) et Arch Linux. Un script d'installation unique contrôle tous les prérequis avant le premier changement, en mode autonome comme en cluster. Les archives hors ligne, une par famille de systèmes, contiennent les paquets, revérifiés à l'installation.

L'agent du Navin Manager ouvre lui-même toutes ses connexions : aucun port entrant n'est nécessaire sur les hôtes gérés. Les archives, les images et les paquets Python du miroir hors ligne sont vérifiés par leur sha256, et les dépôts de paquets de l'éditeur sont signés hors ligne par le responsable de release, jamais dans la CI.

Rien ne change tant qu'un contrôle échoue.
  • Fiche techniqueAgents

    Des runtimes MCP isolés par utilisateur et par projet

    Le registre et la passerelle MCP décident qui peut utiliser quel serveur ; le runtime MCP crée à la demande des instances isolées sur le ToolHive Kubernetes Operator et les détruit après usage. Chaque appel d'outil passe toujours par la politique, la DLP et l'approbation.

    3 min de lecture
  • Fiche techniqueSécurité

    Analyse obligatoire des fichiers par ClamAV et YARA-X

    Chaque fichier envoyé à l'IA passe en quarantaine, est analysé par ClamAV et YARA-X puis validé avant que Docling, l'OCR ou le RAG ne puissent le lire. Entièrement local, en échec fermé, journalisé et hautement disponible.

    2 min de lecture
  • Livre blancGouvernance

    Gouverner les agents IA en production

    Comment Navin Enterprise AI garde les agents autonomes sous contrôle : politiques OPA empilées de la plateforme au tenant puis au projet, approbations avec un humain dans la boucle, kill switch disponible à tout moment et registre de gouvernance comme source de vérité unique.

    26 min de lecture

Voyez ces principes appliqués à vos cas d'usage

Un architecte vous présente la plateforme sur vos propres contraintes.