Muitas organizações partem do princípio de que a sua função está fixa: são utilizadoras de um sistema construído por um fornecedor, e as obrigações correspondentes são claras e permanentes. Esse pressuposto está frequentemente correto, mas não sempre. A função que uma organização tem relativamente a um sistema de IA não é um rótulo fixo. É o resultado do que efetivamente acontece com o sistema, e esse resultado pode alterar-se sem que seja assinado um novo contrato ou feita uma nova aquisição.
A classificação de uma função depende de um conjunto de elementos factuais, não de como um fornecedor designa o sistema ou de como um departamento interno o posiciona internamente. É relevante, entre outros aspetos, quem colocou o sistema no mercado, quem efetivamente utiliza o sistema num processo próprio, e quem adaptou o sistema após a entrega. Também conta sob que nome o sistema é apresentado externamente, e se uma organização repassa o sistema a terceiros sem o utilizar ela própria. Estes elementos determinam em conjunto se uma organização atua como fornecedor, como utilizador, ou como parte que se situa numa posição intermédia.
A razão pela qual isto é relevante para a governança é que a função determina que obrigações recaem sobre que parte. Uma organização que é apenas utilizadora tem responsabilidades diferentes de uma organização que, de facto, atua como fornecedor. O que exatamente se espera de cada função está descrito noutro local; aqui trata-se do mecanismo que determina qual a função aplicável, e da identificação do momento em que esse mecanismo produz um resultado diferente do anterior.
Uma função não está ligada a um sistema durante toda a sua vida útil. Está ligada ao que efetivamente acontece num determinado momento. Isto significa que a mesma organização, relativamente ao mesmo sistema, pode assumir funções diferentes em dois momentos distintos. Algumas situações em que isto acontece: uma equipa que faz o ajuste fino (finetuning) de um modelo adquirido com dados próprios, um departamento que reclassifica um sistema e o oferece sob nome próprio a outros departamentos, ou uma organização que repassa a um cliente ou parceiro um sistema originalmente destinado a uso interno. Em cada um destes casos, a função efetiva altera-se, ainda que exteriormente pouco mude.
O que muda na prática não é abstrato. Determina quem é responsável pela documentação, quem deve demonstrar que um sistema faz o que afirma fazer, e quem deve reagir se algo correr mal. Mais informação sobre o que exatamente muda quando um modelo é adaptado encontra-se em a página sobre adaptações a um modelo. Essa alteração é um dos exemplos mais claros de como uma função se altera sem que a preceda uma decisão consciente.
A razão pela qual este tema é relevante não só juridicamente, mas também organizacionalmente, é que uma alteração de função ocorre frequentemente sem ser notada. Uma equipa que adapta um modelo pensa numa melhoria técnica, não numa alteração de responsabilidade. Um departamento que transmite uma ferramenta a outro departamento pensa em conveniência, não numa nova função como fornecedor. Uma governança que olha apenas para o que foi adquirido perde sistematicamente estas alterações.
Isto está relacionado com a questão de saber exatamente que aplicações se enquadram numa determinada regulamentação e quais não se enquadram; essa fronteira é tratada em a página sobre o âmbito de aplicação. Um sistema que estava fora do âmbito quando foi adquirido pode passar a estar dentro do âmbito assim que a função da organização se altera. Isso torna insuficiente avaliar apenas uma vez, no momento da aquisição; a avaliação deve acompanhar o que efetivamente acontece com um sistema.
Também o nível de risco de uma aplicação pode acompanhar uma alteração de função. O que significa exatamente um nível de risco elevado para as obrigações de uma organização, e de que depende isso, está esclarecido em a página sobre as consequências de um nível de risco elevado. Uma organização que, devido a uma alteração de função, passa subitamente a ser considerada fornecedora de um sistema com um nível de risco elevado, assume responsabilidades diferentes das que tinha quando era apenas utilizadora desse mesmo sistema.
Para detetar alterações de função antes de estas se tornarem um problema, uma organização precisa de saber que sistemas existem, quem os adapta, e quem os transmite a quem. Isso exige um inventário que vá além da lista aprovada pelo departamento de TI, e um local fixo onde sejam registadas as decisões sobre adaptação, transmissão e reclassificação. Esse local fixo, e as questões que lhe estão associadas, estão descritos em a página sobre uma lista de decisões de supervisão.
O Responsible AI Scan foi concebido para tornar visíveis estas alterações: que sistemas estão efetivamente em funcionamento, quem os utiliza, quem os adaptou, e que função resulta disso neste momento. A ferramenta que apoia este processo está em desenvolvimento; quem desejar utilizá-la pode inscrever-se na lista de espera.
Uma alteração de função não afeta apenas a governança. Quando um sistema passa de simples ferramenta auxiliar a algo que assume estruturalmente parte de uma tarefa, altera-se também a questão de quanto trabalho esse sistema realmente realiza e quanto ainda recai sobre as pessoas. O werkscan da FTE TO AI calcula, por tarefa, que parte do trabalho pode ser assumida pela IA, tornando assim visível onde uma alteração de função na governança coincide com uma alteração efetiva na distribuição do trabalho.
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.