Uma lista de decisões de oversight regista quem tomou qual decisão sobre qual sistema de IA, com base em que informação, e com que ressalva. Isso parece simples. Na prática, a primeira versão falha frequentemente porque é apresentada como um novo processo ao lado das reuniões existentes. Um segundo processo ao lado do existente é ignorado, não porque as pessoas sejam desleixadas, mas porque ninguém reserva tempo para algo que não se encaixa numa agenda já preenchida.
A lista não é um registo de atividades nem um registo de riscos. Contém decisões: momentos em que alguém com competência aprovou, rejeitou, adiou ou permitiu avançar sob condições. Por linha devem constar, no mínimo, quatro elementos: o sistema ou a aplicação a que a decisão se refere, o nome e a função de quem decidiu, a data, e a fundamentação ou a ressalva. Sem fundamentação, uma lista de decisões é uma lista de presenças. Com fundamentação, torna-se a prova de que houve reflexão, não apenas de que algo foi assinalado.
A lista deve também deixar espaço para revisão. Uma decisão tomada há seis meses com base na informação então disponível pode estar desatualizada. Uma boa lista de decisões mostra quando uma decisão foi reconfirmada ou revogada, não apenas quando foi originalmente tomada.
Os conselhos e as direções já têm um ritmo próprio: reuniões trimestrais, comités de risco, comissões de auditoria. Quem cria uma nova estrutura de oversight desligada desse ritmo está a pedir às pessoas que encontrem tempo extra para algo sem um lugar claro. Isso raramente acontece de forma estruturada. As primeiras vezes talvez resultem, com esforço. Depois desaparece da agenda logo que surge algo mais urgente, e surge sempre algo mais urgente.
A solução não é construir um novo processo, mas fazer com que a lista de decisões acompanhe o que já está a acontecer. Se já existe um comité de risco que se reúne todos os trimestres, a lista de decisões sobre IA deve ser uma parte fixa dessa agenda, não uma sessão separada. Se já existe um trilho de auditoria para decisões financeiras, a lógica desse trilho — quem assina, quem verifica, onde é guardado — deve ser reutilizada para as decisões sobre IA. É também por isso que alinhar com a estrutura de risco existente é um tema separado: uma lista de decisões que não se alinha com a forma como o risco já é discutido em outros lugares permanece um documento isolado que ninguém consulta.
Uma lista de decisões não funciona isoladamente. Alimenta o relatório de que um conselho precisa para poder afirmar que existe visibilidade sobre o risco de IA, e pressupõe que existe um caminho para quando uma decisão se revela insustentável. Sem um relatório de conselho de uma página que resuma a lista de decisões, a informação desaparece num arquivo que ninguém consulta. Sem caminhos de escalonamento que funcionam, uma decisão desatualizada simplesmente permanece, porque ninguém sabe a quem a deve comunicar.
Os três elementos estão relacionados: a lista de decisões regista o que foi decidido, o relatório torna isso visível ao nível onde tem peso, e o escalonamento garante que uma decisão pode ser reaberta se a situação mudar. Construir um sem os outros dois cria uma aparência de controlo que, ao primeiro teste — um incidente, uma pergunta de um regulador, um jornalista — não se revela suficiente para cobrir o que realmente se passa.
Uma lista de decisões vale tanto quanto a informação que nela entra. Se ninguém souber quais sistemas de IA estão efetivamente em uso — incluindo o que foi adquirido ou implementado fora do departamento de TI — a lista apenas regista decisões sobre as aplicações visíveis e formalmente aprovadas. O resto permanece sem decisão, não porque não fosse necessária uma decisão, mas porque ninguém sabia que havia algo sobre o que decidir. É por isso que um inventário precede sempre uma lista de decisões, e não o contrário. O que um administrador deve saber sobre isso está descrito em o que um administrador deve saber sobre o risco de IA; o que um CIO deve reconhecer nesse inventário está em o que um CIO deve saber sobre o risco de IA.
O que é certo: uma lista de decisões sem ligação a uma reunião existente não é mantida, e uma lista de decisões sem uma visão completa do que está em funcionamento regista apenas uma parte da realidade. O que depende da organização: qual reunião é o ponto de ancoragem indicado, com que frequência essa reunião acontece, e quem tem competência para tomar uma decisão que acaba na lista. Isso varia por setor, por estrutura de governação e por cultura de risco, e por isso não existe um modelo fixo que funcione em todo o lado sem adaptação.
O Responsible AI Scan está em construção. Quem precisar, neste momento, de uma lista de decisões alinhada com a estrutura existente pode inscrever-se na lista de espera; ainda não é oferecido nada que ainda não exista.
Uma lista de decisões diz quem decidiu, não quanto trabalho um sistema efetivamente absorve ou poderia absorver. Para essa questão — que parte de uma tarefa se pode transferir para a IA, e que parte não — é necessário um outro olhar, além daquele que a governação por si só oferece. O werkscan da FTE TO AI calcula, por tarefa, que parte do trabalho pode ser transferida, como complemento à visão que uma lista de decisões e a respetiva estrutura de oversight oferecem.
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.