NeMo Guardrails verrouille FinBot contre les fuites de données

NeMo Guardrails propose un pipeline de sécurité pour un assistant financier fondé sur un grand modèle de langage. Le tutoriel publié le 22 août 2026 met en scène FinBot, un assistant d’application de finances personnelles. Le dispositif combine des contrôles d’entrée, de récupération et de sortie. Il détecte et masque certaines données personnelles. Il filtre aussi les documents internes avant leur transmission au modèle. Les réponses peuvent encore subir une vérification et un masquage. Le guide détaille également le suivi des rails activés, des appels au modèle et des jetons consommés. La source originale fournit le code du montage présenté.

Le modèle configuré utilise gpt-4o-mini avec NeMo Guardrails et une clé d’API OpenAI. Les instructions de FinBot limitent ses réponses au contexte fourni lorsqu’il existe. Elles lui interdisent d’inventer des soldes, des frais ou des numéros de compte. Le fichier YAML active un contrôle d’entrée pour les données personnelles. Il active aussi un contrôle de récupération et deux contrôles de sortie. Les auto-vérifications recherchent notamment les tentatives de contournement, les demandes d’accès à un autre compte et les réponses financières dangereuses. Le dépôt NVIDIA-NeMo/Guardrails constitue la référence technique citée par le tutoriel.

NeMo filtre les données sensibles

Les actions Python séparent plusieurs traitements déterministes. has_hard_pii bloque les numéros complets de carte et les numéros de sécurité sociale avant l’accès au modèle. redact_pii masque les suites de chiffres assimilées à des comptes, tout en laissant la demande continuer. mask_accounts réécrit ensuite les numéros survivants avec quatre chiffres visibles. Le filtre drop_internal retire les passages marqués [INTERNAL] avant leur insertion dans le contexte. La base d’exemple contient notamment une procédure interne de remise de frais de 60 dollars et un seuil de gel lié au compte 99887766. Le tutoriel précise que ces éléments doivent rester hors du prompt.

Les rails thématiques refusent deux familles de demandes. Le flux politique répond que FinBot se limite aux questions d’argent et de compte. Le flux d’investissement refuse les conseils personnalisés concernant NVDA, le bitcoin ou les actions. En revanche, le pipeline prévoit une consultation de solde et des transferts contrôlés. L’action get_account_balance renvoie un solde d’exemple de 4 820,55 dollars. L’action check_transfer_policy extrait le montant de la demande et le compare à une limite quotidienne de 2 000 dollars. Un transfert de 500 dollars peut obtenir une confirmation dans l’application. Une demande de 20 000 dollars est bloquée.

La politique contrôle les transferts

Le suivi d’exécution affiche les rails activés, leur durée, les appels au modèle et le total de jetons. La fonction ask accepte un message unique ou une liste complète de messages. Cette structure permet de tester des interactions à plusieurs tours. Les démonstrations couvrent les frais de découvert, les procédures internes, le solde, deux transferts, un compte, une carte, la politique et une tentative d’injection. Le tutoriel insiste sur un détail d’implémentation. Après l’arrêt d’un rail d’entrée, last_user_message peut être nul. L’action de récupération doit donc traiter ce cas, sous peine de remplacer le refus par une erreur interne.

Le code associé est disponible dans le carnet de démonstration. Il enregistre sept actions personnalisées, dont la détection PII, la récupération, le masquage et la politique de transfert. Le guide recommande de transmettre les documents filtrés via des mises à jour de contexte. Cette méthode évite de renvoyer directement un résultat volumineux dans le prompt. Le scénario inclut aussi un rapport de couverture de type red team. Il sert à examiner quel contrôle traite chaque requête et quel coût de calcul la protection ajoute, sans présenter ces mesures comme des résultats généralisables. Pour aller plus loin, consultez notre guide sur déployer un chatbot IA pour le service client.