Kennisbank

A monitorização que funciona é a que se encaixa no que já existe

Muita monitorização do uso de IA surge como uma iniciativa separada: um novo formulário, uma nova reunião, um novo painel. Parece completa no momento do lançamento. Um ano depois, esvaiu-se. Não porque o conteúdo fosse mau, mas porque estava ao lado da estrutura existente em vez de dentro dela.

A questão não é apenas o que deve ser monitorizado, mas onde essa monitorização se instala. Um processo que ninguém precisa de memorizar, porque já faz parte de uma rotina que de todo o modo já existe, sobrevive. Um processo que exige um passo extra de pessoas que já estão sobrecarregadas acaba, com o tempo, por ser ignorado. Isso não é falta de vontade. É uma consequência previsível da forma como as organizações gerem o tempo e a atenção.

Por que motivo um segundo processo perde terreno

Toda a organização já tem um ritmo próprio: relatórios trimestrais, comités de risco, ciclos de auditoria, reuniões de equipa. Se a monitorização do uso de IA introduzir um novo ritmo, entra em concorrência com tudo o que já existe — e normalmente perde. Não há um ponto na agenda para isso, não há um responsável que o veja como parte essencial da sua função, não há um momento em que surja naturalmente na conversa.

Se, pelo contrário, a monitorização se tornar uma pergunta que já é feita — no comité de risco existente, no controlo interno existente, na linha de reporte existente à administração — então ninguém precisa de memorizar nada de novo. A pergunta "que aplicações de IA foram adicionadas ou alteradas" torna-se então tão natural como "há novos fornecedores" ou "houve incidentes". A forma exata como esse encaixe se concretiza depende de como o encaixe na estrutura de risco existente já está organizado na sua organização — essa estrutura é o ponto de partida, não algo ao lado dela.

O que deve constar no documento

Um documento de monitorização que funciona é suficientemente breve para ser usado de forma repetida e suficientemente específico para permitir assinalar algo quando algo muda. Deve conter, no mínimo:

• Uma lista atualizada de aplicações de IA, incluindo o que foi registado através das TI e o que é usado fora desse circuito. Essa segunda categoria é muitas vezes a maior, e desaparece de qualquer documento que dependa apenas da aprovação formal.
• Uma classificação de risco por aplicação, de modo a que nem toda a alteração exija a mesma atenção. Um gerador de texto para notas internas exige algo diferente de um modelo que participa em decisões sobre aceitação de clientes.
• Um responsável por aplicação, um nome, não um departamento. Sem um responsável, uma alteração não é detetada por ninguém.
• Um intervalo fixo em que a lista é revista, ligado a um momento que já existe — não um novo momento que precise de ser agendado em separado.
• Um local onde os desvios se tornam visíveis, de modo a que um novo uso ou uma aplicação alterada não passe despercebida durante meses.

O valor do documento não está na sua completude no primeiro dia. Isso raramente é possível, nem é necessário. O valor está no facto de ser mantido atualizado, e de essa atualização não exigir um esforço separado, acima do que já acontece.

Por que motivo a responsabilização punitiva interrompe a informação

A monitorização depende daquilo que as pessoas estão dispostas a comunicar. No momento em que comunicar equivale a correr o risco de ser penalizado por algo, a informação para. Alguém que conclui uma tarefa com uma ferramenta de IA mais rapidamente do que o esperado não o comunica se a consequência disso for a retirada de orçamento ou uma conversa incómoda. A lista mantém-se então formalmente completa e substancialmente vazia — exatamente o problema que perpetua a IA-sombra.

A consequência é que a monitorização só funciona se as perguntas forem feitas sem punição associada. Não porque o uso deva ficar sem consequências, mas porque o primeiro passo — saber o que está a acontecer — exige uma postura diferente do segundo passo — avaliar se é apropriado. Quem faz coincidir estes dois passos não obtém uma resposta honesta em nenhum deles.

Essa distinção é também onde a governação e a responsabilização se cruzam. A visibilidade para a administração não tem de significar que cada aplicação individual seja levada à mesa; trata-se de um nível de reporte que permite formar um juízo sem se perder em detalhes, como descrito em um relatório à administração que cabe numa página. O que está abaixo disso — o registo de decisões sobre aplicações concretas — pertence mais a uma lista de decisões de supervisão do que ao documento que sobe até à administração.

Se um documento de política é ou não efetivamente lido é uma questão semelhante: um texto que ninguém consulta oferece tão pouco apoio como um processo de monitorização que ninguém preenche. Veja a este respeito uma política de IA que é lida. E para quem se pergunta que parte desta responsabilidade cabe à administração e que parte cabe à governação de TI, existe uma distinção entre o que um administrador precisa de saber sobre o risco de IA e o que um CIO precisa de saber sobre o risco de IA — ambos exigem níveis de detalhe diferentes dentro do mesmo processo de monitorização.

De saber o que está em funcionamento a saber o que rende

Uma estrutura de monitorização que se encaixa no que já existe acaba, em determinado momento, por produzir uma imagem fiável de quais as aplicações de IA em uso e para que fins. Esse inventário é uma questão diferente de quanto do trabalho subjacente é efetivamente realizado por IA, e com que efeito. Quem quiser calcular isso por tarefa — que parte de uma função ou processo pode ser transferida para a IA, com base nas tarefas tal como são executadas atualmente — encontra essa resposta na análise de trabalho da FTE TO AI.