

Guía completa paso a paso para preparar tu solicitud y justificación del Kit Espacio de Datos con éxito. Incluye evidencias técnicas, guía práctica para solicitantes y chat con IA integrado.
El despliegue de la economía del dato en la Unión Europea ha transitado desde modelos teóricos hacia implementaciones tangibles, siendo el programa "Kit Espacios de Datos" la materialización de esta estrategia en el territorio español. Impulsado por el Ministerio para la Transformación Digital y de la Función Pública, a través de la Secretaría de Estado de Digitalización e Inteligencia Artificial, y gestionado operativamente por la entidad pública empresarial Red.es, este instrumento se enmarca en la Inversión 1 del Componente 12 del Plan de Recuperación, Transformación y Resiliencia (PRTR) financiado por los fondos europeos Next Generation EU.
A diferencia de las iniciativas de digitalización de madurez básica orientadas a la adquisición de herramientas ofimáticas o presencia web fundamental, el Kit Espacios de Datos, dotado con un presupuesto inicial de 60 millones de euros, representa un mecanismo de financiación de alta complejidad tecnológica. Su propósito fundacional es sufragar los costes derivados de la integración técnica, semántica y legal de organizaciones con alta madurez digital en ecosistemas sectoriales federados, conocidos como Espacios de Datos.
Los fondos se asignan por estricto orden de llegada de las solicitudes válidamente formuladas, hasta el agotamiento del crédito presupuestario o hasta la fecha límite: 31 de marzo de 2026 a las 11:00h.
Se aplica el modelo de Cuenta Justificativa Simplificada entregada en el mismo instante de la solicitud. La interconexión tecnológica, el despliegue de la arquitectura y el abono de los costes deben estar finalizados antes de la presentación.
El andamiaje legal reposa sobre la Orden TDF/758/2025, de 11 de julio, publicada en el BOE número 170. La celeridad administrativa unida a la perfección técnica en la generación de evidencias determinan la viabilidad de la captación de la subvención.
Quedan excluidas las Uniones Temporales de Empresas (UTEs), los profesionales en situación de autoempleo (autónomos sin forma societaria mercantil) y las comunidades de bienes o patrimonios separados carentes de personalidad jurídica.
Incorporación efectiva de carácter básico. La entidad culmina su adhesión contractual al espacio de datos, obtiene una identidad criptográfica y configura su infraestructura con el objetivo de consumir información y servicios.
Incorporación efectiva avanzada. La entidad trasciende la posición de consumidor pasivo para inyectar valor estratégico a la red, publicando al menos un producto de datos en el catálogo federado.
| Concepto | Participante (Privada) | Participante (Pública) | Proveedor (Privada) | Proveedor (Pública) |
|---|---|---|---|---|
| Ayuda máxima | 15.000 € | 25.000 € | 30.000 € | 50.000 € |
| Cobertura | 100% de gastos elegibles | |||
Cloud (Máx. 1 año)
El diseño de la convocatoria, al cimentarse sobre un pago único retrospectivo que requiere la finalización y liquidación previa del proyecto, traslada el esfuerzo probatorio inicial a las tesorerías y departamentos de contabilidad de las entidades solicitantes.
Premisa temporal inamovible: Únicamente son financiables gastos devengados con fecha posterior al 16 de julio de 2025 (publicación de las bases en el BOE). Gastos anteriores serán automáticamente excluidos.
IVA NO subvencionable: Bajo ninguna circunstancia es subvencionable. Debe ser detraído de las bases imponibles. Magnitudes en euros (€) con máximo 2 decimales.
Se permite imputar los costes salariales (nóminas y cotizaciones sociales obligatorias) de los ingenieros de datos, arquitectos de sistemas, desarrolladores backend, asesores legales de plantilla y gestores de proyecto directamente involucrados.
Es mandatorio implementar una metodología basada en la dedicación proporcional efectiva. Las organizaciones deben instaurar sistemas de registro horario (timesheets) fehacientes y auditables que vinculen las horas reportadas con tareas específicas del proyecto.
Engloba los honorarios por contratación de terceros expertos: servicios de ingeniería software para APIs, asesoría jurídica RGPD en entornos federados, y servicios de firmas consultoras.
Un modelo viable contempla el cobro de provisiones iniciales por la gestión de la adhesión vinculante y honorarios contingentes o success fees condicionados a la consecución efectiva y al cobro de la ayuda.
Cubre desembolsos en capital físico o lógico necesarios: hardware específico (servidores), alojamiento en la nube (cloud computing), capacidad de procesamiento y herramientas de middleware.
Las licencias SaaS son plenamente elegibles con una restricción: la financiación únicamente cubrirá el coste equivalente a un máximo de un año de suscripción.
No se financia el almacenamiento aislado de datos (silos), sino la creación de ecosistemas federados bajo estándares europeos alineados con IDSA y Gaia-X.
Se requiere la instalación de conectores de código abierto certificados: Eclipse Dataspace Components (EDC) o módulos FIWARE.
| Componente | Función Estructural | Implicaciones para la Evidencia |
|---|---|---|
| Sistemas Backend Internos | Repositorios primarios (ERP, Data Lakes, SQL/NoSQL, CRM) donde residen los datos originales. | Diagramas de red mostrando conexión segura con el nodo del conector sin exposición directa a internet. |
| Plano de Control | Núcleo de soberanía. Gestiona negociaciones de contratos, orquestación de transferencias y validación de políticas. | La Memoria Técnica debe explicar la configuración de APIs y cómo ejecuta los contratos digitales automatizados. |
| Plano de Datos | Componente de ejecución responsable de la transferencia física, eficiente y encriptada de los datos. | Registros del sistema (logs) evidenciando transferencias exitosas tras controles criptográficos. |
| Centro de Identidad Descentralizada | Infraestructura de confianza externa que verifica mediante protocolos criptográficos la identidad del interlocutor remoto. | Documentación de cómo el conector interroga al Identity Hub para verificación de identidad. |
| Catálogo Federado | Índice global donde se anuncian los productos de datos disponibles y sus condiciones de uso. | Capturas de la publicación efectiva en el catálogo federado. |
La interoperabilidad semántica requiere que los datos intercambiados sean interpretables de forma automática por aplicaciones de terceros. Se valora el uso de estándares como JSON-LD para contexto semántico preciso.
Para Proveedores, se exige definir los derechos, deberes y obligaciones en código ejecutable usando el estándar Open Digital Rights Language (ODRL) implementado dentro del conector Eclipse Dataspace.
Esta sección está dirigida al solicitante no técnico. Mientras que Procuredata se encarga de toda la programación compleja, el despliegue de servidores y la generación de registros informáticos (logs), su organización necesita colaborar en áreas específicas de su negocio. A continuación se detalla paso a paso qué actividades debe realizar.

Portada del documento "Guía Práctica para Solicitantes: Preparación de Evidencias Técnicas del Kit Espacios de Datos con conectores EDC en Procuredata"
Acceso Seguro (DMZ/Firewall): Habilitar una conexión segura para que el conector pueda "leer" los datos sin exponer el resto de servidores a Internet.
Diagrama de Red: Red.es exige un esquema visual. Su equipo informático debe proporcionar un diagrama básico (formato Visio, UML o similar) que muestre cómo sus servidores internos se conectan con el conector EDC de ProcureData.
Caso de Uso: Breve resumen de qué datos va a compartir y con qué objetivo comercial o sectorial.
Condiciones de Acceso: ¿Quién puede acceder? ¿Solo empresas europeas? ¿Tiene coste? ¿Durante cuánto tiempo?
Restricciones: ¿Hay datos sensibles que deban ser seudonimizados o anonimizados?
Limpieza de Datos (Data Cleansing): Seleccionar la base de datos o archivo (Excel, CSV, etc.) que va a compartir y asegurarse de que no contiene errores, celdas vacías corruptas o información personal no autorizada.
Diccionario de Datos: Documento simple (puede ser un Excel) donde explique qué significa cada columna del archivo.
Aprobación de la Política ODRL: Dar el "OK" definitivo a cómo quedan configuradas sus restricciones antes de publicarlas.
Timesheets: Partes de horas firmados detallando qué día y cuántas horas dedicó cada empleado a tareas exclusivas del proyecto.
Facturas Pagadas: Todas las facturas deben estar pagadas mediante transferencia bancaria antes de la solicitud.
Certificados DNSH: Certificados de eficiencia energética de servidores y firma del Anexo medioambiental.
En los espacios de datos europeos no existe el anonimato. Para participar, su empresa necesita una identidad digital certificada, conocida como Credencial Verificable de Gaia-X.
La normativa del Kit Espacios de Datos exige taxativamente la demostración de una separación estructural insoslayable entre el control del intercambio y la transmisión física de los datos. La arquitectura financiable no puede basarse en un simple intercambio de archivos mediante protocolos de transferencia tradicionales o repositorios centralizados en la nube.
El diseño técnico debe evidenciar el despliegue de nodos conectores que dividen sus operaciones de forma estricta en un Plano de Control (Control Plane) y un Plano de Datos (Data Plane). ProcureData utiliza la base de código del proyecto Eclipse Dataspace Components (EDC): cada conector separa el plano de control y el plano de datos, implementando esta misma bifurcación funcional y satisfaciendo plenamente los requerimientos de IDSA.
| Componente Red.es | Función Normativa | Equivalencia EDC | Evidencia Requerida |
|---|---|---|---|
| Sistemas Backend Internos | Repositorios primarios (ERP, Data Lakes, SQL/NoSQL, CRM) | Bases de datos locales protegidas tras firewall/DMZ | Diagramas de red (Visio/UML) mostrando aislamiento |
| Plano de Control | Gestión de negociaciones, orquestación, validación de políticas | Acuerdos de contrato EDC + políticas ODRL | Logs de inicialización de servicio, transferTxId confirmados |
| Plano de Datos | Transferencia física encriptada de datos | Conector EDC (data plane gestionado por la plataforma) | Logs de download, Proof-of-Download inmutable |
| Identity Hub | Verificación criptográfica del interlocutor | GXDCH + SSI (did:web) + Wallet did:ethr | Credenciales Verificables VP firmadas criptográficamente |
| Catálogo Federado | Índice global de productos y condiciones de uso | Catálogo Aquarius + metadatos JSON-LD | Capturas del dataset publicado con DID y políticas ODRL |

Cartografía de red demostrando el cumplimiento de la separación estructural exigida por Red.es. Los datos primarios permanecen aislados en el backend interno, mientras que el plano de datos del conector EDC gestiona la transferencia y el plano de control (Dataspace Protocol) orquesta catálogo, negociación y contratos.
El Plano de Control es el "cerebro" del sistema. Es el encargado de verificar quién pide sus datos y si tiene permiso, ejecutando contratos digitales automáticos (acuerdos de contrato EDC con ODRL) antes de mover un solo byte de información.
En ProcureData, esta gobernanza se ejerce mediante una arquitectura híbrida que combina los acuerdos de contrato EDC con política ODRL, el registro de evidencias firmado y el componente Conector EDC como controlador de acceso. El proceso algorítmico comienza cuando un consumidor solicita acceso a un producto de datos. El Provider invoca internamente el endpoint REST de inicialización: GET /api/services/initialize.
La respuesta exitosa (HTTP 200) no entrega datos, sino una cotización con la oferta de contrato EDC requerida y un nonce criptográfico. Solo tras la confirmación del cobro se genera el transferTxId que autoriza el siguiente paso.
Recreación de la traza de auditoría extraída del conector EDC del proveedor. Destacan las validaciones del identificador de transferencia (transferProcessId), la comprobación de firmas criptográficas y el registro definitivo de la descarga en el registro de evidencias, evidencias troncales para la cuenta justificativa.

Captura del documento oficial mostrando la traza de auditoría y evidencia empírica de trazabilidad de transferencia en el Plano de Datos.
Para que los registros operativos posean el nivel de granularidad requerido por la administración evaluadora:
LOG_CFG: Ubicación física del archivo de auditoría en el sistema de archivos.LOG_LEVEL=DEBUG: Modo detallado de diagnóstico para capturar el ciclo de vida completo de la petición HTTP.USE_CHAIN_PROOF=true: Inscribe automáticamente una prueba criptográfica en el registro de evidencias firmado (inmutable, no repudio).USE_HTTP_PROOF: Para consolidar evidencias en un SIEM corporativo centralizado.AUTHORIZED_DECRYPTERS: Lista blanca de direcciones autorizadas para desencriptar información.Para entidades que aspiren a maximizar la puntuación técnica (hasta 50.000 €), resulta estratégicamente imperativo documentar la funcionalidad de Compute-to-Data. En entornos donde la información no puede abandonar las instalaciones del custodio (datos biomédicos, secretos industriales), el Plano de Datos no transfiere el archivo, sino que orquesta un entorno de cómputo aislado (sandbox) dentro de la infraestructura local del proveedor.
Esto permite que algoritmos de IA viajen hacia los datos, entrenen modelos de aprendizaje automático (federated learning) y extraigan conocimiento sin revelar información en bruto.
Endpoints C2D a documentar:
POST /api/services/initializeCompute — InicializaciónPOST /api/services/compute — Ejecución del trabajo algorítmicoGET /api/services/computeResult — Extracción del resultadoOPERATOR_SERVICE_URL (vinculación con clúster Kubernetes/Docker)En el paradigma de un espacio de datos verdaderamente soberano, la eliminación absoluta del anonimato en las interacciones es un precepto tecnológico innegociable. El Identity Hub actúa como una infraestructura de confianza externa que verifica mediante protocolos criptográficos la titularidad y legitimidad de los interlocutores.
En ProcureData, este requisito se satisface mediante la adherencia al marco normativo de Gaia-X Trust Framework y el uso de Identidades Autosoberanas (SSI), basadas en los estándares abiertos del W3C: Documentos de Identidad Descentralizada (DID) bajo el método did:web.
La entidad no se registra con un formulario web estándar con usuario y contraseña. Debe orquestar una interacción técnica con los servicios del GXDCH usando sus propias claves criptográficas. El flujo comienza con la solicitud de una Credencial Verificable de Participante (Participant VC) a través del Gaia-X Wizard.
Esta credencial debe incluir: el nombre legal exacto, la dirección corporativa (ISO 3166-2), y el Número de Registro Legal (EUID, EORI, LEI o NIF), que el motor de verificación cotejará contra registros oficiales europeos.
La VP (Verifiable Presentation) es un documento serializado en JSON-LD que consolida múltiples credenciales en un único objeto de transmisión. Debe ser firmada criptográficamente (estándar JSON Web Signature - JWS) mediante la clave privada soberana de la entidad.
La clave pública complementaria debe estar alojada en el Documento DID público de la organización, cerrando el ciclo de confianza criptográfica sin depender de un directorio central.
Red.es exige demostrar "cómo el conector interroga al Identity Hub" de manera operativa. En los conectores EDC de ProcureData, esto se ejecuta dinámicamente cada vez que se intenta una transacción. El servicio de cumplimiento (Compliance Service) inspecciona la cadena de certificados X.509 asociados a la firma pública del consumidor.
Esta inspección garantiza que las firmas provienen de una Autoridad de Certificación reconocida bajo el reglamento europeo eIDAS (Reglamento UE 910/2014).
La Memoria debe incorporar volcados de peticiones/respuestas de la API de Compliance probando la emisión del veredicto positivo, que se materializa en una nueva "Gaia-X Verifiable Credential" de cumplimiento.
El Registro 2.0 es una estructura dinámica y distribuida alimentada vía API REST que rastrea los DID de los participantes vinculándolos a las credenciales de cumplimiento Gaia-X emitidas por el clearing house.
Proporciona un panel público y auditable que certifica el alta operativa y el estado activo de la mercantil dentro del ecosistema de confianza europeo.
El programa Kit Espacios de Datos penaliza la compartición de datos crudos (raw data) y bonifica con la mayor intensidad financiera a organizaciones que ejecutan labores de ingeniería de datos, dotando a sus conjuntos de un significado estructurado y procesable por máquinas.
En el Catálogo Federado DCAT-AP de MyDataSpace, esta contextualización se logra modelando los activos como Objetos de Datos Descentralizados (DDO) bajo el estándar JSON-LD (JSON for Linked Data).
El atributo crítico @context funciona como una matriz de validación que define la ontología exacta que rige las propiedades de los datos compartidos, asegurando que variables como id, type, created, author y license se interpreten de forma universal.
La prosa legal tradicional (acuerdos de confidencialidad en PDF, términos y condiciones) carece de validez técnica operativa en entornos de transaccionalidad a nivel de máquina. Los derechos, permisos condicionados y obligaciones deben transcribirse a código ejecutable y auditable usando el estándar ODRL del W3C.
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Set",
"uid": "https://w3c.github.io/odrl/bp/examples/1",
"permission": [{
"target": "http://example.com/asset:9898.movie",
"action": "use",
"constraint": [{
"ovc:leftOperand": "location",
"odrl:operator": "odrl:eq",
"odrl:rightOperand": "Europe",
"ovc:credentialSubjectType": "ParticipantCredential"
}]
}]
}@context + @type + uid — Establece el andamiaje legal de la política. Identifica unívocamente el acuerdo y declara que rige bajo el estándar normativo digital del W3C para espacios de datos.
permission — Inicia la autorización formal. El Proveedor habilita afirmativamente el acceso de terceros. Todo acceso no definido explícitamente queda denegado por defecto.
target + action: "use" — Fija el producto de datos exacto expuesto en el Catálogo Federado y limita la interacción a un consumo básico de solo lectura, protegiéndolo frente a modificación.
constraint — Condición de ejecución automatizada (política ODRL en el conector EDC). La transferencia solo se autoriza si el consumidor presenta una Credencial Verificable válida (ParticipantCredential) atestiguando que su ubicación geográfica coincide con el operando establecido.

Mapeo esquemático de un contrato digital. La política ODRL determina el conjunto de datos (Target), habilita su consumo (Action: use) y establece restricciones vinculadas a las Credenciales Verificables (Constraint) requeridas para la autorización automática en el conector EDC.
Designación unívoca del recurso protegido, expresado mediante su DID en ProcureData.
Declaración explícita de operaciones autorizadas: use, read, access.
Barrera programática de soberanía: restricciones temporales, geográficas o de identidad vinculadas a VCs.
La administración pública evaluadora ejerce una desconfianza sistémica hacia la documentación meramente descriptiva. Red.es es muy estricta: si no se ve, no existe.
Las capturas de pantalla deben revelar de manera nítida e inalterada el reloj y el calendario del sistema operativo de la máquina desde la que se ejecuta la acción de auditoría, certificando que la plataforma estaba operativa dentro de las fechas de elegibilidad.
Capturas mostrando:
Además de las anteriores, capturas del catálogo público mostrando:
Contrato de Adhesión: Documento PDF (máx. 2 MB) que vincula contractualmente al solicitante con el Promotor del Espacio de Datos. Debe estipular: identidad verificada de las partes, vigencia temporal, y que el objeto es la adhesión operativa al espacio sectorial.
Declaración de Evidencias de Registro y Publicación: Firmado electrónicamente de forma mancomunada (certificados cualificados) por el apoderado del solicitante y el representante del Promotor. Da fe de que registro, asignación de identidades y publicación se ejecutaron correctamente.
La grabación de pantalla ininterrumpida debe trazarse como un flujo de usuario que narre el ciclo de vida completo de la operatividad:
Login en ProcureData evidenciando intercambio de identidades seguras mediante credenciales verificables (DCP) e identidad did:web del conector. El acceso de usuarios se realiza con cuentas propias (Keycloak).
Tránsito visual por las áreas privadas del panel de control del proveedor, mostrando la gestión de los activos publicados.
Simular la experiencia de un consumidor externo: buscar el producto por metadatos semánticos, abrir la página de detalle mostrando DID, políticas y oferta en vivo. Culminar evidenciando la transaccionalidad real.
El diseño financiero de la convocatoria reposa sobre un pago único retrospectivo que demanda la ejecución previa, finalización técnica y completa liquidación económica del proyecto antes de remitir la documentación.
Para justificar costes de personal propio, es mandatorio un sistema de certificación de trazabilidad horaria. Los registros deben vincular la jornada técnica exacta de cada empleado con tareas cristalinas del proyecto.
Conceptos genéricos serán rechazados. El registro debe detallar actividades técnicas precisas como: "Despliegue y configuración del conector EDC", "Codificación de reglas ODRL", "Mapeo de variables a esquemas JSON-LD", "Gestión de certificados SSI y sincronización con GXDCH".
La memoria de estructuración del gasto debe presentar una matriz de detracción fiscal contable en Excel que excluya de forma rigurosa y sistemática el IVA, coste considerado tributariamente recuperable y nunca elegible mediante fondos públicos en esta tipología de ayudas.
En un escenario que depende de redes distribuidas, procesamiento criptográfico continuo e infraestructuras cloud escalables, el cumplimiento del principio DNSH debe ser inmaculado y documentado.
El incumplimiento o justificación deficiente del DNSH es una de las causas más frecuentes de denegación directa de expedientes de digitalización en el marco del PRTR.
Todos los fondos del PRTR están condicionados al cumplimiento del principio "Do No Significant Harm" (DNSH). El solicitante debe completar el Anexo I (Cuestionario de Autoevaluación DNSH) y el Anexo IV (Declaración DACI).
Certificación de eficiencia energética de servidores y hardware (Directiva 2009/125/CE).
Evaluación de riesgo climático y vulnerabilidad física de instalaciones IT.
Hardware sin sustancias REACH. Equipos canalizados a gestores autorizados para recuperación al fin de vida.
Cumplimiento de normativas de uso sostenible del agua y protección de ecosistemas.
Están vetadas entidades cuya actividad troncal orbite en torno a: refinerías de petróleo, extracción/procesamiento de combustibles fósiles, generación termoeléctrica basada en carbón, u operación de vertederos e incineradoras.
La Cuenta Justificativa Simplificada demanda cuatro bloques de evidencia fundamentales:
Requisito obligatorio: El reloj y calendario del sistema operativo debe ser nítidamente visible.
Participantes: Evidencia de registro mostrando nombre del espacio, usuario corporativo e identificador único.
Proveedores: Además, visualización del dataset en el catálogo federado mostrando DID, metainformación, políticas ODRL y accesibilidad por terceros.
Contrato de Adhesión: Archivo digital (máximo 2 MB) con firma electrónica mancomunada.
Declaración de Evidencias: Documento con firma electrónica mancomunada del apoderado del solicitante y del representante del Promotor.
Grabación de pantalla ininterrumpida (screencasting) del ciclo de vida completo:
La adhesión debe realizarse exclusivamente sobre espacios de datos que ostenten el respaldo oficial del Gobierno de España, auditados por el Centro de Referencia de Espacios de Datos (CRED).
Espacio multimodal biomédico y genómico. Requiere ENS Nivel Alto y seudonimización en origen.
Datos biológicos, genéticos, microbianos y de sensorización agraria.
Sector automoción basado en Catena-X. Trazabilidad soberana de componentes.
Instrumento dividido en 5 módulos especializados dirigidos a los departamentos corporativos competentes.
| Elemento | Formato | Justificación |
|---|---|---|
| Identidad y Fiscalidad | NIF oficial, domicilio fiscal UE | Personalidad jurídica |
| Poderes Notariales | PDF escrituras de apoderamiento | Capacidad legal del firmante |
| Certificados AEAT/TGSS | Telemáticos (<6 meses) | Ley General de Subvenciones |
| Certificado Bancario | IBAN con sello entidad financiera | Cuenta para reembolso |
| Declaración Responsable | Firma digital: no crisis, DACI | Compromiso PRTR antifraude |
| Elemento | Formato | Justificación |
|---|---|---|
| Determinación de Roles | Declaración Participante vs Proveedor | Determina presupuesto máximo |
| Caso de Uso | Memoria de oportunidad y modelo de negocio | Resumen Ejecutivo de la Memoria |
| Análisis RGPD | Documentación DPO seudonimización | Requisitos Jurídicos |
| Ecosistema de Destino | Nombre oficial en Lista de Confianza CRED | Elegibilidad del destino |
| Elemento | Formato | Justificación |
|---|---|---|
| Cartografía de Red | Diagramas Visio/UML | Separación Plano de Datos y Control |
| Certificación del Conector | Especificaciones EDC/FIWARE | Conectores código abierto IDS/Gaia-X |
| Codificación ODRL | Fragmentos de código | Transposición reglas legales a código |
| Interoperabilidad Semántica | Esquemas XML/JSON-LD | Interoperabilidad requerida |
| Elemento | Formato | Justificación |
|---|---|---|
| Timesheets | Plantillas firmadas con desglose horario | Justificar gasto salarial |
| Facturas y Justificantes | Post-16 julio 2025 + transferencias SWIFT/SEPA | Trabajo concluido y abonado |
| Licencias SaaS/Cloud | Contratos ≤1 año pagados anticipado | Infraestructura directa del conector |
| Exclusión IVA | Extracción sistemática en cada factura | Mandato innegociable |
| Elemento | Formato | Justificación |
|---|---|---|
| Dossier DNSH | Anexo I + certificados eficiencia energética | Imperativo del PRTR |
| Contrato + Declaración | PDF (max 2MB) con firmas electrónicas | Vínculo interinstitucional |
| Screenshots | Con fecha/reloj, usuario, nombre espacio, ID dataset | Evidencia de operatividad |
| Vídeo | Screencasting del ciclo completo | Confianza visual definitiva |
El programa "Kit Espacios de Datos" cristaliza una evolución cualitativa en el panorama de las subvenciones tecnológicas europeas. No se trata de un mecanismo de inyección de liquidez orientado a la modernización aislada, sino de un vector estratégico que premia exclusivamente la interoperabilidad compleja, la madurez semántica y la cesión segura de soberanía en entornos B2B descentralizados.
La arquitectura de su convocatoria — régimen de concurrencia no competitiva y cuenta justificativa concurrente — elimina el margen para la iteración burocrática. Todo el esfuerzo debe estar cristalizado antes de la conformación del expediente.
Al documentar irrefutablemente:
Las organizaciones podrán catalizar la financiación de hasta 50.000 euros, integrándose en la vanguardia de la economía continental del dato.
PROCUREDATA gestiona la tramitación completa de tu solicitud Kit Espacio de Datos, incluyendo la preparación de evidencias, memoria técnica y conformación documental.