As organizações pensam muitas vezes que a sua função está fixa: nós somos utilizador, o fornecedor é o fornecedor, ponto final. Essa suposição frequentemente não é correta, ou é correta hoje e deixa de ser amanhã. A função que uma organização tem em relação a um sistema de IA não é uma característica fixa da organização. É um resultado do que acontece com o sistema: quem o cria, quem o adapta, quem o coloca no mercado, e sob que nome. Se um desses fatores mudar, a função também pode mudar, e com isso as obrigações que lhe estão associadas.
Isso torna a classificação algo que não é uma fotografia num único momento. Uma função que foi corretamente determinada no momento da aquisição pode estar incorreta um ano depois, sem que internamente se tenha decidido conscientemente nada.
A classificação depende de um número limitado de fatores, mas esses fatores não estão todos do lado da parte que utiliza o sistema. É relevante, entre outros aspetos, se um sistema foi desenvolvido internamente ou adquirido, se o sistema adquirido é utilizado sem alterações ou é adaptado, e se a adaptação afeta o perfil de risco do sistema. Também é relevante sob que nome um sistema é apresentado externamente: um sistema que é revendido ou desenvolvido posteriormente sob uma marca própria pode implicar uma função diferente do que manter em funcionamento, sem alterações, um produto externo. Para a fronteira exata entre essas duas posições, é relevante a página sobre o que muda quando uma organização adapta ela própria um modelo adquirido, e para a questão básica de qual das duas funções principais se aplica, existe a página que explica de que depende exatamente a escolha entre fornecedor e utilizador.
A classificação não é, portanto, algo que uma organização determina uma vez e depois arquiva. É uma classificação que tem de ser reavaliada sempre que os factos subjacentes mudam.
Se a função mudar, também muda o que se espera de uma organização. Uma parte que é puramente utilizadora tem obrigações diferentes de uma parte que é (co)responsável pela criação de um sistema. Isso não afeta apenas o trabalho administrativo. Afeta também onde, na organização, deve estar a responsabilidade por um sistema, quem reporta sobre ele, e que nível de supervisão é adequado.
Essa alteração tem repercussões na questão de quão significativo um sistema deve ser considerado internamente. Uma alteração de função pode levar a que um sistema anteriormente considerado controlável tenha de ser reavaliado quanto ao seu nível de risco — uma questão tratada separadamente na página sobre o que significa um nível de risco elevado para a organização que utiliza ou fornece o sistema. Inversamente, uma alteração de função também pode fazer com que um sistema passe a ficar fora do âmbito de determinadas obrigações, ou passe a ficar dentro dele. Quais as aplicações que ficam exatamente fora do âmbito e quais não, está explicado na página sobre que tipos de aplicações de IA ficam fora do âmbito das obrigações.
Os fatores que causam uma alteração de função ocorrem, na maioria das vezes, a um nível ao qual a administração, o departamento jurídico ou a gestão de risco não têm visibilidade automática. Uma equipa que faz o afinamento (finetuning) de um modelo adquirido com dados próprios. Um departamento que disponibiliza um produto de chatbot externo aos clientes sob um nome de produto próprio. Uma integração que combina um modelo de um fornecedor com regras próprias e que, em seguida, oferece essa combinação externamente. Nenhum desses passos passa automaticamente por um registo central, e a lista de ferramentas aprovadas do departamento de TI normalmente não regista este tipo de alteração, porque a alteração não é reconhecida como uma "nova aquisição", mas sim como uma adaptação de algo que já tinha sido aprovado.
Esta é a razão pela qual as alterações de função só se tornam visíveis, muitas vezes, quando algo corre mal, ou quando é exigida uma justificação externa. A pergunta "qual é a nossa função relativamente a este sistema" é então respondida com efeitos retroativos, num momento em que a margem para fazer ajustes é menor do que se a pergunta tivesse sido feita mais cedo.
Como a classificação pode mudar, a distinção entre o que exige atenção neste momento e o que deve ser reavaliado a prazo é relevante para o planeamento do trabalho de governança. Nem tudo o que uma alteração de função implica exige ação imediata; parte disso pode ser planeado. Qual parte é essa, e qual parte não pode esperar, é tratado na página sobre o que deve ser tratado agora e o que pode ser planeado para mais tarde. Para um resumo compacto da própria questão da classificação, incluindo os principais pontos de viragem, existe a página que aprofunda as circunstâncias exatas em que uma função muda.
A questão de qual função uma organização tem em relação a um sistema de IA está próxima de outra questão que raramente recebe a mesma atenção: que parte do trabalho efetivo na organização já é realizada por IA, está planeada para o ser, ou já está a ser assumida sem que ninguém o tenha registado. Enquanto a questão da função trata da responsabilidade em relação a um sistema, o scan de trabalho da FTE TO AI trata da própria divisão de tarefas: para cada tarefa, calcula-se que parte pode ser assumida pela IA, independentemente da função que a organização formalmente assume nesse contexto. Estas duas questões estão relacionadas, porque uma alteração na divisão de tarefas é muitas vezes o motivo de uma alteração de função.
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.