La operación del día: cómo marcar el servicio en riesgo antes de que se incumpla, con IA y MCP

Son las 11:40 de un martes. El coordinador de la sede norte tiene treinta servicios abiertos, seis salas ocupadas, dos cortejos que salen esta tarde y una cremación programada a las 15:00. El teléfono suena: es el asesor que acompaña a una familia en la sala 2, preguntando por qué el cuerpo no ha llegado. El traslado salió tarde de otra ciudad hace tres horas. Nadie lo supo hasta que la familia preguntó.

Ese es el problema. No es que el sistema no tenga el dato —lo tiene—, es que el dato solo habla cuando alguien lo mira, y el coordinador que debería mirarlo es exactamente la persona que está resolviendo otras veintinueve cosas. La pregunta de este artículo es concreta: ¿se puede usar la IA y el MCP sobre el ERP para que ese traslado aparezca marcado a las 9:15, cuando todavía se podía mandar el segundo coche?

La respuesta honesta tiene dos partes. Sí, se puede —pero no por donde casi todo el mundo empieza. Y en algunos casos no se debe, y hay evidencia formal de por qué. Este es el undécimo caso del cluster de IA, agentes y MCP aplicado a la operación funeraria, después de los de atención, call center, cobranza, cuadrantes de turnos, cierre contable, KPIs en lenguaje natural y gobierno de los agentes. Si lo que buscas es cómo se estructura la operación en sí —estados, SLA, coordinación 24/7—, ese trabajo está en la guía de gestión operativa de servicios funerarios a escala. Este artículo es lo otro: qué pasa cuando le pides a una IA que te avise antes.

1. El problema de negocio y cuánto cuesta hoy

En un grupo funerario grande, el incumplimiento operativo casi nunca es catastrófico. Es acumulativo. El traslado que llega cuarenta minutos tarde y desplaza la preparación; la preparación que se corre y hace esperar a la familia en el ingreso; la velación que empieza tarde y se solapa con la siguiente reserva de la misma sala; el cortejo que sale con retraso y llega al parque después de la hora de inhumación; la cremación que pierde su cupo del día y obliga a reprogramar con la familia ya notificada.

Ninguno de esos eventos genera por sí solo una crisis. Todos juntos, repetidos varias veces por semana en seis sedes, producen tres costos que sí llegan al comité de dirección:

• Costo de reputación en el peor momento posible. Una familia en duelo no evalúa tu operación por el promedio: la evalúa por la hora en que le dijiste que llegaba su padre. Este sector no tiene segunda oportunidad ni cliente recurrente que perdone.
• Costo directo de la corrección tardía. El segundo vehículo que sale a las carreras, la hora extra del conductor, el turno que se estira, el proveedor de última hora que cobra tarifa de urgencia. Se paga siempre, pero se contabiliza como gasto operativo difuso y no como consecuencia de un retraso.
• Costo de oportunidad de la sala y del horno. Una sala bloqueada por una velación que no cerró y un horno con el cupo perdido son inventario perecedero: la hora no vendida no se recupera. Es el mismo argumento del inventario de espacios del parque, aplicado a la operación diaria.

Y hay un cuarto costo, invisible y más caro: la carga cognitiva del coordinador. La persona que sostiene la operación de la sede está haciendo, todo el día, la misma tarea manual: recorrer mentalmente treinta expedientes y decidir cuáles merecen una llamada. Eso es exactamente el trabajo que una máquina puede reducir —y es, además, la métrica correcta del proyecto, como veremos más adelante.

2. Antes de construir nada: la pregunta que decide si el panel vale la pena

El instinto de cualquier equipo de producto ante este problema es pintar un semáforo en cada fila del tablero. La investigación sobre monitoreo prescriptivo de procesos —la disciplina que estudia exactamente esto: cuándo alertar sobre un caso en curso— dice que ese instinto está mal, y lo dice con una condición formal.

Traducido a una funeraria, esto obliga a una conversación que dura media hora y ahorra un proyecto entero. Para cada tipo de incumplimiento hay que estimar tres números: qué cuesta que ocurra, qué cuesta corregirlo y qué fracción de las veces la corrección de verdad funciona. El resultado es una lista corta, no un semáforo universal:

Hay un segundo hallazgo de la misma línea de investigación que conviene conocer antes de prometer nada. Los mismos autores probaron una variante que retrasa el disparo de la alarma hasta tener varias confirmaciones en vez de dispararla al cruzar el umbral. El resultado: a veces el costo baja un veinte por ciento o más, pero en la gran mayoría de los casos ambos sistemas producen el mismo resultado. Es decir, la confirmación múltiple es una idea razonable —no dispares por un solo indicio, espera a que el traslado además no marque el siguiente hito— pero no es una característica vendible hasta que la midas en tu propia operación.

El problema del momento: la predicción es peor justo cuando sirve

El segundo hecho incómodo es de calendario. En el benchmark de referencia de predicción de resultado de procesos —once métodos sobre registros reales—, la exactitud del modelo crece a medida que el caso avanza y llega a ser perfecta cerca del cierre. Dicho de otro modo: el sistema acierta con seguridad justo cuando ya no queda nada por reasignar. La predicción temprana, la única que sirve para mover una carroza, es la menos confiable.

La consecuencia de diseño es directa y va contra la costumbre: no publiques un solo número de exactitud, publica la exactitud por ventana de acción. Qué tan bien acierta el sistema a veinticuatro horas del servicio, a seis horas y a una hora. Si a seis horas —la ventana en que todavía se puede reorganizar el día— el modelo apenas supera al azar, entonces lo correcto no es un semáforo rojo, es una lista ordenada por holgura: cuánto margen le queda a cada servicio antes de que el retraso sea irreversible.

Y conviene fijar expectativas con la mejor evidencia disponible sobre cuánto se puede predecir realmente la duración de una operación con hora comprometida, que es la industria hospitalaria:

3. Qué datos del ERP intervienen (y qué de esto existe hoy)

Este es el punto donde la mayoría de los artículos del sector se vuelven vagos. Vamos al revés: lo que sigue está verificado contra el código del producto, y separa con claridad lo que un grupo funerario puede montar esta semana de lo que todavía no existe.

Lo que ya existe y es aprovechable hoy

• Detección de vencimiento en vivo de traslados. El módulo de recursos de la consola marca un traslado como vencido cuando su hora de fin ya pasó y su estado no es «Terminado» ni «Cancelado», cuenta cuántos hay y ordena los servicios poniendo primero los que más incumplimientos acumulan. La pantalla se refresca sola cada noventa segundos.
• Detección en vivo de velaciones y salas, con una clasificación de cuatro estados —en curso, vencida, próxima, inactiva— y, sobre todo, un porcentaje de avance de la ventana consumida. Ese porcentaje es la semilla natural de una señal anticipada: no hace falta un modelo para saber que una velación al 95 % de su ventana con la siguiente reserva a media hora es un problema.
• Estado del servicio derivado en lote y barato. El sistema calcula el estado de todos los servicios abiertos con una docena de consultas agregadas en vez de recorrerlos uno por uno, lo que hace viable evaluar la operación completa del día varias veces por hora.
• Una jerarquía de severidad ya escrita en el producto: lo que la familia está viviendo pesa más que lo administrativo, y cobrar o entregar al cliente pesa más que lo pendiente con el proveedor. Es la prioridad del negocio ya codificada; no hay que inventarla para ordenar la lista del día.
• Encadenamiento de traslados: al cerrar uno, el sistema propone el siguiente del mismo servicio, prefiriendo el que arranca donde el anterior terminó. Es la base para proyectar el efecto dominó de un retraso.
• Agenda semanal unificada que cruza traslados, velaciones y exequias por servicio en una rejilla de día y hora: el plan contra el cual comparar la ejecución.
• El historial ya se está acumulando. El traslado tiene activado el seguimiento de cambios, así que cada modificación de estado y de fecha queda registrada. Con eso se puede calcular hoy la duración real contra la programada por tipo de traslado, sin tocar el modelo de datos. Es el activo más subestimado de todo el caso.
• Los canales de aviso ya están montados: mensajería en tiempo real hacia la consola y envío por WhatsApp con plantilla aprobada, registro de notificación y encolado. Hoy se usan para recordar el cierre de turno del coordinador, no para avisar de un servicio en riesgo — pero la integración no hay que construirla.

Lo que no existe, y por qué importa más que el modelo

Aquí van las brechas verificadas de nuestro propio producto. Las publicamos porque un artículo de caso de uso que solo cuenta lo que ya funciona no le sirve a nadie para decidir, y porque este es el orden real en que hay que resolverlas.

4. Cómo se arma el caso con MCP, paso a paso

El orden importa, y es contraintuitivo: las tres primeras etapas no tienen modelo. Cada una entrega valor por sí sola y es condición de la siguiente.

Etapa 1 — Congelar la promesa (sin esto no hay caso)

Antes de cualquier IA, el sistema tiene que guardar dos horas distintas: la comprometida con la familia cuando se acordó el servicio, que no se reescribe nunca, y la programada actual, que cambia todas las veces que haga falta. La diferencia entre ambas es el cumplimiento. Es un campo, no un proyecto, y sin él todo lo que sigue es imposible de evaluar. En paralelo, hay que declarar la duración esperada por tipo —retiro urbano, traslado interurbano, preparación, velación estándar, cortejo, cremación— aunque sea con el promedio histórico que ya se puede calcular del historial de cambios.

Etapa 2 — Medir el cumplimiento real antes de intentar predecirlo

Con la promesa congelada, un agente conectado por MCP puede hacer algo que hoy nadie hace en el sector: producir la distribución real de desviaciones por tipo de servicio, por sede, por franja horaria y por día de la semana. No «llegamos tarde a veces», sino: el retiro hospitalario nocturno se desvía en mediana veinticinco minutos y en el percentil noventa, dos horas. Esa tabla es, por sí sola, el primer entregable con valor de dirección — y es la línea base contra la cual se medirá todo lo demás.

Etapa 3 — La lista del día por holgura, no por semáforo

Con las duraciones esperadas y la agenda del día, se calcula para cada servicio abierto cuánto margen le queda antes de que el retraso se vuelva irreversible. No hace falta aprendizaje automático: es aritmética sobre datos que ya existen, más el encadenamiento que el producto ya calcula. La salida es una lista corta ordenada por holgura, con el motivo escrito al lado.

Etapa 4 — Dónde entra de verdad el modelo, y dónde el LLM

Recién en la cuarta etapa, y con meses de historial ya acumulado, tiene sentido un modelo que estime la probabilidad de incumplimiento. Y aquí hay un hallazgo de 2026 que conviene tener claro antes de escribir una sola línea de código: en una comparación sobre cinco registros de procesos, los modelos de secuencia clásicos superaron a los modelos de lenguaje en la predicción misma, con tiempos de ejecución entre diez y cien veces menores. Los autores lo resumen sin ambigüedad: los modelos de lenguaje suelen quedarse atrás pese a un costo mayor.

Esa intuición tiene respaldo desde un dominio muy distinto. En un trabajo publicado en Transportation Science sobre recuperación de tripulaciones en una aerolínea con más de 2.800 vuelos diarios, los autores destacan que la estructura interpretable del modelo fue crítica para ganar la confianza del usuario final, y que las soluciones resultantes eran más robustas a la incertidumbre de la predicción de retraso que la optimización directa. La compañía no publica el ahorro puntual, así que aquí no hay cifra que citar: lo transferible es el diseño, no el número.

La señal que nadie está usando: el propio comportamiento en el sistema

El hallazgo más aprovechable de toda la investigación viene de un ensayo hospitalario multicéntrico registrado, con casi 61.000 encuentros, donde el sistema de alerta temprana no leía sensores: leía los patrones de documentación del personal de enfermería. Es decir, la conducta del operador dentro del sistema resultó ser señal predictiva por sí misma. Los resultados reportados incluyen una reducción del riesgo de muerte y de la estancia — y, con la misma honestidad, un aumento cercano al 25 % de los traslados no anticipados a cuidados intensivos: más detección significa más intervenciones, y las intervenciones cuestan.

Homologado a una funeraria: el registro de uso del ERP ya es señal y nadie lo mira. Cuántas veces se abrió el expediente 4412, cuántas veces se reprogramó, si alguien dejó una nota a las 23:40, si el coordinador consultó dos veces al crematorio el mismo día. Ese rastro ya está en la base de datos, no requiere ningún campo nuevo, y es probablemente el mejor predictor disponible de que un servicio se está complicando. También conviene presupuestar su contracara: si la detección funciona, habrá más vehículos de refuerzo y más horas extra, y eso hay que poder pagarlo.

5. El bucle de mejora continua

Como todo caso de este cluster, esto no es un tablero que se instala: es un ciclo que se corre. La cadencia que tiene sentido en una operación funeraria es doble.

1. Todos los días, al cierre de la operación (15 minutos). Revisar los servicios que la lista marcó y los que se incumplieron sin haber sido marcados. Estos últimos —los falsos negativos— son el material de aprendizaje más valioso: cada uno responde «qué señal existía a las 9:00 que no estábamos mirando».
2. Todos los días, sobre las alertas descartadas. Cuando el coordinador descarta una alerta, esa decisión es un dato. Si descarta sistemáticamente el mismo tipo de aviso, el umbral está mal calibrado y hay que subirlo, no insistir.
3. Cada semana, con la operación de las sedes (45 minutos). Revisar la distribución de desviaciones por tipo y sede. Aquí es donde se descubre que el problema no era el modelo sino que la sede sur programa los retiros hospitalarios con veinte minutos de margen cuando el histórico dice cuarenta.
4. Cada mes, con dirección. Recalcular la exactitud por ventana de acción y, sobre todo, revisar si el módulo sigue cumpliendo la condición económica: ¿la intervención sigue funcionando lo suficiente como para que valga la pena avisar?
5. Cada trimestre, reentrenar y revalidar. Las duraciones cambian con el tránsito, con las sedes nuevas, con los proveedores nuevos. Un modelo de duraciones que no se revisa envejece en silencio.

6. Gobierno y límites: qué no se automatiza nunca

Este cluster tiene una regla que no se negocia y que ya desarrollamos en el artículo de gobierno de agentes de IA en el ERP: si no quieres que el agente haga algo, la herramienta para hacerlo no debe existir en su catálogo. Escribir «no lo hagas» en las instrucciones no es un control. Aplicado a la operación del día:

• El agente no reasigna nada. No mueve conductores, no cambia salas, no reprograma cremaciones, no cancela traslados. Propone y explica; la decisión y la ejecución son del coordinador. En esta industria la reasignación tiene consecuencias sobre una familia que está esperando, y eso no admite «la mayoría de las veces acierta».
• El agente no cierra un traspaso. Nunca marca un traslado como terminado ni da por recibido un cuerpo: la firma de quien recibe es un privilegio humano. Es la misma línea que trazamos en la cadena de custodia del cuerpo.
• El agente no le habla a la familia. Puede redactar el borrador del aviso; quien llama es una persona. Un deudo en duelo esperando a su padre es el peor escenario posible para una comunicación automática.
• El panel nunca pinta de verde. Este es un requisito de diseño y viene de la evidencia sobre sesgo de automatización: cuando el sistema de apoyo está equivocado, los operadores aceptan su recomendación errónea más de la mitad de las veces y sus errores por omisión aumentan de forma marcada. Un panel que declara «este servicio está bien» invita a dejar de mirarlo. El panel solo puede subir servicios a revisión; jamás bajar la guardia sobre los demás.
• Presupuesto explícito de alertas. No una por fila: un número fijo por coordinador y por turno. El metaanálisis disponible sobre alertas clínicas encuentra una tasa de descarte cercana al 90 %; un sistema que grita todo el tiempo se apaga solo, en la cabeza de quien lo usa.
• Permisos heredados y datos del doliente. El agente lee con los permisos de quien pregunta —el coordinador de la sede norte no ve la operación de la sur si su usuario tampoco la ve— y el motivo del riesgo se explica en términos operativos, sin volcar datos sensibles del fallecido ni de la familia en una notificación que va a un canal de mensajería.

7. Cómo se mide si funcionó

El indicador que hay que llevar al comité no es la exactitud del modelo. Es cuánto trabajo de revisión dejó de hacer el coordinador. La formulación viene de un trabajo sobre más de dos millones y medio de tickets de soporte, donde el sistema identificó cerca del 80 % de los casos que iban a escalar reduciendo alrededor del 80 % la carga del analista para encontrarlos. Traducido: de los treinta servicios del día, ¿cuántos tiene que abrir el coordinador para cubrir el 80 % del riesgo? Si son seis, hay producto. Si son veintidós, no lo hay.

8. Hoja de ruta de adopción

Semana 1: decidir sobre qué se alerta

• Listar los tipos de incumplimiento de la operación y estimar, para cada uno, costo de ocurrencia, costo de corrección y efectividad esperada de la corrección. Quedarse con dos o tres. El primer candidato natural es la cremación que pierde cupo: caro si ocurre, barato de corregir.
• Definir la hora comprometida y la duración esperada por tipo de servicio, aunque la primera versión sea el promedio histórico.
• Nombrar a la persona que va a mirar la lista. Sin dueño, no hay caso — el punto siguiente explica por qué.

Mes 1: medir sin predecir

• Congelar la hora comprometida en el sistema y empezar a acumular la desviación real.
• Construir la distribución de desviaciones por tipo, sede y franja. Presentarla a operaciones: este entregable solo ya cambia decisiones de programación, antes de cualquier IA.
• Publicar la lista diaria por holgura, calculada con aritmética simple, con presupuesto fijo de alertas y sin ningún semáforo verde.
• Exponer al MCP las funciones que ya detectan vencimiento, para que el agente pueda consultarlas en vez de reconstruirlas.

Trimestre 1: modelo, explicación y validación

• Con historial suficiente, entrenar un modelo de duración y de riesgo. Compararlo contra el baseline honesto: la hora agendada y el criterio del coordinador con experiencia, no contra «nada».
• Poner el agente de IA a ordenar la lista del día y a redactar el motivo y la siguiente acción sugerida, en el lenguaje de quien coordina.
• Publicar la exactitud por ventana de acción —24 horas, 6 horas, 1 hora— en la pantalla de configuración del módulo.
• Medir la efectividad de la intervención con un grupo de comparación, y volver a evaluar la condición económica con datos propios.

9. Cinco errores que se repiten

1. Empezar por el modelo. El cuello de botella no es el algoritmo: es que nunca se escribió la hora prometida. Un modelo sobre datos sin promesa es un generador de opiniones.
2. Poner un semáforo en cada fila. La condición formal de utilidad de la alarma dice que en varios escenarios lo óptimo es no alertar. Un panel con treinta luces es un panel apagado.
3. Colgar el panel del coordinador que ya está saturado. El diseño hospitalario que sí funcionó tenía un rol dedicado exclusivamente a revisar la lista de riesgo y un protocolo de escalamiento. La alerta no es la intervención: la intervención es una persona con tiempo asignado.
4. Prometer una hora exacta de finalización. Con más de un millón de casos, la mejor evidencia disponible sigue teniendo media hora de error. Se venden bandas y probabilidad de solape, no relojes.
5. Instalar y no volver a mirar. El caso del modelo de sepsis que operó años con exactitud apenas superior al azar en cientos de hospitales no es una anécdota: es el desenlace por defecto de todo modelo que se despliega sin validación externa y sin dueño.

Vale la pena cerrar con un límite de método que la propia literatura reconoce. La revisión de referencia sobre monitoreo prescriptivo señala expresamente la necesidad de validar los métodos existentes en entornos reales; el barrido de 2025 y 2026 no encontró ningún ensayo de campo publicado con efecto de intervención medido en una empresa. Además, la ganancia depende mucho de la saturación de recursos —en las evaluaciones disponibles varía por dos órdenes de magnitud según el nivel de utilización—, lo que significa algo muy concreto para un grupo funerario: esto vale mucho en la sede de treinta servicios diarios y casi nada en la de seis. Y en el sector funerario, sencillamente, no hay literatura revisada por pares sobre este problema: quien lo construya tendrá que generar su propia evidencia.

Preguntas frecuentes

¿Se puede predecir con IA qué servicio funerario se va a retrasar?

Se puede estimar el riesgo, con dos condiciones. La primera es que exista una hora comprometida congelada contra la cual medir el incumplimiento: sin ella no hay nada que predecir ni con qué entrenar. La segunda es aceptar el techo real de exactitud: la mejor evidencia disponible sobre duración de operaciones con hora comprometida, con más de un millón de casos, sigue teniendo un error medio de alrededor de media hora. Lo que sí funciona muy bien y no necesita ningún modelo es calcular la holgura: cuánto margen le queda a cada servicio antes de que el retraso sea irreversible.

¿Por qué un tablero de alertas puede empeorar la operación?

Por dos razones documentadas. La primera es el descarte: la evidencia sobre alertas en sistemas de apoyo a la decisión muestra tasas de rechazo cercanas al 90 %, de modo que un panel que avisa de todo deja de leerse. La segunda, más seria, es el sesgo de automatización: cuando el sistema se equivoca, los operadores aceptan su recomendación errónea más de la mitad de las veces y cometen más errores que sin apoyo. Por eso el panel debe tener un presupuesto fijo de alertas y no debe declarar nunca que un servicio está bien.

¿Qué datos necesita un ERP funerario para anticipar incumplimientos?

Cuatro cosas, en este orden: la hora comprometida con la familia guardada de forma inmutable; la duración esperada por tipo de servicio; el historial de cambios de estado con su marca de tiempo —que en muchos sistemas ya se está grabando sin que nadie lo aproveche—; y el registro de uso del propio sistema, que según la evidencia hospitalaria puede ser una señal predictiva por sí misma. La geolocalización del vehículo ayuda mucho en traslados, pero no es el punto de partida.

¿El agente de IA puede reasignar una carroza o mover una velación?

No, y no por prudencia retórica: por diseño. La herramienta de reasignación no debe existir en el catálogo del agente, porque prohibir por instrucción no es un control. El agente ordena la lista, explica por qué un servicio está en riesgo y propone la alternativa; el coordinador decide y ejecuta. Tampoco cierra traspasos ni se comunica con la familia.

¿Cómo se justifica este proyecto ante la dirección?

Con una sola métrica: cuántos de los servicios del día tiene que revisar el coordinador para cubrir el 80 % del riesgo. Es entendible, es auditable y le habla a la dirección de operaciones. La exactitud del modelo es un dato técnico intermedio; el ahorro de revisión es el resultado. Y conviene decir de entrada que el costo de las correcciones va a subir al principio: si no sube, es que nadie está actuando sobre las alertas.

¿Qué puede hacer hoy SFUN y qué es hoja de ruta?

Hoy el sistema detecta en vivo los traslados y las velaciones cuya hora de fin ya pasó, calcula el porcentaje de ventana consumida de cada velación, deriva el estado de todos los servicios abiertos de forma económica, encadena traslados y expone la operación al MCP para consulta con permisos heredados. No tiene ningún componente predictivo, ni compromiso horario congelado, ni notificación proactiva de operación, ni informes de cumplimiento del servicio. Todo lo que este artículo describe como predicción, alerta anticipada y priorización automática es hoja de ruta declarada, y las brechas concretas están enumeradas más arriba.

Referencias

• I. Teinemaa, N. Tax, M. de Leoni, M. Dumas y F. M. Maggi, Alarm-Based Prescriptive Process Monitoring, BPM Forum 2018, DOI 10.1007/978-3-319-98651-7_6: establece la condición formal de utilidad de la alarma y muestra escenarios donde el óptimo es no alertar nunca: arxiv.org/abs/1803.08706.
• S. A. Fahrenkrog-Petersen, N. Tax, I. Teinemaa, M. Dumas, M. de Leoni, F. M. Maggi y M. Weidlich, Fire Now, Fire Later: Alarm-Based Systems for Prescriptive Process Monitoring, arXiv 1905.09568: el efecto de retrasar el disparo de la alarma hasta tener confirmaciones adicionales, y por qué en la mayoría de los casos no cambia el resultado: arxiv.org/abs/1905.09568.
• I. Teinemaa, M. Dumas, M. La Rosa y F. M. Maggi, Outcome-Oriented Predictive Process Monitoring: Review and Benchmark, ACM TKDD 13(2), 2019, DOI 10.1145/3301300: el benchmark de referencia; muestra que la exactitud crece con el avance del caso y es máxima cuando ya no queda margen de acción: arxiv.org/abs/1707.06766.
• Y. Jiao, B. Xue, C. Lu, M. S. Avidan y T. Kannampallil, Continuous real-time prediction of surgical case duration using a modular artificial neural network, British Journal of Anaesthesia, 2022, DOI 10.1016/j.bja.2021.12.039: predicción a una hora de anticipación del desborde de turno, con el baseline de la duración agendada: bjanaesthesia.org.
• S. Kendale, A. Bishara, M. Burns, S. Solomon, M. Corriere y M. Mathis, Machine Learning for the Prediction of Procedural Case Durations Developed Using a Large Multicenter Database, JMIR AI, 2023, DOI 10.2196/44909: el techo de exactitud de la duración con 1.177.893 procedimientos: ai.jmir.org.
• D. J. Bartek y otros, Improving Operating Room Efficiency: Machine Learning Approach to Predict Case-Time Duration, Journal of the American College of Surgeons, 2019, DOI 10.1016/j.jamcollsurg.2019.05.029: la ganancia del aprendizaje automático sobre el estándar histórico, del 32 % al 39 % de casos dentro del ±10 %: journals.lww.com.
• G. J. Escobar, V. X. Liu, A. Schuler, B. Lawson, J. D. Greene y P. Kipnis, Automated Identification of Adults at Risk for In-Hospital Clinical Deterioration, New England Journal of Medicine, 2020, DOI 10.1056/NEJMsa2001090: el diseño donde la alerta va acompañada de un rol dedicado a revisarla y de un protocolo de respuesta: nejm.org.
• A. Wong y otros, External Validation of a Widely Implemented Proprietary Sepsis Prediction Model in Hospitalized Patients, JAMA Internal Medicine, 2021, DOI 10.1001/jamainternmed.2021.2626: el modelo propietario desplegado en cientos de hospitales con discriminación de 0,63, dos tercios de casos no detectados y alerta en el 18 % de las hospitalizaciones: jamanetwork.com.
• D. Lyell, F. Magrabi, M. Z. Raban, L. G. Pont, M. T. Baysari y R. O. Day, Automation bias in electronic prescribing, BMC Medical Informatics and Decision Making, 2017, DOI 10.1186/s12911-017-0425-5: el apoyo correcto reduce errores de omisión y el incorrecto los aumenta, con aceptación de la recomendación errónea por encima del 50 %: bmcmedinformdecismak.biomedcentral.com.
• H. Felisberto y otros, Override rate of drug-drug interaction alerts in clinical decision support systems: a brief systematic review and meta-analysis, Health Informatics Journal, 2024, DOI 10.1177/14604582241263242: prevalencia de descarte de alertas cercana al 90 %: journals.sagepub.com.
• C. Fertig, L. Kirchdorfer y M. Sesterhenn, Revisiting Predictive Process Monitoring in the Age of Foundation Models, arXiv 2607.27797 (julio de 2026): los modelos de secuencia superan a los modelos de lenguaje en la predicción de la próxima actividad, con tiempos de ejecución mucho menores: arxiv.org/abs/2607.27797.
• L. Montgomery, Escalation Prediction using Feature Engineering: Addressing Support Ticket Escalations within IBM's Ecosystem, arXiv 2010.06390: la métrica correcta es la reducción de la carga de revisión del analista, no la exactitud del modelo: arxiv.org/abs/2010.06390.
• A. E. Hızır, C. Barnhart y V. Vaze, Large-Scale Airline Crew Recovery Using Mixed-Integer Optimization and Supervised Machine Learning, Transportation Science, 2026, DOI 10.1287/trsc.2025.0105: la interpretabilidad como condición de confianza del operador en la recuperación de una operación crítica. La compañía no publica el ahorro puntual: pubsonline.informs.org.
• K. Kubrak, F. Milani, A. Nolte y M. Dumas, Prescriptive process monitoring: Quo vadis?, PeerJ Computer Science, 2022, DOI 10.7717/peerj-cs.1097: la revisión que señala la falta de validación en entornos reales, todavía vigente: peerj.com.
• D. Neira-Rodado, J. Paz-Roa, J. W. Escobar y M. Ortiz-Barrios, A novel machine learning approach for spatiotemporal prediction of EMS events: a case study from Barranquilla, Colombia, Heliyon, 2025, DOI 10.1016/j.heliyon.2025.e41904: predicción espacio-temporal de demanda de emergencias en una ciudad de la región, aplicable al pre-posicionamiento de flota: cell.com/heliyon.
• Model Context Protocol — especificación de herramientas y prácticas de seguridad, incluida la persona en el circuito con capacidad de denegar la invocación: modelcontextprotocol.io.