Hace unos meses, renovar un SaaS era casi un trámite. Se revisaba el precio, se comparaba con el año anterior y, salvo un aumento demasiado agresivo, se aprobaba sin mucha discusión. Eso está cambiando. En varias empresas con las que hemos conversado últimamente, la conversación de renovación ya no es solo sobre precio: es sobre si esa suscripción sigue siendo necesaria cuando un agente, bien configurado, puede hacer buena parte de lo mismo.
A este fenómeno se le empezó a llamar "agentic arbitrage": la posibilidad de reemplazar una herramienta que se pagaba mes a mes por un agente que ejecuta la misma tarea a un costo marginal mucho menor. Tiene sentido que esté pasando. Muchas suscripciones de software resuelven procesos relativamente simples (generar un reporte, mover datos entre dos sistemas, mandar una notificación con cierta lógica) y ese tipo de trabajo es exactamente donde un agente rinde bien. El error sería pensar que esto convierte la decisión en un simple "construir siempre gana". No es así, y tratarlo como una regla general es donde empiezan los problemas.
Lo primero que conviene aclarar es que no todo SaaS es candidato a reemplazo. Hay una diferencia real entre una herramienta que resuelve un proceso acotado y bien entendido, y una que además trae integraciones, cumplimiento normativo, actualizaciones constantes y soporte detrás. Reemplazar la primera con un agente puede ser una buena decisión de negocio. Reemplazar la segunda con algo construido a la rápida suele salir caro más adelante, aunque no se note el primer mes. El criterio práctico no debería ser "¿puedo construirlo?", que casi siempre la respuesta es sí, sino "¿quién lo va a mantener, actualizar y asegurar cuando la persona que lo armó ya no esté mirando ese proceso?".
El problema que no se está discutiendo
Ahí aparece un fenómeno que estamos viendo con más frecuencia en clientes, y que todavía no tiene suficiente atención dentro de las conversaciones de adopción de IA. Ahora es tan fácil programar con ayuda de un agente que, dentro de muchas organizaciones, cualquier persona se convirtió en desarrollador sin proponérselo. No hablamos de un ingeniero de software armando una herramienta interna con criterio de arquitectura. Hablamos de alguien de un área de negocio que, con acceso a Claude o a otro asistente similar, construyó un sitio en Node, con su propia base de datos, corriendo en su computador personal, y que en algún momento ese proceso terminó siendo parte de un flujo real de trabajo del equipo.
Esto es distinto al shadow AI del que se habla habitualmente. No es una herramienta no autorizada: la licencia se la dio TI, con buena intención y buscando fomentar la adopción. El problema no está en el permiso, está en lo que se construyó con ese permiso y en la falta de visibilidad sobre eso. Un asistente de IA corriendo en un navegador es relativamente fácil de gobernar. Una aplicación con su propia base de datos, corriendo fuera de cualquier entorno gestionado, sin respaldo, sin control de acceso formal y sin que seguridad o TI sepan que existe, es un riesgo de otra naturaleza. Si esa aplicación guarda datos de clientes, información financiera o cualquier dato sensible, la empresa tiene una exposición real que nadie decidió conscientemente asumir.
El riesgo no termina en seguridad. También es un problema de continuidad y de cumplimiento. Si esa persona cambia de rol o deja la empresa, ese proceso queda huérfano, sin documentación y sin nadie que entienda cómo se sostiene. En sectores regulados, además, ese tipo de herramientas informales suelen no cumplir con los mismos estándares que la empresa exige a sus proveedores de software, simplemente porque nunca pasaron por ese filtro.
Cómo pensarlo con criterio
La conclusión no es que haya que prohibir que las personas construyan nada, ni tampoco que haya que dejar todas las suscripciones tal como están por miedo a los riesgos. Las dos posturas extremas son cómodas y las dos son equivocadas. Hay suscripciones que efectivamente conviene reemplazar, porque el proceso es simple, el volumen es bajo y un agente lo resuelve mejor y más barato. Hay otras que conviene mantener, precisamente porque la complejidad, el cumplimiento o la integración con otros sistemas hacen que construirlo internamente sea más caro de lo que parece a primera vista.
Lo que sí necesita atención inmediata es el desorden que puede generarse en el camino: equipos completos empezando a desarrollar por su cuenta, cada uno con su propio criterio, sin un mínimo de gobierno sobre dónde vive esa aplicación, qué datos toca y quién es responsable de mantenerla. La misma facilidad que permite evaluar con seriedad si conviene reemplazar un SaaS es la que, sin dirección, puede llenar una organización de aplicaciones caseras que nadie audita. La pregunta que debería hacerse cada empresa no es solo cuáles suscripciones vale la pena reemplazar con un agente, sino quién tiene visibilidad de todo lo que ya se está construyendo puertas adentro.
