En los últimos dos años, la conversación sobre inteligencia artificial se ha centrado en los modelos. GPT, Claude, Gemini, Llama y muchas otras opciones open source compiten en benchmarks, rankings y comparativas de desempeño.
Pero mientras la discusión gira en torno a qué modelo usar, hay una decisión igual de importante que suele pasar desapercibida durante el desarrollo de aplicaciones: dónde ocurre realmente la inferencia.
La ubicación influye en mucho más que la latencia. Determina por qué infraestructuras circulan los datos, qué proveedores participan en ese procesamiento, qué legislaciones pueden aplicar a ese flujo y cuánto control conserva la empresa cuando necesita cambiar de modelo o responder a una caída del servicio.
Esto no significa que toda organización deba abandonar las APIs externas u operar su propia infraestructura de AI. Para la mayoría de las empresas, eso ni siquiera tendría sentido. El punto es que la ubicación del procesamiento dejó de ser un detalle técnico y se convirtió en una decisión de arquitectura.
Qué es la soberanía digital en la práctica
La soberanía digital suele asociarse con la idea de tener todo bajo el mismo techo. En la práctica, pocas organizaciones operan así. Las aplicaciones modernas dependen de nubes públicas, servicios especializados, librerías open source, modelos de AI y decenas de integraciones distribuidas a lo largo de la arquitectura.
Lo importante es saber cuáles de esas dependencias pueden afectar la operación si dejan de existir o cambian sus condiciones de uso.
Una empresa gana soberanía cuando puede decidir dónde procesar los datos, qué información puede salir de determinado entorno, qué proveedores participan en cada etapa de la aplicación y cómo mantener un servicio funcionando si un componente deja de responder. Con eso, también gana libertad para sustituir modelos, cambiar de proveedor y aplicar sus propias políticas de seguridad y observabilidad.
Almacenar datos no es lo mismo que procesarlos
Gran parte de las discusiones sobre localización de datos se quedan en el almacenamiento, pero en las aplicaciones de AI eso es apenas una parte del problema.
Una empresa puede tener todas sus bases de datos en una región específica y, aun así, enviar información a un modelo que se ejecuta en otro país. Cada llamada recorre una cadena de componentes que normalmente incluye:
- Autenticación
- Enrutamiento
- Servicios intermediarios
- Infraestructura de ejecución
- Herramientas de monitoreo
- Sistemas de logging
En aplicaciones de AI, además de saber dónde se almacenan los datos, también hay que entender cómo se mueve ese flujo por la infraestructura y qué dependencias va creando en el camino.
Cómo afecta la ubicación de la inferencia a la latencia, la gobernanza y la continuidad
La ubicación del procesamiento afecta varios aspectos de la operación al mismo tiempo.
El primero es la experiencia del usuario. Entre más distancia haya entre la aplicación y la infraestructura que hace la inferencia, más tiempo suele tomar el transporte de la solicitud. Dependiendo del caso de uso, esa diferencia puede representar unos cuantos milisegundos o comprometer aplicaciones que necesitan respuestas en tiempo real.
También hay un impacto en la gobernanza de datos. Cada vez que una solicitud sale del entorno de la empresa, hay que entender qué información forma parte de ese flujo, qué contratos regulan el procesamiento, qué políticas de retención aplican y qué legislaciones podrían tener injerencia sobre la operación.
La continuidad del servicio entra en la misma ecuación. Cuando toda la inferencia depende de un solo endpoint externo, cambios comerciales, fallas técnicas o modificaciones en las políticas del proveedor pueden afectar directamente una aplicación en producción. Las arquitecturas distribuidas y las estrategias de fallback reducen esa concentración de riesgo, aunque no la eliminan.
Por último, está la cuestión jurisdiccional. La legislación aplicable a un flujo de datos depende de dónde está la empresa, dónde están los titulares de los datos, qué infraestructura se usa y quién es el proveedor. El lugar donde ocurre el procesamiento es una de esas variables, y influye en todas las demás decisiones de arquitectura.
Antes de entrar en los requisitos específicos de cada país, vale la pena entender cómo circulan los workloads de AI por la infraestructura y qué dependencias crea esa arquitectura. Ese diseño es el que determina qué riesgos y exigencias regulatorias tendrá que enfrentar la empresa.
El contexto regulatorio cambia. La arquitectura, menos de lo que parece.
Una aplicación de AI construida sobre APIs externas enfrenta los mismos retos técnicos en cualquier parte del mundo: disponibilidad del proveedor, ruta que recorren los datos, arquitectura de inferencia y capacidad de sustituir ese servicio cuando haga falta. Lo que cambia entre mercados es el entorno regulatorio y operativo en el que opera esa arquitectura.
La LGPD y la AI: qué cambia cuando la inferencia ocurre fuera de Brasil
En Brasil, la discusión normalmente empieza por la LGPD. Cuando se envían datos personales a un servicio de AI fuera del país, la organización tiene que evaluar cómo se realizará esa transferencia, qué mecanismo legal la respalda y qué garantías se ofrecen a los titulares de los datos.
La Resolución CD/ANPD n.º 19/2024 regula los mecanismos que prevé la LGPD para transferencias internacionales, incluyendo decisiones de adecuación, cláusulas contractuales estándar y otros supuestos contemplados en la ley.
Para los equipos de tecnología, esto se traduce en algo muy concreto: saber exactamente qué información sale de la infraestructura de la empresa, hacia dónde se envía y qué integraciones participan en ese flujo. Sin ese mapeo, cualquier conversación sobre cumplimiento queda incompleta.
Infraestructura de AI en Estados Unidos: concentración de proveedores y riesgo operativo
En Estados Unidos, además de las preocupaciones sobre la privacidad y la transferencia de datos, cada vez cobran más relevancia la continuidad operativa, la concentración de la infraestructura y la gobernanza de los proveedores. Gran parte de las aplicaciones modernas dependen de un grupo reducido de proveedores de nube y modelos de AI. Entre mayor sea esa concentración, mayor es el impacto potencial de una caída del servicio, un cambio comercial o la necesidad de migrar rápidamente a otra plataforma.
En este contexto, el NIST AI Risk Management Framework ofrece una estructura para identificar, evaluar y gestionar los riesgos asociados con los sistemas de IA, incluidas las dependencias técnicas y operativas.
La pregunta deja de ser “¿los datos permanecen en el país?” y pasa a ser “¿cuánto de mi operación depende de un solo proveedor?”.
América Latina: una arquitectura para varios regímenes regulatorios
Las empresas que operan en distintos países de América Latina enfrentan un reto adicional: no existe una legislación única para toda la región.
Cada país tiene su propia autoridad, sus propias reglas de protección de datos y mecanismos distintos para transferencias internacionales. Esto significa que una misma aplicación puede atender a usuarios brasileños, procesar datos de clientes colombianos, operar equipos en México y usar servicios alojados en otro continente.
En este escenario, la necesidad de centralizar las políticas técnicas aumenta. Las capas de autenticación, enrutamiento, observabilidad, clasificación de datos y control sobre llamadas externas se vuelven más importantes porque permiten aplicar reglas distintas sin tener que reconstruir toda la aplicación para cada país. La legislación varía. La arquitectura no tiene por qué variar en la misma proporción.
¿Usar APIs externas compromete la soberanía digital?
Hay una tendencia a tratar cualquier arquitectura basada en APIs públicas como un problema de soberanía digital. Esa conclusión es apresurada.
Gran parte de las aplicaciones de AI en producción usan modelos alojados por terceros. En muchos casos, esa es la decisión más eficiente desde el punto de vista técnico y económico. Los modelos avanzados requieren una infraestructura difícil de reproducir internamente, además de equipos especializados para operarla de forma continua. El problema surge cuando la empresa pierde el control sobre su propia arquitectura.
Piensa en dos escenarios. En el primero, un equipo usa un modelo externo para resumir documentos internos: si la API se cae por algunas horas, la productividad baja, pero la operación sigue funcionando. En el segundo, una plataforma financiera envía todos sus análisis de riesgo a un único endpoint sin alternativa disponible: ahí, la caída del proveedor ya no es un problema técnico, es una parada del negocio.
El riesgo no está en el modelo en sí, sino en el grado de dependencia que se crea alrededor de él. Si la caída de un solo proveedor detiene la operación, esa arquitectura concentra más riesgo del que debería. Si la aplicación sigue funcionando, aunque sea con un impacto limitado, la dependencia tiende a ser mucho menos crítica.
Cómo organizar la inferencia de AI: tres arquitecturas posibles
La arquitectura de inferencia suele reflejar el riesgo de la aplicación. Entre más crítica sea la operación y más sensibles los datos, mayor tiende a ser la necesidad de control sobre ese procesamiento.
Acceso directo al proveedor
En este modelo, la aplicación llama directamente al endpoint del modelo, sin una capa intermedia de control. La simplicidad reduce la complejidad operativa, pero también aumenta el acoplamiento con el proveedor y dificulta las estrategias de fallback o migración.
Una capa de control entre la aplicación y el modelo
Cuando la inferencia empieza a formar parte de procesos críticos, muchas organizaciones dejan de conectar la aplicación directamente al modelo. En su lugar, agregan una capa intermedia encargada de concentrar la lógica de inferencia, aplicar políticas y decidir cómo se procesa cada solicitud. Ahí es donde se toman decisiones como qué modelo usar, cuándo activar un fallback y qué información se debe enviar al proveedor. Con esto, la aplicación reduce su acoplamiento con el servicio de inferencia y gana más flexibilidad para evolucionar la arquitectura.
Inferencia distribuida
No todas las solicitudes tienen que procesarse con el mismo modelo o el mismo proveedor. Los modelos que corren en infraestructura distribuida pueden convivir con APIs externas, usadas solo cuando ofrecen capacidades específicas. Así, la aplicación elige dónde ejecutar cada inferencia según criterios como costo, desempeño, disponibilidad o los requisitos propios del workload.
El AI Inference de Azion hace posible este modelo: inferencia serverless distribuida globalmente, con autoescalado, APIs compatibles con OpenAI e integración directa con el resto de la aplicación, sin necesidad de aprovisionar u operar clústeres de GPU. La aplicación elige el destino más adecuado para cada solicitud, lo que reduce la concentración y evita que una decisión tomada en el primer prototipo termine definiendo la arquitectura durante años.
Cómo organiza Azion esta capa
Las organizaciones que usan AI en producción necesitan responder las mismas preguntas: dónde se va a ejecutar la inferencia, qué datos pueden salir de la organización, quién decide qué modelo se usa y qué pasa cuando un proveedor deja de estar disponible. Esas decisiones tienen que vivir en algún lugar. En Azion, esa capa se construye combinando Applications, Functions y AI Inference.
Las solicitudes llegan a través de Applications, pasan por las políticas de seguridad configuradas y son procesadas por Functions, donde la lógica de negocio decide el siguiente paso: enviarla a un proveedor externo, activar un fallback, aplicar autenticación, registrar el evento o ejecutar un modelo directamente en AI Inference. Con AI Inference es posible correr LLMs, VLMs, modelos de embeddings y modelos con fine-tuning vía LoRA directamente en la infraestructura distribuida de la plataforma, con autoescalado serverless y APIs compatibles con OpenAI.
Este diseño desacopla la aplicación del modelo. Un cambio de proveedor implica modificaciones concentradas en la capa de orquestación, no en toda la aplicación.
Axur, empresa de ciberseguridad, es un buen ejemplo de lo que significa ese control en la práctica. Después de mover sus workloads de AI al AI Inference de Azion, redujo el tiempo de detección hasta la solicitud de retiro a 5 minutos y ahora automatiza más de 30 mil takedowns al mes. Esa ganancia no vino de cambiar un modelo por otro. Vino de pasar de una infraestructura administrada a una arquitectura serverless con autoescalado y la posibilidad de personalizar modelos vía LoRA, lo que redujo el esfuerzo de ingeniería y liberó al equipo para enfocarse en detección y respuesta a amenazas.
La ubicación del procesamiento dejó de ser un detalle de infraestructura
La ubicación de la inferencia dejó de ser solo una decisión de desempeño. Hoy también influye en la gobernanza, la protección de datos y la continuidad operativa.
Las exigencias cambian de un mercado a otro. En Brasil, la discusión pasa por la LGPD. En Estados Unidos, por la concentración de infraestructura y la resiliencia operativa. En América Latina, por el reto de conciliar distintas legislaciones dentro de una misma aplicación.
Pero la decisión de arquitectura sigue siendo la misma. Entre más pronto entienda la organización dónde se ejecutan sus workloads y qué dependencias está creando, mayor será su libertad para evolucionar la aplicación sin quedar atada a un solo modelo, proveedor o requisito específico.
Conoce el AI Inference de Azion y descubre cómo construir aplicaciones de AI con más control, escalabilidad y flexibilidad.
Preguntas frecuentes
¿Qué es la soberanía digital en aplicaciones de AI? Es la capacidad de controlar dónde se procesan los datos, qué proveedores forman parte de la arquitectura y cómo sigue funcionando la aplicación si un servicio externo deja de estar disponible.
¿Usar APIs externas compromete la soberanía digital? No necesariamente. El factor clave es el nivel de dependencia que se genera alrededor de esas APIs. Entre más fácil sea sustituir a un proveedor o mantener la operación durante una caída, mayor tiende a ser la soberanía de la arquitectura.
¿Por qué importa la ubicación de la inferencia? Porque influye no solo en la latencia, sino también en la gobernanza de datos, los requisitos regulatorios, la continuidad operativa y la capacidad de evolucionar la arquitectura sin depender de un solo proveedor.
