Valor Ganado

Artículo

SaaSpocalipsis y el nuevo SaaS

Mucho se ha dicho sobre la próxima «muerte del SaaS», pero el diagnóstico confunde dos cambios distintos: la desaparición de ciertas formas de usar el software y la desaparición de los servicios que contienen los datos, las reglas y las operaciones del trabajo.

Conversemos sobre esto

La «muerte del SaaS» es una falsa dicotomía

Mucho se ha dicho sobre la próxima «muerte del SaaS», pero el diagnóstico confunde dos cambios distintos: la desaparición de ciertas formas de usar el software y la desaparición de los servicios que contienen los datos, las reglas y las operaciones del trabajo.

Llamamos agentes a los sistemas que, en lugar de limitarse a responder preguntas, persiguen objetivos, organizan procesos y utilizan herramientas con un grado de autonomía. Anthropic describe precisamente esa diferencia entre los asistentes tradicionales y los agentes orientados a completar tareas complejas.

La pregunta decisiva, por tanto, no es si los agentes sustituyen al SaaS, sino si el SaaS puede convertirse en una infraestructura que resulte utilizable por personas y agentes. Si un agente necesita consultar sistemas y actuar sobre ellos para completar una misión, la automatización agéntica no elimina necesariamente esos servicios: aumenta la importancia de poder acceder a ellos de forma estructurada y controlada.

Los agentes necesitan servicios, no solo modelos

Un modelo puede interpretar una petición, pero una misión real suele exigir algo más: datos actualizados, contexto empresarial y capacidad de ejecutar una operación. Según The Intercom Blog, una atención al cliente eficaz con IA depende del acceso en tiempo real a sistemas como CRM, plataformas de facturación y conversaciones anteriores. Sin esas conexiones, el agente entiende peor el historial del cliente y resuelve menos consultas de forma contextualizada.

Los conectores de Claude muestran la misma lógica desde otro ángulo: permiten consultar datos y realizar acciones en servicios conectados, heredando los permisos de cada persona en el sistema de origen. Así, un conector puede buscar archivos en Google Drive, enviar mensajes en Slack o crear incidencias en Linear, siempre dentro del acceso concedido a ese usuario.

La consecuencia es una inferencia, no una medición automática: el valor práctico de un agente depende en parte de la red de servicios a la que puede acceder y de las acciones que esos servicios le permiten realizar. El SaaS sigue siendo relevante porque convierte una respuesta conversacional en un resultado operativo dentro del trabajo.

MCP convierte el SaaS en infraestructura para agentes

El Model Context Protocol, o MCP, expresa esta evolución mediante una arquitectura sencilla: unos clientes solicitan y utilizan datos o herramientas, mientras unos servidores exponen capacidades de sistemas empresariales. The Intercom Blog lo presenta como un estándar para conectar aplicaciones de IA con herramientas y datos; Claude también lo describe como un estándar abierto para conectar aplicaciones de IA con herramientas y datos.

Figura 1. Del objetivo a la acción controlada
  1. El agente formula la necesidad

    Interpreta una tarea y determina qué información o herramienta necesita.

  2. El cliente MCP solicita acceso

    El agente o la aplicación cliente pide datos o una acción a un servicio conectado.

  3. El servidor del SaaS expone la capacidad

    El sistema empresarial ofrece información u operaciones definidas para ese uso.

  4. Se aplican permisos y condiciones

    La acción queda limitada por los permisos, parámetros, reglas y salvaguardas configurados.

  5. El servicio ejecuta y devuelve el resultado

    La operación se realiza en el sistema de origen y el agente incorpora el resultado a la tarea.

En la práctica, Claude anunció conexiones con servicios como Jira, Confluence, Intercom, Linear, PayPal y Plaid. Intercom, por su parte, describe ejemplos que incluyen consultar la facturación en Stripe, acceder a datos de Shopify, crear o actualizar tickets en Linear y encadenar varias acciones bajo condiciones definidas.

Esto cambia la naturaleza visible del SaaS. Deja de ser únicamente una aplicación que una persona abre para convertirse también en un conjunto de capacidades que otros agentes pueden descubrir, consultar e invocar. Por eso importan no solo las integraciones técnicas, sino también la claridad de los datos, la disponibilidad de las acciones y la forma de declarar sus condiciones de uso.

La amenaza es el SaaS cerrado o sin gobierno

Abrir un servicio a los agentes no significa concederles acceso ilimitado. Claude Help Center explica que los administradores de los planes Team y Enterprise pueden restringir las acciones de un conector en toda la organización, por ejemplo permitiendo leer información pero impidiendo que el conector escriba cambios.

The Intercom Blog describe controles complementarios: decidir cuándo se activa una herramienta, qué parámetros debe recopilar, qué valores puede completar y qué instrucciones debe seguir. Para tareas como reembolsos, disputas de transacciones o cambios de suscripción, también contempla encadenar acciones y exigir condiciones antes de ejecutar operaciones de mayor riesgo.

Anthropic plantea el mismo límite desde la gobernanza de los agentes: las personas deben conservar el control, especialmente antes de decisiones de alto impacto. Su marco menciona la combinación de permisos de solo lectura, aprobaciones humanas y autorizaciones persistentes para tareas rutinarias.

Un SaaS para humanos y agentes

El nuevo SaaS no tiene que elegir entre la interfaz humana y el acceso agéntico. Puede cumplir simultáneamente tres funciones: ofrecer una experiencia para las personas, proporcionar contexto a los agentes y ejecutar acciones dentro de límites definidos.

Las integraciones descritas por Claude, Claude Help Center e Intercom ya apuntan en esa dirección: los agentes pueden investigar, crear registros, actualizar sistemas y coordinar flujos entre varias herramientas. Pero la existencia de esas posibilidades no demuestra que todo SaaS vaya a beneficiarse automáticamente. La ventaja dependerá de la calidad de sus datos, de las acciones que exponga y de la gobernanza que permita aplicar.

La amenaza, entonces, no es el SaaS en sí, sino el SaaS que permanece cerrado a esta nueva forma de uso. Un servicio que no pueda ser descubierto, conectado o utilizado de manera segura por agentes puede perder utilidad relativa frente a otro que sí integre esas capacidades.

Por eso tenemos SaaS para rato, aunque no exactamente el mismo SaaS. La evolución pasa por permitir que los agentes usen estos servicios, pero también por conducir ese uso: definir qué pueden ver, qué pueden hacer, cuándo deben pedir aprobación y cómo se entiende el resultado. El futuro no enfrenta agentes contra SaaS; enfrenta servicios adaptables y gobernables contra servicios que se niegan a participar en el nuevo modo de trabajo.

Fuentes

Conversemos

¿Quieres conversar sobre este tema?

Elige un horario disponible y conversamos sobre cómo aplica a tu contexto.

Completa tus datos y elige un horario disponible.

Conversación: SaaSpocalipsis y el nuevo SaaS

Disponibilidad

—

Seleccione una fecha