El 13 de mayo de 2026 pasaron dos cosas que, leídas juntas, cuentan la historia real de los agentes de IA este año.
Por un lado, Anthropic anunció Claude for Small Business: agentes empaquetados, con flujos prefabricados y conectores a las herramientas de gestión que ya usa cualquier pyme. La barrera de entrada se desploma. Ya no hace falta un equipo de ingeniería para poner un agente a trabajar sobre tu contabilidad o tus leads.
Por otro, Sinch publicó el informe The AI Production Paradox: el 74% de las empresas que ya habían desplegado un agente de IA de comunicación con clientes ha tenido que revertirlo o apagarlo por un fallo de gobernanza.
El mismo día: los agentes llegan a la pyme en formato "activar y usar", y tres de cada cuatro de quienes ya los tienen en producción han tenido que dar marcha atrás con alguno. No es una contradicción. Es la descripción exacta del momento en el que estamos, y explica bastante bien qué hay que hacer antes de encender nada.
Este artículo continúa lo que escribí en abril sobre qué es real y qué es marketing en los agentes de IA de 2026. Allí la pregunta era "¿esto funciona?". Aquí la pregunta es otra: funciona, ¿y ahora cómo lo gobierno?
Qué dice exactamente el informe de Sinch
Conviene fijar los números antes de interpretarlos, porque esta cifra se está citando ya bastante mal.
Sinch encuestó a 2.527 decisores sénior en 10 países y 6 industrias, con trabajo de campo entre enero y febrero de 2026. Los datos relevantes:
| Dato | Cifra |
|---|---|
| Organizaciones con agentes de IA ya en producción | 62% |
| Han revertido o apagado un agente de cara al cliente tras desplegarlo | 74% |
| Idem, entre organizaciones con guardarraíles "totalmente maduros" | 81% |
| Planean aumentar la inversión en IA en 2026 | 98% |
Lo primero que hay que entender: el 74% no mide agentes que no funcionan. Mide agentes que se desplegaron, se pusieron delante de clientes reales y hubo que retirarlos o pausarlos por un fallo de gobernanza. Es una métrica de operación, no de capacidad del modelo.
Y lo segundo, que es lo interesante: ese mismo 98% que ha tenido que apagar cosas va a invertir más este año. No están abandonando. Están aprendiendo dónde duele.
Un "rollback" en este contexto no significa que el agente alucinara y se cancelara el proyecto. Significa que alguien detectó un comportamiento fuera de límites y ejecutó una decisión operativa: pausar, acotar o apagar. Eso requiere que alguien estuviera mirando.
La cifra que descoloca: 81% entre los que tienen guardarraíles maduros
Aquí es donde casi todo el mundo lee mal el informe.
Si las organizaciones con guardarraíles "totalmente maduros" revierten agentes más a menudo (81%) que la media (74%), la lectura perezosa es: "la gobernanza no sirve de nada, o incluso empeora las cosas". Es exactamente al revés.
Quien no instrumenta no revierte, porque no se entera. Un agente que atiende a tus clientes sin logging, sin métricas de negocio y sin alertas no deja de fallar: simplemente falla en silencio. Los clientes se van, las conversaciones se pudren, las promesas imposibles se cumplen a pérdida, y nadie en la empresa tiene un dato que le diga "esto está roto". Ese agente jamás aparecerá en una estadística de rollbacks, y no porque funcione bien.
La organización madura, en cambio, ve el fallo a los tres días, lo mide, lo apaga, corrige el alcance y vuelve a encenderlo. Registra un rollback. Puntúa "peor" en la encuesta. Y tiene el sistema en mejor estado.
Un rollback registrado es un indicador de madurez, no de fracaso. La pregunta que le harías a un proveedor —o a tu propio equipo— no es "¿cuántas veces habéis tenido que apagarlo?", sino "¿cómo os enterasteis?". Si no saben responder a la segunda, la primera no significa nada.
Traducido a la práctica: si llevas seis meses con un agente conversacional en producción y nunca has tenido que tocarlo, hay dos posibilidades. La buena es que su alcance sea tan pequeño que no pueda romper nada. La mala, y la más frecuente, es que no tengas forma de saber lo que está haciendo.
El otro titular del mismo día: agentes empaquetados para la pyme
Claude for Small Business no es un plan nuevo ni un producto separado. Es un toggle dentro de Claude Cowork que se activa sobre cualquier plan de pago existente, sin coste adicional. Incluye 15 flujos de trabajo agénticos prefabricados y conectores a herramientas de gestión como QuickBooks, PayPal, HubSpot, Canva, DocuSign, Google Workspace o Microsoft 365, entre otras.
Los casos de uso que plantea son reconocibles para cualquier empresa pequeña: planificar nóminas, conciliar libros, perseguir facturas impagadas, triar leads entrantes, redactar campañas, revisar contratos.
Esto importa por una razón concreta: cambia quién puede desplegar un agente. Hasta ahora, poner un agente delante de un proceso de negocio requería alguien que supiera de arquitectura, integraciones y control de errores — y esa persona, con suerte, pensaba en los guardarraíles por oficio. Un toggle lo pone al alcance de la responsable de administración un martes por la tarde.
No es una crítica al producto. Los flujos prefabricados están bien pensados y la mayoría son de bajo riesgo. Es una observación sobre el perfil de riesgo agregado: la curva de adopción se acelera justo cuando la encuesta de Sinch nos dice que la gobernanza es el cuello de botella.
Hay una diferencia enorme entre un agente que redacta un borrador que tú revisas y un agente que envía algo a un cliente o mueve dinero. El primero se puede activar hoy sin ceremonia. El segundo necesita todo lo que viene en la segunda mitad de este artículo, tanto si lo has construido tú como si viene empaquetado.
Por qué falla un agente de cara al cliente
En los proyectos que he visto de cerca, los fallos de agentes conversacionales no vienen del modelo. El modelo entiende bien al cliente y redacta mejor que muchos humanos con prisa. Los fallos vienen de cuatro sitios, siempre los mismos.
1. Alcance mal acotado
El error clásico: se define lo que el agente debe hacer y no lo que no puede hacer bajo ninguna circunstancia. Se le dan las herramientas para consultar pedidos, abrir incidencias y aplicar descuentos, y el límite del descuento vive en el prompt como una frase ("no ofrezcas más de un 10%") en lugar de en el código como una validación.
Un límite escrito en lenguaje natural es una sugerencia. Un cliente insistente, una conversación larga o una instrucción hábil lo mueven. Un límite en código no se mueve.
Lo mismo pasa con el dominio temático: un agente de soporte al que nadie le ha puesto una frontera acabará opinando sobre la política de devoluciones de la competencia, sobre plazos que nadie puede cumplir o sobre asuntos que comprometen legalmente a la empresa.
2. Sin criterio de escalado a persona
Casi todos los agentes tienen un botón de "hablar con un humano". Muy pocos tienen definido cuándo el propio agente debe pulsarlo sin que el cliente lo pida.
Es una distinción crítica. El cliente enfadado pide humano y lo consigue. El cliente educado que lleva ocho mensajes recibiendo respuestas que no resuelven su problema no lo pide: se cansa y se va. El agente tiene que ser capaz de detectar su propia incompetencia y ceder el control por iniciativa propia.
Un agente sin criterio de escalado explícito tiene un incentivo estructural perverso: siempre le sale más "barato" seguir contestando que reconocer que no puede.
3. Sin trazabilidad
Cuando un cliente reclama —o cuando lo hace su abogado— la pregunta es simple: "¿qué le dijo exactamente vuestro sistema, y por qué?". Si tu respuesta es que el modelo generó eso y no guardáis las conversaciones ni las llamadas a herramientas, no tienes defensa.
La trazabilidad no es solo un requisito de auditoría. Es la única forma de aprender del fallo. Sin registro de qué herramientas invocó el agente, con qué parámetros, con qué contexto y con qué resultado, un fallo es irreproducible: no puedes corregirlo, solo puedes apagar el agente entero. Que es, precisamente, lo que hizo ese 74%.
4. Sin métrica de negocio definida antes del despliegue
Este es el que más proyectos entierra. Se despliega el agente porque "reduce la carga de soporte", pero nadie ha medido la carga de soporte antes. A las seis semanas, alguien de dirección pregunta si está funcionando y la respuesta es un puñado de anécdotas: dos clientes encantados, uno furioso y un pantallazo simpático que circula por el grupo de WhatsApp.
Sin baseline y sin umbral, la decisión de mantener o apagar el agente se toma con la anécdota más reciente. Y las anécdotas negativas pesan siempre más, así que el agente acaba apagado por motivos políticos aunque estuviera funcionando. Es el mismo problema que abordo en el framework de validación de casos de uso de IA en cuatro semanas: el umbral se fija antes, o no se fija nunca.
5. Y el que nadie escribe: no hay dueño
Un agente en producción es un sistema vivo. El modelo se actualiza, los productos cambian, la política de devoluciones se modifica y el catálogo crece. Si no hay una persona con nombre y apellidos responsable de revisar su comportamiento con una cadencia definida, la degradación es cuestión de meses.
Los cinco elementos que hay que montar antes de encender
Esto es lo que, en mi experiencia, separa un despliegue que se puede defender de uno que acabará apagado en caliente. Ninguno de los cinco es opcional para un agente que habla con clientes.
Límites duros de acción
En código, no en el prompt. Una lista explícita de acciones permitidas, y todo lo demás denegado por defecto. Para cada acción con impacto económico o contractual, un límite numérico validado fuera del modelo.
- Lista blanca de herramientas: el agente solo puede llamar a lo que está en la lista.
- Rangos duros: importe máximo de compensación, número máximo de reenvíos, ventana temporal en la que puede actuar.
- Acciones irreversibles fuera del alcance: emitir un abono, cancelar un contrato o borrar datos requieren confirmación humana, siempre.
- Límite de pasos y de coste por conversación, para que un bucle no se convierta en una factura.
La prueba de fuego: si la única cosa que impide que tu agente regale un producto es una frase en su prompt, no tienes un límite, tienes una esperanza.
Escalado a persona
Define por escrito, antes de desplegar, los disparadores de escalado. Los que uso como base:
- El cliente lo pide, explícita o implícitamente.
- Se detecta enfado, vulnerabilidad o riesgo reputacional.
- La misma pregunta se repite más de N veces sin resolverse.
- La conversación toca un tema de la lista negra (bajas, reclamaciones formales, temas legales, incidencias de seguridad o de datos personales).
- El agente necesitaría una acción fuera de sus límites duros.
- Baja confianza del propio agente en su respuesta.
Y, sobre todo: define qué pasa cuando no hay nadie al otro lado. Un escalado a las 23:40 de un sábado que muere en una cola vacía es peor que no haber escalado. La respuesta correcta suele ser un mensaje honesto de "esto lo va a ver una persona el lunes a primera hora" y un ticket creado de verdad.
Logging de cada decisión
No basta con guardar la transcripción. Para poder reconstruir lo que pasó necesitas registrar, por cada turno:
| Qué registrar | Para qué sirve |
|---|---|
| Mensaje del cliente y respuesta del agente | Reconstruir la conversación tal como la vivió el cliente |
| Herramientas invocadas, parámetros y respuesta | Saber sobre qué datos decidió, no solo qué dijo |
| Versión del modelo y del prompt del sistema | Correlacionar cambios de comportamiento con despliegues |
| Contexto recuperado (documentos, base de conocimiento) | Distinguir alucinación de dato desactualizado |
| Escalados y su motivo | Medir si el criterio de escalado está calibrado |
| Coste y latencia por conversación | Detectar bucles y degradación antes de que escale |
Con esto, un fallo se reproduce en diez minutos. Sin esto, un fallo se convierte en una decisión de apagar todo. Añade una política de retención y de minimización de datos personales acorde con el RGPD: registrar todo lo necesario para auditar, sin convertir tus logs en un almacén paralelo de datos sensibles. Bien hecho, el logging ayuda a cumplir las obligaciones de trazabilidad; mal hecho, crea un problema nuevo.
Métrica de éxito definida antes del despliegue
Una métrica de negocio, un baseline medido y un umbral, firmados por la persona responsable del área antes de encender nada. Ejemplos de métricas que sí sirven:
- Porcentaje de conversaciones resueltas sin intervención humana (con una definición de "resuelta" acordada).
- Tiempo hasta primera respuesta útil frente al baseline humano.
- Tasa de escalado, con banda alta y baja: un 2% de escalados no es una buena noticia, es la señal de que el agente no está cediendo el control cuando debe.
- Satisfacción medida al cierre, segmentada agente vs. humano.
- Reaperturas: cuántas conversaciones "resueltas" vuelven en 72 horas.
- Coste por conversación resuelta, incluyendo la revisión humana.
Y una métrica de guardia que debería disparar alarma sola: proporción de conversaciones que terminan sin resolución y sin escalado. Ese número, si nadie lo mira, es donde se esconde el fallo silencioso.
Plan de apagado
Escrito, probado y con una persona de guardia. Un plan de apagado que nunca se ha ensayado no es un plan.
- Interruptor real: una acción, sin desplegar código, que devuelve todo el tráfico a la cola humana. Si apagar el agente requiere un release, no tienes kill switch.
- Modo degradado intermedio: antes del apagado total, la opción de dejarlo solo en lectura (responde información, no ejecuta acciones). La mayoría de incidentes se resuelven aquí.
- Umbrales de disparo definidos: qué valor de qué métrica obliga a apagar, decidido en frío y no en mitad del incidente.
- Capacidad humana de reserva: quién absorbe el volumen y durante cuánto tiempo puede hacerlo.
- Comunicación: qué se le dice a los clientes que quedaron a medias en una conversación.
- Post-mortem: qué falló, en qué capa, qué guardarraíl faltaba. Y volver a encender con el alcance corregido, no con el mismo alcance y más esperanza.
Ensaya el apagado antes de necesitarlo. Un simulacro de quince minutos en horario de baja carga te dice, gratis, si tu interruptor funciona y si tu equipo humano puede absorber el volumen. Descubrirlo durante el incidente cuesta clientes.
Los cinco, en una tabla
| Elemento | Pregunta que responde | Señal de que no lo tienes |
|---|---|---|
| Límites duros de acción | ¿Qué es imposible que haga? | Los límites están en el prompt |
| Escalado a persona | ¿Cuándo deja de decidir él? | Solo escala si el cliente lo pide |
| Logging de decisiones | ¿Qué hizo exactamente y por qué? | Solo guardas transcripciones |
| Métrica y umbral | ¿Está funcionando? | La respuesta son anécdotas |
| Plan de apagado | ¿Cómo lo paro en dos minutos? | Apagarlo requiere un despliegue |
Cómo aplicar esto a un agente empaquetado
La objeción razonable a todo lo anterior: "yo no construyo el agente, lo activo con un toggle". Válida. Cambia la implementación, no los requisitos.
Con un producto empaquetado, tu trabajo se desplaza a tres sitios:
- Los permisos que concedes. Es la traducción directa de "límites duros de acción". Un conector de solo lectura sobre tu contabilidad tiene un perfil de riesgo radicalmente distinto al de uno con permiso de escritura. Concede el mínimo, y súbelo cuando tengas datos, no antes.
- Dónde termina el agente y empieza la persona. En los flujos empaquetados, la frontera segura casi siempre es la misma: el agente prepara, la persona envía o aprueba. Un agente que redacta el recordatorio de una factura impagada es una ayuda enorme; un agente que lo envía solo a un cliente estratégico es una decisión de negocio que alguien tiene que tomar conscientemente.
- Lo que puedes auditar. Antes de conectar nada, comprueba qué registro te deja el producto, cuánto tiempo lo conserva, dónde se procesan los datos y cómo se revoca un acceso. Son las mismas preguntas de observabilidad y de datos que planteaba en la guía para evaluar a un proveedor de agentes, aplicadas a un SaaS en lugar de a un desarrollo a medida.
Y el criterio general, que sirve para ambos mundos: empieza por los flujos donde el agente propone y un humano dispone. Todo el valor de ahorro de tiempo está ahí, y casi todo el riesgo está en el otro lado.
Checklist: no enciendas un agente de cara al cliente hasta que tengas esto
Imprímela y que alguien la firme. Si falta un solo punto, el agente no sale a producción.
Alcance
- Lista explícita de acciones permitidas; el resto, denegado por defecto.
- Todo límite económico o contractual validado en código, no en el prompt.
- Acciones irreversibles excluidas o con confirmación humana obligatoria.
- Temas fuera de alcance definidos por escrito (legal, bajas, datos personales, competencia).
- Límite de pasos y de coste por conversación.
Escalado
- Disparadores de escalado documentados, incluidos los que activa el propio agente.
- Ruta de escalado probada de punta a punta, con persona real al otro lado.
- Comportamiento definido fuera del horario de atención.
- El cliente puede pedir humano en cualquier momento y funciona.
Trazabilidad
- Registro por turno de mensaje, respuesta, herramientas, parámetros y resultado.
- Versión de modelo y de prompt registradas en cada conversación.
- Retención definida y minimización de datos personales en los logs.
- Un incidente de la semana pasada se puede reconstruir en menos de quince minutos.
Medición
- Métrica de negocio, baseline y umbral fijados y firmados antes del despliegue.
- Banda alta y baja de tasa de escalado.
- Alerta automática sobre conversaciones cerradas sin resolver y sin escalar.
- Revisión humana de una muestra de conversaciones con cadencia fija.
Apagado
- Kill switch que no requiere despliegue de código.
- Modo degradado (solo lectura) disponible.
- Umbrales de disparo decididos en frío.
- Simulacro de apagado ejecutado al menos una vez.
- Capacidad humana de reserva identificada y avisada.
Responsabilidad
- Una persona con nombre es dueña del agente.
- Cadencia de revisión de comportamiento definida.
- Procedimiento de post-mortem acordado.
- Está claro qué se le comunica al cliente sobre que habla con un sistema automático.
Conclusión
La paradoja del informe de Sinch se disuelve en cuanto dejas de leer el 74% como una tasa de fracaso. Los agentes de cara al cliente funcionan lo bastante bien como para que el 62% de las empresas los tenga ya en producción y el 98% vaya a invertir más este año. Lo que todavía no está resuelto es el andamiaje que los rodea: límites, escalado, registro, métricas y un interruptor.
Ese andamiaje no es glamuroso. No sale en ninguna demo. Y es exactamente lo que separa a la empresa que apaga su agente un martes, lo corrige y lo vuelve a encender el jueves con el alcance bien puesto, de la que descubre seis meses tarde —por una reclamación— que llevaba medio año prometiendo cosas que no podía cumplir.
Con los agentes llegando empaquetados a la pyme, la ventaja competitiva ya no está en tener uno. Está en ser de los que se enteran de lo que hace.
¿Hablamos?
Si estás pensando en poner un agente delante de tus clientes —o ya tienes uno funcionando y no sabes muy bien qué está haciendo— podemos ayudarte a montar los límites, la trazabilidad y las métricas antes de que sea un problema. Cuéntanos tu caso en nuestro formulario de contacto y lo revisamos.
