Automatización de Mantenimiento Hospitalario con IA: Caso Real
En una unidad hospitalaria de São Paulo, cuatro gestores perdían dos horas y media por semana decidiendo, orden por orden, qué era urgente y qué podía esperar en el mantenimiento del hospital. Agence fue convocada para probar que la automatización de mantenimiento hospitalario con IA podía hacer esa clasificación inicial sin quitarles la última palabra.
El cuello de botella: 14 horas por semana para priorizar órdenes de mantenimiento manualmente
La unidad atendida forma parte de una gran red hospitalaria de São Paulo, con un parque de activos que va desde equipos críticos de UCI hasta ítems de infraestructura edilicia, como aire acondicionado e iluminación. Todo ese parque se gestiona de forma centralizada a través de Manusis4, el CMMS que la red usa para registrar las órdenes de mantenimiento preventivo, correctivo y predictivo a lo largo de la semana. Fue el propio hospital el que se acercó a Agence, a fines del primer semestre de 2025, con una queja directa: el proceso semanal de priorización de órdenes de mantenimiento estaba consumiendo demasiado tiempo del equipo de gestión.
La rutina seguía un guion fijo. Cada lunes por la mañana, el analista de planificación entraba a Manusis4, exportaba los datos y consolidaba todo manualmente en una planilla de Excel. El lunes por la tarde, cuatro gestores se reunían durante dos horas y media para analizar cada orden, una por una, y decidir qué entraba en la cola de ejecución de esa semana. Terminada la reunión, el analista volvía a Manusis4 para actualizar manualmente el estado de cada orden aprobada, liberando así el secuenciamiento del servicio. Las órdenes rechazadas quedaban en la planilla y volvían a la agenda en las semanas siguientes.
Este es el tipo de cuello de botella que suele justificar un proyecto de automatización de procesos: profesionales calificados atrapados en una tarea repetitiva, sin tiempo para frentes más estratégicos de la operación hospitalaria.
14h
horas-hombre consumidas por semana solo en la etapa de priorización, antes de ejecutar un solo servicio
2h30
duración de la reunión semanal en la que los gestores analizaban orden por orden
4
gestores involucrados en el análisis de cada orden de mantenimiento
Diagnóstico: costo de tiempo, variabilidad entre gestores y riesgo de error en la planilla
El diagnóstico del hospital reveló que el problema no era solo la duración de la reunión. La preparación consumía alrededor de 4 horas semanales del analista de planificación, y la reunión ocupaba a los 4 gestores durante 2 horas y media, sumando 10 horas-hombre. En total, 14 horas de trabajo calificado se gastaban antes de que cualquier orden de mantenimiento se ejecutara realmente. En las entrevistas apareció un segundo patrón: en los extremos de la priorización, entre lo claramente crítico y lo claramente de baja prioridad, los gestores coincidían. La divergencia se concentraba en las categorías intermedias, y la causa era más humana que técnica: un gestor con mayor cercanía a determinado sector del hospital tendía a asignarle mayor criticidad a una orden que un colega sin esa vivencia, incluso ante la misma información.
Costo de tiempo
4 horas semanales del analista de planificación más 10 horas de los cuatro gestores en reunión suman 14 horas-hombre por semana, gastadas antes de ejecutar cualquier servicio.
Variabilidad entre gestores
En los extremos de la priorización había consenso. La divergencia se concentraba en las categorías intermedias, por la asimetría de vivencia entre gestores y sectores del hospital.
Riesgo de error manual
La extracción y consolidación enteramente manuales en Excel generaban reuniones afectadas por datos equivocados en la planilla, según relató el propio equipo.
La solución en dos capas: extracción automática y clasificación por IA
La respuesta definida junto con el hospital fue dividir la solución en dos capas. La primera es sistémica: automatiza la extracción y consolidación de los datos que hoy salen de Manusis4, un caso concreto de automatización de CMMS, sin depender de que el analista abra el sistema cada lunes. La segunda es cognitiva: analiza semánticamente cada orden de mantenimiento y propone una clasificación de prioridad, reproduciendo los criterios que los propios gestores usan.
Este diseño sigue los principios de human in the loop en IA aplicados a cualquier proceso crítico, donde la decisión final nunca puede quedar solo en manos del modelo.
La metodología siguió dos carriles. Con el equipo del hospital, Agence aplicó las fases de empatía y definición del Design Thinking, con sesiones de shadowing y entrevistas grabadas a analistas y gestores. Con el equipo técnico, las fases de ideación, prototipado y pruebas corrieron en sprints quincenales bajo Scrum, y el mejor resultado de cada ciclo se llevaba a una reunión de validación con el hospital cada tres días.
Decisiones de ingeniería: por qué automatización web, LLM local y Playwright ganaron a las alternativas
Cada decisión técnica respondió a una necesidad específica, y en casi todas ellas la alternativa más obvia se descartó por un motivo concreto. Manusis4 es un SaaS sin acceso al código fuente y su documentación no contempla API de exportación, lo que hacía inviable la integración vía API. La salida fue automatización web no invasiva, que simula la navegación de un usuario real dentro de la propia plataforma.
| Necesidad | Alternativa descartada | Decisión |
|---|---|---|
| Extracción y consolidación de datos | Integración vía API, inviable por tratarse de un SaaS sin código fuente ni endpoint de exportación | Automatización web no invasiva, simulando la navegación de un usuario |
| Preclasificación de las órdenes | Árbol de decisión y machine learning, exigían un volumen de datos no disponible | Modelo de lenguaje con ingeniería de prompt para IA |
| Interoperabilidad con Power BI | Rehacer los dashboards, con riesgo de incompatibilidad con planillas históricas | Preservación íntegra del formato de la planilla maestra ya usada por el hospital |
| Soberanía de los datos sensibles | API de LLM de terceros, con riesgo de alimentar el entrenamiento de modelos externos | LLM local para datos sensibles, alojado en la infraestructura del propio hospital |
| Resiliencia sistémica | Solicitudes directas sin manejo de fallas, vulnerables a la inestabilidad de Manusis4 | Playwright, con espera automática nativa y lógica de reintento |
El volumen de órdenes históricas priorizadas tampoco sostenía un modelo estadístico convencional: el patrón de referencia disponible sumaba solo 500 órdenes, un dato insuficiente para entrenar un árbol de decisión o un modelo de machine learning tradicional. Fue ese límite, y no el tamaño del parque de equipos del hospital, lo que llevó a elegir un modelo de lenguaje con ingeniería de prompt para IA. El resultado es una stack enteramente abierta, con Python, Playwright, Pandas y Qwen2.5-14B, sin costo de licencia y totalmente auditable, lo que facilita tanto el mantenimiento como la revisión técnica por parte de terceros.
Ingeniería de prompt: cómo la concordancia con los gestores pasó de 38% a 72%
El hospital entregó un patrón de referencia con 500 órdenes de mantenimiento ya priorizadas por los gestores. Con cada cambio relevante en el prompt, el equipo técnico corría el flujo completo y comparaba el resultado con ese patrón mediante scripts propios, que generaban automáticamente el porcentaje de concordancia y la matriz de confusión. El flujo llegó a ejecutarse una o dos veces al día, mapeando avances, retrocesos y patrones de falla en cada iteración.
38%
concordancia en la V1, con persona genérica y sin contexto institucional
55%
concordancia en la V2, con contexto del hospital y few-shot
72%
concordancia en la V3, con puntajes numéricos de riesgo
V1: línea base
Persona de Ingeniero Clínico Senior, anclada en normas reales, pero deliberadamente sin información de la institución. El modelo acertaba las demandas críticas, pero sobreestimaba la prioridad de las órdenes de baja criticidad.
V2: contextualización
Contexto del hospital, matriz de criticidad institucional y ejemplos reales con justificación caso por caso. El calibre general mejoró, pero las órdenes de una misma categoría seguían siendo indistinguibles entre sí.
V3: puntajes numéricos
Se incluyeron dos valores enteros en la respuesta, riesgo para el paciente e impacto operativo. Eso fue lo que le dio a la IA la granularidad que faltaba dentro de cada categoría de prioridad.
El salto de una versión a otra no vino de un modelo más grande o más caro: vino de un prompt más específico. Es la misma lección que aparece en otros proyectos de inteligencia artificial aplicada a procesos de negocio, donde la ingeniería de prompt suele valer más que la elección del modelo en sí.
Dos puntajes numéricos bastaron porque son exactamente las variables que alimentan el score de riesgo en mantenimiento diseñado con el hospital: riesgo para el paciente e impacto operativo. Agregar un tercer criterio exigiría recalibrar toda la matriz de pesos, sin garantía de que el patrón de 500 órdenes sostuviera esa granularidad adicional.
El score de riesgo y las cuatro capas contra la alucinación de la IA
La respuesta de la V3 se apoya en una fórmula simple: score de riesgo en mantenimiento = (riesgo para el paciente × 0,6) + (impacto operativo × 0,4). El equipo probó cuatro combinaciones de peso distintas, y esta fue la que más coincidió con la priorización histórica de los gestores. La variable de riesgo para el paciente captura todo lo que amenaza la seguridad del paciente y las exigencias regulatorias; la de impacto operativo captura infraestructura y gestión.
- ✓Autosuficiencia del prompt: todos los insumos necesarios para la clasificación ya están dentro del propio prompt, sin búsqueda externa en tiempo real.
- ✓Contextualización específica de la institución: cuanto más claras estén las reglas del hospital dentro del prompt, menor será el margen para que la IA invente un criterio propio.
- ✓Restricción de formato: la respuesta sale en JSON, con claves y tipos fijos, lo que permite detectar automáticamente cualquier salida fuera de patrón y disparar un reintento.
- ✓Human in the loop: la validación final sigue en manos de los gestores, la capa de protección más importante de todas.
Esta disciplina de validación sigue el mismo razonamiento que orienta cualquier proyecto de implementación de IA en empresas: probar contra un problema real antes de confiar en la solución a escala.
En la práctica, es la capa 3 la que actúa primero cuando alguna respuesta se desvía de lo esperado. Si el modelo devuelve un JSON con un campo faltante o de tipo incorrecto, el sistema descarta la respuesta y dispara automáticamente un nuevo intento de la misma solicitud, antes de que cualquier clasificación malformada llegue cerca de la planilla de los gestores.
Protocolo de validación: probando la IA sin sesgo de confirmación
Antes de prometer cualquier reducción de esfuerzo, la solución tenía que demostrar que clasificaba bien sin contaminar la decisión de los gestores. El diseño del piloto se pensó exactamente para eso.
- 1Dos semanas en paraleloLa automatización corrió al lado del proceso antiguo completo, procesando 198 órdenes de mantenimiento, sin sustituir todavía ninguna etapa manual.
- 2Confidencialidad hasta el final de la reuniónLas priorizaciones generadas por la IA se mantuvieron ocultas hasta el cierre de cada reunión del comité, para evitar que los gestores decidieran influidos por la sugerencia del modelo.
- 3Comparación solo despuésRecién después de la reunión se comparaban las clasificaciones de la IA con las decisiones humanas. Este diseño evitó el sesgo de confirmación, el punto central de este protocolo de validación de IA en procesos críticos.
- 4Métricas del pilotoPrecisión de la clasificación, sensibilidad en las órdenes críticas y tiempo promedio de cada etapa de la automatización fueron los tres indicadores monitoreados durante esas dos semanas.
- 5Reducción de esfuerzo medida despuésSolo después de que la solución entró en producción, con la planilla ya preclasificada como punto de partida, la ganancia de tiempo de los gestores entró en la cuenta.
Resultados en producción: menos horas de gestión, la misma decisión final humana
Con la solución en producción, el ciclo completo pasó a correr en 55 minutos: 20 minutos de extracción, en su mayoría el tiempo de descarga de las planillas en Manusis4, 33 minutos en el flujo de priorización por IA y 2 minutos de transformación, ya con la consolidación de los datos y la generación de la planilla final en el formato heredado que los dashboards de Power BI ya usaban. El resultado consolida un modelo de IA para gestión hospitalaria que preserva la decisión de los gestores y reduce solo el trabajo repetitivo alrededor de ella.
98%
tasa de éxito en 50 ciclos consecutivos de extracción
72%
concordancia final con los gestores en la prueba en producción
18/18
órdenes críticas del período acertadas, sin ningún rebajamiento en la capa de emergencia
40%
reducción aproximada en el tiempo de las reuniones de gestión semanales
| Indicador | Antes | Después |
|---|---|---|
| Preparación de datos | 4 horas semanales | Menos de 1 minuto, el tiempo de abrir el correo con la planilla lista |
| Reunión de priorización | 4 gestores durante 2h30 | Alrededor de 40% más corta |
| Naturaleza de la reunión | Clasificación ítem por ítem | Validación de excepciones |
| Costo de infraestructura de IA | No existía | Alrededor de US$ 20 al mes, con instancias spot |
La reunión dejó de ser sobre clasificar cada orden una por una y pasó a ser sobre validar las pocas excepciones que realmente exigen una decisión humana.
Preguntas frecuentes sobre automatización de mantenimiento hospitalario con IA
¿Cómo funciona la priorización automática de órdenes de mantenimiento con inteligencia artificial?
Un robot de automatización web extrae las órdenes de Manusis4 al comienzo de cada semana. Cada orden se envía a un modelo de lenguaje, que clasifica la prioridad y calcula un score de riesgo en función del impacto al paciente y de la operación. El resultado llega a los gestores como una pre-priorización, ya organizada en la planilla que siempre usaron.
¿La IA sustituye la decisión de los gestores en la priorización de mantenimiento hospitalario?
No. La IA entrega una sugerencia de prioridad para cada orden, pero la validación final sigue en manos de los cuatro gestores del comité. Esa fue una premisa definida antes de escribir la primera línea de código, porque el proceso implica un riesgo directo para el paciente.
¿Es seguro usar inteligencia artificial con datos hospitalarios sensibles?
El proyecto usó un LLM local para datos sensibles, alojado en la infraestructura del propio hospital, para que ninguna información de paciente o de activo crítico saliera de la institución hacia una API de terceros que pudiera usarla para entrenar otros modelos.
¿Cuánto cuesta mantener una solución de IA local para automatización de mantenimiento?
En el caso analizado, el costo de infraestructura de IA quedó alrededor de US$ 20 al mes. Mantener el servidor con GPU corriendo todo el mes costaría cerca de US$ 400, pero como la rutina solo necesita ejecutarse una vez por semana, las instancias spot se activan y se apagan automáticamente según el uso.
¿Cómo evitar que la IA alucine al clasificar prioridades en procesos críticos?
Con cuatro capas: un prompt autosuficiente, que ya contiene toda la información necesaria; contexto específico de la institución; respuesta en formato fijo, que permite detectar y repetir automáticamente cualquier salida fuera de patrón; y validación humana final, la capa que ninguna de las otras reemplaza.
Prioriza el mantenimiento crítico con el rigor que tu operación exige
El resultado de este caso no vino de una promesa genérica de IA: vino de un patrón real para medir concordancia, de una ingeniería de prompt iterada hasta que el número sostuvo la decisión, y de un protocolo de validación sin sesgo de confirmación. Si en tu operación lidias con un proceso manual y crítico, vale la pena evaluar con un especialista dónde hay espacio para este mismo tipo de pre-priorización, sin renunciar a la decisión final humana.
