Uma demo é agendada. Um fornecedor ou uma equipa interna mostra o que uma aplicação de IA consegue fazer: um chatbot que responde a perguntas de clientes, uma ferramenta que resume relatórios, um assistente que escreve código. A sala fica entusiasmada. Há acenos de aprovação, fazem-se perguntas, alguém diz que isto é "exatamente o que precisamos". Uma semana depois, a energia desapareceu e nada mais acontece.
A armadilha não é a demo em si. A armadilha é que uma demo é realizada sem que fique previamente estabelecido quem é responsável, depois da apresentação, pelo que acontece com o resultado. Há uma apresentação, não há um responsável de processo. Há uma reação, não há uma decisão. Há atenção, não há uma agenda.
Organizar uma demo parece uma ação concreta. Mostra-se algo, há reação, vê-se movimento. Numa organização sob pressão para fazer algo com IA, esse movimento já tem valor: prova que não se está de braços cruzados. Uma demo custa pouco, é fácil de agendar e gera imediatamente uma história que pode ser partilhada com uma direção ou um conselho de administração.
Além disso, organizar uma demo é mais fácil do que atribuir uma responsabilidade. Uma demo exige apenas um espaço na agenda. A responsabilidade exige alguém que receba orçamento, tempo e mandato para responder por um resultado, mesmo quando esse resultado é insatisfatório. Esta última é uma questão política, não operacional. Agendar uma demo é mais fácil do que colocar essa questão, por isso a demo é agendada e a questão é ignorada.
O resultado é que uma demo se torna um substituto de uma decisão em vez de um motivo para tomar uma decisão. Enquanto ninguém perguntar quem será o responsável a partir daí, a demo permanece uma apresentação sem continuidade.
Há alguns sinais reconhecíveis. Depois da demo, há aplausos, mas nenhum nome é mencionado como responsável por dar continuidade à iniciativa. Fala-se em "vamos continuar a avaliar isto" sem que fique definido quem faz essa avaliação e quando essa pessoa apresenta um resultado. A demo é repetida dentro de algumas semanas para outro departamento, com a mesma reação e a mesma falta de continuidade.
Outro sinal é que a discussão após a demo se centra na tecnologia — quão impressionante é a ferramenta, tudo o que ela consegue fazer — em vez de na organização que deveria utilizá-la. Isso é um indício de que se está a ignorar a pergunta se a estrutura existente consegue suportar a aplicação. O que isso significa pode ler em por que a tecnologia sobre uma estrutura inalterada não gera resultado nenhum.
Também reconhecível: a demo é sustentada por duas pessoas que estão pessoalmente entusiasmadas com IA, enquanto o resto da organização permanece como espectador. Assim que essas duas pessoas ficam ocupadas com outro trabalho, a iniciativa estagna, porque mais ninguém se sente responsável. Essa dinâmica está descrita em por que dois entusiastas e mais ninguém não gera resultado nenhum.
Um último sinal: depois da demo decide-se avançar para um piloto, mas ninguém acordou previamente com base em que critérios esse piloto será avaliado. Sem esse acordo, um piloto é apenas uma demo prolongada — mostra algo, mas não prova nada. Esse padrão está desenvolvido em por que um piloto sem acordo sobre o que deve ficar demonstrado não gera resultado nenhum.
Uma demo sem responsável não é um erro na demo, mas um erro na sua preparação. Antes de agendar uma demo, pode ficar estabelecido quem assume o resultado depois de terminada, quem decide se há continuidade e dentro de que prazo essa decisão é tomada. Essa não é uma condição técnica, mas organizacional, e essa condição precede a pergunta sobre qual ferramenta demonstra melhor.
Essa ordem — organização primeiro, tecnologia depois — é exatamente onde a maioria das iniciativas de IA encalha. Quem quiser saber se a própria organização já tem essa base estabelecida encontra uma visão detalhada por função em o que um CEO observa na maturidade em IA e o que um COO observa na maturidade em IA.
Uma demo mostra o que uma tecnologia consegue fazer, mas nada diz sobre o que isso significa para o trabalho na sua própria organização. A partir do momento em que fica estabelecido quem é o responsável por uma iniciativa de IA e a base está pronta para isso, surge a questão de que parte do trabalho efetivo pode realmente ser assumida. Essa questão não é respondida por uma demo, mas por um cálculo estruturado por tarefa. O werkscan da FTE TO AI faz exatamente isso: calcula, por tarefa, que parte do trabalho pode ser assumida pela IA, permitindo que um responsável decida com números, em vez de impressões, o que vale a pena dar continuidade.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.