Risk, compliance and evidence

This page describes how the Navin Platform records the risks of its AI systems, inventories what is deployed, produces verifiable evidence and maps its controls to the requirement families of the frameworks. The mapping of the kit requirement domains to audits and evidence sets is in ../../operations/en/compliance-mapping.md; it is not repeated here. Code: services/control-plane/src/eai/domains/risk, services/control-plane/src/eai/domains/governance, services/control-plane/src/eai/domains/evidence.

Version française : ../risk-compliance.md

Risk register

Assessments

POST /v1/risk/assessments classifies a target (agent, model, application) under the European AI Act from the declared use cases and answers (eai.domains.risk.rules.classify):

Category	Trigger	Recorded obligations
unacceptable	Prohibited practice of Article 5 (social scoring, manipulation, emotion recognition at work...)	Placing on the market and use prohibited
high	Annex III area or safety component of Article 6(1)	Articles 9 to 15, 27, 43 and 49
limited	Transparency obligation of Article 50	Transparency
minimal	No trigger	Voluntary codes of conduct (Article 95)

• Roles: tenant_admin, security_officer, developer, ai_governance_officer create; only tenant_admin, security_officer and ai_governance_officer record an approved assessment.
• The category of an agent is copied into its risk_level (registry); promoting a high risk system needs an approved assessment (approvals.md).
• Read: GET /v1/risk/assessments. Every creation is audited (risk.assessment.create).

Controls and exceptions

• POST /v1/risk/controls (tenant_admin, security_officer) creates or updates a tenant control: code, title, frameworks (iso_42001, nist_ai_rmf, gdpr, eu_ai_act), status (planned, implemented, partially_implemented, not_applicable), owner, attached evidence. Audit: risk.control.upsert.
• POST /v1/risk/exceptions (tenant_admin, security_officer, developer) accepts a deviation from a control for a target: reason, compensating controls, named approver (never the author, 409 separation_of_duties), expiry in the future and at most 365 days (422 invalid_exception). An expired exception becomes expired.
• GET /v1/risk/evidence returns recorded evidence and evidence collected automatically by the platform, grouped by control.

Governance registry

GET /v1/governance/registry aggregates the tenant inventory: agent, model, provider, tool, skill, plugin, connector, with name, version, status and the assessed AI Act category when there is one. The kind parameter filters; an unknown kind answers 400. This registry is the evidence source of the EAI-GOV-01 control.

Evidence

Evidence	Mechanism	Route
Audit chain	Chained hash of every event, written in the transaction of the change	GET /v1/audit/verify
Seals	sha256 Merkle root, previous seal hash, Ed25519 signature	GET /v1/evidence/seals, POST /v1/evidence/seals, GET /v1/evidence/seals/{seal_id}/verify, GET /v1/evidence/verify
Offline bundle	Manifest signed by the seal key, verifiable with python -m eai.domains.evidence.verify	GET /v1/evidence/bundle
WORM export	One signed NDJSON and a manifest per tenant and per UTC day (audit_worm job), or a signed export on demand, object lock storage	POST /v1/audit/export
Run configuration	Components and configuration recorded for a run	POST /v1/evidence/runs/{run_id}/components, GET /v1/evidence/runs/{run_id}/configuration
Access log	Every read, search, verification and export audited	GET /v1/evidence/access-log
Incident evidence	Per incident chain and chain of custody, UPDATE and DELETE refused	GET /v1/soc/incidents/{incident_id}/evidence, GET /v1/soc/incidents/{incident_id}/custody

Roles: seals auditor, security_officer; evidence readers auditor, security_officer, tenant_admin. Guarantees and limits: audit-evidence.md; SIEM and WORM operations: ../../operations/en/siem-audit.md.

note

Storage immutability is only achieved with an audit_worm storage profile whose object lock was verified (POST /v1/storage/profiles/{profile_id}/verify). Without it, tampering is detected (chain, seals), not prevented.

Control catalogue

The builtin catalogue (CATALOG in services/control-plane/src/eai/domains/risk/rules.py) maps each platform control to the references it covers. The references below are those of the code, nothing added.

Control	What the platform does	ISO/IEC 42001	NIST AI RMF	GDPR	Evidence source
EAI-GOV-01	AI system inventory with accountable owners	A.4.2, A.3.2	GOVERN 1.6, MAP 1.1	Art. 30	governance_registry
EAI-RISK-01	AI risk and impact assessment before deployment	6.1.2, 6.1.4, A.5.2	MAP 5.1, MEASURE 1.1	Art. 35	risk_assessments
EAI-DATA-01	Data classification and DLP on prompts, outputs and media	A.7.2, A.7.4	MAP 4.1, MANAGE 2.2	Art. 5(1)(c), Art. 25	dlp_rules
EAI-DATA-02	Retention limits and data subject erasure	A.7.3	GOVERN 1.5	Art. 5(1)(e), Art. 17	retention
EAI-SEC-01	Encryption of data at rest with tenant keys and rotation	A.6.2.4	MANAGE 2.4	Art. 32	encryption_keys
EAI-LOG-01	Tamper evident audit trail of AI decisions	A.6.2.8	MEASURE 2.8, GOVERN 4.2	Art. 5(2)	audit_chain
EAI-QA-01	Evaluation and blocking quality gates before promotion	A.6.2.5, 9.1	MEASURE 2.3, MEASURE 2.5	none	evaluations
EAI-QA-02	Adversarial testing (prompt injection, jailbreak)	A.6.2.6	MEASURE 2.7, MANAGE 4.1	Art. 32	redteam
EAI-OPS-01	AI incident management and kill switches	A.8.4, 10.2	MANAGE 4.3, GOVERN 6.2	Art. 33, Art. 34	incidents
EAI-HUM-01	Human oversight and approvals for sensitive actions	A.9.3	GOVERN 3.2, MANAGE 2.3	Art. 22	approvals

Requirement families and platform controls

Requirement family	Platform controls	Page
Identity, access, separation of duties	OIDC, API keys, SPIFFE, roles, OpenFGA, OPA, delegations, four eyes	authentication-authorization.md, approvals.md
Personal data protection	Classification, DLP, tokenization, retention, erasure, consents	retention-privacy.md, data-protection.md
Cryptography and secrets	OpenBao, Transit, PKCS#11 HSM, IT vault	secrets-vault.md
Logging and evidence	Audit chain, seals, WORM, chain of custody	audit-evidence.md
Incident response	SOC, AI-SDR, kill switches, four eyes recovery	soc-runbook.md, runbooks.md
Input security	File scanning, injection detection, egress guard	file-security-pipeline.md, injection-matrix.md
AI risk management	AI Act assessments, controls, exceptions, registry	this page

Element by element conformance with the client reference architecture is tracked in docs/implementation/conformance (for example docs/implementation/conformance/c14-audit-data-protection.yaml): each element cites its paths, tests and evidence sets, and its state is never written by hand.