Los agentes de IA con SLMs locales son la apuesta de AWS en su nuevo Adaptive Agentic Intelligence Framework (AAIF), un framework construido con Strands Agents que decide dónde se resuelve cada petición en lugar de enviarlo todo a un único LLM grande. La idea es sencilla: un modelo pequeño reparte el trabajo, otro local ejecuta lo rutinario y Amazon Bedrock se reserva para el análisis complejo. Para PYMEs y equipos de desarrollo con el presupuesto de API ajustado, el planteamiento merece atención, aunque conviene leerlo con cabeza.
Qué ha publicado AWS y por qué importa a quienes montan agentes
AWS ha presentado AAIF como un framework que reparte las peticiones de un agente en tres capas. La primera es un orquestador basado en un SLM, concretamente llama3.2:1b, que recibe la consulta y decide a quién corresponde. La segunda es el procesamiento local con Ollama, donde se resuelven las tareas rutinarias sin salir de la máquina o de la red propia. La tercera es el análisis complejo, que se delega en modelos de Amazon Bedrock cuando el problema lo justifica. Es decir, el modelo grande y caro deja de ser la puerta de entrada y pasa a ser un recurso al que se recurre solo cuando hace falta.
El argumento de venta es triple: menos coste de API, menos latencia y menos dependencia de la nube. Además, las tareas rutinarias pueden funcionar sin conexión, algo que importa en instalaciones industriales, almacenes o sedes con conectividad irregular. Conviene precisar que estos beneficios son los que plantea el diseño del framework; la información publicada no incluye cifras de ahorro ni benchmarks comparativos, así que cualquier número tendrás que medirlo en tu propio caso.
El contexto ayuda a entender el movimiento. Lo habitual al construir un agente es conectarlo a un LLM potente y dejar que resuelva todo, desde la consulta trivial hasta el razonamiento difícil. Cada llamada consume tokens y añade latencia, y la factura crece con el uso. Los SLM (small language models) y herramientas como Ollama, que permite ejecutar modelos en local, han hecho viable otra opción: reservar la nube para lo que realmente la necesita.
Cómo funciona el reparto: tres capas y tres herramientas
La implementación de referencia es un caso de monitorización IoT con tres herramientas. La primera, get_device_telemetry, se ocupa de la telemetría de los dispositivos, el tipo de consulta frecuente y repetitiva que no necesita un modelo grande. La segunda, analyze_camera_feed, analiza imágenes de cámara con llama3.2-vision, un modelo con capacidad de visión que se ejecuta en la capa local. La tercera, get_expert_insights, es la que sube de nivel: llama a modelos de Amazon Bedrock mediante boto3, el SDK de AWS para Python, para el análisis que exige más razonamiento.
Este diseño tiene una consecuencia técnica clara: el orquestador pasa a ser una pieza crítica. Un modelo de 1b parámetros decide qué herramienta se invoca, así que la calidad del enrutado depende de lo bien que un modelo tan pequeño interprete la intención del usuario. Si clasifica mal, una consulta compleja puede acabar resuelta por una capa insuficiente, o una trivial puede viajar a Bedrock y generar coste innecesario. Es el punto que más conviene probar antes de llevar algo así a producción.
Por otro lado, el uso de Strands Agents como base mantiene el patrón reconocible: las capacidades del agente se expresan como herramientas que el orquestador elige. Para un equipo que ya trabaje con funciones Python y boto3, la barrera de entrada es baja. El esfuerzo real está en otra parte: preparar la capa local, con hardware capaz de mover los modelos, y definir con criterio qué tareas se consideran rutinarias y cuáles merecen el modelo grande.
Cómo pueden aplicar esto las empresas hoy
Lo primero es revisar qué hace hoy tu agente, o el que estés planeando. Recopila una muestra de consultas reales y sepáralas en rutinarias (consultar un estado, leer un dato, clasificar algo simple) y complejas (interpretar un patrón, razonar sobre varias fuentes). Si la mayoría cae en el primer grupo, un esquema de agentes de IA con SLMs locales tiene sentido económico. Si casi todo es complejo, el ahorro será pequeño y la complejidad añadida no compensará.
Después, monta un prototipo acotado, siguiendo el esquema de referencia: un orquestador pequeño, una o dos herramientas locales con Ollama y una herramienta que llame a Bedrock. Mide tres cosas antes y después: coste de API por consulta, latencia y porcentaje de peticiones bien enrutadas. Sin esos datos, la decisión es una intuición.
Qué evitar: migrar todo de golpe, dar por bueno el enrutado del SLM sin evaluarlo y subestimar el coste del hardware y del mantenimiento locales. Ejecutar modelos en tus propios equipos elimina parte de la factura de API, pero traslada trabajo a tu equipo técnico. Para una PYME con instalaciones distribuidas o conectividad limitada, el beneficio de operar sin conexión puede pesar más que el ahorro directo, y ese es un criterio legítimo para empezar por ahí.
Análisis Blixel
Mandar cada pregunta trivial a un modelo enorme es como pedir a un consultor senior que lea el contador de la luz: funciona, pero es absurdo pagarlo. Por eso el patrón que defiende AWS es sensato, y no solo para quien ya vive en su nube. Separar el trabajo según su dificultad es ingeniería básica aplicada a los agentes, y era cuestión de tiempo que un proveedor lo empaquetara.
Dicho esto, hay que mantener los pies en el suelo. Lo publicado es una implementación de referencia en un caso de IoT, sin cifras de ahorro, sin datos de precisión del enrutado y con un orquestador de apenas 1b parámetros tomando decisiones importantes. Es una buena plantilla para aprender y prototipar, no una prueba de que el modelo funcione en cualquier negocio. Tampoco hay que olvidar que el framework empuja, con naturalidad, hacia Bedrock en la capa de análisis complejo.
Mi posición: los agentes de IA con SLMs locales van a ser la configuración razonable por defecto para tareas repetitivas, y las empresas que midan sus consultas pronto tendrán ventaja en costes. Pero la ventaja no vendrá de copiar AAIF, sino de entender cuántas de tus peticiones necesitan de verdad un modelo grande. Empieza pequeño, mide con honestidad y deja que los datos decidan cuánta nube necesitas.
¿Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido común. Hablemos.