Cómo uso la IA para resumir boletines oficiales
Un día normal, el BOE publica entre 50 y 100 entradas. El BDNS añade entre 100 y 300 convocatorias de subvenciones. Los boletines autonómicos contribuyen varias decenas más. En total, entre 200 y 500 entradas diarias de texto legal-administrativo que ningún ser humano tiene tiempo ni ganas de leer.
En Boletín Claro, uso LLMs para convertir ese volumen de información en resúmenes concisos que un autónomo o una pyme puede leer en 3 minutos con su café de la mañana. El reto no es "resumir texto con IA" (eso es trivial). El reto es hacerlo a escala, con coste controlado y con la calidad suficiente para que un usuario confíe en el resumen sin necesitar leer el original.
El problema de la escala
Resumir 300 entradas con un LLM es caro si lo haces de forma ingenua. Supongamos que cada entrada tiene una media de 2.000 tokens. Son 600.000 tokens de entrada al día. Con GPT-4o a $2.50 por millón de tokens de input, serían $1.50/día solo en input. Parece poco, pero hay que sumar los tokens de output, el hecho de que algunos textos son mucho más largos, y que esto se multiplica por cada alerta de cada usuario.
Si tengo 100 usuarios con 3 alertas cada uno y proceso las 300 entradas para cada alerta, estamos hablando de 90.000 llamadas al LLM al día. Obviamente, eso no escala.
Filtrar antes de resumir
La solución es un pipeline de dos fases: filtrado y resumen. El filtrado descarta el 85-95% de las entradas antes de que toquen el LLM.
Fase 1: Filtrado por relevancia
Cada usuario tiene alertas configuradas con una descripción en lenguaje natural, como "subvenciones para empresas tecnológicas en Madrid" o "licitaciones de servicios de limpieza en edificios públicos". El filtrado funciona en tres capas:
- Filtro por fuente: si la alerta solo monitoriza BOE y BDNS, descartamos directamente los boletines autonómicos. Esto es trivial pero elimina mucho volumen.
- Filtro por sección: las entradas del BOE están clasificadas en secciones (I. Disposiciones generales, II. Autoridades y personal, III. Otras disposiciones, etc.). Si una alerta busca subvenciones, solo nos interesan las secciones III y V.
- Filtro semántico: usamos embeddings para calcular la similaridad entre la descripción de la alerta y cada entrada. Solo pasan al LLM las entradas con una similaridad por encima de un umbral. Este umbral lo calibré empíricamente: 0.35 para recall alto (pocas entradas perdidas) pero suficiente para descartar lo claramente irrelevante.
El resultado: de 300 entradas diarias, una alerta típica pasa 10-30 al LLM. El coste se reduce un orden de magnitud.
Fase 2: Resumen con LLM
Las entradas que pasan el filtro se envían al LLM para generar un resumen. Aquí es donde el prompt engineering marca la diferencia.
Prompt engineering para texto legal
El texto administrativo español tiene características específicas que hacen que un prompt genérico funcione mal:
- Frases de 200 palabras: el lenguaje jurídico español usa subordinadas encadenadas hasta el infinito. El LLM necesita instrucciones explícitas de simplificar la estructura sintáctica.
- Información clave enterrada: el presupuesto, el plazo de solicitud y los beneficiarios suelen estar en el tercer párrafo, no en el primero. El prompt debe especificar qué extraer.
- Nombres de organismos: "Dirección General de Industria, Energía y Minas de la Consejería de Economía, Hacienda y Empleo" es un nombre real de organismo. El resumen debe abreviarlo sin perder la referencia.
- Fechas y plazos: aparecen en formato "veinte días hábiles a contar desde el siguiente al de la publicación del extracto en el BOE". El resumen debe convertirlo a una fecha concreta.
El prompt que uso sigue esta estructura:
Eres un analista de boletines oficiales españoles.
Genera un resumen conciso de la siguiente entrada.
REGLAS:
- Máximo 3 frases
- Incluye SIEMPRE: quién convoca, qué se ofrece, a quién va dirigido
- Si hay presupuesto, inclúyelo con cifras
- Si hay plazo, calcula la fecha límite a partir de la fecha de publicación
- Simplifica nombres de organismos (ej: "Consejería de Economía" en vez del nombre completo)
- NO uses lenguaje jurídico: escribe para un empresario, no para un abogado
- Idioma: español
FECHA DE PUBLICACIÓN: {date}
FUENTE: {source}
ENTRADA:
{content}He iterado este prompt docenas de veces. Los ajustes más impactantes fueron: pedir explícitamente que calcule la fecha límite (antes daba el plazo en días hábiles, que es inútil para el usuario) y pedir que simplifique los nombres de organismos.
Coste real
Con el sistema de filtrado, los costes reales son mucho más razonables de lo que parece:
| Concepto | Volumen diario | Coste estimado |
|---|---|---|
| Embeddings (filtrado) | ~300 entradas | $0.01 |
| Resúmenes LLM (por alerta) | ~15 entradas | $0.02 |
| Total por alerta/día | - | ~$0.03 |
Con 100 alertas activas, el coste de IA es de unos $3/día o $90/mes. Viable como coste de un SaaS con suscripción mensual.
Entrega por email
Una vez generados los resúmenes, se agrupan por alerta y se envían por email. El email es HTML con un diseño minimalista: cada resumen es un bloque con título, resumen de 2-3 líneas y un enlace a la fuente original.
La decisión de enviar por email (y no push notifications ni un feed in-app) fue deliberada. El público objetivo son pymes y autónomos que ya tienen el email como herramienta de trabajo. No necesitan instalar otra app ni acordarse de visitar otro dashboard. El email llega, se lee, se archiva o se actúa. Sin fricción.
El envío se hace con Amazon SES. Cada email se personaliza por alerta: si un usuario tiene una alerta de "subvenciones de digitalización" y otra de "licitaciones de consultoría", recibe dos emails separados. Probé agrupar todo en uno y los usuarios preferían la separación por tema.
Calidad y alucinaciones
La gran pregunta con cualquier sistema de IA generativa: ¿se inventa cosas? En el contexto de boletines oficiales, una alucinación no es solo molesta, es potencialmente dañina. Si el resumen dice que el plazo acaba el 15 de abril y en realidad acaba el 5, el usuario puede perder una subvención.
Mi estrategia para mitigar esto:
- Citar siempre la fuente: cada resumen enlaza al texto original en el boletín. El resumen no pretende sustituir al original, sino señalar qué es relevante.
- Formato extractivo sobre generativo: el prompt pide que extraiga información existente, no que genere interpretaciones. "Subvención de 500.000 euros para digitalización de pymes en Andalucía, plazo hasta el 30 de abril" es más seguro que "Esta interesante oportunidad permitirá a las pymes andaluzas dar un salto digital".
- Temperatura baja: uso
temperature=0.1. Para resúmenes factuales, quiero determinismo, no creatividad. - Validación de fechas: un postprocesador comprueba que las fechas mencionadas en el resumen son coherentes con la fecha de publicación. Si el LLM dice que el plazo acaba en una fecha anterior a la publicación, se marca el resumen para revisión.
Lo que he aprendido
Después de meses procesando boletines con IA, mis conclusiones principales son:
Primero, el LLM es la parte fácil. El 80% del trabajo está en el pipeline anterior: extraer el texto limpio, filtrar lo relevante, estructurar el contexto. Si le das basura al LLM, te devuelve basura resumida.
Segundo, los costes de IA son gestionables si filtras bien. La mayoría de artículos sobre "costes prohibitivos de la IA" asumen que se procesan todos los datos con el modelo más caro. En la práctica, con un buen pipeline de filtrado, los costes son una fracción del hosting.
Tercero, los usuarios valoran más la cobertura que la perfección. Preferirían recibir un resumen "suficientemente bueno" de todo lo relevante antes que un resumen perfecto de solo el 50% de las publicaciones.
Si quieres probar cómo funciona el producto, puedes visitar la página de alertas con IA para ver ejemplos reales de resúmenes generados. Y si estás construyendo algo similar con LLMs sobre datos públicos, me encantaría intercambiar notas: me encuentras en LinkedIn.