IBM lanzó el 1 de octubre la versión self-hosted y air-gapped de Bob, su plataforma de coding agents que ya usan más de 80,000 empleados internos de IBM con una ganancia reportada de productividad del 45%. La promesa es simple: bancos, aseguradoras y gobiernos que nunca han podido meter un agente de código a su operación —porque la política interna les prohíbe sacar código de su red— ahora pueden correr el mismo tipo de agente dentro de su propia infraestructura, sin que una sola línea toque un servidor externo. Lo que no está en el anuncio oficial, y sí en la letra chica que fueron destapando varios medios técnicos esta semana, es el precio real de esa soberanía: para correr Bob completamente aislado, tienes que dejar de usar Claude o GPT y conformarte con modelos que, según los propios benchmarks de sus fabricantes, rinden hasta 15 puntos menos en tareas de código. Importa hoy porque es la primera vez que un proveedor grande pone sobre la mesa, con números, cuánto cuesta en calidad la decisión de mantener el código 100% dentro de la red de un cliente regulado.
Qué cambia exactamente con Bob self-hosted
La versión SaaS de Bob, lanzada en abril de 2026, enruta cada tarea entre Claude de Anthropic, modelos abiertos de Mistral y Granite de IBM, eligiendo dinámicamente según precisión, desempeño y costo. La versión self-hosted, anunciada este 1 de octubre, funciona distinto: corre sobre un solo modelo central, sin la opción de combinar varios al mismo tiempo, y está pensada para desplegarse on-premises, en nube privada, nube soberana o redes completamente air-gapped.
Según Neel Sundaresan, gerente general de IA y Automatización de IBM, la razón es directa: "las organizaciones necesitan IA que opere dentro de entornos que ellas controlan, especialmente cuando trabajan con código sensible y datos regulados." La plataforma mantiene el mismo IDE, el mismo BobShell, el mismo agent harness, skills y modos que la versión en la nube — lo que cambia de fondo es qué modelo hace el trabajo pesado.
El precio real: qué pierdes al salir de la nube
Para el despliegue totalmente local, IBM soporta hoy solo dos modelos: NVIDIA Nemotron 3 Ultra (550 mil millones de parámetros, 55B activos) y Poolside Laguna S 2.1 (118B totales, 8B activos). Ninguno de los dos acepta imágenes como input, así que cualquier flujo que dependa de mandarle un screenshot o un diagrama al agente simplemente no funciona en esta configuración.
Los números de la brecha
- En Terminal-Bench 2.1, Nemotron 3 Ultra marca 56.4 puntos; Laguna S 2.1 llega a 70.2% con "thinking" activado.
- En SWE-Bench, Nemotron saca 70.7%, mientras Laguna se mueve entre 59.4% y 78.5% dependiendo de la configuración.
- Según los propios reportes de Poolside, Laguna queda entre 10 y 15 puntos por debajo de los sistemas cerrados de OpenAI y Anthropic en Terminal-Bench.
- Bob self-hosted además pierde el registro y monitoreo de eventos de seguridad que sí trae de fábrica la versión en la nube — esa responsabilidad se traslada a los logs de OpenShift, la plataforma sobre la que corre obligatoriamente el despliegue local.
IBM sí ofrece una opción híbrida, donde el modelo local puede llamar a Claude Sonnet 5.0, Claude Opus 4.8, Gemini 3.7 Flash o GPT 5.6 Sol vía endpoints compatibles con OpenAI, AWS Bedrock o Google Vertex AI. Pero aquí hay un detalle que ningún comunicado menciona con claridad: la documentación de IBM no explica qué control técnico impide que código restringido viaje hacia esos modelos externos cuando se activa el modo híbrido. Por ahora, esa frontera depende de política interna, no de una barrera técnica forzada por la plataforma.
Por qué, aun así, tiene sentido para bancos y gobierno
El dato que explica por qué IBM se tomó la molestia de construir esto viene de su propio Institute for Business Value: 68% de los ejecutivos encuestados dijo que cumplir con requisitos de residencia y soberanía de datos entre distintas geografías es un reto significativo. El mercado al que apunta Bob self-hosted no es "cualquier agencia que quiera ahorrarse unos dólares de API" — es bancos, aseguradoras, gobiernos y operadores de infraestructura crítica que literalmente rechazaron Claude Code y GitHub Copilot en el pasado por restricciones de salida de código ("code-egress"), no por falta de presupuesto. Para ese tipo de cliente, perder 10 o 15 puntos de benchmark puede seguir siendo mejor negocio que arriesgarse a una violación de cumplimiento regulatorio o a una fuga de código fuente de un sistema core de banca.
Lo que todavía no está resuelto
IBM no publicó precio para el despliegue self-hosted. Lo que sí sabemos: se cobra por licencia negociada (con opción "bring-your-own-license" para quien ya tiene contratado alguno de los modelos soportados), más el costo de GPUs, más la infraestructura de OpenShift — todo como líneas separadas. Y los requerimientos de hardware no son triviales: Nemotron pide 8 GPUs B200/B300, 8 H200, o 16 H100; Laguna necesita al menos un NVIDIA DGX Spark completo, con capacidad adicional si se va a escalar más allá de un solo developer. Para comparar, la versión SaaS cuesta entre $20 y $200 USD al mes por usuario. La brecha entre "pagar una suscripción" y "comprar o rentar un clúster de GPUs con OpenShift" es enorme, y todavía no hay cifra pública que permita hacer esa cuenta completa.
Lo que esto significa para agencias y developers
Si tienes clientes en sectores regulados —banca, seguros, salud, gobierno— en LATAM, esto es una plantilla de conversación que vas a tener que tener pronto, con IBM o sin IBM:
- Separa "dónde vive el código" de "qué tan bueno es el agente". Son dos decisiones distintas y a veces están en tensión directa, como muestra este caso: ganas soberanía, pierdes puntos de benchmark. Haz que el cliente decida con los números sobre la mesa, no con la promesa de marketing.
- Pregunta explícitamente por el logging de seguridad antes de recomendar cualquier despliegue on-premises. Que la responsabilidad de auditoría se mueva a los logs de la plataforma base (en este caso OpenShift) no es un detalle menor — es trabajo adicional de configuración que alguien tiene que hacer bien desde el día uno.
- No asumas que "híbrido" significa que el código sensible está realmente contenido. Si vas a diseñar o auditar un despliegue híbrido de cualquier agente de código, exige ver el control técnico — no solo la política — que impide que ese código llegue a un modelo externo.
- Cotiza la infraestructura completa, no solo la licencia. Entre GPUs, clúster de OpenShift y el modelo con licencia aparte, el costo real de "soberanía" para un cliente regulado puede ser varias veces lo que paga hoy por una suscripción en la nube — y esa es información que tu cliente necesita antes de firmar, no después.
La lección de fondo conecta con algo que seguimos viendo una y otra vez este año: no existe una opción sin trade-offs entre autonomía, control y capacidad. Cada vez que un proveedor te da más soberanía sobre tus datos, en algún lado del sistema estás pagando ese control con algo —rendimiento, velocidad, visibilidad de seguridad o dinero en infraestructura. El trabajo de una agencia seria no es vender "la opción segura" o "la opción potente" como si fueran gratis; es ayudar al cliente a ver exactamente qué está cediendo en cada dirección, antes de que lo descubra en producción.
Si tienes un cliente en banca, gobierno o cualquier sector regulado evaluando si vale la pena correr agentes de código fuera de la nube pública, o si ya estás armando ese caso de negocio y quieres una segunda opinión sobre los números reales de infraestructura, escríbenos a comercial@geekvibes.agency.
