Recuos na IA: Histórias Reais de Líderes
Lições sobre IA: Muitos líderes ignoram as valiosas lições de projetos de IA falhados ou suspensos, perdendo conhecimentos fundamentais.
Parar em Vez de Avançar: As empresas beneficiam frequentemente de suspender as iniciativas de IA para estabelecer processos fundamentais e garantir a qualidade dos dados.
Primeiro, Manualmente: A automatização só deve acontecer depois da execução manual, garantindo que os processos estão claramente definidos e compreendidos.
Medir o Impacto: A chave para o sucesso é avaliar os processos atuais e o potencial impacto da IA antes de iniciar a implementação.
Importância da Documentação: Uma documentação eficaz deve registar não só os processos, mas também a lógica subjacente às decisões e às exceções.
A maioria das histórias sobre adoção da AI é contada a partir do pódio dos vencedores. São muito menos os líderes que falam do momento em que desligaram tudo — a automação que foi cancelada, a implementação que foi suspensa, o projeto-piloto que teve de ser reconstruído de raiz. Mas é muitas vezes nessas histórias que se encontram as verdadeiras lições.
Perguntámos a três especialistas que passaram por isso: o que foi desfeito, porquê e o que fariam de forma diferente? As respostas convergem para um tema surpreendentemente consistente — o problema quase nunca é a própria AI.
Quando a decisão inteligente é fazer uma pausa, não avançar
Para a maioria das organizações, eliminar completamente um investimento em AI não é realista depois de o dinheiro ter sido gasto. Tejinder, gestor sénior na Deloitte Consulting, afirma claramente que a remoção total não estava em cima da mesa, tendo em conta os investimentos já realizados — mas uma pausa deliberada estava. Quando os resultados não estiveram à altura, a sua equipa recuou e “analisou primeiro os aspetos básicos”, questionando se os processos subjacentes estavam estabelecidos, se “a qualidade dos dados” era “boa” e se os planeadores compreendiam o papel dos agentes em comparação com o seu próprio papel. “Penso que, depois de estas questões terem sido respondidas, a reativação fez sentido”, afirma.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Priyanka Dave, PhD, responsável pelo desenvolvimento de competências e proprietária do processo de aprendizagem na Oregon State University, observou o mesmo padrão repetir-se várias vezes. “Observei várias organizações a adiar intencionalmente a expansão de iniciativas de AI depois de reconhecerem que não estavam operacionalmente preparadas.” Nesses casos, o recuo não foi um fracasso — foi um redirecionamento. “Em vez de expandir imediatamente a AI, a liderança transferiu o seu foco para o reforço da base organizacional”, explica Dave. Isto significou que “as organizações investiram na documentação dos processos empresariais, na normalização dos fluxos de trabalho, na melhoria da governação dos dados e no desenvolvimento das capacidades dos colaboradores através de aprendizagem estruturada e gestão da mudança.”
Em vez de expandir imediatamente a AI, a liderança transferiu o seu foco para o reforço da base organizacional.
Não automatize aquilo que ainda não fez manualmente
Por vezes, recuar significa cancelar um projeto por completo — e descobrir que essa foi a decisão certa desde o início. Jaime Gil Martinez, fundador e consultor principal da Swift Ops Solutions, aprendeu isso da forma mais difícil. “Certa vez, criei uma automação para produzir materiais de marketing para um cliente que nunca tinha realizado o processo manualmente”, recorda. “Como era algo novo para eles, ambos concluímos que seria melhor criar a automação de raiz. No papel, fazia sentido. Visto em retrospetiva, foi um erro de principiante.”
O sistema funcionava do ponto de vista técnico. “A automação funcionava”, afirma Gil Martinez. “O problema era que, sempre que era necessário um resultado, algo tinha de ser reconsiderado ou ajustado (um público-alvo diferente, um formato diferente, um esquema diferente), por isso eu continuava a reconstruí-la. Depois de algumas rondas, o padrão era evidente — estava a automatizar um processo que ainda não tinha sido definido por ninguém.”
Depois de algumas rondas [de ajustes], era evidente que estava a automatizar um processo que ainda não tinha sido definido por ninguém.
A solução foi recuar. “Por isso, cancelámos o projeto por completo e voltámos a produzir os materiais manualmente”, afirma. “Afinal, esse era o objetivo: cada ronda manual deu-nos aquilo que nos faltava, nomeadamente exemplos de referência e uma visão clara do que variava e do que não variava. Retomámos a automação mais tarde, e esses resultados manuais tornaram-se a base de conhecimento que entregámos à AI.” Esta experiência deu origem a uma regra que aplica agora na sua própria empresa e com os seus clientes: “não automatize nada até o ter feito manualmente pelo menos três vezes. Depois, pode começar a ponderar fazê-lo.”
O passo que todos ignoram: meça antes de construir
Pergunte a Gil Martinez o que falta na maioria dos planos de adoção de IA, e a resposta é imediata: “Medir antes de construir. À data de início, faltam à maioria das empresas dois números: quão bom ou mau é realmente o seu processo atual e que impacto a IA poderia realisticamente ter nele. Sem ambos, não é possível saber quão eficaz foi a implementação nem se o custo foi justificado.”
Ele aponta para uma clínica de saúde que queria automatizar o agendamento de mais de 100 pacientes. “Não sabiam quanto tempo isso lhes levava, apenas que era demorado e frustrante”, afirma. “E, se não sabe quanto tempo demora, não sabe quanto lhe custa.” Assim, antes de construir fosse o que fosse, o primeiro passo foi calcular as horas consumidas pelo agendamento e o valor financeiro dessas horas. “Isso deu-nos a referência: duas semanas de trabalho manual a tempo inteiro. A automatização reduziu-o a um dia de trabalho assistido por IA, a um custo inferior à despesa equivalente atual.” Com esses números em mãos, “a decisão surgiu naturalmente.”
Dave vê uma omissão diferente, mas igualmente crítica: a preparação não diz respeito apenas à tecnologia. “O passo que vejo as organizações omitirem com mais frequência é avaliar a capacidade da força de trabalho antes de implementar IA”, afirma. E as lacunas raramente acabam por estar relacionadas com a formação na utilização das ferramentas. Em várias avaliações de capacidades, “as avaliações revelaram consistentemente que as maiores lacunas de capacidade envolviam o pensamento analítico, o pensamento crítico, a literacia de dados, a comunicação consultiva e a resolução de problemas.” A sua conclusão é clara: “A preparação tecnológica e a preparação da força de trabalho são desafios diferentes. Uma adoção sustentável da IA exige ambas.”
Quando a IA é aplicada a um processo que não está preparado
O que falha realmente quando a IA é integrada num processo imaturo? Tejinder viu isso em primeira mão quando “a IA foi integrada num processo empresarial (processamento e distribuição de encomendas) que não era suficientemente maduro” — o resultado foi uma solução repleta de erros. Mas é claro quanto à origem do problema: “Acredito que a IA não foi o problema neste caso”, afirma, apontando antes para a maturidade do processo, problemas com os dados principais, lacunas de requisitos não colmatadas e testes inadequados.
A IA foi integrada num processo empresarial (processamento e distribuição de encomendas) que não era suficientemente maduro.
Dave descreve a mesma dinâmica nas suas avaliações: diferentes departamentos a realizar o mesmo trabalho de formas diferentes, documentação incompleta e exceções que existem apenas na cabeça dos colaboradores. “A preocupação era que a IA se limitasse a reproduzir práticas inconsistentes em toda a organização”, afirma. É uma consequência de um princípio a que recorre frequentemente: “A IA não resolve problemas organizacionais. Amplifica os sistemas existentes. Se os processos forem inconsistentes ou estiverem mal documentados, a IA irá muitas vezes ampliar essas inconsistências em vez de as melhorar.” A conclusão, nas suas palavras, é a seguinte: “A lição recorrente foi que as organizações devem melhorar os processos antes de tentarem automatizá-los.”
Se os processos forem inconsistentes ou estiverem mal documentados, a IA irá muitas vezes ampliar essas inconsistências em vez de as melhorar.
Gil Martinez também tem as suas próprias marcas desta experiência — uma aplicação de geração de contactos que “falhou de forma dramática da primeira vez.” O desenvolvimento passou de semimanual para totalmente automatizado sem requisitos ou testes definidos. “O meu erro foi presumir que a IA descobriria parte da lógica por si própria, porque a lógica parecia óbvia e simples”, admite. A situação complicou-se a partir daí. “O código tornou-se impossível de gerir e ficou inteiramente sob o controlo da IA, ao ponto de eu não conseguir reverter para um marco seguro. Foi nesse momento que percebi que estava estruturalmente danificado, e não apenas com erros.”
A recuperação exigiu uma reinicialização completa. “A solução foi tão dolorosa quanto óbvia: começar de novo”, afirma. “Desta vez, delineei todos os requisitos e um teste para cada um, desenvolvi de forma incremental e dei à IA instruções claras para registar falhas e sucessos, juntamente com um controlo de versões adequado.” A segunda tentativa, mais disciplinada, “demorou aproximadamente metade do tempo que tinha desperdiçado na primeira tentativa para chegar a uma solução funcional e adequada para produção.”
Como é realmente uma boa documentação para a IA
Por detrás das três histórias está a mesma solução: documentação que regista como o trabalho é realmente realizado. Para Dave, isso significa ir além das listas de tarefas. “Uma boa documentação de processos explica não só o que as pessoas fazem, mas também por que motivo tomam determinadas decisões”, afirma. E o material mais valioso é geralmente aquilo que nunca é escrito. “Um dos erros mais comuns cometidos pelas organizações é documentarem apenas o fluxo de trabalho padrão. O maior conhecimento organizacional encontra-se frequentemente nas exceções, nas decisões baseadas em juízos e nas decisões contextuais tomadas por colaboradores experientes.”
Gil Martinez enquadra-o através de uma perspetiva que os gestores de projeto reconhecerão cada vez mais: “Uma boa documentação de processos é semelhante à engenharia de prompts. Os mesmos elementos que aprendemos a fornecer à IA num prompt (função, contexto, tarefa, instruções, restrições) devem surgir ao nível do projeto.” Esta mudança tem implicações na forma como os profissionais ocupam o seu tempo. “O tempo de execução dos humanos está a desaparecer, sendo transferido para a IA, pelo que o nosso foco tem de passar para um bom planeamento e para a validação dos resultados. Temos de agir como gestores de IA.”
Conclusão: a sequência é a estratégia
Nenhum destes líderes se arrepende de ter investido em IA. O que lamentam — ou viram outros lamentarem — é a ordem das operações. Tejinder resume-o assim: “A adoção empresarial da IA falha quando o modelo é implementado antes dos fundamentos operacionais. A sequência certa é, primeiro, maturidade dos processos, qualidade dos dados e clareza das funções. A IA vem depois. Quando as organizações invertem essa ordem, culpam a IA, mas o problema subjacente é quase sempre o ambiente em que a IA foi inserida.” Afinal, recuar não é o fracasso. Implementar antes de estar preparado é.
Quer mais informações como estas? Crie uma conta DPM gratuita para ouvir mais especialistas como estes.
