De un PDF del BOE a un asistente laboral más fiable

Resumen

Esta nota documenta la conversión de un convenio colectivo publicado en el Boletín Oficial del Estado en una fuente de conocimiento preparada para asistentes de inteligencia artificial.

El proceso incluyó la auditoría de las fuentes oficiales, la detección de pérdidas silenciosas durante la conversión, la reconstrucción de contenido tabular que únicamente existía como imagen, la preservación de los artefactos defectuosos y la ejecución de una misma batería de preguntas antes y después de corregir el corpus.

La auditoría mostró que una conversión aparentemente correcta —con un 99,9 % de cobertura textual y una primera validación satisfactoria— podía ocultar fallos relevantes. Treinta tablas salariales habían perdido sus títulos y nueve matrices de carreras profesionales no estaban disponibles como texto en ninguna de las fuentes oficiales utilizadas.

Para medir el efecto de estos fallos se diseñó una batería acotada de catorce preguntas salariales. Sobre el corpus original, el resultado fue de 11 respuestas correctas, 2 respuestas prudentes o incompletas y 1 respuesta incorrecta. Tras recuperar los títulos de las tablas, reconstruir el Anexo II y normalizar la estructura documental, la misma batería obtuvo 14 respuestas correctas.

El único error grave de la línea base consistió en atribuir a un concepto salarial una cifra real perteneciente a otra tabla. La respuesta era plausible y fue presentada con seguridad, lo que muestra que los errores más peligrosos no siempre proceden de datos inventados, sino también de relaciones documentales perdidas durante la ingesta.

El resultado no demuestra la fiabilidad general del asistente ante cualquier consulta laboral. Demuestra una mejora medible dentro del conjunto de preguntas evaluado y propone un procedimiento reproducible para auditar, corregir y comparar corpus normativos destinados a sistemas de IA.

01Objetivo

El objetivo del proyecto es convertir documentación legal-laboral oficial —el II Convenio Colectivo del Grupo AENA— en un corpus estructurado, íntegro y preparado para ser consultado por asistentes de inteligencia artificial.

El asistente construido sobre ese corpus debe poder responder consultas sobre jornada, permisos, salarios, complementos y promoción, con una obligación fija: citar el artículo, la disposición o el anexo que sostiene cada respuesta.

El objetivo no termina en que el asistente responda. Es necesario poder demostrar mediante evidencia qué alcance ha sido validado y cuál queda fuera de la evaluación.

02Problema abordado

La auditoría de la conversión identificó tres fallos:

1. Pérdida de treinta títulos <caption>. Treinta tablas salariales perdieron su título durante la conversión. Las cifras se conservaron; la identificación del concepto al que pertenecía cada tabla, no.
2. Nueve matrices del Anexo II existentes solo como imagen. Las matrices de carreras profesionales no estaban disponibles como texto en ninguna de las fuentes oficiales utilizadas.
3. Una batería inicial de cinco preguntas con un punto ciego. La primera validación no contenía preguntas capaces de detectar tablas salariales sin título, por lo que dio un resultado satisfactorio sobre un corpus defectuoso.

03Materiales y entornos

Materiales

Corpus final

Entornos y modelos

Las dos líneas no se presentan como una comparación de rendimiento ni como un ranking. NotebookLM fue la interfaz de consulta y el banco de pruebas del asistente; Antigravity fue el entorno utilizado en la línea Google; Claude Code se utilizó para la auditoría, los scripts, la reconstrucción y el QA.

04Proceso metodológico

El trabajo siguió esta secuencia:

1. fuente oficial
2. auditoría
3. detección de pérdidas
4. hipótesis previa
5. línea base
6. preservación de evidencia
7. corrección
8. repetición de la prueba
9. comparación
10. límites documentados

Una decisión estructura todo el proceso: antes de regenerar el corpus, la versión defectuosa se preservó intacta. Corregir sin conservar el original habría hecho imposible demostrar qué fallaba y medir el efecto real de la corrección.

05Línea base

La línea base se midió con una batería de catorce preguntas salariales. Las respuestas de referencia se fijaron directamente desde el XML oficial, antes de ejecutar ninguna consulta.

La hipótesis se escribió antes de ejecutar la prueba, y todos los resultados —antes y después de la corrección— se clasificaron con la misma taxonomía:

• ✅ Correcta — cifra y concepto correctos;
• ⚠️ Prudente o incompleta — reconoce una limitación o evita inventar;
• ❌ Incorrecta — cifra equivocada o mal atribuida.

06Curación y reconstrucción

La corrección del corpus combinó estas medidas:

• preservación de cada versión mediante sufijos, con hashes MD5 registrados;
• reescritura de convertir_boe.py;
• recuperación de los treinta títulos perdidos y de una nota normativa;
• comprobación de superconjunto estricto: el corpus corregido debía contener todo el texto del original;
• reconstrucción de las nueve matrices del Anexo II;
• dieciséis aserciones sobre la estructura final.

Para las matrices del Anexo II se probó primero OCR y se descartó.

La alternativa aplicada fue una reconstrucción sin OCR:

• clasificación de píxeles de las imágenes oficiales;
• veintisiete clusters etiquetados;
• reglas verificadas sobre recortes ampliados;
• recuentos por valor para contrastar cada matriz.

07Evaluación posterior

La batería se repitió sobre el corpus corregido sin modificar nada del protocolo:

• las preguntas;
• las respuestas de referencia;
• los criterios;
• la taxonomía.

08Resultados y hallazgos

El hallazgo más relevante es la naturaleza del único error grave:

Los 50,00 € existen en el convenio: pertenecen a la tabla de «Segundo idioma». El asistente los atribuyó al incentivo de cumplimiento de jornada del artículo 154. La respuesta era plausible y fue presentada con seguridad.

La línea base dejó además dos aciertos engañosos: las preguntas sobre las pagas extraordinarias de junio y diciembre se respondieron con la cifra correcta a pesar de que las tablas implicadas habían perdido su título. Un corpus defectuoso puede producir respuestas correctas por caminos frágiles, y eso no queda registrado si solo se anota el acierto.

Tras la corrección también se redujo el ruido defensivo: las respuestas prudentes que reconocían limitaciones o evitaban comprometerse dejaron de aparecer cuando el corpus contenía la información completa y correctamente atribuida.

La mejora procede de la curación del corpus, no del diseño del prompt. Ningún ajuste de instrucciones puede recuperar un título que no está en los datos: son problemas de capas distintas.

09Trazabilidad y explicabilidad

Nada que documente un error, una hipótesis o una decisión se elimina sin dejar constancia.

En este proyecto no se utilizó Git, por decisión del propietario. Esa elección no se presenta como recomendación general.

En su lugar, la trazabilidad se sostuvo con:

• versiones preservadas con sufijos;
• hashes de verificación;
• notas fechadas;
• respuestas literales conservadas;
• comparaciones con diff.

Se conservaron también los errores del propio auditor, y las interpretaciones se añadieron encima de la evidencia, sin sobrescribirla.

10Herramientas y reproducibilidad

El pipeline documental se compone de cuatro scripts:

• convertir_boe.py — conversión del XML oficial a Markdown y TXT;
• generar_tablas_anexo_ii.py — generación de las tablas reconstruidas del Anexo II;
• png_puro.py — clasificación de píxeles de las imágenes oficiales;
• extraer_anexo_ii.py — extracción del contenido del Anexo II.

Ejecución de referencia:

python3 scripts/generar_tablas_anexo_ii.py \
    data/anexo_II_tablas.md

python3 scripts/convertir_boe.py \
    data/BOE-A-2025-15819.xml \
    --md data/BOE-A-2025-15819.md \
    --txt data/BOE-A-2025-15819.txt

El pipeline utiliza únicamente la librería estándar de Python, sin dependencias externas.

11Lecciones transferibles

1. Validar las tablas explícitamente. Una batería que no pregunta por las tablas no las está validando.
2. Tratar los metadatos como contenido. Un título perdido es información perdida, aunque las cifras sigan ahí.
3. Medir antes de corregir. Sin línea base no hay forma de demostrar el efecto de una corrección.
4. Proteger la evidencia defectuosa. El corpus con fallos es parte del experimento, no un residuo.
5. Escribir la hipótesis antes del experimento. Evita ajustar la expectativa al resultado.
6. Clasificar los fallos por riesgo. Una respuesta prudente y una cifra mal atribuida no pesan lo mismo.
7. No sustituir ingeniería de datos por prompting. Lo que falta en el corpus no se recupera con instrucciones.
8. Congelar corpus, hash, prompt, modelo y fecha. Sin esa foto fija, la comparación antes/después no es reproducible.

12Limitaciones y trabajo futuro

Limitaciones registradas:

• n = 14: la batería es deliberadamente acotada;
• un solo evaluador y ausencia de evaluación ciega;
• los modelos y las plataformas cambiarán con el tiempo; los resultados están ligados a las versiones utilizadas;
• algunas cuantías podrían ser provisionales;
• no existe vigilancia automatizada del BOE ante nuevas publicaciones;
• el piloto con trabajadores está en curso;
• la trazabilidad local sin Git tiene limitaciones propias.

Las interfaces de consulta se plantean como evolución prevista, no como desarrollos completados:

13Conclusión

Convertir un PDF en texto no equivale a construir una fuente de conocimiento fiable.

En este piloto, una conversión con un 99,9 % de cobertura textual escondía treinta tablas sin título y nueve matrices ausentes, y bastó para que un asistente atribuyera con seguridad una cifra real al concepto equivocado.

Tras la auditoría, la curación y la doble evaluación, el corpus dejó de ser un archivo convertido y pasó a ser un artefacto evaluado: con línea base, evidencia preservada, correcciones verificadas y límites documentados.

La mejora medida vale dentro de su alcance: la batería acotada de catorce preguntas salariales. Fuera de ese conjunto, lo que queda no es una garantía, sino un procedimiento que puede repetirse.