Passer au contenu principal
La première question d’un auditeur n’est jamais « avez-vous une politique ? » — c’est « montrez-moi, clause par clause, quel contrôle la satisfait, et prouvez qu’il a tourné. » Une matrice de contrôles répond exactement à cela : une ligne par clause dans le périmètre, le plan auquel elle correspond, l’objet de politique vivant qui l’applique, et si ce contrôle est covered, encore en observe, une gap divulguée, ou attested par le propriétaire. OrcaRouter construit cette matrice pour vous à partir des packs que vous installez — la même correspondance qui alimente le rapport signé, de sorte que la vue de readiness et les preuves ne peuvent jamais dériver. Cette page montre comment lire et assembler la matrice de contrôles de conformité IA pour votre espace de travail, avec une clause concrète parcourue de bout en bout. Pour ce qu’un pack contient réellement, suivez les liens à la fin.

​
1. Ce qu’est ici une matrice de contrôles de conformité IA

La matrice est l’union de deux listes par framework :
  • les clauses qu’un pack installé couvre — chacune jointe à la politique guardrail ou firewall exacte que l’installation a matérialisée ;
  • les clauses qui ne peuvent jamais être automatisées par la passerelle — formation du personnel, Business Associate Agreements, accès physique — rédigées comme des gaps honnêtes de sorte que la matrice les divulgue plutôt que de sous-entendre un faux 100 %.
La matrice est une vue, pas un second moteur. Chaque ligne couverte pointe vers une règle guardrail ou une politique firewall réelle et éditable que vous possédez déjà — ouvrez-la, lisez-la, ajustez-la. La matrice enregistre juste laquelle répond à quelle clause.
Chaque clause correspond à exactement l’un de deux plans :

Plan guardrail

Les clauses de contenu — PII confidentielles, secrets, divulgations requises — correspondent à une règle guardrail avec une action block, mask ou flag.

Plan firewall

Les clauses d’action — agence excessive, appels d’outils dangereux, egress — correspondent à une règle firewall avec un verdict allow / audit / deny sur la surface inbound, response, mcp ou egress.

​
2. Les états de readiness qu’une ligne peut porter

Chaque ligne de matrice porte un état. Ce sont les mots qu’un auditeur lit, donc ils signifient exactement ce qu’ils disent :
ÉtatCe qu’il signifie
coveredUn contrôle de pack est installé et applique la clause.
observeInstallé mais log seul — collecte des preuves « aurait bloqué », n’applique pas encore.
gapAucun contrôle installé ne couvre la clause (ou elle est organisationnelle et ne peut l’être).
attestedUne clause organisationnelle qu’un Admin a attestée comme propriétaire plutôt qu’automatisée.
Une gap n’est pas un échec — c’est de l’honnêteté. Une clause organisationnelle comme la formation du personnel HIPAA 45 CFR §164.308(a)(5) ne peut jamais être appliquée par un proxy, donc la matrice la remonte comme une lacune divulguée (ou, une fois qu’un Admin atteste la propriété, comme attested) au lieu de prétendre que la passerelle la couvre.
Il y a aussi une superposition drift : si la correspondance d’un pack installé est en retard sur la version actuelle du catalogue, ses lignes s’affichent comme drift afin que vous sachiez qu’il faut réinstaller avant de vous fier aux preuves.

​
3. Lire la matrice (un appel concret)

L’endpoint de readiness renvoie toute la matrice — pourcentages de couverture par framework, les principaux risques classés sur la fenêtre, et une entrée coverage_rows par clause. Parcourir la readiness est ouvert à chaque Member de l’espace de travail et est gratuit, de sorte que vos relecteurs sécurité et audit peuvent surveiller la matrice sans accès en écriture. La console pilote cette route de gestion sous votre session — vous ne remettez jamais une clé de relais sk-orca-… à une route de conformité : 
GET /api/compliance/readiness?window=30d
Authorization: Bearer <your console session>
Une seule ligne couverte ressemble à ceci — clause, plan, état, et l’id de politique vivant auquel elle se joint : 
{
  "framework": "soc2",
  "control_id": "soc2.confidentiality",
  "clause": "TSC CC6.1 Logical access controls",
  "reference": "https://www.aicpa-cima.com/resources/...",
  "plane": "guardrail",
  "state": "covered",
  "guardrail_id": 41,
  "observe_count": 0,
  "organizational": false
}
Le guardrail_id (ou firewall_policy_id sur le plan firewall) est le champ porteur : il relie la clause directement à un objet que vous pouvez ouvrir dans la console et éditer comme n’importe quel autre. C’est la lignée qu’un auditeur parcourt — clause → id de contrôle → politique appliquante → les correspondances qu’elle a produites.
Lire la matrice est une capacité Member gratuite. La construire — installer un pack pour que ses contrôles peuplent les lignes — est une action d’Admin de l’espace de travail sur un plan payant, et le serveur applique les deux. Un viewer ou un espace de travail gratuit ne peut pas matérialiser une couverture en appelant l’API directement. Voir Plan gating.

​
4. Assembler la matrice pour vos frameworks

Vous construisez la matrice en installant des packs. Chaque installation fusionne ses contrôles en un guardrail et une politique firewall tagués avec la provenance du pack, et ses clauses commencent à peupler coverage_rows :
  1. Choisissez vos frameworks. L’installation se fait depuis la console sous Compliance → Catalog, en tant qu’Admin de l’espace de travail. Le catalogue couvre les régimes de sécurité et de gouvernance de l’IA (soc2, iso_27001, iso_42001, nist_ai_rmf, eu_ai_act, owasp_llm), les régimes sectoriels (hipaa, pci_dss, glba, nist_800_53), et un large ensemble de lois régionales sur la vie privée (gdpr, uk_gdpr, ccpa, et d’autres). Parcourez l’ensemble en direct sur Frameworks.
  2. Installez d’abord en observe. Une installation fraîche atterrit en mode observe — actions de guardrail contraintes à flag, politique firewall en shadow — de sorte que chaque nouvelle ligne commence comme observe et produit des preuves « aurait bloqué » avant d’appliquer.
  3. Regardez les lignes se remplir. Re-récupérez la readiness sur une fenêtre réelle. Les lignes couvertes montrent leur observe_count ; les lacunes restent divulguées ; les clauses organisationnelles attendent l’attestation.
  4. Passez en production. Lorsque les lignes se lisent propres, un Admin de l’espace de travail passe en production et les lignes observe basculent en application covered.
L’OWASP Top 10 for LLM Applications est dans le catalogue sous le pack owasp_llm — ses clauses (par exemple LLM05:2025 Supply Chain) atterrissent dans la matrice de la même façon que celles de tout autre framework, mises en correspondance avec des contrôles vivants ou divulguées comme lacunes. Voir OWASP LLM Top 10.

​
5. De la matrice aux preuves signées

La matrice que vous lisez dans la console est la même donnée de couverture que sérialise le rapport — de sorte que lorsque vous générez des preuves, l’auditeur voit les états par clause identiques, plus les comptes d’application que chaque contrôle a produits sur la période. Une clause qui a bloqué 4 000 requêtes et une clause avec zéro correspondance se lisent très différemment, et le rapport montre les deux. Les rapports sont hashés SHA-256, signés Ed25519, et publiquement vérifiables.
Les objets guardrail et firewall exacts qu’un pack matérialise, et comment chaque clause se joint à sa politique appliquante — voir Contenu du pack.
Pourquoi chaque ligne commence en observe, ce qu’elle journalise, et comment le passage en production la bascule — voir Observer vs appliquer.
Comment la matrice se restitue pour un auditeur, avec les états par clause et les comptes d’application — voir Rapport signé.

​
6. Où aller ensuite

Installer un pack

Le flux d’installation complet qui peuple la matrice — sélection des contrôles, mode observe, et passage en production.

Tous les frameworks

Le catalogue en direct des frameworks dont vous pouvez construire les clauses dans la matrice.

Guardrails vs Firewall

Les deux plans auxquels une ligne de matrice peut correspondre, et comment le résolveur les exécute ensemble.

Responsabilité partagée

Pourquoi certaines clauses sont applicables par la passerelle et d’autres restent les vôtres — la frontière que reflète chaque ligne de lacune.
Une matrice de contrôles est le pont entre la checklist d’un régulateur et votre passerelle en marche : une ligne par clause, jointe au contrôle vivant qui l’applique, honnête sur ce qu’un proxy ne peut couvrir, et identique aux preuves signées que vous remettez à un auditeur.