Um modelo que adquire e utiliza sem alterações é uma situação diferente de um modelo em que faz finetuning, que retreina com dados próprios, ou que combina com outros sistemas. A pergunta associada não é se isso é permitido, mas o que isso altera na sua função. Esta página descreve de que depende essa classificação. O conteúdo regulamentar atual encontra-se noutro lugar; aqui trata-se do mecanismo que determina quando algo muda e o que faz internamente com isso.
Se a alteração de um modelo modifica a sua função depende de vários fatores que deve determinar caso a caso, não de um limite fixo igual para todos os modelos.
Estes fatores funcionam em conjunto. Nenhum destes pontos é decisivo por si só; é a combinação que determina se a alteração modifica a sua posição.
Se a alteração for suficientemente significativa, geralmente não muda apenas a qualificação do modelo, mas também o que se espera da organização: documentação diferente, responsabilidade interna diferente, possivelmente uma parte diferente responsável pelo conjunto. Esse mecanismo, e a distinção entre uma parte que apenas utiliza um modelo e uma parte que também o configura, está desenvolvido na página que descreve a distinção entre fornecedor e utilizador. Quando é que exatamente uma alteração é suficientemente significativa para fazer essa função mudar é uma questão que deve ser respondida separadamente para cada sistema; o mecanismo geral subjacente está descrito na página sobre o momento em que a sua função muda.
As consequências dessa mudança dependem, por sua vez, do nível de risco atribuído ao modelo alterado. Um modelo alterado que se enquadra numa categoria de risco elevado acarreta obrigações diferentes de um modelo alterado que permanece fora dela. O que um nível de risco elevado significa na prática para os processos internos e a supervisão está descrito na página sobre as consequências de um nível de risco elevado para a sua organização. Inversamente, também é possível que uma alteração mantenha precisamente um sistema fora da categoria mais pesada, ou que o âmbito de aplicação simplesmente não seja abrangido pelo regulamento; quais as aplicações que ficam fora do âmbito e porquê está descrito na página sobre as aplicações que ficam fora do âmbito.
As alterações a modelos ocorrem frequentemente perto do trabalho em si: uma equipa que faz o finetuning de um modelo externo com documentos próprios, um desenvolvedor que liga dois sistemas entre si, um departamento que alimenta um chatbot com bases de conhecimento internas. São precisamente essas alterações que não passam por um processo de aquisição centralizado e, por isso, não constam automaticamente numa lista de TI. Quem quiser saber se, e onde, isto acontece dentro da organização, tem de perguntar — e isso só funciona se a pergunta não estiver associada a uma penalização. Uma equipa que alterou um modelo sem pedir autorização para isso não o comunica se a resposta resultar numa sanção.
Como a classificação das alterações não é fixa, mas é determinada caso a caso, não é suficiente determinar uma única vez qual a função de um modelo. As alterações que ocorrem após a avaliação inicial devem passar novamente pelas mesmas perguntas. Uma política que apoie isto deve descrever em linguagem simples quando uma alteração deve ser comunicada e a quem; como é que essa política se mantém legível em vez de ser um texto que ninguém consulta está descrito na página sobre uma política de IA que é efetivamente lida. Além disso, é importante que as decisões sobre alterações — quem deu a aprovação, com base em que avaliação, com que nível de risco como resultado — sejam registadas num local onde possam ser encontradas. Como é que esse registo se apresenta na prática está descrito na página sobre uma lista de decisões de supervisão.
A classificação de um modelo alterado determina quais as obrigações aplicáveis, mas não diz nada sobre o que o modelo faz na prática com o trabalho em si. Para essa questão — que parte de uma tarefa é assumida pela IA, que parte permanece com um colaborador, e o que uma alteração desloca nessa divisão — é necessária uma perspetiva diferente de uma avaliação de risco. O scan de trabalho da FTE TO AI calcula, por tarefa, que parte do trabalho pode ser assumida pela IA, independentemente da questão de quais regras de governação se aplicam ao modelo.
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.