V-PROOF: Spain's first AI governance platform that turns compliance into cryptographic proof
V-PROOF: infraestructura modular de evidencia para la gobernanza de la IA
Siete capacidades integrables para registrar activos, versiones, decisiones, revisiones humanas y eventos de software con evidencia técnica verificable. V-PROOF complementa los sistemas de gobierno, riesgo y cumplimiento existentes; no sustituye por sí solo las obligaciones jurídicas, organizativas o de conformidad.
Key Points
- V-PROOF se posiciona como una capa probatoria integrada en los procesos corporativos, no como una declaración automática de cumplimiento.
- Una huella SHA-256 permite comprobar la correspondencia e integridad de un activo presentado posteriormente; no demuestra por sí sola su autoría, veracidad, licitud o aprobación.
- El anclaje externo puede reforzar la cronología y dificultar la alteración retroactiva, pero no equivale automáticamente a un sello de tiempo cualificado eIDAS.
- Las siete capacidades descritas pueden implantarse de forma gradual. Su disponibilidad depende de la versión, el alcance y la modalidad de despliegue acordada.
- El origen europeo del proveedor reduce determinados vectores de exposición jurisdiccional, pero la soberanía efectiva depende también de cloud, subencargados, soporte, claves, telemetría y redes externas.
De la documentación declarativa a la evidencia vinculada al proceso
Las políticas, procedimientos e informes siguen siendo esenciales. El reto aparece cuando la organización debe relacionar esos documentos con una versión, una decisión o una intervención concreta y demostrar que el registro no fue alterado posteriormente.
Un procedimiento puede describir cómo debe realizarse la supervisión humana. Una capa probatoria puede registrar quién revisó, qué versión examinó, en qué momento y con qué resultado, siempre que la identidad, los metadatos y el contexto procedan de fuentes fiables.
V-PROOF estructura esa evidencia en puntos definidos del flujo: creación, validación, aprobación, publicación, despliegue o respuesta ante una incidencia. El resultado es un paquete verificable que puede utilizarse en auditorías, investigaciones internas o procesos de supervisión.
La criptografía permite comprobar integridad y correspondencia. El significado probatorio se completa con identidad, contexto, fuente, controles y cadena de custodia. Ninguna de esas dimensiones debe confundirse con las demás.
Contexto, huella y referencia: una cadena verificable
Cada operación debe definir previamente qué activo o evento se registra, qué identidad lo origina, qué metadatos son necesarios y qué información puede transmitirse fuera del entorno corporativo.
Resultado: evidencia técnica de correspondencia, integridad y cronología, condicionada por la calidad de las fuentes y la cadena de custodia.
En modalidades que utilicen redes públicas o almacenamiento distribuido, deben documentarse disponibilidad, persistencia, costes, proveedores, privacidad de metadatos y mecanismos de continuidad. Una referencia pública no garantiza por sí sola que el paquete completo de evidencia permanezca disponible.
Una arquitectura común para distintos puntos de evidencia
Los módulos pueden activarse de forma independiente o coordinada. Las integraciones, conectores, sistemas operativos y modos de despliegue deben confirmarse durante la evaluación técnica.
Hash, identificador del evento, versión, fuente, contexto, referencia temporal y metadatos definidos por la organización.
Versiones, métricas declaradas, aprobaciones, rechazos, excepciones y transición entre estados del ciclo de vida.
Sistema generador, versión, fecha, usuario o servicio, política aplicable, declaraciones y referencia del contenido.
Identidad, rol, acción, criterio, resultado y versión revisada. No evalúa por sí mismo la calidad sustantiva de la decisión.
Repositorio, commit, pipeline, artefacto, resultado del control, aprobación y entorno de despliegue.
Inicio del flujo, fuente, datos minimizados, resultado, excepción y estado de sincronización.
Huella local, metadatos definidos, cola de sincronización y estado del registro. El anclaje externo requiere conectividad.
Una biblioteca de outputs no satisface automáticamente el marcado técnicamente detectable del artículo 50 del AI Act. Una integración Git tampoco cumple por sí sola el CRA. Cada módulo aporta evidencia de controles concretos dentro de un programa de cumplimiento más amplio.
Obligación, evidencia posible y límite de la herramienta
El mapeo siguiente identifica contribuciones potenciales. No constituye certificación de cobertura ni sustituye el análisis de aplicabilidad.
| Norma / obligación | Evidencia que puede apoyar | Capacidades | Límite |
|---|---|---|---|
| AI Act · Reglamento (UE) 2024/1689 | |||
|
Arts. 9–11 Riesgos, datos y documentación técnica |
Versiones, controles, revisiones, aprobaciones y fuentes declaradas. | AI Orchestrator V-SEAL Core | No evalúa automáticamente calidad, sesgo, representatividad ni suficiencia de la documentación. |
|
Art. 12 Conservación de registros |
Integridad y referencia temporal de logs producidos por el sistema o por la integración. | 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 Supervisión humana |
Intervenciones, aprobaciones, rechazos, escalados y roles. | V-PROOF AI | Registrar una intervención no demuestra que la supervisión fuera competente, efectiva o suficiente. |
|
Art. 50 Transparencia de ciertos sistemas y contenidos |
Procedencia, sistema generador, declaraciones y referencias del contenido. | AI Library | El registro no sustituye por sí solo el marcado machine-readable ni las divulgaciones exigibles. |
|
Arts. 53–55 Proveedores de modelos GPAI |
Versiones, documentación y eventos del ciclo de vida del modelo. | AI Orchestrator | Aplican a proveedores de modelos GPAI en los supuestos definidos por el Reglamento, no a todo usuario de un LLM. |
| Cyber Resilience Act · Reglamento (UE) 2024/2847 | |||
|
Arts. 13–14 Obligaciones del fabricante y notificación |
Cambios, artefactos, validaciones, vulnerabilidades e incidentes. | Git Integration V-SEAL Core | No sustituye secure-by-design, gestión de vulnerabilidades, evaluación de conformidad ni notificación oficial. |
| RGPD y Esquema Nacional de Seguridad | |||
| RGPD Arts. 5.2, 25, 30 y 32 | Evidencia de ejecución de controles, versiones y registros de determinados tratamientos. | V-SEAL Core AI Library Node-RED | No sustituye base jurídica, información, minimización, DPIA, contratos ni medidas de seguridad. |
|
ENS Trazabilidad y protección |
Registros verificables de cambios, accesos, operaciones y controles seleccionados. | V-SEAL Core Desktop Git Integration | No implica conformidad ENS ni sustituye categorización, medidas, auditorías y certificación cuando procedan. |
| DORA y NIS2 | |||
| DORA Arts. 9–10 y 17–19 | Controles de protección, detección, incidentes, clasificación, decisiones y cronología de respuesta. | V-SEAL Core V-PROOF AI | No sustituye el marco de gestión del riesgo TIC ni el canal y formato de notificación a la autoridad competente. |
| NIS2 Arts. 21 y 23 | Evidencia de medidas, cambios, incidentes y secuencia de notificación. | Git Integration V-SEAL Core | No sustituye las medidas de gestión de riesgos ni las obligaciones de reporte y gobierno de la entidad. |
El origen del proveedor importa, pero no resuelve toda la arquitectura
La sede, el control societario y las leyes aplicables forman parte de la diligencia debida. También deben revisarse subencargados, regiones, accesos remotos, soporte, telemetría, custodia de claves y redes públicas.
Riesgo jurisdiccional evaluable, no inmunidad absoluta
El CLOUD Act puede alcanzar a determinados proveedores sujetos a jurisdicción estadounidense respecto de datos bajo su posesión, custodia o control, aunque se encuentren almacenados fuera de Estados Unidos.
La constitución española de V-PROOF reduce la exposición directa como entidad frente a ese marco. No obstante, el análisis debe incluir todos los proveedores utilizados en alojamiento, soporte, comunicaciones, monitorización, custodia de claves y anclaje externo.
Qué aporta, dónde encaja y qué queda fuera
Capacidades probatorias, casos de uso y responsabilidades que permanecen en la organización.
- Huellas y referencias temporales asociadas a activos y eventos. Integridad · Correspondencia · Cronología
- Evidencia vinculada a versiones, aprobaciones y excepciones. Gobierno por diseño
- Registro de intervención humana cuando la identidad y el rol proceden de fuentes fiables. AI Act · Art. 14
- Integración progresiva en modelos, contenidos, software y procesos corporativos. API · Eventos · Desktop
- Ciclo de vida de sistemas de IA y modelos internos. Versiones · Evaluaciones · Despliegues
- Procedencia y gestión de outputs generativos. AI Act · Transparencia
- Cambios de software, CI/CD y cadena de suministro digital. CRA · NIS2
- Incidentes, revisiones y decisiones en entornos regulados. DORA · ENS · Auditoría
- Determinar la clasificación jurídica y las obligaciones aplicables a cada sistema. Evaluación legal y sectorial
- Evaluar calidad, sesgo, robustez, exactitud o seguridad sustantiva del modelo. Testing independiente
- Realizar evaluaciones de conformidad o emitir certificaciones reservadas a terceros habilitados. Organismos y servicios cualificados
- Garantizar que un dato declarado, una identidad o una aprobación sean verdaderos si la fuente de origen no es fiable. Calidad de fuente · Chain of custody
¿Qué evidencia puede generar hoy su arquitectura?
Analizamos sistemas, proveedores, fuentes de identidad y puntos de control para identificar brechas y definir una integración probatoria proporcionada al riesgo.
Evaluar mi exposición regulatoria →Fuentes normativas de referencia
- Reglamento (UE) 2024/1689 — AI Act.
- Comisión Europea — calendario de aplicación y simplificación del AI Act, actualizado en julio de 2026.
- Reglamento (UE) 2024/2847 — Cyber Resilience Act.
- Reglamento (UE) 2016/679 — RGPD.
- Real Decreto 311/2022 — Esquema Nacional de Seguridad.
- Reglamento (UE) 2022/2554 — DORA.
- Directiva (UE) 2022/2555 — NIS2.
- U.S. Department of Justice — CLOUD Act Resources.
Este artículo describe la arquitectura y el posicionamiento previsto de V-PROOF. Las funciones disponibles deben confirmarse en la versión, contrato y modalidad de despliegue correspondiente. El contenido no constituye asesoramiento jurídico, certificación ni garantía de cumplimiento o resultado probatorio.
