Dos letras intercambiadas. Todo el contrato entre proveedor y cliente, invertido. El modelo de servicio como software (service-as-software o SaS) no es simplemente un cambio de nombre ingenioso para el SaaS.
Es un modelo de negocio en el que el software deja de ser principalmente la herramienta que utiliza el cliente y pasa a ejecutar el trabajo que este necesita. La economía de la inteligencia artificial (AI) está haciendo posible llevar esta idea a procesos y escalas que antes resultaban difíciles de sostener.
La diferencia está en lo que las organizaciones compran: en el modelo tradicional de software, el cliente adquiere una capacidad (una plataforma para gestionar clientes, procesar documentos, administrar las finanzas o atender solicitudes), en SaS, la propuesta es entregar directamente el trabajo que esas herramientas permitían realizar.
Una empresa no necesariamente compra el software para que sus empleados hagan el trabajo, compra el trabajo que el software realiza.
Índice de temas
Del software que habilita al software que ejecuta
Durante años, el software empresarial tuvo como objetivo aumentar la productividad de las personas.
Un CRM proporcionaba las herramientas para que un vendedor gestionara prospectos; una plataforma contable permitía al equipo financiero registrar y conciliar operaciones; un sistema de soporte organizaba las solicitudes que después debía resolver un empleado.
El software podía automatizar una parte importante del proceso, pero la responsabilidad por ejecutarlo seguía dentro de la empresa.
El servicio como software cambia esa relación. En lugar de proporcionar una herramienta para gestionar un proceso, el proveedor puede asumir la ejecución del proceso. Recibe información, interpreta el contexto, realiza las acciones necesarias y entrega un resultado.
La firma de capital de riesgo Foundation Capital identifica un desplazamiento de la lógica de tooling hacia la entrega del trabajo: la diferenciación deja de depender solamente de las funcionalidades del producto y pasa por su capacidad para integrarse con la operación del cliente y producir resultados.
La compañía que apostó por Netflix cuando aún era un servicio de envío de DVD ha estudiado durante el último año a compañías de SaS y calcula en $4.6 billones de dólares la oportunidad de estas, toda vez que esa cifra representa hoy el gasto anual de las empresas en salarios y servicios externalizados que podrían intentar capturar.
En una publicación de blog de diciembre de 2025, el coreógrafo de innovación de Thoughtworks, Matt Kamelman, planteó una diferencia entre ambos modelos: el software tradicional proporciona las herramientas para que las personas realicen el trabajo, mientras que el servicio como software busca automatizar su ejecución.
Diferencias entre SaaS y SaS
Un ejemplo permite distinguir ambos modelos: una empresa puede contratar un software para gestionar sus cuentas por cobrar. Sus empleados utilizan la plataforma para revisar facturas, identificar pagos, contactar clientes y actualizar registros.
Un servicio basado en software puede recibir esas mismas cuentas y encargarse de conciliarlas, identificar excepciones, enviar comunicaciones y actualizar los sistemas de la empresa.
En el primer caso, el producto es la plataforma, mientra que en en el segundo, el producto es el trabajo realizado.
El cambio no consiste únicamente en automatizar más tareas. La propuesta de SaS es que el software pueda asumir una función completa dentro de un proceso.
Foundation Capital ha descrito esta arquitectura como un sistema de agentes: un conjunto de agentes de AI capaces de realizar diferentes funciones y coordinarse para completar procesos que anteriormente requerían varias intervenciones humanas.
Esto permite distinguir tres niveles:
- Automatización: el software ejecuta una tarea específica.
- Workflow: el software encadena varias tareas dentro de un proceso.
- Servicio: el sistema recibe un objetivo y ejecuta las acciones necesarias para entregar un resultado.
La AI es relevante porque permite trabajar con información no estructurada y tomar decisiones dentro de un flujo de trabajo. Un sistema puede interpretar un correo, consultar información en diferentes aplicaciones, decidir qué acción corresponde, ejecutarla y registrar el resultado.
Pero hacer el trabajo no depende únicamente de las capacidades del modelo. Foundation Capital señala que, en los sistemas de AI empresariales, la integración con los flujos de trabajo, los datos y las reglas particulares de cada organización se ha convertido en parte del propio producto.
La implementación adquiere un papel central en la entrega del servicio y el software pasa de ser solamente una herramienta que una persona opera a convertirse en quien realiza una parte del trabajo.
Smarter Technologies describe esta evolución como el paso de herramientas de productividad hacia sistemas que pueden asumir funciones completas mediante AI.
Más allá de la AI agéntica
Aunque la AI agéntica es la base tecnológica, no define por completo SaS. Este es un modelo de negocio y de entrega.
Una organización puede incorporar agentes dentro de un producto SaaS y continuar vendiendo ese producto mediante una suscripción. El hecho de que un sistema utilice AI para automatizar tareas no lo convierte automáticamente en SaS.
El cambio ocurre cuando la propuesta comercial se desplaza hacia la ejecución.
La diferencia también está en el tipo de instrucción que recibe el sistema. Kamelman señala que los sistemas agénticos pueden operar a partir de objetivos, en lugar de limitarse a ejecutar instrucciones predeterminadas: interpretan contexto y restricciones, seleccionan acciones y coordinan herramientas y fuentes de datos.
Un proveedor puede vender un software para que una empresa gestione sus tickets de soporte. Otra compañía puede vender la resolución de esos tickets.
Ambas pueden utilizar agentes. La diferencia es qué recibe el cliente al final de la operación. En un caso recibe una herramienta, en el otro recibe un servicio ejecutado mediante software.
El impacto económico en los modelos de cobro
Si el producto deja de ser una herramienta y pasa a ser el trabajo realizado, también cambia la economía del software.
La unidad de cobro puede desplazarse del acceso al uso, el workflow, la tarea o el resultado. Foundation Capital identifica esta evolución como una consecuencia de que el proveedor asuma una participación cada vez mayor en la ejecución del proceso.
Eso no implica que todos los modelos de SaS tengan que adoptar un esquema de outcome-based pricing. Pueden coexistir tarifas por consumo, transacción, volumen procesado, tarea completada y modelos híbridos.
Lo que sí cambia es la distribución del riesgo. Cuando el proveedor vende la ejecución, también debe responder por las condiciones bajo las cuales esa ejecución se considera satisfactoria. ¿Qué nivel de precisión se espera? ¿Qué casos se escalan a una persona? ¿Quién responde por los errores?
Para el proveedor existe además un reto económico: cada operación de AI incorpora costos variables de inferencia, infraestructura y, en algunos casos, intervención humana. El precio cobrado por el trabajo debe guardar relación con el costo de producirlo.
Bessemer Venture Partners señala que esta combinación de costos variables y nuevos modelos de monetización está llevando a las compañías de AI a experimentar con esquemas que van más allá de la licencia por usuario, incluidos modelos híbridos que ofrecen mayor previsibilidad a los clientes empresariales.
Casos de uso ideales para SaS
El modelo tiene mejores condiciones para determinados tipos de trabajo. Los procesos con alto volumen, entradas digitales, reglas relativamente definidas y resultados que pueden medirse ofrecen un terreno más favorable.
Soporte, procesamiento de documentos, determinadas operaciones financieras, clasificación de solicitudes, gestión de reclamaciones y algunas funciones administrativas son ejemplos de procesos susceptibles de ser entregados como servicios ejecutados mediante software.
En cambio, actividades donde el resultado depende de relaciones personales, decisiones ambiguas o factores difíciles de medir presentan mayores dificultades.
Esto introduce una pregunta más útil que si una empresa debería “adoptar SaS”: ¿Qué procesos de la organización pueden convertirse en resultados medibles que un proveedor pueda ejecutar de principio a fin?
Implicaciones clave para IT
Para un comprador empresarial, la aparición de SaS modifica también la evaluación de proveedores.
La primera pregunta ya no debería ser solamente qué funcionalidades ofrece una plataforma. También conviene determinar:
- ¿Qué trabajo realiza realmente el sistema?
- ¿Qué parte del proceso sigue dependiendo de empleados?
- ¿Cómo se mide el resultado?
- ¿Quién responde cuando el sistema falla?
- ¿Qué nivel de intervención humana existe?
- ¿Cómo se calcula el precio?
- ¿Qué datos necesita el proveedor para ejecutar el servicio?
Y, sobre todo: ¿Qué responsabilidad está transfiriendo la empresa al proveedor?
Estas preguntas permiten distinguir un producto que simplemente incorpora AI de uno que realmente está utilizando la AI para entregar un servicio.
El futuro de la gestión de software
Service-as-Software no significa que el SaaS esté desapareciendo. Las organizaciones seguirán necesitando plataformas, sistemas de registro, herramientas de colaboración, infraestructura y aplicaciones que los empleados utilicen directamente.
Lo que cambia es que existe una nueva posibilidad entre el software y los servicios tradicionales: software que no solamente proporciona la capacidad para realizar un trabajo, sino que ejecuta ese trabajo y entrega el resultado.
En SaaS, la empresa compra una herramienta y conserva buena parte de la responsabilidad de utilizarla para conseguir un resultado, y en SaS, el proveedor busca asumir una parte mayor de esa ejecución.
Por eso, las dos letras intercambiadas importan, porque cambian la pregunta que está detrás de la compra: ¿la empresa necesita software para hacer el trabajo o está dispuesta a comprar el trabajo que el software puede hacer?
