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 (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 (los documentos con los que licitan o renuevan esos sistemas); a medio plazo, y como complemento estatal, incorporar CommonMark (una especificación abierta y precisa de Markdown, la variante recomendable para un estándar administrativo) al Catálogo de Estándares del Esquema Nacional de Interoperabilidad, competencia de la AEAD (la Agencia Estatal de Administración Digital, sucesora de la antigua SGAD, el organismo del Estado que mantiene ese Catálogo), 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.
El núcleo de la propuesta es el segundo vector: la adopción de un formato de origen estructurado (Núcleo: Markdown), que es donde se concentra el desarrollo y la recomendación realizable.
En torno a él, el marco: la infraestructura de confianza (Marco de confianza), 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 mediante blockchain (Horizonte: blockchain), examinada no como propuesta operativa sino como dirección de futuro cuyas condiciones de viabilidad aún no se cumplen.
El trabajo acota además su alcance territorial a la administración local (ayuntamientos y diputaciones), por dos razones. Primera, es donde el diagnóstico localiza el foso más profundo del problema (Diagnóstico y Caso ilustrativo). 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 (Recomendación).
Por último, una advertencia de método: 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 o pendiente de verificación de detalle, que se marca como tal (Apéndice C).
2. Diagnóstico: el desfase no es de leyes, es de arquitectura documental
El ordenamiento ya obliga a casi todo lo que una lectura ambiciosa de la transparencia exigiría: la Ley 19/2013 impone la publicidad activa; la Ley 39/2015 consagra el procedimiento electrónico; la Ley 40/2015 ancla en su artículo 156 el Esquema Nacional de Interoperabilidad. El mandato 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. El resultado es una transparencia formalmente cumplida y materialmente opaca: la información está publicada, pero no es procesable a un coste razonable, lo que la literatura llama dark data (datos oscuros).
Conviene calibrar el diagnóstico con honestidad: el grado de oscuridad no es uniforme. Hay que distinguir tres capas, en orden de profundidad creciente.
Lo que se publica bien: El BOE ya es reutilizable.
Lo que se publica mal: Los pliegos, como PDF para imprimir.
Lo que ni se ve: Cómo se fabrica el documento por dentro. Aquí nace el problema.
El Boletín Oficial del Estado no es hoy el mejor ejemplo de dark data: además del PDF firmado, ofrece una API REST de datos abiertos y legislación consolidada en PDF, XML y HTML. La contratación pública, en cambio, es un foso real: los pliegos se publican abrumadoramente como PDF orientado a impresión.
Pero incluso los pliegos son ya un output publicado. Bajo ellos existe la capa más profunda: la producción interna del acto administrativo, es decir, la retención de crédito, el certificado de existencia de crédito, los oficios, las providencias, los informes, que nace de un modo revelador: plantillas de Word recicladas de expediente en expediente, que se aplanan a un PDF firmado, aunque en el sistema de gestión que las produjo esos datos existieran perfectamente estructurados.
Este es el hallazgo central: el dark data no se origina al publicar, sino al producir. El acto que confiere al documento su mayor valor jurídico-probatorio (aplanarlo a PDF/A y firmarlo) es exactamente el que destruye su valor informático. No se necesita una reforma constitucional ni una nueva ley: se necesita intervenir en la arquitectura de la fábrica documental.
3. Marco de confianza: seguridad y protección de datos
Cualquier propuesta de apertura documental debe apoyarse en una capa de confianza previa. El primer pilar es el Esquema Nacional de Seguridad (ENS), regulado por el Real Decreto 311/2022, que obliga a garantizar cinco dimensiones de seguridad de la información: confidencialidad, integridad, trazabilidad, autenticidad y disponibilidad.
Ya existe un marco de seguridad obligatorio
La autenticidad y la integridad 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: derivada en fuerza probatoria, no en orden de generación, ya que ambas nacen del mismo dato estructurado (Objeciones y límites). El segundo pilar es la protección de datos (RGPD y LOPDGDD 3/2018): el principio de minimización es el que, más adelante, impone los límites más duros al horizonte de blockchain (Horizonte: blockchain): los datos personales no deben inscribirse en la cadena, preferentemente sobre redes permisionadas.
4. Núcleo: Markdown como formato de origen
La tesis: adoptar Markdown, con metadatos en YAML, como formato de creación de la documentación administrativa, no como mero formato de publicación añadido.
4.1 El problema del formato
Los formatos hoy dominantes (PDF, DOCX, hojas de cálculo) fueron diseñados para la fidelidad visual, no para la extracción semántica. Para un modelo de lenguaje, un PDF es un contenedor de posiciones gráficas que hay que reconstruir mediante procesos costosos y falibles.
| Aspecto | PDF / DOCX | Markdown + YAML |
|---|---|---|
| ¿Se puede sacar el texto sin errores? | Hay que adivinarlo, con fallos que pasan desapercibidos. | El texto ya está: es la propia estructura. |
| ¿La máquina entiende la estructura? | Implícita: hay que reconstruirla. | Explícita, en el propio texto. |
| ¿Se puede consultar y auditar? | Caro y opaco. | Directo y trazable. |
4.2 La propuesta
Markdown opera en la capa opuesta: texto plano que codifica la estructura lógica del contenido, con sintaxis mínima y sin peso de etiquetado. Acompañado de metadatos YAML, ofrece a un LLM, incluido uno local, una entrada directa y de máxima densidad informativa por token. El objetivo es habilitar la transparencia semántica: que un ciudadano pueda preguntar a una ley o a un pliego y obtener una respuesta fiel.
4.3 Estado del arte, y el argumento-bisagra
España dispone desde hace más de una década de un marco de interoperabilidad: el Esquema Nacional de Interoperabilidad (ENI), RD 4/2010, desarrollado por Normas Técnicas de Interoperabilidad (NTI) de 2011-2013. Un lector experto objetará que la interoperabilidad documental ya está normada. La respuesta es que el ENI resuelve una capa distinta de la que aquí se propone intervenir.
El envío entre administraciones ya funciona
▓▓▓▓▓ ▓▓▓ ▓▓▓▓▓▓▓▓
▓▓▓ ▓▓▓▓▓▓▓ ▓▓▓▓
pero lo que va dentro es un PDF que las máquinas no saben leer
La solución: que ese contenido nazca en Markdown
# Retención de crédito
El ENI resuelve la interoperabilidad sintáctica y de intercambio: un «sobre» XML (estructura, índice, firma, metadatos) para que una Administración remita un expediente a otra.
Pero el contenido real del documento viaja dentro de ese sobre como un fichero adjunto, y ese fichero es, de manera abrumadora, un PDF. El Catálogo de Estándares (`BOE-A-2012-13501`) admite PDF, PDF/A, ODF, OOXML, HTML, MHTML, RTF, CSV y SVG, pero Markdown/CommonMark no figura, y el ENI, a diferencia de su hermano el ENS, nunca ha sido refundido: sigue congelado en 2010-2013, anterior a la irrupción de los grandes modelos de lenguaje.
Fuera de España existen estándares más ricos para representaciones jurídicas: Akoma Ntoso (OASIS LegalDocML, 2018) y el European Legislation Identifier (ELI). Frente a ellos, la posición honesta de Markdown no es la de sustituto sino la de complemento en otra capa: más ligero y accesible, pero semánticamente más pobre (Objeciones y límites).
4.4 Objeciones y límites
Dos objeciones de mayor calado. La de autenticidad jurídica: hoy la versión que hace fe es el documento firmado con su Código Seguro de Verificación (CSV). La vía prudente es Markdown como representación derivada, publicada junto a la versión auténtica, no en su lugar. La de pobreza semántica: Markdown no captura nativamente la estructura jurídica fina que un XML como Akoma Ntoso sí modela.
4.5 La palanca real de adopción
El obstáculo no es técnico sino de gobernanza. La palanca normativa correcta es el propio ENI y su Catálogo de Estándares. Pero pedir que los funcionarios escriban Markdown a mano sería irreal. El segundo ask se dirige al motor de plantillas, 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 para convertirse en una feature de producto, de coste marginal casi nulo.
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: la retención de crédito (RC) de un ayuntamiento, regulada en los arts. 183-189 del RDLeg 2/2004 (TRLRHL) y el RD 500/1990.
El documento y las cifras que siguen son un ejemplo hipotético construido para mostrar la estructura, no un documento real.
Fuente
---
importe_euros: 12450.00
aplicacion_presupuestaria: "920.22000"
expediente: "2026/CONTR/045"
tercero: null
---
Render
Retención de crédito
Existiendo crédito adecuado y suficiente en la aplicación 920.22000, por importe de 12.450,00 €, se retiene dicho crédito.
Conviene subrayar un detalle: 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, mientras que en el PDF esa ausencia es simplemente silencio.
“¿Cuánto crédito reservó el ayuntamiento en 2026 en la aplicación 920.22000?”
Suma exacta de todas las retenciones de crédito del ejercicio en esa aplicación.
Determinista, auditable
Extraer cada cifra de la prosa de cientos o miles de documentos: un error de parsing(“12.450” leído como “124.500”) contamina el resultado en silencio.
Costoso, falible
Los límites del ejemplo. Este caso descansa sobre una premisa razonablemente fundada pero no verificada al detalle: que el gestor de expedientes ya dispone de esos datos estructurados. El ejemplo no depende de ella para su valor demostrativo: muestra qué se gana con la estructura; la premisa solo condiciona lo barato que resulta obtenerla.
6. Horizonte especulativo: blockchain
Sección deliberadamente prospectiva, separada del cuerpo con certeza del trabajo. No hay propuesta operativa lista: hay una dirección de futuro cuyas condiciones de viabilidad aún no se cumplen.
El tercer vector, convertir las condiciones legales en código ejecutable bajo el lema «el código es ley», es el más ambicioso. El «código es ley» solo es admisible supeditado al «cumplimiento es ley»: el derecho administrativo español desactiva buena parte de la promesa de automatización tal como suele formularse.
Sellar que algo pasó y cuándo
Ya funciona hoy: la Generalitat Valenciana sella así sus notificaciones.
Que la máquina decida por sí sola
Horizonte lejano, aún no viable.
- Jurídico: Recursos, nulidad y silencio administrativo no tienen equivalente en un contrato que se ejecuta de forma inexorable.
- Procedimental: La exclusión automática de ofertas por oráculo elude la audiencia obligatoria al licitador (art. 149 LCSP).
- Protección de datos: AEPD y EDPB no lo prohíben, fijan cómo: datos personales fuera de la cadena, solo pruebas dentro, redes permisionadas preferidas.
- Conceptual: El EUDI Wallet usa credenciales SD-JWT y mDoc, diseñado para operar sin cadena de bloques.
- Madurez: Infraestructura institucional (EBSI, ISBE) todavía en fase piloto, no en producción.
Síntesis del horizonte. El valor a corto plazo defendible de esta tecnología no es la ejecución automática del acto, sino algo más humilde: integridad y sellado temporal auditables del expediente: eso ya ocurre en producción en España, no solo en teoría; la Generalitat Valenciana sella en cadena la evidencia de integridad de sus notificaciones administrativas, sin decidir ni ejecutar nada. La frontera está entre sellar evidencia (realizable hoy) y automatizar el acto (horizonte de largo plazo). Este trabajo sitúa la automatización blockchain 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 no exige reforma constitucional ni nueva ley, dirigida de forma preferente a la administración local.
Se articula en dos palancas y se escalona en el tiempo: a corto plazo, que los gestores de expedientes emitan Markdown + YAML junto al PDF firmado, exigible vía pliegos y Bases de Ejecución; a medio plazo, incorporar CommonMark al Catálogo de Estándares del ENI, competencia de la AEAD (antigua SGAD); a largo plazo, y fuera del ask actual, la automatización mediante blockchain (Horizonte: blockchain). El orden importa: la secuencia va de la fábrica del documento hacia arriba.
El diagrama completo de la recomendación, con sus tres horizontes temporales, está en la portada («Cómo está organizado» → Fig. 2).
8. Conclusión
La revolución que la Administración pública española necesita no requiere una reforma constitucional: requiere un cambio de arquitectura documental. En el núcleo, que la información nazca estructurada en origen. Como marco, una capa de seguridad y protección de datos que no es un fin, sino la condición que protege al ciudadano. Y como horizonte, no como medida, la automatización mediante blockchain.
La intervención debe ordenarse de la fábrica del documento hacia arriba: actuar en el eslabón más profundo hace que la mejora se propague sola por toda la cadena posterior, con coste marginal casi nulo.
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
Material de referencia que acompaña al cuerpo del trabajo, cada uno en su propia página.