Le AI POD de Cisco pour Splunk ajoute un runtime packagé qui associe l’infrastructure Cisco à un calcul accéléré par NVIDIA et une orchestration Kubernetes, optimisés pour les charges IA de Splunk. L’Assistant IA de Splunk (aujourd’hui) et l’Agent Launchpad (à venir) reposent sur cette couche pour permettre aux équipes de mener des enquêtes, rédiger des requêtes ou créer des agents personnalisés sans envoyer la télémétrie hors site. Parce qu’il est pré-validé, les clients bénéficient de paramètres par défaut avisés pour les profils GPU, le débit de stockage et la segmentation réseau — essentiels pour une latence prévisible et une réponse aux incidents efficace. Le résultat : des cycles de déploiement plus courts, moins d’intégrations ponctuelles et un modèle que les équipes de sécurité peuvent examiner et renforcer comme toute autre charge réglementée.

Splunk Agent Observability instrumente les agents et modèles de bout en bout : invites, appels d’outils, latences, modes de défaillance et jetons. Les équipes peuvent attribuer les dépenses par agent, équipe ou projet, appliquer des limites de taux et prévoir les courbes de consommation en cours de période. Cela comble le classique « choc de facture » et crée la base pour la refacturation ou la justification des coûts. Comme les garde-fous sont intégrés, vous pouvez bloquer les actions à haut risque, limiter les fenêtres de contexte et isoler les outils. Associé aux indicateurs de performance — temps de résolution, réduction des faux positifs, taux d’assistance des analystes — la direction obtient une vision claire des agents méritant un budget GPU plus important et de ceux nécessitant une refonte, des modèles plus petits ou des améliorations de récupération.

Tous les workflows ne nécessitent pas un modèle de 70 milliards de paramètres. Utilisez des poids ouverts petits et rapides pour le routage, la sélection d’outils et les réponses modélisées ; réservez les modèles plus grands aux enquêtes nécessitant un raisonnement poussé. Adaptez la VRAM à la fenêtre de contexte et à la concurrence ; utilisez MIG ou des partitions GPU pour isoler les charges et protéger les SLO de latence. Kubernetes devient le plan de contrôle : autoscale selon la profondeur de la file d’attente, attribuez des types de GPU par namespace et séparez les clusters dev/test de la production. Ajoutez un registre de modèles avec évaluations liées aux tranches de données Splunk pour que les remplacements soient fondés sur des preuves. Cela maintient les coûts prévisibles tout en conservant la possibilité d’ajouter des modèles de classe Nemotron ou spécifiques au domaine au fur et à mesure que de nouveaux cas d’usage apparaissent.

Jour 0–30 : définissez deux cas d’usage proches de la production (par exemple, triage d’alertes et rédaction de requêtes). Établissez les coûts de référence et le MTTR ; déployez les paramètres de référence du AI POD ; instrumentez la tokenomie avec des centres de coûts par équipe et des garde-fous par défaut. Jour 31–60 : mettez en place un registre de modèles, ajoutez des modèles petits et moyens, et testez en A/B sur des tickets réels. Appliquez des limites de contexte, orientez avec un classificateur léger et publiez des invites partagées. Jour 61–90 : activez la refacturation/justification des coûts, ajoutez des SLO par agent (latence, précision, coût par incident) et étendez aux agents de codage avec des budgets séparés. Ce n’est qu’alors que vous élargirez le périmètre aux playbooks autonomes dans le SOC ou le NOC.

Le contrôle sur site réduit les risques d’exfiltration et de gouvernance, mais transfère la complexité à votre équipe. Des GPU sous-dimensionnés ou des plafonds d’E/S vont créer des goulets d’étranglement lors des incidents avec des pics de concurrence. La prolifération des modèles sans registre ni discipline d’évaluation conduit à la dérive et à des coûts imprévisibles. Traitez les GPU comme une ressource rare et planifiée ; codifiez les politiques de routage ; appliquez une hygiène des invites ; et pré-approuvez les connecteurs de récupération. Soyez réaliste quant à la capacité de pointe — les architectures hybrides peuvent encore être pertinentes pour les débordements ou les charges à faible risque. Enfin, investissez tôt dans le red-teaming et les pistes d’audit pour pouvoir expliquer — et si nécessaire, revenir en arrière — chaque action d’agent en toute confiance.