IA on-premise para salud: guía de arquitectura e infraestructura
Una guía práctica de infraestructura para desplegar IA on-premise en entornos de salud. Cubre requisitos de hardware, arquitectura de red, despliegue en red aislada, registro de auditoría HIPAA, estrategias de actualización de modelos y comparaciones reales de costos contra APIs en la nube.
El equipo de TI de tu hospital dice "no podemos usar IA en la nube." Tienen razón. Que PHI salga de tu red es un evento de cumplimiento. Cada llamada API a OpenAI o Anthropic con datos de pacientes crea responsabilidad de auditoría, complejidad de BAA y riesgo de brecha.
Pero aquí está la parte que quizás no sepan todavía: la IA on-premise ahora es práctica y asequible. Una sola GPU NVIDIA T4 cuesta menos que una estación de trabajo de gama media. Los modelos open-source ejecutan tareas de NLP clínico con calidad de producción. Los patrones de infraestructura están bien establecidos.
Esta guía cubre exactamente lo que necesitas — hardware, arquitectura de red, servicio de modelos, almacenamiento, monitoreo, actualizaciones y recuperación ante desastres — para ejecutar IA on-premise en un entorno de salud.
Requisitos de hardware
La primera decisión es inferencia por GPU vs CPU. Esto depende de tus requisitos de volumen y latencia.
Inferencia GPU vs CPU para volúmenes de salud
| Factor | GPU (NVIDIA T4) | Solo CPU (Xeon/EPYC) |
|---|---|---|
| Costo de hardware | $2,000-3,000 por tarjeta | $0 adicional (usar servidores existentes) |
| Rendimiento | 15-40 tokens/seg (modelo 7B, Q4) | 3-8 tokens/seg (modelo 7B, Q4) |
| Usuarios concurrentes | 10-20 solicitudes simultáneas | 2-5 solicitudes simultáneas |
| Mejor para | Más de 500 inferencias/día, triaje en tiempo real | Menos de 200 inferencias/día, procesamiento por lotes |
| Consumo de energía | 70W por T4 | Incluido en la línea base del servidor |
| Espacio en rack | 1U por 2-4 GPUs | Infraestructura de servidor existente |
Para la mayoría de los hospitales medianos (200-500 camas): Comienza con una sola GPU T4. Maneja resumen de notas clínicas, asistencia de codificación diagnóstica y triaje de pacientes en volúmenes que cubren 3-5 departamentos. Costo total de hardware: $8,000-12,000 para un servidor de inferencia completo (CPU + RAM + T4 + almacenamiento).
Para clínicas más pequeñas (menos de 100 camas): La inferencia solo por CPU es viable. Un servidor moderno de 32 núcleos Xeon con 64GB de RAM ejecuta modelos cuantizados de 7B con latencia aceptable para tareas no en tiempo real como procesamiento nocturno por lotes de notas clínicas o generación semanal de reportes.
Especificaciones mínimas del servidor
| Componente | Ruta GPU | Ruta solo CPU |
|---|---|---|
| CPU | 16+ núcleos (Xeon Silver o EPYC) | 32+ núcleos (Xeon Gold o EPYC) |
| RAM | 32GB mínimo, 64GB recomendado | 64GB mínimo, 128GB recomendado |
| GPU | NVIDIA T4 16GB (o A2000 12GB) | Ninguna |
| Almacenamiento | 500GB NVMe SSD | 500GB NVMe SSD |
| Red | 1GbE mínimo, 10GbE recomendado | 1GbE mínimo |
| SO | Ubuntu 22.04 LTS o RHEL 9 | Ubuntu 22.04 LTS o RHEL 9 |
Arquitectura de red
Los despliegues de IA en salud siguen tres patrones de red, cada uno con perfiles de seguridad diferentes.
Patrón 1: despliegue en red aislada
La opción más estricta. El servidor de inferencia tiene cero conectividad a internet.
[Sistemas clínicos] <---> [Gateway API interno] <---> [Servidor de inferencia IA]
|
[BD de log de auditoría]
Sin conexión de red externa. Actualizaciones de modelo vía medios seguros.
Cuándo usar: Entornos de máxima seguridad. Instalaciones que manejan registros de salud militar, registros psiquiátricos, registros de tratamiento por abuso de sustancias (42 CFR Parte 2) o datos de investigación bajo protocolos IRB estrictos.
Concesión: Las actualizaciones de modelo requieren medios físicos (USB cifrado) o un registro de artefactos interno dedicado. Sin monitoreo remoto. Mayor carga operativa.
Patrón 2: despliegue en DMZ
El servidor de inferencia se ubica en una DMZ con acceso saliente controlado solo para actualizaciones. Sin conexiones entrantes desde internet.
[Internet] --X-- [Firewall] --- [DMZ: Proxy de actualización] --- [Firewall] --- [Servidor de inferencia IA]
|
[Sistemas clínicos] <-----------------------------------------> [Gateway API interno]
Cuándo usar: La mayoría de los despliegues hospitalarios. Permite actualizaciones automatizadas de modelos a través de un proxy controlado mientras mantiene el procesamiento de PHI completamente interno.
Concesión: Requiere reglas de firewall cuidadosas. El proxy de actualización debe ser endurecido y auditado.
Patrón 3: aislamiento por VLAN
La infraestructura de IA se ejecuta en una VLAN dedicada, segmentada del tráfico general de la red hospitalaria pero accesible para sistemas clínicos autorizados.
VLAN 100 (Clínica): [EHR] [PACS] [Apps clínicas]
|
[Switch L3 / Reglas de firewall]
|
VLAN 200 (Infra IA): [Gateway API] [Servidor de inferencia] [BD de auditoría]
Cuándo usar: Instalaciones que necesitan control de acceso departamental. Radiología obtiene acceso al modelo de imagen. Patología obtiene acceso al modelo de generación de reportes. Urgencias obtiene acceso a la asistencia de triaje. Cada regla VLAN-a-VLAN se documenta y es auditable.
Stack de servicio de modelos
El stack de producción para inferencia de IA en salud es directo.
Componentes principales
- Motor de inferencia: Ollama o llama.cpp. Ollama proporciona una API REST lista para usar. llama.cpp ofrece control de más bajo nivel y rendimiento ligeramente mejor.
- Gateway API: Nginx o Envoy como proxy inverso frente al motor de inferencia. Maneja autenticación, limitación de tasa y terminación TLS.
- mTLS entre servicios: Cada conexión entre el gateway API, motor de inferencia y base de datos de auditoría usa TLS mutuo. Sin excepciones. Esto es un requisito de HIPAA para ePHI en tránsito.
Flujo de solicitudes
[App clínica] --> [mTLS] --> [Gateway API (Nginx)]
--> [Verificación de auth: clave API + ID de departamento]
--> [Verificación de límite de tasa]
--> [mTLS] --> [Ollama/llama.cpp]
--> [Respuesta registrada en BD de auditoría]
--> [mTLS] --> [App clínica]
Gestión de claves API
Cada departamento obtiene su propia clave API. Esto habilita seguimiento de uso por departamento, limitación de tasa y control de acceso. Rota las claves trimestralmente. Almacénalas en HashiCorp Vault o tu sistema de gestión de secretos existente.
Requisitos de almacenamiento
El almacenamiento de IA en salud se divide en tres categorías con perfiles de dimensionamiento muy diferentes.
| Tipo de almacenamiento | Tamaño | Tasa de crecimiento | Retención |
|---|---|---|---|
| Archivos de modelo base | 4-14GB por modelo (cuantizado) | Estático por versión | Mantener actual + 1 versión anterior |
| Archivos de adaptadores LoRA | 50-200MB por adaptador de especialidad | ~1-2 nuevos adaptadores/trimestre | Mantener todas las versiones (rastro de auditoría) |
| Logs de auditoría | 10-50GB/año | Escala con el uso | 6-7 años (mínimo HIPAA 6) |
| Datasets de evaluación | 1-5GB | Actualizaciones trimestrales | Mantener todas las versiones |
Almacenamiento total del primer año: 30-70GB para modelos y adaptadores, más crecimiento de logs de auditoría. Un SSD NVMe de 1TB maneja más de 5 años de operación con espacio de sobra.
Estrategia de respaldo: Respaldos cifrados a una ubicación secundaria on-premise. Nunca respaldes a almacenamiento en la nube a menos que el proveedor de nube tenga un BAA firmado y tu evaluación de riesgos lo apruebe explícitamente.
Monitoreo y registro
HIPAA requiere registro de auditoría para cualquier sistema que procese ePHI. Para inferencia de IA, esto significa cada solicitud individual.
Qué registrar por inferencia
| Campo | Ejemplo | Propósito |
|---|---|---|
| Timestamp | 2026-02-26T14:32:01Z | Rastro de auditoría |
| ID de solicitud | uuid-v4 | Correlación |
| Versión del modelo | llama-3.1-8b-q4_K_M + radiology-v2.3 | Reproducibilidad |
| Departamento | radiología | Auditoría de control de acceso |
| ID de usuario/servicio | ehr-integration-svc | Atribución |
| Hash de entrada (SHA-256) | a3f2... | Verificación de integridad sin almacenar PHI |
| Hash de salida (SHA-256) | b7c1... | Verificación de integridad |
| Conteo de tokens (entrada/salida) | 342 / 128 | Seguimiento de uso |
| Latencia (ms) | 1,240 | Monitoreo de rendimiento |
| Estado | success / error | Operaciones |
Detalle crítico: Registra hashes de entrada y salida, no contenido crudo. Esto te permite verificar integridad y probar qué versión del modelo produjo qué salida sin almacenar copias adicionales de PHI en la base de datos de auditoría.
Registro de acceso HIPAA
Más allá del registro de inferencia, necesitas logs de acceso HIPAA estándar:
- Quién accedió al sistema de IA y cuándo
- Éxitos y fallos de autenticación
- Cambios de configuración (actualizaciones de modelo, intercambios de adaptador, cambios de parámetros)
- Acceso administrativo al servidor de inferencia
Usa tu SIEM existente (Splunk, Elastic, etc.) para agregar estos logs. La infraestructura de IA debería alimentar el mismo pipeline de registro que el resto de tus sistemas clínicos.
Estrategia de actualización de modelos
Llevar nuevas versiones de modelos a sistemas aislados o en red cerrada es el mayor desafío operativo.
Opción 1: transferencia USB segura (red aislada)
- Descarga archivos de modelo en una estación de trabajo con internet en una sala segura
- Verifica checksums contra hashes publicados
- Transfiere a unidad USB cifrada (compatible con FIPS 140-2)
- Transporta vía personal autorizado con documentación de cadena de custodia
- Carga en el servidor de inferencia, verifica checksums nuevamente
- Ejecuta suite de validación antes de cambiar el tráfico de producción
Tiempo por actualización: 2-4 horas incluyendo verificación y validación.
Opción 2: registro de artefactos interno (DMZ)
- Descarga automatizada desde registro externo de modelos (Hugging Face, registro de Ollama) a través del proxy DMZ
- Los archivos de modelo llegan a un registro de artefactos interno (Nexus, Artifactory o un simple servidor de archivos Nginx)
- El servidor de inferencia descarga del registro interno según un calendario
- Suite de validación automatizada se ejecuta antes de cambiar el tráfico
Tiempo por actualización: 30-60 minutos, mayormente automatizado.
Despliegue por etapas
Independientemente del método de entrega, sigue un despliegue por etapas:
- Canario (5% del tráfico): Enruta un pequeño porcentaje de solicitudes no críticas al nuevo modelo
- Validación (24-48 horas): Compara métricas de calidad de salida contra la versión anterior
- Despliegue completo: Cambia todo el tráfico a la nueva versión
- Ventana de rollback: Mantén la versión anterior cargada y lista para rollback instantáneo por 7 días
Recuperación ante desastres
Los fallos del sistema de IA en entornos clínicos necesitan procedimientos de respaldo claros.
Modos de fallo y respuestas
| Fallo | Objetivo RTO | Respuesta |
|---|---|---|
| Fallo de GPU | 4 horas | Failover a inferencia CPU (rendimiento degradado) |
| Crash del servidor de inferencia | 15 minutos | Reiniciar servicio, auto-recuperación |
| Corrupción de archivo de modelo | 1 hora | Restaurar desde respaldo local, re-verificar checksums |
| Fallo completo del servidor | 8 horas | Restaurar desde respaldo a hardware de reserva |
| Partición de red | Inmediato | Apps clínicas recurren a flujos sin IA |
Respaldo a CPU
Todo despliegue acelerado por GPU debería tener una ruta de respaldo a CPU probada. Si la GPU falla:
- Ollama/llama.cpp automáticamente recurre a inferencia por CPU
- El rendimiento cae de ~30 tokens/seg a ~5 tokens/seg
- Reduce el límite de solicitudes concurrentes de 10 a 2
- Prioriza casos de uso clínico en tiempo real, encola trabajos por lotes
Este modo degradado mantiene la IA disponible mientras se reemplaza el hardware. Ningún flujo de trabajo clínico debería tener una dependencia dura de la IA — siempre debería ser asistencial, con respaldo humano.
Comparación de costos: on-premise vs API en la nube
Las matemáticas favorecen al on-premise en volúmenes de salud.
Costo total de propiedad a 3 años
| Componente de costo | On-premise (GPU T4) | API en la nube (clase GPT-4, BAA) |
|---|---|---|
| Hardware (año 0) | $10,000 | $0 |
| Software/licencias | $0 (stack open-source) | $0 |
| Costos API (año 1) | $0 | $36,000-72,000 |
| Costos API (año 2) | $0 | $36,000-72,000 |
| Costos API (año 3) | $0 | $36,000-72,000 |
| Energía/refrigeración (3 años) | $1,800 | $0 |
| Tiempo DevOps (3 años) | $15,000 (tiempo parcial) | $5,000 (solo integración) |
| Costos BAA/cumplimiento | $0 (interno) | $5,000-15,000 (evaluación de proveedor) |
| Total 3 años | $26,800 | $82,000-231,000 |
Supuestos: 1,000 inferencias/día, promedio de 500 tokens de entrada + 200 de salida. Precios de nube a $0.01-0.03/1K tokens (nivel cubierto por BAA, típicamente 2-3x el precio estándar). DevOps a $75/hora, 4 horas/semana on-premise vs 1 hora/semana nube.
El punto de equilibrio es típicamente alrededor de 200-300 inferencias por día. Por debajo de eso, las APIs en la nube con BAA pueden ser más rentables. Por encima, on-premise gana y la brecha se amplía cada mes.
Requisitos de equipo
No necesitas un equipo dedicado de ML. Necesitas:
- 1 ingeniero de DevOps/infraestructura (tiempo parcial, ~4 horas/semana): Maneja mantenimiento del servidor, actualizaciones de modelo, alertas de monitoreo y parches de seguridad. Esta persona ya existe en tu equipo de TI.
- 1 campeón clínico por departamento: Un clínico que es dueño del caso de uso, valida salidas y proporciona retroalimentación para fine-tuning. No es un rol técnico.
- Soporte de proveedor (opcional): Ertas o plataforma similar para fine-tuning, gestión de adaptadores y herramientas de despliegue. Elimina la necesidad de experiencia en ML.
El error más común es sobre-dotación de personal. La inferencia de IA on-premise es operativamente similar a ejecutar cualquier otro servicio interno. Si tu equipo puede gestionar un servidor de base de datos interno, pueden gestionar un servidor de inferencia de IA.
Ship AI that runs on your users' devices.
Ertas early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Poniéndolo todo junto
Aquí está la arquitectura completa para un despliegue hospitalario mediano:
Internet (solo actualizaciones)
|
[DMZ: Proxy de actualización]
|
[Red interna - VLAN 200: Infraestructura IA]
|
[Registro de artefactos] --> [Servidor de inferencia: GPU T4 + Ollama]
| |
[Gateway API (Nginx)] [BD de auditoría (PostgreSQL)]
|
[mTLS + Auth por clave API]
|
[VLAN 100: Sistemas clínicos]
| | |
[EHR] [PACS] [Apps clínicas]
Despliegue del día uno: Un solo servidor T4, un departamento, un caso de uso (resumen de notas clínicas). Costo total menor a $12,000. Tiempo a producción: 2-3 semanas con personal de TI existente.
Ruta de escalamiento: Agrega adaptadores LoRA para nuevos departamentos. Agrega una segunda T4 para mayor rendimiento. Agrega modelos de especialidad para radiología, patología, codificación. Cada expansión es incremental — no se necesita rediseño de arquitectura.
La infraestructura es la parte fácil. El stack de servicio de modelos está probado. Los patrones de red están bien entendidos. Lo que importa es poner el primer caso de uso en producción y demostrar valor al personal clínico que lo usará cada día.
Lectura adicional
- Comparación de costos de GPU para autoalojar IA en 2026 — Benchmarks detallados de hardware y precios para cargas de inferencia
- Calculadora de ROI de IA autoalojada — Construye un caso de negocio con números reales para tu volumen específico
- IA compatible con HIPAA: on-premise vs API en la nube — Inmersión profunda en requisitos de cumplimiento y concesiones arquitectónicas
Ship AI that runs on your users' devices.
Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Keep reading
On-Premise AI for Banking: Satisfying Regulator Audit Requirements
Architecture and operational guide for deploying on-premise AI in banking environments that satisfy OCC, FINRA, and Federal Reserve audit requirements. Covers infrastructure, audit trails, access controls, change management, disaster recovery, and a 10-dimension compliance comparison.
Fine-Tuning AI for Healthcare: HIPAA-Compliant Pipeline from Data to Deployment
A comprehensive guide to building HIPAA-compliant fine-tuning pipelines for healthcare AI — covering de-identification methods, training data structures for five clinical use cases, model selection, and cost analysis of on-premise vs cloud deployment.
LoRA Adapters Per Healthcare Specialty: Radiology, Pathology, Primary Care
How to serve multiple hospital departments from a single base model using specialty-specific LoRA adapters. Covers architecture, training data requirements, storage math, adapter management, and performance benchmarks.