¿Y si mañana no tienes ChatGPT, Claude o Gemini?

Edge AI no solo puede reducir costos y proteger datos. También puede formar parte de una estrategia de continuidad.

Cada vez que utilizamos ChatGPT, Claude, Gemini o cualquier otro modelo alojado en la nube, estamos delegando una parte de nuestro trabajo a infraestructura que no controlamos. En algunos casos se trata apenas de una consulta ocasional, pero en otros la inteligencia artificial empieza a integrarse en procesos empresariales completos: atención al cliente, análisis de documentos, generación de reportes, soporte al desarrollo, clasificación de información o procesamiento de audio.

Mientras el servicio está disponible, la arquitectura parece funcionar perfectamente. El problema aparece cuando deja de estarlo.

No hace falta imaginar que OpenAI, Google o Anthropic desaparezcan. Basta con una caída de servicio, un problema de conectividad, un cambio de precios, un límite de consumo, una modificación de API, una nueva política sobre el tratamiento de datos o la retirada de una versión del modelo sobre la que construimos nuestra aplicación.

Si el proceso depende completamente de ese servicio externo, la indisponibilidad del modelo deja de ser un problema técnico y empieza a convertirse en un riesgo operativo.

Y ahí aparece una pregunta que probablemente tendremos que empezar a incorporar con mayor frecuencia al diseñar soluciones de inteligencia artificial: si mañana el modelo que utilizamos deja de estar disponible, ¿qué parte de nuestra operación puede seguir funcionando?

De la dependencia del modelo a la arquitectura

Durante años hemos aprendido a diseñar sistemas pensando en disponibilidad, redundancia, recuperación y continuidad. Implementamos clusters, balanceadores, backups, replicación, enlaces alternativos, recuperación ante desastres y procedimientos de contingencia porque sabemos que ningún componente tecnológico debería considerarse infalible.

Sin embargo, muchas de las primeras arquitecturas construidas alrededor de inteligencia artificial vuelven a introducir una dependencia bastante sencilla:

Aplicación → API → LLM.

Si el modelo responde, todo funciona. Si no responde, el proceso se detiene.

El problema no está en utilizar un servicio cloud. El cloud ofrece capacidades extraordinarias y, para determinadas tareas, probablemente seguirá siendo la mejor alternativa. El problema aparece cuando un proceso crítico depende de un único proveedor, de una única API o incluso de una única forma de ejecutar la inteligencia que necesita.

Por eso Edge AI empieza a ser interesante no solamente desde la perspectiva de privacidad o rendimiento, sino también desde el punto de vista de arquitectura y gestión del riesgo.

La idea de Edge AI consiste en ejecutar parte de la inteligencia mucho más cerca de donde se generan los datos, ya sea en un dispositivo, un servidor local, un gateway o infraestructura propia. No significa necesariamente eliminar la nube ni intentar reproducir localmente las capacidades de los modelos más grandes del mercado. En muchos casos significa algo bastante más práctico: determinar qué funciones realmente necesitan depender de la nube y cuáles pueden mantenerse disponibles localmente.

Desde esa perspectiva, la discusión deja de ser “cloud versus local” y se convierte en una decisión de distribución de capacidades.

No todo necesita el modelo más grande

Uno de los argumentos habituales a favor de los grandes modelos de lenguaje es su enorme capacidad generalista. Pueden redactar, resumir, programar, analizar textos, conversar sobre prácticamente cualquier tema y resolver problemas que requieren niveles importantes de razonamiento.

Pero no todos los procesos empresariales necesitan esa amplitud.

Una organización que clasifica determinados documentos, extrae información de formatos conocidos, procesa audio, identifica patrones concretos o consulta una base documental interna podría obtener resultados satisfactorios utilizando modelos más pequeños o especializados. En algunos casos esos modelos pueden complementarse con información propia mediante RAG, ajustarse para una tarea específica o integrarse con reglas y componentes tradicionales.

La pregunta entonces no debería ser únicamente cuál es el modelo más potente que podemos utilizar, sino cuál es el nivel de inteligencia que realmente necesita cada parte del proceso.

Esta diferencia importa porque un modelo local puede reducir dependencias que desaparecen cuando toda la inferencia ocurre en infraestructura propia. Ya no es necesario enviar cada operación a una API externa, y determinadas funciones pueden seguir disponibles incluso ante problemas de conectividad o indisponibilidad del proveedor.

Naturalmente, esto no convierte a Edge AI en una solución mágica. El servidor puede fallar, la GPU puede presentar problemas, el almacenamiento puede quedar indisponible y los modelos necesitan actualización, monitoreo y seguridad. La privacidad tampoco deja de ser un problema simplemente porque los datos permanezcan localmente: siguen existiendo riesgos relacionados con accesos, respaldos, credenciales, logs y administración de infraestructura.

El riesgo no desaparece. Cambia de manos.

Y precisamente ahí está una de las decisiones arquitectónicas más interesantes.

Lo que estoy viendo con ELISA

Trabajando en ELISA me encontré con esta decisión de una manera bastante práctica. Para determinadas capacidades opté por utilizar infraestructura propia y ejecutar modelos localmente en lugar de convertir cada operación en una llamada hacia un servicio externo.

Una de las razones iniciales fue el costo. Cuando ya existe capacidad de cómputo disponible, determinadas cargas pueden ejecutarse localmente sin generar un costo variable por cada token, consulta o minuto procesado. Esto no significa que la infraestructura local sea siempre más económica; mantener hardware también tiene costos de adquisición, electricidad, administración, almacenamiento y mantenimiento. La relación depende del volumen, del tipo de modelo y de la carga de trabajo.

Sin embargo, al trabajar con esta arquitectura apareció otra ventaja que inicialmente no era tan evidente: algunas funciones dejan de depender de que una API externa esté disponible.

ELISA Transcribe, por ejemplo, procesa audio utilizando infraestructura propia para realizar la transcripción. Esto permite controlar mejor el flujo de procesamiento y evita que el núcleo del servicio dependa exclusivamente de una plataforma externa para ejecutar esa función.

La experiencia también deja claro el otro lado de la ecuación. Cuando la inteligencia se ejecuta sobre infraestructura propia, también asumimos responsabilidades que antes pertenecían al proveedor: capacidad, monitoreo, disponibilidad, actualizaciones, seguridad y recuperación.

Por eso no veo Edge AI como una competencia contra la nube. Lo veo como una opción adicional dentro de una arquitectura más resiliente.

Diseñar una IA que pueda degradarse sin detenerse

En sistemas tradicionales existe un concepto bastante conocido: operación degradada. Cuando un componente falla, el sistema puede perder algunas capacidades, pero mantiene disponibles las funciones esenciales.

Podríamos empezar a aplicar el mismo principio a las arquitecturas de inteligencia artificial.

Una aplicación podría utilizar normalmente un modelo cloud de altas capacidades para tareas complejas, pero mantener un modelo local para funciones básicas o críticas. Si el proveedor principal deja de estar disponible, el sistema no tendría necesariamente que comportarse exactamente igual; podría entrar temporalmente en un modo de operación limitado.

La arquitectura podría incluso combinar varios niveles: un modelo principal en la nube, otro proveedor como alternativa, modelos locales para determinadas funciones y, cuando corresponda, procedimientos manuales para situaciones excepcionales.

No todas las organizaciones necesitan esa complejidad. Un asistente utilizado ocasionalmente para mejorar la redacción de correos probablemente no requiere un plan de recuperación. Pero la situación cambia cuando la inteligencia artificial empieza a participar directamente en procesos de negocio cuya interrupción tiene consecuencias económicas u operativas.

En ese momento, el modelo deja de ser simplemente una herramienta y pasa a ser parte de la arquitectura.

Edge AI también puede ser una estrategia de riesgo

Cuando hablamos de Edge AI solemos concentrarnos en tres beneficios: menor latencia, mayor privacidad y menor dependencia de conectividad. Son argumentos importantes, pero quizá estamos dejando fuera otro igualmente relevante.

La continuidad.

Una estrategia de inteligencia artificial madura no debería limitarse a decidir qué modelo utilizar. También debería considerar qué ocurre cuando ese modelo no está disponible, qué funciones realmente requieren conectividad permanente, qué cargas pueden ejecutarse localmente y qué capacidades mínimas deberían mantenerse si falla el proveedor principal.

Eso no significa que todas las empresas deban instalar GPUs en sus oficinas ni desarrollar sus propios modelos. En muchos casos la mejor arquitectura seguirá siendo completamente cloud. En otros, una combinación de modelos externos y locales puede ofrecer un equilibrio más razonable entre capacidad, costo, privacidad y disponibilidad.

Lo importante es que esa decisión sea consciente y forme parte del diseño.

Hace tiempo dejamos de diseñar infraestructura suponiendo que un servidor nunca iba a fallar. Tal vez también tengamos que dejar de diseñar soluciones de inteligencia artificial suponiendo que el modelo que utilizamos hoy siempre estará disponible exactamente en las mismas condiciones.

Porque a medida que la IA se integra en procesos cada vez más importantes, la pregunta ya no es solamente qué modelo utilizamos.

También tendremos que preguntarnos:

Si mañana desapareciera el LLM del que depende mi solución, ¿mi operación seguiría en pie?