A maioria dos projetos de AI falha pela mesma razão: começa pela tecnologia em vez do problema. Uma equipa escolhe uma ferramenta, procura onde a usar, e constrói um piloto que impressiona numa demonstração e nunca chega a produção. Os projetos que funcionam começam pelo lado contrário. Encontram uma tarefa específica, cara e repetitiva, e desenham o sistema à volta das regras do negócio, com o modelo a fazer apenas a parte em que é bom. É esta a diferença entre uma iniciativa de AI que devolve horas e margem e uma que se acaba por desligar em silêncio.
O padrão da falha é quase sempre o mesmo
A história repete-se em empresas de todos os tamanhos. Alguém no topo decide que o negócio precisa de AI. Escolhe-se uma ferramenta, define-se um orçamento, e uma equipa vai à procura de um sítio onde a aplicar. Constrói-se um piloto, demonstra bem, todos ficam entusiasmados por uns dias, e depois estagna. Seis meses depois o piloto ainda é um piloto, o entusiasmo esvaziou-se, e o veredicto interno honesto é que a AI “não funcionou bem connosco”.
A tecnologia raramente foi o problema. O problema foi a ordem das operações. Começar pela ferramenta é resolver “onde podemos usar isto” em vez de “o que nos está de facto a custar tempo e dinheiro”. Acaba-se a automatizar algo que era barato de fazer à mão, ou algo que acontece duas vezes por mês, ou algo que precisava de juízo humano de cada vez. A demonstração ficou bem porque uma demonstração só tem de funcionar uma vez. A produção é outra coisa, porque tem de funcionar todos os dias, sobre entradas reais e desorganizadas, de uma forma em que alguém consiga confiar e que consiga defender.
O que têm em comum os projetos que funcionam
Os sistemas que chegam a produção e lá ficam partilham um pequeno número de traços. Nenhum deles é ter um modelo melhor. Todos eles são sobre como o trabalho foi enquadrado antes de se escrever uma linha de código.
Começam por um bloqueio, não por uma ferramenta
Os projetos bem-sucedidos começam por uma tarefa repetitiva, de volume alto, presa a regras, e que consome hoje o tempo de alguém cujas horas valem mais noutro sítio. Essa descrição é o filtro. Se uma tarefa não encaixa nela, nenhuma tecnologia engenhosa faz valer a pena automatizá-la. A pergunta nunca é “onde podemos usar AI”, é “onde está o tempo humano preso em trabalho que não precisa de juízo humano”, e depois se a AI é sequer a forma certa de o libertar.
Deixam as regras decidir e o modelo ler
Esta é a escolha de desenho mais importante, e a que a maioria dos pilotos condenados erra. Um modelo de linguagem é excelente a ler texto desorganizado e a escrever uma resposta limpa. É um mau sítio para pôr uma decisão, porque não é consistente, não é auditável, e não se explica da mesma forma duas vezes. Os sistemas que funcionam usam o modelo para aquilo em que é bom, ler e redigir, e põem cada decisão em regras de negócio explícitas escritas em código. Quando alguém pergunta porque é que um caso foi tratado de certa maneira, há uma resposta concreta: uma regra com nome e condições. A mesma entrada produz sempre o mesmo resultado. O negócio é dono dessas regras e altera-as sem um programador.
Mantêm um humano nas decisões que importam
Os sistemas que funcionam fazem a primeira passagem e encaminham o que é incerto para uma pessoa, com o motivo explicado em linguagem simples. Isto não é uma limitação, é o que torna o sistema fiável o suficiente para se usar. Um sistema que age com confiança sobre tudo, incluindo os casos em que se enganou, é um sistema que se desliga na primeira vez que causa um erro visível.
São medidos pelo número certo
Os projetos que sobrevivem são avaliados pela percentagem de trabalho concluído sem intervenção humana, não pela precisão média do modelo. A precisão média é uma armadilha. Um sistema com 95% de precisão média pode ser inútil se os 5% de erro estiverem espalhados por casos que parecem corretos, porque então não há fila de exceções, há erros silenciosos a seguir para jusante. O objetivo é errar pouco, e quando se erra, saber, para o erro cair numa fila de revisão em vez dos registos do negócio.
Porque é tão tentador começar pela ferramenta
Se começar pelo problema funciona melhor, porque é que quase toda a gente começa pela ferramenta? Porque a ferramenta é a parte entusiasmante. Há pressão para “estar a fazer alguma coisa com AI”, e comprar uma ferramenta ou construir um piloto vistoso dá a sensação de progresso. Mapear os próprios processos para encontrar onde o tempo está de facto preso é mais lento, menos glamoroso, e força respostas incómodas, às vezes a resposta de que o caso de uso mais falado não vale a pena automatizar.
Há também um incentivo de fornecedor que merece nome. A maior parte do mercado vende o modelo, a plataforma, ou as horas de build, porque é isso que tem para vender. Começar pelo bloqueio conclui às vezes que a resposta certa é um sistema pequeno e pouco vistoso, ou nenhum sistema neste trimestre. Isso é mais difícil de vender e mais honesto de aconselhar.
Como é começar pelo problema
A alternativa é um diagnóstico antes de um build. Antes de escolher qualquer ferramenta, mapear os processos, encontrar onde o tempo humano está preso em tarefas repetíveis, e ordenar os candidatos pelo esforço de os automatizar face às horas e à margem que devolveriam. O output é uma lista curta de oportunidades ordenadas por retorno. Às vezes a linha mais valiosa dessa lista é a que diz que uma dada tarefa ainda não vale a pena automatizar.
Só então um build faz sentido, e é um build focado: um ou dois sistemas em produção numa questão de semanas, com âmbito fechado e entrega real, em vez de um programa sem fim à vista. É a mesma disciplina de diagnóstico que aplicamos ao resto de um negócio através do Growth Engine. Um sistema de AI é construído porque os números o suportam, e não porque a AI está na agenda.
Como é isto em sistemas reais
O padrão mantém-se nos sistemas que construímos, descritos em termos gerais porque os clientes ficam anónimos. Uma mesa de subscrição para uma corretora de seguros comerciais lê pedidos em texto livre para fichas de risco estruturadas e redige respostas, mas cada decisão de aceitar, declinar ou referir sai dos critérios da própria corretora em código, não do modelo. Um sistema de extração de documentos para um escritório de advogados tira campos de faturas e contratos, e depois verifica-os com validação determinística, regras de aritmética e de formato sem modelo nenhum, antes de qualquer coisa chegar a uma pessoa. Um sistema de monitorização de preços para um retalhista acompanha cerca de cinquenta mil referências de sete concorrentes de forma contínua, devolvendo uma semana de trabalho manual por mês. Em cada um, o modelo faz a leitura e a escrita, as regras fazem a decisão, e uma pessoa fica com as decisões que têm consequências. É essa divisão que os mantém a funcionar.
A lição mais funda de todos eles é a mesma. O valor nunca esteve no modelo, que é um bem acessível a qualquer um. O valor esteve em enquadrar o problema certo e construir as regras, as verificações e a revisão humana à volta dele. É esse o trabalho que faz a AI compensar, e é esse o trabalho que a maioria dos projetos falhados saltou.
Perguntas frequentes
Porque é que tantos projetos de AI não chegam a produção?
Porque começam pela tecnologia em vez do problema. Escolhe-se uma ferramenta e constrói-se um piloto para a mostrar, mas resolve-se “onde podemos usar isto” em vez de “o que nos está a custar tempo e dinheiro”. As demonstrações só têm de funcionar uma vez; a produção tem de funcionar todos os dias sobre entradas desorganizadas.
O que fazem de diferente os projetos de AI que funcionam?
Começam por uma tarefa repetitiva e presa a regras, deixam regras explícitas tomar as decisões enquanto o modelo só lê e redige, mantêm um humano nas decisões com consequências, e medem a percentagem de trabalho feito sem intervenção em vez da precisão média.
A AI deve tomar as decisões num processo de negócio?
Não. O modelo é bom a ler entradas desorganizadas e a escrever respostas, e mau a tomar decisões consistentes e auditáveis. Pôr as decisões em regras de negócio explícitas em código, para o resultado se poder explicar e a mesma entrada produzir sempre o mesmo resultado.
Como sei se um projeto de AI vale a pena?
Através de um diagnóstico antes de qualquer build: mapear os processos, encontrar onde o tempo humano está preso em trabalho repetível, e ordenar os candidatos por esforço face às horas e à margem devolvidas. Muitas vezes a conclusão mais útil é que uma tarefa ainda não vale a pena automatizar.
A pensar num projeto de AI?
A forma mais barata de evitar um projeto falhado é começar pelo problema. Numa sessão de estratégia, mapeamos onde a AI devolveria horas e margem, e onde não devolveria.
