Por qué IBM se fue hacia los agentes
Un cliente corporativo rara vez compra un modelo por sus demos vistosas. Necesita que el software haga algo: procesar tickets, conciliar facturas, llamar a APIs internas, redactar resúmenes de documentos. Es precisamente ese nicho el que ocupa la lógica agéntica: cuando el modelo no solo responde a una pregunta, sino que decide por sí mismo qué herramienta invocar a continuación.
Granite 4.2 en esta historia no es "otro modelo grande más", sino un intento de IBM de completar su línea para que funcione con la misma solidez tanto en la nube como en el entorno cerrado del cliente. La apuesta se basa en la combinación de tres cosas: pesos abiertos, requisitos modestos de hardware y un comportamiento predecible al invocar funciones externas.
Qué es exactamente la línea Granite
IBM lleva años manteniendo una familia de modelos abiertos bajo el nombre común de Granite. Durante este tiempo se ha consolidado una filosofía reconocible: los modelos se lanzan en varios tamaños, están orientados en primer lugar al código, el trabajo con tablas, la extracción de datos de documentos y los escenarios corporativos, y no a competir en benchmarks generales de chat.
Los tamaños importan
La línea se construye como una escalera: desde variantes muy pequeñas que caben en una sola tarjeta gráfica o incluso funcionan en un procesador, hasta modelos de gama media. La idea es que para cada tarea se pueda elegir el tamaño mínimamente suficiente. Para un agente que principalmente enruta solicitudes e invoca funciones, un modelo gigante suele ser excesivo: es más caro en inferencia y responde más lento.
Arquitectura híbrida
En la cuarta rama de la familia, IBM pasó a un esquema híbrido en el que parte de las capas se basan en Mamba y parte en la atención clásica del transformer. La ventaja práctica aquí es prosaica: el contexto largo se procesa más barato, la memoria se consume de forma más económica y el rendimiento en el mismo hardware es mayor. Para los escenarios agénticos esto es crítico, porque en el contexto se cargan constantemente los resultados de las llamadas a herramientas, fragmentos de documentos y el historial de pasos.
Licencia sin sorpresas
Los modelos Granite se distribuyen bajo la licencia Apache 2.0. Para un abogado corporativo es una noticia aburrida, y eso es precisamente una buena noticia: se puede hacer fine-tuning, integrar en un producto comercial, desplegar dentro del perímetro y no rendir cuentas al proveedor sobre cuánto ganó el producto.
El argumento principal: esto se puede tener en casa
Las APIs en la nube son cómodas justo hasta el momento en que los datos quedan sujetos a restricciones regulatorias. Un banco, una clínica, una empresa industrial o una entidad pública a menudo no pueden físicamente enviar parte de los documentos al exterior. Ahí es donde empieza la conversación sobre el "hardware propio".
Qué se necesita realmente para arrancar
Lo clave aquí no son los aceleradores de gama alta, sino un mínimo razonable. Las versiones pequeñas de Granite se levantan en una sola tarjeta de consumo, en un contenedor en un servidor sin GPU o en el portátil de un desarrollador. Los tamaños medianos ya requieren varias tarjetas o cuantización. El arranque suele hacerse mediante herramientas estándar como vLLM u Ollama, lo que elimina el problema de la dependencia de un stack exclusivo del proveedor.
Seguridad y previsibilidad
La segunda capa del argumento es el control. Cuando el modelo vive en tu propio entorno, tú decides qué logs escribir, qué datos entran en el prompt, qué se cachea y cuánto tiempo se almacena. Para los agentes esto es especialmente importante: son capaces de ejecutar acciones, no solo de generar texto, y cada una de esas acciones conviene hacerla pasar por tus propias reglas y auditoría.
IBM aquí vende no solo el modelo, sino también el andamiaje: la plataforma watsonx, un conjunto de modelos "guardianes" para filtrar contenido indeseado y herramientas de fine-tuning con datos propios. El modelo en ese esquema es un detalle, aunque sea el central.
Cómo se ve un escenario agéntico en la práctica
La idea del agente es simple: el modelo recibe una tarea, decide qué datos le faltan, invoca la herramienta necesaria, lee la respuesta y continúa hasta llegar al resultado. La diferencia entre "un simple chat" y un agente está en la existencia de un ciclo y de permisos.
Roles típicos para los que se afinan estos modelos:
- Enrutador. Analiza la solicitud entrante y decide a qué escenario derivarla.
- Extractor. Extrae campos de facturas, contratos, extractos y los coloca en una estructura.
- Ejecutor. Llama a las APIs de los sistemas internos: crea una solicitud, actualiza un estado, envía un correo.
- Revisor. Verifica el resultado del paso anterior y decide si se puede aceptar.
Un modelo pequeño en cada uno de estos pasos suele ser más ventajoso que uno grande: más barato, más rápido, más fácil de testear y, lo que no es poco, más sencillo de reemplazar si la calidad deja de convencer.
En qué fijarse y dónde están las limitaciones
Los modelos abiertos no son una píldora mágica, y una conversación honesta sobre las limitaciones es más útil que el marketing.
Tamaño frente a calidad de razonamiento
Los modelos pequeños son económicos, pero en tareas complejas de varios pasos todavía van por detrás de los grandes. El compromiso suele buscarse a nivel arquitectónico: se reparten los roles entre varios modelos pequeños, se añaden verificaciones deterministas en código, se deja al humano el derecho a la decisión final.
El ecosistema alrededor
Los pesos abiertos significan que el modelo se traslada fácilmente entre frameworks, desde LangChain hasta orquestadores propios. La otra cara: hay menos soluciones "de caja" listas para un sector concreto que en las plataformas propietarias, y parte del trabajo de integración recae en el equipo del cliente.
Hardware y coste de propiedad
El hardware propio no solo supone un ahorro en API, sino también costes de capital, electricidad, refrigeración y personas que lo mantengan todo. Para una empresa pequeña la nube casi siempre saldrá más barata; para una grande con datos sensibles, al contrario, y ese umbral se desplaza en función de los volúmenes.
Evaluación de la calidad
La principal trampa es medir al agente con benchmarks generales. Un agente que funciona se prueba en sus propios escenarios: un conjunto de tareas reales con una respuesta correcta conocida, la robustez ante datos de entrada basura y el comportamiento cuando la herramienta invocada devuelve un error. Sin ese conjunto, cualquier cifra de una nota de prensa sigue siendo una cifra de una nota de prensa.
Qué se deduce de todo esto
La reacción de IBM al momento actual del mercado parece lógica. Mientras unos persiguen la calidad máxima en la nube, otros cubren el nicho donde importan más el control, el precio por token y la posibilidad de desplegarlo todo dentro del perímetro. Pesos abiertos más requisitos modestos de recursos más un énfasis en la invocación de herramientas: justo el conjunto que necesita un cliente corporativo cansado de negociar el envío de datos al exterior.
La pregunta clave no es si la nueva versión superará a los líderes en las pruebas generales. La pregunta es si el equipo tendrá la disciplina suficiente para construir alrededor del modelo un circuito agéntico decente: con permisos limitados, auditoría, pruebas y un rollback claro. Si es así, mantener a ese agente en hardware propio se convierte en una estrategia perfectamente viable, y no en un compromiso.
