Ir al contenido principal
Soberanía Tecnológica: Mi Orquestador de IA Local

Soberanía Tecnológica: Mi Orquestador de IA Local

AI Integration
5 min readPor Daily Miranda Pardo

¿Por qué enviar cada consulta a la nube cuando puedes tener el "cerebro" en casa? Tras semanas de configuración e iteración, he terminado de desplegar mi propia arquitectura de agentes de IA integrada en local. En este artículo cuento cómo funciona, qué decisiones técnicas tomé y por qué la soberanía tecnológica es una apuesta real, no solo un titular.

El problema con depender 100% de la nube

Los proveedores cloud de IA son potentes, pero tienen costes que escalan rápido, latencias que varían y —lo más importante— todos tus datos pasan por sus servidores. Para proyectos propios o de clientes que requieran confidencialidad, esto supone una barrera real.

La alternativa: construir un orquestador local que decida qué tareas se resuelven en casa y cuáles merece la pena delegar a modelos externos especializados.

El hardware: Mac mini M4 con 32 GB de RAM

La elección del hardware no fue casual. El Mac mini M4 con 32 GB de RAM unificada ofrece una relación rendimiento/consumo difícilmente igualable para inferencia local:

  • Neural Engine de Apple Silicon: aceleración hardware nativa para modelos de lenguaje
  • 32 GB de memoria unificada: permite cargar modelos de 7B a 13B parámetros con total comodidad
  • Conectividad 10 Gbps: transferencias internas ultrarrápidas entre servicios del servidor
  • Consumo eficiente: funciona 24/7 sin disparar la factura eléctrica

Este servidor actúa como el núcleo de toda la arquitectura: siempre activo, siempre disponible en la red local.

El orquestador: Llama 3.2 vía Ollama

El corazón del sistema es un modelo Llama 3.2 corriendo localmente a través de Ollama. Su misión es actuar como el cerebro que recibe cada petición, analiza la intención y decide el flujo de trabajo más eficiente.

¿Qué hace exactamente el orquestador?

  1. Recibe la petición del usuario o del sistema automatizado
  2. Clasifica la intención: ¿es una tarea de código? ¿requiere datos en tiempo real? ¿es conversacional?
  3. Decide el flujo: resuelve localmente o delega en un subagente especializado
  4. Agrega la respuesta y la devuelve de forma coherente

Todo esto ocurre en milisegundos, sin latencia de red, sin coste por token en esta fase de triaje.

// Ejemplo simplificado de llamada al orquestador local vía API de Ollama
const response = await fetch("http://localhost:11434/api/generate", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    model: "llama3.2",
    prompt: `Analiza esta petición y clasifica la intención: "${userRequest}"`,
    stream: false,
  }),
});

const { response: intent } = await response.json();
// intent → "code_generation" | "realtime_data" | "conversational"

Subagentes especializados: cada tarea a su experto

La arquitectura brilla cuando el orquestador delega. No todos los modelos son igual de buenos en todo; la clave está en enrutar cada tarea al agente más capaz:

Claude (vía OpenRouter) → Código complejo

Para generación de código avanzado, refactorización o análisis arquitectónico, el orquestador invoca a Claude a través de OpenRouter. La razón es simple: Claude destaca en razonamiento técnico profundo y en mantener consistencia en proyectos grandes.

Grok → Datos en tiempo real

Cuando la tarea requiere información actualizada —noticias, precios, tendencias— se delega en Grok, cuya integración con fuentes de datos en tiempo real lo convierte en el agente ideal para este tipo de consultas.

Kimi → Contextos muy largos

Para documentos extensos, análisis de repositorios completos o tareas que requieren ventanas de contexto masivas, Kimi es la elección. Su capacidad para manejar millones de tokens lo hace irreemplazable en estos escenarios.

Privacidad y eficiencia: el triaje nunca sale de tu red

Una de las ventajas más valiosas de este diseño es que el triaje inicial siempre ocurre en local. Llama 3.2 analiza la petición, determina si contiene datos sensibles y solo entonces decide si es seguro enviarla a un proveedor externo.

Esto significa:

  • Cero exposición involuntaria: el orquestador puede redactar o bloquear datos confidenciales antes de cualquier llamada externa
  • Coste 0€ en triaje: miles de clasificaciones diarias sin un solo céntimo de gasto en API
  • Latencia predecible: el tiempo de respuesta local no depende de la carga de servidores externos

Optimizar hardware y software en armonía

Lo que hace que esta arquitectura funcione no es solo el hardware ni solo el software: es la sinergia entre ambos. Apple Silicon, Ollama, los modelos cuantizados y los proveedores externos se complementan en un sistema donde cada componente hace aquello para lo que está optimizado.

Algunos ajustes clave que marquaron la diferencia:

  • Usar modelos cuantizados a 4-bit (Q4_K_M) para maximizar velocidad sin perder demasiada precisión
  • Configurar Ollama con keep_alive extendido para evitar recargar el modelo en cada petición
  • Implementar un caché semántico para respuestas repetidas, reduciendo llamadas innecesarias

Escalar de forma real

Esta arquitectura no es un experimento: es la base de cómo gestiono proyectos de clientes que requieren integración de IA con privacidad de datos. Lo que hoy corre en un Mac mini M4 puede escalar mañana a un clúster de nodos sin cambiar la lógica del orquestador.

Si quieres implementar una arquitectura similar en tus productos o integrar flujos agénticos en tu stack existente, puedo ayudarte. Consulta mis servicios de integración de IA o descubre cómo el desarrollo impulsado por IA puede transformar tu proceso.

¿Tienes preguntas sobre el setup o quieres compartir tu propia arquitectura? Escríbeme y lo hablamos.

Compartir artículo

LinkedInXWhatsApp

Escrito por Daily Miranda Pardo

Consultora especializada en integración de IA en frontend y desarrollo web moderno.