# Cuando el software deja de ser predecible: sobre que el SaaS va a colapsar Satya Nadella dijo, sin mucho aspaviento, que las aplicaciones de negocio van a colapsar en la era de los agentes. Su argumento fue técnicamente correcto y brutalmente resumido: un CRM, un ERP, una herramienta de gestión de proyectos son esencialmente bases de datos con lógica de negocio encima. Cuando los agentes de IA puedan ejecutar esa lógica, el software como capa intermedia deja de tener sentido. El comentario generó la reacción habitual: posts sobre la hipocresía de un CEO de SaaS anunciando el fin del SaaS, iluminados augurando (por enésima vez en los últimos 20 años 🤦‍♂️) la caída de Microsoft, respuestas técnicas con arquitecturas de cuatro capas y términos en inglés que nadie necesita. Todos correctos en algún punto. Ninguno termina de explicar lo que realmente está pasando. Lo que está cambiando no es solo la capa de presentación ni la distribución de la lógica. Lo que está cambiando es el carácter del sistema: **de determinista a no determinista**. Y esa diferencia tiene consecuencias que van bastante más allá del debate sobre si el SaaS muere o se transforma. ## Lo que el software de negocio realmente es ![](./attachments/75-cuando-el-software-deja-de-ser-predecible.webp) Para entender qué cambia, conviene ser precisos sobre qué existe hoy. El software empresarial -cualquier CRM, ERP, plataforma de gestión, herramienta de operaciones- tiene siempre la misma estructura de fondo: una base de datos que contiene los datos del negocio, una capa de lógica que define qué operaciones se pueden hacer sobre esos datos, y una interfaz que permite a las personas ejecutar esas operaciones. La capa de lógica es la parte importante para este argumento. Esa lógica está programada de forma determinista: para cada acción posible, el sistema ejecuta un conjunto predefinido de instrucciones y produce un resultado predecible. Crea un cliente, actualiza un pedido, genera una factura, activa un flujo de aprobación. **El conjunto de acciones posibles es finito**. Está definido en tiempo de desarrollo. Si necesitas una funcionalidad que no existe, alguien tiene que programarla. La interfaz de usuario existe para que las personas puedan acceder a ese conjunto finito de funcionalidades. Los botones, formularios, menús desplegables y tablas no son un capricho de diseño: son la representación visual de un sistema cuyo espacio de posibilidades está completamente delimitado. El usuario no puede hacer nada que el desarrollador no haya previsto. Eso es exactamente el punto. Los datos persisten. La lógica es efímera en el sentido de que sin software que la ejecute, los datos siguen existiendo pero nadie puede operar sobre ellos. Por eso el vendor lock-in funciona: no solo tienes los datos atrapados en su formato, sino que tienes los procesos de negocio atrapados en su lógica. ## La transición: de funcionalidades finitas a inteligencia infinita ![](./attachments/75-cuando-el-software-deja-de-ser-predecible-1.webp) Lo que cambia con los agentes de IA no es que la lógica de negocio desaparezca. Es que deja de ser un conjunto finito de instrucciones deterministas para convertirse en una capa de inteligencia no determinista. Un agente que opera sobre la misma base de datos puede responder a cualquier instrucción formulada en lenguaje natural, no solo a las que un desarrollador anticipó. Puedes pedirle que analice qué clientes con más de tres años de antigüedad han reducido su ticket medio en los últimos seis meses y han tenido más de dos incidencias de soporte abiertas simultáneamente. Esa combinación no existía como funcionalidad en ningún CRM del mercado. En un sistema de agentes, es simplemente una instrucción sobre los datos. Eso es lo que significa que **el número de funcionalidades se vuelva prácticamente infinito**: no que el sistema sea omnipotente, sino que el espacio de operaciones posibles ya no está acotado por lo que alguien programó de antemano. Está acotado solo por los datos disponibles, la capacidad de razonamiento del agente y **la habilidad del usuario para formular instrucciones**. La consecuencia directa sobre la interfaz es obvia. Si el conjunto de funcionalidades es infinito, no se puede representar en botones y menús. Una interfaz basada en controles discretos no puede mapear un espacio ilimitado de operaciones: no hay suficientes botones. La única forma de acceder a eso es mediante lenguaje natural, y no por razones estéticas o de modernidad, sino estructurales. El input es lenguaje natural, texto o voz. El output es lo que sea adecuado: una respuesta en texto, una visualización, un artefacto, una acción ejecutada directamente sobre los datos. Hay una simetría aquí que merece atención: la interfaz de usuario basada en controles discretos no era un diseño arbitrario. Era el reflejo fiel de un sistema cuyo espacio de posibilidades era discreto y finito. Cuando ese espacio cambia, la interfaz tiene que cambiar con él por razones estructurales, no estéticas. ## Lo que nadie está discutiendo bien: la observabilidad ![](./attachments/75-cuando-el-software-deja-de-ser-predecible-2.webp) **Observabilidad**. Aquí es donde la mayoría de los análisis se quedan cortos, incluidos los que hablan de las declaraciones de Satya Nadella, aunque Microsoft es de los pocos que se lo está tomando en serio. En un sistema determinista, saber qué está haciendo el sistema es relativamente sencillo. O funciona o no funciona. Si no funciona, hay un error que se puede trazar: una excepción, un log, un mensaje de fallo. La lógica de negocio se comporta exactamente como fue programada, lo cual significa que el código es la documentación completa del comportamiento del sistema. Si quieres entender qué hace el sistema, lees el código. En un sistema no determinista, esto ya no es verdad. Un agente puede tomar dos decisiones distintas ante el mismo input dependiendo del contexto, de la formulación de la instrucción, del estado del modelo en ese momento. No hay un error binario: hay un espectro de comportamientos posibles, algunos más acertados que otros, pero ninguno directamente etiquetado como "correcto" o "incorrecto" por el sistema mismo. La lógica de negocio no se puede auditar revisando el código porque no existe como código: existe como comportamiento emergente de un modelo en ejecución. Esto tiene una implicación que va mucho más allá de la ingeniería: **la observabilidad deja de ser una función técnica para convertirse en una función de negocio**. En el modelo anterior a los agentes IA, la monitorización era cosa del equipo de tecnología. El código para generar trazas era sencillo, nada clave del sistema. Si el sistema fallaba, tecnología miraba los logs y encontraba el problema. Si todo funcionaba, la monitorización era irrelevante para el resto de la organización. El CFO no necesitaba saber qué había en los logs. El COO no necesitaba entender la trazabilidad del sistema. En el modelo de agentes, saber qué decisiones está tomando el sistema, sobre qué datos, con qué resultado y por qué razón es una pregunta de negocio, no solo técnica. Si un agente está gestionando aprobaciones de crédito, el equipo de riesgo necesita poder auditar sus decisiones. Si un agente está ejecutando procesos de compras, el equipo financiero necesita tener visibilidad sobre qué criterios está aplicando. Si un agente está tomando decisiones de pricing, el equipo comercial necesita entender cuándo y por qué modifica condiciones. > En muchos casos, cuando un sistema agéntico ofrece una respuesta, el usuario querrá entender cómo llegó ahí. Por eso las herramientas actuales -aún en una fase muy temprana- muestran el registro de razonamiento del modelo. Es el primer intento de hacer observable algo que por naturaleza no lo es. La trazabilidad de acciones, el linaje del dato, el registro inmutable de decisiones: todo esto era infraestructura técnica en el modelo determinista. En el modelo no determinista es la capa que hace que el negocio sea operable. Sin ella, tienes un sistema que actúa pero que nadie puede supervisar, que produce resultados pero que nadie puede explicar, que opera sobre datos pero que nadie puede auditar. En sectores regulados -finanzas, salud, legal- esto no es opcional, desde el primer día. Pero tampoco es opcional en cualquier organización que necesite rendir cuentas sobre sus decisiones, que tenga requisitos de compliance, o que simplemente quiera entender qué está haciendo su propio negocio. La observabilidad no es la parte glamurosa de esta transición. Precisamente por eso es la que menos aparece en los titulares y la que más va a determinar si la adopción de agentes funciona o produce caos bien camuflado. ## Lo que cambia en el moat del vendor ![](./attachments/75-cuando-el-software-deja-de-ser-predecible-3.webp) Cuando la lógica de negocio sale del software y entra en los agentes, el valor que construyeron los vendors de SaaS durante décadas se redistribuye de forma bastante desfavorable para ellos. Las funcionalidades propietarias pierden valor porque los agentes pueden replicar cualquier operación sobre los datos sin necesidad de que esa operación esté programada de antemano. La interfaz de usuario pierde valor porque se sustituye por lenguaje natural. Los flujos de trabajo codificados en el sistema pierden valor porque un agente puede ejecutar el mismo flujo a partir de una instrucción. Lo que no pierde valor -y de hecho lo gana- es el control sobre la capa de datos. Si la inteligencia está en el agente y los datos están en el sistema del vendor, quien tiene los datos tiene el negocio. El lock-in se puede volver más profundo que antes: antes estabas atrapado en la interfaz y en los procesos, ahora puedes estar atrapado directamente en el modelo de datos, en la semántica del dominio, en los identificadores y relaciones que hacen que tus datos sean operables. > Si tienes un SaaS cuyo proveedor te cobra por el acceso a los datos, prepara la cartera para el año que viene. La semántica del dominio es un concepto que va a ganar relevancia. Un conjunto de datos con definiciones precisas, relaciones bien modeladas y contexto de negocio incorporado es mucho más valioso para un agente que un conjunto de datos mal estructurado o sin documentar. La diferencia entre un agente que puede responder preguntas de negocio con precisión y uno que produce respuestas genéricas está muchas veces en la calidad del modelo de datos sobre el que opera, no en el modelo de IA en sí. > La semántica del dominio no es un problema nuevo: las **ontologías** llevan décadas intentando resolverlo. La diferencia es que ahora hay agentes que pueden usarlas directamente. Lo que antes era un ejercicio académico o una deuda técnica pendiente se convierte en ventaja competitiva real. ## Lo que cambia en el pricing y en el acceso ![](./attachments/75-cuando-el-software-deja-de-ser-predecible-4.webp) El pricing y el acceso al software empresarial también cambian, y de forma que **afecta directamente a cualquiera que compre o venda software hoy**. El modelo de pricing del SaaS -por usuario, por módulo, por funcionalidad activada- está construido sobre la premisa de que las funcionalidades son un conjunto finito que se puede tasar. Cuando ese conjunto se vuelve infinito, la unidad de precio tiene que cambiar. El mercado todavía no ha encontrado el modelo que se imponga: por outcome, por operación ejecutada, por consumo de capacidad de inferencia, por nivel de garantía sobre el comportamiento del agente. **El modelo por outcome es el más disruptivo** de todos porque alinea incentivos directamente con resultados de negocio -el vendor solo cobra si el agente produce algo de valor- pero requiere definir y medir ese outcome de forma objetiva, y eso es exactamente lo que la mayoría de organizaciones no saben hacer hoy. Ahí está el próximo problema. El acceso al software empresarial, por otro lado, se va a ampliar. Hoy, adoptar un ERP requiere formación, consultores, procesos de cambio, adaptación de la organización al software. Ese coste de adopción ha excluido históricamente a pymes y organizaciones con recursos limitados de capacidades que solo están al alcance de empresas grandes. La interfaz conversacional no elimina la complejidad del negocio, pero sí elimina la complejidad de aprender a usar el software. Una organización pequeña con datos bien estructurados puede operar sobre ellos con un agente sin necesitar formación especializada en ninguna herramienta. El mercado potencial del software empresarial se expande de forma significativa, y los beneficiarios inmediatos son los segmentos que más barreras tenían hasta ahora. La condición, en ambos casos, es la misma que la que aparece en el punto de observabilidad: la calidad de los datos subyacentes. La democratización de la interfaz no resuelve el problema de los datos mal estructurados. Un agente que opera sobre datos sin semántica de dominio clara produce resultados imprecisos con la misma fluidez con la que un sistema bien diseñado produce resultados correctos. La interfaz conversacional hace que los errores sean menos visibles, no menos frecuentes. ## La pregunta que queda abierta ![](./attachments/75-cuando-el-software-deja-de-ser-predecible-5.webp) El debate sobre si el SaaS va a colapsar o transformarse es menos interesante que la pregunta que plantea la transición para las organizaciones que tienen que vivirla. Operar con software determinista requiere cierto tipo de disciplina: definir procesos, configurar el sistema, entrenar a las personas. Es una disciplina sobre el diseño. Operar con agentes no deterministas requiere una disciplina distinta: saber qué están haciendo los agentes, poder evaluar si sus decisiones son correctas, tener mecanismos para detectar cuando se desvían del comportamiento esperado. Es una disciplina sobre la supervisión. La mayoría de las organizaciones tienen bastante experiencia con la primera y muy poca con la segunda. El software empresarial lleva décadas entrenando a las organizaciones para adaptarse a sistemas predecibles. Los agentes van a requerir que aprendan a gobernar sistemas que no lo son. **Esa capacidad -de supervisar, auditar y corregir comportamiento no determinista- es la que va a determinar qué organizaciones sacan valor real de esta transición y cuáles acaban con sistemas que actúan por su cuenta sin que nadie entienda exactamente qué están haciendo ni por qué.** ## Bonus Ya que has llegado hasta aquí, de dejo una visualización interactiva sobre una arquitectura SaaS vs. agéntica. Click sobre los elementos para ver la descripción. <iframe src="https://davidhurtadoai.github.io/Explorations/saas-vs-agentic.html" width="600" height="1050" style="border:none;"></iframe> ---