Alertas de conversación para agentes de IA: qué detectar y a quién derivarlo

Las alertas de conversación son señales automatizadas que se generan cuando una interacción de un cliente con un agente de IA cumple una condición definida: una derivación omitida, una carencia de cumplimiento normativo, un intento de sondeo de seguridad o una caída brusca del sentimiento. Se diferencian de las notificaciones habituales porque se activan por el contenido y el resultado de la conversación, no por un evento del sistema, como un error del servidor o la entrega de un mensaje de texto. Una alerta útil identifica el problema, muestra las evidencias y llega a una persona que puede actuar.

Esta guía explica qué son las alertas de conversación, qué eventos justifican una, cómo configurar los umbrales y la asignación, qué no pueden indicar y cómo contribuyen a aportar evidencias de auditoría conforme a normas como el EU AI Act.

En resumen

• Una alerta de conversación se activa por lo que se ha dicho o hecho en una interacción con un cliente, como rechazar una derivación a una persona o no informar del uso de IA, y no por el estado de la infraestructura.
• Genere alertas sobre eventos ante los que alguien pueda actuar. Envíe las tendencias y las señales informativas a un panel de control.
• Asigne las alertas según su gravedad y responsable, exija que una condición persista antes de activarlas y mantenga cada alerta vinculada a la transcripción que la originó.
• Las alertas detectan patrones conocidos. Las auditorías independientes y la revisión por muestreo descubren los puntos ciegos que las reglas no describen.
• Almacene las evidencias de las alertas con controles de acceso y un plazo de conservación, de modo que sirvan a los equipos de calidad, los equipos jurídicos y los reguladores.

Índice

• Qué son las alertas de conversación
• Qué eventos de una conversación justifican una alerta
• Cómo configurar los umbrales, la asignación y el escalado
• Alertas y evidencias de auditoría
• Qué exige el EU AI Act
• Privacidad y tratamiento de datos en los registros de alertas
• Perspectiva: por qué las alertas necesitan una verificación independiente
• Qué no pueden hacer las alertas
• Cómo llevarlo a la práctica con Lexic
• Preguntas frecuentes
• Fuentes

Qué son las alertas de conversación

El término de búsqueda «alertas» devuelve principalmente herramientas de envío masivo de SMS: programas que envían un mensaje de texto a un grupo sobre un evento, el cierre de un colegio o una interrupción del servicio. Eso es mensajería saliente. Las alertas de conversación funcionan en sentido contrario. Supervisan las conversaciones que ya se producen entre los clientes y un chatbot, un agente de voz o un agente humano, y avisan a su equipo cuando algo requiere atención.

Tres aspectos las diferencian de otras herramientas afines:

La distinción es importante para los agentes de IA. Un agente puede responder a todas las solicitudes dentro del límite de latencia previsto, sin errores técnicos, y aun así proporcionar a un cliente información incorrecta sobre las políticas o ignorar una solicitud para hablar con una persona. La supervisión tradicional no detecta eso. Las alertas a nivel de conversación están diseñadas para hacerlo.

Qué eventos de una conversación justifican una alerta

No todas las desviaciones merecen una notificación. Los casos más claros son los eventos en los que el coste de una demora es elevado y una persona puede cambiar el resultado. Agrupados por el equipo responsable:

Experiencia del cliente

• Derivación fallida o ignorada. El cliente pide hablar con una persona, o expresa frustración repetidamente, y el agente continúa. En nuestras propias auditorías, el 85% de los agentes evaluados no derivó adecuadamente las incidencias a un representante humano, por lo que consideramos esta alerta de máxima prioridad.
• Bucles repetidos. La misma pregunta se plantea tres o más veces sin resolverse.
• Cambios bruscos de sentimiento o urgencia. Una conversación que comienza con un tono neutro y termina en una queja, una amenaza de cancelación o una mención a un regulador.
• Abandono tras una respuesta del agente. El cliente abandona la conversación inmediatamente después de una respuesta concreta, lo que puede indicar que esta era confusa o incorrecta.

Cumplimiento normativo y transparencia

• Ausencia de aviso sobre el uso de IA. El agente no informa al usuario de que está interactuando con un sistema de IA cuando es obligatorio hacerlo.
• Compromisos que el agente no debe asumir. Reembolsos, promesas con efectos jurídicos, excepciones de precios o asesoramiento médico y financiero fuera del ámbito autorizado.
• Intenciones sujetas a regulación. Reclamaciones, señales de vulnerabilidad del cliente, solicitudes de ejercicio de derechos de los interesados o datos de pago compartidos en un canal que no debería recogerlos.

Seguridad

• Intentos de inyección de prompts o de elusión de restricciones. Un usuario intenta anular las instrucciones del agente o extraer información interna.
• Divulgación de datos. El agente revela datos de otro cliente, documentos internos o instrucciones del sistema.
• Acciones no autorizadas. El agente ejecuta un reembolso, un cambio en una cuenta o una acción sobre un ticket sin la verificación exigida.

Fiabilidad técnica

• Respuestas incoherentes. La misma pregunta recibe respuestas sustancialmente distintas en diferentes sesiones o canales.
• Fallos de herramientas o integraciones ocultos al usuario. El agente afirma que una tarea está completada cuando la llamada al backend ha fallado.
• Regresión tras un cambio. Una actualización del modelo, del prompt o de la base de conocimiento altera el comportamiento en conversaciones que antes superaban las pruebas.

Cómo configurar los umbrales, la asignación y el escalado

Las alertas solo ayudan si las personas confían en ellas. Un canal que genera avisos constantemente acaba silenciado, y un canal silenciado deja pasar la conversación que realmente importaba. Las directrices consolidadas de supervisión de los equipos de ingeniería se aplican directamente a las alertas de conversación.

Asegúrese de que cada alerta permita actuar

Las buenas prácticas de alertas de Grafana recomiendan que las alertas permitan actuar, expliquen qué las ha activado, identifiquen a un responsable y se dirijan al equipo correspondiente. También aconsejan exigir que una condición persista durante un periodo de espera antes de activar la alerta y mostrar en un panel de control la información que no requiera medidas. En las conversaciones, esto se traduce en una regla sencilla: si nadie puede hacer nada al respecto hoy, debe incluirse en un informe de tendencias.

Reserve los avisos urgentes para situaciones urgentes

Las directrices de ingeniería de fiabilidad de sitios de Google indican que un aviso urgente debe corresponder a una situación urgente ante la que se pueda actuar y que los avisos repetidos por situaciones inocuas provocan fatiga por alertas, ya que cada aviso requiere una respuesta humana fundamentada. La ausencia de un aviso sobre el uso de IA o una filtración de datos cumple ese criterio. Una puntuación de sentimiento ligeramente negativa en un único chat, no.

Una escala práctica de gravedad

La mayoría de los equipos establece tres o cuatro niveles. Una opción viable:

Pasos para configurarlo

1. Elabore un inventario de las funciones del agente. Enumere lo que el agente puede hacer, decir y decidir. Las alertas se definen a partir de los límites de ese ámbito.
2. Ordene los escenarios según sus consecuencias. Empiece por los pocos en los que un fallo ocasiona perjuicios jurídicos, financieros o de seguridad.
3. Defina cada desencadenante con precisión. «El cliente solicitó hablar con una persona y las tres intervenciones siguientes del agente no ofrecieron una derivación» se puede comprobar. «Mala experiencia», no.
4. Asigne un responsable a cada tipo de alerta. Los problemas de experiencia del cliente se remiten a ese equipo; las carencias informativas, al de cumplimiento normativo; y los intentos de inyección, al de seguridad.
5. Añada persistencia y agrupación. Para las señales con mucho ruido, exija dos o más incidencias dentro de un intervalo y agrupe los duplicados en una única notificación.
6. Adjunte las evidencias. Cada alerta incluye la transcripción o grabación, la regla que la activó, la versión del agente y la marca de tiempo.
7. Revise mensualmente las propias alertas. Controle cuántas dieron lugar a medidas, cuántas se descartaron y qué reglas nunca se activan. Retire o reajuste las menos útiles.

Los valores de referencia también ayudan. Antes de elegir umbrales numéricos de sentimiento o tasas de fallo, observe durante un periodo el rango habitual del agente y genere alertas ante desviaciones significativas, en lugar de basarse en cifras estimadas sin fundamento.

Alertas y evidencias de auditoría

Una alerta es una indicación. El registro que la respalda es lo que permite responder a una reclamación, una disputa con un proveedor o una consulta de un regulador. La guía de gobernanza de la IA en centros de contacto de TechTarget señala que las pistas de auditoría pueden mostrar qué se le dijo al cliente, qué datos utilizó el modelo, qué versión tomó la decisión y si una persona asumió el control. Son evidencias útiles tanto para los equipos de calidad y jurídicos como para los reguladores.

La misma fuente recomienda clasificar los sistemas de IA por nivel de riesgo y establecer reglas estrictas, con supervisión humana dentro del proceso, para interacciones de gran trascendencia, como el procesamiento de pagos o los compromisos jurídicos. Los niveles de alerta pueden reflejar esa clasificación: cuanto mayor sea la categoría de riesgo de la interacción, menor será la tolerancia y más rápida la derivación a una persona.

Para que las evidencias sean utilizables, incluya lo siguiente en cada registro de alerta:

• La conversación completa, con el canal y las marcas de tiempo
• La regla o el mecanismo de detección que se activó y su versión
• El agente, el modelo y la versión del prompt o de la configuración utilizados
• Si se avisó a una persona, cuándo se hizo y qué medidas tomó
• Una comprobación de integridad que permita detectar manipulaciones, para demostrar que el registro no ha cambiado

Qué exige el EU AI Act

Las empresas que atienden a clientes en la Unión Europea, incluidas las estadounidenses que acceden a ese mercado, deben considerar las alertas como parte del diseño de la supervisión, no como un complemento. Dos disposiciones son especialmente relevantes.

Supervisión humana. El artículo 14 exige que los sistemas de IA se diseñen de modo que personas competentes puedan comprenderlos, detectar anomalías e intervenir o detener el sistema, tal como se describe en una guía de transparencia alojada en el Observatorio de Políticas de IA de la OCDE. La misma guía señala que, para los sistemas de alto riesgo, las instrucciones previstas en el artículo 13 deben incluir las medidas de supervisión humana del artículo 14. Una alerta que llega a una persona formada, con las evidencias necesarias para decidir, es una forma práctica de demostrar que la supervisión funciona en la práctica, no solo sobre el papel.

Transparencia hacia los usuarios. Una guía práctica del artículo 50 explica que los proveedores de chatbots y asistentes virtuales deben diseñarlos de modo que los usuarios sean informados de que interactúan con IA, y que los borradores de directrices incluyen a los agentes de IA dentro de esa obligación. Una alerta por ausencia de aviso es una forma directa de detectar omisiones, especialmente tras un cambio de configuración o en un nuevo idioma o canal.

Las obligaciones aplicables a un despliegue concreto dependen de su función y clasificación de riesgo. Confírmelo con asesores jurídicos familiarizados con el EU AI Act antes de utilizar cualquier configuración de supervisión como prueba de cumplimiento.

Privacidad y tratamiento de datos en los registros de alertas

Las alertas copian partes de las conversaciones de los clientes en nuevos destinos: colas, herramientas de chat y sistemas de gestión de tickets. Esto amplía la superficie de exposición de los datos personales. Las directrices sobre privacidad y seguridad para aplicaciones de IA del Gobierno de Canadá recomiendan controles de acceso basados en roles para los registros de auditoría, plazos de conservación definidos para los datos recogidos y su eliminación al finalizar esos plazos. Aplicado a las alertas:

• Envíe un enlace a las evidencias, no la transcripción completa, en las notificaciones de chat.
• Limite el acceso a las transcripciones a los responsables que lo necesiten para ese tipo de alerta.
• Enmascare los datos de pago y de identidad antes de que lleguen a un canal de alertas.
• Establezca un plazo de conservación para los registros de alertas y aplíquelo a todos los sistemas que los almacenen.
• Registre quién ha abierto cada registro.

Las directrices de Canadá no son una norma estadounidense ni de la UE, por lo que debe comprobar los requisitos aplicables en sus jurisdicciones, como el RGPD para los datos de residentes en la UE, al establecer los plazos.

Perspectiva: por qué las alertas necesitan una verificación independiente

La calidad de las alertas depende de las reglas que las sustentan, y esas reglas las redacta el equipo que ya considera que el agente funciona. Esa es la debilidad estructural de la supervisión dirigida por el proveedor: la parte que ha creado o vende el agente también define qué se considera un problema.

Nosotros lo abordamos desde el otro lado. Lexic Compass interactúa con agentes de IA conversacional de cualquier proveedor como lo hacen los usuarios reales y evalúa la experiencia del cliente, la seguridad, la fiabilidad técnica y el cumplimiento normativo. Así se detectan problemas que los paneles de control y las reglas basadas en palabras clave no describen de antemano. El hallazgo de que el 85% de los agentes evaluados no realizaba las derivaciones adecuadamente surgió de su comportamiento, no de un campo de registro que alguien hubiera decidido supervisar.

La configuración más sólida combina ambas capas. Las auditorías independientes muestran dónde están los puntos ciegos. Después, las alertas continuas de conversación vigilan esos patrones en producción, con evidencias que resisten el escrutinio cuando un proveedor, un auditor o un regulador pregunta qué ocurrió. La generación de hashes criptográficos por un tercero respalda esa trazabilidad.

La gobernanza de la IA conversacional no se determinará por cuántas alertas recibe un equipo. Se determinará por si la alerta adecuada llegó a la persona adecuada con pruebas adjuntas.

Sergio Llorens

Qué no pueden hacer las alertas

Las alertas detectan lo que se ha definido. Conviene tener en cuenta tres limitaciones al planificar.

• Riesgos cuya existencia se desconoce. Una regla no puede activarse ante un modo de fallo que nadie ha descrito. Las pruebas adversariales periódicas, los escenarios predefinidos y la revisión humana por muestreo los detectan y permiten incorporar nuevas reglas al conjunto de alertas.
• La detección es probabilística. Los clasificadores de sentimiento e intención cometen errores. Mida los falsos positivos y los falsos negativos sobre una muestra etiquetada y ajuste los umbrales a partir de esos resultados, no por intuición.
• Fallos silenciosos. Si el agente ofrece con seguridad una respuesta incorrecta y el cliente no se queja, no se activa ninguna regla de sentimiento. Contrastar las respuestas con información de referencia verificada, como los documentos de políticas, permite detectar lo que el tono no revela.

Por tanto, un programa equilibrado tiene tres capas: alertas inmediatas para eventos conocidos de consecuencias graves, revisión programada de una muestra de conversaciones y pruebas independientes del agente desde la perspectiva del cliente, repetidas después de cada cambio importante del modelo o del prompt.

Cómo llevarlo a la práctica con Lexic

Lexic ofrece dos productos conectados. Lexic Compass es nuestra plataforma de auditoría de agentes de IA. Evalúa de forma independiente agentes conversacionales de cualquier proveedor y genera evidencias que permiten tomar medidas para gobernar los agentes en producción y exigir responsabilidades a los proveedores. Los servicios están disponibles en las modalidades Flash Preview, Audit Sprint y Enterprise Continuous Trust, descritas en la página de opciones de auditoría.

Lexic Pulse analiza el 100% de las conversaciones con clientes en llamadas, chats, correos electrónicos y tickets. Proporciona información sobre sentimiento, riesgo de abandono y oportunidades; puntuaciones de estado de ánimo, NPS y urgencia; alertas inmediatas; e integraciones con CRM, sistemas de gestión de tickets y herramientas de comunicación. Los equipos que necesitan alertas y una visión independiente del comportamiento del agente pueden empezar por cualquiera de los dos productos. Para conocer los precios y el alcance, consulte las páginas anteriores o la página de inicio de Lexic.

Preguntas frecuentes

¿Cuál es la diferencia entre las alertas de conversación y la analítica de conversaciones?

La analítica resume numerosas conversaciones para identificar temas, tendencias y segmentos. Las alertas destacan una conversación individual o un patrón repentino que requiere actuar de inmediato. La mayoría de los equipos necesita ambas: analítica para aprender y alertas para responder.

¿Cómo puedo evitar la fatiga por alertas?

Active alertas solo ante condiciones sobre las que alguien pueda actuar, asigne cada alerta a un responsable y exija que la condición persista antes de activarla. Envíe las señales informativas a un panel de control. Revise cada mes qué alertas se descartaron y retire las que nadie utiliza.

¿Cumplen las alertas de conversación los requisitos del EU AI Act?

Ninguna herramienta lo hace por sí sola. Las alertas facilitan la supervisión humana porque comunican las anomalías a una persona competente que puede intervenir, y pueden detectar la ausencia de avisos sobre el uso de IA. Sus obligaciones dependen de su función y de la categoría de riesgo de su sistema, por lo que debe confirmarlas con asesores jurídicos.

¿Qué comportamiento de un agente de IA debe activar una alerta en primer lugar?

Empiece por las derivaciones fallidas, la ausencia de avisos sobre el uso de IA en flujos regulados, la exposición de datos y los compromisos que el agente no está autorizado a asumir. Son los casos con consecuencias más graves y tienen definiciones claras y verificables.

Fuentes

• Buenas prácticas | Documentación de Grafana
• Google SRE: supervisión de sistemas distribuidos
• Guía práctica de gobernanza de la IA en centros de contacto | TechTarget
• Privacidad y seguridad para aplicaciones de asistencia con IA | Canada.ca
• Guía de transparencia | Observatorio de Políticas de IA de la OCDE
• Las normas de transparencia del EU AI Act: guía práctica del artículo 50