Respuesta a incidentes en chatbots de IA: modo degradado, rollback y plan de contingencia

Un chatbot web puede estar técnicamente disponible y, aun así, causar una incidencia: las respuestas se vuelven lentas de repente, faltan fuentes, un modelo externo devuelve errores, una herramienta escribe datos incompletos o la calidad de la respuesta cae en un solo idioma. Si en esa situación se empieza a buscar quién es responsable o cómo desactivar el sistema, se pierde un tiempo valioso. Por ello, un playbook de incidentes define con antelación qué señales cuentan, quién decide y cómo pasa el chatbot de forma controlada a un modo degradado seguro.

El objetivo no es ocultar cada error tras una disponibilidad máxima. Un servicio limitado pero honesto suele ser mejor que un bot aparentemente normal que realiza afirmaciones no fiables. Esta guía muestra una estructura pragmática para equipos de sitio web, soporte y producto: desde la detección hasta el postmortem, pasando por el fallback y el rollback.

Qué se considera una incidencia en un chatbot de IA

Una incidencia es más que una caída completa del servicio. En los chatbots, los equipos deben considerar tanto los fallos técnicos como los funcionales. Los errores técnicos incluyen un aumento de la latencia, tiempos de espera agotados (timeouts) del proveedor, fallos en la recuperación de la base de conocimiento o integraciones defectuosas. Los fallos funcionales abarcan, por ejemplo, un aumento drástico de la tasa de fallbacks, una asignación incorrecta de fuentes, un idioma inesperado, llamadas a herramientas no permitidas o respuestas fuera del ámbito temático previsto.

Defina los umbrales siempre en función del contexto de uso. Una breve caída de un bot de preguntas frecuentes informativas se valora de manera muy distinta a la entrega de información incorrecta en un proceso crítico para el negocio. El Marco de Gestión de Riesgos de IA del NIST (NIST AI Risk Management Framework) recomienda documentar el uso previsto, los límites de la supervisión humana y las posibles consecuencias de los errores. Asimismo, señala los mecanismos de anulación manual, desactivación, recuperación y comunicación de incidentes de IA como parte de las operaciones.

Separar los dominios de error antes de reaccionar

Una señal genérica de «el chatbot no funciona» rara vez conduce a la medida correcta. Descomponga el servicio en dominios de error verificables:

• Interfaz y red: el widget no se carga, los mensajes no se transmiten o las respuestas se interrumpen.
• Modelo y proveedor: tiempos de espera agotados, límites de tasa, respuestas vacías o cambios llamativos en la calidad.
• Base de conocimiento y recuperación: las fuentes no están accesibles, están desactualizadas o no se encuentran para preguntas de prueba conocidas.
• Herramientas e integraciones: las operaciones de escritura, consultas de citas o transferencias devuelven errores o resultados no confirmados.
• Seguridad y permisos: las reglas de protección no se aplican, las entradas influyen en las instrucciones internas o una herramienta recibe permisos demasiado amplios.
• Configuración regional y enrutamiento: solo se ven afectados ciertos idiomas, temas o rutas de destino.

Esta separación evita que un equipo desactive todo el chatbot cuando solo una integración está afectada. Por el contrario, un estado HTTP correcto no debe ocultar un fallo funcional. El artículo sobre cómo probar el enrutamiento de chatbots de IA describe cómo comparar sistemáticamente las rutas esperadas con los resultados reales.

Un modelo de salud con señales técnicas y funcionales

Una buena observabilidad combina métricas, registros (logs), trazas y evaluaciones de calidad. Las métricas técnicas básicas incluyen la tasa de éxito, el tiempo de respuesta, las clases de error, la longitud de la cola y la disponibilidad de dependencias clave. En la parte de IA, se añaden las coincidencias de recuperación, el uso de fuentes, las interrupciones de respuesta, la tasa de fallback, la tasa de transferencia (handoff) y los resultados de un conjunto de referencia (Golden Set) reducido. La guía para medir la calidad de respuesta de chatbots de IA muestra cómo mantener este tipo de casos de prueba.

Para las estrategias de emergencia, Microsoft recomienda una monitorización integral, registros estructurados, cuadros de mando adaptados al público objetivo y, sobre todo, alertas orientadas a la acción. En un chatbot, esto significa que una alarma no debe limitarse a indicar «tasa de error alta», sino señalar el idioma o región afectado, el dominio de error, el inicio, el alcance y la entrada correspondiente en el runbook. Active alarmas únicamente cuando se requiera una intervención humana; de lo contrario, se genera fatiga por alertas.

Guarde solo los datos necesarios para la reconstrucción. El contenido completo de las conversaciones no es indispensable en todos los casos. Los eventos, referencias seudónimas breves y muestras de calidad controladas suelen ser suficientes. Encontrará recomendaciones al respecto en el artículo sobre cómo diseñar la analítica de chatbots de IA con minimización de datos.

Definir niveles de gravedad y desencadenantes claros

Una clasificación sencilla de tres niveles es suficiente para la mayoría de los equipos:

1. Observar: leve desviación sin un impacto apreciable para el usuario; la persona responsable analiza la tendencia y la muestra.
2. Limitado: una parte relevante de las respuestas, idiomas o integraciones se ve afectada; se activan el modo degradado y la coordinación interna.
3. Crítico: indisponibilidad generalizada, declaraciones falsas en procesos críticos para el negocio, acciones no controladas de herramientas, sospecha de fallo de seguridad o riesgo para los datos; las funciones afectadas se desactivan de inmediato y la incidencia se gestiona de forma oficial.

Documente para cada nivel los desencadenantes medibles, las acciones autorizadas y el rol con capacidad de decisión. Combine las métricas con una opción de escalado manual: el equipo de soporte o de contenidos puede detectar una incidencia antes que una alarma técnica. La publicación NIST SP 800-61 Revisión 3 sitúa la respuesta a incidentes dentro de la gestión continua de riesgos y destaca la detección, la respuesta y la recuperación como tareas interconectadas.

El modo degradado como una escala progresiva en lugar de un interruptor de encendido y apagado

Un chatbot robusto cuenta con varios estados de funcionamiento controlados. La escala concreta dependerá del caso de uso, pero puede estructurarse de la siguiente manera:

1. Funcionamiento normal: la base de conocimiento aprobada, el modelo y las integraciones permitidas están activos.
2. Respuestas limitadas: el bot responde únicamente a preguntas claramente delimitadas procedentes de fuentes verificadas; no se improvisa sobre temas inciertos.
3. Herramientas desactivadas: el bot explica que una acción no se puede ejecutar en ese momento y no confirma el éxito de ninguna operación sin un resultado fiable.
4. Modo asistencial: el bot solo ayuda con la orientación básica y deriva a un contacto humano verificado o a una vía de autoservicio.
5. Modo fuera de línea (offline): la conversación se cierra o se reemplaza por un aviso estático y accesible.

Cada transición requiere una condición, un responsable y una vía de retorno probada. Evite expresiones como «completado» o «reservado» cuando una acción dependiente no haya sido confirmada. En una transferencia a un agente, deben estar definidos el alcance del contexto, la protección de datos y la disponibilidad. A este respecto, resulta útil la guía sobre transferencia a agentes humanos en chatbots de IA.

Definir criterios de rollback antes del siguiente lanzamiento

Un rollback es conveniente cuando existe una relación temporal con un cambio y se demuestra que la versión anterior ofrece un estado más seguro. La capacidad de realizar un rollback no debe limitarse a las versiones de la aplicación, sino extenderse a las configuraciones de prompts, estados de la base de conocimiento, reglas de enrutamiento, permisos de herramientas y asignaciones de modelos. Determine qué componentes deben revertirse conjuntamente para evitar combinaciones incompatibles.

Defina también criterios de interrupción. Si un rollback no mejora las métricas, el equipo no debe insistir repetidamente en la misma medida; en su lugar, se pasa al siguiente nivel de modo degradado o al aislamiento de una dependencia. En sus prácticas de SRE, Google describe los rollbacks rápidos como una medida legítima ante incidentes, pero exige al mismo tiempo una coordinación estructurada y un registro continuo de las decisiones.

Antes de volver al funcionamiento normal, se requiere una comprobación de recuperación (Recovery-Check): indicadores de salud técnica estables, muestra del conjunto de referencia aprobada, idioma o región afectado verificado, herramientas validadas con casos de prueba sin riesgo y vía de transferencia accesible. Solo entonces se incrementa el tráfico de forma controlada.

El playbook de incidentes para los primeros 30 minutos

Un runbook conciso es más útil en una emergencia que una directriz general y extensa. Puede establecer el siguiente orden:

1. Confirmar la alarma o el informe de soporte y registrar la hora de inicio, las funciones afectadas y el impacto en los usuarios.
2. Determinar el nivel de gravedad del incidente y designar a un responsable de la gestión del incidente.
3. Detener cualquier otro cambio no coordinado y registrar los últimos lanzamientos o modificaciones en prompts, conocimiento o enrutamiento.
4. Activar un modo degradado seguro y restringir las herramientas o respuestas de riesgo.
5. Comparar las señales técnicas y funcionales; aislar las configuraciones regionales y dependencias afectadas.
6. Ejecutar el rollback o la solución temporal (workaround) según los criterios previamente definidos.
7. Informar al equipo de soporte, responsables de producto y otras partes interesadas con datos confirmados.
8. Evaluar el impacto tras cada medida y documentar la marca temporal, el resultado y la siguiente decisión.

Google SRE resume la gestión de incidentes en tres pilares: coordinación, comunicación y control. La definición clara de roles evita que varias personas realicen cambios contradictorios de forma simultánea. Los equipos pequeños pueden combinar roles; lo crucial es que una persona dirija la situación, otra se encargue de la mitigación técnica y alguien mantenga información de estado fiable.

Comunicación sin especulaciones

Los informes de estado deben incluir los efectos observados, las funciones afectadas, las vías alternativas activas y la hora de la siguiente actualización. No deben incluir causas no comprobadas ni estimaciones precipitadas del tiempo de recuperación. Si solo se ve afectado un idioma o una integración, especifíquelo con precisión. Si el alcance aún no está claro, mencione dicha incertidumbre.

En el caso de incidentes sensibles, se aplican además los procesos internos de seguridad, protección de datos y, si corresponde, notificación. El playbook habitual de soporte no los sustituye. Si se sospecha de una inyección de prompts (prompt injection), una fuga de datos o acciones no permitidas por parte de las herramientas, se debe involucrar tempranamente al equipo de seguridad correspondiente. El artículo sobre protección contra prompt injection en chatbots web aborda las capas de protección técnica adecuadas.

El postmortem y las simulaciones cierran el ciclo

Tras la recuperación, un postmortem sin culpa (blameless postmortem) documenta el impacto, la cronología, la detección, la mitigación, los factores contribuyentes y las medidas de seguimiento concretas. Google SRE recomienda definir los criterios para realizar un postmortem antes de que ocurra la incidencia; por ejemplo, una degradación visible para el usuario, pérdida de datos, un rollback manual o el fallo de la monitorización. El enfoque se centra en los sistemas y las decisiones, no en señalar culpables.

Cada medida requiere responsables, un plazo y un resultado verificable. Las mejoras habituales incluyen una nueva alarma, permisos más restrictivos para las herramientas, un caso adicional en el conjunto de referencia, una plantilla de estado mejorada o un aviso fuera de línea probado. Igual de importantes son las simulaciones breves: simule un tiempo de espera agotado del proveedor, una base de conocimiento inaccesible y una configuración regional defectuosa. Compruebe si las responsabilidades, el modo degradado, la comunicación y la verificación de recuperación funcionan en la práctica.

Lista de comprobación para la preparación ante incidentes

• Las señales de incidentes técnicas y funcionales están definidas de forma separada.
• Los niveles de gravedad cuentan con desencadenantes medibles y derechos de decisión claros.
• Existen fallbacks aislables para el modelo, la base de conocimiento, las herramientas, el enrutamiento y las configuraciones regionales.
• El chatbot nunca confirma una acción sin un resultado fiable.
• El modo degradado y el aviso fuera de línea se han probado en ordenadores de escritorio, dispositivos móviles y mediante navegación por teclado.
• El rollback abarca las configuraciones interrelacionadas y dispone de criterios de interrupción.
• Las vías de transferencia y comunicación están comprobadas y contienen solo datos de contacto verificados.
• La recuperación requiere métricas estables, una muestra de calidad y una puesta en marcha progresiva y controlada.
• Las medidas derivadas del postmortem cuentan con asignación de responsables, plazos y evaluación de eficacia.
• El equipo realiza simulaciones prácticas de varios dominios de error reales.

Fuentes

• NIST: SP 800-61 Revisión 3 sobre Respuesta a Incidentes
• NIST AI Risk Management Framework: Core
• Microsoft Well-Architected: Estrategia de respuesta ante emergencias
• Google SRE Workbook: Respuesta a incidentes
• Google SRE: Cultura postmortem

Estar preparado para incidentes no hace que un chatbot esté libre de errores. Permite que un equipo detecte las desviaciones a tiempo, limite las funciones de riesgo y guíe a los usuarios por una vía fiable. ChatReact puede utilizarse como parte de un proceso bien documentado de sitio web, conocimiento y transferencia a agentes; las responsabilidades, los límites y las vías de emergencia deben adaptarse a cada empresa.