Uma equipa quis experimentar algo. Um chatbot para perguntas de clientes, um script que resume relatórios, uma ligação a um modelo de linguagem para organizar e-mails. Não foi preciso nenhuma grande decisão: alguém tinha uma conta, uma chave de API ou um período de teste gratuito, e dentro de uma tarde já havia algo em funcionamento. O piloto funcionava, ou funcionava suficientemente bem, e ninguém tinha mais nenhum motivo para o desligar.
Isto não é uma excepção. É a forma habitual como a IA entra numa organização. Não através de um concurso público ou de um orçamento aprovado, mas através de uma instalação-piloto que sobrevive ao seu próprio estatuto de teste. A fase de teste nunca foi formalmente encerrada, porque também nunca houve um início formal para encerrar.
Um piloto que funciona é utilizado. E aquilo que é utilizado torna-se dependência. A equipa que construiu o resumidor de relatórios pode já ter saído, mas o resumo continua a chegar todas as semanas. Ninguém tem a incumbência de o desligar, e ninguém quer correr o risco de algo deixar de funcionar sem saber o que o vai substituir.
Além disso, uma instalação-piloto normalmente não tem um responsável no sentido em que uma estrutura de governança o exige. Não foi feita nenhuma classificação de risco, não foi realizada nenhuma análise de dados, não foi tomada nenhuma decisão sobre quem é responsável se algo correr mal. O piloto existe num espaço intermédio: demasiado utilizado para ser ignorado, demasiado informal para ser gerido. É exactamente este o padrão que leva a colaboradores que utilizam uma ferramenta que ninguém aprovou — só que agora a nível de equipa em vez de individual.
A reacção reflexa ao descobrir uma instalação-piloto não autorizada é frequentemente: quem permitiu isto, e por que razão não sabíamos. Essa pergunta é compreensível, mas produz o efeito contrário. Quem, já na primeira conversa, sente que se aproxima uma busca de culpados, deixa de contar mais nada na próxima vez. E a próxima instalação-piloto — que sem dúvida virá — desaparecerá do radar tão bem como esta.
Um levantamento construído sobre confiança rende mais do que uma auditoria construída sobre controlo. Não porque as pessoas não tenham nada a esconder, mas porque a informação que procura está junto do utilizador, e esse utilizador só fala se não for penalizado pelo que revela.
Assim que uma instalação-piloto é identificada, a primeira pergunta não é se pode continuar a existir, mas o que exactamente faz. Que dados entram, quem utiliza o resultado, e o que acontece se o resultado estiver errado. São as mesmas perguntas que se aplicam a qualquer outra aplicação de IA, e a resposta determina se algo é uma ferramenta informal ou um risco que merece atenção.
Segue-se depois a classificação: a aplicação encaixa numa categoria de risco já existente, ou exige uma nova avaliação. A seguir: o que deve ser registado para demonstrar que a organização sabe o que está em funcionamento e porquê. É exactamente isso que o que deve registar por aplicação aborda — não como burocracia adicional, mas como a documentação mínima necessária para distinguir um piloto de um risco.
Uma instalação-piloto que passa este teste pode continuar a existir, agora com um responsável e uma classificação. Uma instalação-piloto que não passa o teste deve ser desmantelada — mas isso é um processo controlado, não uma penalização da pessoa que a iniciou.
A instalação-piloto que nunca foi desligada é uma forma de um padrão mais amplo. Pense na extensão do browser com acesso ao seu e-mail que alguém instalou um dia para poupar tempo, ou nos dados empresariais que acabam numa janela de chat gratuita porque era mais rápido do que a ferramenta oficial. Todas estas situações partilham uma característica: surgiram de uma necessidade prática, não de uma escolha de política, e continuam a existir enquanto ninguém perguntar por elas.
A lista de TI com software aprovado não é, por isso, o ponto de partida de um inventário — é o ponto de partida de uma procura por aquilo que fica fora dessa lista. Quem quiser saber como é essa procura encontra uma abordagem em como constrói um inventário de IA.
Uma instalação-piloto que sai à luz costuma suscitar uma pergunta que vai além da governança: por que razão é que isto funcionava tão bem que ninguém se atreveu a interrompê-lo? Essa é uma pergunta sobre o próprio trabalho, não apenas sobre o risco. O scan de trabalho da FTE TO AI calcula, por tarefa, que parte do trabalho pode ser assumida pela IA, tornando visível aquilo que uma instalação-piloto já implicitamente mostrava: que parte do trabalho pode ser organizada de forma diferente. Enquanto a Responsible AI Scan mapeia o que está em funcionamento e sob que risco, o scan de trabalho mostra de onde vem essa utilização e o que significa estruturalmente para a distribuição de tarefas.
A Responsible AI Scan, com o levantamento, a classificação e o conjunto de governança descritos acima, está em desenvolvimento. Quem já lida com isto e quiser ser informado assim que o instrumento estiver disponível pode inscrever-se na lista de espera.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.