⚠️

STATIC ANALYSIS — Limited confidence Code and documentation were analysed statically — the audit engine did not execute the system live. Where session traces were provided, behavioural findings derive from those traces, not from live execution. Some verdicts rely on heuristic signals and are labelled accordingly; they may not reflect actual runtime behaviour. For a full technical dossier with executable evidence and SHA-256 seal, contact contact@factnotebook.com.

EU AI Act Compliance Audit — Technical Evidence Report

📋 Regulatory Report — For: regulators · DPO · CISO · auditors · compliance teams
For technical teams: see the Technical Forensic Report · For executives: see the Executive Report

System Identification

System Name: agents-for-openbb
Code Version: 1.0.0
Audit Date: 2026-06-17
Audit ID: CSVA-20260614-9BE11290
Audit Mode: ⚡ STATIC — DOC ↔ CODE
System Role (AI Act): provider
Audit LLM: deepseek/deepseek-chat
Static Fallback Rate: 0.0%

Regulatory Classification

Risk Level: [HIGH RISK] — EU AI Act Annex III

Compliance Verdict

⚠️ PARTIAL COMPLIANCE

Gate passed · Maturity below threshold

Decision Summary

Layer	Value	Assessment
Regulatory verdict	PARTIAL EVIDENCE	Gate passed · Maturity below threshold
Raw Maturity Score (pre-gates)	79.3/100	Weighted average across 7 articles — before gate penalties
Regulatory Final Score (gates applied)	57.2/100	After gate kill-switches, coverage factor, and proof factor · Partial (50-74)
Deployment threshold	75/100	EU AI Act conformance baseline

⚖️ AI ACT APPLICABILITY ASSESSMENT

This section establishes what is known and unknown about the regulatory scope
before presenting compliance findings. An auditor will ask these questions.

Question	Status	Notes
Project analysed	✅	agents-for-openbb — 🕸️ MICRO-MESH topology
Intended use case	❓	Not declared in scanned files
Deployment context	❓	Unknown — library or deployed system?
Regulatory classification	⚠️	Assumed HIGH (conservative default)
Annex III use case confirmed	❓	Requires manual review
Conformity assessment required	❓	Depends on deployment context

This project appears to be a deployable AI system. High-Risk obligations apply directly if deployed in an Annex III context.

What this audit covers:
- Technical compliance evidence within the scanned codebase
- Governance documentation presence/absence
- Code-level implementation of required controls

What this audit does NOT determine:
- Whether this system is actually deployed in a regulated context
- The legal obligation status of the deploying organisation
- Whether a Notified Body assessment is required

Scores below assume the system is deployed in a High-Risk context (Art. 6 + Annex III).
If this is a research library, governance obligations fall primarily on the deploying organisation.

0. 📊 CAMSVA MULTI-AXIS VERDICT

Summary table

Axe	Verdict	Indicateur
🏛️ Regulatory Compliance	🟢 COMPLIANT	All regulatory gates are satisfied.
🔍 Technical Sincerity	🟢 ÉLEVÉE	87.3%
🧪 Runtime Robustness	— NON ÉVALUÉ	Mode STATIC
📊 Audit Coverage	🔴 LIMITED	53.8% (29/54 checkpoints)
⭐ Assurance Level	Tier A/B — Technical evidence solides	81.0%

Per-article detail

✅ Art. 10 (critical gate) : 92/100 🛠️ DOC DEBT
⚠️ Art. 12 : 0/100 N/A
✅ Art. 13 : 100/100 🛠️ DOC DEBT
✅ Art. 14 (critical gate) : 85/100 🛠️ DOC DEBT
✅ Art. 15 (critical gate) : 85/100 🛠️ DOC DEBT
✅ Art. 9 (critical gate) : 92/100 🛠️ DOC DEBT

AXIS 2 — Technical Sincerity: 🟢 ÉLEVÉE (87.3%)

SCI (Semantic Collision Index): 100.0% — active CODE↔DOC contradictions
IntegrityGap: 1.9% — controls with no real technical evidence
Dissonances detected: 0

Les déclarations sont corroborées par les preuves techniques.

AXIS 3 — Runtime Robustness: — NON ÉVALUÉ

Mode STATIC — sandbox non exécuté. Relancez avec --mode full pour activer cet axe.

AXIS 4 — Coverage: 🔴 LIMITED · 53.8%

Checkpoints covered: 29/54
Active DOC↔CODE collisions: 0

Only 29/54 checkpoints covered — incomplete audit.

AXIS 5 — Assurance: Tier A/B — Technical evidence solides · 81.0%

Preuves de haute qualité (code + doc alignés).

1. 🧨 EXECUTIVE SUMMARY

FINAL VERDICT

⚠️ PARTIAL TECHNICAL ALIGNMENT (57/100 — threshold: 75)

📌 DECISION SYNTHESIS

Layer Value Detail

Regulatory verdict ⚠️ PARTIAL EVIDENCE Evidence maturity below deployment threshold (57/100 — threshold: 75)

Regulatory Final Score (gates applied) 57.17/100 🟡 Partial (threshold : 75) · After gate kill-switches, coverage factor, and proof factor

DOC↔CODE Sincerity 🟢 TRUSTED (100.0%) Declared vs implemented alignment

Recommended decision P1 remediation required. Controls present but evidence incomplete.

Key finding : No sufficient technical evidence identified within the analyzed scope for: Article 12.

Algorithmic sincerity analysis performed on 17/06/2026

Layer	Value	Detail
Regulatory verdict	⚠️ PARTIAL EVIDENCE	Evidence maturity below deployment threshold (57/100 — threshold: 75)
Regulatory Final Score (gates applied)	57.17/100	🟡 Partial (threshold : 75) · After gate kill-switches, coverage factor, and proof factor
DOC↔CODE Sincerity	🟢 TRUSTED (100.0%)	Declared vs implemented alignment
Recommended decision	P1 remediation required. Controls present but evidence incomplete.

📊 KEY INDICATORS (KPIs)

This report does not only produce a score. It produces verifiable technical evidence, re-executable tests, and a cryptographically sealed dossier.

Metric	Value	Meaning
Technical signals extracted	92	Facts collected from source code
Maturity score	46 checkpoints	Articles 9–15 EU AI Act (Annex III)
Controls Failing Verification	0	Active evidence of control absence (not just missing evidence)
Evidence Gaps (NOT OBSERVED)	14	No evidence found in audit scope — does not assert absence
Raw Maturity Score (pre-gates)	79 / 100	Weighted average across 7 articles — before gate penalties
Unsupported Documentation Ratio	100.00%	🚨 CRITICAL — Share of documented controls without technical implementation evidence — 100% = no documented control is technically corroborated

Interpretation : Critical divergence detected between documented controls and technical implementation.

🔥 TOP 3 BUSINESS RISKS

REGULATORY: Regulatory exposure increased due to critical deficiencies under Article 12 (record-keeping). Process mining shows 0% strict compliance over 20 sessions, with all sessions non-compliant. No audit trail evidence was found, undermining the ability to demonstrate conformity to regulators.
OPERATIONAL: Deployment approval risk — Article 12 documentation fidelity is critically low at 57.17/100, indicating poor doc-code consistency. This gap may delay or block market placement as regulators require robust evidence of record-keeping before authorization.
REPUTATIONAL: Technical audit trail insufficient for due diligence by enterprise customers or potential acquirers requiring AI Act conformity evidence. The 100% non-compliance rate in audit trail logging erodes trust and may deter partnerships or investments.

🎯 RECOMMENDED DECISION

❌ EVIDENCE INSUFFICIENT — Available technical evidence is insufficient to support a positive assessment within the analyzed scope. Technical remediation required.

Immediate action : Priority remediation on critical gaps before deployment in regulated context.
Next step : Technical architecture review (see Section 7).

2. ⚖️ REGULATORY POSITIONING

AI ACT CLASSIFICATION

Category: > ## High-Risk AI System (Annex III / Art. 6)

Parameter	System Analysis
Impact level	Strict compliance, third-party audit and CE marking mandatory.
Identified exposure	Critical sectors (Health, Education, HR, Infrastructure).

📖 PLAIN-LANGUAGE READING

"Votre système d'IA est classé à haut risque selon l'AI Act, ce qui nécessite une conformité stricte. Avec un score de 79,3/100, des améliorations sont encore nécessaires pour atteindre la pleine conformité."

⚠️ EXPOSURE ANALYSIS

Analysis of the codebase and dependencies indicates that the system falls within the scope of the European AI legislation.

Impact of sustained non-compliance:
* Financial penalties: Up to €35 million or 7% of total worldwide annual turnover.
* Operational penalties: Ban from the European market and obligation to delete models trained on non-compliant data.

🔬 CAMSVA VERIFICATION SCOPE

EPISTEMIC NOTE
The CAMSVA score is a Technical Verifiability Score (TVS) of 57.2/100.
It does not certify full regulatory compliance in the sense of the EU AI Act.
It measures technical alignment on the elements verifiable by automated analysis.

This score covers 38 checkpoints verifiable by technical analysis (out of 54 total checkpoints).
The 16 remaining checkpoints require human attestation (see below).

✅ What CAMSVA verifies (static analysis + execution)

Control	Verification method
Presence of code implementing the controls	Static AST analysis + LLM
Audit log structure (format, fields)	JSONL / structural parsing
Input validation (schema, types)	Pydantic / jsonschema detection
HITL mechanisms active in the code	HITL pattern detection
Model integrity (SHA-256 checking)	Import / load-pattern analysis
DOC↔CODE alignment (semantic collisions)	Semantic collision engine
Decision traceability (audit trails)	Log structure analysis
Sandbox execution tests (FULL mode)	Isolated pytest, READ-ONLY

⚠️ What CAMSVA cannot verify (human attestation required)

Out-of-scope control	Article	Reason
Competence and training of HITL operators	Art. 14 §5	Human quality not verifiable by code
Real representativeness of training data	Art. 10 §3	Requires domain expertise
Effectiveness of organisational processes	Art. 9 §7	Practice vs written procedure
Actual notification to competent authorities	Art. 73	External administrative process
AI governance (committees, training, culture)	Art. 9	Organisational, not codifiable

These elements must be the subject of a formal declaration by the compliance officer,
complementing CAMSVA's technical evidence to constitute a complete dossier.

🧪 Generated tests — Activation required

In STATIC mode, execution tests are not run.
Re-run with --mode full to generate executable evidence artefacts
(re-runnable, signed artefacts that hold up before a regulatory auditor).

📊 Volume of evidence collected in this audit

Type	Count
Technical evidence (code, logs, config)	17
Documentary evidence (docs, notices)	0
Total facts extracted	92

⚖️ REGULATORY GATES — Deployment Authorisation

Regulatory Gates are the non-negotiable EU AI Act articles for high-risk systems.
A failure on any of them constitutes a deployment block, regardless of the overall maturity score.

Evidence Level Scale:
L0 No evidence · L1 Documentation only · L2 Code artefact · L3 DOC↔CODE match · L4 Runtime trace · L5 Cryptographic proof

Article	Score	Status	Evidence Level	Gate
Art. 9 — Risk Management	92%	✅ COMPLIANT	L0 (0%)	✅ Pass
Art. 10 — Data Governance	92%	✅ COMPLIANT	L0 (0%)	✅ Pass
Art. 14 — Human Oversight (HITL)	85%	⚠️ PARTIAL	L0 (0%)	✅ Pass
Art. 15 — Robustness & Cybersecurity	85%	⚠️ PARTIAL	L5 (100%)	✅ Pass

✅ ALL GATES PASSED — Technical alignment sufficient for deployment review

No blocking regulatory articles detected. > The system may proceed to formal conformity assessment.
Note: This is a technical alignment assessment, not a certification. > Formal EU AI Act compliance requires documentation completion and, for some Annex III uses, a Notified Body review.

3. 📊 COMPLIANCE TABLE (CORE PRODUCT)

TECHNICAL VERIFICATION MATRIX

This table cross-references AI Act requirements with your codebase reality. Unlike a declarative audit, each status below is correlated to evidence (code or documentation).

Article	Status	Score	Sincerity	Severity	Dominant Evidence	Type	Assurance	Audit State	Nature défaut
Article 12	❌ NON-COMPLIANT	0.00	N/A	🔴 CRITICAL	None	—	Tier E — Unsupported claim	MANQUEMENT	NO EVIDENCE OBSERVED IN AUDIT SCOPE
Article 14	⚠️ PARTIAL	85.00	🛠️ DOC DEBT	🟠 MAJOR	Authority Delegation	LOG_WORKFLOW	Tier A — Runtime · Tests · Code	STABLE	PARTIAL IMPLEMENTATION
Article 9	✅ COMPLIANT	92.50	🛠️ DOC DEBT	🟢 MINOR	Confidence-Based Human Routing	LOG_WORKFLOW	Tier A — Runtime · Tests · Code	STABLE	NO MAJOR DEFICIENCY
Article 15	⚠️ PARTIAL	85.00	🛠️ DOC DEBT	🟠 MAJOR	Contextual Memory Limitation	LOG_WORKFLOW	Tier A — Runtime · Tests · Code	STABLE	PARTIAL IMPLEMENTATION
Article 10	✅ COMPLIANT	92.50	🛠️ DOC DEBT	🟢 MINOR	Data Traceability	LOG_WORKFLOW	Tier A — Runtime · Tests · Code	STABLE	NO MAJOR DEFICIENCY
Article 13	✅ COMPLIANT	100.00	🛠️ DOC DEBT	🟢 MINOR	System Explainability	LOG_WORKFLOW	Tier A — Runtime · Tests · Code	STABLE	NO MAJOR DEFICIENCY
Article 73	✅ COMPLIANT	100.00	🛠️ DOC DEBT	🟢 MINOR	Serious Incident Notification Procedure	LOG_WORKFLOW	Tier A — Runtime · Tests · Code	STABLE	NO MAJOR DEFICIENCY

🔑 ASSURANCE INDICATOR GUIDE

Indicator	Meaning	Decision Impact
⚠️ ILLUSION	Critical divergence detected between documented controls and technical evidence.	Requires immediate remediation before any conformity assessment.
🛠️ DOC DEBT	Technically implemented but undocumented.	Operational risk in case of audit.
🛡️ AUDIT-READY	Technical evidence + Documentary evidence aligned.	Maximum confidence level.

Auditor's Note : A "FACADE" status on a High-Criticality article (Art. 10, 14, 15) indicates that the documentation claims compliance that the code does not support. This constitutes a significant regulatory risk whose precise assessment requires specialized legal counsel.

3-bis. 🌲 CONTROL HIERARCHY & DEPENDENCIES

This section shows the dependencies between controls.
A ⛔ BLOCKED control cannot be evaluated while its prerequisite is missing:
fixing the prerequisite automatically unblocks the child controls.

Article 9

❌ Risk Register · 0/1 ✅
❌ DYNAMIC_AUDIT — Dynamic test result for Risk Register: failed
⛔ Risk Matrix (⛔ bloqué — prérequis absent : Risk Register)
⛔ Risk Mitigation (⛔ bloqué — prérequis absent : Risk Register)
⛔ Continuous Monitoring (⛔ bloqué — prérequis absent : Risk Register)
⛔ Post-Market Plan (⛔ bloqué — prérequis absent : Risk Register)
🟡 Serious Incident Notification Procedure · 1/2 ✅
✅ feedback_sessions_2026_events.jsonl — No violations detected.
⚠️ DYNAMIC_AUDIT — Dynamic test result for Serious Incident Notification Procedure: skipped
⛔ Risk Ownership Assignment (⛔ bloqué — prérequis absent : Risk Register)
🟡 Confidence-Based Human Routing · 1/2 ✅
✅ feedback_sessions_2026_events.jsonl — Non-compliant sessions: fb-89F335E1
⚠️ DYNAMIC_AUDIT — Dynamic test result for Confidence-Based Human Routing: skipped

Article 10

❌ Data Inventory · 0/1 ✅
❌ DYNAMIC_AUDIT — Dynamic test result for Data Inventory: failed
⛔ Data Traceability (⛔ bloqué — prérequis absent : Data Inventory)
⛔ Data Cleansing & Anonymisation (⛔ bloqué — prérequis absent : Data Inventory)
⛔ Physical Dataset Existence (⛔ bloqué — prérequis absent : Data Inventory)
❌ Dataset Quality · 0/1 ✅
❌ DYNAMIC_AUDIT — Dynamic test result for Dataset Quality: failed
⛔ Bias Metrics (⛔ bloqué — prérequis absent : Dataset Quality)
⛔ Balancing & Representativeness (⛔ bloqué — prérequis absent : Dataset Quality)
❌ PII Masking Before External Transmission · 0/3 ✅
❌ feedback_sessions_2026_events.jsonl — Non-compliant sessions: fb-D534D661, fb-89F335E1, fb-3899A858, fb-6F43C4DE, fb-BB281A1F
⚠️ DYNAMIC_AUDIT — Dynamic test result for PII Masking Before External Transmission: skipped

Article 11

🟡 System Architecture · 1/2 ✅
✅ DYNAMIC_AUDIT — Dynamic test result for System Architecture: passed
❌ Model Card · 0/1 ✅
❌ DYNAMIC_AUDIT — Dynamic test result for Model Card: failed
⛔ System Explainability (⛔ bloqué — prérequis absent : Model Card)
⛔ Limitations Disclosure (⛔ bloqué — prérequis absent : Model Card)
❌ Version Management · 0/1 ✅
⚠️ DYNAMIC_AUDIT — Dynamic test result for Version Management: skipped

Article 12

❌ Logging Implementation · 0/1 ✅
❌ DYNAMIC_AUDIT — Dynamic test result for Logging Implementation: failed
⛔ Audit Trail (⛔ bloqué — prérequis absent : Logging Implementation)
⛔ Decision Record Structure (⛔ bloqué — prérequis absent : Logging Implementation)
❌ Storage Definition · 0/1 ✅
⚠️ DYNAMIC_AUDIT — Dynamic test result for Storage Definition: skipped
⛔ Real Execution Traces (⛔ bloqué — prérequis absent : Storage Definition)
⛔ Log Retention Policy (⛔ bloqué — prérequis absent : Storage Definition)
❌ Logging Integrity · 0/1 ✅
❌ DYNAMIC_AUDIT — Dynamic test result for Logging Integrity: failed

Article 13

❌ User Notice · 0/1 ✅
❌ DYNAMIC_AUDIT — Dynamic test result for User Notice: failed

Article 14

❌ Human Decision Endpoint · 0/1 ✅
⚠️ DYNAMIC_AUDIT — Dynamic test result for Human Decision Endpoint: skipped
❌ Human Approval Gates Execution · 0/1 ✅
⚠️ DYNAMIC_AUDIT — Dynamic test result for Human Approval Gates Execution: skipped
❌ Automatic Blocking Linked to Human Rejection · 0/2 ✅
❌ feedback_sessions_2026_events.jsonl — Non-compliant sessions: fb-D534D661, fb-89F335E1, fb-3899A858, fb-6F43C4DE, fb-BB281A1F |
⚠️ DYNAMIC_AUDIT — Dynamic test result for Automatic Blocking Linked to Human Rejection: skipped
❌ Full Workflow Integration · 0/1 ✅
⚠️ DYNAMIC_AUDIT — Dynamic test result for Full Workflow Integration: skipped
❌ Human Validation · 0/2 ✅
❌ feedback_sessions_2026_events.jsonl — Non-compliant sessions: fb-D534D661, fb-89F335E1, fb-3899A858, fb-6F43C4DE, fb-BB281A1F |
❌ DYNAMIC_AUDIT — Dynamic test result for Human Validation: failed
⛔ Escalation to Human (⛔ bloqué — prérequis absent : Human Validation)
⛔ User Override (⛔ bloqué — prérequis absent : Human Validation)
🟡 Human-in-the-Loop Mechanism · 1/3 ✅
✅ feedback_sessions_2026_events.jsonl — No violations detected.
⚠️ DYNAMIC_AUDIT — Dynamic test result for Human-in-the-Loop Mechanism: skipped
❌ Agent Tool Scope · 0/2 ✅
⚠️ DYNAMIC_AUDIT — Dynamic test result for Agent Tool Scope: skipped
🟡 Authority Delegation · 1/3 ✅
✅ feedback_sessions_2026_events.jsonl — No violations detected.
⚠️ DYNAMIC_AUDIT — Dynamic test result for Authority Delegation: skipped

Article 15

❌ Unsafe Serialization Formats · 0/2 ✅
⚠️ DYNAMIC_AUDIT — Dynamic test result for Unsafe Serialization Formats: skipped
❌ Secure Format Policy · 0/1 ✅
⚠️ DYNAMIC_AUDIT — Dynamic test result for Secure Format Policy: skipped
⛔ Input Robustness (⛔ bloqué — prérequis absent : Secure Format Policy)
⛔ Cybersecurity Audit (⛔ bloqué — prérequis absent : Secure Format Policy)
❌ Error Handling · 0/2 ✅
⚠️ DYNAMIC_AUDIT — Dynamic test result for Error Handling: skipped
✅ Component Obsolescence · 1/1 ✅
✅ DYNAMIC_AUDIT — Dynamic test result for Component Obsolescence: passed
❌ Prompt Guardrail / Injection Detection · 0/2 ✅
⚠️ DYNAMIC_AUDIT — Dynamic test result for Prompt Guardrail / Injection Detection: skipped
🟡 Contextual Memory Limitation · 1/3 ✅
✅ feedback_sessions_2026_events.jsonl — No violations detected.
⚠️ DYNAMIC_AUDIT — Dynamic test result for Contextual Memory Limitation: skipped
🟡 Execution Limits (Guardrails) · 1/3 ✅
✅ feedback_sessions_2026_events.jsonl — No violations detected.
⚠️ DYNAMIC_AUDIT — Dynamic test result for Execution Limits (Guardrails): skipped
❌ Bypass Detection · 0/3 ✅
❌ feedback_sessions_2026_events.jsonl — Non-compliant sessions: fb-D534D661, fb-89F335E1, fb-3899A858, fb-6F43C4DE, fb-BB281A1F
⚠️ DYNAMIC_AUDIT — Dynamic test result for Bypass Detection: skipped

Article 25

❌ Provider Identity · 0/1 ✅
⚠️ DYNAMIC_AUDIT — Dynamic test result for Provider Identity: skipped
⛔ Deployer Identity (⛔ bloqué — prérequis absent : Provider Identity)

Article 26

Article 73

4. 🔍 SINCERITY ANALYSIS (Reliability Index of Compliance Declarations)

FINDING : 12.7% SINCERITY GAP

The sincerity analysis measures the correlation between compliance declarations (DOC) and algorithmic reality (CODE).

Sincerity Verdict :

🟠 GOVERNANCE MATURITY GAP

📐 FORMAL METRICS — REGULATORY EVIDENCE ENGINE

Indicator	Value	Status	Interpretation
DFI (Documentation Fidelity Index)	100.0%	🟢	DOC↔CODE truthfulness: 100% = no false claims in documentation
Evidence Coverage Gap	1.9%	🟢	Controls with no evidence in audit scope — distinct from DFI
RuntimeConfidence	72.5%	🟡	Test pass rate — FULL mode only (N/A in STATIC)
Composite Sincerity	87.3%	🟢	DOC↔CODE alignment score
Audit mode	STATIC	—	STATIC = DOC↔CODE analysis · FULL = + runtime execution

Metrics computed from artefacts in audit scope. In STATIC mode, runtime-dependent metrics (RuntimeConfidence) are unavailable. All metrics are anchored in the SHA-256 seal (Section 10).
Note: Exact figures reflect the analysed artefact set — not the full system boundary.

🧠 AUDITOR INTERPRETATION

Situation : Significant gap: important compliance commitments are not found in the code.

Sincerity-related risks : MODERATE. The file is vulnerable. An urgent update of the implementation is required.

🛠️ CORRELATION ANALYSIS (TOP 3)

No major contradiction detected between code and documentation.

📊 EVIDENCE BREAKDOWN

Documentary Evidence (Declarations) : 0 control points cited.
Technical Evidence (Reality) : 17 verified implementations.
Code-Backed Evidence : 17 — checkpoints where source code artifacts were directly observed (function definitions, API implementations, test files). This is the strongest form of static evidence.

checkpoints supported by documentation claims, configuration files, or structural inference only — no source code artifact was directly linked. This does not mean controls are absent; they may exist in code not provided, in external services, or in formats not machine-readable.

Compliance without technical sincerity is legally riskier than non-compliance with honest documentation.

🧾 Evidence Ledger — Regulatory traceability register

CAMSVA Multi-Source Correlation · Triangulation Code × Doc × Tests × Runtime

Indicator	Value
Control points analysed	31
Documentary facades detected	0
Skeleton Ratio (Structural density)	100%

Checkpoint	Article	Sources (Technical)	Code	Internal Doc	Test Trace	Execution Trace	Seal	Sincerité globale
Audit Trail	N/A	Dossier global	NOT OBSERVED	NOT OBSERVED	❌ ÉCHOUÉ (1)	🔴 20 sess. · 0%✅ · 100%❌	-	⬛NON-COMPLIANTNONEXISTENT CONTROL**
Automatic Blocking Linked to Human Rejection	N/A	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 0❌	🔴 20 sess. · 0%✅ · 3⚠️ · 85%❌	-	⬛NON-COMPLIANTNONEXISTENT CONTROL**
Confidence-Based Human Routing	N/A	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 0❌	🟢 20 sess. · 95%✅ · 5%❌	-	⬛⚠️ UNVERIFIABLE — Activity signals detected but no source implementationNONEXISTENT CONTROL**
Contextual Memory Limitation	N/A	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 1❌	🟢 20 sess. · 100%✅	-	⬛⚠️ UNVERIFIABLE — Activity signals detected but no source implementationNONEXISTENT CONTROL**
Data Cleansing & Anonymisation	N/A	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 0❌	🟢 20 sess. · 100%✅	-	⬛⚠️ UNVERIFIABLE — Activity signals detected but no source implementationNONEXISTENT CONTROL**
Decision Record Structure	N/A	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 1❌	⚠️ 20 sess. · 85%✅ · 3⚠️	-	⬛NON-COMPLIANTNONEXISTENT CONTROL**
Authority Delegation	N/A	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 1❌	🟢 20 sess. · 100%✅	-	⬛⚠️ UNVERIFIABLE — Activity signals detected but no source implementationNONEXISTENT CONTROL**
Bypass Detection	N/A	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 1❌	🔴 20 sess. · 15%✅ · 85%❌	-	⬛NON-COMPLIANTNONEXISTENT CONTROL**
Human-in-the-Loop Mechanism	N/A	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 1❌	🟢 20 sess. · 100%✅	-	⬛⚠️ UNVERIFIABLE — Activity signals detected but no source implementationNONEXISTENT CONTROL**
Escalation to Human	N/A	Dossier global	NOT OBSERVED	NOT OBSERVED	❌ ÉCHOUÉ (1)	🟢 20 sess. · 100%✅	-	⬛⚠️ UNVERIFIABLE — Activity signals detected but no source implementationNONEXISTENT CONTROL**
Human Validation	N/A	Dossier global	NOT OBSERVED	NOT OBSERVED	❌ ÉCHOUÉ (1)	🔴 20 sess. · 0%✅ · 3⚠️ · 85%❌	-	⬛NON-COMPLIANTNONEXISTENT CONTROL**
Execution Limits (Guardrails)	N/A	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 1❌	🟢 20 sess. · 100%✅	-	⬛⚠️ UNVERIFIABLE — Activity signals detected but no source implementationNONEXISTENT CONTROL**
User Override	N/A	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 1❌	🟢 20 sess. · 100%✅	-	⬛⚠️ UNVERIFIABLE — Activity signals detected but no source implementationNONEXISTENT CONTROL**
PII Masking Before External Transmission	N/A	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 1❌	🔴 20 sess. · 0%✅ · 100%❌	-	⬛NON-COMPLIANTNONEXISTENT CONTROL**
Agent Tool Scope	Article 14	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 1❌	NOT OBSERVED	-
Unsafe Serialization Formats	Article 15	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 1❌	NOT OBSERVED	-
Error Handling	Article 15	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 1❌	NOT OBSERVED	-
Prompt Guardrail / Injection Detection	Article 15	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 1❌	NOT OBSERVED	-
Risk Mitigation	Article 9	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 1❌	NOT OBSERVED	-
Logging Implementation	Article 12	Dossier global	NOT OBSERVED	NOT OBSERVED	❌ ÉCHOUÉ (1)	NOT OBSERVED	-
Logging Integrity	Article 12	Dossier global	NOT OBSERVED	NOT OBSERVED	❌ ÉCHOUÉ (1)	NOT OBSERVED	-
Component Obsolescence	Article 15	Dossier global	NOT OBSERVED	NOT OBSERVED	✅ PASSÉ (1)	NOT OBSERVED	-
Continuous Monitoring	Article 9	Dossier global	NOT OBSERVED	NOT OBSERVED	❌ ÉCHOUÉ (1)	NOT OBSERVED	-
Physical Dataset Existence	Article 10	Dossier global	NOT OBSERVED	NOT OBSERVED	❌ ÉCHOUÉ (1)	NOT OBSERVED	-
Balancing & Representativeness	Article 10	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 0❌	NOT OBSERVED	-
Input Robustness	Article 15	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 1❌	NOT OBSERVED	-
Real Execution Traces	Article 12	Dossier global	NOT OBSERVED	NOT OBSERVED	❌ ÉCHOUÉ (1)	NOT OBSERVED	-
Cybersecurity Audit	Article 15	Dossier global	NOT OBSERVED	NOT OBSERVED	✅ PASSÉ (1)	NOT OBSERVED	-
Human Decision Endpoint	Article 14	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 0❌	NOT OBSERVED	-
Human Approval Gates Execution	Article 14	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 0❌	NOT OBSERVED	-
Full Workflow Integration	Article 14	Dossier global	NOT OBSERVED	NOT OBSERVED	⚠️ PARTIAL 0✅ / 0❌	NOT OBSERVED	-

📊 COMPLIANCE DASHBOARD (EU AI ACT PILLARS)

Section	Score	Status
I. Stratégie & Gouvernance	92.5%	🟢 COMPLIANT
II. Ingénierie des Données	92.5%	🟢 COMPLIANT
III. Transparence & Interface	61.7%	🟡 PARTIAL
IV. Résilience & Cybersécurité	85.0%	🟢 COMPLIANT

🛰️ Confrontation & Sincerity Report

Cross-analysis between declared commitments and technical reality.

N/A - Audit Trail

Sincerity Verdict: ⬛NON-COMPLIANTNONEXISTENT CONTROL
* Technical Evidence (Code) : NOT OBSERVED
* Documentary Evidence : NOT OBSERVED
* Execution Evidence : EVIDENCE INSUFFICIENT
* Tests — result : ❌ ÉCHOUÉ (1)
* External Evidence :** NOT OBSERVED

🔬 Runtime — Process Mining Analysis (Behavioral Audit) :
* Sample : 2026-04-04 → 2026-04-05 (2j)
* Sessions analysed : 20
* ✅ Compliant : 0 (0.0%)
* ⚠️ Partial : 0
* 🔴 Non-compliant : 20 (100.0%)
* Sessions NOK : fb-D534D661, fb-89F335E1, fb-3899A858, fb-6F43C4DE, fb-BB281A1F, fb-FA3E3725, fb-193F126A, fb-3ABD45B7, fb-1ACF4C41, fb-9318008E, hitl-222B705F, hitl-ED2A6C5D, hitl-26E4C429, fb-9EC3B248, fb-E439D5BF, fb-5F56C6CC, fb-659B8219, fb-E3B62030, fb-F7C43BE4, fb-8111D2BC

Detailed analysis :
* ⚠️ FACADE WITHOUT TEST: No test validates the declared compliance.

N/A - Automatic Blocking Linked to Human Rejection

Sincerity Verdict: ⬛NON-COMPLIANTNONEXISTENT CONTROL
* Technical Evidence (Code) : NOT OBSERVED
* Documentary Evidence : NOT OBSERVED
* Execution Evidence : EVIDENCE INSUFFICIENT
* Tests — result : ⚠️ PARTIAL 0✅ / 0❌
* External Evidence :** NOT OBSERVED

🔬 Runtime — Process Mining Analysis (Behavioral Audit) :
* Sample : 2026-04-04 → 2026-04-05 (2j)
* Sessions analysed : 20
* ✅ Compliant : 0 (0.0%)
* ⚠️ Partial : 3
* 🔴 Non-compliant : 17 (85.0%)
* Sessions NOK : fb-D534D661, fb-89F335E1, fb-3899A858, fb-6F43C4DE, fb-BB281A1F, fb-FA3E3725, fb-193F126A, fb-3ABD45B7, fb-1ACF4C41, fb-9318008E, fb-9EC3B248, fb-E439D5BF, fb-5F56C6CC, fb-659B8219, fb-E3B62030, fb-F7C43BE4, fb-8111D2BC

Detailed analysis :
* ⚠️ FACADE WITHOUT TEST: No test validates the declared compliance.

N/A - Confidence-Based Human Routing

Sincerity Verdict: ⬛⚠️ UNVERIFIABLE — Activity signals detected but no source implementationNONEXISTENT CONTROL
* Technical Evidence (Code) : NOT OBSERVED
* Documentary Evidence : NOT OBSERVED
* Execution Evidence : OBSERVED
* Tests — result : ⚠️ PARTIAL 0✅ / 0❌
* External Evidence :** NOT OBSERVED

🔬 Runtime — Process Mining Analysis (Behavioral Audit) :
* Sample : 2026-04-04 → 2026-04-05 (2j)
* Sessions analysed : 20
* ✅ Compliant : 19 (95.0%)
* ⚠️ Partial : 0
* 🔴 Non-compliant : 1 (5.0%)
* Sessions NOK : fb-89F335E1

Detailed analysis :
* ⚠️ FACADE WITHOUT TEST: No test validates the declared compliance.
* 🚨 GHOST : Les logs simulent une réussite alors que le code source est absent ou invalide.

N/A - Contextual Memory Limitation

🔬 Runtime — Process Mining Analysis (Behavioral Audit) :
* Sample : 2026-04-04 → 2026-04-05 (2j)
* Sessions analysed : 20
* ✅ Compliant : 20 (100.0%)
* ⚠️ Partial : 0
* 🔴 Non-compliant : 0 (0.0%)

Detailed analysis :
* ⚠️ FACADE WITHOUT TEST: No test validates the declared compliance.
* 🚨 GHOST : Les logs simulent une réussite alors que le code source est absent ou invalide.

N/A - Data Traceability

Sincerity Verdict: **
* Technical Evidence (Code) : NOT OBSERVED
* Documentary Evidence : NOT OBSERVED
* Execution Evidence : NOT OBSERVED
* Tests — result : —
* External Evidence :** NOT OBSERVED

Detailed analysis :
No anomaly detected.

N/A - Data Cleansing & Anonymisation

Detailed analysis :
* ⚠️ FACADE WITHOUT TEST: No test validates the declared compliance.
* 🚨 GHOST : Les logs simulent une réussite alors que le code source est absent ou invalide.

N/A - Decision Record Structure

Sincerity Verdict: ⬛NON-COMPLIANTNONEXISTENT CONTROL
* Technical Evidence (Code) : NOT OBSERVED
* Documentary Evidence : NOT OBSERVED
* Execution Evidence : PARTIAL
* Tests — result : ⚠️ PARTIAL 0✅ / 1❌
* External Evidence :** NOT OBSERVED

🔬 Runtime — Process Mining Analysis (Behavioral Audit) :
* Sample : 2026-04-04 → 2026-04-05 (2j)
* Sessions analysed : 20
* ✅ Compliant : 17 (85.0%)
* ⚠️ Partial : 3
* 🔴 Non-compliant : 0 (0.0%)

Detailed analysis :
* ⚠️ FACADE WITHOUT TEST: No test validates the declared compliance.

N/A - Authority Delegation

Detailed analysis :
* ⚠️ FACADE WITHOUT TEST: No test validates the declared compliance.
* 🚨 GHOST : Les logs simulent une réussite alors que le code source est absent ou invalide.

N/A - System Explainability

Detailed analysis :
No anomaly detected.

N/A - Bypass Detection

Sincerity Verdict: ⬛NON-COMPLIANTNONEXISTENT CONTROL
* Technical Evidence (Code) : NOT OBSERVED
* Documentary Evidence : NOT OBSERVED
* Execution Evidence : EVIDENCE INSUFFICIENT
* Tests — result : ⚠️ PARTIAL 0✅ / 1❌
* External Evidence :** NOT OBSERVED

🔬 Runtime — Process Mining Analysis (Behavioral Audit) :
* Sample : 2026-04-04 → 2026-04-05 (2j)
* Sessions analysed : 20
* ✅ Compliant : 3 (15.0%)
* ⚠️ Partial : 0
* 🔴 Non-compliant : 17 (85.0%)
* Sessions NOK : fb-D534D661, fb-89F335E1, fb-3899A858, fb-6F43C4DE, fb-BB281A1F, fb-FA3E3725, fb-193F126A, fb-3ABD45B7, fb-1ACF4C41, fb-9318008E, fb-9EC3B248, fb-E439D5BF, fb-5F56C6CC, fb-659B8219, fb-E3B62030, fb-F7C43BE4, fb-8111D2BC

Detailed analysis :
* ⚠️ FACADE WITHOUT TEST: No test validates the declared compliance.

N/A - Human-in-the-Loop Mechanism

Detailed analysis :
* ⚠️ FACADE WITHOUT TEST: No test validates the declared compliance.
* 🚨 GHOST : Les logs simulent une réussite alors que le code source est absent ou invalide.

N/A - Escalation to Human

Sincerity Verdict: ⬛⚠️ UNVERIFIABLE — Activity signals detected but no source implementationNONEXISTENT CONTROL
* Technical Evidence (Code) : NOT OBSERVED
* Documentary Evidence : NOT OBSERVED
* Execution Evidence : OBSERVED
* Tests — result : ❌ ÉCHOUÉ (1)
* External Evidence :** NOT OBSERVED

Detailed analysis :
* ⚠️ FACADE WITHOUT TEST: No test validates the declared compliance.
* 🚨 GHOST : Les logs simulent une réussite alors que le code source est absent ou invalide.

N/A - Human Validation

Detailed analysis :
* ⚠️ FACADE WITHOUT TEST: No test validates the declared compliance.

N/A - Serious Incident Notification Procedure

Detailed analysis :
No anomaly detected.

N/A - Execution Limits (Guardrails)

Detailed analysis :
* ⚠️ FACADE WITHOUT TEST: No test validates the declared compliance.
* 🚨 GHOST : Les logs simulent une réussite alors que le code source est absent ou invalide.

N/A - User Override

Detailed analysis :
* ⚠️ FACADE WITHOUT TEST: No test validates the declared compliance.
* 🚨 GHOST : Les logs simulent une réussite alors que le code source est absent ou invalide.

N/A - PII Masking Before External Transmission

Sincerity Verdict: ⬛NON-COMPLIANTNONEXISTENT CONTROL
* Technical Evidence (Code) : NOT OBSERVED
* Documentary Evidence : NOT OBSERVED
* Execution Evidence : EVIDENCE INSUFFICIENT
* Tests — result : ⚠️ PARTIAL 0✅ / 1❌
* External Evidence :** NOT OBSERVED

Detailed analysis :
* ⚠️ FACADE WITHOUT TEST: No test validates the declared compliance.

N/A - Post-Market Plan

Detailed analysis :
No anomaly detected.

Article 14 - Agent Tool Scope

Sincerity Verdict: **
* Technical Evidence (Code) : NOT OBSERVED
* Documentary Evidence : NOT OBSERVED
* Execution Evidence : NOT OBSERVED
* Tests — result : ⚠️ PARTIAL 0✅ / 1❌
* External Evidence :** NOT OBSERVED

Detailed analysis :
No anomaly detected.

Article 15 - Unsafe Serialization Formats

Detailed analysis :
No anomaly detected.

Article 15 - Error Handling

Detailed analysis :
No anomaly detected.

Article 15 - Prompt Guardrail / Injection Detection

Detailed analysis :
No anomaly detected.

Article 9 - Risk Mitigation

Detailed analysis :
No anomaly detected.

Article 10 - Bias Metrics

Detailed analysis :
No anomaly detected.

Article 12 - Logging Implementation

Sincerity Verdict: **
* Technical Evidence (Code) : NOT OBSERVED
* Documentary Evidence : NOT OBSERVED
* Execution Evidence : NOT OBSERVED
* Tests — result : ❌ ÉCHOUÉ (1)
* External Evidence :** NOT OBSERVED

Detailed analysis :
No anomaly detected.

Article 12 - Logging Integrity

Detailed analysis :
No anomaly detected.

Article 15 - Component Obsolescence

Sincerity Verdict: **
* Technical Evidence (Code) : NOT OBSERVED
* Documentary Evidence : NOT OBSERVED
* Execution Evidence : NOT OBSERVED
* Tests — result : ✅ PASSÉ (1)
* External Evidence :** NOT OBSERVED

Detailed analysis :
No anomaly detected.

Article 9 - Continuous Monitoring

Detailed analysis :
No anomaly detected.

Article 15 - Secure Format Policy

Detailed analysis :
No anomaly detected.

Article 10 - Physical Dataset Existence

Detailed analysis :
No anomaly detected.

Article 10 - Balancing & Representativeness

Detailed analysis :
No anomaly detected.

Article 10 - Dataset Quality

Detailed analysis :
No anomaly detected.

Article 10 - Data Inventory

Detailed analysis :
No anomaly detected.

Article 15 - Input Robustness

Detailed analysis :
No anomaly detected.

Article 13 - Limitations Disclosure

Detailed analysis :
No anomaly detected.

Article 12 - Storage Definition

Detailed analysis :
No anomaly detected.

Article 12 - Real Execution Traces

Detailed analysis :
No anomaly detected.

Article 11 - Model Card

Detailed analysis :
No anomaly detected.

Article 15 - Cybersecurity Audit

Detailed analysis :
No anomaly detected.

Article 9 - Risk Matrix

Detailed analysis :
No anomaly detected.

Article 9 - Risk Ownership Assignment

Detailed analysis :
No anomaly detected.

Article 9 - Risk Register

Detailed analysis :
No anomaly detected.

Article 11 - System Architecture

Detailed analysis :
No anomaly detected.

Article 13 - User Notice

Detailed analysis :
No anomaly detected.

Article 11 - Version Management

Detailed analysis :
No anomaly detected.

Article 15 - Robustness Level Reality

Detailed analysis :
No anomaly detected.

Article 26 - Deployer Identity

Detailed analysis :
No anomaly detected.

Article 12 - Log Retention Policy

Detailed analysis :
No anomaly detected.

Article 25 - Provider Identity

Detailed analysis :
No anomaly detected.

Article 4 - Documented AI Policy

Detailed analysis :
No anomaly detected.

Unknown - FACT_ART

Detailed analysis :
No anomaly detected.

Article 27 - FRIA — Fundamental Rights Impact Assessment

Detailed analysis :
No anomaly detected.

Article 14 - Human Decision Endpoint

Detailed analysis :
No anomaly detected.

Article 14 - Human Approval Gates Execution

Detailed analysis :
No anomaly detected.

Article 14 - Full Workflow Integration

Detailed analysis :
No anomaly detected.

---

5. 🧾 EVIDENCE LEDGER

REGULATORY TRACEABILITY INDEX

This section is the detailed register of evidence extracted from the technical environment. It allows each EU AI Act requirement to be correlated with a specific asset (source code or document).

REGULATORY CONTRADICTION INDEX

ℹ️ VERIFICATION PROTOCOL

Extraction: Each piece of evidence was extracted via static analysis of the codebase.
AI validation: The verdict results from a confrontation between the raw content and the referenced Article's requirements.
Integrity: File paths (Source) are authoritative for locating controls during a counter-review.

Legal notice: Analysis excerpts are truncated for readability. The full technical logs are preserved in the report's digital seal (Section 10).

Machine-readable export: The complete evidence register is available as JSON in .factdna/evidence_ledger.json (SHA-256 sealed in the audit manifest). This file can be imported into a GRC system or provided to a third-party auditor.

7. 🛠️ REMEDIATION PLAN — ACTIONS PER CHECKPOINT

🎯 Quick-wins — Highest-impact remediations

Each row is a missing root control whose remediation automatically unlocks
dependent child controls. The % indicates the share of regulatory weight for the article concerned.

Priority	Root checkpoint	Article	Potential impact
🔴 P1	Provider Identity	Article 25	100.0% du poids article → unlocks 1 cross-article control(s)
🔴 P1	Risk Register	Article 9	87.1% du poids article → unlocks 5 cross-article control(s)
🔴 P1	Data Inventory	Article 10	52.8% du poids article → unlocks 3 cross-article control(s)
🔴 P1	Logging Implementation	Article 12	45.5% du poids article → unlocks 2 cross-article control(s)
🔴 P1	Secure Format Policy	Article 15	33.3% du poids article → unlocks 2 cross-article control(s)
🔴 P1	Human Validation	Article 14	29.5% du poids article → unlocks 2 cross-article control(s)

Each row corresponds to an AI Act checkpoint for which no sufficient evidence was identified
within the analyzed scope, and describes the evidence gap to close.
The approaches listed are illustrative examples, not prescriptions — any equivalent control
that produces the expected evidence is acceptable. Implementation choices remain the
responsibility of the system owner.

Remediation Dashboard

Reg. Severity	Priority	Checkpoint	Article	Example remediation approach	Indicative effort
⛔ GATE ARTICLE	🔴 P1 CRITIQUE	Audit Trail	Article 12	Add an AuditLogger call before each critical decision.	2–4 days
⛔ GATE ARTICLE	🔴 P1 CRITIQUE	Automatic Blocking Linked to Human Rejection	Article 14	Analyse and fix checkpoint 'Automatic Blocking Linked to Human Rejection' per Article 14.	To be estimated
⛔ GATE ARTICLE	🔴 P1 CRITIQUE	Bypass Detection	Article 15	Analyse and fix checkpoint 'Bypass Detection' per Article 15.	To be estimated
⛔ GATE ARTICLE	🔴 P1 CRITIQUE	Human Validation	Article 14	Implement a human approval gate before any critical automated decision.	1–2 wks
⛔ GATE ARTICLE	🔴 P1 CRITIQUE	PII Masking Before External Transmission	Article 10	Add a PII masking layer before any transmission to an external LLM or API.	3–5 days
⛔ GATE ARTICLE	🔴 P1 CRITIQUE	Unsafe Serialization Formats	Article 15	Replace pickle.load() with a secure format (safetensors, ONNX, joblib with verification).	2–5 j
🔴 HIGH	🔴 P1 CRITIQUE	Decision Record Structure	Article 12	Enrich the log structure with mandatory accountability fields.	3–5 days
⛔ GATE ARTICLE	🔴 P1 CRITIQUE	Prompt Guardrail / Injection Detection	Article 15	Integrate a semantic guardrail (Llama Guard or equivalent) before LLM transmission.	3–5 days
🔴 HIGH	🔴 P1 CRITIQUE	Risk Mitigation	Article 9	Analyse and fix checkpoint 'Risk Mitigation' per Article 9.	To be estimated
🔴 HIGH	🔴 P1 CRITIQUE	Bias Metrics	Article 10	Integrate bias metrics (Disparate Impact, Equal Opportunity) into the test pipeline.	3–5 days
🔴 HIGH	🔴 P1 CRITIQUE	Logging Implementation	Article 12	Configure a centralised logger (logging.getLogger) writing to persistent storage.	1–2 days
🟠 MEDIUM	🔴 P1 CRITIQUE	Logging Integrity	Article 12	Verify that log functions actually write to DB/file (no pass or print stubs).	1–3 days
⛔ GATE ARTICLE	🔴 P1 CRITIQUE	Physical Dataset Existence	Article 10	Analyse and fix checkpoint 'Physical Dataset Existence' per Article 10.	To be estimated
⛔ GATE ARTICLE	🔴 P1 CRITIQUE	Data Inventory	Article 10	Analyse and fix checkpoint 'Data Inventory' per Article 10.	To be estimated
⛔ GATE ARTICLE	🔴 P1 CRITIQUE	Real Execution Traces	Article 12	Analyse and fix checkpoint 'Real Execution Traces' per Article 12.	To be estimated
⛔ GATE ARTICLE	🔴 P1 CRITIQUE	Risk Matrix	Article 9	Analyse and fix checkpoint 'Risk Matrix' per Article 9.	To be estimated
⛔ GATE ARTICLE	🔴 P1 CRITIQUE	Risk Ownership Assignment	Article 9	Assign a named Risk Owner for each risk in the register.	1 day
⛔ GATE ARTICLE	🔴 P1 CRITIQUE	Risk Register	Article 9	Create a formalised risk register (JSON, YAML or doc section) listing all identified risks.	2–3 days
🔴 HIGH	🟠 P2 MAJEUR	Agent Tool Scope	Article 14	Restrict the agent tool catalogue to the strict minimum (least privilege principle).	1–3 days
🔴 HIGH	🟠 P2 MAJEUR	Error Handling	Article 15	Wrap critical calls in try/except blocks returning generic errors.	1–2 days
🔴 HIGH	🟠 P2 MAJEUR	Continuous Monitoring	Article 9	Analyse and fix checkpoint 'Continuous Monitoring' per Article 9.	To be estimated
🔴 HIGH	🟠 P2 MAJEUR	Dataset Quality	Article 10	Analyse and fix checkpoint 'Dataset Quality' per Article 10.	To be estimated
🔴 HIGH	🟠 P2 MAJEUR	Limitations Disclosure	Article 13	Analyse and fix checkpoint 'Limitations Disclosure' per Article 13.	To be estimated
🟠 MEDIUM	🟠 P2 MAJEUR	Model Card	Article 11	Write a model card (intended use, limits, metrics, version).	2–3 j
🟠 MEDIUM	🟠 P2 MAJEUR	System Architecture	Article 11	Analyse and fix checkpoint 'System Architecture' per Article 11.	To be estimated
🔴 HIGH	🟠 P2 MAJEUR	User Notice	Article 13	Write a user notice explaining the system's operation and limits.	1–2 days
🔴 HIGH	🟠 P2 MAJEUR	Input Robustness	Article 15	Add schema validation (Pydantic/jsonschema) on all user inputs.	2–4 days
🔴 P1 STRATÉGIQUE	`STUB_IMPLEMENTATION_RATIO`	Global	Remplacer les fonctions vides (pass/stub) détectées par une implémentation réelle.	3–6 sem	CODE

Remediation detail with example approaches

`Audit Trail` — Audit Trail (Article 12)

Field	Value
Severity	⛔ BLOCKING
Priority	🔴 P1 CRITIQUE
Effort	2–4 days
Type	CODE

Action required: Add an AuditLogger call before each critical decision.

Implementation example:

AuditLogger.log_event(event='decision', resource_id=res_id)

Expected evidence (how to prove this is fixed):

audit.log file or audit_events DB table with sample entries (decision_id, timestamp, actor, input_hash, output)

Risk if not remediated:

⚠️ Without decision traceability, incident investigation and regulatory inspection become impossible. Art. 12 §1 mandatory.

`Human Validation` — Human Validation (Article 14)

Field	Value
Severity	⛔ BLOCKING
Priority	🔴 P1 CRITIQUE
Effort	1–2 wks
Type	CODE

Action required: Implement a human approval gate before any critical automated decision.

Implementation example:

if not human_approval_cb(decision=result, actor=user): raise HumanApprovalRequired()

Expected evidence (how to prove this is fixed):

hitl.py + screenshot of approval workflow + sample approval log entry

Risk if not remediated:

⚠️ Automated critical decisions may be executed without human intervention. Non-compliance with Art. 14 §4, direct enforcement action risk.

`PII Masking Before External Transmission` — PII Masking Before External Transmission (Article 10)

Field	Value
Severity	⛔ BLOCKING
Priority	🔴 P1 CRITIQUE
Effort	3–5 days
Type	CODE

Action required: Add a PII masking layer before any transmission to an external LLM or API.

Implementation example:

masked = pii_filter.mask(payload); response = llm_client.call(masked)

Expected evidence (how to prove this is fixed):

Evidence requirements depend on implementation architecture. Examples: test report, runtime logs, configuration snapshot, CI/CD validation report.

Risk if not remediated:

⚠️ Regulatory gap — see article reference.

`Unsafe Serialization Formats` — Unsafe Serialization Formats (Article 15)

Field	Value
Severity	⛔ BLOCKING
Priority	🔴 P1 CRITIQUE
Effort	2–5 j
Type	CODE

Action required: Replace pickle.load() with a secure format (safetensors, ONNX, joblib with verification).

Implementation example:

# AVANT: model = pickle.load(f)
# APRES: model = safetensors.load_file('model.safetensors')

Expected evidence (how to prove this is fixed):

Evidence requirements depend on implementation architecture. Examples: test report, runtime logs, configuration snapshot, CI/CD validation report.

Risk if not remediated:

⚠️ Regulatory gap — see article reference.

`Decision Record Structure` — Decision Record Structure (Article 12)

Field	Value
Severity	🔴 HIGH
Priority	🔴 P1 CRITIQUE
Effort	3–5 days
Type	CODE

Action required: Enrich the log structure with mandatory accountability fields.

Implementation example:

{'decision_id': str(uuid.uuid4()), 'actor_id': user.id, 'model_version': MODEL_VER, 'input_hash': sha256(input)}

Expected evidence (how to prove this is fixed):

Sample log entry: {decision_id, actor_id, model_version, input_hash, output, timestamp}

Risk if not remediated:

⚠️ AI decisions cannot be attributed or reconstructed. Required for conformity assessment under Art. 12 §2.

`Prompt Guardrail / Injection Detection` — Prompt Guardrail / Injection Detection (Article 15)

Field	Value
Severity	⛔ BLOCKING
Priority	🔴 P1 CRITIQUE
Effort	3–5 days
Type	CODE

Action required: Integrate a semantic guardrail (Llama Guard or equivalent) before LLM transmission.

Implementation example:

safe_input = guardrail.check(user_input); if not safe_input.is_safe: raise PromptInjectionError()

Expected evidence (how to prove this is fixed):

Evidence requirements depend on implementation architecture. Examples: test report, runtime logs, configuration snapshot, CI/CD validation report.

Risk if not remediated:

⚠️ Regulatory gap — see article reference.

`Risk Mitigation` — Risk Mitigation (Article 9)

Field	Value
Severity	🔴 HIGH
Priority	🔴 P1 CRITIQUE
Effort	To be estimated
Type	?

Action required: Analyse and fix checkpoint 'Risk Mitigation' per Article 9.

Expected evidence (how to prove this is fixed):

Code implementing mitigation + reference to risk_id in RISK_REGISTER + test confirming mitigation active

Risk if not remediated:

⚠️ Identified risks with no mitigation action. Regulatory gap under Art. 9 §2.

`Bias Metrics` — Bias Metrics (Article 10)

Field	Value
Severity	🔴 HIGH
Priority	🔴 P1 CRITIQUE
Effort	3–5 days
Type	CODE

Action required: Integrate bias metrics (Disparate Impact, Equal Opportunity) into the test pipeline.

Implementation example:

from fairlearn.metrics import demographic_parity_difference
    dpd = demographic_parity_difference(y_true, y_pred, sensitive_features=gender)

Expected evidence (how to prove this is fixed):

fairness_report.json or model_card.md section with: protected_groups, metrics (TPR, FPR, equalized_odds)

Risk if not remediated:

⚠️ No evidence of bias evaluation. High-risk AI without fairness metrics exposed to Art. 10 §2 non-compliance.

`Logging Implementation` — Logging Implementation (Article 12)

Field	Value
Severity	🔴 HIGH
Priority	🔴 P1 CRITIQUE
Effort	1–2 days
Type	CODE

Action required: Configure a centralised logger (logging.getLogger) writing to persistent storage.

Implementation example:

import logging; logger = logging.getLogger('ai_system'); logger.addHandler(FileHandler('audit.log'))

Expected evidence (how to prove this is fixed):

audit.log or audit_events table with persistent entries (not stdout only)

Risk if not remediated:

⚠️ Logs written to stdout are lost at process restart. Non-persistent logging fails Art. 12 §1.

`Logging Integrity` — Logging Integrity (Article 12)

Field	Value
Severity	🟠 MEDIUM
Priority	🔴 P1 CRITIQUE
Effort	1–3 days
Type	CODE

Action required: Verify that log functions actually write to DB/file (no pass or print stubs).

Implementation example:

def log_event(self, **kw): self.db.insert('audit_log', kw)  # NON: pass ou print()

Expected evidence (how to prove this is fixed):

Test confirming log entries written to DB/file (not just print). Log rotation config.

Risk if not remediated:

⚠️ Logs that only print to stdout provide no durable audit trail.

`Risk Ownership Assignment` — Risk Ownership Assignment (Article 9)

Field	Value
Severity	⛔ BLOCKING
Priority	🔴 P1 CRITIQUE
Effort	1 day
Type	DOC

Action required: Assign a named Risk Owner for each risk in the register.

Implementation example:

risks.yaml:
- id: RISK-001
      owner: 'Chief Risk Officer'
      contact: 'risk-owner@company.example'

Expected evidence (how to prove this is fixed):

Evidence requirements depend on implementation architecture. Examples: test report, runtime logs, configuration snapshot, CI/CD validation report.

Risk if not remediated:

⚠️ Regulatory gap — see article reference.

`Risk Register` — Risk Register (Article 9)

Field	Value
Severity	⛔ BLOCKING
Priority	🔴 P1 CRITIQUE
Effort	2–3 days
Type	DOC

Action required: Create a formalised risk register (JSON, YAML or doc section) listing all identified risks.

Implementation example:

risks.yaml:
- id: RISK-001
      name: Algorithmic bias
      probability: MEDIUM
      impact: HIGH

Expected evidence (how to prove this is fixed):

risks.yaml or RISK_REGISTER.md with: id, probability, impact, mitigation, owner, review_date

Risk if not remediated:

⚠️ Without a risk register, all downstream risk management obligations (Art. 9) cannot be demonstrated. Potential regulatory exposure under Article 9.

`Agent Tool Scope` — Agent Tool Scope (Article 14)

Field	Value
Severity	🔴 HIGH
Priority	🟠 P2 MAJEUR
Effort	1–3 days
Type	CODE

Action required: Restrict the agent tool catalogue to the strict minimum (least privilege principle).

Implementation example:

ALLOWED_TOOLS = ['search', 'summarize']  # Supprimer: 'delete', 'send_email', 'execute_code'

Expected evidence (how to prove this is fixed):

Evidence requirements depend on implementation architecture. Examples: test report, runtime logs, configuration snapshot, CI/CD validation report.

Risk if not remediated:

⚠️ Regulatory gap — see article reference.

`Error Handling` — Error Handling (Article 15)

Field	Value
Severity	🔴 HIGH
Priority	🟠 P2 MAJEUR
Effort	1–2 days
Type	CODE

Action required: Wrap critical calls in try/except blocks returning generic errors.

Implementation example:

try: result = model.infer(input)
    except InferenceError: return {'error': 'Service unavailable', 'code': 503}

Expected evidence (how to prove this is fixed):

Evidence requirements depend on implementation architecture. Examples: test report, runtime logs, configuration snapshot, CI/CD validation report.

Risk if not remediated:

⚠️ Regulatory gap — see article reference.

`Model Card` — Model Card (Article 11)

Field	Value
Severity	🟠 MEDIUM
Priority	🟠 P2 MAJEUR
Effort	2–3 j
Type	DOC

Action required: Write a model card (intended use, limits, metrics, version).

Implementation example:

MODEL_CARD.md: Model — <name> v<version> | Intended use: <domain task> | Limitation: <known out-of-scope conditions>

Expected evidence (how to prove this is fixed):

MODEL_CARD.md with: intended_use, limitations, performance metrics, bias assessment, version

Risk if not remediated:

⚠️ Users and deployers cannot assess system capabilities. Art. 13 transparency obligation not met.

`System Architecture` — System Architecture (Article 11)

Field	Value
Severity	🟠 MEDIUM
Priority	🟠 P2 MAJEUR
Effort	To be estimated
Type	?

Action required: Analyse and fix checkpoint 'System Architecture' per Article 11.

Expected evidence (how to prove this is fixed):

SYSTEM_DESCRIPTION.md or Annex IV-compatible technical documentation

Risk if not remediated:

⚠️ No technical documentation for conformity assessment. Required under Art. 11 and Annex IV.

`User Notice` — User Notice (Article 13)

Field	Value
Severity	🔴 HIGH
Priority	🟠 P2 MAJEUR
Effort	1–2 days
Type	DOC

Action required: Write a user notice explaining the system's operation and limits.

Implementation example:

User guide — Section 1: This AI system assists <domain task>. It does not replace expert human judgement.

Expected evidence (how to prove this is fixed):

Evidence requirements depend on implementation architecture. Examples: test report, runtime logs, configuration snapshot, CI/CD validation report.

Risk if not remediated:

⚠️ Regulatory gap — see article reference.

`Input Robustness` — Input Robustness (Article 15)

Field	Value
Severity	🔴 HIGH
Priority	🟠 P2 MAJEUR
Effort	2–4 days
Type	CODE

Action required: Add schema validation (Pydantic/jsonschema) on all user inputs.

Implementation example:

class InputSchema(BaseModel): query: str = Field(max_length=2000); ...

Expected evidence (how to prove this is fixed):

Evidence requirements depend on implementation architecture. Examples: test report, runtime logs, configuration snapshot, CI/CD validation report.

Risk if not remediated:

⚠️ Regulatory gap — see article reference.

Architecture context — Topology 🕸️ MICRO-MESH

Complexity: 0.05 / 1.0 — Acceptable level
Integrity Gap: 21.79 % — Strategic action required (see P1 row above)
Risk profile: 🟢 CONTROLLED

8. 📈 REMEDIATION ROADMAP

⚠️ These are estimated scores — not predictions or guarantees.
They assume all recommended controls are implemented as described in the Playbook,
all evidence artifacts are accepted, and no new findings emerge during review.

Work Phase	Estimated Score	Evidence Strength	Indicative Timeline
CURRENT STATE	57.2/100	EVIDENCE INSUFFICIENT — Available technical evidence is insufficient to support a positive assessment within the analyzed scope. Technical remediation required.	Now
PHASE 1 — Critical gaps	~75/100 (estimated)	Gate article gaps resolved	4–6 weeks
PHASE 2 — Full evidence	~91/100 (estimated)	Evidence sufficient for review	10–14 weeks

Estimation basis:
Phase 1 — assumes: all BLOCKING checkpoints addressed, gate articles pass.
Phase 2 — assumes: 80% of HIGH/MEDIUM controls evidenced at E2 or above.
These scores are indicative estimates, not certification guarantees.
An independent conformity assessment may produce different results.

Indicative Effort Estimate

Phase	Checkpoints	Indicative Effort
Phase 1 — BLOCKING	19	High (months)
Phase 2 — HIGH	16	High (months)
Phase 3 — MEDIUM/LOW	1	Low (days)

Effort levels are indicative only. Actual effort depends on team size, stack,
architecture and organisational maturity — none of which are assessed by this audit.
No cost estimate is provided for this reason.

Phase 1 priority: l'alignement technique des Article 12 — resolves immediate regulatory exposure and unblocks dependent controls.

9. ⚠️ AUDIT LIMITATIONS

EXECUTION FRAMEWORK

This technical audit is a "point-in-time" analysis based on the assets provided during the ingestion phase.

Scope of responsibility:
1. Nature of the analysis: This audit is a technical compliance assessment, not a definitive legal opinion. It does not replace certification by a Notified Body if the system is classified "High Risk".
2. Source quality: The accuracy of the results depends on the completeness of the codebase and documentation provided. Third-party components (closed APIs, SaaS models) were assessed on the basis of their declared specifications.
3. Evolvability: Any subsequent change to the source code, algorithmic logic or training datasets voids the validity of the scores presented in this report.

WORKING ASSUMPTIONS

Files identified as "Skeleton Code" were penalised in the Skeleton Ratio.
The reference framework used is the consolidated version of the EU AI Act (2024).
The absence of a technical response on a critical article was interpreted by default as non-compliance (precautionary principle).

ANALYSIS ENGINE: LLM & STATIC ANALYSIS

Parameter	Value
Audit LLM model	`deepseek/deepseek-chat`
Temperature	`0.0` (deterministic)
Static-analysis rate (STATIC_FALLBACK)	0.0%

0.0% (0/92 facts) of the facts were produced by static analysis (regex) — without LLM judgement. These facts have a confidence of 0.1 and do not replace semantic analysis.

Note on reproducibility: At temperature 0, the LLM produces quasi-deterministic results on a fixed commit. The same commit re-read with the same provider will produce identical or very close results. The main variability comes from cloud batching (external provider) — in air-gap mode (Ollama), reproducibility is maximal.

🧮 SCORE CALCULATION METHODOLOGY (CAMSVA ENGINE)

The final compliance score is computed with a **Progressive Rigour** algorithm. It is not a simple average, but a reliability funnel that applies reduction coefficients based on the quality of the technical evidence.

1. The Mathematical Formula

Final_Score = ( Σ(Score_Art × Weight_Art) / Σ(Weight_Art) ) × C_ov × F_p × Ψ_sincerity × Φ_certainty

2. Component Definitions

Score_Art (Weighted Average): Each article is evaluated on its control points. Critical Articles (9, 10, 15) carry a weight of 3, while transparency articles (13) carry a weight of 1.
- Cleaver rule: Any critical failure (🔴) on a weight-3 article immediately caps that article's score at 0.
C_ov (Coverage Factor: penalises the audit if the scope analysed is incomplete.) If less than 30% of applicable articles could be technically verified, the score is capped at 30/100.
F_p (Proof Strength Factor: values certainty. A system with many 'Inconclusive' verdicts is penalised.) A system with many "Uncertain" verdicts (⚠️) will have a reduced score.
Ψ_sincerity (P-Consistency Index): The truth multiplier. It measures the alignment between Code and Documentation. If contradictions (collisions) are detected, this factor sharply reduces the final score.
Φ_certainty (Uncertainty Index): A final adjustment based on the reliability of the extracted data.

3. Rigour Thresholds (Safety Caps)

Collision alert: If semantic consistency is below 40%, the overall score is mathematically capped at 40/100, regardless of code state.
Critical Failure: detection of non-compliance on a security pillar (e.g. Article 10) caps the score. Cap at 49/100 (rejection threshold).

10. 🔐 DIGITAL SEAL — AUDIT CERTIFICATION

DELIVERABLE INTEGRITY VERIFICATION

This document is protected by an SHA-256 cryptographic seal.
The fingerprints below are anchored in the audit database (audit_runs)
and in the .factdna/audit_manifest.json manifest.
Any change to the score, a verdict, the source code or the text invalidates this seal.

Element	Value
Audit identifier	`CSVA-20260614-9BE11290`
Audit mode	`STATIC`
Sealed score	`57.17 / 100`
Sealed verdict	⚠️ PARTIAL TECHNICAL ALIGNMENT (57/100 — threshold: 75)
Sealed SCI	`100.0%`
Sealed IntegrityGap	`1.9%`
Sealed RuntimeConfidence	`72.5`
Sealed Sincerity	`87.3%`
Timestamp	2026-06-17 09:47:24 UTC
SHA-256 — Report body	`469bd553af11394b09d7f77477b1883798cb40432588f8e2e9881c7081720243`
SHA-256 — Evidence Ledger	`e8d1ab7a18147efbbb38169228453f18…`
SHA-256 — Source tree	`0ab1f790327ac5db491398a61904858e…`
SHA-256 — Tests	`3e755643549dfa81e004d60957647415…`
SHA-256 — Configuration	`82ff2e505fd38023a47e74e0e0d87037…`
SHA-256 — Models / Weights	`N/A (0 fichiers)`
SHA-256 — Manifest	`2ccc0d89faa13afebb13c8f541b93c3b…`
Sealed source files	90 file(s)
Database anchoring	✅ Ancré (audit_runs)
RFC 3161 token (FreeTSA)	`Non disponible (optionnel)`

SEAL TOKEN — EXTERNAL CRYPTOGRAPHIC VERIFICATION

This token is the primary proof of integrity. It can only be produced by CAMSVA.

CAMSVA-SEAL-v1:CSVA-20260614-9BE11290:20260617T094724Z:0ab1f790327ac5db491398a61904858e5253e99ceebe02a836be72e23cbdc257:37da6a4d10fb5719

Meaning: This token contains audit_id + timestamp + tree_hash, signed with HMAC-SHA256
using a secret key internal to CAMSVA (never accessible in the user's code).
A user who modifies their source files or their assert_integrity() cannot
produce a valid token for their new code.

To verify at any time that the code has not changed since this audit:

# From the CAMSVA directory (third-party tool, outside the user's scope):
python camsva.py --verify \
       --project "C:/projects/kosmos1/FactDNA_Pro/camsvapro/public_audits/openbb/agents-for-openbb" \
       --seal    "CAMSVA-SEAL-v1:CSVA-20260614-9BE11290:20260617T094724Z:0ab1f790327ac5db491398a61904858e5253e99ceebe02a836be72e23cbdc257:37da6a4d10fb5719"

Possible results:

Status	Meaning	Action
`IDENTICAL`	Code = audited version ✅	Seal valid
`MODIFIED`	Files changed since the audit ⚠️	Re-audit before deployment
`INVALID_SEAL`	Token forged or truncated 🔴	Contact the CAMSVA auditor

INTEGRITY GUARD (runtime complement, opt-in)

.factdna/camsva_integrity_guard.py enables a check at application startup.
This is a convenience tool — the official cryptographic proof is the Seal Token above.

# In the application entry point (opt-in):
import sys, os
sys.path.insert(0, os.path.join(os.path.dirname(__file__), ".factdna"))
from camsva_integrity_guard import assert_integrity, verify

assert_integrity(__file__)   # raises RuntimeError if the code has drifted

END OF AUDIT REPORT — CAMSVA v1.0
This document is the property of the audited organisation.
Any reproduction without the associated sealing metrics is considered invalid.
Applied framework: EU AI Act (2024) — Regulation (EU) 2024/1689.

Methodology Notice
Evidence levels (E0–E5), contradiction detection, assurance scoring and control mapping are defined in the FactNotebook Technical Evidence Framework.
View methodology →

FactNotebook — AI Act Technical Alignment Assessment (Regulation EU 2024/1689)
Audit ID: CSVA-20260614-9BE11290 — Generated on 2026-06-17 09:47 UTC
Verify integrity: factnotebook verify CSVA-20260614-9BE11290 | This report is a technical evidence document. It does not constitute legal advice, regulatory certification, or an official conformity assessment.