Aller au contenu

Produit · Preuves de conformité

Statut des contrôles et preuves, mis en correspondance avec les référentiels

Le Module XIII lit l'activité que vous enregistrez déjà et la mappe à un statut par contrôle à travers des référentiels comme l'EU AI Act, NIST AI RMF et ISO/IEC 42001 — puis scelle les preuves dans un ledger append-only chaîné par hash. C'est un statut de contrôles et des preuves que vous pouvez remettre à un auditeur, pas une certification que nous délivrons.

Dans le produit

La console de conformité

Une capture d'écran authentique, avec des données d'exemple. Statut par contrôle dans chaque référentiel, couverture en un coup d'œil, la carte des capacités aux preuves et les paquets de preuves scellés ancrés au ledger. Chaque rapport porte la mention : il s'agit de statut de contrôles et de preuves, pas d'une certification.

Capture réelle
Console de conformité Olivares : statut par contrôle à travers les référentiels avec les états satisfied, by_design, partial, gap et unmapped ; un résumé de couverture, une carte des capacités aux preuves et des paquets de preuves scellés — renseignés avec des données d'exemple.

Ce qu’il produit

De l'activité à des preuves qu'un auditeur peut lire

Quatre résultats, chacun fondé sur ce que le ledger a réellement enregistré — et chacun étiqueté en toute honnêteté.

Statut par contrôle, pas un badge réussite/échec

Chaque contrôle se résout en l'un de cinq états — satisfied, by_design, partial, gap ou unmapped. « Satisfied » est adossé à une télémétrie opérationnelle réelle ; « by_design » est une garantie de conception qui n'a pas encore de télémétrie. Nous ne confondons jamais les deux : une promesse de conception n'est pas une preuve de fonctionnement.

Analyse des écarts et carte des capacités

L'analyse des écarts nomme les capacités qui vous manquent pour un contrôle donné ; la carte des capacités aux preuves montre quelle capacité produit quelle preuve. Un résumé inter-référentiels les consolide pour qu'un même contrôle réponde à plusieurs référentiels à la fois.

Paquets de preuves scellés

Les preuves sont exportées sous forme de paquets scellés ancrés au ledger append-only chaîné par hash — ainsi l'intégrité de ce que vous remettez est vérifiable, et toute modification ultérieure briserait la chaîne. La preuve appartient au ledger, ce n'est pas un document que nous vous demandons de croire sur parole.

Classification de risque des agents et résidence

Chaque agent est classé selon les niveaux de risque de l'EU AI Act, avec une mise en correspondance vers NIST AI RMF, aux côtés d'une attestation de résidence des données. Le niveau de risque et la résidence sont des données de preuve — ils alimentent le statut des contrôles, ils ne certifient pas le résultat.

Comment ça marche

L'activité devient une preuve mappée et scellée

Le ledger d'activité alimente un moteur de correspondance des contrôles, qui résout chaque contrôle en un statut ; le résultat est exporté sous forme de paquet de preuves mis en correspondance avec les référentiels. Ce qui est satisfied par la télémétrie et ce qui est by_design sont représentés comme des états distincts — jamais fusionnés en une seule coche verte.

Schéma : un ledger d'activité → un moteur de correspondance des contrôles → un paquet de preuves, mis en correspondance avec des référentiels comme EU AI Act, NIST AI RMF, ISO 42001, SOC 2.
La preuve est scellée au ledger append-only chaîné par hash — son intégrité est vérifiable, et toute modification ultérieure brise la chaîne.

Ce qui est réel

Le statut des contrôles et les preuves sont live ; la certification vous revient

Nous sommes précis sur ce point, car les mots ont une portée juridique :

  • Live, sur un contrat stable : statut par contrôle, analyse des écarts, la carte des capacités aux preuves, le résumé inter-référentiels, les paquets de preuves scellés, la classification de risque des agents et l'attestation de résidence des données.
  • Six familles de référentiels établis sont prises en charge — EU AI Act, NIST AI RMF, ISO/IEC 42001, SOC 2, ISO/IEC 27001 et le RGPD. Plusieurs autres références relèvent uniquement de l'approche design-toward — OWASP Agentic, CSA MAESTRO, les recommandations agentiques Five-Eyes de la CISA et les overlays NIST — et ne portent aucune affirmation de conformité ; la conception les suit, elle n'affirme pas la conformité à leur égard.
  • Ce n'est pas une certification. Olivares est en pre-release et n'est pas certifié SOC 2, ISO ni EU AI Act. Ce module vous fournit un statut de contrôles et des preuves pour appuyer une certification que vous choisissez de poursuivre ; il n'en délivre aucune, et l'absence de certification ne bloque pas la v1. Chaque rapport l'indique clairement.

Preuves de conformité — questions

Cela nous rend-il conformes ou certifiés ?

Non — et nous ne le prétendrons pas. Le Module XIII produit un statut de contrôles et des preuves : un état par contrôle dans chaque référentiel, plus des paquets de preuves scellés qu'un auditeur peut lire. La certification au regard de SOC 2, ISO ou de l'EU AI Act est un processus que vous menez avec un organisme certificateur ; Olivares lui-même est en pre-release et n'est pas certifié. Chaque rapport porte cette mention.

Quelle est la différence entre « satisfied » et « by_design » ?

« Satisfied » signifie que le contrôle est adossé à une télémétrie opérationnelle réelle — le ledger a enregistré l'activité qui le démontre. « By_design » signifie que l'architecture garantit le contrôle mais qu'aucune télémétrie ne l'a encore exercé. Ce sont délibérément des états distincts, car une promesse de conception n'équivaut pas à la preuve que quelque chose a fonctionné. Les autres états sont partial, gap et unmapped.

Quels référentiels sont réellement mappés ?

Six familles de référentiels établis : l'EU AI Act, NIST AI RMF, ISO/IEC 42001, SOC 2, ISO/IEC 27001 et le RGPD. Au-delà, la conception suit plusieurs références non finalisées — OWASP Agentic, CSA MAESTRO, les recommandations agentiques Five-Eyes de la CISA et les overlays NIST. Celles-ci, nous les étiquetons design-toward et nous ne faisons aucune affirmation de conformité à leur égard.

Comment puis-je savoir qu'un paquet de preuves n'a pas été modifié après l'export ?

Chaque paquet est scellé et ancré au ledger append-only chaîné par hash. L'intégrité est vérifiable au regard de la chaîne, de sorte qu'une modification ultérieure de la preuve — ou de l'activité sous-jacente — briserait le hash et se verrait. La confiance réside dans le ledger, pas dans un PDF que nous vous demandons de croire sur parole.

Remettez à un auditeur des preuves, pas des affirmations

Déployez Olivares sur votre propre infrastructure, mappez votre activité à un statut par contrôle à travers les référentiels, et exportez des preuves scellées ancrées au ledger.