Um líder de programa de IA recebe normalmente um mandato: garantir que a IA seja adotada, que as equipas se tornem mais rápidas com ela, que o programa mostre resultados. Raramente surge um segundo mandato: garantir que tudo o que surge entretanto é responsável. Ainda assim, ele é avaliado por ambos no momento em que algo corre mal. Esse é o cerne do seu risco: é responsável por um programa cujos limites não conhece.
O que ganha com a adoção — processos mais rápidos, equipas satisfeitas, uma narrativa de inovação visível — contrapõe-se ao que perde se algo correr mal: um incidente com uma ferramenta que não constava da sua lista, uma auditoria que faz perguntas às quais não tem resposta, um conselho de administração que questiona por que razão o programa não viu o que já estava em curso. Essa assimetria torna a sua posição vulnerável, mesmo quando o programa em si corre bem.
A sua pergunta não é "que ferramentas de IA aprovámos". Essa lista ele tem, e é frequentemente mais curta do que a realidade. A sua pergunta é: o que estão as equipas a usar que não consta da minha lista, e como torno isso visível sem que as pessoas o escondam. Um líder de programa que quer estimular a adoção não se pode permitir que os utilizadores escondam as suas ferramentas por medo de uma correção. Quem pergunta o que está a ser usado e depois faz disso um problema, deixa de obter resposta na pergunta seguinte. Governação e adoção trabalham aqui uma contra a outra se for abordado de forma errada.
Uma resposta que ele não aceita é um bloqueio único: "O uso de IA não é permitido sem aprovação." Essa resposta satisfaz um auditor por um momento, mas desloca o uso para locais que ninguém vê. É o contrário do que um líder de programa quer alcançar: quer que o uso de IA seja visível e acompanhado, não que se torne clandestino. Uma proibição sem mecanismo para reportar e aprender representa para ele uma perda, mesmo que soe conforme no papel.
Também não aceita uma resposta que trate tudo da mesma forma. Uma ferramenta que resume texto para uso interno não representa o mesmo risco que uma ferramenta que toma decisões automáticas sobre clientes ou colaboradores. Sem distinção por função e nível de risco, um programa não consegue priorizar, e um líder de programa que não consegue priorizar não pode cumprir o seu mandato.
O que funciona é um levantamento que comece pelo que existe, não pelo que foi aprovado. Isso significa fazer perguntas às equipas sobre o que realmente utilizam, e fazê-lo de uma forma que não implique represálias. Só assim a IA-sombra surge à vista — os sistemas introduzidos sem um percurso formal, muitas vezes porque aliviavam o trabalho e ninguém viu razão para esperar por aprovação.
Segue-se depois a classificação: que aplicação toca em clientes, qual afeta apenas o processo interno, qual toma decisões sem um humano no meio. Essa classificação determina onde a supervisão deve ser rigorosa e onde pode permanecer leve. Sem essa classificação, um programa trata tudo com o mesmo grau de rigor ou de leveza, e ambos são um problema: o primeiro atrasa a adoção, o segundo deixa riscos sem controlo.
A estrutura de governação que se segue deve alinhar-se com o que já existe dentro da organização — as comissões de risco existentes, as linhas de reporte existentes — e não um novo circuito paralelo. É também aqui que um líder de programa se distingue de outras funções na organização: um administrador quer saber o que um administrador deve saber sobre o risco de IA ao nível da responsabilidade final, um CIO aborda-o a partir de sistemas e acessos, tal como descrito em o que um CIO deve saber sobre o risco de IA, e um General Counsel olha para a responsabilidade legal e o dever de documentação através de o que um General Counsel deve saber sobre o risco de IA. Um líder de programa deve conseguir atender a essas três perspetivas sem perder a sua própria tarefa — a adoção.
Quais as obrigações concretas que se aplicam a cada categoria de risco, e dentro de que prazos, não é o tema desta página. Esse texto muda, é reforçado e é explicado noutros locais. Aqui trata-se do mecanismo: como um programa ganha visibilidade sobre o que se passa, como traduz isso em níveis de risco, e como o demonstra de forma comprovável ao conselho de administração e à supervisão, independentemente do que o texto exato da regulamentação prescreva num dado momento.
Quando fica claro o que está em curso e quem é responsável por isso, surge uma outra pergunta: o que é que se ganha se esse trabalho for bem organizado. Essa é uma pergunta que deve ser respondida por tarefa, não por organização. O werkscan da FTE TO AI calcula a esse nível qual a parte do trabalho que pode ser assumida pela IA, de modo a que um líder de programa não saiba apenas o que está em jogo, mas também onde acrescentar capacidade faz realmente diferença.
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.