Service-as-a-software: el modelo que está reemplazando al SaaS

Por qué este texto importa antes de tu próxima renovación SaaS

El SaaS te vendió capacidad. Cobraba por usuario, por mes, por feature. Tu equipo aprendía a usarlo, lo configuraba, lo integraba con otros sistemas y, al cabo de un año, evaluaba si había sido útil. La métrica era adoption: cuánta gente entró, cuántas veces, cuánto tiempo se quedaron.

Service-as-a-software cambia las tres preguntas. No vende capacidad: vende resultado. No cobra por uso: cobra por trabajo entregado. La métrica deja de ser adoption y pasa a ser delivery. Es la diferencia entre comprar un taladro y contratar a alguien para que haga el agujero.

Esa diferencia, que parece semántica, redefine contratos, presupuestos, riesgo, propiedad de datos y el rol de tecnología en la organización. La transición ya está en curso. Gartner estima que en 2026 el 40% del software empresarial incorporará capacidades agénticas, frente a menos del 5% hace dos años. La conversación dejó de ser si va a pasar y empezó a ser cuándo le toca a tu organización.

Este texto explica el modelo, las cuatro capas donde se captura el valor, las preguntas que conviene hacerle a un proveedor que dice operar en este modo, y las dinámicas locales que importan en Chile. Lo escribimos porque Trenzar IA opera explícitamente en este modelo y, al hacerlo, nos topamos con la falta de un vocabulario común para conversarlo en español.

La era del SaaS está terminando (no porque lo digamos, lo dice Gartner)

Durante dos décadas el SaaS fue la forma natural de comprar tecnología en una empresa: contrato anual, licencia por usuario, soporte estándar, una promesa de productividad y la responsabilidad de obtener resultado del lado del cliente. El modelo funcionó porque convertía la tecnología en un gasto operativo predecible y transfería al usuario la curva de aprendizaje.

Lo que se quiebra ahora no es el SaaS como infraestructura, sino el SaaS como modelo de relación. Los agentes de inteligencia artificial no usan software del modo que lo hace una persona: ejecutan tareas, articulan workflows y entregan resultados. Cuando esa capa de ejecución madura, el cliente empieza a preguntar otra cosa. Ya no le interesa pagar por una herramienta que su equipo va a aprender a usar; le interesa pagar por el trabajo que esa herramienta entrega. La pregunta cambia de «¿qué puedo hacer con esto?» a «¿qué obtengo de esto, sin tener que aprender nada?».

Ese giro tiene precedentes. Pasamos del on-premise al SaaS cuando el costo de operar infraestructura propia dejó de tener sentido. Ahora pasamos del SaaS al service-as-a-software cuando el costo de aprender a usar herramientas dejó de tener sentido. Es la misma lógica de capas: cada vez que una capa se vuelve commodity, el valor migra hacia arriba.

La diferencia que importa: capacidad vs. resultado

Es útil pensar la diferencia con una matriz simple.

Dimensión	SaaS	Service-as-a-software
Qué se compra	Capacidad de uso	Resultado entregado
Métrica clave	Adopción y engagement	Trabajo entregado
Contrato	Licencia por usuario	SLA por resultado
Riesgo del outcome	Cliente	Proveedor
Curva de aprendizaje	Cliente la asume	Proveedor la abstrae
Datos del cliente	Insumo del cliente	Activo compartido del servicio
Pricing	Suscripción fija	Variable según entrega

La pregunta que cambia todo es ¿quién hace el trabajo?. En SaaS, el trabajo lo hace tu equipo, asistido por la herramienta. En service-as-a-software, el trabajo lo hace el sistema y tu equipo lo supervisa. El proveedor pasa de vender una herramienta a hacerse cargo de un proceso.

Esa transferencia tiene consecuencias contractuales. Si el resultado no llega, no es el cliente quien tiene que esforzarse más; es el proveedor quien incumplió. La penalización es por entrega, no por disponibilidad. Es un cambio profundo del riesgo y, por eso, los contratos van a empezar a parecerse menos a una licencia y más a un servicio profesional auditado.

El modelo de las cuatro capas

Conviene mirar el ecosistema de IA empresarial como cuatro capas superpuestas. Cada una captura una porción distinta del valor, y cada una tiene actores característicos.

Capa 1: infraestructura. Modelos fundacionales (GPT, Claude, Gemini, Llama), cómputo (las nubes hyperscalers), bases de datos vectoriales. Es la capa más visible en prensa porque tiene los actores más grandes, pero es también la que se está volviendo commodity más rápido. Ningún negocio chileno construye en esta capa, ni debería: es un negocio de billones de dólares y márgenes en compresión.

Capa 2: orquestación. Frameworks de agentes, herramientas de workflow, plataformas de automatización (LangChain, n8n, los agentes de los hyperscalers). La capa de orquestación es donde la mayoría de las empresas de software están construyendo hoy. Es importante, pero también está siendo absorbida rápidamente por las capas adyacentes.

Capa 3: aplicación. Interfaces, productos, experiencias de uso. Aquí están la mayoría de los SaaS verticales que conoces. La capa de aplicación es la que más se parece al SaaS clásico, pero es también la que va a sufrir más presión: si la capa 4 entrega resultado directamente, la interfaz de la capa 3 se vuelve menos necesaria.

Capa 4: contexto. Aquí es donde Trenzar IA opera y donde, sostenemos, está el valor más durable. La capa 4 no es la herramienta ni el agente: es el conocimiento operacional sedimentado, el modo particular en que una organización entiende su problema, sus actores, su historia, sus procesos. Un agente de IA sin contexto es un asistente genérico; un agente con contexto es un colega que sabe cómo se hacen las cosas en esta organización. Ese contexto no es portátil. No se descarga ni se transfiere fácilmente. Es lo que vuelve defendible la posición de un proveedor en service-as-a-software.

Por qué la capa 4 es la más valiosa (y por qué casi nadie la opera)

Hay dos errores frecuentes con la capa 4. El primero es asumir que el contexto se importa del mes pasado: que basta con cargar documentos y políticas en una base vectorial, hacer un fine-tuning y listo. No funciona así. El contexto operacional incluye cosas que casi nunca están escritas: cómo se decide en realidad, qué actores tienen veto, qué argumentos funcionan en qué momento del año, dónde están los puntos sensibles que nadie nombra en una reunión.

El segundo error es asumir que el contexto se construye una vez. Las organizaciones cambian. Los conflictos cambian. Los actores cambian. El contexto operacional es un activo vivo: requiere mantenimiento, curaduría y actualización. Por eso las plataformas que se pretenden «instalables» con tres clicks raramente funcionan más allá del piloto.

Lo que define a un servicio operando en capa 4 es que el conocimiento se construye con la organización, no a partir de ella. Hay un proceso participativo, hay iteración, hay aprendizaje en ambas direcciones. Eso es lento. También es lo que vuelve a la relación entre cliente y proveedor más parecida a la consultoría tradicional que a un deployment SaaS. La diferencia, claro, es que el resultado se entrega cada día, no solo en un informe trimestral.

Qué cambia para tu organización si el modelo es service-as-a-software

Cambia el contrato. Pasa de licencia con cláusulas de uptime a SLA de entrega: tantas tareas resueltas, tantos informes producidos, tantos análisis entregados. Las cláusulas de penalización son por incumplimiento del outcome, no por caída del sistema. Para un departamento legal, esto significa reescribir los modelos contractuales que se vienen usando hace una década.

Cambia la métrica. El KPI ya no es number of seats o minutes of usage. Es throughput de trabajo entregado y calidad del entregable. Los reportes a la dirección dejan de mostrar adopción y empiezan a mostrar productividad. Eso es bueno: alinea la herramienta con el negocio. Pero también obliga a tener métricas claras del trabajo que antes no se medía.

Cambia el rol de TI. En SaaS, TI compra licencias, integra sistemas y gobierna identidades. En service-as-a-software, TI cura el contexto, audita resultados y asegura que el sistema esté alimentado con la información correcta. Pasa de comprador a curador. Para muchos equipos chilenos de tecnología, ese cambio de rol va a ser cultural antes que técnico.

Cambia el riesgo. Quien se equivoca lo paga. Si el agente entrega mal, no es problema del cliente. Pero el cliente tiene que poder auditar el resultado. Eso obliga a un nivel de trazabilidad que muchos SaaS actuales no proveen, y que es un campo de competencia central para los próximos cinco años.

Cinco preguntas para auditar a un proveedor que dice ser service-as-a-software

Si un proveedor te dice que opera en este modelo, conviene hacer estas cinco preguntas en la primera reunión.

¿Cuál es el resultado que entregan, no la herramienta? Si la respuesta describe una plataforma con módulos, no es service-as-a-software, es SaaS con marketing renovado. La respuesta correcta nombra un trabajo: «redactamos los expedientes», «respondemos las consultas», «monitoreamos las menciones».

¿Cómo miden la entrega? Si la respuesta habla de uptime y de usuarios activos, no es service-as-a-software. La respuesta correcta nombra una unidad de trabajo y una calidad esperada de ese trabajo.

¿Qué pasa si el agente no entrega? Si la respuesta es «rebajamos la mensualidad», está bien pero es flojo. La respuesta correcta describe un protocolo de remediación: el equipo humano del proveedor toma el caso, lo entrega, ajusta el contexto y recalibra el sistema.

¿Quién es dueño del contexto al cabo de un año? Esta es la pregunta que distingue a los proveedores serios de los oportunistas. La respuesta correcta es alguna versión de «el contexto es del cliente, queda en su infraestructura, y al término del contrato se entrega». Cualquier respuesta que sugiera que el contexto se queda con el proveedor es una alerta roja.

¿Cómo se aborda la auditoría y la trazabilidad? Para industrias reguladas, esta pregunta es decisiva. La respuesta correcta describe logs verificables, control de versiones del modelo, documentación del entrenamiento y un proceso para responder ante autoridades. La respuesta incorrecta es «confíen en nosotros».

El caso chileno: tres dinámicas locales que importan

Industrias reguladas y la cuestión de la auditabilidad. Salmonera, minería, banca, salud, sector eléctrico: cinco industrias chilenas donde un agente de IA que entrega trabajo tiene que poder ser auditado por un regulador. La SUSESO, Sernapesca, Sernageomín, la SBIF, la Superintendencia de Servicios Sanitarios. Cualquier proveedor que no pueda explicar cómo va a sostener la trazabilidad ante una fiscalización está vendiendo un producto que tu organización no puede comprar.

Operaciones territoriales y el riesgo socioambiental. Una porción significativa de las grandes empresas chilenas opera en territorios con tensiones sociales, comunidades indígenas, expedientes ambientales abiertos y procesos de consulta. Un agente de IA que automatiza decisiones sin entender ese contexto es un riesgo reputacional latente. La capa 4 —el contexto— no es opcional en estos sectores; es el corazón del producto.

Talento técnico escaso y la presión por capacidad interna. Chile tiene pocos perfiles que combinen experiencia técnica con conocimiento sectorial profundo. Eso favorece estructuralmente a los modelos service-as-a-software bien diseñados: si el proveedor entrega trabajo terminado, la organización no tiene que contratar y formar talento que no existe en el mercado. La condición es que el modelo no genere dependencia: el conocimiento del proceso debe seguir creciendo dentro del cliente, no migrar al proveedor.

Tres errores que vemos repetir

Error 1: comprar service-as-a-software como SaaS. Negociar el contrato como si fuera una licencia, con cláusulas de uptime y SLAs de disponibilidad. Quien negocia así pierde la mitad de las ventajas del modelo: la transferencia del riesgo de ejecución al proveedor.

Error 2: medir el éxito por adopción interna. Si el agente entrega trabajo, da igual cuántos colaboradores «lo usaron». Lo que importa es cuánto trabajo entregó y de qué calidad. Insistir en métricas de uso es traer el mindset SaaS a un contexto donde no aplica.

Error 3: pretender que la capa 4 se construye en seis semanas. Los proveedores serios saben que el contexto profundo toma trimestres, no semanas. Los proveedores oportunistas prometen pilotos exitosos en 30 días. La diferencia se nota al sexto mes, cuando el primer agente empieza a fallar de modos que solo el contexto operacional puede prevenir.

Próximo paso

Si tu organización está evaluando renovar contratos SaaS por más de un millón de dólares anuales, o si está considerando contratar consultoría de IA por primera vez, vale la pena hacer el ejercicio: ¿cuáles de tus contratos podrían reescribirse como service-as-a-software? ¿En cuáles tiene sentido seguir comprando capacidad? ¿En cuáles, comprar resultado?

En Trenzar IA hacemos ese diagnóstico en una conversación de 30 minutos, sin compromiso. No es un sales pitch: es un mapeo de las cuatro capas aplicado a tu organización, con criterios para decidir dónde tiene sentido moverse de modelo y dónde no.

[Agendar diagnóstico de 30 minutos →]

[Descargar el diagrama imprimible de las cuatro capas →]

Lecturas recomendadas

• «Service as a Software» — *UXTigers* (definición ejecutiva en inglés)
• «Service as Software» — *SmarterTech* (panorama del mercado global)
• «A IA não vai matar o SaaS, mas vai forçá-lo a crescer» — *MIT Sloan Management Review Brasil* (perspectiva regional)
• «Inteligencia Artificial Responsable en Chile» — *PwC Chile* (contexto local)

Preguntas frecuentes

¿Service-as-a-software es lo mismo que SaaS con IA? No. SaaS con IA es un SaaS que sumó una funcionalidad de inteligencia artificial. Service-as-a-software es un cambio de modelo: el proveedor entrega trabajo, no herramienta. Puedes tener un SaaS con IA muy bueno y seguir siendo SaaS.

¿Significa que voy a despedir a mi equipo de operaciones? No automáticamente. El modelo cambia el tipo de trabajo que tu equipo hace, no necesariamente el tamaño. En la mayoría de los casos que vemos, el equipo deja de hacer tareas repetitivas de bajo nivel y empieza a hacer supervisión, curaduría y trabajo de alto nivel.

¿Cómo se factura un servicio que no es por licencia? Hay tres modelos comunes: por trabajo entregado (fee por unidad), por SLA fijo con tope de capacidad, o híbrido (un fijo mensual más un variable por sobre-uso). Lo que importa es que el contrato sea predecible para la organización y alineado con el resultado, no con el uso.

¿Qué pasa con el cumplimiento normativo? Es un tema central. El proveedor debe poder demostrar trazabilidad, control de versiones, documentación del entrenamiento y capacidad de responder ante autoridades. En Chile esto no es una buena práctica: en industrias reguladas, es un requisito.

¿Esto es relevante para una empresa de menos de 200 personas? Depende del negocio. En empresas pequeñas con procesos repetitivos de alto volumen (atención a clientes, gestión documental, monitoreo de medios) el modelo encaja muy bien. En empresas pequeñas con procesos artesanales y bajo volumen, el SaaS clásico sigue siendo lo correcto.

¿Por qué Trenzar IA escribe sobre esto? Porque construimos en este modelo. Diseñamos agentes a medida que entregan trabajo y nos hacemos cargo del resultado. Estamos convencidos de que el modelo es mejor —para cierto tipo de organización y de problema—, y queremos hacer la conversación pública en español, donde casi no existe.