Você tem uma lista de ferramentas de IA aprovadas. A questão não é se essa lista está correta, mas se ela ainda significa algo. Um funcionário que acelera uma tarefa com um chatbot que não está na lista não relata isso como incidente. Ele não relata porque não parece um incidente. A resposta que você não deve aceitar é, portanto, "temos uma política de IA e uma lista aprovada" — porque essa frase não diz nada sobre o que acontece fora dessa lista, e essa é provavelmente a maior parte.
Como CIO, é você quem tem de explicar por que um incidente de IA não era conhecido antes, enquanto o resto da organização assume que a TI tem visão geral. Essa visão geral existe para sistemas que foram adquiridos. Ela não existe para o plug-in que uma equipe instalou por conta própria, a versão de teste que alguém ativou, ou o modelo que veio incluído numa ferramenta de atendimento ao cliente. O risco para você não é que a IA seja usada — isso acontece de qualquer forma — mas que você seja o último a saber, no momento em que já deu errado.
Um inventário correto muda a sua posição. Em vez de reagir a incidentes que não viu chegar, você pode indicar antecipadamente onde estão os riscos e por quê. Essa é também a base para conduzir, dentro da organização, a conversa com o General Counsel, que olha para a mesma IA-sombra a partir de outra perspetiva, e com o gestor de risco, que quer integrá-la na estrutura de risco já existente em vez de criar um percurso separado ao lado dela.
A lista de TI regista o que foi adquirido e aprovado. A IA-sombra surge onde essas duas etapas são ignoradas: um funcionário encontra uma ferramenta, usa-a, e não reporta nada porque parece não haver nada a reportar. Isto não é negligência — é a consequência de um processo de aquisição que não foi concebido para acompanhar o que as pessoas adotam por conta própria. Quanto maior a organização e quanto mais equipas trabalham de forma autónoma, maior pode ser a diferença entre a lista e a realidade. O quão pequena é essa diferença depende de quanta liberdade as equipas têm para escolher as suas próprias ferramentas e de quão visível esse comportamento já é — não há um número sobre isso, apenas a tendência.
A única forma de saber o que realmente está em uso é perguntar às pessoas que o utilizam. Isso só funciona se a resposta não implicar uma consequência para quem a dá. Se perguntar "usa ferramentas de IA que não foram aprovadas" num tom que remete para uma avaliação de desempenho, obterá a resposta que a lista de TI já dava: não. Se perguntar isso desligado de consequências, com o objetivo de compreender em vez de corrigir, surge uma imagem que corresponde efetivamente à prática. Essa distinção — perguntar sem consequências versus perguntar com consequências — é a diferença entre um inventário que vale algo e um exercício que não diz nada a ninguém.
Uma lista de ferramentas utilizadas é um ponto de partida, não um ponto de chegada. Nem toda aplicação de IA carrega o mesmo risco. Uma ferramenta que reescreve texto para uso interno é diferente de uma ferramenta que participa na decisão sobre a aceitação de um cliente ou numa avaliação de pessoal. Classificar por função — o que o sistema faz — e por nível de risco — qual é o impacto se algo correr mal — é necessário para saber onde deve concentrar a atenção. Sem classificação, todas as aplicações de IA parecem iguais num relatório, e é precisamente essa imagem que não ajuda a conquistar o apoio da direção.
Como CIO, você provavelmente já tem um quadro de risco para sistemas de TI, segurança da informação e fornecedores. A governação de IA funciona melhor quando se liga a essa estrutura do que quando se torna um quadro solto ao lado. É também isso que o compliance officer e o líder do programa de IA enfrentam: demasiadas iniciativas de IA separadas que não comunicam entre si, enquanto a direção espera precisamente uma resposta única e coerente sobre o que está a acontecer e o que está a ser feito a esse respeito.
O significado da IA-sombra varia por setor. Na construção civil, funciona de forma diferente do setor das instalações técnicas, e vale a pena ver como a governação de IA se configura na construção civil ou como isso se apresenta no setor das instalações técnicas antes de assumir que uma única abordagem serve para todos os contextos.
O Responsible AI Scan que produz isto — inventário, classificação, um conjunto de governação alinhado com a sua estrutura existente — está em desenvolvimento. Quem já quiser avançar com isto pode inscrever-se na lista de espera; ainda não há um produto pronto para oferecer, e preferimos escrever isso com honestidade do que prometer algo que ainda não existe.
Assim que souber que IA está a ser utilizada e com que risco, surge naturalmente a pergunta seguinte: que parte do trabalho em si poderia ser uma tarefa para a IA, e que parte não. Essa é uma pergunta diferente da gestão de risco — trata-se de capacidade, não de exposição — e o scan de trabalho da FTE TO AI calcula isso por tarefa, para que você saiba não só o que já está em funcionamento, mas também onde a IA poderia assumir o próprio trabalho.
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.