Triaje de incidentes con IA: Circle K bajó de 60 a menos de 15 minutos con Amazon Bedrock

Cuando suena una alerta a las tres de la madrugada, el problema no suele ser arreglar la avería, sino entender qué pasó. En Circle K, ese paso previo consumía entre 45 y 60 minutos por incidente. Hoy el triaje de incidentes con IA que construyó su equipo de DevOps sobre Amazon Bedrock lo ha dejado en menos de 15 minutos, una reducción del 67-75 % según las métricas internas de respuesta a incidentes de la compañía.

La escala explica la urgencia. Circle K opera más de 17.200 tiendas de conveniencia y combustible en 27 países, y detrás hay una infraestructura nativa en la nube en AWS que sostiene sistemas de punto de venta, aplicaciones de fidelización y cargadores de vehículos eléctricos. Más servicios significaban más alertas, y cada una exigía la misma investigación manual: revisar logs en Amazon CloudWatch, consultar trazas en Amazon OpenSearch Service, comprobar el estado de las tareas en Amazon ECS y cruzar los síntomas con los runbooks en GitHub. Además, la calidad del diagnóstico dependía de lo bien que el ingeniero de guardia conociera el servicio afectado. Así que el equipo lanzó una iniciativa de I+D para automatizar la recopilación de contexto, sin quitarle el criterio operativo a las personas.

Cómo funciona el triaje de incidentes con IA en Circle K

La primera versión se montó con Amazon Bedrock Flows como capa de orquestación. El recorrido es este: una alerta de Grafana se publica en Amazon SNS, pasa a una cola SQS y una función Lambda extrae la carga y lanza el flujo. Dentro, dos agentes de IA trabajan en paralelo:

AWSResourceExplorerAgent: consulta varias cuentas de AWS Organizations y revisa el estado de las tareas de ECS, la salud de los destinos del balanceador y las métricas y logs de CloudWatch.

OpenSearchExplorerAgent: busca logs de aplicación y trazas distribuidas. Va aislado porque OpenSearch devuelve grandes volúmenes de datos, y así la ventana de contexto de cada agente se mantiene manejable. Además es el único con acceso a la base de conocimiento, con fichas de cada servicio y sus dependencias.

Cuando ambos terminan, entra un tercer agente, GitHubExplorerAgent. Con lo que encontraron los anteriores, localiza los repositorios del servicio afectado, revisa código, infraestructura como código y commits recientes, y propone una corrección concreta. Ejecutarlo después evita búsquedas amplias y poco útiles. Por último, un nodo de análisis, una sola llamada al modelo sin herramientas, consolida todo en un resumen estructurado: causa probable, evidencias, servicio y responsable afectados, y pasos de remediación. Llega a Slack en 5 a 15 minutos, en un formato que el equipo de guardia puede leer en menos de dos minutos.

Según los resúmenes de terceros que recogen el caso, el sistema migró después a un único agente sobre Amazon Bedrock AgentCore Runtime, y el artículo original dedica una sección a esa transición y a las lecciones de escalarlo.

Por qué Bedrock y no un framework propio

El equipo evaluó frameworks de agentes de código abierto en infraestructura propia, pero eso implicaba hacerse cargo del alojamiento del modelo, el versionado de prompts, la orquestación de herramientas y los controles de seguridad. Con Bedrock accedieron a varios modelos mediante una sola API, podían cambiar de modelo sin reescribir código y se integraron con las políticas de IAM, las configuraciones de VPC y los registros que ya tenían. Las Knowledge Bases les ahorraron operar una base vectorial aparte. Y como Bedrock no comparte los datos de clientes con los proveedores de modelos ni los usa para entrenarlos, cumplía los requisitos de seguridad para trabajar con logs de producción.

Qué puedes aplicar en tu empresa

Un matiz importante antes de copiar la receta: las cifras son métricas internas de Circle K, no una auditoría independiente. Aun así, el patrón es replicable.

1. Cuantifica el coste del contexto. Mide cuánto tiempo pasa tu equipo reuniendo información antes de actuar. Ahí está el retorno más claro.
2. Automatiza la investigación, no la decisión. Circle K entrega un resumen con evidencias y deja la acción a los ingenieros. Es el mismo principio que aplica Rescale en su agente de triaje con IA, que pasó del problema a staging en cinco días.
3. Divide por fuente de datos. Aislar el agente que maneja más volumen protege la ventana de contexto y facilita el mantenimiento.
4. Encadena según dependencias. Lo que puede ir en paralelo, en paralelo; lo que necesita contexto previo, después.
5. Documenta tus servicios. Las fichas de producto en la base de conocimiento son las que convierten un resultado genérico en un diagnóstico útil.
6. Aplica mínimo privilegio y audita. Los agentes necesitan lectura sobre logs, índices y APIs; define permisos estrictos y revisa qué datos sensibles llegan al modelo.

El caso se parece a lo que logró Cornerstone al bajar de 45 a 10 minutos el diagnóstico de bases de datos con IA. Y quien quiera ver hasta dónde llega la observabilidad con IA puede mirar cómo Netflix convierte 38 millones de eventos por segundo en diagnósticos automáticos.

¿Cuándo conviene dar el paso?

El momento llega cuando el volumen de alertas crece más rápido que el equipo, cuando el tiempo de diagnóstico depende de quién esté de guardia o cuando ya tienes runbooks y datos de observabilidad razonablemente ordenados. Si trabajas ya en AWS, la barrera de entrada baja, porque seguridad, red y registros se reutilizan. Empieza por un tipo de incidente frecuente, mide el tiempo medio de triaje antes y después, y amplía solo si los números aguantan.

La lección de Circle K es que el triaje de incidentes con IA no sustituye a tu equipo de guardia: le devuelve la primera hora de cada incidente. ¿Cuánto vale esa hora en tu organización, y cuántas alertas más podrías atender si no tuvieras que gastarla?