Responsável de implementação de IA — tarefas, uma a uma

Decidir o que experimentar primeiro

A entrada que manda não é conhecer as ferramentas, é conhecer esta empresa: que passo é mesmo o estrangulamento, a quem mexem os números se mudar, e quem vai ficar zangado. Essa informação na sua maior parte não está escrita em lado nenhum, por isso não se consegue ir buscá-la — tem de ser recolhida por alguém que ande por lá a perguntar.

Difícil de automatizar não é o mesmo que duradouro. Este lugar existe todo ele porque há uma transição a decorrer; quando as ferramentas se tornarem banais como as folhas de cálculo se tornaram, escolher o que automatizar passa a ser parte de gerir uma função em vez de ser uma função própria. A segurança aqui é a segurança de um andaime.

Testá-lo no trabalho real desta empresa

As ferramentas de avaliação ficaram genuinamente boas e grande parte da pontuação pode correr sozinha. O que não se automatiza é decidir o que conta como correto para esta empresa, que é um juízo de negócio vestido de técnico — duas empresas que fazem a mesma tarefa podem ter limiares diferentes para o mesmo erro.

Uma boa avaliação diz-te que a ferramenta funciona nos casos que te lembraste de juntar. Nada diz sobre os casos em que ninguém pensou, e é aí que vivem as falhas caras — por isso passar é uma razão para começar a vigiar, e não para parar.

Ligá-la ao que já existe

Escrever o código de integração é uma das coisas que estas ferramentas fazem melhor, por isso construir ficou muito mais barato. Saber qual dos quatro sistemas tem a versão boa de um registo, e que campo mente em silêncio, não ficou — esse conhecimento vive em pessoas que estão na empresa há anos.

Integrar ser barato é a razão pela qual os pilotos se multiplicam e pela qual a maioria continua a correr como pilotos. Conseguir ligar uma ferramenta numa tarde não estabelece que alguém tenha mudado a forma de trabalhar, e as duas coisas são reportadas como o mesmo marco.

Decidir o que ela pode fazer sem supervisão

Isto é uma repartição de responsabilidade, e não uma tarefa de configuração. Decidir que uma ferramenta pode comprometer a empresa com um preço, uma data ou um pedido de desculpa é uma decisão sobre quem responde por isso — e um sistema não pode autorizar a sua própria autoridade.

Os limites serem trabalho humano não significa que cheguem a ser escritos. Na maioria das empresas ninguém recebeu esta tarefa, por isso a fronteira é decidida por omissão — por quem configurou a ferramenta — e essa omissão é invisível até sair alguma coisa que não devia ter saído.

Conseguir que as pessoas a usem mesmo

A adoção falha por razões que as pessoas não põem num inquérito: faz alguém parecer mais lento, tira a parte do trabalho de que gostava, está um clique mais longe de onde já estão. Descobrir isso exige confiança, e agir sobre isso exige autoridade para mudar o processo.

É a tarefa com mais probabilidade de ser cortada, porque é lenta e não produz nenhuma peça para mostrar. Uma empresa que compra as ferramentas e salta isto fica com o custo das licenças e com o piloto, e reporta ambos como progresso.

Estar lá quando ela erra

Todos os recuos públicos que este sítio regista têm esta forma: a falha técnica era recuperável e o vazio de responsabilidade não era. Alguém tem de responder pelo resultado à frente de um cliente ou de um regulador, e responder é a única coisa que não se pode delegar no sistema que o causou.

Carregar com a culpa não é o mesmo que ter a autoridade. Este lugar responde muitas vezes por decisões que não pode anular — o orçamento, o fornecedor, o prazo foram fixados noutro sítio — e essa combinação é a razão mais comum pela qual as pessoas o deixam.