Transcripción clínica con IA privada: guía práctica

Por qué el audio no puede salir

Una conversación clínica contiene datos de pacientes: nombres, diagnósticos, casos concretos. Enviarla a una API de transcripción en la nube de un proveedor externo es ceder el dato a un tercero, con las implicaciones de seguridad, base legal y contratos que eso conlleva. En la práctica, en muchos hospitales esa opción se descarta antes de empezar.

• El dato no sale de la institución: la transcripción ocurre dentro de la red del hospital; ni el audio ni el texto se envían a ningún servicio externo.
• Compliance más simple: al no ceder el dato a un tercero, el mapa de riesgos y la base legal del tratamiento son más fáciles de sostener.
• Sin coste por uso: no se paga por audio ni por token a un proveedor; el coste es la infraestructura, que es fija y de la institución.
• Trazabilidad: cada uso queda registrado por equipo y caso, con registro de auditoría independiente.

Cómo funciona

El mismo principio que puedes probar ahora mismo: un reconocedor de voz con IA privado que transcribe en tu navegador —el audio se procesa en tu dispositivo y no se envía a ningún servidor—. En un entorno clínico el esquema es el mismo, pero con el modelo corriendo en el hardware del hospital.

La infraestructura, en números

No hace falta un data center. En un proyecto real basta con un servidor en tu red, dentro de la Unión Europea, corriendo modelos abiertos —por ejemplo Qwen 27B y variantes cuantizadas— con registro de uso independiente por equipo y cliente.

• Un servidor con una GPU de 16 GB de VRAM llega a 20–50 tokens/s con un modelo 27B: suficiente para transcripción, resumen y agentes. Es lo que entregamos en el caso de IA local para datos clínicos, con un servidor completo de en torno a 1.200 €.
• El reconocimiento de voz se puede añadir al mismo hardware o servirse desde un servicio interno equivalente; lo que no cambia es que el audio no salga.
• Red segmentada y tráfico cifrado: la IA vive en un tramo de tu red, no en la de los clínicos.
• Monitorización activa y registro de auditoría por equipo y cliente.
• Nada se aloja en servidores de terceros: la infraestructura es tuya y la elegimos contigo.

Cómo empezar: tres fases

El mismo camino de todos los proyectos de IA privada.

Errores comunes

• Copiar el flujo de la nube tal cual: asumir que la transcripción privada es «lo mismo pero en local» ignora el dimensionamiento, la concurrencia y el mantenimiento de modelos. El hardware y el reparto de carga se diseñan.
• Confundir transcribir con redactar: un texto literal de la conversación no es un informe. El valor está en el post-proceso con las plantillas de cada servicio, no en el stt solo.
• Omitir la revisión humana: nadie debería firmar un documento clínico generado por IA sin leerlo. El flujo debe contemplar la revisión como paso obligado, no como opción.
• Modelo genérico sin adaptación: la terminología de un servicio —siglas, medicamentos, procedimientos— no está en un modelo genérico. Afinar el vocabulario y las plantillas es lo que separa una demo de un sistema usable.
• Dejar el mantenimiento huérfano: los modelos, la seguridad y la normativa cambian. Sin un responsable de mantenimiento, el sistema se degrada en meses.

Un caso real

Montamos un sistema de IA local para datos clínicos en un pequeño servidor con GPU de 16 GB de VRAM y modelos open weight como Qwen 27B a 20–50 tokens/s, con el 100% del dato permaneciendo dentro del edificio y un stack que asegura trazabilidad, seguridad y disponibilidad. El caso completo, con el hardware y los números, está aquí.

Guías y servicios relacionados