Como estruturar um projeto-piloto de IA no ITSM: uma abordagem baseada em casos de utilização com controlo rigoroso

Quase todas as grandes organizações iniciaram pelo menos um projeto-piloto de inteligência artificial destinado a ter impacto na gestão dos serviços de TI. Muitas interrompem-no após alguns meses, com resultados abaixo das expectativas, e atribuem o resultado negativo à tecnologia. Em grande parte dos casos, a causa encontra-se noutro lugar: na forma como o projeto foi estruturado desde o início.

As causas recorrentes são duas. A primeira é a ambição excessiva, que leva a começar com agentes de IA capazes de operar de forma autónoma, mesmo quando a organização ainda não dispõe da maturidade necessária para os governar. A segunda é a ausência de estrutura e de uma governação estável e partilhada: nenhum responsável designado, nenhuma métrica de sucesso acordada antes do arranque, nenhum critério para decidir se se deve continuar.

Este artigo propõe um método para construir um projeto-piloto de IA no ITSM que produza resultados verificáveis e permita recolher, desde as primeiras semanas, evidências úteis para construir e validar a justificação comercial.

Começar com casos de utilização de baixo risco

A escolha correta do caso de utilização determina em grande medida o sucesso do projeto-piloto. Um caso de baixo risco apresenta três características: os resultados são verificáveis por uma pessoa em poucos segundos, o erro produz consequências limitadas e reversíveis e o volume de pedidos tratados é suficiente para gerar dados significativos em poucas semanas.

Três atividades satisfazem estas condições.

Triagem de pedidos. O sistema propõe a categoria, a prioridade e a equipa de atribuição de cada pedido recebido. O colaborador vê a proposta e confirma-a ou modifica-a com um clique. Cada interação gera um dado útil sobre a percentagem de propostas corretas.

Resumo das ocorrências. Para incidentes com muitas anotações, o sistema produz um resumo do estado e das ações tomadas. É particularmente útil nas passagens de turno, onde reconstruir manualmente a cronologia de um incidente complexo consome minutos preciosos que poderiam ser dedicados à sua resolução.

Rascunhos para a base de conhecimento. Utilizando os pedidos resolvidos, o sistema gera uma primeira versão do artigo, que um editor revê e aprova. A criação de conteúdos para a base de conhecimento continua a ser uma das atividades mais sacrificadas pela pressão operacional, e uma contribuição neste sentido liberta tempo qualificado.

Estas três atividades partilham uma propriedade valiosa para um projeto-piloto de IA no ITSM: a análise humana já faz parte natural do fluxo. Por isso, o controlo não acrescenta passos artificiais. Os fluxos de trabalho completamente autónomos, pelo contrário, só podem ser ativados depois de o sistema ter demonstrado uma fiabilidade constante ao longo do tempo.

Definir as métricas antes do lançamento

Antes do arranque do projeto-piloto, é necessário definir para cada indicador escolhido três elementos: o valor de partida apurado com base nos dados históricos, o objetivo esperado no final do período de teste e a tradução dessa melhoria em termos compreensíveis para a gestão de topo e direção financeira. Fórmulas genéricas como ”maior eficiência operacional” ou ”melhor apoio de TI” não resistem sequer ao primeiro confronto com a direção financeira.

Deve ainda ser definido antecipadamente o critério de decisão: que resultado justifica a passagem à fase seguinte e qual, pelo contrário, sugere que se deve parar. Estabelecê-lo antes evita que a avaliação final se reduza a uma comparação de opiniões sobre o significado dos resultados obtidos.

Quantos indicadores e em que período?

Os indicadores efetivamente úteis são específicos: redução das ocorrências não significativas, tempo necessário para atribuir um pedido à equipa mais adequada, percentagem de atribuições corretas à primeira tentativa, tempo médio de resolução, qualidade da resposta aos incidentes de maior gravidade e perceção das equipas envolvidas.

Além disso, cada indicador deve ser associado a uma consequência concreta para a empresa, reconhecível também fora da área de TI. Por exemplo: o tempo de atribuição corresponde à espera percebida pelo utilizador; a qualidade dos rascunhos da base de conhecimento influencia a capacidade dos colaboradores do serviço de assistência de encerrar os pedidos sem envolver as equipas especializadas.

É preferível selecionar dois ou três indicadores, não mais. Cada métrica requer uma definição partilhada, uma medição inicial rigorosa e uma interpretação no final do teste. Um projeto-piloto de IA no ITSM que monitoriza seis indicadores reduz a atenção dedicada a cada um, porque distribui a atenção por demasiadas frentes.

Uma vez que os volumes variam consideravelmente ao longo do ano, a medição deve ser alargada a um período suficientemente amplo para incluir tanto os momentos de pico como os de menor carga.

Responsabilidade e governação

Um projeto-piloto de IA no ITSM sem um responsável designado fica bloqueado ao primeiro obstáculo. A responsabilidade deve ser atribuída nominalmente a uma pessoa que responda pelos resultados e tenha autoridade para decidir eventuais intervenções corretivas.

Além da responsabilidade, são necessários três instrumentos de trabalho. O primeiro é um mapa técnico que descreve as ferramentas de monitorização envolvidas, as fontes de dados utilizadas, as relações entre serviços extraídas da CMDB, os controlos de segurança aplicados, os limites estabelecidos para a introdução de automatização e os pontos de integração. O segundo é um registo de riscos dedicado, onde se anotam os riscos identificados, a sua prioridade e as ações a realizar. O terceiro é um modelo operacional que estabelece quem mantém os dados, quem verifica a qualidade das recomendações e com que frequência o sistema é revisto.

O mapa técnico, o registo de riscos e o modelo operacional funcionam apenas se a organização dispuser de regras partilhadas sobre a utilização da IA. Na ausência de uma governação definida, cada equipa adota as suas próprias ferramentas e convenções, com o resultado de multiplicar as divergências em vez de as reduzir.

Os controlos com intervenção humana

O controlo humano deve necessariamente ser previsto onde o risco é mais elevado, evitando aplicá-lo indistintamente a cada decisão. Três elementos devem ser definidos e documentados antes do arranque do projeto: que recomendações do sistema requerem a aprovação de um colaborador antes de serem implementadas, quem tem a responsabilidade de as aprovar e onde é registada essa aprovação.

Deve ainda ser definido o que acontece quando o sistema erra: quem deteta o erro, como se repõe a situação anterior e em quanto tempo. Definir este procedimento durante a fase experimental, quando as consequências permanecem contidas, evita ter de o improvisar em fase de produção.

Por que razão a taxa de aprovação pode enganar

Um aspeto a ter em conta é o esforço necessário para rejeitar uma proposta. Se a aprovação se obtém com uma única ação (um único clique), enquanto a correção obriga a preencher manualmente os campos, os colaboradores sob pressão tendem a confirmar mesmo as recomendações imprecisas.

Os dados sobre a qualidade das propostas acabam, assim, por refletir a carga de trabalho do serviço de assistência mais do que o desempenho do sistema: se a percentagem de propostas aprovadas for usada como indicador da precisão do sistema, e se aprovar requer uma ação rápida enquanto corrigir impõe um trabalho manual, essa percentagem subirá nos períodos de maior pressão sobre o serviço de assistência e descerá quando a carga diminuir. A solução consiste em tornar a correção tão rápida quanto a aprovação, por exemplo propondo alternativas selecionáveis em vez de um campo vazio.

Introduzir a autonomia de forma gradual

Num projeto-piloto de IA no ITSM, o alargamento da autonomia deve avançar por versões sucessivas, cada uma subordinada aos resultados da anterior.

V1 – Sugestões com análise humana

O sistema propõe e a pessoa responsável pela supervisão do processo decide. Cada proposta do agente de IA é comparada com a escolha efetiva do colaborador, e desta comparação obtém-se a taxa de concordância entre a proposta do sistema e a decisão do colaborador. A concordância, no entanto, não equivale automaticamente à precisão: uma amostra das decisões deve ser verificada separadamente para confirmar a sua correção.

V2 – Automatização dos casos de elevada fiabilidade

Uma vez identificadas as tipologias em que o sistema atinge de forma constante níveis de fiabilidade suficientemente elevados, a execução automática é ativada apenas nessas. Os restantes pedidos continuam a passar pela análise humana. O limite deve ser fixado separadamente para cada tipo de proposta: a atribuição de um pedido requer garantias diferentes relativamente à alteração de uma prioridade.

V3 – Autonomia alargada

O alargamento prossegue à medida que cresce a fiabilidade do sistema e, consequentemente, a confiança dos colaboradores. A monitorização dos resultados é contínua e existe sempre a possibilidade de reverter a automatização quando o desempenho se degrada.

Um percurso deste tipo retoma uma lógica de transição gradual da experimentação para a operação, em que a fase de observação precede a introdução num perímetro controlado e, só depois, a entrada nas operações do dia a dia.

Do projeto-piloto à demonstração do valor

A ligação entre experimentação e retorno económico (ROI) constrói-se durante o projeto. Por outras palavras, os dados que servem para demonstrar o valor do investimento devem ser recolhidos enquanto o projeto-piloto decorre. Os dados históricos recolhidos antes do arranque constituem a base de referência para avaliar os resultados. Os dados produzidos durante a fase V1 servem para verificar e calibrar o comportamento do sistema. E as melhorias registadas em V2 tornam-se a prova a apresentar para solicitar orçamento adicional para a extensão do projeto.

Os mesmos princípios surgem nas recomendações mais difundidas sobre a introdução da IA na gestão dos serviços: começar por casos de utilização de elevado valor, cuidar da qualidade dos dados, adotar as ferramentas adequadas, formar as pessoas, experimentar em pequena escala e crescer de forma gradual.

Um projeto-piloto de IA no ITSM estruturado desta forma mantém-se útil independentemente do resultado. Se o projeto funcionar, a organização disporá de dados verificáveis para justificar a sua extensão. Se o projeto não funcionar, com uma despesa contida, a organização saberá que lacunas colmatar antes de tentar novamente. A reflexão que os decisores empresariais devem fazer diz respeito ao grau de maturidade da sua organização, mais do que aos limites da tecnologia.

Perguntas frequentes

1. Quanto tempo deve durar um projeto-piloto de IA no ITSM?
   O tempo necessário para recolher um número suficiente de observações sobre o caso de utilização escolhido. Para atividades de elevado volume, como triagem de pedidos, bastam algumas semanas. Períodos mais curtos não permitem distinguir um resultado estável de uma variação ocasional.
   
2. Por que razão convém evitar agentes autónomos na fase inicial?
   Porque são necessários mecanismos de controlo, limites de fiabilidade e responsabilidades definidas que se constroem com a experiência. Começar com sugestões sujeitas a análise permite recolher os dados necessários para calibrar esses limites antes de alargar a autonomia.
   
3. Quem deve liderar o projeto?
   Uma única pessoa, acompanhada por responsáveis pela área dos dados, governação e  equipas operacionais envolvidas. Uma responsabilidade partilhada entre várias funções atrasa os processos de decisão no momento em que precisam de ser ágeis.
   
4. Como se demonstra o retorno do investimento no final da experimentação?
   Comparando os valores apurados antes do arranque com os registados durante o projeto, nos indicadores acordados inicialmente, e convertendo os resultados em horas de trabalho libertadas e em custos evitados.