--- title: "público.md" description: "Los actos administrativos españoles nacen aplanados en PDF y mueren como dato. Este paper propone que nazcan estructurados en Markdown, sin nueva legislación." url: "https://publico.md" site: "público.md" author: "Pau March" language: "es" --- # público.md > Los actos administrativos españoles nacen aplanados en PDF y mueren como dato. Este paper propone que nazcan estructurados en Markdown, sin nueva legislación. ## 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". ## Cómo está organizado el sitio - [De la transparencia formal a la transparencia por diseño](https://publico.md/paper.md): El paper completo: una arquitectura documental para que los actos administrativos nazcan estructurados, no aplanados en PDF. 9 secciones, con objeciones y citas. - [Glosario](https://publico.md/glosario.md): Apéndice A: las 45 siglas del paper, con su expansión y su desambiguación por contexto. - [Normas citadas](https://publico.md/normas.md): Apéndice B: las 17 normas citadas en el paper, con su identificador BOE o CELEX y su enlace a fuente primaria. - [Metodología](https://publico.md/metodologia.md): Apéndice C: la convención verificado/especulativo con la que se marca la certeza de cada afirmación, y por qué el alcance del trabajo es local. - [Investigación relacionada](https://publico.md/investigacion.md): Repositorio de 29 fuentes académicas verificadas, organizadas en 4 vías de investigación, cada una con su síntesis comparada. - [Blockchain y registros públicos](https://publico.md/investigacion/blockchain.md): Registro de la propiedad, identidad digital soberana, contratación pública e interoperabilidad. Es la literatura que más directamente pone a prueba el Pilar 3 del paper. - [Smart contracts y automatización de actos administrativos](https://publico.md/investigacion/smart-contracts.md): Ejecución automática de reglas jurídico-administrativas, «rules as code», validación multi-firma. La vía más ligada al ejemplo del secretario-interventor ya construido en la home. - [Modelos de lenguaje en la Administración](https://publico.md/investigacion/llms.md): Procesamiento de documentos administrativos, atención ciudadana, riesgos de alucinación sobre texto jurídico. La vía más ligada al núcleo del paper: Markdown como formato legible por máquina. - [Administración digital: ciudadano, interoperabilidad y trabajador público](https://publico.md/investigacion/administracion-digital.md): Qué significa realmente «ser digital» en tres planos distintos — la relación con el ciudadano, el intercambio entre administraciones, y el día a día de quien tramita por dentro —, siempre desde la óptica de la administración local española que impulsa este proyecto, sin descartar su extrapolación a otras administraciones. - [Posts](https://publico.md/posts.md): Notas de Pau March sobre transparencia, Administración pública y por qué el problema es de diseño, no de leyes. - [El buscador de oposiciones que España se merece (y su API)](https://publico.md/posts/el-buscador-de-oposiciones-que-espana-se-merece.md): El BOE anunció una oposición y apuntó a unas bases que estaban en otro número, casi seis meses después. Hubo que repetir el plazo entero. He escrito la API que lo habría hecho imposible. - [Westworld en la Generalitat Valenciana](https://publico.md/posts/westworld-en-la-generalitat-valenciana.md): Vi la Ciutat de les Arts convertida en ciudad futurista en Westworld. La semana pasada, la Generalitat me hizo sentir que volvía a serlo. - [Seis cifras, tres fechas y una app que no existe](https://publico.md/posts/seis-cifras-tres-fechas-emt-indra.md): La EMT de València pagó nueve millones por una plataforma que no existe. Saber cuánto costó me llevó una investigación; debería haber sido una consulta. - [El síndrome de Kafka, la aceituna de American Airlines y la transparencia en la Administración](https://publico.md/posts/sindrome-de-kafka-aceituna-american-airlines.md): La transparencia no es colgar un PDF en un portal: es que el ciudadano no sufra el funcionamiento interno de la Administración. - [Kit de prensa](https://publico.md/prensa.md): Material de comunicación de público.md: resumen ejecutivo, el ejemplo en lenguaje llano, texto de referencia citable y contacto. ## Preguntas frecuentes ### ¿Este cambio requeriría de nueva legislación? En parte. La palanca de corto plazo (que los gestores de expedientes emitan también Markdown + YAML) se activa hoy con instrumentos que cada entidad ya controla y firma cada año: sus Bases de Ejecución del Presupuesto y sus pliegos de prescripciones técnicas y administrativas, sin necesidad de una ley nueva para empezar. Pero esto no es solo un cambio de formato, es un cambio de modelo en cómo se produce la documentación administrativa; llevarlo más allá del piloto (estandarizarlo, incorporarlo al Catálogo de Estándares del ENI) sí implicaría articulación legislativa e institucional a distintos niveles. A día de hoy el trabajo está en fase de propuesta, no de implementación. Secciones del paper: La palanca de adopción, Recomendación. ### ¿Lo tiene que construir mi ayuntamiento, o lo hace el proveedor del gestor de expedientes? El ask está dirigido al proveedor, no al empleado público, y a más de un tipo de proveedor a la vez: los que ya mantienen los gestores de expedientes de cada entidad, los departamentos de TI de las administraciones superiores (autonómica, ministerial), y en general cualquier proveedor de tecnología que preste servicio a la Administración. Los datos que forman una retención de crédito, una notificación o una resolución ya suelen existir estructurados dentro del gestor; lo que falta es que su motor de plantillas emita también Markdown con metadatos YAML junto al PDF firmado, reutilizando esos mismos datos. No es pedirle a nadie que escriba Markdown a mano, y deliberadamente no es una propuesta que dependa de una gran adjudicación plurianual: cuanto más se parezca a una opción de exportación más en un sistema que ya existe, más se aleja del modelo que hoy encarece y ralentiza la digitalización pública. Secciones del paper: La palanca de adopción. ### Si empezamos con un piloto, ¿por dónde se empieza? Por un solo tipo de documento, no por todo el acto administrativo a la vez. El caso que usa el propio trabajo como ilustración es la retención de crédito municipal: alto volumen, pocos campos, bien acotada jurídicamente. Generalizar a otros actos es un paso posterior, no el punto de partida, y sería un piloto inédito: no se conoce ningún ayuntamiento que ya esté haciendo algo comparable. Secciones del paper: Caso ilustrativo. ### ¿El Markdown tiene el mismo valor jurídico que el PDF firmado? No: el documento que hace fe sigue siendo el PDF firmado electrónicamente. Pero el origen no es al revés de lo que podría parecer: el PDF se construye a partir del Markdown, no el Markdown a partir del PDF. El dato nace estructurado, se valida, y de ahí se generan tanto el Markdown legible por máquina como el PDF que se firma. 'Derivada' se refiere aquí a la fuerza probatoria, es decir que en caso de discrepancia prevalece el PDF firmado, no al orden en que se generan los dos formatos. Secciones del paper: Núcleo: Markdown, Objeciones y límites. ### ¿Esto me obliga a publicar más de lo que ya publico? No. Cambia el formato en el que nace un documento que la ley ya exige producir, no amplía por sí solo qué información debe hacerse pública. La transparencia relevante no es publicar más, es que lo que ya se produce nazca en un formato que se pueda auditar y consultar, no solo leer. Secciones del paper: Diagnóstico. ### ¿Hay algún ayuntamiento que ya lo esté haciendo? No se conoce ningún comparable en marcha a día de hoy. Es una de las limitaciones que el propio trabajo reconoce abiertamente: el aparato es normativo (qué debería pasar) y se apoya en un caso ilustrativo, no en un piloto real medido todavía. Ver la convención de honestidad metodológica para más detalle sobre qué está verificado y qué no. ### ¿Estructurar los documentos expone datos personales que hoy están escondidos dentro del PDF? La protección de datos y la seguridad de la información (ENS, RGPD/LOPDGDD) son una restricción de partida que cualquier propuesta debe respetar, no una casilla aparte. Estructurar un documento no cambia por sí solo qué datos deben ser públicos; sigue rigiendo la misma normativa de protección de datos que ya se aplica hoy al PDF. Secciones del paper: Marco de confianza. ### ¿Cómo se evita que el Markdown se manipule y deje de coincidir con el PDF auténtico? Es un riesgo real, no resuelto todavía como estándar formal. Hay dos caminos posibles: extender a esa referencia cruzada el mismo sistema de sellado y firma que ya protege al PDF hoy (CSV, sello electrónico), sin infraestructura nueva; o sellarla en una cadena de bloques, inmutable y verificable por cualquiera. Nada impide técnicamente empezar a explorar esto último desde el principio, en paralelo al piloto de Markdown, no depende de completar antes las fases de corto o medio plazo — de hecho ya hay un caso real en producción en España con ese mismo patrón (ver la siguiente pregunta). Pero sigue siendo Pilar 3, horizonte especulativo y no la propuesta operativa: no por una limitación técnica, sino porque la AEPD y el Comité Europeo de Protección de Datos exigen mantener los datos personales fuera de la cadena y usar redes permisionadas, y la infraestructura pública europea de referencia relevante sigue en fase piloto. Secciones del paper: Objeciones y límites, Horizonte: blockchain. ### ¿La propuesta implica usar blockchain para todo? No. Blockchain y los smart contracts se tratan de forma explícita como horizonte especulativo, no como propuesta operativa. La recomendación de política pública se sostiene entera sobre Markdown y el marco de seguridad, sin depender de blockchain en ningún punto. Secciones del paper: Horizonte: blockchain. ### Entonces, ¿por qué se habla de ello? Porque marca una dirección de futuro con condiciones que hoy no se cumplen del todo, no porque sea la propuesta — y no porque la tecnología esté vetada. La AEPD y el Comité Europeo de Protección de Datos no prohíben blockchain con datos personales: fijan un protocolo (datos personales fuera de la cadena, solo pruebas criptográficas dentro, redes permisionadas preferidas). Ese patrón exacto ya está en producción en España: la Generalitat Valenciana sella en cadena la integridad de sus notificaciones administrativas, sin decidir ni ejecutar nada. Lo que sigue en fase piloto es la infraestructura pública europea de referencia (EBSI, ISBE); lo que sigue siendo horizonte, no propuesta, es automatizar el acto administrativo en sí. Tratarlo como horizonte para eso último, no como plan, es deliberado. Secciones del paper: Horizonte: blockchain. ### ¿Usar blockchain significa que todo tiene que ser público y auditable por todo el mundo? No. Las redes permisionadas —el modelo que prefieren tanto el regulador como la infraestructura pública europea de referencia (EBSI, ISBE)— permiten un registro compartido con confidencialidad configurable: canales aislados y datos visibles solo para quien está autorizado, no una cadena abierta que cualquiera pueda leer. Trabajar de forma estructurada con datos y apoyarse en blockchain no son alternativas incompatibles; elegir entre estructura y confidencialidad no hace falta. Secciones del paper: Horizonte: blockchain. ### ¿Por qué Markdown y no un estándar más completo como Akoma Ntoso o un XML jurídico? Porque resuelven problemas distintos y no compiten entre sí. Markdown se plantea como una capa de contenido legible de bajo coste, no como un modelo jurídico estructurado completo; estándares como Akoma Ntoso modelan la jerarquía del articulado y el versionado consolidado, algo que Markdown no pretende sustituir. La propuesta es complementaria a lo que ya existe, no una alternativa que lo reemplace. Secciones del paper: Estado del arte.