Continuidad de contratos en n8n
Un hospital público descubre tarde que un contrato vence. Llevé el despliegue de principio a fin: diagnóstico, una cartera priorizada, dos flujos en producción en n8n y el modelo operativo que se queda el hospital.
Resumen
Los hospitales públicos contratan casi todos sus servicios recurrentes a plazo fijo, y nadie es responsable de la fecha de fin. Lo traté como un despliegue empresarial, no como una demo: un diagnóstico con datos públicos de contratación, nueve oportunidades de automatización puntuadas por valor, disponibilidad de datos, esfuerzo y riesgo, las dos primeras construidas y funcionando en n8n Cloud, y un modelo operativo de una página con entrada de peticiones, responsables, una revisión previa a producción, credenciales y señales de ampliación. Claude redacta; decide una persona con nombre; cada decisión queda registrada.
En resumen
- 15 %de los 255 contratos recurrentes de un hospital requieren una decisión yaDatos públicos · radar 10 oct 2026
- 84 %de los urgentes no tienen sucesor localizadoEmparejamiento heurístico, precisión aún sin medir
- 1 correoa la semana a la jefatura de contratación: cinco resúmenes, un formulario, una decisión obligatoria por contratoEn producción en n8n Cloud
- 20 → 6lotes desiertos agrupados por licitación, cada una clasificada y derivada una sola vezEn producción en n8n Cloud
- 9oportunidades puntuadas; la de más valor, a propósito, con prioridad bajaCartera
- 0nombres de compradores en el repositorio público, comprobado antes de cada publicaciónMedido
El problema
Un hospital renueva mantenimientos, suministros y servicios mediante licitaciones que duran meses. La ley deja poco margen: la prórroga solo obliga al contratista con dos meses de preaviso, y un contrato vencido solo puede continuar hasta nueve meses si la nueva licitación se publicó tres meses antes del fin. El plazo real es la fecha de publicación, mucho antes de la fecha de fin.
En la práctica, la fecha de fin vive en una hoja de cálculo o en la memoria de alguien. Cuando se pasa, el hospital prorroga de urgencia o sigue pagando sin contrato, y ambas cosas vuelven después como reparos de auditoría.
La solución no es licitar más rápido. Es empezar antes, con un responsable con nombre y una decisión con fecha.
Qué construí
Dos flujos en n8n Cloud, alimentados por una API de solo lectura sobre los datos de contratación que ya mantengo.
- Radar semanal de vencimientos: obtiene los contratos en riesgo, se queda con los que requieren decisión, pide a Claude un resumen breve de cada uno y envía a la jefatura de contratación un solo correo con un solo formulario: la sugerencia de Claude y una decisión obligatoria por contrato. Cada respuesta queda en un registro con quién, cuándo y qué sugirió Claude.
- Clasificación de lotes desiertos: agrupa por licitación los lotes sin ofertas, omite los ya clasificados, pide a Claude el motivo probable con las reglas del propio hospital (estructural, decisión previa, abordable), deriva cada licitación a quien puede actuar y la registra una vez.
- Una API de solo lectura: el sistema de referencia sigue siéndolo. Sirve códigos y referencias anonimizados, nunca enlaces ni nombres de proveedores o compradores.
Mi papel
Lo llevé como se lleva un despliegue presencial, con la parte de negocio primero.
- Diagnóstico. Mapa del proceso actual, mapa de actores con el escéptico probable (la Intervención), los plazos legales, preguntas para las entrevistas de la primera semana y cuatro hipótesis que el piloto debe confirmar o descartar. Diagnóstico ↗
- Priorización y valor. Nueve oportunidades puntuadas como valor × disponibilidad de datos ÷ (esfuerzo + riesgo), una hoja de ruta de 90 días con una puerta medida entre fases y una lógica de retorno que empieza por el riesgo y el tiempo del equipo, no por el precio. Cartera ↗
- Construcción. Las dos primeras oportunidades como flujos de n8n, generados desde código para que cada versión de nodo y cada conexión se pueda revisar, y ejecutados en n8n Cloud con correo y tablas de datos reales. Guía de puesta en marcha ↗
- Gobierno. Un modelo operativo que se queda el hospital: roles, entrada de peticiones, una matriz RACI, una revisión de nueve puntos antes de producción, una política de credenciales, métricas y las señales de ampliación para el equipo de Customer Success. Modelo operativo ↗
Decisiones de diseño
Dónde está el criterio.
Una persona decide cada caso.
Claude redacta y sugiere; la jefatura elige entre cuatro opciones. No se envía nada a proveedores. Si nadie responde en tres días, se registra «sin respuesta», así el silencio se ve.
Un correo a la semana, no uno por contrato.
Cinco decisiones en un formulario respetan el tiempo de la jefatura, que es lo que decide si el flujo se usa o no.
Lo de más valor, con prioridad baja a propósito.
Redactar pliegos con IA es lo que más aporta y lo que más riesgo tiene. Espera a que flujos más sencillos se ganen la confianza de la asesoría jurídica y la Intervención.
Lo ilegible nunca se pierde.
Si la respuesta de Claude no se puede leer, el caso pasa a una persona con confianza baja; ni se rompe el flujo ni queda un hueco silencioso.
Nunca dos veces.
La clasificación consulta su propio registro antes de trabajar: si se ejecuta otra vez, no envía ni registra nada nuevo.
Anónimo por diseño.
Los códigos de hospital y las referencias de contrato son hashes con clave, los títulos se depuran con una lista privada y una comprobación revisa cada archivo antes de publicar.
Lo que encontraron las ejecuciones reales
Cada ejecución, una mejora.
Nada de esto apareció al planificar. Cada hallazgo cambió el flujo.
Lectura
Hallazgo
La instantánea pública se sirve como texto plano: n8n leyó 38 contratos como una sola cadena y se detuvo sin avisar.
Cambio
La petición fuerza la lectura como JSON; la prueba local usa ya la misma URL que producción.
Formato
Hallazgo
Claude envolvió su JSON en un bloque de código y una capa extra; el analizador estricto falló en dos de cinco resúmenes.
Cambio
Un analizador tolerante y una salida visible para lo que siga sin poder leerse.
La heurística
Hallazgo
El emparejador tomó un contrato de ovocitos como «sucesor» de uno de semen de donante. El resumen de Claude señaló el error.
Cambio
Se mantiene como diseño: la heurística propone, Claude revisa, decide una persona y el registro guarda las tres cosas.
Agrupación
Hallazgo
Una licitación tenía 13 lotes desiertos y la primera clasificación escribió el mismo resumen seis veces.
Cambio
Los lotes se agrupan por licitación antes de clasificar: 20 lotes quedaron en 6 casos distintos.
Comillas
Hallazgo
Una respuesta rompió el JSON con unas comillas dentro de un valor; esa licitación pasó a una persona como «no claro».
Cambio
La red de seguridad funcionó; el analizador ahora también lee los campos uno a uno.
En producción en n8n Cloud
Las decisiones de estas capturas son respuestas de demostración, no las de un hospital.
Qué debe demostrar el piloto
| H1 · Contratación responde al resumen semanal: casos respondidos en 3 días | ≥ 80 % |
|---|---|
| H2 · El radar acierta lo bastante para fiarse: precisión del emparejador en las primeras 50 respuestas | ≥ 70 % |
| H3 · Decidir antes reduce los vencimientos sin sucesor: por trimestre, frente a la línea base | A la baja |
| H4 · Claude ayuda y no sesga: tasa de discrepancia, con motivos registrados | 10–50 % |
Tecnología
- n8n Cloud
- Claude (Sonnet, desde n8n)
- Formularios de Gmail con espera de respuesta
- Tablas de datos de n8n
- Enrutado con Switch y Merge
- Python (servidor HTTP estándar)
- DuckDB
- Anonimización con hashes con clave
- Datos públicos de la PLACSP
Siguientes pasos
- Usar cada respuesta del formulario como verdad de referencia para el emparejador, para medir la precisión en lugar de suponerla.
- Avisos de preaviso de prórroga tres semanas antes del plazo de dos meses, lo siguiente en la cartera.
- Un informe mensual para la Gerencia a partir del registro de decisiones.
- Pasar el resumen de un buzón personal a uno compartido de contratación, como exige la política de credenciales.
Proyecto independiente con datos públicos de contratación de la PLACSP. No se nombra ningún hospital, comprador, región ni tribunal; el hospital aparece como un código anónimo y fue socio de diseño de una investigación independiente, no un cliente. Las decisiones mostradas son de demostración. n8n y Claude son las herramientas utilizadas; este proyecto no está respaldado ni patrocinado por n8n ni por Anthropic.
Siguiente proyectoLicita