Passer au contenu principal
Quand un auditeur demande « prouvez que ces contrôles étaient réellement appliqués », une capture d’écran de votre console ne survivra pas à l’examen — elle n’est pas signée, elle est la vôtre, et elle est éditable. OrcaRouter génère un rapport de conformité signé : un pack de preuves autonome capturé depuis vos contrôles de passerelle en direct, hashé avec SHA256, et signé avec Ed25519 de sorte que quiconque détient le rapport peut vérifier qu’il a été produit par OrcaRouter et n’a pas été altéré depuis. Cette page parcourt le cas d’usage de bout en bout — générer le rapport, le remettre, et laisser l’auditeur le vérifier indépendamment. Pour le catalogue de frameworks et ce à quoi chaque pack correspond, voir Frameworks et Contenu du pack.

​
1. Ce que contient le rapport de conformité IA signé

Un rapport est généré par framework sur une fenêtre temporelle que vous choisissez, et capture huit sections de preuves au moment de la génération afin que l’artefact reste valide même après que les logs sous-jacents expirent sous votre politique de rétention.
Chaque rapport couvre les mêmes sections ordonnées afin que deux rapports soient comparables :
  • Coverage — à quels contrôles de framework vos packs installés correspondent, chacun tagué covered / observe / gap / attested.
  • Enforcement — les correspondances de guardrail et les verdicts firewall (allowed / blocked / audited) réellement enregistrés dans la fenêtre.
  • Consent — l’état de consentement enregistré pour la période, classé valide / périmé / révoqué / aucun.
  • Change log — l’historique des guardrails et les lignes d’audit de l’espace de travail sur la fenêtre.
  • Admin access — qui détenait l’admin et quelles actions privilégiées ont tourné.
  • Gaps — les contrôles non couverts, y compris les clauses organisationnelles (personnes/processus) qui ne peuvent jamais être automatisées par la passerelle. Le rapport les divulgue comme des lacunes honnêtes plutôt que de sous-entendre une conformité automatisée à 100 %.
  • AI supply chain — les fournisseurs amont (sous-traitants) et les modèles joignables par l’espace de travail, pour servir de preuve contre vos DPA.
  • Access reviews — les clés API de l’espace de travail et la liste des membres privilégiés pour l’hygiène de rotation des clés.
Le JSON de preuves canonique est hashé avec SHA256 (hex minuscule). Ce hash de contenu est signé avec Ed25519, et la signature plus un court id de clé (par ex. orca-…) sont intégrés dans l’artefact. Changez un octet de preuve et le hash ne correspond plus ; forgez le hash et la signature ne se vérifie plus contre la clé publique d’OrcaRouter.
  • PDF — la remise lisible par un humain pour l’auditeur, avec la signature et l’id de clé imprimés dessus.
  • JSON — l’export de preuves lisible par machine. (La signature est calculée sur une forme canonique des preuves, pas sur les octets bruts du fichier, donc vérifiez-la via l’endpoint public de vérification plutôt que de re-hasher l’artefact vous-même — voir Vérifier un rapport.)
  • CSV — export tabulaire plat pour les tableurs et l’outillage GRC.
Par défaut, les emails des membres et acteurs sont masqués dans chaque export. Optez explicitement pour des PII non rédigées par rapport lorsque votre auditeur en a besoin.
Les rapports sont estampillés par région. Chaque artefact est stocké et servi sous la région de résidence des données déclarée de votre espace de travail (us / eu / uk / ap / cn / global) ; un rapport produit pour une région n’est pas servi sous une autre. Définissez la résidence avant de générer si cela compte pour vos obligations.

​
2. Qui peut en générer un

Parcourir le catalogue de frameworks, les packs installés et la readiness est ouvert à chaque membre de l’espace de travail et est gratuit. Générer un rapport requiert le rôle Admin de l’espace de travail, et l’export est gardé par plan :
  • Le plan gratuit inclut un rapport PDF, pour que vous puissiez faire la démo de l’artefact.
  • L’export CSV / JSON et les rapports supplémentaires requièrent un plan payant.
Les deux règles sont appliquées côté serveur — il n’y a pas de contournement côté client uniquement.
Générez depuis la console : ouvrez Compliance → Reports, choisissez le framework et la fenêtre temporelle, choisissez un format, et cliquez sur générer. La génération est asynchrone — la ligne du rapport apparaît en pending, passe à generating, et atterrit en ready (ou failed, sans artefact partiel). Tout ceci tourne contre les routes /api/compliance/* sous votre session console — aucune clé de relais (sk-orca-…) n’est impliquée.

​
3. Un parcours concret

Un auditeur SOC 2 veut des preuves d’application pour le T1. Le workflow :
1

Installez le framework (une fois)

En tant qu’Admin sur un plan payant, installez le pack SOC 2 depuis Compliance → Frameworks. Installer matérialise les guardrails et les politiques firewall qui correspondent aux contrôles du framework. Voir Installer un pack.
2

Générez le rapport

Dans Compliance → Reports, sélectionnez soc2, réglez la période sur votre fenêtre T1, choisissez PDF, et générez. Attendez que la ligne atteigne ready, puis téléchargez.
3

Remettez-le à l'auditeur

Envoyez-lui le PDF (ou frappez un lien de partage auditeur en lecture seule pour qu’il le récupère lui-même). La signature et l’id de clé sont imprimés sur le rapport.
4

Il le vérifie indépendamment

L’auditeur n’a jamais à faire confiance à votre console. Il re-hashe les preuves, récupère la clé publique d’OrcaRouter, et vérifie la signature — le tout contre des endpoints publics et non authentifiés (section suivante).

​
4. Comment un auditeur le vérifie

La vérification ne nécessite aucun compte ni clé de relais — elle tourne contre deux endpoints publics sur api.orcarouter.ai. D’abord, récupérez la clé publique active : 
curl https://api.orcarouter.ai/api/public/compliance/pubkey
# => { "algo": "ed25519", "key_id": "orca-…", "public_key": "<base64>" }
Puis soumettez le hash de contenu du rapport, la signature et l’id de clé : 
curl -X POST https://api.orcarouter.ai/api/public/compliance/verify \
  -H "Content-Type: application/json" \
  -d '{
    "content_hash": "<sha256-hex from the report>",
    "signature":    "<base64 Ed25519 signature>",
    "sig_key_id":   "orca-…"
  }'
# => { "valid": true, "key_id": "orca-…" }
Un valid: true signifie que le hash de preuves a été signé par OrcaRouter et n’a pas changé depuis. Un auditeur qui préférerait ne pas appeler notre endpoint du tout peut prendre la clé publique Ed25519 publiée et vérifier la signature sur le hash avec n’importe quelle bibliothèque cryptographique standard — le rapport est vérifiable hors ligne.
Vous préférez ne pas envoyer le PDF en pièce jointe ? Frappez plutôt un lien de partage auditeur en lecture seule — une URL tokenisée qui sert le rapport (et sa signature) directement, sans connexion. Voir Exporter les preuves.

​
5. Où cela s’inscrit

Le rapport signé est l’artefact à la fin du flux de conformité. Les pièces autour de lui :

Frameworks

Le catalogue complet — SOC 2, HIPAA, GDPR, EU AI Act, ISO 27001/42001, NIST AI RMF, PCI DSS, OWASP LLM Top 10, et l’ensemble régional.

Installer un pack

Matérialisez les guardrails et politiques firewall d’un framework avant d’en faire un rapport.

Résidence des données

Estampillez et épinglez la région sous laquelle votre rapport signé est stocké et servi.

Vérifier un rapport

Le flux de vérification en profondeur — clé publique, hash et vérifications hors ligne.
Les preuves à l’intérieur du rapport proviennent des contrôles que vous avez configurés. Pour renforcer ce qui est rapporté, ajustez vos Guardrails et votre Firewall, et passez en revue la frontière de ce que la passerelle peut et ne peut pas attester dans Responsabilité partagée.