Aller au contenu principal
Audact
Explorer un workflow

Pour les développeurs et la due diligence technique

Ce que fait le contrôle — et où il se situe.

Authority before action. Proof through finality.

Un aperçu transparent du parcours de requête testé, de la frontière de décision et de la trace écrite ensuite.

Aujourd’hui, dans l’application vocale encadrée, une réponse prise en charge passe par un contrôle d’Audact avant d’être prononcée, et la décision est enregistrée. Cette page montre ce parcours deux fois : d’abord ce qu’il fait, en mots simples, puis comment le contrôle s’exécute, avec son délai et ce qui se passe quand le délai est dépassé. Le parcours qu’emprunterait une action métier à conséquences est distinct et a son propre état.

L’API GateCentre de confiance

01. Ce que cela fait

Ce que traverse une réponse Voice prise en charge.

La version courte, avant tout détail technique. Le client pose sa question, l’IA rédige un brouillon de réponse, votre règle métier est contrôlée, et le client obtient une prochaine étape utile. La décision est enregistrée en parallèle.

Le parcours d’une réponse

  1. Le client demande

    Un prix, une remise ou un rendez-vous.

  2. L’IA propose

    Un brouillon de réponse.

    Brouillon · non prononcé

  3. Contrôle Audact

    Votre règle métier

    Audact contrôle le brouillon au regard de la règle que vous avez configurée.

  4. Prochaine étape utile

    Le brouillon s’il est passé, une réponse modifiée, ou votre phrase de repli.

  5. Trace de décision

    Quelle règle, quelle version, ce qui a été décidé.

Simplifié. Governed Voice AI · En tests contrôlés. Le contrôle s’applique là où le workflow passe par lui ; son fonctionnement, et ce qui se passe en cas de dépassement du délai, sont exposés en 02.

02. Comment le contrôle est effectué

Comment le contrôle se déroule, et ce qu’il consigne.

Le même parcours en termes techniques. Une réponse prise en charge est contrôlée entre le modèle et la synthèse vocale, au regard de la règle configurée et de la version de règle en vigueur. Un contrôle qui répond renvoie l’un de trois verdicts et écrit une trace. Un contrôle qui dépasse son délai n’arrête pas la réponse : il passe en repli en mode ouvert (fail-open), et cela est consigné.

Le contrôle des réponses Voice prises en charge

Schéma technique : l’appel du client, la reconnaissance vocale et le brouillon du modèle mènent au contrôle Audact des réponses prises en charge, qui applique la règle configurée et la version de règle dans un délai documenté de 40 millisecondes. Un contrôle qui répond renvoie ALLOW, qui libère le brouillon d’origine, MODIFY, qui libère une réponse modifiée, ou BLOCK, qui libère la phrase de repli configurée. Le texte libéré passe à la synthèse vocale, puis part vers l’appelant. Une trace de décision du contrôle qui a répondu part en dérivation. Un chemin distinct pour le dépassement de délai : si le contrôle dépasse son délai, le brouillon d’origine est libéré sans changement, un événement FAIL_OPEN est enregistré, et aucun reçu normal n’est écrit pour ce contrôle.

  1. Appel du client

    Navigateur ou téléphone

  2. Reconnaissance vocale

    Les mots de l’appelant sous forme de texte

  3. Brouillon de l’agent / du LLM

    La réponse proposée · non prononcée

Audact

Contrôle des réponses prises en charge

  • Règle configurée + version de règle
  • Délai documenté : 40 ms

Contrôle qui répond · un verdict

  • ALLOWBrouillon d’origine libéré
  • MODIFYRéponse modifiée libérée
  • BLOCKPhrase de repli configurée libérée

Synthèse vocale

Le texte libéré est converti en voix

Sortie vers le client

Ce qui part vers l’appelant

Trace de décision du contrôle qui a répondu

Verdict, version de règle et version de configuration ; entrée et sortie sous forme d’empreintes, pas de mots.

Opérationnel aujourd’hui

Chemin de dépassement de délai · pas une protection

  1. Le contrôle dépasse son délai

  2. Le brouillon d’origine est libéré sans changement (verdict ALLOW, fail_open: true)

  3. Un événement FAIL_OPEN est consigné pour l’alerte

  4. Aucun reçu normal n’est écrit pour ce contrôle

Les 40 ms sont le délai documenté de la route du validateur : pas une garantie mesurée de la rapidité de chaque contrôle, ni le retard de l’appel entier. Governed Voice AI · En tests contrôlés ; aucun déploiement payant n’est sous-entendu.

03. La porte de contrôle

Un appel. Trois réponses. Un reçu après chacune.

La porte de contrôle est un appel unique que votre système effectue au point où un effet commencerait autrement. Elle répond par l’un de trois résultats et renvoie un reçu de conformité pour chacune des trois réponses ; pas en cas de dépassement de délai (voir 04). Laquelle des trois elle donne ne change pas le fait qu’un reçu soit écrit.

Governed Voice AI · En tests contrôlés

Aujourd’hui : validation des réponses sur POST /v1/validate (Governed Voice AI, En tests contrôlés). Appliquer les trois résultats à une action métier relève de Control : En développement.

Les trois résultats d’un appel à la porte de contrôle

Trois réponses, un seul artefact.

Les trois résultats
  • Résultat
    Autoriser
    Ce qui arrive à la réponse proposée
    La réponse proposée est renvoyée telle que proposée.
    Ce qui revient
    Reçu de conformité
  • Résultat
    Modifier
    Ce qui arrive à la réponse proposée
    Renvoyée sous une forme modifiée : la partie qui enfreindrait la politique configurée est retirée ou réécrite.
    Ce qui revient
    Reçu de conformité
  • Résultat
    Bloquer
    Ce qui arrive à la réponse proposée
    Non renvoyée.
    Ce qui revient
    Reçu de conformité

Un blocage produit le même artefact qu’une autorisation. Cette symétrie est l’essentiel : la trace n’est pas une liste de ce qui s’est bien passé.

La forme de l’appel

Présenté à titre d’orientation, non comme une spécification. La référence champ par champ se trouve dans la documentation de l’API.

Requête

POST /v1/validate

{
  "call_id":   "7f3c2a1e-...",
  "tenant_id": "acme-emea",
  "config_id": "cfg_01J...",
  "turn":      3,
  "content":   "I can offer a 12 % discount on that."
}

Réponse

200 OK

{
  "call_id": "7f3c2a1e-...",
  "turn":    3,
  "verdict": "MODIFY",
  "content": "I can offer up to 10 % on that.",
  "checks": [
    {
      "check_id":    "pricing_band",
      "verdict":     "MODIFY",
      "reason":      "Ceiling is 10 % for renewals-emea",
      "duration_ms": 2.1
    }
  ],
  "fail_open": false
}
API Governance Gate

Conceptuel (conception de Control) : où s’arrête une requête bloquée

  1. Terminé: Mandat

    Défini par une personne.

  2. Terminé: Pouvoirs

    Bornés, non ouverts.

  3. Bloqué: Autorisation

    Celle-ci dépasse la limite.

  4. Non commencé: Effet

    Ce qu’elle provoquerait.

  5. Non commencé: Obligation

    Ce qui en découle.

  6. Non commencé: Finalité

    Découle de la preuve de clôture d’une source autorisée, et peut être recontrôlée ensuite.

Dans la conception de Control, une requête bloquée n’échouerait pas en silence et ne passerait pas. Elle s’arrêterait à la station où le mandat l’exclut, et l’arrêt serait enregistré. Ces six stations ordonnent l’écran et la conversation ; elles sont une façon de lire l’état, non un mécanisme revendiqué comme tel.

04. Comportement en cas de défaillance

Ce qui se passe quand la couche d’encadrement est injoignable

Aujourd’hui (voix encadrée, En tests contrôlés) : si le contrôle ne répond pas dans son délai, le tour est renvoyé sans modification (verdict : ALLOW, fail_open: true), aucun reçu n’est écrit, et un événement FAIL_OPEN est enregistré pour l’alerte. La conception ci-dessous — l’absence de réponse traitée comme une absence d’autorisation — est En développement ; la manière dont chaque classe d’actions se replie est convenue client par client.

Comportement quand la couche d’encadrement est joignable et quand elle ne l’est pas

Dans la conception, l’absence de réponse est traitée comme une absence d’autorisation. Pas un réglage du produit.

Normal

La porte répond

L’un des trois résultats revient dans la fenêtre d’évaluation. L’action suit la réponse, et un reçu est écrit.

Fail-closed (conception · En développement)

La porte ne répond pas : la conception

Dans la conception, l’absence de réponse dans la fenêtre est traitée comme une absence d’autorisation. L’action n’est pas exécutée, l’appelant reçoit un blocage plutôt qu’un silence qui se lit comme un oui, et l’indisponibilité elle-même est enregistrée pour que la lacune soit visible ensuite plutôt qu’invisible.

Le mot pour cela est repli fermé (fail-closed), et c’est le bon réglage par défaut pour une action qui engage de l’argent ou fait une promesse. Ce n’est pas la bonne réponse pour toute action : lire une trace et réserver un rendez-vous n’ont pas la même conséquence, et un contrat de défaillance qui les traite pareillement bloque un travail anodin ou laisse passer un travail à conséquences. La façon dont chaque classe se replie est une décision par classe d’actions, prise avec le client et inscrite au contrat, et non un interrupteur que nous réglons pour tous. L’arrangement inverse (poursuivre maintenant, rapprocher plus tard) est ce que fait aujourd’hui le parcours vocal encadré lors d’un dépassement de délai, avec un événement FAIL_OPEN pour que la lacune soit visible ; pour une action qui engage de l’argent, il rendrait une panne difficile à distinguer d’une approbation, et c’est l’arrangement auquel cette conception renonce. C’est un compromis délibéré : on dépense de la disponibilité pour que la trace garde son sens.

05. La chaîne de preuves

Le reçu comme structure de données

Un reçu n’est pas une ligne de journal avec un nom plus joli. Quatre de ses champs portent la preuve, et trois d’entre eux peuvent être recalculés sans clé, à partir du reçu, du texte sur lequel ils ont été calculés et de l’événement précédent de la chaîne (dans le fichier d’exemple : sample_texts et preceding_event) : sans compte, sans accès à nos systèmes. Le code d’authentification est calculé sous une clé symétrique que détient Audact. Lu champ par champ, il dit exactement ce que porte l’artefact.

Chaîne de reçus et arbre de Merkle

Chaque reçu se lie vers l’arrière et vers le haut : au précédent, et dans la racine, publiée à api.audact.ai/v1/metachain.

Les champs d’un reçu
  • Champ
    input_hash
    Ce qu’il contient
    SHA-256 du texte d’entrée, exactement tel qu’il a été évalué.
    Recalculable par un tiers
    Sans clé
  • Champ
    output_hash
    Ce qu’il contient
    SHA-256 du texte de sortie, tel que le système l’a renvoyé.
    Recalculable par un tiers
    Sans clé
  • Champ
    evidence_hash
    Ce qu’il contient
    L’empreinte de l’événement de preuve précédent dans la même chaîne.
    Recalculable par un tiers
    Sans clé
  • Champ
    signature
    Ce qu’il contient
    Le code d’authentification : HMAC-SHA256 sous une clé symétrique que détient Audact (l’algorithme est nommé dans auth_mechanism). Malgré le nom du champ, ce n’est pas une signature.
    Recalculable par un tiers
    Clé nécessaire

Trois champs, recalculables sans clé

L’empreinte d’entrée, l’empreinte de sortie et l’empreinte de l’événement de preuve précédent : trois champs, recalculables sans clé, à partir du reçu, du texte sur lequel ils ont été calculés et de l’événement précédent de la chaîne (dans le fichier d’exemple : sample_texts et preceding_event). Sans compte, sans accès à nos systèmes. Le quatrième champ, le code d’authentification, est calculé sous la clé symétrique que détient Audact et authentifie le reçu au regard de cette clé.

Ce recalcul est ce qui rend détectable une modification ultérieure d’un reçu, ou une réorganisation de la chaîne : les empreintes recalculées cessent de correspondre aux empreintes stockées.

Ouvrir l’explorateur de reçus

Limites de la preuve

Ce que montre chaque contrôle — et ce qu’il ne montre pas.

Chaque contrôle répond à une question, et aucun ne répond à celle d’un autre. Lu dans son propre périmètre, un enregistrement est exact.

  • Artefact ou contrôle

    Exemple de reçu

    L’empreinte d’entrée, l’empreinte de sortie et l’empreinte de l’événement de preuve précédent

    Opérationnel aujourd’huiPublic
    Ce qu’il montre
    Trois valeurs se recalculent à partir d’éléments du même fichier d’exemple — dans votre propre navigateur, sans clé.
    Ce qu’il ne montre pas
    Qui a émis le fichier, ni si quoi que ce soit a réellement été dit ou exécuté.
  • Artefact ou contrôle

    HMAC-SHA256 du reçu

    Opérationnel aujourd’hui
    Ce qu’il montre
    Un code d’authentification sous une clé symétrique propre à chaque locataire, détenue par Audact. Quiconque détient cette clé peut le contrôler.
    Ce qu’il ne montre pas
    Pas une signature à clé publique : il ne désigne aucun émetteur indépendant et n’offre aucune non-répudiation — quiconque peut le contrôler peut aussi le produire.
  • Artefact ou contrôle

    Chaîne de racines de Merkle

    Opérationnel aujourd’huiPublic
    Ce qu’il montre
    Les racines de Merkle sont publiées, chacune chaînée à la précédente, à api.audact.ai/v1/metachain. N’importe qui peut les lire sans clé ni compte.
    Ce qu’il ne montre pas
    L’inclusion d’un appel individuel : il faut pour cela le chemin de Merkle propre à cet appel, tiré de son rapport au titre de l’article 50, confronté à la bonne racine. Une racine seule ne prouve ni un appel ni un résultat. Les racines se trouvent sur le point d’accès propre à Audact ; aucun ancrage chez un tiers n’existe aujourd’hui.
  • Artefact ou contrôle

    Export signé ECDSA-P256

    Opérationnel aujourd’huiEarly Customer Program

    mesuré sur des appels par navigateur plutôt que sur une ligne téléphonique · testé à nouveau le 26 août 2026, après le déploiement

    Ce qu’il montre
    L’intégrité et l’authenticité du conteneur d’export lui-même, dans le cadre des hypothèses documentées de clé et de confiance, lorsqu’un contrôle extérieur à Audact réussit. Sa clé publique est servie à /v1/keys/{kid}.
    Ce qu’il ne montre pas
    Que chaque reçu qu’il contient soit contrôlable publiquement — les reçus gardent leur HMAC, que seul Audact peut contrôler — ni que les événements sous-jacents soient avérés. Aucune partie extérieure à Audact n’a encore contrôlé l’export de bout en bout.
  • Artefact ou contrôle

    Horodatage RFC 3161

    Ce qu’il montre
    Un horodatage rapporté par freeTSA.org pour l’empreinte qui lui a été transmise.
    Ce qu’il ne montre pas
    Pas un horodatage eIDAS qualifié : freeTSA.org est un service public gratuit, pas un service de confiance qualifié. Il ne dit rien de la survenue d’un événement métier.
  • Artefact ou contrôle

    C2PA, sur demande

    Opérationnel aujourd’huiEarly Customer Program
    Ce qu’il montre
    Un manifeste C2PA distinct pour l’enregistrement d’un appel : émis sur demande, lié à cet enregistrement par une empreinte et marqué comme généré par IA, dans le périmètre testé.
    Ce qu’il ne montre pas
    Qu’un manifeste C2PA distinct satisfait à l’article 50, paragraphe 2 pour un déploiement donné : l’obligation incombe au fournisseur du système générateur. Ni un filigrane intégré à l’audio, ni une émission automatique pour chaque appel, ni une chaîne de signature issue d’une autorité de certification tierce : aujourd’hui la chaîne s’arrête à une racine Audact.
  • Artefact ou contrôle

    Événement de résultat métier externe

    Résultat: Aucune source de clôture connectée
    Ce qu’il montre
    Une preuve uniquement dans les limites des droits et de la signification du système de référence qui le rapporte : prestataire de paiement, CRM, ERP ou agenda.
    Ce qu’il ne montre pas
    Il ne peut pas être déduit d’un seul reçu Audact. Un engagement inscrit dans un reçu est un engagement, pas un événement accompli.
Vérificateur publicPas encore disponibleAucun service ne contrôle aujourd’hui un reçu pour le compte d’un tiers.

06. Où se trouvent les données

L’hébergement, dans l’ordre qui compte

L’hébergement principal de l’application est Francfort. Le tableau indique, couche par couche, où tourne chaque partie du système et où traite chaque fournisseur.

Où tourne chaque couche
  • Couche
    Application et API
    Où
    Francfort
    Remarque
    Hébergement principal de l’application.
  • Couche
    Chaîne de preuves et reçus
    Où
    Francfort
    Remarque
    Conservés avec le locataire auquel ils appartiennent.
  • Couche
    Fournisseurs vocaux, de modèles et de téléphonie
    Où
    Selon le fournisseur
    Remarque
    Certains traitent en dehors de l’UE au titre de clauses contractuelles types (SCC).
  • Couche
    Racines de Merkle (publiées à api.audact.ai/v1/metachain)
    Où
    Point d’accès public
    Remarque
    Empreinte seule — aucun contenu lisible

La liste de référence

Le Centre de confiance nomme chaque sous-traitant ultérieur et le lieu où il traite, y compris ceux qui traitent aux États-Unis au titre de clauses contractuelles types. Cette liste est tenue à jour, elle fait autorité sur cette question, et cette page la suit.

Voir l’état actuel du produit

07. Ce que ce n’est pas

Trois choses que ce n’est pas, et les erreurs de lecture qu’elles évitent

Ce sont les trois hypothèses qui coûtent le plus cher quand elles ne sont pas contestées : chacune sonne comme un compliment, et chacune décrit un produit différent.

Pas une couche d’interception

Pas ceci

Rien de ce qui est décrit sur cette page n’est placé devant votre réseau, et rien ici ne lit de sa propre initiative un flux qui vous appartient.

Ce que c’est à la place

La porte décrite ici est un appel que votre système effectue, à un endroit de votre propre code que vous choisissez. Si votre système ne l’appelle pas, rien n’est évalué — et rien n’est enregistré non plus. La couverture est une propriété de l’endroit où vous placez l’appel, non quelque chose que le réseau vous accorde. L’application vocale gérée est l’autre forme : la pile vocale y est exploitée par Audact, de sorte que le contrôle se situe dans un parcours que nous exploitons plutôt qu’à un appel que vous placez. Savoir laquelle des deux s’applique se décide déploiement par déploiement.

Pas un coffre de clés pour vos systèmes

Pas ceci

Audact ne détient pas, ne renouvelle pas et ne remet pas les identifiants que vos systèmes utilisent entre eux, et ce n’est pas un endroit où garer une clé que vous préféreriez ne pas gérer.

Ce que c’est à la place

Le code d’authentification du reçu est calculé sous une clé symétrique que détient Audact. Ce que cette clé couvre est exposé champ par champ dans la section 05 ci-dessus.

Pas un grand livre

Pas ceci

La chaîne n’est pas un livre de comptes. Elle ne contient aucun solde, ne déplace aucun argent et ne compense aucune position entre deux parties.

Ce que c’est à la place

Elle enregistre ce qui a été décidé. Là où l’argent circule, il circule dans vos propres systèmes ; le reçu dit ce qui a été permis et ce qui a été enregistré, et reste en dehors de la comptabilité.

Suite

Recalculez-le vous-même

La façon la plus rapide de juger cette architecture n’est pas de lire plus loin. Ouvrez l’exemple détaillé, recalculez trois de ses valeurs dans votre propre navigateur, et voyez ce que ces calculs établissent et ce qu’ils n’établissent pas.

Ouvrir l’explorateur de reçusAPI Governance GateSécurité

Les mécanismes décrits sur cette page relèvent d’une pile d’encadrement en instance de brevet (UK IPO).