Um compliance officer não perde na primeira pergunta sobre IA. Perde na segunda: quando se revela que a resposta à primeira pergunta estava incompleta. "Quais sistemas de IA a sua organização utiliza" pode ser respondida com uma lista extraída do portfólio de TI. A pergunta que vem a seguir — "essa é a lista completa" — é a pergunta em que a maioria dos dossiês de compliance naufraga.
Não: quais ferramentas de IA a organização adquiriu. Mas sim: quais sistemas de IA são efetivamente utilizados, por quem, para que decisões, e com base em que avaliação de risco. São quatro perguntas, não uma. A primeira é uma lista de compras. As outras três exigem que as pessoas relatem o que fazem, incluindo o que não submeteram a aprovação. Um compliance officer que só tem a lista de compras tem uma falsa sensação de cobertura — e isso é mais arriscado do que nenhuma cobertura, porque é reportado como completo.
Os colaboradores que usam uma ferramenta de linguagem ou análise sem a adquirir através da TI não deixam rasto disso num registo de ativos. Deixam, sim, rasto naquilo que produzem: relatórios, comunicação com clientes, pareceres. A lacuna entre o que está registado e o que é utilizado normalmente não é uma violação intencional. É o resultado de uma organização que encontra uma ferramenta mais rapidamente do que percorre um processo de aprovação. O compliance não consegue colmatar essa lacuna com uma proibição mais estrita — isso apenas empurra o uso ainda mais para fora da vista. Colmata-se a lacuna perguntando, sem que haja uma sanção associada à resposta. Quem teme uma anotação no seu dossiê não conta o que usa; conta o que pensa que o senhor quer ouvir.
Um gestor de risco quer saber qual é a dimensão da exposição. Um compliance officer quer isso, mais algo adicional: consigo demonstrar que seguimos o processo, mesmo que o resultado se revele discutível mais tarde. Esse é um tipo diferente de prova. Não se trata apenas da classificação de um sistema, mas do rasto: quem avaliou isto, em que momento, com que informação, e se essa avaliação foi repetida quando o sistema mudou. Os sistemas de IA são atualizados sem aviso; uma classificação de há seis meses diz pouco sobre o sistema de hoje. O compliance deve, portanto, conseguir mostrar não só um resultado, mas um processo que continua em funcionamento.
"Temos uma política de IA" não é resposta à pergunta de saber se essa política cobre algo. Um documento de política que nunca foi confrontado com o que realmente é utilizado é uma declaração de intenção, não uma declaração de situação. O que um compliance officer precisa é de um inventário que se alinhe com as categorias de risco existentes — a mesma classificação já utilizada para outros riscos operacionais — de modo a que a IA não fique como um tema separado e exótico ao lado do restante quadro de risco, mas integrado nele.
O compliance officer raramente trabalha isto sozinho. A pergunta sobre quais sistemas são considerados de alto risco e que prova disso é exigida está relacionada com o que um General Counsel deve saber sobre risco de IA, a partir da perspetiva de responsabilidade e obrigações contratuais. A pergunta sobre se a organização consegue tecnicamente rastrear quais sistemas estão em funcionamento está a cargo do que um CIO deve saber sobre risco de IA. E a pergunta sobre se este tema chega à mesa da administração antes de escalar pertence ao que um administrador deve saber sobre risco de IA. O compliance é muitas vezes a parte que tem de reunir estas três linhas sem ser proprietário da tecnologia ou do contrato.
O conteúdo regulamentar — quais obrigações se aplicam exatamente, por categoria de risco, com que prazos — encontra-se noutro lugar e muda. Esta página descreve o mecanismo: como saber o que está em funcionamento, como classificar isso, e como demonstrar que o processo foi seguido. Um compliance officer à procura do texto legal atual não o encontrará aqui.
A quantidade de IA-sombra que uma organização tem depende do setor, da cultura e do rigor com que proibições anteriores foram aplicadas. Uma proibição mais estrita correlaciona-se frequentemente com mais uso oculto, não com menos. Este padrão não é igual em todo o lado: na construção civil o foco recai sobre o cálculo de projetos e o planeamento, enquanto no setor das instalações técnicas trata-se mais frequentemente de diagnóstico de manutenção e análise de avarias. O levantamento deve, portanto, ser feito por organização; uma média nacional diz pouco sobre a sua própria exposição.
A Responsible AI Scan mapeia o que é efetivamente utilizado, classifica isso por função e nível de risco, e entrega um conjunto de governança que se alinha com a estrutura de risco existente — sem, com isso, antecipar o que já esteja definido noutro lugar. Este scan está em desenvolvimento. Quem tiver interesse nisto pode inscrever-se na lista de espera; não é oferecido nada que ainda não esteja concluído.
Quem uma vez sabe quais sistemas de IA estão em funcionamento, depara-se muitas vezes com a pergunta seguinte: o que significa isso para a composição do quadro de pessoal e a divisão de tarefas. Esse é um cálculo diferente da classificação de risco, e é esse que a FTE TO AI faz com a werkscan, que calcula por tarefa qual a parte do trabalho que pode ser assumida pela IA.
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.