Règles de gouvernance
Gouverner les modèles, les données et les actions
Un appel autorisé vers un modèle ne doit pas devenir automatiquement le droit d’envoyer un e-mail, de modifier un CRM ou de déclencher une autre action métier. Ces opérations n’ont ni le même risque ni la même preuve attendue.
État de la capacité
Architecture cible — Gateway et Edge en préparation
Le modèle de séparation entre flux IA et actions métier est défini dans la direction produit. Il ne doit pas être présenté comme un contrôle disponible sur tous les environnements aujourd’hui.
Règles de gouvernance
Une route IA est plus précise qu’un simple nom de modèle
Dire qu’un modèle est « autorisé » est souvent trop vague. Une décision de gouvernance utile tient compte de la route effective : organisation, endpoint, fournisseur, modèle ou version connue, région, identité du workflow, classe de données, finalité et mode de contrôle.
Cette précision permet de traiter une même famille de modèles différemment selon le contexte. Un flux de test synthétique, une analyse interne et une action destinée à un client n’appellent pas nécessairement la même règle.
- Route fournisseur et modèle visé
- Workflow ou système à l’origine de la demande
- Finalité déclarée et classe de données
- Politique, décision et durée de validité associées
Règles de gouvernance
Distinguer l’inférence de l’effet de bord
Une demande envoyée à un modèle est une inférence : elle porte notamment sur l’egress de données vers une route externe. Une action métier est un effet de bord : création d’un ticket, envoi d’un e-mail, modification d’une fiche ou déclenchement d’un paiement.
DUBSAR est conçu pour séparer ces deux décisions. Une inférence acceptée ne suffit pas à autoriser une action. Une action sensible doit être liée à son contenu, son destinataire, sa politique et à une autorisation limitée, expirante et non rejouable.
Règles de gouvernance
Le filtrage dépend du point de passage réel
Pour filtrer, masquer ou refuser une sortie de données, il faut que le flux HTTP ou API traverse un composant capable de l’examiner avant l’egress. C’est le rôle envisagé pour DUBSAR Edge et le Gateway.
Ce point de passage doit échouer de manière prudente lorsqu’il ne peut pas vérifier la décision : pas de Core disponible, reçu invalide, route non cataloguée ou information insuffisante. Une telle limite doit être observable dans les preuves, pas masquée par une promesse générale de sécurité.
Questions fréquentes
Clarifier le périmètre avant de promettre un contrôle.
Une IA autorisée peut-elle automatiquement réaliser une action métier ?
Non. Dans le modèle DUBSAR, l’autorisation d’une inférence et l’autorisation d’un effet de bord sont deux décisions distinctes.
DUBSAR filtre-t-il toutes les données d’une entreprise ?
Non. Un filtrage n’est possible que sur les flux qui passent techniquement par un Edge, un Gateway ou un connecteur intégré au périmètre.
À lire ensuite
Approfondir la gouvernance des usages IA.
Le portail DUBSAR est en cours de développement ; la méthode et les limites sont présentées publiquement.