Saltar al contenido

Contratación pública · Plataforma de análisis con IA

Radar de licitaciones

El radar busca contratos públicos con poca competencia que una empresa pueda cumplir y acreditar de verdad. Propone y prepara, pero nunca firma, presenta ni escribe a un organismo sin que el usuario lo apruebe.

Tipo
Producto propio
Sector
Contratación pública
Solución
Plataforma de análisis con IA
Periodo
Desde octubre de 2026
Estado
MVP En curso, preparación de ofertas en primera versión
Panel «Licitaciones» del radar: contadores de licitaciones a las que presentarse, que cierran esta semana y presupuesto en juego, filtros por tipo de trabajo y tarjetas con encaje, dificultad, órgano, presupuesto y días para el cierre.

Resumen ejecutivo

Radar de licitaciones públicas que lee la Plataforma de Contratación, puntúa cada oportunidad, lee los pliegos con IA citando la página y prepara la oferta.

Encontrar una licitación adecuada exige revisar a diario miles de publicaciones, leer pliegos de decenas de páginas y comprobar si la empresa cumple cada requisito. El radar carga los feeds de la Plataforma de Contratación del Sector Público en formato CODICE, detecta señales de oportunidad, descarta lo que la empresa no puede acreditar y puntúa el resto de 0 a 100. Los pliegos los lee Claude con salida validada por esquema y cada dato lleva su cita literal comprobada en la página. Desde la ficha se preparan la checklist, la declaración responsable y un borrador de memoria técnica que bloquea lo que el perfil no respalda.

El reto

  1. Las licitaciones se publican en feeds ATOM en formato CODICE, repartidos entre la plataforma estatal, las agregadas autonómicas y registros propios como el de Cataluña, y un mismo expediente aparece varias veces con versiones distintas.

  2. Saber si una empresa puede presentarse depende de su objeto social, sus vías de solvencia, sus certificados y el procedimiento, y casi nada de eso viene completo en los datos del feed.

  3. Los requisitos que deciden la oferta están en pliegos en PDF, y una lectura automática que se equivoque o invente un dato lleva a presentar una oferta excluida.

  4. La ley no permite afirmar en una oferta experiencia, medios o certificados que la empresa no pueda acreditar, así que el sistema no puede rellenar huecos por su cuenta.

La solución

Un motor en Python que corre cada hora en un equipo local: ingesta, detección, encaje, puntuación y lectura de pliegos, con todas las reglas de negocio como funciones puras y los umbrales legales en configuración con su fuente. Lo que el usuario necesita ver se sincroniza con una base pequeña en la nube que sirve una web en Next.js, y la web encola trabajos que el equipo local ejecuta.

Funcionalidades

Qué hace, pantalla a pantalla

Radar local con contadores de licitaciones que pasan filtros, descartadas y pendientes, la última ingesta con sus entradas de siete días, y la tabla de nuevas con puntuación, órgano, importe y fecha límite.

01

Ingesta de la Plataforma de Contratación

Parser de los feeds ATOM de CODICE con la estructura real documentada campo a campo, carga idempotente que versiona los cambios y guarda las diferencias, y fuente propia para los contratos menores de Cataluña desde su registro público.

Lista de oportunidades con puntuación, tipo de señal (vencimiento o desierta), título, órgano, municipio e importe, con filtros por tipo y puntuación mínima.

02

Señales, encaje y puntuación

Detecta desiertas, relicitaciones, contratos que vencen y menores repetidos. Un filtro por sociedad aplica las vías de solvencia y avisa de los datos que faltan en vez de descartar, y una puntuación de 0 a 100 guarda de dónde sale cada dimensión.

  • Portada por tipo de trabajo

    Las licitaciones abiertas se agrupan por tipo de trabajo con su dificultad, importe y opciones de ganar, con filtro por zona y un aviso de última llamada para las que cierran entre dos y cinco días.

  • Lectura de pliegos con IA y citas verificadas

    Claude lee el pliego administrativo y el técnico y devuelve un JSON validado contra un esquema. Cada dato lleva documento, página y texto literal, y el sistema comprueba que ese texto aparece en esa página; si no aparece, el dato queda marcado.

  • Requisitos frente al perfil de la empresa

    La ficha lista capacidad, solvencia, certificaciones, inscripciones y garantías con su página, y marca cada requisito como cumple, no cumple o verificar según los documentos del perfil. La página de empresa resume qué falta y a cuántas licitaciones afecta.

  • Precio y baja anormal

    Calcula el umbral de baja anormal del artículo 85 del RGLCAP o el que fije el pliego, aplica su fórmula de puntuación económica y sugiere un precio con las bajas ganadoras del histórico público y las ofertas leídas de las actas.

  • Preparación de la oferta

    Genera la checklist por sobre, la declaración responsable y un borrador de memoria técnica en Word ordenado por los criterios del pliego. Lo que el perfil no respalda queda marcado como FALTA o VERIFICAR y bloquea la carpeta de la oferta.

  • Embudo y alertas

    Cada licitación pasa por un embudo de Nueva, Me interesa y Preparando, con pasos hasta presentar. Las alertas llegan por Telegram con botones para leer el pliego o marcar interés, más resúmenes por n8n y un recordatorio 48 horas antes del cierre.

Módulos

Qué funciona hoy y qué está propuesto

3 operativos, 2 parciales y 1 propuestos. Los propuestos son diseño de producto: todavía no hay software detrás.

  • Ingesta y normalización

    Operativo

    Feeds de PLACSP con 24 meses de histórico, menores de Cataluña, deduplicación por versión y registro de errores de carga.

  • Detección, encaje y puntuación

    Operativo

    Señales de oportunidad, filtro duro por sociedad con vías de solvencia, lotes puntuados por separado y puntuación trazable.

  • Lectura de pliegos con IA

    Parcial

    Funciona con revisión humana por campo en la web. El criterio de calidad de la especificación, menos del 10 % de error en datos críticos sobre 20 pliegos revisados, todavía no se ha medido.

  • Preparación de ofertas

    Parcial

    Primera versión con checklist, declaración responsable, memoria técnica en borrador y validadores que bloquean. El DEUC y el registro de ofertas quedan para la segunda versión.

  • Alertas y web en la nube

    Operativo

    Ciclo horario, cola de trabajos entre web y equipo local, Telegram con botones y flujos de n8n. Los canales de aviso se activan por configuración.

  • Prospección, proveedores y ejecución

    Propuesto

    Seguimiento de organismos objetivo, presupuestos de proveedores para el coste real y seguimiento de contratos adjudicados: definidos en la especificación, sin código todavía.

Cómo funciona

De la publicación a la oferta preparada

  1. Ingesta

    Cada hora se leen las últimas páginas de los feeds y se versiona lo que ha cambiado.

  2. Detección y encaje

    Se calculan señales y se cruza cada licitación con el perfil de cada sociedad activa.

  3. Puntuación

    Cada oportunidad recibe de 0 a 100 con el origen de cada dimensión.

  4. Lectura del pliego

    Las de 60 puntos o más sin lectura vigente se encolan para que la IA lea el pliego.

  5. Revisión y requisitos

    El usuario confirma o corrige cada campo y ve qué requisitos cumple.

  6. Preparación

    Checklist, declaración y memoria en borrador; firmar y presentar son del usuario.

Arquitectura

Cómo está construido

Plano · radar-licitaciones 5 capas · 18 piezas
  1. Clientes

    • Web del radar con login de un usuario
    • Bot de Telegram con botones
    • Panel local en el equipo de trabajo
    • De Clientes a Web y nube: navegador
  2. Web y nube

    • Next.js 16, React 19 y Tailwind 4
    • Esquema nube en PostgreSQL de Supabase
    • Cola de trabajos con latido y reintentos
    • De Motor local a Web y nube: sincronización por upsert
    • De Web y nube a Motor local: cola de trabajos
  3. Motor local

    • Ciclo horario y worker como servicios systemd
    • API FastAPI para el panel local
    • Sincronización idempotente con la nube
    • De Motor local a Reglas de negocio: pipeline cada hora
  4. Reglas de negocio

    • Detección, encaje, puntuación y precio como funciones puras
    • Normativa, empresa, radar y alertas en YAML con fuente y vigencia
    • Validadores que bloquean la oferta
  5. Datos e integraciones

    • PostgreSQL local con unas 270.000 licitaciones
    • Feeds ATOM de PLACSP y registro de contratos de Cataluña
    • Claude con salida validada por JSON Schema
    • PyMuPDF para el texto por página y Word para la memoria
    • Playwright y Lighthouse para auditar la web del organismo
    • n8n y Telegram para los avisos

Otros flujos

  • Datos e integraciones → Motor local : feeds CODICE y pliegos en PDF
  • Motor local → Clientes : alertas por Telegram

Tecnologías

Stack verificado en el código

Interfaz

  • Next.js
  • React
  • TypeScript
  • Tailwind CSS

Backend

  • Python
  • FastAPI
  • Pydantic
  • PyMuPDF

Datos

  • PostgreSQL
  • Supabase

IA y voz

  • Claude (Anthropic)

Automatización y vídeo

  • n8n
  • Playwright

Infraestructura

  • Linux

Integraciones

  • Telegram

Calidad

  • pytest

Ingeniería

Cómo se planteó y se construyó

  1. Radar mínimo (octubre de 2026)

    Primero se inspeccionó un mes completo de datos reales y se documentaron los campos de CODICE antes de modelarlos. Sobre eso se construyeron el parser, la carga idempotente, las señales, el filtro duro, la puntuación, la API y un primer panel, con un backtest del criterio de corte de la fase 1.

  2. Pliegos y web conectada (octubre de 2026)

    Se añadió la lectura de pliegos con citas verificadas, la web en la nube con su cola de trabajos hacia el equipo local, la ficha con revisión humana, el ciclo horario y el embudo. Llegaron también precio por fórmula, rivales probables, contratos que vencen y alertas de Telegram con botones.

  3. Ampliación y rendimiento (noviembre de 2026)

    La línea de informática se amplió a toda España con filtro por zona y un umbral de aviso propio. El filtro del nicho, que se evaluaba con expresiones regulares sobre todas las licitaciones en cada consulta, pasó a calcularse una vez por licitación y guardarse.

  4. Preparación de ofertas (noviembre de 2026)

    Primera versión de la fase 4: checklist por sobre, declaración responsable, validadores que bloquean, pasos hasta presentar en la ficha, memoria técnica en borrador y lista de requisitos del pliego con su estado frente al perfil.

Retos técnicos resueltos

Cargar feeds que repiten el mismo expediente en varios archivos y versiones sin duplicar ni pisar datos más recientes.
Se conserva la versión con la fecha de actualización más reciente, se hace upsert por el identificador de la plataforma con un hash del contenido y solo los cambios en campos vigilados crean una versión nueva con sus diferencias. Una versión más antigua nunca sobrescribe la guardada.
Usar IA para leer pliegos sin aceptar datos que el pliego no dice.
El esquema de extracción es un modelo Pydantic que sirve a la vez de JSON Schema para la IA y de validación de la respuesta. Cada dato lleva su cita y el sistema exige que el literal aparezca en la página indicada; si no, el dato queda sin verificar.
Un cálculo de alertas que tardaba unos nueve minutos porque repetía un filtro por expresión regular sobre todo el histórico en siete consultas.
El filtro se guarda como una marca por licitación y criterio, con el hash de la configuración, y solo se recalcula lo que cambia de título o CPV. Un test comprueba que el resultado es idéntico al del filtro directo.
Servir una web en la nube cuando la base completa ocupa casi 1 GB y vive en un equipo local.
A la nube solo sube lo que la web enseña, por upsert y marcando lo cerrado sin borrarlo. La web encola trabajos que el equipo reclama con for update skip locked, con latido y reintentos, y un índice único impide encolar dos veces el mismo trabajo.

Resultados

Lo que se ha medido

Cada cifra lleva su fuente y su fecha. Lo que no se ha medido va aparte, como potencial.

  • 543 s a 7 s

    tiempo de cálculo de la alerta temprana tras guardar el filtro del nicho por licitación

    docs/decisiones.md, decisión 68, y commit 3b0f862 del repositorio del radar · 2026-11

  • 56 s

    primera lectura real de un pliego de 32 páginas, con criterios que suman 100 y todas las citas verificadas

    docs/decisiones.md, decisión 33 (primera prueba real con PCAP y PPT) · 2026-10

Potencial · sin medición propia

  • Cada dato

    del pliego con página y texto literal comprobados antes de usarlo

  • 0 afirmaciones

    sin documento soporte en la oferta; lo que falta bloquea la exportación

Cronología

Cómo ha evolucionado

  1. Ingesta de CODICE, señales, filtro duro y puntuación sobre datos reales.

  2. Lectura de pliegos con citas verificadas y web conectada al equipo local por una cola.

  3. Alertas de Telegram con botones y embudo por licitación.

  4. Cálculo de alertas de unos nueve minutos a siete segundos.

  5. Preparación de ofertas con memoria técnica en borrador y requisitos del pliego.

Evolución prevista

Lo siguiente

Trabajo planificado, todavía no disponible.

  1. Previsto · 01

    Validación de la lectura de pliegos

    Revisar 20 pliegos a mano en la web y medir el error por grupo de datos críticos: solvencia, criterios, sobres y fecha límite, con menos del 10 % en cada uno.

  2. Previsto · 02

    Segunda versión de la preparación de ofertas

    DEUC, registro de cada oferta en la base y forma de dar por verificada la solvencia desde la web.

  3. Previsto · 03

    Prospección en organismos

    Seguimiento de los organismos que compran lo que la empresa ofrece, sin referirse nunca a un expediente en curso.

  4. Previsto · 04

    Proveedores e insumos

    Presupuestos de proveedores para sustituir el margen por defecto por el coste real en el precio sugerido.

Proyectos relacionados

Más trabajo en esta línea

Ver todos los proyectos
  • Sunkiss MVP

    CRM omnicanal Sunkiss

    Cosmética y comercio electrónico · CRM/ERP a medida

    CRM y gestión de stock para una marca argentina que vende en Tiendanube y Mercado Libre: lotes con FEFO, ventas unificadas, cobros conciliados y anuncios.

    • Python
    • FastAPI
    • Pydantic
    • JWT
  • Datos de demostración Tablero del CRM con las órdenes repartidas por estación del taller (preparación, diamantado, pintura, montaje, control de calidad y terminado), con operario y tiempo en curso.

    The Wheel Lab En producción

    CRM y ERP a medida para un taller de llantas

    Automoción y posventa · CRM/ERP a medida

    CRM y ERP a medida para un taller de reparación de llantas: de la consulta al cobro, con QR por llanta, recogidas con conductor y facturación por sucursal.

    • Python
    • FastAPI
    • SQLModel
    • Pydantic
  • Portada de la web pública del Observatorio: un corredor vial con un tramo cortado por crecida y el aviso de desvío en el kilómetro 300.

    Producto propio En producción

    Observatorio de Riesgo Vial

    Logística y transporte por carretera · Plataforma de datos e inteligencia territorial

    Plataforma que reúne 44 fuentes públicas sobre las rutas argentinas y estima, por tramo de 10 km, la probabilidad de corte en las próximas horas.

    • Python
    • Pydantic
    • APScheduler
    • PostgreSQL

Hablemos

¿Necesitas desarrollar una solución similar?

Cuéntanos el problema. Te respondemos con un planteamiento claro: qué haríamos, en cuánto tiempo y con qué entregables.