IA local vs IA en la nube: lo que casi nadie revisa antes de implementar

Introducción

Si llegaste hasta esta página probablemente viste mi short donde explico por qué usar un modelo de IA en la nube significa compartir datos de tus clientes con un tercero.

Uno de los errores más comunes cuando una empresa implementa su primer agente de IA es asumir que el proveedor en la nube ya se ocupa del compliance.

Pero la realidad es que cada vez que tu agente le manda un prompt a OpenAI, Anthropic o Gemini, esos datos están saliendo de tu infraestructura. Y según la industria en la que estés, eso puede ser un problema serio.

Elegir mal puede generar consecuencias como:

• multas por incumplimiento de GDPR o HIPAA
• pérdida de contratos B2B por subprocesadores no autorizados
• fuga de información confidencial usada para entrenar modelos futuros
• costos en tokens que a los 12 meses superan lo que costaría hardware propio

En esta página te dejo un resumen rápido del concepto y también el documento completo con la matriz de decisión y los modelos locales recomendados según el caso.

La diferencia que cambia todo

Un modelo en la nube procesa cada conversación a través de internet. Los datos viajan al proveedor, se procesan en su infraestructura, y según el contrato pueden quedar logueados, usarse para entrenar modelos futuros, o estar sujetos a leyes del país donde está el datacenter.

Un modelo local corre 100% dentro de tu infraestructura. Los datos nunca salen.

La desventaja del modelo local es que requiere inversión en hardware (GPU, RAM, almacenamiento) y alguien que mantenga el stack. Pero en muchos casos ese número es menor que lo que gastas en tokens a largo plazo.

Cuándo esta decisión importa

No todos los proyectos necesitan correr modelos locales. La decisión pasa a ser crítica cuando:

• procesás datos de salud, financieros, biométricos o de menores
• tu industria está regulada (banca, seguros, salud, gobierno)
• tenés clientes en la UE, en California, o sujetos a HIPAA
• firmaste cláusulas de confidencialidad que prohíben subprocesadores no listados
• el volumen de tokens mensual ya supera lo que costaría amortizar hardware propio

Si nada de eso aplica, cloud sigue siendo la opción de menor fricción para arrancar.

Las normativas que más veo en proyectos reales

Cuando trabajo en proyectos B2B o con empresas medianas, las normativas que aparecen más seguido son:

GDPR restringe la transferencia internacional de datos. Si tenés clientes en la UE, los subprocesadores deben estar listados y aprobados.

HIPAA requiere BAA firmado con cada proveedor que procese datos de salud. La mayoría de las APIs públicas de IA no firman BAA en sus tiers estándar.

SOC 2 no es ley pero es lo que te piden los enterprise en US. Auditan cómo manejás datos, incluyendo subprocesadores.

EU AI Act clasifica sistemas de IA por nivel de riesgo. Los de alto riesgo (RRHH, crédito, salud, biometría) requieren documentación y supervisión humana.

Cada una tiene implicancias distintas en cómo armás la arquitectura.

El error más común al diseñar agentes con datos sensibles

El error más frecuente es asumir que firmar el DPA estándar del proveedor cubre todo el compliance.

Aunque esto puede funcionar para casos simples, rápidamente aparecen problemas porque:

• los DPAs estándar no cubren todas las normativas verticales (HIPAA, PCI DSS)
• la mayoría de los DPAs no incluyen BAA, que es requisito específico de salud
• algunos proveedores procesan los datos en regiones no permitidas por GDPR
• el opt-out de entrenamiento no siempre viene activado por default

Los sistemas bien diseñados suelen ser híbridos: el modelo local maneja datos sensibles (PII, transcripciones, embeddings) y el modelo en la nube se usa solo para tareas donde la calidad importa y los datos ya fueron anonimizados.

Sobre este contenido

En mi canal comparto ejemplos reales de cómo diseñar sistemas de IA aplicados a WhatsApp, voz y atención al cliente, con foco en arquitectura, trade-offs y compliance.

Si te interesa este tipo de análisis técnico, podés encontrar más contenido en mi canal de YouTube.

Documento: IA Local vs Cloud, compliance y modelos

Si estás evaluando dónde correr tu sistema de IA, preparé un documento donde explico cómo decidir entre cloud, local o arquitectura híbrida según el caso de uso.

En el documento vas a encontrar:

• las normativas globales que más impactan en decisiones de arquitectura
• matriz de decisión por escenario (atención al cliente, salud, contratos B2B, etc.)
• modelos open-source recomendados con specs de hardware mínimo
• cuándo cloud sigue siendo la mejor decisión
• arquitectura híbrida como tercera opción