Muitas vezes já existe um documento com o título procedimento de escalonamento. Nele consta um esquema com setas, uma lista de nomes, e alguns valores-limite. O problema não é a falta do documento. O problema é que ninguém o abre no momento em que é necessário.
Isso não acontece por falta de vontade. Acontece porque já existe um caminho pelo qual os problemas sobem: o gestor de linha que comunica o incidente de TI, o responsável de compliance que fala com o negócio, o líder de equipa que apresenta o seu problema ao seu próprio superior. Esse caminho existe, é usado diariamente, e funciona — para as coisas para as quais foi concebido. Um novo caminho de escalonamento específico para incidentes de IA torna-se então uma segunda rota ao lado de uma rota que já existe. Em caso de dúvida, todos escolhem a rota que já conhecem.
Um caminho de escalonamento que está desligado da estrutura existente exige do colaborador que primeiro reconheça que algo é um incidente de IA, depois se lembre de que para isso se aplica outro processo, e em seguida se dê ao trabalho de seguir esse processo em vez de simplesmente ligar ao seu superior. Cada passo dessa cadeia é um momento em que o caminho é abandonado.
A isso acresce uma segunda razão, menos visível mas igualmente determinante: quem comunica um desvio não quer ficar imediatamente registado no formulário de incidentes da organização. Se escalar equivaler a ser responsabilizado, não se escala. Isso aplica-se a um colaborador que utilizou uma ferramenta de IA que não tinha sido aprovada, e aplica-se a um gestor que colocou um modelo em funcionamento sem que ninguém soubesse. Um caminho de escalonamento que é efetivamente utilizado é um caminho em que a primeira comunicação não é um julgamento, mas um sinal.
Um caminho de escalonamento que funciona descreve três coisas, e nada mais do que isso.
Quem observa algo — um colaborador, um cliente, uma parte externa — deve saber a quem se pode dirigir sem primeiro ter de averiguar se se trata de uma questão de IA ou de uma questão operacional normal. O caminho articula-se com o ponto de contacto que já existe, com uma ramificação adicional no momento em que se verifica que a IA está envolvida.
Quem toma a decisão — se algo é interrompido, ajustado, ou comunicado a uma autoridade de supervisão — deve estar definido antes de o incidente ocorrer. Não como um título de função abstrato, mas como um nome, com um substituto. Um escalonamento que fica bloqueado por falta de mandato não é escalonamento.
O que acontece depois com quem comunica deve ser claro. Se um segundo processo consistir apenas numa obrigação de comunicação sem clareza sobre as consequências para quem comunica, esse processo é evitado. É precisamente aí que se esconde a IA sombra: não nos sistemas que a TI conhece, mas nas ferramentas que alguém passou a usar sem o comunicar, porque comunicar parecia uma confissão.
A solução não é um documento mais extenso. É um caminho de escalonamento que utiliza a estrutura que já existe — o ponto de contacto, a linha de escalonamento, o comité de risco — e a essa adiciona uma ramificação específica para a IA nos pontos onde faz diferença. A forma exata como essa articulação funciona, também para a política mais ampla e a lista de decisões do órgão de supervisão, está descrita em como obter uma política de IA que é lida porque está incorporada no que já existe e em como obter uma lista de decisões de supervisão que se articula com o ritmo de decisão existente. Ambos os documentos tocam no mesmo ponto: um processo que está ao lado da organização é ignorado; um processo que está incorporado nela é seguido.
Este princípio não se aplica apenas ao escalonamento. Aplica-se a toda a estrutura de governação em torno da IA. Quem quiser saber como isso se apresenta de forma mais ampla — como a classificação de risco se articula com as categorias de risco existentes, como articular com a estrutura de risco existente evita que surja uma burocracia paralela — encontra ali o princípio subjacente. O mesmo se aplica à comunicação ascendente: um relatório ao conselho de administração de uma página só funciona se os escalonamentos nele referidos tiverem sido efetivamente comunicados. E sem observação contínua daquilo que muda, qualquer caminho de escalonamento fica desatualizado dentro de um ano; o que isso significa na prática está explicado em monitorização que produz resultados.
Um caminho de escalonamento só pode ser escrito quando se sabe o que pode escalar. Enquanto ninguém souber que IA está em funcionamento na organização — incluindo o que não foi aprovado — o documento permanece teórico. A Responsible AI Scan não começa, por isso, no caminho de escalonamento, mas no inventário: o que está em funcionamento, quem o utiliza, e que nível de risco lhe corresponde. Só com base nisso é possível escrever um caminho de escalonamento que se articule com o que já existe, em vez de com o que deveria existir no papel.
Os caminhos de escalonamento tratam do que corre mal com a IA que já está em uso. Uma outra questão, igualmente pouco explorada, é onde a IA poderia assumir o próprio trabalho. O werkscan da FTE TO AI calcula, por tarefa, que parte do trabalho é elegível para isso, independentemente de isso já estar a acontecer ou ainda ter de ser organizado.
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.