Diseña el estado de caída de la IA: nombra la falla, muestra lo que sigue funcionando y da a los usuarios un siguiente paso

Cuando un asistente deja de funcionar, lo más costoso que puede hacer un producto es fingir que todo está bien. Una caída no es solo un incidente de backend; es un momento en el que la interfaz gana confianza o la gasta. Los usuarios no necesitan un misterio. Necesitan un contrato de servicio degradado: qué está roto, qué sigue funcionando, qué pueden hacer ahora y qué esperar a continuación.

Una caída así parece un evento típico de confiabilidad, pero los detalles visibles para el usuario la convierten en un evento de diseño. ChatGPT, Claude, Gemini y Grok experimentaron una interrupción del servicio que afectó a usuarios. Un rastreador de caídas reportó problemas en cuatro chatbots populares. La página de estado de OpenAI reportó errores graves en ChatGPT y Codex, y OpenAI dijo que se habían aplicado medidas correctivas y que la recuperación estaba siendo monitoreada. Sin embargo, ninguna empresa había detallado la razón técnica exacta de los errores.

El detalle más dañino no fue el error en sí. Fue la discrepancia entre la confianza del producto y su capacidad. Claude a veces negaba tener problemas mientras no podía cargar más respuestas ni buscar en la web. Ese es el patrón que los diseñadores deberían temer: un sistema que suena normal mientras su comportamiento no lo es. En productos de IA, el modelo puede ser la interfaz. Si el modelo está degradado, la interfaz también está degradada, aunque la pantalla siga viéndose pulida.

Por qué los estados de caída son un problema de confianza

Las fallas tradicionales de software suelen ser visibles: un spinner, un tiempo de espera agotado, un botón roto. Los productos de IA añaden una segunda capa de incertidumbre porque el usuario está hablando con algo que puede explicarse a sí mismo. Eso hace que la comunicación del estado sea más difícil, no más fácil. Un chatbot puede decir «todo funciona» mientras no puede recuperar contexto, llamar a una herramienta ni continuar una conversación. El usuario tiene que decidir si confía en las palabras o en el comportamiento. El producto no debería forzar esa elección.

La confianza no se construye ocultando la falla. Se construye haciendo que la falla sea legible. Cuando un servicio está degradado, los usuarios necesitan saber si su trabajo está a salvo, si su entrada fue procesada, si deben reintentar y si el producto sigue siendo útil para algo. Si la respuesta no es clara, los usuarios no solo pierden una función; pierden la confianza en el juicio del producto.

Lista de verificación de confianza para el servicio degradado

Usa esta lista de verificación cada vez que una función de IA esté parcialmente caída, con límite de tasa o comportándose fuera de su contrato normal. El objetivo no es sonar calmado. El objetivo es ser lo suficientemente preciso para que los usuarios puedan actuar.

1. Reconoce la caída de forma clara. Di que el servicio está degradado si el usuario no puede completar la tarea. Un lenguaje claro reduce la ansiedad y evita que los usuarios se culpen a sí mismos.
2. Enumera las capacidades afectadas. Nombra lo que está roto: generación, búsqueda, carga de archivos, memoria, uso de herramientas, contexto largo o un flujo de trabajo específico. Un lenguaje vago hace que los usuarios prueben el producto y descubran la falla por sí mismos.
3. Enumera las capacidades no afectadas. Si el historial, la configuración, los proyectos guardados o las respuestas básicas siguen funcionando, dilo. Esto convierte un callejón sin salida en un estado utilizable.
4. Ofrece la mejor acción para el usuario. Dile a los usuarios qué hacer ahora: esperar, reintentar más tarde, cambiar a una función soportada, exportar el trabajo o contactar con soporte. La acción debe coincidir con la ruta de recuperación real.
5. Indica la expectativa de recuperación o el estado de monitoreo. Si sabes cuándo debería volver el servicio, dilo. Si no, di que la recuperación está siendo monitoreada y dónde revisar las actualizaciones.
6. Evita afirmar que todo opera con normalidad cuando el comportamiento está degradado. Si el sistema no puede completar una tarea, no dejes que el modelo describa la experiencia como normal. La confianza sin capacidad es la forma más rápida de erosionar la confianza.

Rediseño del estado de caída

Un buen estado de caída no es una cara triste con un botón de reintento. Es una pequeña superficie del producto con tres funciones: explicar, preservar y dirigir. La explicación debe aparecer donde el usuario está trabajando, no solo en una página de estado. La preservación debe proteger el trabajo del usuario: mantener la conversación, mostrar lo que se envió y dejar claro si la solicitud fue procesada. La orientación debe dar un siguiente paso, no un menú de posibilidades.

En productos de chat, el mensaje de caída debe aparecer en la conversación misma. No debe estar oculto en un banner que el usuario pueda descartar. Si el asistente no puede continuar, la interfaz debe decirlo en el mismo lugar donde el usuario esperaba una respuesta. En productos de agentes, el estado debe mostrar qué paso falló, qué herramientas no están disponibles y si el agente puede reanudar de forma segura. En productos de asistentes, el estado debe distinguir entre no poder responder a una solicitud en particular y no poder responder a nada.

La página de estado importa, pero no es todo el trabajo. Una página de estado es para operadores, desarrolladores y personas que ya saben que están buscando un incidente. El usuario dentro del producto necesita la misma información en el momento de la falla. Eso significa que el estado de caída debe diseñarse como parte del producto, no añadido después de que comienza el incidente.

Cuando la confiabilidad no es perfecta, el trabajo del producto es hacer que la imperfección sea comprensible. Un contrato de servicio degradado claro no hace que la caída sea menos molesta. Hace que el producto sea más confiable. Los usuarios pueden perdonar una falla cuando saben qué pasó, qué sigue funcionando y qué hacer a continuación. No pueden perdonar un producto que sigue sonriendo mientras se rompe.