Toda vez que falo de IA com alguém da área, a pergunta aparece em algum momento: “e aí, daqui a pouco o agente faz o meu trabalho, né?”.
Eu entendo a ansiedade. Os fornecedores falam em “TI autônoma”, os analistas publicam previsões com prazo e porcentagem, e quem vive de analisar incidentes, aprovar mudanças ou manter o CMDB fica pensando se está do lado certo da história.
Mas acho que a pergunta está mal formulada. “Vou ser substituído?” trata o trabalho como um bloco único, que fica ou vai embora. Na prática, o trabalho é um conjunto de verbos: coletar, classificar, investigar, decidir, aprovar, comunicar, auditar.
A IA não substitui o bloco. Ela muda os verbos.
Nenhuma prática de ITSM morre com a IA, mas cada uma muda de verbo: o profissional deixa de executar e passa a definir, supervisionar e auditar. Este guia percorre práticas comuns de ITSM e mostra, em cada uma, o que muda, o que continua humano e por onde começar.
O que a IA já entrega e o que ainda é promessa?
Antes de adaptar qualquer prática, vale separar evidência de discurso.
O Gartner prevê que mais de 40% dos projetos de IA agêntica serão cancelados até o fim de 2027, por custo, risco ou retorno que não aparece. No mesmo estudo, estima que apenas cerca de 130 dos milhares de fornecedores que se dizem “agênticos” entregam de fato algo agêntico. O resto é agent washing: o chatbot de sempre com um nome novo.
Ao mesmo tempo, o mesmo Gartner projeta que 70% das empresas usarão agentes de IA para operar infraestrutura até 2029, contra menos de 5% em 2025.
As duas previsões não se contradizem. A direção é clara, mas o caminho vai ser cheio de projetos abandonados no meio. Na minha leitura, quem adapta as práticas agora deve começar pelo que já tem dado e está otimizado (lembre-se do princípio "otimizar e automatizar" - nessa ordem!), e deixar a autonomia total para quando houver evidência (e governança) para sustentá-la.
Ao longo do texto, uso números de fornecedores em vários pontos. Eles são úteis para dar ordem de grandeza, mas são números de quem vende a solução. Trate como teto, não como expectativa.
Gestão de eventos: do operador de painel ao dono do sinal
Esta é a prática mais madura para começar, e não é por acaso. Correlacionar alertas, agrupar duplicados e separar ruído de sinal é exatamente o tipo de trabalho repetitivo, volumoso e baseado em padrão que a IA faz bem.
O Hype Cycle de IA em ITSM do Gartner de 2026 coloca a correlação e redução de ruído de eventos entre as tecnologias para acelerar nos próximos dois anos. O ponto de partida costuma ser feio: a BigPanda relata que, na base dela, só 18% dos incidentes gerados por alertas eram de fato acionáveis.
O que muda para quem trabalha com gestão de eventos? O operador que olhava painéis e deduplicava alertas na mão vira o dono do sinal. O trabalho passa a ser definir o que merece alertar (sintomas para o usuário, não cada CPU que encosta em 80%) e manter o mapa de quem é dono de cada serviço, para que o roteamento automático funcione.
E surge um trabalho novo, que pouca gente está fazendo: auditar o que a IA descartou. Se o agente suprimiu um alerta, alguém precisa conseguir responder, depois, por que ele foi suprimido. Em ambiente regulado, essa pergunta vai ser feita (geralmente no pior momento possível, que é depois do incidente).
Gestão de incidentes: o agente investiga, você decide
Aqui a mudança já está acontecendo, e com produto em prateleira. Datadog, AWS, Microsoft e PagerDuty lançaram agentes que começam a investigar o incidente no momento do alerta: cruzam logs, métricas, mudanças recentes e runbooks, testam hipóteses e entregam uma causa provável com evidências.
Quando o plantonista abre o notebook, a primeira meia hora de garimpo já foi feita.
Os casos públicos de bancos brasileiros vão na mesma direção. O Itaú relata, em estudo de caso publicado pela Datadog, queda de 40% na taxa de incidentes e de 35% no tempo de resolução após modernizar a observabilidade com uso de IA. O Bradesco usa a BIA Tech, ferramenta interna, para apoiar a análise de incidentes, e relata redução de 23% no tempo dessa análise. O executivo do banco faz questão de dizer que sempre há um humano verificando o que foi feito.
Esse detalhe é o que importa.
O agente coleta, correlaciona, sugere e até executa runbooks pré-aprovados (um restart, um rollback, um failover). Mas a decisão de mitigar em produção, a comunicação com o negócio e a classificação de um incidente grave para fins regulatórios continuam com uma pessoa. Não por romantismo, mas porque alguém precisa responder por elas.
Então, o que eu faria para adaptar a prática?
Primeiro, reescrever os runbooks pensando em quem vai lê-los. Um runbook que dependia do “bom senso do plantonista” não serve para um agente. Passos atômicos, pré-condições explícitas e uma linha clara sobre o que o agente pode executar sozinho e o que precisa de aprovação.
Segundo, criar desde já uma categoria para incidentes causados por agentes. O Gartner projeta que ações agênticas em ITSM causarão mais de 2.000 incidentes por organização média em 2028. Se você não separar esses casos agora, não vai ter dados para saber se a autonomia que concedeu está valendo a pena.
Gestão de problemas: o guardião da verdade causal
Confesso que esta é a prática que mais me interessa. E é a que, na minha opinião, ganha importância com a IA, em vez de perder.
A IA é excelente em encontrar padrões. Agrupar incidentes parecidos, detectar recorrência, abrir um problema candidato com as evidências já anexadas: tudo isso já funciona, e libera o analista de horas de garimpo em base de tickets.
O problema começa quando a gente pede à IA que explique a causa.
O RCACopilot, sistema de análise de causa raiz que a Microsoft testou com 653 incidentes reais, teve desempenho bom nas categorias frequentes e bem pior na cauda longa. Em números: micro-F1 de 0,766, que pondera pelos casos mais comuns, e macro-F1 de 0,533, que dá peso igual a cada categoria.
Traduzindo: a IA acerta o problema que você já viu cem vezes e erra o raro. E o raro é justamente o problema caro, o que derruba o sistema em dia de pico e vira pauta de comitê.
Pior do que errar é errar de forma convincente. Um modelo de linguagem produz uma narrativa causal coerente, bem escrita, com evidências citadas. Ela pode estar completamente errada e, ainda assim, parecer melhor do que o RCA que o time escreveria às pressas e sob pressão.
O novo trabalho do analista de problemas passa a ser contestar a explicação plausível. Checar se a causa proposta é fiel às evidências, e não apenas consistente com elas. Fazer a pergunta que o modelo não faz: “e se não for isso?”.
Isso pede duas adaptações práticas.
A primeira é cuidar da taxonomia de causas. Os modelos aprendem com os rótulos que a gente coloca nos registros. Taxonomia confusa, com metade dos problemas classificados como “outros”, gera IA confusa. A curadoria da classificação de falhas deixa de ser burocracia e vira insumo de qualidade para os modelos.
A segunda é ampliar a própria taxonomia. Quando agentes passam a agir sobre o ambiente, surgem causas raiz que não existiam: um prompt mal escrito, uma permissão excessiva, um artigo de conhecimento desatualizado consumido pelo agente. Se a sua taxonomia não tem onde colocar isso, você vai classificar como “erro humano” algo que não foi.
Gestão de conhecimento: de autor a curador
Pela previsão do Gartner no Magic Quadrant de IA em ITSM, até 2027 a IA generativa vai criar mais artigos de suporte e de base de conhecimento do que os humanos.
À primeira vista, é uma ótima notícia. Quem já tentou convencer um time a documentar a solução depois de fechar o ticket sabe o quanto essa batalha é perdida.
Mas existe uma mudança mais profunda escondida aí. O artigo de conhecimento deixa de ser lido por pessoas e passa a ser consumido por agentes. O agente lê o artigo, interpreta e age.
Se o modelo é a turbina, a base de conhecimento é o querosene.
O próprio KCS acompanhou essa virada. Em abril de 2026, o Consortium for Service Innovation renomeou a metodologia de Knowledge-Centered Service para Knowledge-Centered Success, com um argumento simples: sistemas de IA são tão bons quanto o conhecimento que usam.
Na prática, o analista sai do papel de autor e entra no de curador. A IA redige o rascunho a partir do ticket, do chat da sala de crise e do postmortem. O humano valida, aprova, aposenta o que ficou obsoleto e, principalmente, decide para que cada artigo pode ser usado.
Essa é a adaptação que eu mais recomendaria: classificar o conteúdo pelo nível de autonomia que ele permite. Um artigo pode ser só informativo, pode servir para o agente sugerir uma solução ou pode autorizar o agente a executar. Um workaround que vai ser executado automaticamente precisa de um rigor que um artigo de consulta nunca precisou.
Gestão de mudanças: o CAB vira comitê de exceções
Aqui a IA entra por dois lados, e os dois exigem atenção.
O primeiro lado é o da avaliação de risco. Em vez de uma matriz estática, um modelo calcula o risco da mudança com base no histórico daquele item, nas dependências, no estado atual do ambiente e na taxa real de falha de mudanças parecidas. Mudanças de baixo risco passam a ser pré-aprovadas por política, e o CAB deixa de ser um rito semanal universal para virar um comitê de exceções.
O segundo lado é o mais delicado: a IA está gerando mais mudanças, mais rápido. O relatório DORA 2025, do Google, mostra 90% de adoção de IA no desenvolvimento de software, 30% dos profissionais com pouca ou nenhuma confiança no código gerado e uma associação persistente entre adoção de IA e instabilidade nas entregas.
Ou seja: a mesma tecnologia que ajuda a avaliar o risco das mudanças está aumentando o volume e o risco das mudanças.
E existe um terceiro elemento, que muda o desenho da prática: o agente como solicitante. Quando um agente de SRE identifica que precisa aumentar a capacidade de um cluster ou aplicar um patch, ele está abrindo uma mudança. Quem aprova?
Adaptar a prática passa por responder a essa pergunta antes que ela apareça em produção. Que classes de mudança um agente pode propor? Quais pode executar sozinho? E a regra de ouro da segregação de funções precisa valer para máquinas também: o agente que propõe não pode ser o mesmo que aprova.
Por fim, o modelo de risco precisa ser auditado como qualquer outro modelo. Cada mudança classificada como de baixo risco que virou incidente é um falso negativo, e alguém precisa olhar para isso com a mesma seriedade com que um banco valida um modelo de crédito.
CMDB: mais importante do que nunca, e não menos
Existe uma tese circulando de que a IA vai tornar o CMDB obsoleto. A topologia seria inferida da telemetria, em tempo real, e o repositório de configuração viraria peça de museu.
Eu acreditava nessa tese, mas agora estou mais propenso a achar o contrário.
Agentes agem com base no que acreditam ser verdade sobre o ambiente. Se o CMDB diz que um servidor pertence a um serviço que ele não suporta mais, o agente vai investigar o lugar errado, sugerir a mitigação errada ou aprovar a mudança errada. E vai fazer isso com toda a confiança.
O Gartner é cauteloso sobre o CMDB “aumentado” por IA: no Hype Cycle de 2026, a tecnologia aparece com penetração inferior a 1% e evidência limitada de ganho consistente de acurácia. E o mesmo relatório aponta a causa raiz de forma bem direta: muitas organizações não definem o que significa “correto”. Sem essa definição, nem o CMDB nem a IA conseguem detectar um desvio relevante.
Esse é o primeiro passo de adaptação, e não envolve tecnologia nenhuma: definir o estado correto, pelo menos para os serviços críticos. Depois disso, sim, a IA ajuda muito a reconciliar fontes (descoberta, nuvem, infraestrutura como código, observabilidade) e a propor correções.
E há um item novo a registrar: os próprios agentes. Cada agente em produção deveria existir como item de configuração, com dono, versão do modelo, ferramentas que acessa e permissões que tem. Sem esse inventário, não há como auditar nada.
Nível de serviço e XLA: medir também o agente
A migração de SLA para XLA já estava em curso antes da IA, e o ITIL Version 5 reforçou essa direção com um módulo dedicado à experiência. A maturidade, porém, ainda é baixa: segundo a Forrester, só 20% das organizações têm um time dedicado à experiência digital do colaborador.
A IA acrescenta uma camada que pouca gente está considerando: os agentes também precisam de níveis de serviço.
Taxa de resolução autônoma, taxa de erro, ações revertidas, custo por resolução, tempo até escalonar para um humano. Se o agente virou o primeiro nível de atendimento, ele precisa ser medido como qualquer prestador de serviço.
E aqui vai um alerta importante: deflexão não é resolução. Um usuário que desistiu de falar com o bot e abriu um chamado por telefone conta como deflexão em muitos relatórios. Separe as duas métricas desde o primeiro dia, ou você vai comemorar números que não existem.
SRE: o toil não sumiu, mudou de lugar
A promessa era que a IA acabaria com o toil, o trabalho manual, repetitivo e sem valor duradouro que consome os times de SRE. Os dados contam outra história.
O relatório de SRE da Catchpoint registrou em 2025 a primeira alta de toil em cinco anos. Na edição de 2026, 49% dos profissionais dizem que a IA reduziu o toil, mas 16% dizem que aumentou, com gestores bem mais otimistas do que os engenheiros que fazem o trabalho.
Faz sentido. Supervisionar um sistema que acerta 80% das vezes é trabalho. Revisar a saída do agente, ajustar o runbook que ele interpretou mal e investigar por que ele travou num loop: tudo isso é toil novo, só que com outra cara.
E não há nada de errado nisso. É o custo de transição de qualquer automação séria. O erro é não medir.
Uma ideia que me parece promissora para adaptar a prática é estender a lógica do error budget aos agentes. Algo como um orçamento de autonomia: o agente ganha mais permissões enquanto cumpre seu nível de serviço, e perde automaticamente quando ultrapassa o limite de ações erradas no período.
Outra adaptação, menos óbvia, é proteger a competência humana. O Gartner prevê que 50% das organizações vão exigir avaliações de habilidades “sem IA” por causa da atrofia do pensamento crítico. Se o agente cair no meio de um incidente grave, o time precisa saber operar sem ele. Game days sem IA deveriam entrar no calendário.
A prática que ainda não tem nome: governar os agentes
Se eu tivesse que apostar em uma única mudança com alta probabilidade, seria esta: o surgimento de uma prática nova, transversal a todas as outras, dedicada a governar a frota de agentes.
Os sinais de que ela é necessária já estão aí. Uma pesquisa da Agen.co com a Frontegg, feita com 300 CISOs, mostrou que 78% das empresas já precisaram retirar permissões de um agente que estava em produção. E 40% veem agentes rodando com credenciais pessoais de funcionários. Na trilha de auditoria, aparece a pessoa fazendo o que o agente fez.
O caso mais famoso é o do agente da Replit que, em 2025, apagou um banco de dados de produção durante um congelamento de código e ainda informou, falsamente, que o rollback era impossível. Acesso de escrita em produção, nenhuma separação de ambientes, nenhuma aprovação humana para ação destrutiva. Nada que uma prática madura de mudanças e acessos não teria barrado.
Essa prática nova junta pedaços que hoje estão espalhados: inventário de agentes, identidade e privilégio mínimo, segregação de funções, avaliação antes de entrar em produção, gestão de mudanças de prompts e modelos, tratamento de incidentes causados por agentes e um botão de desligar que funcione.
O Banco do Brasil, por exemplo, publicou diretrizes para IA generativa e agêntica que preveem mecanismos de interrupção de agentes e autonomia concedida em fases, sob supervisão humana.
No Brasil, o Banco Central já sinalizou que não pretende editar uma norma específica de IA antes do fim de 2026. Mas isso não significa um vazio regulatório. As regras de segurança cibernética, gestão de riscos e qualidade de dados que já existem se aplicam aos agentes, porque um agente que lê dados e age sobre sistemas é, antes de qualquer coisa, um sistema de TI. O ITIL Version 5, aliás, já traz um módulo inteiro dedicado à governança de IA.
Quem vem de ITSM tem uma vantagem enorme aqui. Inventário, controle de mudanças, gestão de acessos e tratamento de incidentes são o nosso feijão com arroz. A diferença é que agora o “usuário” é uma máquina.
Então seremos substituídos, afinal?
Volto à pergunta do começo.
Se o seu trabalho é só executar o processo (coletar evidência, preencher o formulário, deduplicar o alerta, redigir o artigo), parte dele vai, sim, para os agentes. Fingir que não seria desonesto.
Mas, olhando prática a prática, o que aparece não é um vazio. É uma mudança de verbo. O operador de eventos vira dono do sinal. O analista de incidentes vira quem decide e responde. O analista de problemas vira guardião da verdade causal. O gestor de conhecimento vira curador do combustível dos agentes. O gestor de mudanças vira dono da política de risco. E todos ganham uma responsabilidade nova: supervisionar e auditar máquinas que agem.
Não sei quanto tempo essa transição vai levar. Desconfio de quem diz que sabe. O que me parece certo é que quem começar a mudar os próprios verbos agora vai chegar do outro lado com mais relevância, não com menos.
E você? Em qual prática a IA já mudou o seu dia a dia, e em qual ela só mudou o discurso do fornecedor? Me conta nos comentários.
Se este guia foi útil, a newsletter do ITSM na Prática é onde eu compartilho esse tipo de reflexão e as novidades da área. É só se inscrever.