Uma lista de decisões de supervisão não é um novo formulário nem uma nova reunião. É um local fixo onde se registam qual aplicação de IA foi avaliada, por quem, com base em que avaliação de risco, e com que decisão. Aprovada, reprovada, com condições, ou temporariamente permitida à espera de análise mais aprofundada. Sem essa lista, uma decisão só existe na memória de quem estava presente, e desaparece assim que alguém mude de função ou a conversa não tenha sido registada em ata.
A lista contém, por aplicação, uma breve descrição da tarefa, a classificação por função e nível de risco, o nome do responsável do processo, a data da avaliação, a decisão tomada e a razão dessa decisão. Nenhuma especificação técnica, nenhuma documentação do fornecedor: isso pertence ao dossiê da própria aplicação, não à lista de decisões. A lista é uma visão de conjunto um nível acima — quem decidiu o quê, e quando essa decisão foi confirmada por último. Uma aplicação que foi aprovada há um ano para uma tarefa com risco limitado pode, entretanto, estar a ser usada para outra coisa. Sem confirmação periódica, uma decisão antiga continua a valer para uma situação que já não existe.
A razão pela qual registos de IA autónomos costumam ficar vazios não é falta de vontade, mas sim ordem. Cada organização já tem um local onde os riscos são discutidos e registados: um comité de risco, uma comissão de auditoria, uma reunião de direção com um ponto fixo na agenda sobre risco operacional. Quem, além disso, monta um registo de IA separado, está a pedir às pessoas que mantenham uma segunda administração para algo que, em termos de conteúdo, pertence à primeira. Esse segundo processo perde, estruturalmente, para a urgência do dia a dia. A lista de decisões de supervisão só funciona se estiver integrada no que já existe — como parte fixa de uma reunião já existente, com um lugar fixo na agenda, em vez de uma nova obrigação à parte.
Isso também significa que a lista utiliza a mesma escala e a mesma linguagem que o resto da estrutura de risco. Uma aplicação com um nível de risco elevado recebe o mesmo tipo de atenção que outro dossiê com um nível de risco elevado: frequência de relatório fixa, responsável fixo, linha de escalonamento fixa. A forma como essa ligação se concretiza na prática depende da governação já existente na organização e está descrita na página sobre alinhar com a estrutura de risco existente.
Uma lista de decisões é inútil sem um percurso definido para o que acontece quando alguém não está de acordo, ou quando uma aplicação muda sem que ninguém o comunique. Esse percurso não pertence à própria lista, mas tem de estar alinhado com ela: quem pode contestar uma reprovação, quem deve prorrogar uma autorização temporária, e a quem chega um caso quando o responsável do processo e a função de risco não estão de acordo. A forma como essas linhas funcionam sem que cada pergunta chegue ao topo da organização está descrita em caminhos de escalonamento que funcionam.
A lista de decisões é a memória; além disso, a direção precisa de um resumo que não tenha de ser reconstruído a cada trimestre a partir de atas dispersas. O que deve constar nesse resumo — e o que precisamente não deve, porque já está na lista de decisões — está descrito na página sobre um relatório de direção de uma página. Sem esse passo, a lista de decisões permanece um documento que só os responsáveis do processo leem, enquanto a direção continua legalmente responsável pelo que é decidido.
Registar uma decisão não é o mesmo que saber se a decisão é cumprida. Uma aplicação que foi reprovada pode continuar em uso se ninguém verificar se a reprovação foi efetivamente aplicada. É por essa razão que uma lista de decisões sem seguimento produz pouco resultado: documenta intenções, não comportamento. O que é necessário para verificar se uma decisão de facto se mantém, e que sinais estão associados a isso, está descrito na página sobre monitorização que produz resultados.
Uma lista de decisões só pode conter o que foi comunicado. Quem depende de comunicações através do departamento de TI vê apenas uma fração do que realmente está a ser utilizado: a maior parte do uso de IA numa organização surge fora dos processos formais de aquisição, em equipas que experimentam uma ferramenta porque funciona. Se essas aplicações chegam alguma vez a constar na lista de decisões depende de os colaboradores terem a confiança de dizer o que usam — e isso só acontece se as perguntas sobre o assunto não parecerem uma antecâmara para uma sanção.
A primeira pergunta que ajuda nesse ponto não é 'que IA foi aprovada', mas sim 'que parte deste trabalho já está, na verdade, ou poderia estar, a ser feito por IA'. Esse é um ponto de partida diferente de uma lista de decisões, e mais completo: o werkscan da FTE TO AI calcula, por tarefa, que parte do trabalho pode ser assumida por IA, estabelecendo assim uma base que não depende do que por acaso foi comunicado. A partir desse resultado, torna-se visível quais aplicações já estão realmente em funcionamento antes de a lista de decisões alguma vez ter conhecimento delas.
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.