Um colaborador cola um trecho de texto numa janela de chat gratuita porque isso funciona mais rápido do que o sistema interno. Uma equipa assina uma ferramenta de IA porque o pedido para algo oficial demoraria semanas. Um fornecedor adiciona funcionalidade de IA a um software já utilizado há anos, sem que sobre isso tenha havido qualquer conversa. Nenhuma destas pessoas está a tentar esconder algo. Estão a tentar fazer o seu trabalho.
Essa é a essência da IA sombra: não surge por má vontade, mas por uma lacuna entre aquilo de que as pessoas precisam e aquilo que o processo formal entrega. Enquanto essa lacuna existir, a IA sombra continuará a surgir, independentemente da quantidade de políticas que sejam escritas.
A maioria das organizações tem uma visão geral do software aprovado. Essa visão é um ponto de partida, não um reflexo da realidade. O que as pessoas efetivamente utilizam está quase sempre à frente disso: a questão de como evitar dados empresariais numa janela de chat gratuita ilustra a facilidade com que uma ferramenta pode escapar a qualquer controlo. O mesmo se aplica a um departamento que, por iniciativa própria, subscreve um serviço porque a via regular parece demasiado lenta, ou a uma extensão de navegador que obtém acesso ao correio eletrónico sem que exista uma aprovação específica para isso. Nenhuma destas situações consta de uma lista de TI. Mas todas existem.
Existe uma tendência para tratar a IA sombra como um problema de fiscalização: proibir, bloquear, sancionar. Isso é contraproducente. Quem sabe que uma resposta honesta leva a um problema deixa de dar respostas honestas. A ferramenta não desaparece, torna-se mais invisível. Exatamente o contrário daquilo de que uma organização precisa.
Uma segunda razão pela qual isto não se resolve por si só: a governação existente é frequentemente concebida para software que se compra e instala, não para um serviço que alguém abre num navegador e abandona no dia seguinte. Uma configuração experimental que outrora se destinava a ser temporária mostra como algo pequeno, sem um momento claro de avaliação, pode perdurar durante anos sem que ninguém se sinta responsável por isso. Sem um processo que identifique estruturalmente este tipo de utilização, ela permanece sob o radar, por muito boas que sejam as intenções.
A única forma de saber o que está a acontecer é perguntar. Não como controlo, mas como levantamento. Os colaboradores que sabem que uma resposta honesta não resulta numa conversa com o departamento de Recursos Humanos também dão essa resposta. Isso exige um tom e um processo que deixem claro, desde o início: isto é sobre obter visão geral, não sobre confrontar alguém.
A isto associa-se também a atenção à forma como novos processos são colocados ao lado dos existentes. Um segundo processo colocado ao lado do já existente, sem que o primeiro seja ajustado ou retirado, é frequentemente ignorado, simplesmente porque as pessoas mantêm o seu hábito. Um levantamento que surge como uma obrigação extra em cima do trabalho recebe o mesmo tratamento.
Uma vez claro o que está realmente a ser utilizado, segue-se a próxima pergunta: o que faz essa ferramenta, e que risco lhe está associado? Uma ferramenta que resume texto para uso interno exige algo diferente de uma ferramenta que participa na decisão sobre a aceitação de clientes ou na avaliação de pessoal. Essa classificação por função e nível de risco é o que transforma um inventário em algo utilizável: uma base a partir da qual a direção, o CIO ou o General Counsel pode explicar o que está em curso e por que motivo isso é justificável.
Esta camada de governação alinha-se com a estrutura de risco que uma organização já possui, e não com um quadro novo ao lado. O conteúdo das regras que as aplicações de IA devem cumprir muda e é mantido atualizado noutro lugar; o que aqui importa é que a organização disponha de uma forma funcional de saber o que está em funcionamento, quem é responsável por isso, e como isso pode ser demonstrado à direção ou ao supervisor.
Uma vez esclarecido que IA é efetivamente utilizada e com que risco isso está associado, surge naturalmente outra pergunta: que parte do trabalho poderia efetivamente uma aplicação de IA assumir, e que parte não. Essa é uma pergunta diferente da aprovação e da supervisão, mas que se segue logicamente a ela. O werkscan da FTE TO AI calcula, por tarefa, qual a parte do trabalho que pode ser assumida por IA, com base naquilo que uma função efetivamente implica. Onde a Responsible AI Scan traz ordem ao que já está em funcionamento, o werkscan mostra o que ainda há a ganhar.
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.