Agentes de IA dentro de un SaaS: 6 decisiones de producto para 2026

Un agente de IA integrado es un agente dedicado a una tarea concreta que vive dentro de un producto SaaS y completa un trabajo definido en nombre del usuario, de principio a fin, con los datos del producto y los permisos del propio usuario. Un asistente de IA responde y sugiere mientras el trabajo lo hace el usuario; un agente integrado hace el trabajo y entrega un resultado. Gartner prevé que a finales de 2026 el 40% de las aplicaciones empresariales incorporará agentes de IA para tareas concretas, frente a menos del 5% en 2025.

La previsión pone fecha límite a los equipos de producto. Si tu SaaS vende a empresas, los clientes empezarán a preguntar qué hace el producto sin ellos, y un panel de chat no responde a esa pregunta. Aquí están las seis decisiones de producto que tomamos antes de meter un agente en una interfaz SaaS: qué trabajo se le asigna, cuánta autonomía tiene, con qué permisos actúa, dónde se revisa su trabajo, cómo se deshacen sus acciones y cuánto cuesta ejecutarlo.

¿Por qué tantos agentes se quedan por el camino antes del lanzamiento?

La misma consultora que prevé el 40% espera el resultado contrario para buena parte de los proyectos. Según Gartner, más del 40% de los proyectos de IA agéntica se cancelarán antes de que acabe 2027 por costes crecientes, un valor de negocio poco claro y controles de riesgo insuficientes. En el mismo comunicado calcula que solo unos 130 de los miles de proveedores que venden IA agéntica ofrecen agentes de verdad. Al resto lo llama "agent washing": asistentes, RPA y chatbots con otra etiqueta.

Las tres causas son decisiones de producto. El coste depende de cada cuánto se ejecuta el agente y de cuánto contexto lee. El valor depende del trabajo que se le asigna y de cuánto pagaría un cliente por dejar de hacerlo. El control del riesgo depende de los permisos, la revisión y la forma de deshacer. Ninguna se arregla con un modelo mejor.

Por qué un chat lateral es el punto de partida equivocado

La forma más rápida de añadir "un agente" a un producto es un panel de chat conectado a un LLM con unas cuantas herramientas. En una demo queda bien. Pero deja abiertas las preguntas difíciles: qué puede cambiar el agente, dónde aparece el trabajo terminado, cómo lo revisa un responsable y qué pasa cuando se equivoca. Una transcripción de chat es un mal registro del trabajo: es lineal, la ve un solo usuario y cuesta auditarla. La parte de arquitectura la tratamos en AI-native vs IA pegada encima. Las seis decisiones que siguen son la parte de producto.

1. ¿Qué trabajo se le asigna?

Se empieza por un solo trabajo, escrito como una frase con una meta. "Concilia las transacciones con tarjeta del mes pasado con los recibos y marca las que no tienen pareja" es un trabajo. "Ayuda con la contabilidad" es una categoría. Un buen primer trabajo cumple cuatro condiciones:

• Una meta clara. El usuario ve en segundos si el resultado es correcto.
• Frecuencia. Se repite cada semana o cada día, así que el tiempo ahorrado se acumula.
• Datos acotados. Lo que necesita ya está en el producto, o detrás de una sola integración.
• Resultados reversibles. Un error se corrige antes de que llegue a un cliente, a un banco o a un regulador.

Los trabajos que no pasan la cuarta prueba (mover dinero, borrar registros, escribir a los clientes del cliente) pueden ser trabajos de agente más adelante. Empiezan con un nivel de autonomía más bajo, que es la siguiente decisión.

2. ¿Cuánta autonomía tiene?

La autonomía es una decisión de diseño, independiente de lo que el modelo sabe hacer. Lo defienden tres investigadores de la Universidad de Washington en "Levels of Autonomy for AI Agents" (Feng, McDonald y Zhang, 2025), que define cinco niveles según el papel del usuario: operador, colaborador, consultor, aprobador y observador. En el nivel operador el usuario dirige y el agente ejecuta. En el nivel observador el agente trabaja solo y el usuario supervisa.

Fijamos el nivel por tipo de acción, y un mismo agente puede estar en tres niveles a la vez. El agente de conciliación empareja transacciones por su cuenta (observador), propone categorías que una persona acepta en bloque (aprobador) y nunca registra un asiento contable sin un clic explícito (operador). En la interfaz se traduce en un ajuste pequeño y visible por tipo de acción, con el nivel más prudente por defecto. Los equipos lo suben cuando confían en los resultados, y el producto registra quién lo subió y cuándo.

3. ¿Con qué permisos actúa?

Un agente integrado nunca debe poder hacer más que la persona para la que trabaja. El patrón más seguro es el acceso delegado y acotado: el agente actúa en nombre de un usuario concreto, hereda su rol y recibe además un alcance limitado a su trabajo. Un agente que concilia transacciones lee el libro mayor y escribe emparejamientos en borrador. No tiene ningún motivo para tocar los ajustes de facturación ni la gestión de usuarios.

En el modelo de datos esto tiene dos consecuencias. Cada escritura lleva dos identidades, el agente y el usuario en cuyo nombre actuó, y el registro dice "emparejado por el agente de conciliación para María García". Y al revocar el acceso de un usuario se revocan sus agentes en el mismo paso. Las mismas preguntas de autorización vuelven cuando son los agentes de otras empresas los que llaman al tuyo, como explicamos en la guía del protocolo A2A.

4. ¿Dónde se revisa su trabajo?

La salida de un chat se pierde al hacer scroll. El trabajo de un agente necesita un sitio en el producto donde esperar: una cola de revisión, una bandeja de cambios propuestos, una columna de estado en los registros que ha tocado. Aquí se trata sobre todo de diseño de producto clásico, y las pautas son anteriores a los LLM. Las 18 pautas de interacción entre personas e IA de Microsoft Research (Amershi y otros, CHI 2019) siguen encajando bien con los agentes. Cuatro tratan justo esta decisión:

• Dejar claro qué puede hacer el sistema. El trabajo del agente y sus límites caben en una frase, en el punto donde se activa.
• Facilitar la corrección. Aprobar o corregir veinte propuestas cabe en una sola pantalla, con acciones en bloque y atajos de teclado.
• Dejar claro por qué el sistema hizo lo que hizo. Cada propuesta muestra las pruebas que usó: el recibo emparejado, la regla aplicada.
• Acotar el servicio en caso de duda. Cuando la confianza es baja, el agente pregunta, o deja el elemento a una persona, en lugar de adivinar.

Aquí entra también la transparencia. El artículo 50 del Reglamento de IA de la UE, aplicable desde el 2 de agosto de 2026, exige a los proveedores diseñar los sistemas de IA que interactúan directamente con personas de forma que estas sepan que tratan con una IA, salvo que resulte evidente por el contexto. Cómo se aplica a un producto concreto es una pregunta para un abogado. La respuesta de producto es barata en cualquier caso: marcar como tales los cambios hechos por el agente, allí donde aparezcan.

5. ¿Cómo se deshace una acción?

Cada acción del agente necesita un camino de vuelta, decidido antes del lanzamiento. Tres patrones cubren casi todos los casos:

• Primero el borrador. El agente escribe un borrador (un email, un asiento contable, una respuesta a un ticket) y una persona lo envía. Deshacer es borrar el borrador.
• Escrituras reversibles. Los cambios del agente se guardan como un conjunto que el usuario revierte con un clic, con los valores anteriores conservados.
• Ejecución diferida. Las acciones irreversibles esperan en una ventana corta y visible en la que se pueden cancelar, como la opción de deshacer el envío en los programas de correo.

Junto a la opción de deshacer hace falta un registro de ejecuciones: en cada una, qué la disparó, qué datos leyó, qué acciones hizo y con qué resultado. Lo lee el equipo de soporte cuando un cliente pregunta por qué ha cambiado algo, y lo leen los desarrolladores cuando falla una evaluación. También es la materia prima para demostrar a un cliente que el agente ahorra tiempo, y responde al "valor poco claro" de Gartner con datos del propio producto.

6. ¿Cuánto cuesta ejecutarlo y quién lo paga?

Un asistente cuesta dinero cuando un usuario escribe. Un agente cuesta dinero en cada ejecución, programada o disparada por un evento, la mire alguien o no. Un trabajo nocturno sobre todas las cuentas multiplica las llamadas al modelo por el número de clientes. Son los "costes crecientes" de la previsión de Gartner, y son una decisión de precio tanto como de ingeniería.

Decide pronto cómo se miden las ejecuciones (por ejecución, por elemento procesado o dentro de la cuota de un plan), pon un tope por cuenta y muestra el consumo en el producto antes de que lo muestre la factura. En la parte técnica, mantén pequeño el contexto de cada ejecución: al agente le llegan solo los registros que el trabajo necesita. Los pasos rutinarios los hace un modelo barato, y el caro se reserva para el paso que requiere criterio.

Cómo se ve en la práctica

Pongamos un software hipotético de facturación B2B que quiere un agente para reclamar facturas vencidas. Las seis decisiones quedan así:

1. Trabajo: cada mañana, encontrar las facturas vencidas hace más de 14 días y preparar un recordatorio para cada una, en el idioma del cliente, con la factura adjunta.
2. Autonomía: nivel aprobador para el primer recordatorio, nivel observador para el segundo cuando un equipo lo activa.
3. Permisos: lectura de facturas y contactos, creación de borradores de email, sin acceso a los ajustes de pago ni a las facturas rectificativas.
4. Revisión: una cola "Recordatorios por enviar" en la página de facturas, una fila por factura, con el borrador visible y un botón para enviarlos todos.
5. Deshacer: borradores hasta la aprobación; los emails aprobados esperan diez minutos en la bandeja de salida antes de salir.
6. Coste: una ejecución por cuenta al día, un modelo pequeño para los borradores, consumo contado dentro de la cuota mensual del plan.

Nada de esto es exótico. La mayor parte del trabajo son colas, permisos, registros y ajustes, las partes de un SaaS que ya existen, y la llamada al modelo es una parte pequeña. Por eso las funciones con agentes encajan mejor en productos con un modelo de datos y unos roles ya limpios: el agente hereda todo lo que el producto hace bien, y todo lo que hace mal.