DXC coloca agentes de IA na TI de bancos e hospitais: tempo de resolução de incidentes cai 95%

Quando um agente pode entrar no servidor de produção de um banco, a pergunta "qual modelo usar" passa para segundo plano. Incidentes públicos em que agentes autônomos executaram ações destrutivas que ninguém havia pedido mostram que o problema raramente está no modelo em si. Ele está num agente com mais permissões do que a tarefa exige e numa arquitetura que não o detém. A prestadora de serviços DXC Technology (115 mil funcionários em 70 países, com clientes entre bancos, hospitais e órgãos governamentais) contou no blog da AWS como construiu esse limitador para sua plataforma DXC OASIS.

Duas camadas: substrato e estrutura de controle

A ideia é simples: a pergunta "qual modelo" fica separada da pergunta "como o trabalho é feito". A camada inferior a DXC chama de substrato (substrate). É o Amazon Bedrock: uma API única para Claude, Amazon Nova, Meta Llama e famílias open-weight. Sobre ele ficam os Bedrock Guardrails, com filtragem de conteúdo, remoção de dados pessoais e temas proibidos, iguais para todos os modelos. O tráfego de inferência passa pelo PrivateLink dentro da VPC do cliente, e o modelo serverless elimina a frota própria de GPUs como ponto de falha.

A camada superior é a "estrutura de controle" (harness) da própria DXC. A orquestração é construída sobre o LangGraph, de código aberto: um agente supervisor divide a tarefa e a distribui a agentes especializados. É na estrutura de controle que ficam o contexto operacional de 60 anos de runbooks e dados de ITSM, a verificação de políticas a cada requisição e o registro de ações.

Um detalhe importante é onde passa a fronteira. Os Guardrails filtram a entrada e a saída do modelo, mas não conseguem limitar o que o agente pode fazer com um servidor. Isso só a estrutura de controle consegue, porque depende do contexto e da responsabilidade de cada cliente.

Como fica num único incidente

No ambiente de demonstração de uma companhia aérea fictícia, o servidor FlightOps está ficando sem espaço e o runbook não ajuda. O CIO vê o alerta como risco de negócio, enquanto o engenheiro Linux recebe os mesmos dados com detalhes técnicos. O supervisor monta um plano e aciona os agentes Metrics, Linux System e ITSM. O primeiro confirma que o disco está 99% cheio e cita artigos da base de conhecimento; o segundo encontra um arquivo temporário de 5 GB.

Em seguida vem o ponto-chave: o agente mostra o plano completo e nada é executado até que o engenheiro confirme. Ele pode diagnosticar livremente, mas só altera a produção com aprovação registrada. O registro (o que foi executado, onde, quem aprovou e quando) é gerado pela estrutura de controle, e não por um relato do próprio agente.

As atribuições são organizadas em quatro degraus: observar, sugerir, agir com aprovação e agir dentro de um escopo definido. Cada persona começa em read-only, e a ampliação de permissões é uma decisão consciente, um degrau por vez.

Os números e o que fazer com eles

Desde a disponibilidade geral (GA) em março de 2026, o OASIS atende 12 personas operacionais (Linux, Windows, SAP, redes, backups, AWS, Azure e outras). Segundo a DXC, o tempo médio de resolução caiu 95% em 56 cenários medidos. Um incidente de sistema de arquivos que levava de 53 a 90 minutos agora leva de 3 a 6. Problemas de banco de dados: de 2–3 horas para 5–12 minutos. Problem management complexo: de 2–6 dias para 8–10 minutos. A precisão do diagnóstico é de 92% ou mais em relação à avaliação de engenheiros seniores.

É preciso tratar esses números com cautela. Trata-se de um post conjunto da AWS e do fornecedor, sem verificação independente, a metodologia de medição "antes/depois" não foi divulgada, e 92% de precisão significa que, em um a cada doze casos, o diagnóstico pode estar errado. Por isso a aprovação humana aqui não é mera formalidade.

Conclusão prática para quem constrói agentes para produção:

• Mantenha a escolha do modelo, a orquestração e o ambiente de implantação como decisões independentes. Assim, uma falha do provedor ou a descontinuação de um modelo se resolve com um ajuste de roteamento. Mas API igual não significa comportamento igual: antes de colocar um novo modelo no roteamento, rode-o em seus próprios conjuntos de tarefas.
• Não confie que o modelo limite a si mesmo. Permissões, degraus de autonomia e auditoria devem ficar fora do modelo, em código e políticas.
• Comece com read-only e amplie a autonomia por tarefa, e não por padrão.
• Considere a dependência: todo o esquema se apoia no Bedrock, e o conjunto de modelos disponíveis depende da região da AWS.

A principal lição não é sobre um serviço de nuvem específico. A segurança de um agente é definida pelo que ele tem permissão de fazer, e não pela inteligência do modelo. Enquanto essa fronteira não for traçada de forma explícita, é cedo para escalar agentes para sistemas em produção.