Slotback
Huecos de citas hospitalarias liberados, devueltos a la lista de espera en el orden del hospital, con pruebas.
Resumen
Despliegue de principio a fin de un agente de voz con IA para un hospital público español ficticio, Hospital General (ficticio), parte de un servicio regional de salud en España: desde la investigación de la cuenta y el caso de negocio hasta un sistema que funciona, una barrera de evaluaciones, llamadas reales grabadas y un plan piloto. Un despliegue de referencia independiente, con datos sintéticos.
De un vistazo
- 14 de 14huecos liberados recolocados desde la lista de espera, en su ordenSimulado · un día sintético de consultas
- 14 frente a 3,7huecos liberados recolocados: circuito de voz frente a solo recordatorios por SMS. Descontando los que el personal habría recolocado, 9 son facturablesSimulado · un día sintético
- 3,54 €coste de plataforma por hueco recolocado (5,51 € por hueco facturable); sin telefonía ni integraciónSimulado
- 15/15 · 0escenarios de la barrera superados · fugas de privacidad: 12 pruebas de herramientas contra Postgres real y 3 conversaciones de texto simuladasEvaluaciones
- 2 llamadasllamadas reales grabadas; la primera encontró 4 errores que las simulaciones no vieronLlamadas reales
- 1.707eventos en el registro, verificables de forma independienteSimulado · día sintético
El problema
En la sanidad pública española, los pacientes faltan a citas de especialista. Las tasas de ausencia van del 5,75 % (Galicia, 2024) al 14,6 % (estudio de 2011), según la región y el año. En el caso mejor documentado, un estudio de 2013–14 en un área sanitaria de Andalucía, se perdió el 13,8 % de 400.761 citas, con un coste de unos 61 € por consulta perdida, y el 46 % de las ausencias se debía a olvidos o a avisos que nunca llegaron. Son referencias de otras regiones, no resultados de Slotback.
Las llamadas de recordatorio funcionan, pero el personal de admisión no puede hacer suficientes, y un hueco liberado el día anterior es difícil de recolocar a tiempo. El SMS es más barato contra el olvido, pero la mayoría de los recordatorios van en un solo sentido: aunque el paciente pueda cancelar respondiendo, el mensaje no puede pasar el hueco a la siguiente persona de la lista de espera.
La idea: no construir un recordatorio mejor, sino el circuito que el SMS no puede cerrar: confirmar, recoger la cancelación y recolocar el hueco desde la lista de espera antes del día, en el orden del hospital.
Qué construí
Un agente de voz saliente en ElevenLabs Agents llama a los pacientes unos días antes de su cita de especialista para confirmarla, cancelarla o cambiarla. Cuando se libera un hueco, llama a la lista de espera del hospital estrictamente en orden y ofrece el hueco, reservándolo 10 minutos para cada persona. Cada paso queda escrito en un registro firmado y encadenado por hash que el hospital o un auditor pueden verificar.
Mi papel
Llevé todo el ciclo de despliegue sobre un único problema, no solo la demo de voz.
- Investigación de la cuenta. Dimensionado del problema con cifras públicas con fuente, un mapa de actores (dirección del hospital, jefatura de admisión, sistemas, delegado de protección de datos, comité de empresa, defensa del paciente) y desencadenantes de compra.
- Descubrimiento. Guías de entrevista por actor, un mapa del proceso actual de admisión y las métricas base que hay que pedir.
- Priorización de casos de uso. Seis candidatos puntuados por valor, viabilidad y riesgo. El triaje clínico quedó fuera por riesgo para la seguridad del paciente.
- Caso de negocio y modelo comercial. Un modelo de ROI interactivo; precio por hueco recuperado verificado (por resultado) frente a por minuto; una vía de contratación pública (un pequeño contrato piloto por debajo del umbral del contrato menor y después una licitación abierta) con un borrador de pliego técnico en español. Caso de negocio ↗ · Pliego técnico ↗
- Diseño de la solución y cumplimiento. Arquitectura, seguridad, modos de fallo, correspondencia con FHIR R4 y un borrador de EIPD. RGPD art. 6.1.e y 9.2.h, transparencia del art. 50 del AI Act, y un diseño pensado para quedar fuera del ámbito de alto riesgo del anexo III. Alojamiento de producción en la UE con conformidad ENS, sin transferencias fuera de la UE, y un tope de precio que mantiene el piloto por debajo del límite del contrato menor. Diseño de la solución ↗ · Borrador de EIPD ↗
- Prototipo. El sistema que funciona (tecnología abajo).
- Evaluaciones. Una barrera de publicación con comprobaciones deterministas, un detector de fugas y pruebas de conversación en vivo. Método de evaluación ↗
- Llamadas reales. Grabadas, revisadas línea a línea y con los errores corregidos el mismo día. Llamadas de demo ↗
- Plan piloto. 90 días, una especialidad, un grupo de control solo con SMS, criterios de continuar o parar y un interruptor de emergencia. Plan piloto de 90 días ↗
- Informe ejecutivo. Unas 10 diapositivas y una nota para la dirección del hospital, primero en español. Informe (ES) ↗ · Informe (EN) ↗
- Feedback al equipo de producto. Notas de campo para el equipo de producto de la plataforma, por ejemplo sobre reconocimiento de voz de personas mayores en español, detección de buzón de voz y conectores con sistemas de información hospitalarios. Notas de campo ↗
Decisiones de diseño clave
Dónde está el criterio.
El agente nunca decide la prioridad.
Solo ofrece los huecos liberados en el orden de la propia lista del hospital, y nunca reordena, puntúa ni elimina a nadie. Un bloqueo solo detiene las llamadas automáticas y avisa al personal de admisión, que hace el seguimiento. El diseño busca quedar fuera del uso de alto riesgo del AI Act para el acceso a servicios públicos; necesita revisión jurídica antes de un piloto. El registro muestra que cada oferta coincidió con la copia de la lista tomada al liberarse el hueco.
Pago por resultado verificado.
Un hueco solo es facturable si el agente lo recolocó, el paciente acudió y coincide con el registro de citas del propio hospital, descontando lo que el personal habría recolocado de todos modos.
Las salvaguardas viven en el código, no solo en el prompt.
Cada llamada lleva un token ligado a un único paciente, y la identidad (fecha de nacimiento y parte del DNI) se comprueba en el servidor antes de revelar nada; incluso la especialidad cuenta como dato de salud. Dos intentos fallidos terminan la llamada y tres llamadas fallidas en 24 horas bloquean al paciente. A un buzón de voz o a un familiar solo se le deja un número de contacto, y las preguntas médicas pasan a una persona. En la primera llamada real, el servidor rechazó una acción que el agente no debía hacer: la salvaguarda aguantó aunque el prompt estuviera mal.
Un registro a prueba de manipulaciones.
Una cadena SHA-256 por día con una cabecera firmada con Ed25519. Un verificador de línea de comandos comprueba cuatro cosas: la cadena está intacta, la identidad se verificó antes de cualquier detalle, las ofertas siguieron el orden de la lista y la cabecera está firmada. Si se cambia un evento, la verificación falla exactamente en esa línea.
Configuración como código.
Fragmentos de prompt que se combinan en cuatro perfiles de agente (demo y referencia de producción, saliente y entrante). Los esquemas de herramientas se generan desde los modelos de la API, y la integración continua falla si la configuración se desvía.
Su parte reutilizable se convirtió en un kit.
El registro, las salvaguardas, la barrera de publicación, las comprobaciones de despliegue y la revisión de llamadas pasaron a voiceops, un kit de código abierto, sin cambiar el comportamiento de Slotback; después, un segundo despliegue entró en producción con él.
Cada número tiene procedencia.
SIMULATED, BENCHMARK, SYNTHETIC, MEASURED o ASSUMPTION, llevado desde un único registro a cada documento y página.
Escúchalo
Llamadas reales.
Dos llamadas reales por Twilio a mi propio teléfono. Yo hago de paciente sintético. El agente habla en español. Cada llamada empieza con un breve aviso en inglés de la cuenta de prueba de Twilio antes de que hable el agente.
El flujo completo: aviso de IA → comprobación de identidad → lee la cita → ofrece tres huecos → repite los datos → la mueve en el sistema en vivo → declina una pregunta médica (“¿tengo que ir en ayunas?”) y agenda una llamada de admisión → cuelga por sí solo.
Las 15 evaluaciones simuladas habían pasado. La primera llamada real aun así encontró cuatro problemas: una voz inglesa leyendo español, una llamada de confirmación tratada como oferta de lista de espera, una “transferencia” que no existía y ninguna forma de colgar. Los cuatro se corrigieron el mismo día; la llamada 02 es el resultado.
Evaluaciones: una barrera de publicación, no una demo Simulado
- Barrera superada, 15/15 (simulado): 12 escenarios a nivel de herramienta contra Postgres real (ingeniería social, inyección de prompt, dos pacientes compitiendo por un hueco, una aceptación tardía tras caducar la reserva, bloqueo, buzón de voz, número equivocado, baja voluntaria, cancelar y recolocar en orden) y 3 escenarios de conversación en ElevenLabs Tests contra el agente en vivo, como conversaciones de texto simuladas (un paciente mayor con problemas de audición, un paciente enfadado, un cambio al rumano).
- Mis propias comprobaciones deterministas se ejecutan en cada transcripción, porque el juez de la plataforma es solo orientativo: la IA se presenta primero, y un detector de fugas de privacidad (español, inglés, rumano y árabe) debe detectar 16/16 fugas sembradas sin falsas alarmas antes de que su resultado de “0 fugas” cuente.
- Un escenario que no se ejecutó nunca cuenta como superado: PASS, FAIL o ERRORED.
- Lo que encontraron las evaluaciones: a un llamante enfadado no se le ofrecía una persona, así que corregí la estructura del prompt. Lo que solo encontraron las llamadas reales: los cuatro errores de la llamada 01. Las simulaciones son necesarias, no suficientes.
Resultados en un día sintético de consultas Simulado
| Citas / llamadas de confirmación | 400 / 400 |
|---|---|
| Llamadas contestadas | 68,5 % |
| Huecos liberados por una cancelación durante la llamada | 14 |
| Recolocados desde la lista de espera, en su orden | 14 (mediana 11 min) |
| Facturables tras asistencia y línea base del personal | 9 |
| Contrafactual solo con SMS | 3,7 |
| Infracciones de identidad antes de detalle halladas por el verificador del registro | 0 |
| Coste de plataforma estimado por hueco recolocado (por hueco facturable) | 3,54 € (5,51 €) |
El plan piloto de 90 días es como estos números pasarían a ser medidos: una especialidad con muchas ausencias, frente a un grupo de control solo con SMS, con criterios de continuar o parar y un interruptor de emergencia.
Arquitectura
Tecnología
- Python 3.12
- uv
- FastAPI
- PostgreSQL (psycopg 3)
- Panel Jinja2 + JS sin frameworks (EN/ES)
- ElevenLabs Agents (voz, herramientas, Tests API, webhooks)
- Twilio
- Cadena SHA-256 + firmas Ed25519
- pytest + pruebas de propiedades con Hypothesis (117 pruebas)
- Ruff
- GitHub Actions CI
- Docker
- Render (UE)
- Hugging Face Spaces
Pantallas
Pantallas del panel en vivo, con un día sintético de consultas.
Qué haría después
- Medir la latencia a nivel de voz (por ahora solo se mide la de las pruebas de texto).
- Calibrar el juez integrado de la plataforma con unas 20 transcripciones etiquetadas a mano.
- Hacer el piloto real de 90 días: la única forma de que los números simulados pasen a ser medidos.
Hospital ficticio, solo datos sintéticos. Las cifras de rendimiento de Slotback son simuladas y están marcadas como tales. Las cifras públicas son referencias de otras regiones españolas, con fuente y año. Fuentes: Jabalera Mesa (2015), tesis doctoral, Universidad de Málaga, datos de 2013–14; cifras de Galicia de 2024 (noticia de prensa, enero de 2025); Pereira-Victorio et al. (2016), datos de agosto de 2011. ElevenLabs es la plataforma de agentes de voz utilizada; es un proyecto independiente, sin respaldo ni patrocinio de ElevenLabs.
Siguiente proyectovoiceops