IBM Bob se adentra en el firewall, y ese es precisamente el punto

IBM ha empezado a ofrecer su plataforma de desarrollo de software agéntico, IBM Bob, en formato autoalojado. Las implementaciones on-premises, en nube privada, nube soberana y en entornos aislados (air-gapped) están todas sobre la mesa. Los clientes eligen su propia configuración de modelo, mantienen el código fuente y el contexto de las aplicaciones dentro de su propia red, y conservan el control sobre la residencia de datos y la política de seguridad.

Eso suena a una nota al pie sobre la implementación. Se parece más a una tesis sobre quién puede usar agentes de programación en absoluto.

La brecha que cierra el autoalojamiento

Los agentes de programación han avanzado rápido. Leen un repositorio, proponen cambios, ejecutan pruebas y abren pull requests. Para una startup, conectar uno a un servicio en la nube es cosa de una tarde de martes. Para un contratista de defensa, un banco o un sistema hospitalario, el mismo movimiento falla en la primera revisión legal. El código fuente no puede salir del edificio. El contexto interno, ese conocimiento institucional desordenado que hace comprensible una base de código, tampoco puede salir. Los entornos aislados no tienen ruta a la nube, por diseño.

Por qué esto es más difícil de lo que parece

Un agente es más fácil de entender como un bucle que como una cosa única: planificar, actuar, observar, ajustar. En la nube, las herramientas que invoca son servicios, y los modos de fallo son problema de otro. Detrás de un firewall, el agente tiene que llegar a los mismos repositorios, los mismos gestores de tickets, los mismos sistemas de compilación, salvo que ahora la red está segmentada, las credenciales rotan según un calendario y la mitad de los servicios se actualizaron por última vez antes de que la palabra “agente” significara algo.

El argumento de venta de IBM se apoya en que ya vende a estos entornos. Sus clientes ejecutan mainframes y sistemas heredados que nadie más quiere tocar. Hacer que un agente funcione allí es poco glamuroso, lento y exactamente el tipo de trabajo que crea un foso competitivo.

También hay un ángulo de gobernanza, y es el que no deja de surgir. Un agente autoalojado produce registros que son tuyos. En una auditoría regulada, puedes mostrar exactamente qué modelo se ejecutó, qué leyó y qué cambió. En una configuración en la nube, esa evidencia está repartida entre la consola de un proveedor y un acuerdo de servicio. Cuando algo sale mal, la diferencia entre “tenemos los registros” y “hemos solicitado los registros” es la diferencia entre un incidente cerrado y un trimestre de descubrimiento de pruebas.

La cuestión del modelo subyacente

Autoalojar un agente significa autoalojar un modelo, o al menos elegir uno que puedas poner en tu propio hardware. IBM permite a los clientes seleccionar configuraciones compatibles, lo que en la práctica significa una mezcla de modelos de pesos abiertos y de IBM. Las opciones de pesos abiertos importan aquí. Un modelo de clase 70B ejecutándose en un clúster privado es más lento y menos capaz que el mejor modelo alojado. También está disponible cuando la red está caída, cuando el proveedor sube los precios o cuando el proveedor decide que tu caso de uso infringe una política que nunca leíste.

Las empresas han hecho este intercambio durante una década con las bases de datos, y funciona igual: aceptan una brecha de capacidades a cambio de control, y luego cierran la brecha con el tiempo a medida que mejora el hardware.

La economía se ve distinta detrás de un firewall

Los agentes de programación en la nube tienen un precio por token, lo que significa que el costo escala con la cantidad de código que el agente lee y escribe. Para una startup, eso es una partida predecible. Para una gran empresa, donde un solo repositorio puede contener décadas de historial y el agente tiene que ingerir mucho más contexto antes de poder ayudar, el contador se dispara.

El autoalojamiento invierte el modelo. El costo pasa a ser hardware y operaciones, que son gastos de capital que la organización ya asume. Un banco con un centro de datos no paga más cuando el agente lee otro millón de líneas. El costo marginal de una tarea adicional del agente se acerca a la electricidad y al tiempo de GPU, y esos son costos hundidos. Esa asimetría es la razón por la que el argumento autoalojado funciona incluso cuando el producto en la nube es objetivamente mejor.

Sin embargo, hay un costo de cumplimiento que el marketing omite. El autoalojamiento traslada la carga de los parches, la supervisión y las actualizaciones del modelo al cliente. Un proveedor de nube lanza una corrección y listo. Una implementación on-premises tiene que programar la actualización, probarla contra los sistemas internos y sobrevivir a un comité de control de cambios. La herramienta es más controlable y da más trabajo, y ese intercambio es toda la historia del software empresarial.

El mercado adyacente que hace esto viable

Autoalojar un agente solo funciona si hay algo que valga la pena ejecutar detrás del muro, y esa oferta ha crecido. Los modelos de pesos abiertos dentro del rango que puede hacer trabajo de programación real ahora son comunes, publicados bajo licencias permisivas por laboratorios de varios continentes. La pieza que faltaba nunca fue el modelo. Era el arnés que convierte un modelo en algo a lo que un desarrollador puede delegar dentro de una red controlada.

Esa es la capa que vende IBM. Entrenar el mejor modelo no es el objetivo. Ser la integración que hace utilizable un modelo existente en los lugares donde una llamada a la nube no es una opción es el objetivo. La estrategia es la imagen espejo de los laboratorios que priorizan la API. Ellos empujan la capacidad hacia fuera y dejan que cualquiera se conecte. IBM atrae la capacidad hacia dentro y hace que sobreviva al perímetro.

Para los compradores atrapados en ese perímetro, la elección ha sido desagradable durante dos años: ver la ola de los agentes desde lejos o romper una regla de seguridad para unirse a ella. Una opción autoalojada no hace que la ola sea más pequeña. Solo la hace alcanzable, lo que para una organización regulada es lo mismo que hacerla real.

Qué hay que observar

Las demos no son la pregunta honesta sobre la programación agéntica autoalojada. La pregunta honesta es si los resultados se mantienen en una base de código con quince años de deuda técnica, escrita por personas que ya dejaron la empresa. Los agentes en la nube también tienen dificultades con eso. La diferencia es que un agente autoalojado no puede ser mejorado por un proveedor de la noche a la mañana sin que el cliente haga el trabajo. Cada avance tiene que ganárselo el propio equipo del cliente.

Eso hace que la adopción sea más lenta y más pegajosa, lo que le conviene a IBM. Está construyendo para compradores que miden el éxito en años, no en sprints, y que prefieren poseer una herramienta un poco peor que alquilar una mejor que no pueden inspeccionar. Para un mercado de agentes de programación que ha pasado dos años persiguiendo benchmarks, esa es una apuesta conservadora. También es una apuesta por la parte del mercado que aún no ha sido atendida.

Hay una versión de esto que termina mal. Las herramientas autoalojadas tienen reputación de lanzarse una vez y luego quedarse estancadas, porque el proveedor no tiene un incentivo recurrente para mejorarlas y el cliente no tiene poder de negociación para exigirlo. Si IBM Bob se asienta como un producto estable que nunca mejora de forma significativa, los compradores que atraiga obtendrán exactamente lo que pidieron y menos de lo que esperaban. La alternativa, en la que un agente autoalojado mejora según un calendario que controla el cliente, es más difícil de gestionar y mucho más valiosa. Cuál de las dos entrega IBM es lo que hay que observar durante el próximo año.