Gouvernance de l'IA : Introspection et approbations

Introspection métier object (portée introspection:read)

Trois outils de lecture permettent à un client IA d'appréhender la structure de l'entreprise avant toute interaction : les objets existants (y compris les champs et objets personnalisés de l'espace de travail), la signification de chaque attribut, les relations entre les objets et les actions possibles, avec leurs prérequis et les ressources disponibles. Un agent bien conçu consulte ces informations en premier lieu et ne propose que les actions autorisées par les ressources disponibles.

Outils de rédaction en cours de révision : en attente / refusés.

Lorsqu'un outil d'écriture MCP cible une action dont le mécanisme est review, l'appel not n'exécute pas l'effet de bord. Il renvoie un résultat structuré : soit la proposition a été mise en file d'attente pour approbation humaine (pending), soit elle a été refusée d'emblée (refused), avec un reason_code et un suggested_action lisibles par machine.

// proposed — waiting for a human
{
  "status": "pending",
  "proposal_id": "prop_9f2c…",
  "action": "issue_coupon",
  "expires_at": "2026-07-10T00:00:00Z",  // 7 days
  "message": "Queued for human approval in
              AI Activity & Approvals."
}

// refused — with a reason and a next step
{
  "status": "refused",
  "action": "issue_coupon",
  "reason_code": "recently_rejected",
  "suggested_action": "A human rejected this
    proposal recently. Do not re-propose;
    consider a different action or ask the
    operator."
}

Chaque refus porte un reason_code sous cette forme plus un suggested_action — traitez les codes ci-dessus comme ceux sur lesquels bifurquer et le champ comme extensible. Un refus est une limite difficile à lire pour vous, et non une erreur à réessayer : ne reformulez jamais une proposition pour contourner un refus.

Primitives de transparence et modèle d'inventaire « boîte de verre »

La même rigueur en matière de transparence — chaque décision automatisée est enregistrée et explicable, les données personnelles sont exclues du contexte du modèle — s'étend au-delà des actions encadrées : à l'optimisation du trafic expérimental, aux invites LLM sortantes et à l'inventaire de modèles d'apprentissage automatique classiques qui alimentent le classement, la prédiction et la détection dans l'ensemble du produit.

Optimisation automatique du trafic A/B : le journal des décisions

Les campagnes récurrentes (automatisations et parcours clients) peuvent s'inscrire à Optimisation automatique du trafic au fil du temps, qui réalloue les pondérations de diffusion entre les variantes d'expérimentation en fonction des performances de clics observées. Chaque réallocation est traçable :

• Journal de décision (ajout uniquement). Chaque recalcul horaire crée un enregistrement avec les pondérations appliquées et une justification lisible. Les enregistrements ne sont jamais réécrits : le journal conserve l’historique complet expliquant l’évolution du trafic.
• La répartition configurée reste inchangée. La répartition configurée de votre expérience sert de référence ; les pondérations optimisées sont calculées et enregistrées.
• Seuil d'exploration : 10 %. Le poids d'aucune variante ne descend jamais en dessous de 10 %, ce qui garantit un trafic constant pour chaque variante et permet de détecter tout retournement de situation.
• Répartition égale jusqu'à ≥ 100 livraisons par variante. La répartition des poids reste inchangée jusqu'à ce que chaque variante atteigne au moins ~100 livraisons. Aucun réajustement n'est effectué en cas de données peu nombreuses, et ce mécanisme ne désigne aucun « gagnant » statistique.

Masquage LLM PII au niveau de la couture du fournisseur

Avant qu'une invite ne quitte Flash pour un fournisseur LLM externe, les identifiants personnels des membres sont masqués — appliqués au niveau du fournisseur, afin que chaque fonctionnalité d'IA y transite :

• Pseudo-identifiants déterministes. Les adresses e-mail, les numéros de téléphone et les suites de chiffres (comme sur une carte) sont remplacés par des jetons de substitution stables. Un même identifiant correspond toujours au même pseudonyme, ce qui garantit la cohérence du raisonnement du modèle pour une requête donnée.
• Le masquage s’applique à chaque invite sortante de chaque fonctionnalité d’IA ; il n’y a rien à activer et il ne peut pas être désactivé depuis le produit.
• Masquage uniquement, jamais démasqué. Le mappage est unidirectionnel à la limite de sortie : la sortie du modèle n’est jamais réécrite pour rétablir les identifiants réels, de sorte que les informations personnelles brutes ne peuvent pas transiter par une réponse LLM.

Inventaire du modèle « boîte en verre »

Chaque fonctionnalité prédictive ou statistique du produit est un modèle déterministe classique : pas de notation boîte noire, pas d'échantillonnage, de sorte que les mêmes données produisent toujours le même modèle. Chacun porte une porte d'honnêteté explicite : sous la porte, il n'émet rien plutôt qu'une supposition, et chaque score est livré avec les nombres nécessaires pour le recalculer. L'inventaire actuel :

Aucun de ces modèles n'agit de manière autonome : ils classent, notent et signalent les activités, et toute transaction financière ou contact avec un membre est soumise aux mécanismes de contrôle mentionnés précédemment.

Pour obtenir des informations techniques complètes sur chaque modèle (méthode, entrées, colonnes de sortie, contrôles d'honnêteté et surfaces de consommation), consultez le document de référence des modèles prédictifs .