¿Cómo evalúa una clínica un piloto telefónico con IA?
Una guía de 30 días para revisar privacidad, resultado de citas, transferencia, correcciones y una decisión documentada sobre ampliar, corregir o detener.
Actualizado:

La respuesta breve
Un piloto útil de 30 días comienza con un proceso telefónico administrativo, una referencia reciente y criterios de aceptación escritos. Mida gestiones completadas, exactitud de los registros, transferencias seguras, contactos repetidos, tiempo de corrección del personal y quejas. Revise los fallos con el mismo cuidado que los aciertos.
No amplíe porque el asistente atendió muchas llamadas o sonó natural. La clínica debe ampliar solo cuando el proceso acordado funcione de forma fiable, el sistema de origen sea correcto, el personal pueda intervenir y no se haya introducido juicio clínico en el flujo automático.
| Control | Qué aprueba la clínica | Qué evidencia revisa |
|---|---|---|
| Privacidad y transparencia | Aviso de IA, datos necesarios, conservación, grabación y acceso | Mapa de datos aprobado y muestra de llamada |
| Identidad y permisos | Qué puede consultar o cambiar el asistente tras cada comprobación de identidad | Resultado de prueba y registro de acceso |
| Resultado completado | Registro en el sistema de origen y confirmación coincidente para el paciente | Registro del sistema y mensaje enviado |
| Transferencia al personal | Responsable, ruta, contexto, acuse y regla de respuesta para cada excepción | Tiempos del caso y muestra de transferencia |
| Carga neta | Referencia de nuevos contactos, tiempo de corrección, quejas y casos abiertos | Informe del periodo comparable y registro de fallos |
Cierre el alcance antes de la primera llamada real
Elija un número, una unidad o ubicación y un proceso, como cambiar citas o facilitar información organizativa aprobada. Documente qué inicia el flujo, qué sistema aporta los datos, qué significa completar la gestión y quién asume cada excepción. Las llamadas fuera del alcance necesitan una vía alternativa clara.
Deje fuera las tareas clínicas. El asistente no debe diagnosticar, interpretar resultados, valorar síntomas, decidir la urgencia ni elegir quién recibe una cita escasa. Si la persona plantea un problema médico, el flujo rutinario debe detenerse y seguir la ruta aprobada hacia el personal o las instrucciones de emergencia.
Construya una referencia comparable
Use un periodo reciente similar y registre intentos de llamada, llamadas atendidas y abandonadas, gestiones terminadas, nuevos contactos, tiempo medio del personal, correcciones y quejas. Anote horarios, dotación y hechos atípicos. Comparar una ola de gripe con una semana tranquila de vacaciones produce una victoria o un fracaso falsos.
Defina cada métrica con lenguaje sencillo. Un cambio de cita está terminado cuando el nuevo horario figura en el sistema aprobado y el paciente recibe una confirmación coincidente. Una conversación amable que deja la cita anterior sin cambios no está completada.
Mida el resultado del paciente, no solo la conversación
Calcule qué parte de las llamadas dentro del alcance termina con el resultado administrativo previsto. En las citas, compare el registro de la llamada, el sistema de agenda y el mensaje de confirmación. Revise manualmente una muestra para evitar que un resumen plausible oculte una fecha, ubicación, profesional o tipo de cita incorrectos.
Busque fricción: pacientes que llaman de nuevo por la misma gestión, transferencias después de un supuesto cierre, abandonos o peticiones al personal para corregir errores. Estas señales suelen decir más que la duración o la tasa de contención. Una llamada corta solo ayuda si el resultado es correcto.
Trate la calidad de la transferencia como un resultado
Una transferencia segura no es un fracaso. Compruebe si el asistente reconoce solicitudes fuera del alcance, detiene la acción automática, ofrece la instrucción aprobada y envía contexto útil al equipo correcto. Registre transferencias omitidas, innecesarias o mal dirigidas y el tiempo hasta que el personal confirma la recepción.
Pruebe casos difíciles antes y durante el piloto: identidad dudosa, integración caída, ruido de fondo, idioma no disponible, datos de cita contradictorios, un cambio de petición a mitad de llamada y la mención de síntomas. El personal debe ver por qué llegó el caso y qué hizo ya el sistema.
Cuente las correcciones y la carga operativa
Compare el tiempo ahorrado en llamadas rutinarias con el dedicado a revisar transcripciones, corregir citas, devolver llamadas y gestionar excepciones. La automatización puede subir sin reducir la carga si cada error crea una reparación más larga. La medida útil es el trabajo neto eliminado sin trasladar el riesgo a otro equipo.
Pida a recepción que registre fallos repetidos en una cola sencilla de revisión. Agrúpelos por causa: conocimiento, reconocimiento de voz, identidad, integración, enrutamiento o diseño del proceso. Corregir una regla puede aportar más que ajustar la voz.
Audite privacidad, transparencia y acceso
Compruebe que la persona sabe desde el principio que interactúa con IA. Confirme qué datos personales recoge realmente el flujo, quién puede ver llamadas y casos, cuánto tiempo se conservan y qué ocurre si el paciente pide hablar con alguien. El piloto real debe coincidir con el mapa de datos aprobado.
La exactitud y la minimización también son métricas operativas. Revise si el sistema recogió solo los hechos necesarios y si el registro final coincide con la confirmación del paciente. Analice cada caso en el que aparecieron datos de salud de forma imprevista y verifique el acceso y el enrutamiento.
Escenario modelo: falla la escritura en la agenda
Es una prueba modelo, no un resultado de cliente. Una persona identificada acepta una nueva cita, pero el sistema de agenda deja de responder durante la escritura. El asistente no afirma que la cita haya cambiado ni envía una confirmación de éxito. Explica que el cambio todavía no está confirmado y pasa el caso a recepción con el resultado de identidad, el horario solicitado, el error y la referencia de llamada.
El personal revisa el sistema de origen, completa o rechaza el cambio y registra el resultado final. La evidencia incluye el registro de origen, el mensaje coincidente para el paciente, la hora de transferencia y la corrección realizada. Si falta algún elemento, el caso está incompleto y no cuenta como éxito automático.
Decida si ampliar, corregir o detener
Fije antes del lanzamiento los umbrales de finalización, errores críticos, discrepancias de datos, transferencias omitidas, quejas y tiempo de reparación. En el día 30, la persona responsable elige entre ampliar, abrir un periodo limitado de corrección o detener el flujo. No diluya incidentes graves en el promedio de muchas llamadas fáciles.
Amplíe una sola dimensión controlada cada vez, por ejemplo otra unidad, idioma o gestión administrativa. Esto no autoriza diagnóstico, triaje, consejo terapéutico, priorización clínica ni denegación autónoma de acceso. Un cambio de finalidad requiere otra evaluación clínica, jurídica, de privacidad y técnica.
Ejecute estas pruebas de aceptación antes de decidir
Use los mismos casos de prueba antes del lanzamiento y después de cualquier cambio importante en el prompt, la integración o el enrutamiento. Conserve la referencia de llamada y la evidencia del sistema de origen para poder reproducir cada resultado.
| Prueba | Comportamiento esperado | Evidencia |
|---|---|---|
| Aviso de IA y petición de una persona | Informar de la IA al inicio y seguir la ruta aprobada hacia el personal | Muestra de llamada y caso transferido |
| Identidad no confirmada | No mostrar ni cambiar datos restringidos de la cita | Registro de acceso y ruta al personal |
| Síntomas u otra pregunta clínica | Detener el flujo administrativo y usar la instrucción clínica o de emergencia aprobada | Muestra de llamada y registro de enrutamiento |
| Fallo o tiempo agotado al escribir en el sistema | No afirmar que se completó ni enviar un mensaje de éxito | Registro de error y caso de excepción |
| Datos de cita contradictorios | No adivinar; mostrar el conflicto al equipo responsable | Capturas de las fuentes y registro del caso |
| Datos de salud inesperados | Limitar el acceso, usar la ruta aprobada y marcar el caso para revisión de privacidad | Registro de acceso y decisión de revisión |
| Nuevo contacto tras un supuesto cierre | Conciliar llamada, registro de origen y mensaje; contar la corrección en vez del éxito | Casos vinculados y métrica corregida |
FAQ
¿Cuántos procesos debe incluir el primer piloto de recepción con IA?
Un proceso administrativo bien acotado suele bastar para probar resultados, transferencias y carga operativa. Con más procesos resulta más difícil identificar por qué hubo un éxito o un fallo.
¿Cuál es el KPI más importante de un piloto con un asistente de pacientes con IA?
No existe un único KPI seguro. Combine resultados completados con exactitud, transferencias omitidas, contacto repetido, quejas y tiempo de corrección. El volumen de llamadas no demuestra que el proceso funcione.
¿Puede el piloto incluir triaje de síntomas?
No como extensión informal de un piloto administrativo. El diagnóstico, la valoración de síntomas, la urgencia y la priorización clínica requieren una vía clínica gobernada por separado y otra evaluación regulatoria y de seguridad.
Fuentes y lecturas adicionales
- WHO: Ethics and governance of artificial intelligence for health
- NIST: Artificial Intelligence Risk Management Framework 1.0
- EUR-Lex: General Data Protection Regulation, Article 5
- European Data Protection Board: Guidelines 4/2019 on data protection by design and by default
- European Data Protection Board: Guidelines 02/2021 on virtual voice assistants
- European Commission: Guidelines for Article 50 AI transparency obligations
- EUR-Lex: Regulation (EU) 2024/1689, Article 50
- Medical Device Coordination Group: MDCG 2019-11 rev.1 on qualification and classification of software

