Desarrollo de un Agente IA para Clínicas de Fisioterapia: Arquitectura, Integraciones y Coste Real

Lee también: Si estás validando la parte funcional antes de la técnica, revisa nuestra guía de agente IA para fisioterapia con métricas de negocio y ROI.

Por qué un agente propio y no un bot de plantilla

Una clínica de fisioterapia recibe entre 40 y 90 solicitudes por WhatsApp cada día: citas nuevas, cambios de hora, dudas sobre bonos, envío de recibos, preguntas sobre ejercicios de casa. Un bot de plantilla con botones y árbol de decisión resuelve el 12% de esos flujos y agrava el resto: el paciente escribe libre, el bot no entiende, la conversación se estanca y termina cayendo al humano con el contexto perdido.

El desarrollo de un agente IA personalizado para clínicas de fisioterapia parte de la premisa contraria. El agente entiende lenguaje natural, mantiene el contexto de sesión, consulta el software de gestión en tiempo real y solo escala al humano cuando el mensaje contiene señales clínicas o el paciente lo pide expresamente. Según el informe Emitrr 2026, el 68,8% de las clínicas asistenciales cree que la IA reduce carga operativa; el matiz importa: reduce carga siempre que esté integrada con el sistema de historia clínica, no como capa aparte.

La diferencia técnica es medible. Un bot de plantilla resuelve entre 12 y 18 intents. Un agente IA personalizado sobre modelo generalista con RAG sobre la base de conocimiento de la clínica resuelve entre 82 y 91 intents únicos, con contención media del 87% de las conversaciones sin intervención humana en los datos de nuestras seis clínicas en producción durante el segundo trimestre de 2026.

Antes de entrar en la arquitectura conviene fijar tres restricciones no negociables: latencia por debajo de 4 segundos para el 95% de respuestas, integración bidireccional con el software clínico y trazabilidad completa de cada mensaje para auditoría RGPD. Todo lo demás se puede iterar.

Arquitectura por capas: los seis bloques del agente

El desarrollo de un agente IA para clínicas de fisioterapia se estructura en seis capas independientes y desplegables por separado. Ese es el patrón que aplicamos en nuestras implementaciones de CRM wellness y el que sostiene la fiabilidad en producción.

Capa 1: canal (WhatsApp Business API)

El agente conversa por WhatsApp Business API oficial de Meta, nunca por la app gratuita ni por librerías no oficiales. Se conecta al número existente de la clínica mediante un BSP (Business Solution Provider) o directamente con Cloud API. Los mensajes entrantes viajan por webhook HTTPS con verificación de firma HMAC-SHA256 hacia el orquestador. Coste por conversación iniciada por usuario en España: 0,0079 euros al momento de escribir este artículo.

Capa 2: orquestador de eventos

Un servicio ligero (Node.js o Python, típicamente sobre Cloud Run o Fly.io) recibe el webhook, deduplica, normaliza el payload, resuelve la sesión del paciente y encola el evento en una cola con reintentos. Aquí implementamos el patrón claim-check para no arrastrar payloads grandes por toda la pipeline.

Capa 3: motor conversacional

La lógica de conversación combina un LLM (Claude Sonnet o similar) con un router de intents ligero. El router clasifica el mensaje en menos de 40 ms y decide si el LLM debe generar respuesta, si hay que ejecutar una tool call o si la conversación se cierra con una plantilla aprobada.

Capa 4: memoria y RAG

Dos capas de memoria: una de corto plazo (últimos 20 turnos por paciente, en Redis con TTL de 72 horas) y una de largo plazo (embeddings de historia clínica, protocolos de ejercicios y FAQ de la clínica, en pgvector). El RAG se dispara solo cuando el router detecta preguntas fuera de intents transaccionales.

Capa 5: integraciones

Cada acción del agente (crear cita, mover cita, cobrar bono, enviar recibo) es una tool call tipada contra el software clínico. Detallamos las integraciones más habituales en el siguiente apartado.

Capa 6: observabilidad

Cada turno de conversación emite un span de OpenTelemetry con paciente, intent, latencia por capa, tokens consumidos y tool calls disparadas. Los spans se envían a Grafana Tempo, y los KPIs conversacionales a Grafana Cloud. Sin esta capa, cualquier debugging en producción es adivinar.

Integraciones críticas: software de gestión, agenda y WhatsApp Business API

El 80% del valor del agente está en las integraciones. Un agente que responde bonito pero no reserva citas es un juguete. En una clínica de fisioterapia real la lista mínima de integraciones bidireccionales es esta:

• Software de gestión clínica: ClinicCloud, FisioAyuda, Nubimed, Doctoralia PRO o desarrollos internos. La integración se hace por API REST cuando existe (ClinicCloud y Nubimed la tienen); en su defecto, se implementa un adaptador con scraping controlado y colas de reintentos exponenciales.
• Agenda: lectura de huecos por fisioterapeuta y por box, escritura de citas con motivo, duración variable (30, 45, 60 minutos), campo libre para observaciones y bloqueos automáticos por sesión doble.
• Historia clínica: lectura solo de campos necesarios (última visita, plan de tratamiento activo, bonos restantes). Escritura no. La escritura de campos clínicos siempre pasa por un fisioterapeuta.
• Pasarela de pago: Stripe o Redsys para cobros de bonos y confirmaciones con depósito. El agente envía un link de pago y actualiza el estado de la cita cuando el webhook de la pasarela confirma el cobro.
• WhatsApp Business API: plantillas HSM aprobadas para recordatorios (24 h y 2 h antes), botones interactivos para confirmar o reprogramar y sesión de conversación en ventana de 24 horas para el resto.
• Facturación: Holded o Sage para emitir factura simplificada cuando se cobra un bono. Enviamos el PDF por WhatsApp adjuntando el media_id.

Cada integración se implementa como tool JSON schema con validación estricta de entradas y salidas. Ejemplo real del schema de reservar_cita: paciente_id (uuid), fisio_id (uuid), fecha (ISO 8601), duracion_minutos (enum 30, 45, 60), motivo (enum de 12 valores), notas (string, opcional, max 240 caracteres). Cualquier salida del LLM que no valide contra el schema se descarta y se solicita reintento con el mensaje de error del validador. Este contrato duro entre LLM y sistema clínico es lo que evita el 97% de las alucinaciones que colisionarían con la agenda real.

Motor conversacional: intents, contexto clínico y guardarraíles

El motor conversacional del agente no es un simple wrapper del LLM. Tiene tres piezas separadas por razones de coste y seguridad.

Router de intents ligero

Un clasificador entrenado sobre un embedding pequeño (distiluse o e5-small) resuelve la intención del mensaje en menos de 40 ms. Los 14 intents principales cubren el 92% del tráfico real medido en clínicas de 2 a 6 fisioterapeutas: reservar, reprogramar, cancelar, consultar hueco, comprar bono, pedir factura, precios, ubicación, tratamientos ofrecidos, primera visita, seguro médico, urgencia, saludar, otros. Solo el intent "otros" y "urgencia" activan LLM completo. El ahorro en llamadas al modelo es de 62 a 78% en volumen respecto a mandar todo al LLM.

LLM con tool calling

Para los intents que requieren generación, el agente llama al LLM con las tools disponibles filtradas por intent (no le pasamos las 22 tools cuando el intent es "reservar"; le pasamos las tres relevantes). Esto reduce tokens de prompt en 40% y mejora la precisión del tool calling.

Guardarraíles clínicos

Cinco reglas fijas en la capa por encima del LLM: si el mensaje contiene palabras de urgencia médica (dolor 10, no puedo mover, adormecimiento, mareo, pérdida de fuerza), el agente responde con protocolo definido por el fisioterapeuta responsable y escala inmediatamente. Nunca da consejos clínicos concretos, nunca modifica pautas de tratamiento y nunca envía facturas sin cobro confirmado. Esto último se implementa como assertion en el orquestador, no como instrucción en el prompt del LLM. Las instrucciones en prompt se saltan; las assertions no.

Fiabilidad, latencia y observabilidad

Un agente médico o paramédico caído es una crisis operativa, no un aviso de Slack. Diseñamos con tres SLOs vivos que se revisan cada lunes:

• Disponibilidad del webhook de WhatsApp: 99,9% mensual. Traduce a 43 minutos de downtime al mes. Se sostiene con doble región activo-pasivo y health checks cada 20 segundos.
• Latencia p95 de respuesta: por debajo de 4 segundos desde que llega el webhook hasta que sale la respuesta a WhatsApp. p99 por debajo de 8 segundos. Cuando se rompe el p99 dispara un runbook automático de degradación: el agente pasa a plantilla estática y notifica al on-call.
• Tasa de escalado no deseado: por debajo del 15% (mensajes que el agente escala al humano cuando podría haber respondido). Se mide semanalmente sobre una muestra de 200 conversaciones etiquetadas por un fisioterapeuta.

La observabilidad va más allá de logs. Cada conversación se serializa como un trace con spans por intent, por tool call, por invocación al LLM y por respuesta enviada. Esto permite reproducir cualquier conversación fallida en menos de 90 segundos y ejecutar el mismo flujo en staging con el prompt corregido. Sin esa capacidad de replay, iterar sobre el agente en producción es dispararse en el pie.

Seguridad y RGPD: cómo manejar datos de salud sin regarla

Un dato de fisioterapia es un dato de salud según artículo 9 del RGPD. El desarrollo del agente asume esa restricción desde el primer commit.

• Base legal explícita: el consentimiento para tratamiento por IA se pide en la primera conversación mediante plantilla HSM aprobada y se registra con timestamp y hash del mensaje. Si el paciente no acepta, el agente le pasa al humano.
• Cifrado: datos en tránsito con TLS 1.3 y datos en reposo con AES-256 gestionado por KMS. Ninguna PII se guarda en claro en logs ni en Redis.
• Minimización: el LLM recibe el mínimo de contexto necesario. Nombre y motivo bastan para la mayoría de intents; historia clínica completa solo se recupera cuando el fisioterapeuta lo solicita desde el panel interno.
• Retención: conversaciones borradas a los 12 meses por defecto, salvo instrucción contraria del responsable del tratamiento. Facturas y registros contables por el plazo legal.
• Contrato con el proveedor del LLM: se firma DPA con opt-out de entrenamiento con los datos enviados. Sin ese DPA no se despliega.

El registro de actividades de tratamiento se actualiza con el flujo del agente y se documenta la evaluación de impacto (EIPD). En clínicas grandes esto lo lleva un DPO externo; en clínicas pequeñas lo dejamos empaquetado con un runbook y una plantilla editable de la Agencia Española de Protección de Datos.

Coste real de desarrollo y cronograma de cinco semanas

El desarrollo llave en mano de un agente IA para una clínica de fisioterapia con tres a seis fisioterapeutas se ubica entre 4.900 y 8.500 euros de setup, más una cuota mensual de operación entre 297 y 497 euros que cubre modelo, WhatsApp Business API, hosting, observabilidad y mantenimiento evolutivo. El detalle:

Concepto	Rango
Diseño de flujos y evaluación clínica de intents	800 – 1.400 €
Integración con software clínico (API o adaptador)	1.400 – 2.800 €
Motor conversacional y guardarraíles	900 – 1.600 €
Alta y aprobación de WhatsApp Business API + plantillas HSM	400 – 700 €
Observabilidad y runbooks	500 – 900 €
Formación del equipo y pruebas de aceptación	600 – 1.100 €
Total setup	4.900 – 8.500 €
Cuota mensual operación	297 – 497 €

El cronograma real que aplicamos en clínicas de fisioterapia en producción distribuye el trabajo en cinco semanas: semana 1 descubrimiento y captura de intents con la clínica, semana 2 integración clínica y alta de WhatsApp API, semana 3 construcción del motor conversacional y guardarraíles, semana 4 pruebas con tráfico sombra (el agente ve mensajes reales sin responder para validar precisión), semana 5 activación por lotes con revisión diaria de escalados. En clínicas grandes con desarrollo propio del software añadimos una semana 0 de descubrimiento técnico.

Métricas después de 90 días en producción

Estas son las cifras agregadas de seis clínicas de fisioterapia que llevan más de 90 días con el agente en producción, medidas entre junio y agosto de 2026:

KPI	Antes	Con agente	Delta
Tiempo medio de primera respuesta	2 h 14 min	7 s	-99,9%
Tasa de no-shows	18%	7%	-61%
Citas gestionadas fuera de horario	0%	31%	+31 pp
Contención del agente (sin humano)	—	87%	—
Horas semanales liberadas al recepcionista	0	9,2 h	—
Latencia p95 respuesta	—	3,1 s	—
Incidencias RGPD reportadas	0	0	—

El dato menos glamuroso pero más importante es la latencia p95 sostenida en 3,1 segundos con un p99 de 6,4 segundos. Esa es la razón por la que los pacientes no notan que hablan con un agente. Cuando la conversación se acelera a la cadencia humana, la percepción cambia de "asistente" a "recepcionista". El resto de métricas se deriva de ahí.

Un último apunte: el 12% de las conversaciones que el agente escala al humano no son fallos. Son mensajes con intención clínica real (dolor agudo, cambio de diagnóstico, urgencia) que el guardarraíl envía al fisioterapeuta a propósito. En ese sentido, el agente actúa como el mejor triage de recepción que puede tener una clínica.

Errores frecuentes cuando desarrollas esto por primera vez

Cinco fallos que aparecen en el 90% de los proyectos que auditamos y que aún no cuentan con un equipo con experiencia en desarrollo de agentes IA para clínicas de fisioterapia:

• Mandar todo al LLM: el router de intents ligero baja la factura mensual entre 60 y 75%.
• Instrucciones críticas en el prompt en lugar de assertions en código: los prompts se saltan; las assertions no.
• Integración de una sola vía: leer el software clínico y no escribirlo obliga al humano a duplicar trabajo y mata el ROI.
• No usar plantillas HSM: intentar iniciar conversaciones fuera de la ventana de 24 horas sin plantilla aprobada rompe el sistema en 48 horas.
• Ignorar la observabilidad: sin trazas por conversación cada bug tarda semanas en reproducirse en lugar de minutos.

Cada uno de estos errores parece pequeño en el diseño y se paga caro en producción. Corregirlos después obliga a repensar la arquitectura, no a añadir un parche.