DXC lleva agentes de IA a los sistemas de TI de bancos y hospitales: el tiempo de resolución de incidentes cae un 95%

Cuando un agente puede acceder al servidor de producción de un banco, la pregunta de qué modelo elegir pasa a un segundo plano. Los incidentes públicos en los que agentes autónomos realizaron acciones destructivas que nadie había solicitado muestran que el problema rara vez está en el propio modelo. Está en un agente con más permisos de los necesarios para su tarea y en una arquitectura que no lo detiene. El proveedor de servicios de TI DXC Technology, con 115.000 empleados en 70 países y clientes entre los que figuran bancos, hospitales y organismos públicos, explicó en el blog de AWS cómo construyó esos controles para su plataforma DXC OASIS.

Dos capas: sustrato y control

La idea es sencilla: separar la pregunta de qué modelo utilizar de la de cómo se realiza el trabajo. DXC llama sustrato (substrate) a la capa inferior. Es Amazon Bedrock: una única API para Claude, Amazon Nova, Meta Llama y familias de modelos de pesos abiertos. Por encima se sitúa Bedrock Guardrails, que aplica los mismos filtros de contenido, eliminación de datos personales y restricciones temáticas a todos los modelos. El tráfico de inferencia circula por PrivateLink dentro de la VPC del cliente, mientras que el enfoque serverless elimina una flota propia de GPU como punto de fallo.

La capa superior es el entorno de control (harness) desarrollado por DXC. La orquestación se basa en LangGraph, de código abierto: un agente supervisor divide la tarea y la asigna a agentes especializados. Esta capa también contiene el contexto operativo extraído de 60 años de procedimientos operativos y datos de ITSM, verifica las políticas en cada solicitud y mantiene un registro de acciones.

Un detalle importante es dónde se traza el límite. Guardrails filtra las entradas y salidas del modelo, pero no puede restringir lo que un agente está autorizado a hacer en un servidor. Solo la capa de control puede hacerlo, porque depende del contexto y las responsabilidades de cada cliente.

Cómo funciona ante un incidente concreto

En el entorno de demostración de una aerolínea ficticia, el servidor FlightOps se está quedando sin espacio y el procedimiento operativo no resuelve el problema. El CIO ve la alerta como un riesgo para el negocio, mientras que un ingeniero de Linux recibe los mismos datos con los detalles técnicos. El supervisor elabora un plan y activa los agentes Metrics, Linux System e ITSM. El primero confirma que el disco está lleno al 99% y remite a artículos de la base de conocimientos; el segundo encuentra un único archivo temporal de 5 GB.

Entonces llega el paso clave: el agente muestra el plan completo y no se ejecuta nada hasta que el ingeniero lo aprueba. Puede diagnosticar libremente, pero modificar el entorno de producción exige una aprobación registrada. La capa de control genera el registro —qué se ejecutó, dónde, quién lo aprobó y cuándo— en lugar de depender del relato del propio agente.

Los permisos se organizan en cuatro etapas: observar, proponer, actuar con aprobación y actuar dentro de un alcance definido. Cada perfil operativo empieza en modo de solo lectura, y la ampliación de permisos es una decisión deliberada que se toma de una etapa en una.

Las cifras y cómo interpretarlas

Desde su lanzamiento en disponibilidad general en marzo de 2026, OASIS admite 12 perfiles operativos que abarcan Linux, Windows, SAP, redes, copias de seguridad, AWS, Azure y otras áreas. Según DXC, el tiempo medio de resolución cayó un 95% en 56 escenarios medidos. Un incidente del sistema de archivos que antes requería 53–90 minutos ahora se resuelve en 3–6 minutos. Los problemas de bases de datos pasaron de 2–3 horas a 5–12 minutos. La gestión de problemas complejos pasó de 2–6 días a 8–10 minutos. La precisión del diagnóstico es del 92% o superior, tomando como referencia las evaluaciones de ingenieros sénior.

Conviene tratar estas cifras con cautela. Se trata de una publicación conjunta de AWS y el proveedor, sin verificación independiente. No se ha divulgado la metodología de las mediciones de antes y después, y una precisión del 92% significa que el diagnóstico podría ser incorrecto en aproximadamente uno de cada doce casos. Por eso, la aprobación humana aquí es más que una formalidad.

Conclusiones prácticas para quienes desarrollan agentes para producción:

• Mantengan la elección del modelo, la orquestación y el entorno de despliegue como decisiones independientes. Así, una caída del proveedor o la retirada de un servicio se resuelven con un cambio de enrutamiento. Pero una API común no implica un comportamiento idéntico: antes de incorporar un modelo nuevo al enrutamiento, evalúenlo con sus propias baterías de tareas.
• No confíen en que el modelo se limite a sí mismo. Los permisos, los niveles de autonomía y la auditoría deben residir fuera del modelo, en el código y las políticas.
• Empiecen con acceso de solo lectura y amplíen la autonomía por tarea, no por defecto.
• Tengan en cuenta la dependencia de la plataforma: toda la arquitectura se apoya en Bedrock y los modelos disponibles varían según la región de AWS.

La principal lección no gira en torno a un servicio en la nube concreto. La seguridad de un agente depende de lo que tiene permitido hacer, no de lo inteligente que sea el modelo. Hasta que ese límite quede definido de forma explícita, es pronto para desplegar agentes a escala en sistemas de producción.