V-PROOF: AI governance with verifiable cryptographic evidence
V-PROOF: modular evidence infrastructure for AI governance
Seven integrable capabilities for recording assets, versions, decisions, human reviews, and software events with verifiable technical evidence. V-PROOF complements existing governance, risk, and compliance systems; it does not, on its own, replace legal, organizational, or compliance obligations.
Key Points
- V-PROOF It is positioned as a layer of evidence integrated into corporate processes, not as an automatic declaration of compliance.
- An SHA-256 hash can be used to verify the authenticity and integrity of an asset presented at a later date; it does not, by itself, prove its authorship, accuracy, legality, or approval.
- External anchoring can reinforce the timeline and make it more difficult to alter it retroactively, but it does not automatically constitute an eIDAS-qualified time stamp.
- The seven capabilities described form a modular architecture that can be implemented in stages. Their operational availability, connectors, and scope must be confirmed in the version, the technical annex, and the contracted deployment model.
- The provider’s European origin reduces certain factors related to jurisdictional Exposure , but effective sovereignty also depends on the cloud, corporate control, subprocessors, support, keys, telemetry, transfers, portability, and external networks.
- V-PROOF It can support documented information and traceability within management systems such as ISO/IEC 42001 and ISO/IEC 27001, but it does not in and of itself certify the system or replace audits, risk assessments, or organizational controls.
From declarative documentation to process-related evidence
Policies, procedures, and reports remain essential. The challenge arises when the organization must link those documents to a specific version, decision, or action and demonstrate that the record was not altered afterward.
A procedure may describe how human oversight should be conducted. An audit trail can record who reviewed the content, which version was reviewed, when the review took place, and what the outcome was—provided that the identity, metadata, and context come from reliable sources.
V-PROOF It organizes that evidence into specific stages of the workflow: creation, validation, approval, publication, deployment, or response to an incident. The result is a verifiable package that can be used in audits, internal investigations, or oversight processes.
This layer does not replace systems inventory, GRC, IAM, native logs, robustness testing, qualified trust services, or legal assessment. Its purpose is to link control implementation with structured, verifiable technical evidence.
Cryptography makes it possible to verify integrity and authenticity. The evidentiary significance is complemented by identity, context, source, controls, and chain of custody. None of these dimensions should be confused with the others.
Context, Footprint, and Reference: A Verifiable Chain
Each transaction must first define which asset or event is being recorded, which entity is initiating it, what metadata is required, and what information may be transmitted outside the corporate environment.
Result: technical evidence of correspondence, integrity, context, and chronology, contingent upon the quality of the sources, their identity, their preservation, and the chain of custody.
For approaches that use public networks or distributed storage, availability, persistence, costs, providers, metadata privacy, and continuity mechanisms must be documented. A public reference alone does not guarantee that the complete set of evidence will remain available.
A Common Architecture for Different Sources of Evidence
The modules can be activated independently or in coordination with one another. Integrations, connectors, operating systems, and deployment modes must be confirmed during the technical evaluation.
Hash, event identifier, version, source, context, timestamp, and metadata defined by the organization.
Versions, declared metrics, approvals, rejections, exceptions, and transitions between life cycle states.
Generator system, version, date, user or service, applicable policy, disclosures, and content reference.
Identity, role, action, criteria, outcome, and revised version. It does not itself evaluate the substantive quality of the decision.
Repository, commit, pipeline, artifact, build result, approval, and deployment environment.
Start of flow, source, minimized data, result, exception, and synchronization status.
Local fingerprint, defined metadata, sync queue and record status. External anchoring requires connectivity.
An output library does not automatically satisfy the technically detectable requirement of Section 50 of the AI Act. A Git integration alone does not comply with the CRA either. V-SEAL does not, by default, constitute an eIDAS-qualified timestamp. Each module provides evidence of specific controls within a broader compliance program.
Obligation, potential evidence, and limitations of the tool
The following map identifies potential contributions. It does not constitute certification of coverage nor does it replace an applicability analysis.
| Rule / Requirement | Evidence that may support | Capabilities | Limit |
|---|---|---|---|
| AI Act · Regulation (EU) 2024/1689 | |||
|
Articles 9–11 Risks, Data, and Technical Documentation |
Versions, controls, revisions, approvals, and stated sources. | AI Orchestrator V-SEAL Core | It does not automatically assess the quality, bias, representativeness, or adequacy of the documentation. |
|
Art. 12 Record Retention |
Integrity and timestamps of logs generated by the system or by the integration. | V-SEAL Core AI Orchestrator | V-PROOF no crea los logs funcionales que el sistema de IA debería generar si no existen en origen. |
|
Art. 14 Human supervision |
Interventions, approvals, rejections, escalations, and roles. | V-PROOF AI | Recording an intervention does not prove that the supervision was competent, effective, or sufficient. |
|
Art. 50 Transparency of Certain Systems and Content |
Source, generation system, statements, and references for the content. | AI Library | Registration alone does not replace machine-readable marking or the required disclosures. |
|
Articles 53–55 GPAI Model Providers |
Versions, documentation, and events in the model's lifecycle. | AI Orchestrator | These apply to providers of GPAI models in the cases defined by the Regulations, not to all users of an LLM. |
| eIDAS · Trust Services and Electronic Evidence | |||
|
Articles 41–42 Electronic time stamps |
Time references, correspondence, and the completeness of records associated with an asset or event. | V-SEAL Core | V-PROOF It must not be presented by default as a qualified provider or as a qualified electronic time stamp. The enhanced legal effects depend on the service and the corresponding qualified provider. |
| ISO/IEC 42001, ISO/IEC 27001, and ISO/IEC 23894 | |||
|
Management and Risk Systems AI, Information Security, and Risk Management |
Documented information, versions, approvals, events, controls, exceptions, and record retention. | V-SEAL Core AI Orchestrator V-PROOF AI Git Integration | It does not certify the management system or replace risk assessment, the statement of applicability, controls, audits, or third-party certification. |
| Cyber Resilience Act · Regulation (EU) 2024/2847 | |||
|
Articles 13–14 Manufacturer’s Obligations and Notification |
Changes, artifacts, validations, vulnerabilities, and incidents. | Git Integration V-SEAL Core | It does not replace secure-by-design practices, vulnerability management, compliance assessment, or official notification. |
| GDPR and the National Security Framework | |||
| GDPR Articles 5.2, 25, 30, and 32 | Evidence of the implementation of controls, versions, and records for certain processing operations. | V-SEAL Core AI Library Node-RED | It does not replace the legal basis, information, data minimization, DPIA, contracts, or security measures. |
|
ENS Traceability and Protection |
Verifiable records of changes, access, operations, and selected controls. | V-SEAL Core Desktop Git Integration | It does not imply compliance with ENS standards, nor does it replace categorization, measures, audits, and certification where applicable. |
| DORA and NIS2 | |||
| DORA Arts, Chapters 9–10 and 17–19 | Protection controls, detection, incidents, classification, decisions, and response timeline. | V-SEAL Core V-PROOF AI | It does not replace the ICT risk management framework or the channel and format for reporting to the competent authority. |
| NIS2, Articles 21 and 23 | Evidence of actions taken, changes, incidents, and the sequence of notification. | Git Integration V-SEAL Core | It does not replace the entity's risk management measures or its reporting and governance obligations. |
The provider's origin matters, but it doesn't determine the entire architecture
The company's headquarters, corporate governance, and applicable laws are part of due diligence. Subcontractors, regions, remote access, support, telemetry, key custody, and public networks must also be reviewed.
Assessable jurisdictional risk, not absolute immunity
The CLOUD Act may apply to certain providers subject to U.S. jurisdiction with respect to data in their possession, custody, or control, even if it is stored outside the United States.
The Spanish Constitution of V-PROOF does not, on its own, determine the application of the CLOUD Act and reduces certain avenues for direct Exposure access. The analysis must include corporate governance and all providers used for hosting, support, communications, monitoring, key custody, telemetry, and external anchoring.
What it offers, where it fits in, and what's left out
Evidence-gathering capabilities, use cases, and responsibilities that remain within the organization.
- Traces and time stamps associated with assets and events. Integrity · Consistency · Chronology
- Evidence related to versions, approvals, and exceptions. Governance by Design
- Record of human intervention when the identity and role are derived from reliable sources. AI Act · Art. 14
- Progressive integration into models, content, software, and corporate processes. API · Events · Desktop
- Evidence packages tailored for export, post-audit review, portability, and contractual continuity. Audit · Exit plan · Verification
- Life Cycle of AI Systems and In-House Models. Versions · Evaluations · Deployments
- Origin and Management of Generative Outputs. AI Act · Transparency
- Software changes, CI/CD, and the digital supply chain. CRA · NIS2
- Incidents, reviews, and decisions in regulated environments. DORA · ENS · Audit
- Determine the legal classification and obligations applicable to each system. Legal and Sectoral Assessment
- Evaluate the quality, bias, robustness, accuracy, or substantive reliability of the model. Independent testing
- Conducting conformity assessments or issuing certifications reserved for authorized third parties. Qualified bodies and services
- Ensuring that a reported piece of data, an identity, or an approval is accurate if the source is not reliable. Source quality · Chain of custody
What kind of evidence can your architecture generate today?
We analyze systems, vendors, identity sources, and control points to identify gaps and define a testing approach commensurate with the risk.
Request a Strategic Assessment →Key Regulatory Sources
- Regulation (EU) 2024/1689, AI Act .
- European Commission, Timeline for the Implementation and Simplification of the AI Act , updated in July 2026.
- Regulation (EU) 2024/2847, Cyber Resilience Act .
- Regulation (EU) 2016/679, GDPR .
- Royal Decree 311/2022, National Security Framework.
- Regulation (EU) 2022/2554, DORA .
- Directive (EU) 2022/2555, NIS2 .
- Consolidated eIDAS Regulation, electronic identification, trusted services, and electronic time stamps.
- ISO/IEC 42001:2023, ISO/IEC 27001:2022, and ISO/IEC 23894:2023.
- U.S. Department of Justice, CLOUD Act Resources.
This article describes the modular architecture and the planned positioning of V-PROOF. Module names may represent available, configurable, or roadmap-based capabilities. Their production availability, connectors, SLAs, and scope must be confirmed in the corresponding version, technical annex, contract, and deployment model. The content does not constitute legal advice, certification, conformity assessment, a qualified trust service, or a guarantee of compliance or test results.
