Risques, conformité et preuves

Cette page décrit comment la Navin Platform enregistre les risques de ses systèmes d'IA, recense ce qui est déployé, produit des preuves vérifiables et relie ses contrôles aux familles d'exigences des référentiels. La correspondance des domaines d'exigences du kit avec les audits et les jeux de preuves est dans ../operations/compliance-mapping.md ; elle n'est pas répétée ici. Code : services/control-plane/src/eai/domains/risk, services/control-plane/src/eai/domains/governance, services/control-plane/src/eai/domains/evidence.

English version: en/risk-compliance.md

Registre des risques

Évaluations

POST /v1/risk/assessments classe une cible (agent, modèle, application) selon l'AI Act européen à partir des cas d'usage et des réponses déclarés (eai.domains.risk.rules.classify) :

Catégorie	Déclencheur	Obligations enregistrées
unacceptable	Pratique interdite de l'article 5 (notation sociale, manipulation, reconnaissance des émotions au travail...)	Mise sur le marché et usage interdits
high	Domaine de l'annexe III ou composant de sécurité de l'article 6(1)	Articles 9 à 15, 27, 43 et 49
limited	Obligation de transparence de l'article 50	Transparence
minimal	Aucun déclencheur	Codes de conduite volontaires (article 95)

• Rôles : tenant_admin, security_officer, developer, ai_governance_officer créent ; seuls tenant_admin, security_officer et ai_governance_officer enregistrent une évaluation approved.
• La catégorie d'un agent est recopiée dans son risk_level (registre) ; une promotion d'un système à haut risque exige une évaluation approuvée (approvals.md).
• Lecture : GET /v1/risk/assessments. Chaque création est auditée (risk.assessment.create).

Contrôles et exceptions

• POST /v1/risk/controls (tenant_admin, security_officer) crée ou met à jour un contrôle du tenant : code, titre, référentiels (iso_42001, nist_ai_rmf, gdpr, eu_ai_act), statut (planned, implemented, partially_implemented, not_applicable), responsable, preuves jointes. Audit : risk.control.upsert.
• POST /v1/risk/exceptions (tenant_admin, security_officer, developer) accepte un écart sur un contrôle pour une cible : raison, contrôles compensatoires, approbateur nommé (jamais l'auteur, 409 separation_of_duties), échéance dans le futur et au plus 365 jours (422 invalid_exception). Une exception échue passe à expired.
• GET /v1/risk/evidence renvoie les preuves enregistrées et celles collectées automatiquement par la plateforme, rangées par contrôle.

Registre de gouvernance

GET /v1/governance/registry agrège l'inventaire du tenant : agent, model, provider, tool, skill, plugin, connector, avec nom, version, état et la catégorie AI Act évaluée quand elle existe. Le paramètre kind filtre ; un type inconnu répond 400. Ce registre est la source de preuve du contrôle EAI-GOV-01.

Preuves

Preuve	Mécanisme	Route
Chaîne d'audit	Hachage chaîné de chaque événement, écrit dans la transaction du changement	GET /v1/audit/verify
Sceaux	Racine de Merkle sha256, hachage du sceau précédent, signature Ed25519	GET /v1/evidence/seals, POST /v1/evidence/seals, GET /v1/evidence/seals/{seal_id}/verify, GET /v1/evidence/verify
Lot hors ligne	Manifeste signé par la clé des sceaux, vérifiable par python -m eai.domains.evidence.verify	GET /v1/evidence/bundle
Export WORM	Un NDJSON signé et un manifeste par tenant et par jour UTC (job audit_worm), ou export signé à la demande, stockage à verrouillage d'objet	POST /v1/audit/export
Configuration d'un run	Composants et configuration enregistrés pour un run	POST /v1/evidence/runs/{run_id}/components, GET /v1/evidence/runs/{run_id}/configuration
Journal d'accès	Chaque lecture, recherche, vérification et export audité	GET /v1/evidence/access-log
Preuves d'incident	Chaîne par incident et chaîne de possession, refus de UPDATE et DELETE	GET /v1/soc/incidents/{incident_id}/evidence, GET /v1/soc/incidents/{incident_id}/custody

Rôles : sceaux auditor, security_officer ; lecteurs de preuves auditor, security_officer, tenant_admin. Garanties et limites : audit-evidence.md ; mode opératoire du SIEM et du WORM : ../operations/siem-audit.md.

remarque

L'immuabilité du stockage n'est acquise qu'avec un profil de stockage audit_worm dont le verrouillage d'objet a été vérifié (POST /v1/storage/profiles/{profile_id}/verify). Sans lui, l'altération est détectée (chaîne, sceaux), pas empêchée.

Catalogue de contrôles

Le catalogue intégré (CATALOG dans services/control-plane/src/eai/domains/risk/rules.py) relie chaque contrôle de la plateforme aux références qu'il couvre. Les références ci-dessous sont celles du code, sans ajout.

Contrôle	Ce que la plateforme fait	ISO/IEC 42001	NIST AI RMF	RGPD	Source de preuve
EAI-GOV-01	Inventaire des systèmes d'IA avec responsables	A.4.2, A.3.2	GOVERN 1.6, MAP 1.1	Art. 30	governance_registry
EAI-RISK-01	Évaluation des risques et de l'impact avant déploiement	6.1.2, 6.1.4, A.5.2	MAP 5.1, MEASURE 1.1	Art. 35	risk_assessments
EAI-DATA-01	Classification et DLP sur prompts, sorties et médias	A.7.2, A.7.4	MAP 4.1, MANAGE 2.2	Art. 5(1)(c), Art. 25	dlp_rules
EAI-DATA-02	Limites de rétention et effacement des personnes	A.7.3	GOVERN 1.5	Art. 5(1)(e), Art. 17	retention
EAI-SEC-01	Chiffrement au repos par clé de tenant et rotation	A.6.2.4	MANAGE 2.4	Art. 32	encryption_keys
EAI-LOG-01	Piste d'audit inviolable des décisions d'IA	A.6.2.8	MEASURE 2.8, GOVERN 4.2	Art. 5(2)	audit_chain
EAI-QA-01	Évaluations et portes qualité bloquantes avant promotion	A.6.2.5, 9.1	MEASURE 2.3, MEASURE 2.5	aucune	evaluations
EAI-QA-02	Tests adverses (injection de prompt, jailbreak)	A.6.2.6	MEASURE 2.7, MANAGE 4.1	Art. 32	redteam
EAI-OPS-01	Gestion des incidents d'IA et kill switches	A.8.4, 10.2	MANAGE 4.3, GOVERN 6.2	Art. 33, Art. 34	incidents
EAI-HUM-01	Contrôle humain et approbations des actions sensibles	A.9.3	GOVERN 3.2, MANAGE 2.3	Art. 22	approvals

Familles d'exigences et contrôles de la plateforme

Famille d'exigences	Contrôles de la plateforme	Page
Identité, accès, séparation des tâches	OIDC, clés d'API, SPIFFE, rôles, OpenFGA, OPA, délégations, quatre yeux	authentication-authorization.md, approvals.md
Protection des données personnelles	Classification, DLP, tokenisation, rétention, effacement, consentements	retention-privacy.md, data-protection.md
Cryptographie et secrets	OpenBao, Transit, HSM PKCS#11, coffre-fort IT	secrets-vault.md
Journalisation et preuves	Chaîne d'audit, sceaux, WORM, chaîne de possession	audit-evidence.md
Réponse aux incidents	SOC, AI-SDR, kill switches, reprise à quatre yeux	soc-runbook.md, runbooks.md
Sécurité des entrées	Analyse des fichiers, détection d'injection, garde de sortie	file-security-pipeline.md, injection-matrix.md
Gestion des risques d'IA	Évaluations AI Act, contrôles, exceptions, registre	cette page

La conformité élément par élément à l'architecture de référence du client est suivie dans docs/implementation/conformance (par exemple docs/implementation/conformance/c14-audit-data-protection.yaml) : chaque élément cite ses chemins, ses tests et ses jeux de preuves, et son état n'est jamais écrit à la main.