Gere um registo de risco construído em torno de riscos que se deixam identificar, ponderar e atribuir. Risco operacional, risco de crédito, risco de compliance: cada um tem um proprietário, uma medida de controlo, uma linha de reporte. O risco de IA não se encaixa automaticamente nesse padrão, porque o primeiro problema não é a ponderação. O primeiro problema é que não sabe o que está a ponderar. Uma equipa que utiliza um modelo de linguagem para escrever pareceres preliminares, um departamento que subscreveu uma assinatura de IA externa fora do processo de compras de TI, uma macro de folha de cálculo que entretanto se tornou um modelo de previsão: não são casos-limite, é aqui que reside o risco, e não está registado em lado nenhum.
A sua pergunta não é "a IA é arriscada". A sua pergunta é: o que está em funcionamento, quem é responsável por isso, e com base em que informação posso justificar isso perante o conselho e o supervisor. A resposta que não aceita é a garantia sem fundamentação. "Não está a decorrer nada de especial" não é uma resposta a uma questão de risco, é a ausência de uma resposta. Um gestor de risco que transmite isso ao conselho está a transmitir que não se verificou, não que não há nada.
A segunda resposta que não aceita é a lista proveniente da gestão de sistemas de TI como imagem completa. Essa lista mostra o que foi solicitado e aprovado. O uso de IA surge em grande parte precisamente fora desse pedido, porque uma assinatura isolada, uma extensão de browser ou uma funcionalidade incorporada num software existente não são reconhecidas como "novo sistema". Quem quer conhecer o risco não deve, portanto, consultar apenas o panorama dos sistemas, mas as pessoas que fazem o trabalho, e isso exige uma abordagem diferente de uma auditoria de TI.
Como gestor de risco, conhece o padrão de sub-reporte em qualquer tema de risco em que um colaborador tenha algo a perder ao responder com honestidade. O uso de IA é um exemplo flagrante disso: se comunicar uma ferramenta utilizada implicar a revogação do acesso, ninguém mais o comunica. O levantamento que produz resultados é o que pergunta sem associar consequências à resposta. É uma competência diferente daquela que a gestão de risco normalmente exige, e é por isso que um inventário de shadow-AI não é concebido como controlo, mas como sondagem.
Uma vez identificado o uso, o passo seguinte não é avaliar o fornecedor ou o modelo. É avaliar o papel que o sistema desempenha num processo. Uma aplicação de IA que reformula texto acarreta um risco diferente de uma aplicação que pesa numa decisão sobre um cliente, um colaborador ou um investimento. A mesma tecnologia, aplicada num papel diferente, cai numa classe de risco diferente. Essa distinção é exactamente o que um registo de risco necessita para conseguir situar o risco de IA junto dos riscos já lá presentes, sem criar um capítulo de IA separado e isolado que ninguém consulta.
Um gestor de risco não tem interesse num novo framework paralelo ao existente. O interesse está num conjunto de governação que se liga à estrutura de risco já existente: a mesma lógica de propriedade, os mesmos caminhos de escalonamento, o mesmo ciclo de reporte ao conselho. O risco de IA tratado como tema isolado desaparece entre os relatórios regulares. O risco de IA incorporado na taxonomia de risco existente permanece visível no local onde o conselho já olha.
Em algum momento será questionado sobre o que sabe acerca do uso de IA na organização, por um supervisor, um auditor ou o próprio conselho. A resposta que resiste não é "tudo está mapeado", porque isso raramente se consegue garantir num padrão de uso dinâmico. A resposta que resiste é um processo demonstrável: como foi feito o levantamento, que classificação foi aplicada, que acordos de governação daí resultam, e com que frequência isso se repete. É um critério diferente da exaustividade, e é o critério pelo qual a gestão de risco já normalmente é avaliada.
Esta questão não se apresenta de forma idêntica para cada função na organização. O que um responsável de compliance precisa deste levantamento pode ler em o que deve um responsável de compliance saber sobre risco de IA, a questão de direção de quem lidera o programa está em o que deve um líder de programa de IA saber sobre risco de IA, e a forma como este tema chega ao nível do próprio conselho está descrita em o que deve um administrador saber sobre risco de IA. Para a gestão de risco em sectores específicos, com as suas próprias cadeias e formas de supervisão, a perspectiva está ainda mais aprofundada em como é a governação de IA na construção e em como é a governação de IA no sector das instalações técnicas.
O texto das regras em vigor, com as suas definições e prazos precisos, não consta nesta página e é mantido actualizado noutro local. O que aqui se descreve é o mecanismo: como se passa de um padrão de uso desconhecido para um risco classificável e reportável.
Um levantamento de risco de IA traz inevitavelmente também outra coisa à luz: que parte do trabalho já é, de facto, feita por IA, e que parte poderia ser. É uma questão diferente da gestão de risco, mas partilha a mesma origem. O scan de trabalho da FTE TO AI calcula, por tarefa, que parte do trabalho pode ser assumida por IA, ligando-se assim precisamente ao levantamento de que a gestão de risco já necessita.
O Responsible AI Scan está atualmente em desenvolvimento. Quem quiser utilizá-lo assim que estiver disponível pode inscrever-se na lista de espera.
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.