Victor Arias
ZEKI es un chatbot médico que atiende consultas 24/7 sobre un backend en la nube en AWS: entiende la pregunta en lenguaje natural, responde con su base de conocimiento, deriva a una persona cuando el caso lo requiere y escala solo cuando entra más gente. El servicio quedó disponible a todas horas y redujo un 60% las consultas que antes se atendían a mano.
| Cliente | ZEKI |
| Sector | Salud digital |
| Servicio | Servicios Cloud |
| Tecnologías | AWS, Chatbot con IA de lenguaje natural, Backend en la nube, Base de conocimiento, Derivación a un humano, Escalado automático, Historial y métricas |
| Duración | 1-2 meses |
| Nuestro rol | Infraestructura y backend en la nube sobre AWS para el chatbot: IA de lenguaje natural, base de conocimiento, derivación a un humano, escalado automático e historial con métricas. |
| Publicado | 14 de diciembre de 2022 |
Una consulta de salud no respeta el horario de oficina: llega de noche, en fin de semana y en momentos en los que no hay nadie para contestar. Y casi siempre es la misma pregunta, repetida cientos de veces, que es justo el terreno donde un chatbot aporta de verdad.
ZEKI es un chatbot médico montado sobre un backend en la nube en AWS: entiende la consulta en lenguaje natural, responde con su base de conocimiento, deriva a una persona cuando el caso lo requiere y escala solo cuando entra más gente. El servicio quedó disponible 24/7 y redujo un 60% las consultas que antes se atendían a mano.
El reto: consultas que no llegan en horario de oficina
En atención sanitaria el volumen no se reparte como la jornada laboral. Las dudas aparecen cuando el paciente las tiene, y si nadie contesta en ese momento, la consulta se pierde o se acumula para el día siguiente. Es un problema de disponibilidad, no de personal.
La demanda no es constante
Hay horas punta y horas muertas, y ninguna coincide necesariamente con el equipo disponible. Dimensionar para el pico significa pagar capacidad parada el resto del tiempo; dimensionar para la media significa caerse justo cuando más consultas entran.
Un chatbot no puede inventarse respuestas
En salud, una respuesta inventada es peor que no responder. El chatbot tiene que ceñirse a la información que el equipo ha validado y, cuando la consulta se sale de ahí, reconocerlo en lugar de improvisar. Esa frontera es la que separa un asistente útil de un problema.
Cuando el caso se complica, hace falta una persona
Ningún flujo automático cubre todos los casos, y no debe intentarlo. Lo importante es que la conversación llegue a una persona con todo el contexto: qué ha preguntado el paciente y qué se le ha respondido ya, para no obligarle a empezar de cero.
La solución: chatbot con IA sobre AWS
El chatbot se montó sobre AWS, con la infraestructura preparada para escalar según la demanda y el historial de conversaciones guardado para revisarlo. El trabajo se centró en lo que sostiene el servicio: la base de conocimiento, la derivación a personas y las métricas para saber qué se resuelve solo.
El paciente pregunta cuando tiene la duda: la disponibilidad es la primera parte del servicio.
Lenguaje natural y base de conocimiento
El chatbot entiende la pregunta tal como se escribe, sin obligar al paciente a elegir entre menús rígidos, y responde con la información que el equipo mantiene validada. La base de conocimiento es lo que permite corregir una respuesta en un solo sitio y que el cambio valga para todas las conversaciones siguientes.
Derivación a un humano sin perder el contexto
Cuando la consulta se sale de lo previsto, la conversación pasa a una persona con el historial delante. El paciente no repite lo que ya contó y quien atiende no empieza a ciegas, que es lo que suele romper la experiencia en los chatbots mal resueltos.
Escalado automático e historial
La infraestructura en AWS crece cuando entra más gente y baja cuando se marcha, así que el pico de consultas no se convierte en una caída. El historial de conversaciones y el panel de métricas muestran qué se pregunta, qué se resuelve solo y dónde se está derivando de más.
Cómo lo implementamos en uno a dos meses
El proyecto empezó por las preguntas, no por la tecnología: qué consultas llegan, cuáles se repiten y cuáles no puede responder el sistema. Con esa lista se construyó la base de conocimiento y se decidió cuándo hay que derivar a una persona.
El objetivo no es sustituir la atención, sino que llegue a la persona solo lo que necesita una persona.
Empezar por las preguntas reales
Antes de montar el chatbot se revisaron las consultas que ya llegaban al equipo: las repetidas, las urgentes y las que no admiten respuesta automática. Esa clasificación define qué entra en la base de conocimiento y qué se deriva desde el primer mensaje.
Medir cuántas consultas se resuelven solas
La métrica que importa no es cuántas conversaciones abre el chatbot, sino cuántas cierra sin intervención. Se siguió desde el principio junto al porcentaje de derivaciones, para ajustar la base de conocimiento en lugar de dar por bueno el resultado inicial.
Resultados
El servicio se entregó con el chatbot en marcha sobre AWS, la base de conocimiento cargada y la derivación a personas funcionando. Estas fueron las necesidades y cómo se resolvieron:
| Necesidad | Cómo se resolvió |
| Atender consultas fuera del horario de oficina | Chatbot disponible 24/7 sobre la infraestructura en AWS |
| Entender la pregunta tal como la escribe el paciente | IA de lenguaje natural, sin menús rígidos |
| Responder sin improvisar | Base de conocimiento validada y mantenida por el equipo |
| Resolver los casos que el chatbot no cubre | Derivación a una persona con el contexto de la conversación |
| Aguantar los picos de consultas | Escalado automático en la nube |
Los resultados medidos del proyecto: disponibilidad 24/7 y un 60% menos de consultas atendidas a mano. Los dos datos son el mismo: lo que el chatbot resuelve solo deja de ocupar al equipo, que se queda con lo que de verdad necesita una persona.
Qué necesita un chatbot de atención
Si quieres atender consultas sin depender del horario, estos son los puntos que deciden si el chatbot ayuda o estorba:
- Disponibilidad real 24/7, que es lo que cubre las consultas que hoy se quedan sin respuesta.
- Lenguaje natural, para que el paciente pregunte como pregunta y no como el sistema espera.
- Una base de conocimiento validada, mantenida por el equipo y corregible sin tocar el motor del chatbot.
- Derivación a una persona con contexto, sin obligar al paciente a repetir lo que ya contó.
- Infraestructura que escale sola, para que el pico de consultas no se convierta en una caída.
- Historial y métricas, para saber qué se pregunta, qué se resuelve solo y dónde se deriva de más.
Si quieres atender consultas a todas horas sin multiplicar el equipo, en la página de servicios cloud contamos cómo trabajamos, y puedes escribirnos para revisarlo juntos.
Preguntas frecuentes
¿Qué puede resolver un chatbot médico y qué no?
Resuelve lo repetitivo: horarios, preparación de pruebas, dudas frecuentes y trámites, que es donde se va la mayor parte del tiempo de atención. No diagnostica ni sustituye a un profesional: cuando la consulta se sale de lo previsto, el chatbot tiene que pasar la conversación a una persona en lugar de improvisar una respuesta.
¿Por qué un chatbot de salud necesita la nube?
Porque la demanda no es constante: se concentra fuera del horario de oficina, en campañas y en momentos concretos, y un servidor fijo obliga a dimensionar para el peor día. La nube permite escalar automáticamente cuando entra más gente y volver a bajar después, sin pagar por capacidad que solo se usa unas horas.
¿Qué aporta una base de conocimiento en un chatbot?
Que las respuestas se mantengan en un solo sitio y se puedan corregir sin tocar el motor del chatbot. Es lo que evita que el sistema aprenda de cualquier manera: el equipo revisa qué se pregunta y ajusta la información, así que mejorar el chatbot es editar respuestas, no rehacer el desarrollo.
¿Cuánto tarda poner en marcha un chatbot de atención?
Este proyecto se entregó en uno a dos meses. El calendario lo marcan la base de conocimiento, la integración con la nube, la derivación a personas y el historial con métricas para ver qué consultas se resuelven solas.
