El código fuente

# De la transparencia formal a la transparencia por diseño

### Una arquitectura documental para la Administración pública local española

---

## Resumen ejecutivo

La transparencia administrativa española padece un desfase que no es de leyes, sino
de arquitectura documental: el ordenamiento (Leyes 19/2013, 39/2015 y 40/2015) ya
obliga a la publicidad y a la administración electrónica, pero la información nace y
circula en formatos, el PDF firmado, pensados para el ojo humano y no para su
tratamiento automatizado, lo que la convierte en *dark data*. Este trabajo sostiene
que ese problema se origina en la **producción interna del acto administrativo**,
donde documentos como la retención de crédito municipal se generan aplanando a PDF
datos que ya existían estructurados, y que puede corregirse adoptando **Markdown
con metadatos YAML como formato de origen** de la documentación (Pilar 2, el
núcleo), sobre el marco de la seguridad y la protección de datos (Pilar 1) y dejando
la automatización mediante blockchain como horizonte especulativo no realizable hoy
(Pilar 3). El *ask* de política pública, acotado a la administración local, se
escalona en dos palancas: a **corto plazo**, sin nueva legislación, que los
gestores de expedientes electrónicos que las entidades ya usan **emitan
Markdown+YAML junto al PDF**, exigible a través de sus Bases de Ejecución del
Presupuesto y sus pliegos de prescripciones técnicas y administrativas; a **medio
plazo**, y como complemento estatal, **incorporar CommonMark al Catálogo de
Estándares del Esquema Nacional de Interoperabilidad** (competencia de la AEAD,
antigua SGAD), congelado desde 2012 y sin ningún
formato de texto estructurado ligero. El Pilar 3 queda para el **largo plazo** y
fuera de la recomendación. La transición que se propone es la de una "transparencia
formal" a una "transparencia por diseño".

---

## 1. Introducción

La transparencia administrativa goza en España de un respaldo normativo sólido y,
sin embargo, de una eficacia material limitada. La Ley 19/2013, de 9 de diciembre,
de transparencia, acceso a la información pública y buen gobierno, consolidó un
deber de publicidad activa que, dos décadas después de la primera ola de
administración electrónica, se cumple de manera formal pero se agota con
frecuencia en la publicación de documentos que ningún ciudadano, empresa o
investigador puede tratar sistemáticamente. Este trabajo parte de una premisa
correctiva: la transparencia relevante en 2026 no puede entenderse ya como la
*publicación pasiva* de información, sino como una propiedad más exigente y
tripartita: **trazabilidad, accesibilidad algorítmica y auditabilidad**; es
decir, no basta con que la información esté publicada, sino que ha de ser
*procesable* por una máquina, a un coste razonable y sin pérdida, por quien quiera
interrogarla.

La tesis que se defiende es que el desfase entre ese ideal y la realidad no es, en
lo esencial, un problema de déficit normativo, sino de **arquitectura documental**,
y que puede corregirse mediante tres vectores tecnológicos de peso deliberadamente
desigual. Conviene que el lector conozca esa jerarquía desde la primera página,
porque estructura todo el argumento. El **núcleo** de la propuesta es el segundo
vector: la adopción de un **formato de origen estructurado, Markdown con metadatos
en YAML, para la documentación administrativa** (Pilar 2, §4), que es donde se
concentra el desarrollo y la recomendación realizable. En torno a él, el **marco**:
la infraestructura de confianza (Esquema Nacional de Seguridad y protección de
datos) como restricción de partida que cualquier propuesta debe respetar (Pilar 1,
§3), tratada con la brevedad de lo que fija reglas sin ser el objeto central. Y, en
un plano distinto y explícitamente subordinado, el **horizonte especulativo**: la
automatización y trazabilidad mediante blockchain y *smart contracts* (Pilar 3,
§6), que se examina no como propuesta operativa sino como dirección de futuro cuyas
condiciones de viabilidad, jurídicas y técnicas, aún no se cumplen. Estas tres
partes no pesan igual, y el trabajo no pretende que lo hagan.

El trabajo acota además su **alcance territorial a la administración local**
(ayuntamientos y diputaciones), por dos razones que el cuerpo desarrolla. Primera,
es donde el diagnóstico localiza el foso más profundo del problema: la producción
interna, masiva y rutinaria, de actos como la retención de crédito o los informes,
que nacen ya aplanados a PDF (§2, §5). Segunda, es donde las palancas de reforma
resultan realizables **sin necesidad de nueva legislación**, a través de
instrumentos que las propias entidades controlan: sus Bases de Ejecución del
Presupuesto y sus pliegos de prescripciones técnicas y administrativas (§7). Esta acotación no ignora el
plano estatal, que reaparece como recomendación complementaria, pero sí sitúa el
centro de gravedad del análisis en lo local.

Por último, una advertencia de método que el lector encontrará a lo largo de todo
el documento: se distingue de forma explícita entre lo **verificado contra fuente
primaria** (BOE, EUR-Lex, documentación técnica oficial), que se cita con su
identificador, y lo **señalado como especulativo, prospectivo o pendiente de
verificación de detalle**, que se marca como tal. Esta convención, desarrollada en
la nota metodológica de los apéndices, busca que el rigor de cada afirmación sea
legible en el propio texto, y es, en sí misma, una aplicación del principio de
transparencia que el trabajo defiende.

---

## 2. Diagnóstico: el desfase no es de leyes, es de arquitectura documental

La tesis de este apartado es deliberadamente incómoda para el discurso habitual
sobre modernización administrativa: en España, el problema de la transparencia
no es, en lo esencial, un problema de déficit normativo. El ordenamiento ya
obliga a casi todo lo que una lectura ambiciosa de la transparencia exigiría. La
Ley 19/2013, de 9 de diciembre, de transparencia, acceso a la información
pública y buen gobierno, impone la publicidad activa de la información
institucional, organizativa y contractual. La Ley 39/2015, de 1 de octubre, del
Procedimiento Administrativo Común, consagra el procedimiento electrónico como
regla y no como excepción. La Ley 40/2015, de 1 de octubre, de Régimen Jurídico
del Sector Público, ancla en su artículo 156 el Esquema Nacional de
Interoperabilidad y obliga a las Administraciones a relacionarse entre sí por
medios electrónicos. El mandato de transparencia, de administración electrónica
y de interoperabilidad existe, es exigible y lleva años en vigor.

Lo que falla está una capa por debajo de la ley: en la **arquitectura
documental** con la que ese mandato se materializa. La transparencia que el
ordenamiento describe se ejecuta, en la práctica, publicando y remitiendo
documentos cuyo formato está pensado para el ojo humano y para la conservación,
no para su tratamiento automatizado. El resultado es una transparencia
formalmente cumplida y materialmente opaca: la información *está publicada* (el
requisito legal se satisface) pero no es *procesable* a un coste razonable por
quien quiera interrogarla de forma sistemática. Es lo que la literatura de
gestión de la información denomina *dark data* (datos oscuros): información que una
organización posee y publica, pero que permanece efectivamente inaccesible al
análisis porque su formato obliga a procesos de extracción costosos y falibles:
parsing de PDF, OCR sobre documentos escaneados, desanidado de hojas de cálculo,
antes de poder ser leída por una máquina.

Conviene, sin embargo, calibrar el diagnóstico con honestidad y evitar la
caricatura de una Administración analógica que "no tiene nada digitalizado". El
grado de oscuridad de los datos no es uniforme, y el argumento pierde fuerza si
se generaliza en exceso. Hay que distinguir al menos tres capas, en orden de
profundidad creciente.

En un extremo relativamente favorable está el **Boletín Oficial del Estado**. El
BOE no es hoy el mejor ejemplo de *dark data*: además del PDF firmado que
constituye la versión auténtica, la Agencia Estatal BOE ofrece una **API REST de
datos abiertos** que expone los sumarios diarios y la **legislación consolidada**
con enlaces a los formatos **PDF, XML y HTML**, siguiendo además un enfoque de
*Linked Open Data*. Presentar el BOE como paradigma del problema sería, por tanto,
inexacto y debilitaría la credibilidad de la propuesta ante un lector experto.

En una posición intermedia está la **contratación pública**. Los pliegos de
cláusulas administrativas particulares y de prescripciones técnicas (el corazón
informativo de cualquier licitación) se publican de forma abrumadora como PDF
orientados a impresión, cuando no como documentos escaneados. Ahí el *dark data*
es real y cuantitativamente masivo: quien quiera comparar requisitos de
solvencia, criterios de adjudicación o condiciones de ejecución entre
licitaciones se enfrenta a miles de documentos no estructurados.

Pero incluso los pliegos son ya un resultado publicado (el final de una cadena), y
detenerse ahí sería quedarse en la superficie. Bajo ellos existe la capa más
profunda, más antigua y más fundamental del problema: la **producción interna del
acto administrativo**, el día a día de cualquier unidad, hasta el último
ayuntamiento. Antes de que nada se publique, la Administración fabrica los
ladrillos con los que se construye cualquier expediente: la **retención de
crédito (RC)** y el **certificado de existencia de crédito** de la ejecución del
gasto público local (regulados en los arts. 183-189 del Real Decreto Legislativo
2/2004, Texto Refundido de la Ley Reguladora de las Haciendas Locales, y
desarrollados por el RD 500/1990), los **oficios**, las **providencias**, los
**informes** (estos últimos, arts. 79-80 de la Ley 39/2015), y también las
**resoluciones** y las **notificaciones** con las que un expediente se cierra y se
comunica a la persona interesada (arts. 88 y 40-46 de la Ley 39/2015): el mismo
patrón de datos ya estructurados aplanados a prosa se repite en todo tipo
documental de producción repetitiva, no solo en el acto de inicio. Y los fabrica de un
modo revelador: plantillas de Word recicladas de expediente en expediente, que se
copian, se pegan, se ajustan y finalmente se aplanan a un PDF que se firma
electrónicamente (art. 26 de la Ley 39/2015). El documento nace ya como prosa
libre, sin un modelo de datos subyacente, aunque en el sistema de gestión que lo
produjo esos datos (importe, aplicación presupuestaria, interesado, órgano,
fecha) existieran perfectamente estructurados.

Este es el hallazgo central del diagnóstico: **el *dark data* no se origina al
publicar, sino al producir.** Nace en el instante en que un dato que existía
estructurado se aplana a prosa firmada para "dar apariencia de formalidad" ante
un revisor humano. Y esa práctica no es un descuido, sino la respuesta a un
incentivo real: el sistema premia la formalidad *visual* del documento, que
parezca oficial, y no su funcionalidad como *dato*. Se produce así una paradoja
que conviene nombrar con seriedad: el acto que confiere al documento su mayor
valor jurídico-probatorio (aplanarlo a PDF/A y firmarlo electrónicamente) es
exactamente el que destruye su valor informático. La autenticidad y la estructura
entran en conflicto en el momento mismo de la producción, no solo en el de la
publicación.

La conclusión del diagnóstico es, entonces, precisa: no se necesita una reforma
constitucional ni, probablemente, siquiera una nueva ley de transparencia. Se
necesita intervenir en la **arquitectura de la fábrica documental** (la capa donde
el acto se produce), que las normas vigentes dan por resuelta y que, como se verá,
lleva sin revisarse desde antes de que existieran las herramientas que hoy podrían
explotar esa información. Es en esa capa de producción, más aún que en los pliegos
o en el BOE, donde el argumento de este trabajo incide con más fuerza, y de ella
procede el caso ilustrativo más humilde y concreto que se propone más adelante
(§5).

---

## 3. Marco de confianza: seguridad y protección de datos como restricción de partida

Cualquier propuesta de apertura y automatización documental debe apoyarse en una
capa de confianza previa; sin ella, la interoperabilidad y la descentralización no
son una mejora sino un riesgo. Esa capa ya existe en el ordenamiento español y no
hay que inventarla: hay que respetarla como restricción de partida.

El primer pilar es el **Esquema Nacional de Seguridad (ENS)**, hoy regulado por el
**Real Decreto 311/2022, de 3 de mayo**, que sustituyó al anterior RD 3/2010. El
ENS obliga a los sistemas del sector público, y a los del sector privado que le
prestan servicios, a garantizar cinco dimensiones de seguridad de la información:
**confidencialidad, integridad, trazabilidad, autenticidad y disponibilidad**. Dos
de ellas condicionan de forma directa el vector Markdown del núcleo (§4): la
**autenticidad** y la **integridad** son las que hoy se materializan en la firma
electrónica del PDF y en su sello de tiempo, y son la razón por la que este trabajo
sostiene que la representación en Markdown debe nacer como **representación
derivada** verificable, encadenada al documento auténtico firmado, y no como una
copia suelta que rompa la cadena de confianza (§4.4). "Derivada" se predica aquí
de la **validez jurídica**, no del orden de creación: el dato estructurado del
gestor de expedientes es el origen real (§4), y de él nacen a la vez el PDF
firmado (la versión que hace fe) y el Markdown (la representación legible por
máquina); lo que hace fe es el PDF, no cuál de los dos se generó primero. La
**trazabilidad**, por su parte, es precisamente lo que una arquitectura
*docs-as-code* mejora, no degrada.

El segundo pilar es la **protección de datos**: el Reglamento General de
Protección de Datos (**Reglamento (UE) 2016/679, RGPD**) y la **Ley Orgánica
3/2018 (LOPDGDD)**. De aquí procede el principio de **protección de datos desde el
diseño y por defecto** (art. 25 RGPD) y el de **minimización** (art. 5.1.c): toda
innovación debe tratar el mínimo de datos personales imprescindible. Este principio
es el que, más adelante, impone los límites más duros al horizonte de blockchain
(§6): como se verá, la posición regulatoria consolidada (AEPD y Comité Europeo de
Protección de Datos) es que los datos personales **no** deben inscribirse en la
cadena, sino permanecer *off-chain*, dejando en ella solo pruebas criptográficas,
preferentemente sobre redes privadas o permisionadas. El marco de confianza, en
suma, no es un adorno de cumplimiento: es lo que fija,
por adelantado, qué puede y qué no puede hacer cada uno de los otros dos vectores.

---

## 4. Núcleo: Markdown como formato de origen de la documentación administrativa

Este es el vector central de la propuesta. La tesis: adoptar **Markdown (con
metadatos en YAML/JSON) como formato de creación** de la documentación
administrativa de contenido textual, no como mero formato de publicación
añadido, de modo que la información nazca ya estructurada de forma legible tanto
para el ciudadano como para los modelos de lenguaje que éste quiera emplear para
interrogarla.

### 4.1 El problema del formato

Los formatos hoy dominantes para el *contenido* documental (PDF, DOCX, hojas de
cálculo, imagen escaneada) comparten un rasgo: fueron diseñados para la fidelidad
visual y la impresión, o para la edición ofimática, no para la extracción
semántica. Para un modelo de lenguaje, un PDF es un contenedor de posiciones
gráficas del que hay que *reconstruir* el texto y su estructura lógica mediante
procesos, extracción de capa de texto, OCR, reconstrucción de tablas y de orden de
lectura, que son costosos y, sobre todo, falibles: introducen errores que pasan desapercibidos,
pierden la jerarquía de articulado y generan *tokens* de ruido que consumen ventana
de contexto sin aportar información. La consecuencia es doble: encarece y degrada
cualquier intento ciudadano o empresarial de tratar la información pública con IA,
y lo reserva de facto a quien puede permitirse una ingeniería de extracción
robusta.

### 4.2 La propuesta

Markdown opera en la capa opuesta: es texto plano que codifica la *estructura
lógica* del contenido (encabezados, jerarquía, listas, tablas simples, énfasis) con
una sintaxis mínima y sin peso de etiquetado. Un documento nacido en Markdown no
necesita reconstrucción: su estructura es su texto. Acompañado de un bloque de
metadatos en YAML (órgano emisor, fecha, tipo documental, identificadores,
referencias normativas), ofrece a un LLM, incluido uno de código abierto que el
ciudadano ejecute localmente, una entrada directa, ligera y de máxima densidad
informativa por token. El objetivo no es estético: es habilitar lo que puede
llamarse *transparencia semántica* (que un ciudadano pueda preguntar a una ley o a
un pliego y obtener una respuesta fiel) reduciendo la brecha entre la jerga
jurídica y su comprensión, sin depender de intermediarios.

### 4.3 Estado del arte, y el argumento-bisagra: qué resuelve el ENI y qué no

Aquí es donde la propuesta debe demostrar que conoce el terreno y que no reinventa
lo ya resuelto. España dispone desde hace más de una década de un marco de
interoperabilidad: el **Esquema Nacional de Interoperabilidad, aprobado por el
Real Decreto 4/2010, de 8 de enero** (`BOE-A-2010-1331`), previsto hoy en el
art. 156 de la Ley 40/2015, desarrollado por un cuerpo de Normas Técnicas de
Interoperabilidad (NTI) de 2011-2013. Un lector experto objetará, con razón, que
la interoperabilidad documental *ya está normada*. La respuesta, y este es el eje
argumental de todo el trabajo, es que **el ENI resuelve una capa distinta de la que
aquí se propone intervenir**, y conviene ser terminológicamente exacto para no
incurrir en un error de bulto.

Lo que el ENI y sus NTI resuelven es la **interoperabilidad sintáctica y de
intercambio** entre sistemas. La NTI de Documento Electrónico (Resolución de 19
de julio de 2011, `BOE-A-2011-13169`) y la de Expediente Electrónico
(`BOE-A-2011-13170`) definen, en esencia, un *sobre* en XML (estructura, índice
electrónico, firma y un conjunto de metadatos mínimos obligatorios) para que una
Administración remita a otra un expediente y ésta lo reconstruya sin pérdida y
con plena validez probatoria. Es un logro real, pero es interoperabilidad de
*transporte, prueba y catalogación*: describe el documento *desde fuera*
(quién lo emitió, cuándo, con qué firma) y garantiza que el envío llega íntegro y
auténtico. La propia "interoperabilidad semántica" que el RD 4/2010 menciona se
refiere a **modelos de datos y vocabularios compartidos** (que dos sistemas
coincidan en que un campo dado es un NIF), es decir, semántica *de estructura de
datos*, no de lenguaje natural.

El punto decisivo es qué ocurre con el **contenido** real del documento (el
articulado de un pliego, el texto de una resolución) dentro de ese sobre: viaja
como un fichero adjunto cualquiera, y ese fichero es, de manera abrumadora, un
PDF. La NTI de Documento no fija por sí misma los formatos de contenido admisibles:
remite al **Catálogo de Estándares (Resolución de 3 de octubre de 2012,
`BOE-A-2012-13501`)**, cuyo anexo, categoría "Formatos de fichero - Imagen y/o
texto", admite PDF, PDF/A, ODF, OOXML, HTML, MHTML, RTF, CSV (*Comma-Separated
Values*) y SVG como formatos de documento (más TIFF, JPEG y PNG como formatos
de imagen dentro de esa misma categoría mixta); XML figura admitido, pero en la
categoría de datos enlazados, no en la de documentos, y XHTML no figura en el
Catálogo en absoluto. Dos hechos son
relevantes y están verificados. Primero: esos formatos están optimizados para el
intercambio entre sistemas y para la lectura y preservación *humanas* (el PDF/A es
un formato de archivo, no de análisis), no para la ingestión por modelos de
lenguaje. Segundo: **Markdown/CommonMark no figura en el Catálogo**, lo que es
coherente con que éste data de 2012, y, hallazgo más significativo, **el ENI no ha
sido nunca refundido** como sí lo fue su hermano el Esquema Nacional de Seguridad
(sustituido íntegramente por el RD 311/2022, de 3 de mayo). El marco de
interoperabilidad documental español está, en su núcleo, congelado en 2010-2013:
**anterior a la irrupción de los grandes modelos de lenguaje**. Nadie ha revisado
el Catálogo de Estándares pensando en que una máquina no programada ad hoc leyera y
comprendiera el contenido.

De ahí la formulación defendible ante un experto en administración electrónica:
el XML del ENI y el Markdown *no compiten en la misma capa*. El XML-NTI es un
formato de empaquetado y metadatos, extenso en etiquetas y namespaces, cuyo peso
estructural es precisamente ruido para un LLM y que, además, no toca el texto del
documento, que sigue siendo PDF. Markdown estructura el *contenido legible* con
jerarquía mínima y peso casi nulo. El ENI resuelve el transporte entre sistemas;
Markdown resolvería la legibilidad del contenido por la IA y por el ciudadano, una
capa que el ENI hoy no cubre.

Un matiz de honestidad intelectual, imprescindible para no afirmar de más: existe
una excepción dentro del cuerpo NTI donde la Administración sí impulsa formatos
semánticos. La **NTI de Reutilización de la Información del Sector Público
(NTI-RISP, Resolución de 19 de febrero de 2013, `BOE-A-2013-2380`)** promueve la
apertura de datos con metadatos DCAT/Dublin Core y formatos preferentemente
semánticos como RDF y *linked data*. Es lo más cercano a "semántica" del marco, y
conviene nombrarlo para mostrar que se conoce el estado del arte, pero se aplica a
*datasets* de reutilización (el ecosistema de datos.gob.es), no a la representación
del *documento administrativo o legal* en sí: RDF describe *datos*, no el texto de
una resolución o un pliego. Para el documento textual, el hueco persiste.

Fuera de España, y en el plano de las representaciones ricas de la norma jurídica,
conviene situar la propuesta frente al estado del arte internacional. Existe un
estándar XML internacional específico para documentos legislativos, **Akoma
Ntoso**, ratificado como estándar OASIS (LegalDocML) en su versión 1.0 en **agosto
de 2018**, que modela nativamente articulado, disposiciones, referencias cruzadas y
el ciclo de vida de la norma; y el **European Legislation Identifier (ELI)**,
acuerdo voluntario entre los Estados de la UE que aporta identificadores (URIs),
metadatos y un lenguaje de intercambio de legislación en formato legible por máquina
(Akoma Ntoso es más comprensivo que ELI y se centra en el ciclo de vida del
documento). En la misma línea existen los formatos de repositorios nacionales como
legislation.gov.uk (CLML) y de EUR-Lex (Formex). Frente a todos ellos, la posición
honesta de Markdown no es la de sustituto sino la de complemento en otra capa:
Markdown es *más ligero y accesible* pero *semánticamente más pobre* (§4.4). La
propuesta se posiciona, pues, como la capa de contenido legible de bajo coste, no
como el modelo jurídico estructurado completo.

### 4.4 Objeciones y límites

Un trabajo riguroso se anticipa a sus propias debilidades. Dos son las de mayor
calado. La primera, de **autenticidad jurídica**: hoy la versión que "hace fe" de
una disposición o de un acto es el documento firmado electrónicamente (con su
Código Seguro de Verificación, CSV, y sello electrónico), y la validez jurídica se
ancla a ese artefacto. Proponer que Markdown *sustituya* a la versión auténtica
exigiría reforma normativa y abriría la pregunta de qué representación prevalece en
caso de discrepancia. La vía prudente y realista es Markdown como **representación
derivada, legible por máquina, publicada junto a** la versión auténtica firmada, no en
su lugar: derivada en fuerza probatoria (en caso de discrepancia, prevalece el
PDF firmado), no en orden de generación, ya que ambas nacen del mismo dato
estructurado (§4). La segunda, de **pobreza semántica**: la misma ligereza que hace a
Markdown ideal para el consumo por LLM lo hace insuficiente para capturar
nativamente la estructura jurídica fina (jerarquía de articulado, disposiciones
adicionales y transitorias, remisiones, versionado consolidado de una ley
reformada) que un XML como Akoma Ntoso sí modela. Reconocer este límite delimita
correctamente la ambición: Markdown gana en la capa de contenido legible, no en la
de modelo jurídico estructurado.

### 4.5 La palanca real de adopción

El obstáculo determinante no es técnico sino de gobernanza, y el diagnóstico (§2)
ya apuntó dónde: ningún actor está obligado a producir en Markdown, y el ENS (que
regula seguridad) no es la palanca: regula cómo se protege la información, no en qué
formato se crea. La palanca normativa correcta y concreta es el propio **ENI y su
Catálogo de Estándares (NTI)**. El primer *ask* de política pública, por tanto, es
preciso y de bajo coste: **incorporar un formato de texto estructurado ligero
(CommonMark) al Catálogo de Estándares del ENI** como formato admisible para la
publicación legible por máquina del contenido documental.

Pero la palanca normativa por sí sola no bastaría si su cumplimiento exigiera un
cambio de conducta de cientos de miles de empleados públicos. Aquí es donde el
diagnóstico de la capa de producción (§2) reorienta la propuesta hacia algo mucho
más concreto. Sería irreal, y contrario a la práctica administrativa real, la de
la plantilla reciclada y el copiar-pegar, pedir que los funcionarios *escriban
Markdown a mano*. No hace falta: como se vio, cuando una unidad genera una
retención de crédito, un oficio o un informe, **los datos ya existen
estructurados** en el gestor de expedientes que la mayoría de las entidades ya
utilizan (importe, aplicación presupuestaria, interesado, órgano, fecha), y solo se
pierden en el momento en que el motor de plantillas los combina y los aplana a Word
y PDF. El segundo *ask*, por tanto, se dirige a ese motor, no al empleado:

> Que los **gestores de expedientes electrónicos** emitan, en la propia operación
> de generación del documento, una representación **Markdown + YAML** (reutilizando
> los datos que ya obran estructurados en el sistema) junto al PDF firmado.

Formulada así, la adopción deja de ser un problema de hábito (intratable) para
convertirse en una función de producto (tratable), de coste marginal casi nulo,
que además resuelve el problema **en su origen, en la fábrica del documento**, de
modo que la estructura sube limpia por toda la cadena posterior (expediente,
publicación, intercambio, consulta por LLM). La exigencia puede canalizarse por
vías que no requieren nueva legislación: los **pliegos de prescripciones técnicas
y administrativas** de esos
sistemas y las **políticas de gestión documental** (o las propias Bases de
Ejecución) de cada entidad. Nombrar estas dos palancas, una normativa, una de
producto, es lo que separa la propuesta del mero voluntarismo: no pide una
revolución, pide actualizar un Catálogo de Estándares que, verificado por lectura
directa del texto (`BOE-A-2012-13501`, anexo, categoría "Formatos de fichero -
Imagen y/o texto"), admite PDF, PDF/A, ODF, OOXML, HTML, MHTML, RTF, CSV y SVG
pero **no** Markdown, y lleva sin tocarse desde 2012, y
reconfigurar la salida de un software que las Administraciones ya han comprado.

---

## 5. Un caso ilustrativo: la retención de crédito municipal

Para que el argumento no quede en abstracto, conviene bajarlo a un único documento
concreto, elegido precisamente por su humildad: la **retención de crédito (RC)** de
un ayuntamiento. Es uno de los actos más numerosos y rutinarios de la
Administración local (se expide en la fase preventiva de casi cualquier gasto) y
uno de los mejor delimitados jurídicamente: se enmarca en la ejecución del
presupuesto regulada en los **arts. 183-189 del Real Decreto Legislativo 2/2004
(TRLRHL)** y desarrollada por el **RD 500/1990**, dentro de la secuencia de fases
del gasto A-D-O-P (Autorización, Disposición, reconocimiento de la Obligación,
ordenación del Pago). La RC es un documento contable *preventivo*: la Intervención
certifica que en una aplicación presupuestaria existe saldo suficiente y lo
*reserva* por un importe determinado, antes incluso de que se sepa quién será el
adjudicatario.

*(El documento y las cifras que siguen son un ejemplo hipotético construido para
mostrar la estructura, no un documento real.)*

**Cómo nace hoy ese documento.** En la práctica, la RC se produce como se describió
en el diagnóstico (§2): una plantilla en el gestor de expedientes se rellena con
los datos del caso y se aplana a un PDF que se firma electrónicamente. El
artefacto resultante es prosa maquetada ("Existiendo crédito adecuado y suficiente
en la aplicación presupuestaria 920.22000 del vigente presupuesto, por importe de
doce mil cuatrocientos cincuenta euros (12.450,00 €), se procede a su retención
para…"), correcta para el ojo humano pero **muerta como dato**: recuperar
sistemáticamente el importe, la aplicación o el expediente exige *parsing* del PDF,
con el riesgo de confundir cifras, arrastrar errores de OCR y perder toda
posibilidad de agregación fiable a escala.

**Cómo podría nacer.** La misma información, emitida en Markdown con un
encabezamiento de metadatos en YAML, sería a la vez legible por una persona y
procesable sin reconstrucción. Su aspecto sería, esquemáticamente:

```markdown
---
tipo_documento: retencion_de_credito        # RC (fase previa a A-D-O)
entidad: Ayuntamiento de Villaejemplo
nif_entidad: P4600000A
ejercicio: 2026
numero_operacion: "220260001234"
fase: RC
aplicacion_presupuestaria:
  organica: null
  programa: "920"        # Administración general
  economica: "22000"     # Material de oficina no inventariable
importe_euros: 12450.00
expediente: "2026/CONTR/045"
objeto: "Suministro de material de oficina para dependencias municipales"
tercero: null            # no determinado aún: la RC precede a la disposición
organo_gestor: "Intervención General"
fecha: 2026-03-15
base_legal:
  - "RDLeg 2/2004 (TRLRHL), arts. 183-189"
  - "RD 500/1990"
firma:
  csv: "ABCD-1234-EFGH-5678"   # Código Seguro de Verificación
  autoridad: "Interventor/a"
---

# Retención de crédito, nº 220260001234

Existiendo crédito adecuado y suficiente en la aplicación presupuestaria
**920.22000** del presupuesto del ejercicio **2026**, por importe de
**12.450,00 €**, se **retiene** dicho crédito para atender el gasto del
expediente **2026/CONTR/045** (*suministro de material de oficina*).
```

Conviene subrayar un detalle que ilustra la superioridad del formato estructurado
sobre la mera prosa: el campo `tercero` figura explícitamente como `null`. La
estructura no solo captura lo que hay; también **representa lo que aún no hay**: el
adjudicatario, que solo se determinará en la fase de disposición, de un modo
inequívoco, mientras que en el PDF esa ausencia es simplemente silencio.

**Qué se vuelve posible.** Sobre la versión estructurada, una pregunta como
*"¿cuánto crédito reservó el ayuntamiento en 2026 en la aplicación 920.22000, y en
qué expedientes?"* se responde de forma **determinista y auditable**: es una
agregación exacta sobre los campos `importe_euros`, `aplicacion_presupuestaria` y
`expediente` de todas las RC del ejercicio, sin ambigüedad. Un modelo de lenguaje
puede formular y explicar esa consulta, pero la fiabilidad no depende del modelo,
sino de que el dato esté estructurado en origen. Sobre la versión en PDF, esa misma
pregunta obliga a extraer cada cifra de la prosa de cientos o miles de documentos,
un proceso costoso y falible en el que un solo error de *parsing*, un "12.450"
leído como "124.500", una aplicación presupuestaria partida por un salto de
línea, contamina el resultado de forma silenciosa. La diferencia no es de grado
sino de naturaleza: en un caso se consulta un dato; en el otro se apuesta a
reconstruirlo.

**Los límites del ejemplo.** Este caso descansa sobre una premisa que conviene no
dar por cerrada: que el gestor de expedientes puede emitir esa representación
estructurada porque **ya dispone de los datos estructurados** que la alimentan. La
documentación de producto de los gestores de referencia en la Administración local
española (p. ej. esPublico Gestiona) apunta con fuerza en esa dirección: describe
"estructuras de datos" y "reglas de captura por tipo de documento", lo que da a la
premisa una confianza media-alta; pero no se ha inspeccionado el esquema interno de
un documento concreto como la RC, de modo que la afirmación se sostiene como
razonablemente fundada, no como hecho verificado al detalle. El ejemplo, en todo
caso, no depende de esa premisa para su valor demostrativo: muestra qué se gana con
la estructura; la premisa solo condiciona lo barato que resulta obtenerla.

---

## 6. Horizonte especulativo: trazabilidad y automatización mediante blockchain

*Esta sección es deliberadamente prospectiva y se presenta separada del cuerpo con
certeza del trabajo. A diferencia de los pilares 1 y 2, aquí no hay una propuesta
operativa lista: hay una dirección de futuro cuyas condiciones de viabilidad
(jurídicas y técnicas) aún no se cumplen, y que solo es honesto exponer si se
nombran a la vez sus obstáculos. El tono es, por tanto, de mapa de tensiones, no de
recomendación.*

El tercer vector de la propuesta, convertir las condiciones legales en código
ejecutable sobre una red distribuida, bajo el lema "el código es ley" (*Code is
Law*), es el más ambicioso y el que exige más cautela. Conviene adoptar de entrada
una matización imprescindible: el "código es ley" solo es admisible **supeditado al
"cumplimiento es ley"** (*Compliance is Law*). El derecho administrativo español
impone a esa supeditación un contenido muy concreto, que desactiva buena parte de
la promesa de automatización tal como suele formularse.

**El límite jurídico duro: la automatización de la contratación choca con
garantías procedimentales irrenunciables.** El ejemplo más citado, un *smart
contract* que excluya automáticamente las ofertas que no cumplan los requisitos
económicos, es, precisamente, el que la Ley 9/2017 de Contratos del Sector Público
(LCSP) prohíbe automatizar sin más. Su **artículo 149**, sobre ofertas anormalmente
bajas, **obliga a dar audiencia al licitador** para que justifique su oferta antes
de rechazarla; una exclusión automática por oráculo, sin ese trámite contradictorio,
sería nula. Y buena parte de los criterios de solvencia y adjudicación son
*conceptos jurídicos indeterminados* que requieren un juicio de valor, no un
cálculo. Lo genuinamente automatizable es, por tanto, mucho más estrecho de lo que
sugiere el lema: apertura de sobres en plazo, comprobación aritmética de los
criterios evaluables mediante fórmula, sellado temporal y trazabilidad del
expediente. Eso es *trazabilidad y auditoría automatizadas* (valioso), no "la
máquina adjudica".

**El límite estructural: la inmutabilidad choca con la revisabilidad del acto
administrativo.** Todo el sistema de garantías del administrado se construye sobre
que los actos son **revisables**: recursos de alzada y reposición (arts. 121-124
de la Ley 39/2015), nulidad de pleno derecho (art. 47) y anulabilidad (art. 48),
revisión de oficio (art. 106) y revocación (art. 109), y la institución del
**silencio administrativo** (arts. 24-25), sin análogo natural en un contrato que
"se ejecuta inexorablemente". Un *smart contract* inmutable no sabe deshacerse
cuando un tribunal anula el acto o cuando prospera un recurso. La inmutabilidad,
vendida como virtud, es aquí un lastre: cualquier diseño realista tendría que
incorporar **reversibilidad gobernada** (mecanismos de pausa y de anulación,
adjudicaciones que sean *propuesta* revisable y no acto firme), lo que relativiza
buena parte de la promesa de "ejecución inexorable".

**El límite de protección de datos: inmutabilidad frente al derecho de supresión,
y oráculos que hoy no son lo que se supone.** La tensión entre una cadena
inmutable y el **derecho de supresión (art. 17 RGPD)** tiene ya una respuesta
regulatoria consolidada, y conviene leerla con precisión: no es una prohibición,
es un protocolo de diseño. La Agencia Española de Protección de Datos (AEPD),
cuya prueba de concepto demuestra que es *viable* construir una infraestructura
blockchain conforme al RGPD, no que sea inviable, y el **Comité Europeo de
Protección de Datos (EDPB)**, en sus Directrices 02/2025 sobre tratamiento de
datos personales mediante blockchain (con la AEPD como ponente principal, versión
final adoptada el 7 de julio de 2026), convergen en tres reglas: los datos
personales se mantienen **fuera de la cadena** (*off-chain*), inscribiendo en ella
solo **pruebas criptográficas de existencia** (hashes con clave, compromisos
criptográficos); se prefieren explícitamente las **redes privadas o permisionadas**
frente a las públicas, porque en aquellas hay reglas claras de quién lee y escribe
y resulta más viable articular el derecho de supresión (en una red pública no
permisionada, garantizarlo podría exigir rediseñar la red entera); y una cautela
que impide el atajo fácil: **un dato cifrado o con hash sigue siendo dato
personal**, y el RGPD sigue aplicando. Es decir: la vía "registro inmutable sin
revelar identidad" que suele confiarse a las *Zero-Knowledge Proofs* no es
imposible, pero tampoco un detalle de despliegue, sino un problema de diseño de
grado avanzado cuya solución admitida hoy combina dato *off-chain*, prueba
*on-chain* y red de acceso controlado. En cuanto a los **oráculos** que
consultarían "en tiempo real" los datos fiscales, la infraestructura real es más
modesta de lo que la propuesta presupone: la **Plataforma de Intermediación de
Datos (PID)** del Ministerio de Hacienda ya permite verificar que un licitador
está al corriente de sus obligaciones tributarias (AEAT) y con la Seguridad
Social (TGSS), incluido un servicio específico "Obligaciones tributarias: Ley de
contratos", pero funciona como un servicio de **consulta bajo petición y con
control de acceso** (en el marco de Sustitución de Certificados en Soporte
Papel), no como un oráculo público que vuelque datos en tiempo real a una cadena.

**Una precisión que evita un malentendido frecuente: usar blockchain no obliga a
que todo sea auditable por todo el mundo.** Las arquitecturas permisionadas que
el propio regulador prefiere, y sobre las que se construye la infraestructura
pública europea (**EBSI** es una red *public-permissioned*, no una cadena
abierta; **ISBE** se concibe no como una única red sino como varias, cada una
adaptada a los requisitos de cumplimiento del caso de uso que sirve), soportan
**confidencialidad configurable**: canales aislados y colecciones de datos
privadas visibles solo para las partes autorizadas, sobre un mismo registro
compartido (el modelo, por ejemplo, de *Hyperledger Fabric*, el estándar de facto
en despliegues empresariales e institucionales). Trabajar de forma estructurada
con datos y apoyarse en la cadena no exige, por tanto, elegir entre estructura y
confidencialidad. Lo que sigue sin resolver no es la confidencialidad (eso es un
problema de diseño ya conocido), sino las tensiones jurídicas de fondo que este
apartado documenta (revisabilidad del acto, garantías procedimentales) y la
madurez de la infraestructura.

**El límite conceptual: identidad soberana no es sinónimo de blockchain.** Suele
vincularse la identidad digital del art. 9 de la Ley 39/2015 al reglamento **eIDAS
2.0** (que, conviene recordar, ya no es futuro: es el **Reglamento (UE) 2024/1183,
vigente desde el 20 de mayo de 2024**, con despliegue de carteras EUDI hasta finales
de 2026) y a "modelos basados en tecnologías de registro distribuido (DLT)". Es una
imprecisión que debilita el argumento: la arquitectura de referencia del **EUDI
Wallet (ARF)** se basa en **credenciales verificables** en formatos como **SD-JWT**
y **mDoc (ISO/IEC 18013-5)**, y está, en palabras de su propia documentación,
**diseñada para operar sin blockchain**, apoyándose en mecanismos criptográficos
para la confianza. La identidad digital soberana es, pues, un objetivo real y en
marcha, pero en gran medida **ajena** a la cadena.

**El límite de madurez: la infraestructura institucional aún es piloto.** Las
redes que se presentan como base, **EBSI** (European Blockchain Services
Infrastructure) e **ISBE** (Infraestructura de Servicios Blockchain de España),
existen y avanzan, pero no son todavía una columna vertebral administrativa en producción:
ISBE presentó su MVP en julio de 2025 con tránsito a producción a partir de 2026, y
EBSI prevé producción hacia finales de 2026. Apoyar hoy un procedimiento crítico
sobre ellas es una apuesta a infraestructura temprana, con riesgo de hoja de ruta
ajena.

**Síntesis del horizonte.** Conviene no confundir "horizonte especulativo" con
"inexistente". El valor a corto plazo defendible de esta tecnología no es la
ejecución automática del acto, sino algo más humilde y sólido: **integridad y
sellado temporal auditables** del expediente (el uso que, por ejemplo, Estonia
hace de una cadena solo para garantizar la inalterabilidad de sus registros, sin
delegar en ella la decisión); y ese uso estrecho **ya ocurre en producción en
España**: la Generalitat Valenciana sella en cadena, a través de su Carpeta
Ciudadana, la evidencia de integridad del ciclo de vida de sus notificaciones
administrativas (alta, puesta a disposición en la Dirección Electrónica
Habilitada Única y aviso al ciudadano), cada hito con su propia marca de tiempo y
su propio sello en cadena. No decide ni ejecuta nada: registra que un evento
ocurrió y cuándo. La frontera no está, pues, entre "blockchain sí, blockchain
no", sino entre **sellar evidencia** (realizable hoy) y **automatizar el acto
administrativo** (horizonte de largo plazo, supeditado a resolver antes las
cinco tensiones anteriores). Por eso este trabajo sitúa la automatización como
visión, no como propuesta: no para descartarla, sino para no confundir una
dirección con una hoja de ruta.

---

## 7. Recomendación de política pública

De todo lo anterior se sigue una recomendación que, coherentemente con el
diagnóstico, no exige reforma constitucional ni nueva ley, y que este trabajo
dirige de forma preferente al ámbito donde el problema es más agudo y la capacidad
de actuación más inmediata: la **administración local**. La propuesta se articula
en dos palancas y se escalona en el tiempo.

**Corto plazo: realizable sin nueva legislación (Pilar 2).** La palanca decisiva
es de producto, no normativa: que los **gestores de expedientes electrónicos** que
los ayuntamientos y diputaciones ya utilizan **emitan, en la propia operación de
generación del documento, una representación en Markdown + YAML** (reutilizando los
datos que ya obran estructurados en el sistema) junto al PDF firmado. No requiere
que ningún empleado público cambie su forma de trabajar ni escriba Markdown a mano;
requiere una opción de salida en un software ya desplegado. Las entidades locales
disponen de dos vehículos propios para exigirlo sin esperar a nadie: los **pliegos
de compra pública** con que licitan o renuevan esos sistemas, donde puede
incorporarse como requisito funcional, y sus **Bases de Ejecución del Presupuesto**
(que cada entidad aprueba anualmente) donde puede fijarse como política de gestión
documental. El *ask* alcanza a todo tipo documental de producción repetitiva
señalado en §2 (RC, certificado de existencia de crédito, oficios, providencias,
informes, resoluciones, notificaciones), no solo a la RC; pero un piloto en una
sola entidad, sobre un tipo documental tan acotado como la RC, bastaría para
demostrar la viabilidad y el coste marginal antes de generalizar.

**Medio plazo: maduración institucional.** En el plano estatal, y como
recomendación complementaria (no principal para el foco local de este trabajo, pero
sí necesaria para consolidar el estándar), procede **incorporar un formato de texto
estructurado ligero (CommonMark) al Catálogo de Estándares del Esquema Nacional de
Interoperabilidad**, competencia de la Agencia Estatal de Administración Digital
(AEAD, antigua Secretaría General de Administración Digital, SGAD, hasta el
Real Decreto 1118/2024). El Catálogo, verificado por lectura directa
(`BOE-A-2012-13501`), no incluye
hoy ningún markup ligero y no se ha revisado desde 2012, es decir, desde antes de la
irrupción de los modelos de lenguaje; su actualización daría cobertura normativa a
la práctica que las entidades locales pueden iniciar ya. A este horizonte pertenece
también la difusión de la práctica más allá de las entidades pioneras y su reflejo
en los estándares de compra pública del sector.

**Largo plazo: fuera del *ask* actual (Pilar 3).** La automatización de
procedimientos mediante *smart contracts* y las arquitecturas de identidad o
registro sobre blockchain quedan expresamente **fuera de esta recomendación**, por
las razones desarrolladas en §6: chocan con la revisabilidad del acto
administrativo y con las garantías procedimentales de la contratación (art. 149
LCSP); la doctrina de protección de datos no las prohíbe, pero exige datos
personales *off-chain* y, preferentemente, redes permisionadas; y se apoyan en
infraestructura aún en fase piloto. Su valor a corto plazo defendible (integridad y
sellado temporal auditables del expediente) no es solo teórico: ya ocurre en
producción en España (la Generalitat Valenciana, ver §6), pero sigue siendo un
complemento, no un sustituto de la decisión administrativa, y no condiciona nada
de lo propuesto a corto y medio plazo. Se remite, pues, a §6 como horizonte de
investigación para la automatización, no como medida.

El orden importa: la secuencia va **de la fábrica del documento hacia arriba**.
Resolver la estructura en el momento de producción (el eslabón más profundo y hoy
desatendido) hace que la mejora se propague sola por toda la cadena posterior
(expediente, publicación, intercambio, consulta), mientras que intervenir solo
aguas abajo dejaría intacto el origen del *dark data*.

---

## 8. Conclusión

La revolución que la Administración pública española necesita para hacer efectiva
su transparencia no requiere, como se ha argumentado, una reforma constitucional ni
siquiera una nueva ley de transparencia: el ordenamiento ya obliga a casi todo lo
que una lectura ambiciosa exigiría. Lo que requiere es un **cambio de arquitectura
documental** que habilite el derecho vigente de forma más eficaz. Ese cambio se
ordena en la jerarquía que ha vertebrado todo el trabajo. En el núcleo, el Pilar 2:
que la información administrativa **nazca estructurada en origen**, en un formato
(Markdown con metadatos) legible a la vez por la persona y por la máquina, en lugar
de aplanarse a un PDF del que luego hay que reconstruirla con pérdida. Como marco,
el Pilar 1: una capa de seguridad y protección de datos (ENS, RGPD/LOPDGDD) que no
es un fin, sino la condición que garantiza que la apertura no se vuelva contra los
derechos del ciudadano. Y como horizonte, no como medida, el Pilar 3: la
automatización mediante blockchain, cuyo atractivo no debe hacer olvidar que choca
hoy con la revisabilidad del acto administrativo y con las garantías de la
contratación; la doctrina de protección de datos no la prohíbe, pero exige datos
personales *off-chain* y redes permisionadas.

El trabajo ha sostenido, además, que la intervención debe ordenarse **de la fábrica
del documento hacia arriba**. El *dark data* administrativo no se origina en el
momento de la publicación, sino en el de la producción, cuando un dato que ya
existía estructurado en el sistema de gestión se aplana a prosa firmada para
revestirse de formalidad. Actuar en ese eslabón (el más profundo y hoy
desatendido, y en la administración local el más numeroso) hace que la mejora se
propague por sí sola a lo largo de toda la cadena posterior. Es una intervención
de coste marginal casi nulo, porque no pide a nadie que trabaje de otro modo, sino
que un software ya desplegado emita también aquello que ya sabe.

Adoptar esta arquitectura permitiría, en definitiva, abandonar una **"transparencia
formal"**, la que se conforma con publicar un PDF, semanas o meses después,
que satisface el requisito legal pero frustra su finalidad, para avanzar hacia una
**"transparencia por diseño"**: aquella en la que la información pública es, desde
el instante en que se produce, trazable, accesible algorítmicamente y auditable.
No se trata de que la tecnología sea el fin, sino de que sea, al fin, el medio para
que el derecho a saber deje de depender de la buena voluntad con que se maquete un
documento.

---

## Apéndices

### Apéndice A: Glosario de siglas

- **ADO**: Autorización, Disposición y reconocimiento de la Obligación (fases del
  gasto acumuladas en un solo documento contable).
- **AEAD**: Agencia Estatal de Administración Digital (sucesora, desde el Real
  Decreto 1118/2024, de la Secretaría General de Administración Digital, SGAD;
  competente sobre el Catálogo de Estándares del ENI).
- **AEAT**: Agencia Estatal de Administración Tributaria.
- **AEPD**: Agencia Española de Protección de Datos.
- **ARF**: *Architecture Reference Framework* (del EUDI Wallet).
- **CSV**: dos acepciones distintas en el texto, desambiguadas por contexto: (1)
  *Código Seguro de Verificación* (mecanismo de cotejo del documento firmado; §4.4 y
  el metadato `csv` de §5); (2) *Comma-Separated Values* (formato de datos
  tabulares, RFC 4180, en el Catálogo de Estándares del ENI; §4.3 y §4.5).
- **DLT**: *Distributed Ledger Technology* (tecnología de registro distribuido).
- **EBSI**: *European Blockchain Services Infrastructure*.
- **EDPB**: *European Data Protection Board* (Comité Europeo de Protección de
  Datos).
- **ELI**: *European Legislation Identifier*.
- **ENI**: Esquema Nacional de Interoperabilidad.
- **ENS**: Esquema Nacional de Seguridad.
- **EUDI (Wallet)**: *European Digital Identity Wallet* (cartera de identidad
  digital europea).
- **ISBE**: Infraestructura de Servicios Blockchain de España.
- **LCSP**: Ley de Contratos del Sector Público (Ley 9/2017).
- **LOD**: *Linked Open Data* (datos abiertos enlazados).
- **LOPDGDD**: Ley Orgánica de Protección de Datos Personales y garantía de los
  derechos digitales (LO 3/2018).
- **LPAC**: Ley del Procedimiento Administrativo Común (Ley 39/2015).
- **LRJSP**: Ley de Régimen Jurídico del Sector Público (Ley 40/2015).
- **mDoc**: *mobile document* (formato de credencial, ISO/IEC 18013-5).
- **NTI**: Norma(s) Técnica(s) de Interoperabilidad (desarrollo del ENI).
- **NTI-RISP**: NTI de Reutilización de recursos de la información del sector
  público.
- **OCDS**: *Open Contracting Data Standard*.
- **PID**: *(en este trabajo)* Plataforma de Intermediación de Datos. *(No
  confundir con «PID» = Personal Identification Data en el ecosistema EUDI.)*
- **PLACSP**: Plataforma de Contratación del Sector Público.
- **RC**: Retención de Crédito (documento contable preventivo).
- **RGPD**: Reglamento General de Protección de Datos (Reglamento (UE) 2016/679).
- **SCSP**: Sustitución de Certificados en Soporte Papel (marco de servicios de la
  PID).
- **SD-JWT**: *Selective Disclosure JSON Web Token* (formato de credencial).
- **TED**: *Tenders Electronic Daily* (suplemento del DOUE para contratación).
- **TGSS**: Tesorería General de la Seguridad Social.
- **TRLRHL**: Texto Refundido de la Ley Reguladora de las Haciendas Locales (RDLeg
  2/2004).

### Apéndice B: Normas citadas y su identificador

Recopilación de las citas del cuerpo, con su identificador verificado contra
fuente primaria (BOE, EUR-Lex) al cierre de este trabajo.

| Norma | Identificador |
|---|---|
| Ley 19/2013, de 9 de diciembre, de transparencia | `BOE-A-2013-12887` |
| Ley 39/2015, de 1 de octubre (LPAC) | `BOE-A-2015-10565` |
| Ley 40/2015, de 1 de octubre (LRJSP); ENI en art. 156 | `BOE-A-2015-10566` |
| Ley 9/2017, de 8 de noviembre (LCSP); art. 149 | `BOE-A-2017-12902` |
| RDLeg 2/2004, de 5 de marzo (TRLRHL); arts. 183-189 | `BOE-A-2004-4214` |
| RD 500/1990, de 20 de abril (ejecución presupuestaria; art. 32.2) | `BOE-A-1990-9664` |
| RD 311/2022, de 3 de mayo (ENS) | `BOE-A-2022-7191` |
| LO 3/2018, de 5 de diciembre (LOPDGDD) | `BOE-A-2018-16673` |
| RD 4/2010, de 8 de enero (ENI) | `BOE-A-2010-1331` |
| NTI Documento Electrónico, Res. 19-jul-2011 | `BOE-A-2011-13169` |
| NTI Expediente Electrónico, Res. 19-jul-2011 | `BOE-A-2011-13170` |
| NTI Catálogo de Estándares, Res. 3-oct-2012 | `BOE-A-2012-13501` |
| NTI-RISP, Res. 19-feb-2013 | `BOE-A-2013-2380` (corr. `BOE-A-2013-5858`) |
| RGPD; Reglamento (UE) 2016/679, de 27 de abril de 2016; arts. 5.1.c, 17, 25 | CELEX `32016R0679` |
| eIDAS 2.0; Reglamento (UE) 2024/1183, de 11 de abril de 2024 (en vigor 20-may-2024; modifica Reg. 910/2014) | CELEX `32024R1183` |
| Akoma Ntoso, OASIS LegalDocML v1.0 (2018) | Estándar OASIS (no norma BOE/UE) |
| ELI, *European Legislation Identifier* | Conclusiones del Consejo UE (no norma BOE) |

### Apéndice C: Nota metodológica

A lo largo del documento se ha aplicado una convención de trazabilidad de las
afirmaciones. Las citas normativas y los datos fácticos se contrastaron contra
fuente primaria (BOE, EUR-Lex, `administracionelectronica.gob.es`, documentación
técnica oficial de las iniciativas citadas) mediante consulta directa, y se
acompañan de su identificador. Las afirmaciones que no pudieron verificarse a ese
nivel de detalle (por ejemplo, la versión exacta de ciertos estándares extranjeros
como CLML o Formex, o el esquema interno concreto de los gestores de expedientes
municipales) se han redactado en condicional o marcado explícitamente como
razonablemente fundadas pero no verificadas al detalle, en lugar de presentarse
como hechos. Y las propuestas que dependen de condiciones jurídicas o técnicas aún
no cumplidas, señaladamente el Pilar 3, se han rotulado como horizonte especulativo,
deliberadamente separadas del cuerpo de la argumentación con certeza. Esta
convención no es un adorno: es la aplicación, al propio texto, del principio de
auditabilidad que el trabajo reclama para la Administración.