Um sistema de alto risco não é um modelo de alto risco

O risco não vive dentro de um modelo como um rótulo de aviso. Emerge do propósito pretendido, da implementação, da autoridade, das interfaces e das pessoas...

Um sistema de alto risco não é um modelo de alto risco

The label is attached to a use, not a box

A model can be copied from one server to another without learning a thing. Its weights, code and advertised capabilities may be unchanged. Yet the question Europe asks of the thing around it can change completely. What is it for? Who uses it? Whose position can it alter? Which record enters the workflow? Who can question the answer, correct it, stop it or discover later why it was followed?

This is not an attempt to make a simple subject grander than it is. It is the ordinary difference between a component and a system. A brake disc is not a road vehicle. A spreadsheet formula is not a tax decision. A general-purpose AI model is not, by itself, every AI system that may later be built around it. The distinction is easy to nod at and remarkably easy to lose once a procurement meeting begins speaking about a model as though it already contains the whole future deployment.

The EU Artificial Intelligence Act keeps the distinction in view. It defines an AI system and separately defines a general-purpose AI model. Its high-risk rules concern AI systems in particular circumstances, including systems that are safety components of regulated products and systems used in listed areas. The Act also makes intended purpose central to the classification and documentation of an AI system. It does not invite a team to point at a model name, attach a red, amber or green label and declare the work done.

That should be liberating as well as demanding. A model does not carry a permanent moral horoscope. A careful analysis can be narrow where the intended purpose is narrow, and it can become serious where authority, exposure and consequence become serious. The catch is that the analysis must follow the actual system. Not the demo. Not the supplier deck. Not the harmless task that opened the project six months ago. The system that will receive inputs, make outputs available, shape a decision and be operated on an ordinary Tuesday.

Consider a deliberately hypothetical illustration. The same language model is connected first to an internal knowledge search tool. It retrieves policy passages for a trained colleague, who can open the original source and write their own response. Later, an organisation connects the model to an intake form, gives its recommendation a place at the top of a case record, applies a timer to the case, and makes acceptance of the recommendation the quickest way to clear the queue. No fictional council, patient, employee or incident is needed to see the change. The model may be identical. The role of the output, the data path, the incentive, the affected person and the practical authority of the interface are not.

That is the article's argument: a high-risk system is not a high-risk model. A model may be an important part of the system and may have duties of its own. But the risk analysis becomes meaningful only when it reaches intended purpose, deployment context, users, affected people and downstream integration. Those details are not paperwork attached after engineering. They are the circumstances that give an output institutional force.

Passe o cursor ou selecione uma camada. O modelo é uma camada; a consequência só aparece quando as camadas se encontram.

A Europa usa deliberadamente dois substantivos diferentes

A distinção começa nas definições do Regulamento. Um sistema de IA é um sistema baseado em máquinas concebido para funcionar com vários níveis de autonomia e que pode apresentar adaptabilidade após a sua colocação no mercado, que infere, a partir dos dados recebidos, como gerar resultados como previsões, conteúdos, recomendações ou decisões que podem influenciar ambientes físicos ou virtuais. Um modelo de IA de finalidade geral é diferente: é um modelo de IA capaz de executar competentemente uma vasta gama de tarefas distintas, esteja ou não colocado no mercado, e pode ser integrado numa variedade de sistemas ou aplicações a jusante.

Estas definições sobrepõem-se na conversa quotidiana porque a mesma palavra, IA, faz uma grande quantidade de trabalho não remunerado. Não se devem sobrepor numa avaliação. Um modelo de finalidade geral é feito para viajar. Os seus usos possíveis são deliberadamente amplos. Um sistema de IA é o arranjo operacional através do qual os resultados influenciam um ambiente. Tem um propósito, uma configuração, uma interface e um contexto. Pode incluir um modelo, vários modelos, regras determinísticas, bases de dados, sensores, pessoas, procedimentos e muitas pequenas decisões que ninguém chama inteligência artificial até falharem.

É por isso que um fornecedor de um modelo de IA de finalidade geral e um fornecedor ou utilizador de um sistema de IA não podem simplesmente trocar listas de verificação. A orientação da Comissão sobre modelos de IA de finalidade geral afirma que os fornecedores de modelos devem disponibilizar informações e documentação aos fornecedores de sistemas de IA a jusante, para que esses fornecedores possam compreender as capacidades e limitações do modelo e cumprir as suas próprias obrigações. Esta frase é mais interessante do que parece à primeira vista. Pressupõe que o fornecedor a jusante tem um trabalho que não pode ser concluído pelo fornecedor do modelo. A documentação do modelo viaja, mas não termina a viagem.

Há aqui uma humildade prática. Um fornecedor de modelos pode descrever a arquitetura, o processo de treino, a avaliação, as tarefas pretendidas, os requisitos de integração, as entradas e saídas, as limitações e as condições conhecidas. Uma equipa a jusante sabe se um utilizador é um especialista treinado, se uma pessoa afetada pode contestar um resultado, se uma recomendação é consultiva no nome mas vinculativa na prática, se uma chamada a um serviço externo altera um registo e se uma ação defeituosa pode ser revertida. Nenhuma das partes tem, sozinha, uma imagem completa.

A divisão não é uma lacuna. É um mapa de responsabilidades. Diz que um sistema não pode ser governado pedindo ao fornecedor do modelo que prometa controlo sobre uma implementação que não opera nem vê. Diz também que um integrador não pode alegar ignorância quando a documentação torna visível uma limitação importante. O objetivo não é fazer uma entrega limpa entre entidades jurídicas. É evitar perder a questão no espaço entre elas.

Há uma segunda distinção que vale a pena manter ao lado da primeira. Uma classificação de risco elevado não equivale por si só a uma autorização, a uma garantia de segurança, de equidade ou de legalidade. No parecer conjunto sobre a proposta original da Comissão, o Comité Europeu para a Proteção de Dados e a Autoridade Europeia para a Proteção de Dados sublinharam que a classificação como risco elevado não significava necessariamente que um sistema fosse legal enquanto tal ou que pudesse ser utilizado pelo seu utilizador enquanto tal. O ato final alterou o panorama jurídico desde esse parecer, mas o alerta subjacente continua a ser útil. A classificação é uma condição regulamentar. Não é um recibo que dispense a instituição de continuar a pensar.

Isto é importante porque um rótulo de risco elevado pode dar origem a dois erros opostos. Uma equipa pode tratá-lo como uma mancha permanente num modelo e decidir que a solução é simplesmente não olhar mais para o assunto. Outra pode tratar um processo de conformidade concluído como uma autorização para qualquer contexto posterior. Ambas as abordagens substituem um rótulo por um argumento. A Europa escolheu uma abordagem mais incómoda: identificar o sistema, a sua finalidade e o seu papel, e depois examinar os riscos e as obrigações relevantes ao longo do seu ciclo de vida.

A finalidade prevista é o ponto de partida da análise

A finalidade prevista parece modesta, quase burocrática. Não é. O ato define-a como a utilização para a qual um sistema de IA é previsto pelo seu fornecedor, incluindo o contexto e as condições de utilização específicos indicados nas informações fornecidas pelo fornecedor. Por outras palavras, a finalidade não é um slogan numa página de produto. Inclui o contexto e as condições em que o fornecedor afirma que o sistema deve ser utilizado. Uma declaração de finalidade útil tem limites. Diz o que o sistema faz, para quem, com que dados de entrada, em que fluxo de trabalho e onde termina a sua autoridade.

Comparem-se duas descrições. A primeira diz que um sistema utiliza IA para ajudar as organizações a tomar melhores decisões. É suficientemente ampla para caber num pano de fundo de conferência e demasiado ampla para funcionar. A segunda diz que um sistema apresenta resumos preliminares com indicação das fontes de um processo existente a revisores formados; não pode tomar, transmitir ou executar uma decisão; o revisor deve verificar as fontes citadas antes de utilizar um resumo; e a função não está disponível para categorias que exigem um processo legal separado. A segunda descrição é menos entusiasmante. É também algo com que um engenheiro, um responsável de aquisições, um colega de conformidade e uma pessoa afetada podem discordar em termos concretos.

A finalidade não tem de ser uma frase única. Num sistema sério, é normalmente um pacote compacto: tarefa, resultado, utilizador, população afetada, contexto, autoridade, exclusões, dependências e condições. Os requisitos de documentação técnica do ato deixam espaço precisamente para este tipo de descrição. O anexo IV pede uma descrição geral do sistema de IA, incluindo a finalidade prevista, as pessoas e os grupos em que se prevê que seja utilizado e as versões ou formas específicas em que é colocado no mercado. Pede também descrições da arquitetura do sistema, dos requisitos de dados, das medidas de supervisão humana, da monitorização do ciclo de vida e das medidas de gestão de riscos. A documentação tem esta amplitude porque um cartão de modelo, por si só, não consegue descrever uma implementação.

A finalidade é também o ponto onde uma equipa descobre que tem estado a descrever uma ambição em vez de uma operação. «Vamos apoiar os gestores de processos» pode esconder uma dúzia de disposições diferentes. A ferramenta pesquisa documentos, organiza o trabalho, redige uma resposta, recomenda uma categoria, rejeita um pedido, escalona um alerta, define uma prioridade ou chama outro serviço? O colega utiliza-a antes ou depois de formar uma opinião independente? O resultado é uma sugestão num painel lateral ou um campo que tem de ser preenchido antes de o processo poder avançar? O efeito é imediato, diferido, reversível ou difícil de detetar? A resposta altera o sistema, mesmo quando a interface do utilizador parece familiar.

A finalidade declarada de um fornecedor não pode fazer desaparecer a realidade. Uma equipa não pode atribuir a um sistema uma ampla autoridade prática, descrevê-lo como um assistente inofensivo e esperar que a descrição resolva a questão. Mas uma finalidade devidamente delimitada continua a ser um controlo. Diz aos utilizadores que provas foram consideradas, diz aos integradores o que não devem alargar levianamente e diz aos revisores que alteração reabriria a avaliação. Uma finalidade vaga transforma cada questão posterior numa discussão sobre o que se pretendia dizer. Uma finalidade delimitada permite que uma organização pergunte se ainda está a fazer aquilo que aprovou.

Isto torna-se particularmente importante quando uma organização faz uma modificação substancial. O Regulamento contém regras sobre os casos em que um distribuidor, importador, utilizador final ou outro terceiro pode tornar-se fornecedor, incluindo quando coloca um sistema no mercado sob o seu próprio nome, faz uma modificação substancial ou altera a finalidade pretendida de forma a tornar o sistema de risco elevado. A aplicação jurídica exata depende dos factos e deve ser verificada no contexto. A lição operacional é mais simples: uma alteração de integração pode ser um evento de governação. Mover um resultado do modelo de um painel de rascunho para uma fila de decisão pode ser, ao mesmo tempo, uma alteração de produto, uma alteração de fluxo de trabalho e uma alteração de responsabilização.

O contexto não é cenário

O contexto de implementação é muitas vezes tratado como a parte que chega depois do trabalho real: uma lista de países, uma escolha de alojamento, algumas personas de utilizador, talvez um diagrama com setas que conduzem obedientemente da esquerda para a direita. Mas o contexto dá forma ao risco. O mesmo tipo de resultado pode ser inconveniente num ambiente e consequente noutro. Uma conclusão errada numa ferramenta de escrita pode ser corrigida na frase seguinte. Uma prioridade errada num fluxo de trabalho de serviço escasso pode decidir qual o ficheiro que uma pessoa vê primeiro. Uma pontuação que parece ser um contributo entre muitos pode tornar-se decisiva se todos os outros contributos forem lentos, vagos ou estiverem escondidos atrás de outra equipa.

A abordagem de risco elevado do Regulamento reflete isto. O artigo 6.º liga a classificação de risco elevado a sistemas destinados a ser utilizados como componentes de segurança de determinados produtos, ou a sistemas referidos no anexo III. O anexo III enumera áreas em que os sistemas de IA podem ser de risco elevado por se destinarem a utilizações específicas, como determinadas utilizações biométricas, infraestruturas críticas, educação e formação profissional, emprego, acesso a serviços e benefícios essenciais privados e públicos, aplicação da lei, migração e controlo das fronteiras, e administração da justiça e processos democráticos. O pormenor jurídico importa, mas também importa a gramática. Não diz que um artefacto técnico é de risco elevado em abstrato. Diz repetidamente destinado a ser utilizado.

O artigo 6.º contém também uma qualificação para determinados sistemas do anexo III: não devem ser considerados de risco elevado quando não apresentam um risco significativo de danos para a saúde, a segurança ou os direitos fundamentais das pessoas singulares, incluindo por não influenciarem materialmente o resultado da tomada de decisões. Os fornecedores devem documentar essa avaliação antes de colocarem o sistema no mercado ou de o colocarem em serviço. Isto não é um cartão de isenção geral. É um lembrete de que o efeito real do sistema importa. Uma análise útil tem detalhe suficiente para explicar por que razão um sistema influencia, ou não, materialmente um resultado. Se essa explicação não puder ser escrita sem generalizações vagas, a equipa aprendeu algo antes do lançamento.

O contexto inclui o tempo. Uma recomendação no início de uma investigação ampla tem um efeito diferente de uma recomendação no ponto em que uma pessoa tem uma única oportunidade de fornecer material em falta. Inclui o volume. Um revisor individual pode contestar um resultado quando chegam cinco casos por dia e segui-lo por defeito quando chegam quinhentos antes do almoço. Inclui a língua. Um revisor que consegue ler as provas na sua própria língua de trabalho pode exercer um tipo de supervisão diferente daquele de um revisor que recebe um resumo assertivo de material que não consegue inspecionar de forma independente. Inclui o procedimento local, os direitos de recurso, o pessoal, o acesso a um especialista, a disponibilidade de uma alternativa e se um resultado chega a uma pessoa com autoridade suficiente para fazer algo útil.

Nada disto exige que um desastre inventado seja verdadeiro. É simplesmente assim que os sistemas funcionam. Uma política formal pode dizer humano no circuito, mas o sistema pode ainda assim ser funcionalmente automático se a pessoa não tiver tempo, informação, autoridade ou via prática para discordar. O artigo 14.º do diploma fala, portanto, de supervisão humana efetiva adequada aos riscos, ao nível de autonomia e ao contexto de utilização. Exige que os sistemas de alto risco sejam concebidos e desenvolvidos de modo a que as pessoas possam compreender as capacidades e limitações relevantes, permanecer conscientes da tendência para confiar automaticamente no resultado, interpretar corretamente o resultado, decidir não o utilizar, anulá-lo ou revertê-lo e parar o sistema em segurança quando adequado. São questões operacionais. Não podem ser respondidas apenas com base num benchmark de modelo.

Selecione uma postura de implementação. O modelo mantém-se; a fronteira do sistema, a autoridade e as provas necessárias não.

Os utilizadores fazem parte da superfície de controlo

É tentador falar dos utilizadores como se estivessem fora do sistema, com um teclado na mão e a tratar da parte humana. Eles fazem parte do acordo operacional. O seu conhecimento, carga de trabalho, autoridade, incentivos e vias de ajuda determinam o que o resultado faz. Um sistema concebido para um especialista que consegue inspecionar material de origem não é automaticamente adequado para um generalista que se espera que trabalhe a um ritmo acelerado. Uma ferramenta útil para um revisor que pode rejeitar uma recomendação não é automaticamente adequada para um colega que só pode clicar em aprovar ou esperar por outra pessoa.

Isto não significa que o utilizador tenha de questionar todos os componentes de cada vez. Essa seria uma definição estranha de tecnologia útil. Significa que a supervisão deve ser concebida como uma tarefa real. A pessoa precisa de saber quando o sistema está a ser utilizado, qual é a limitação relevante, que provas estão disponíveis, que tipo de discordância pode registar e o que acontece depois de a registar. Precisa de autoridade que corresponda à responsabilidade. Pedir a alguém que supervisione um resultado que não pode pausar, corrigir ou encaminhar é menos supervisão humana e mais decoração humana.

O Regulamento atribui aqui um papel aos utilizadores profissionais. O artigo 26.º exige que os utilizadores profissionais de sistemas de alto risco adotem medidas técnicas e organizativas adequadas para garantir que utilizam os sistemas em conformidade com as instruções que os acompanham. Pede-lhes que atribuam a supervisão humana a pessoas singulares com a competência, a formação e a autoridade necessárias e que acompanhem o funcionamento com base nas instruções. Em determinados casos, exige também que mantenham sob o seu controlo os registos gerados automaticamente. Não se trata de pedir que uma pessoa competente fique por perto caso a interface fique nervosa. É uma exigência para organizar uma prática de trabalho.

A formação é muitas vezes apresentada como a resposta completa. Não é. A formação pode ajudar uma pessoa a reconhecer uma limitação, mas não pode criar um registo de origem que a interface esconde. Não pode criar o tempo que um design de fila consome. Não pode criar a autoridade que um contrato reserva para outra parte. Não pode reparar uma integração que converte uma recomendação cautelosa numa ação irreversível. Uma organização deve formar as pessoas, claro. Deve também tornar possível, no sistema que efetivamente lhes é dado, a tarefa para a qual estão a ser formadas.

Existe um teste útil: descreva a ação do utilizador sem usar o verbo rever. O que leem? Que comparação podem fazer? O que podem recusar? Para onde vai a justificação? Quem a vê? O que acontece à recomendação depois da rejeição? A pessoa afetada pelo resultado pode perguntar o que aconteceu? Um colega posterior pode reconstruir o estado relevante? Se as respostas continuarem genéricas, o design de supervisão provavelmente também é genérico.

Esse teste aplica-se para além dos sistemas de alto risco. A lei tem um âmbito e prazos específicos; um bom juízo operacional não espera por um rótulo de categoria antes de perguntar se uma pessoa foi colocada num papel performativo. É perfeitamente possível construir uma ferramenta de baixa consequência que torna as pessoas menos capazes de pensar sobre o seu próprio trabalho porque o resultado é demasiado fluido para ser questionado. Também é possível construir uma ferramenta limitada que aumenta a capacidade de uma pessoa fazer boas perguntas porque preserva as provas, limita a sua autoridade e torna a incerteza visível. O modelo pode contribuir para qualquer um dos resultados. O sistema decide qual dos resultados tem lugar para acontecer.

As pessoas afetadas estão fora da consola

Muitas das pessoas mais importantes num sistema de IA nunca o tocam. Podem ser um candidato, aluno, trabalhador, paciente, passageiro, residente, cliente, requerente, mutuário, testemunha ou membro do público. Podem não saber que um modelo esteve envolvido. Podem apenas experienciar uma resposta que chega rapidamente, um pedido que é adiado, um serviço que fica indisponível, uma prioridade que muda ou uma decisão que parece impossível de compreender. A sua ausência da interface não os torna ausentes do sistema.

Esta é uma das razões pelas quais o enquadramento de risco do Regulamento se refere à saúde, à segurança e aos direitos fundamentais. Dirige a atenção para consequências que não podem ser reduzidas a saber se um colega com sessão iniciada gostou da ferramenta. É também a razão pela qual uma declaração de finalidade deve nomear as pessoas e os grupos sobre os quais se pretende que o sistema seja utilizado, como exige o anexo IV. Um sistema construído em torno de uma categoria chamada utilizador pode esconder silenciosamente a diferença entre a pessoa que opera a interface e a pessoa que vive com o resultado.

As pessoas afetadas mudam as perguntas que uma equipa precisa de fazer. Haverá forma de saber que o sistema teve um papel significativo? A decisão baseia-se em informação que pode ser corrigida? Uma língua, uma deficiência, um dispositivo, uma localização ou um estatuto administrativo dificultam a participação? A equipa operacional recebe sinais das pessoas afetadas, ou apenas do painel de controlo? Uma correção chega aos dados, à recomendação, à decisão e a qualquer cópia a jusante que nela se baseou? Estas perguntas não são um pedido para transformar todos os sistemas numa consulta pública. São um pedido para seguir a consequência até ao ponto em que se vê a pessoa do outro lado.

A lei de proteção de dados é relevante quando há tratamento de dados pessoais, a par do enquadramento do Regulamento IA. O CEPD e a AEPD deixaram esse ponto claro no seu parecer conjunto de 2021 sobre a proposta: a lei da UE em vigor em matéria de proteção de dados aplica-se ao tratamento de dados pessoais no âmbito da proposta. A análise jurídica exata dependerá do tratamento e dos intervenientes envolvidos. A lição de governação é simples. Um exercício de classificação não pode absorver todas as outras obrigações. A privacidade, a não discriminação, os deveres setoriais, os requisitos de direito administrativo, as regras de defesa do consumidor e os compromissos contratuais não desaparecem porque uma equipa elaborou um registo de riscos de boa aparência.

Há também uma questão básica de legibilidade. Uma pessoa não precisa de se tornar especialista em aprendizagem automática para perceber como pedir uma correção. Mas um sistema não pode usar a complexidade técnica como razão para tornar a correção impossível. Um bom percurso distingue o que o sistema registou, o que um humano decidiu, que provas foram consideradas, o que permanece incerto e o que ainda pode ser alterado. Não reivindica uma precisão que os registos não sustentam. Nesta área, a honestidade não é apenas um tom de voz. Faz parte do serviço.

A integração é onde as responsabilidades mudam de mãos

As equipas desenham por vezes uma arquitetura de IA como uma cadeia arrumada: modelo, instrução, resposta, utilizador. As implementações reais assemelham-se mais a um mapa municipal depois de alguém se lembrar das condutas de serviço. Há sistemas de identidade, armazenamentos de recuperação, permissões de ferramentas, filas, esquemas, caches, plataformas de observabilidade, extensões de navegador, tarefas em lote, regras de aprovação, definições de retenção, fornecedores e pessoas que herdam uma tarefa porque a anterior saiu de férias. O modelo é importante. Raramente está sozinho.

Cada integração pode alterar o que o sistema é capaz de fazer e como um erro se propaga. A recuperação pode fazer com que um resultado do modelo pareça fundamentado quando a fonte está desatualizada, incompleta ou com um âmbito errado. Uma chamada de ferramenta pode transformar um rascunho numa alteração de estado. Uma fila pode transformar uma recomendação atempada numa tardia. Uma camada de orquestração pode selecionar um modelo ou uma versão de instrução diferente. Uma interface de utilizador pode ocultar incerteza que existe numa camada inferior. Uma integração de identidade pode dar a uma ferramenta útil acesso a material que um utilizador não conseguiria abrir de outra forma. Nenhuma destas observações acusa um produto ou organização específicos. Descrevem propriedades comuns dos sistemas, o que é precisamente a razão pela qual devem ser documentadas antes de se tornarem surpreendentes.

A orientação da Comissão sobre modelos de IA de finalidade geral é útil aqui porque coloca a informação no ponto de transição. A documentação para fornecedores a jusante destina-se a ajudá-los a compreender as capacidades e limitações do modelo, as tarefas previstas, os requisitos técnicos de integração, as especificações de entrada e saída e as informações sobre os dados de treino. Essa informação é necessária. Não é suficiente. As equipas a jusante têm ainda de decidir como o modelo é instruído, se um resultado é apresentado com provas, que permissões de ferramentas são permitidas, como uma alteração é testada, que registos são conservados e se uma recomendação pode influenciar um fluxo de trabalho específico.

É por isto que a compra de um serviço de modelo não é a compra de uma postura de risco completa. A documentação do fornecedor pode dizer a uma equipa que um modelo tem uma limitação conhecida ou que foi avaliado em determinadas condições. Não pode provar que o índice de recuperação do comprador está atualizado, que o pessoal do comprador tem a autoridade necessária, ou que uma pessoa afetada tem acesso a uma via de contestação. Inversamente, o comprador não pode exigir que um fornecedor de modelos tenha conhecimento de todas as políticas locais ou processos a jusante. A atitude responsável não é fingir que um dos lados pode conhecer todo o sistema. É tornar o limite explícito e manter as provas a circular através dele.

O artigo 25.º fornece um marcador jurídico útil para esta realidade operacional. Estabelece as circunstâncias em que uma parte que não seja o fornecedor original é considerada fornecedora de um sistema de IA de alto risco. Estas incluem a colocação do sistema no mercado sob o nome ou marca dessa parte, a realização de uma modificação substancial, ou a alteração da finalidade prevista de forma a tornar o sistema de alto risco. A disposição é técnica e dependente dos factos; ninguém deve auto-classificar-se a partir de uma publicação num blogue. Mas a sua direção é clara. A integração e a reorientação podem mudar quem assume as obrigações de fornecedor. Um acordo a jusante não é para sempre a jusante apenas porque o modelo original veio de outro lugar.

Há uma razão institucional para levar isto a sério. Quando a responsabilidade muda silenciosamente, a segurança e a reparação tornam-se um jogo de pingue-pongue organizacional. O fornecedor do modelo aponta para a implementação. Quem implementa aponta para o modelo. O integrador aponta para o serviço em nuvem. O proprietário do serviço aponta para uma configuração que já não existe. As pessoas afetadas recebem uma explicação polida sobre como tudo é complexo. Isso pode ser exato, mas não é uma resposta. O sistema precisa de um registo de qual organização detém a questão em cada limite, e de uma via para a questão viajar quando a resposta está noutro lugar.

A documentação deve descrever um sistema que ainda pode mudar

A documentação técnica tem a reputação de chegar no fim de um projeto com um ligeiro cheiro a pânico. O Regulamento descreve um papel diferente. Para sistemas de alto risco, a documentação técnica deve ser elaborada antes de o sistema ser colocado no mercado ou colocado em serviço e mantida atualizada. A lista do anexo IV vai além do comportamento do modelo para incluir a finalidade prevista, versões, arquitetura do sistema, desenvolvimento, requisitos de dados, validação e testes, supervisão humana, medidas de exatidão e cibersegurança, gestão de riscos, alterações e monitorização pós-comercialização. Isto não é um anexo decorativo. É uma tentativa de preservar memória suficiente para que alguém possa inspecionar o sistema depois de a reunião de lançamento se ter tornado folclore.

A documentação só funciona quando consegue mostrar relações. Uma versão do modelo deve estar ligada à versão do sistema que a utilizou. Um teste deve estar ligado às suas condições de entrada e à sua finalidade. Uma política deve estar ligada a um ponto de aplicação. Uma função de utilizador deve estar ligada à autoridade que tem na interface. Uma política de registo deve estar ligada ao evento que pode reconstruir. Uma alteração deve estar ligada à avaliação que desencadeou. Caso contrário, uma equipa tem uma biblioteca de bons documentos e nenhuma forma de responder a uma pergunta específica.

Os registos são um caso semelhante. O artigo 12.º exige que os sistemas de IA de alto risco disponham de capacidades técnicas para o registo automático de eventos ao longo do ciclo de vida do sistema, de forma proporcional à finalidade prevista. Os registos podem apoiar a rastreabilidade, a monitorização pós-comercialização e a monitorização operacional. Não explicam uma decisão por magia. Um registo pode dizer a um investigador posterior que uma ferramenta foi chamada, que uma versão estava ativa ou que um revisor clicou num controlo. Não pode, por si só, estabelecer se o revisor compreendeu as provas, se a fonte de entrada era fiável ou se um processo foi justo. Os registos são valiosos porque dão a uma investigação um ponto de partida honesto, não porque eliminam a necessidade de juízo.

A monitorização pós-comercialização completa o quadro. O artigo 72.º exige que os fornecedores de sistemas de alto risco estabeleçam e documentem um sistema de monitorização pós-comercialização de forma proporcional à natureza das tecnologias e aos riscos do sistema de IA de alto risco. Isto tem uma implicação simples para as equipas de implementação: uma versão não é o momento em que o sistema se torna totalmente conhecido. A organização precisa de uma forma de receber informação relevante, distinguir um sinal de uma conclusão, decidir se o limite da finalidade prevista se mantém e fazer uma alteração ou interromper uma utilização quando as provas o exigirem.

Esse trabalho não é glamoroso. Parece-se com identificadores de versão, critérios de versão claros, um registo de dependências, um teste para uma via de reversão, um responsável nomeado para uma limitação e uma decisão que permanece visível depois de a pessoa que a tomou mudar de funções. Parece-se com perguntar se uma integração mudou antes de perguntar se o modelo mudou. Parece-se com reter provas suficientes para corrigir uma consequência, em vez de apenas explicá-la a posteriori. Aborrecido não é o oposto de ambicioso aqui. É a parte que faz a ambição caber dentro de uma instituição.

Como raciocinar sobre todo o sistema sem fingir certeza

Uma análise completa não é uma busca por uma pontuação de risco universal. É uma sequência de perguntas que se torna mais exata à medida que um desenho se torna mais exato. A primeira pergunta é a finalidade: o que se pretende que este sistema faça e o que se pretende especificamente que não faça? A segunda é a consequência: quem pode ser afetado, como e através de que decisão ou serviço? A terceira é a autoridade: que resultado pode alterar um estado, influenciar uma decisão, definir uma prioridade ou mudar o que uma pessoa recebe? A quarta é a prova: o que sustenta a utilização do sistema neste contexto e que condições fazem essa prova viajar?

Depois vêm as perguntas desconfortáveis. O que acontece quando o modelo está incerto, errado, indisponível ou é utilizado fora do seu limite declarado? O que muda quando uma fonte está desatualizada ou uma ferramenta é negada? E se um utilizador estiver com pressa, for novo na função ou não puder inspecionar o material subjacente? E se uma pessoa afetada pedir uma correção? E se uma atualização mudar um prompt, um corpus de recuperação, uma predefinição de interface, uma versão do modelo ou uma permissão de função? A resposta é por vezes um controlo técnico, por vezes um procedimento, por vezes uma utilização mais limitada, por vezes um responsável diferente e por vezes uma decisão de não implementar. Uma governação que nunca permite esta última resposta é apenas aprovação com um casaco mais bonito.

Ajuda manter várias afirmações separadas. Um facto confirmado diz o que o fornecedor do modelo documentou ou o que a organização observou num teste definido. Uma inferência diz porque é que esse facto pode ser relevante num fluxo de trabalho específico. Um controlo proposto diz o que a equipa pretende implementar. Um risco residual diz o que permanece após o controlo. Uma conclusão jurídica diz o que se aplica ao abrigo da lei. Estas não são intercambiáveis. Um bom documento rotula-as porque o leitor pode precisar de contestar uma sem descartar as outras.

Por exemplo, é possível dizer: a documentação do fornecedor afirma que o modelo tem uma determinada limitação; a equipa de implementação infere que a limitação pode afetar uma utilização especificada; a equipa propõe uma barreira de verificação da fonte; a barreira ainda não foi testada sob a carga de trabalho pretendida; e o consultor jurídico deve avaliar a utilização resultante ao abrigo da lei aplicável. Essa frase é menos satisfatória do que uma marca de verificação verde. É mais útil do que uma marca de verificação verde porque não deixa qualquer mistério sobre o que foi e o que não foi estabelecido.

As equipas devem ter especial cuidado com a palavra humano. Uma função humana pode ser um controlo, mas apenas quando tem uma tarefa definida, informação adequada, tempo, formação, autoridade e uma via para agir. Uma função humana também pode tornar-se uma forma de transferir a culpa para a pessoa mais próxima do ecrã. A distinção não é filosófica. É visível no fluxo de trabalho. Se um revisor só pode aprovar, se a discordância desaparece num campo de comentários não monitorizado, ou se ninguém consegue corrigir a consequência a jusante, o sistema não ganhou supervisão significativa apenas porque alguém clicou em algo.

A mesma cautela aplica-se à transparência. Um documento longo pode tornar um sistema descritível sem o tornar contestável. Um painel de controlo pode torná-lo visível sem o tornar compreensível. Uma divulgação pode dizer a um utilizador que a IA está envolvida sem lhe dizer o que pode ser feito em relação a um erro. A questão útil é prática: pode a pessoa relevante encontrar a fronteira, as evidências, a função responsável e a via de correção no ponto onde essas coisas importam? Se não, a informação existe no lugar errado para que a governação ocorra.

Uma pequena nota nossa

Na Dweve, o nosso Trust Centre público trata o registo do modelo e a integração a jusante como registos relacionados mas separados. A sua página a jusante afirma que as equipas que integram ou implementam o Loom precisam de capacidades atuais, limites, interfaces, contexto de avaliação e alterações, enquanto o registo público declara que um modelo é um fio num tecido mais amplo de componentes e limites operacionais. Esta é uma postura de documentação, não uma afirmação de que uma página pública classifica todas as implementações possíveis ou prova conformidade para um integrador. O propósito da separação é mais modesto: um registo de modelo deve acompanhar a integração sem fingir substituir a análise de sistema do próprio integrador.

Esse é o padrão que vale a pena manter. Um fornecedor de modelos deve disponibilizar informações úteis. Uma organização que implementa ou integra o modelo deve descrever o sistema real que criou: propósito, pessoas, dados, interfaces, autoridade, monitorização e correção. Nenhum dos lados deve usar a documentação como uma troca cerimonial em que uma parte recebe um PDF e a outra recebe absolvição.

A questão mais difícil é geralmente a melhor

Quando uma equipa pergunta se um modelo é de alto risco, pode estar a procurar uma resposta rápida para uma preocupação sensata. Mas a questão mais útil é geralmente mais longa: que sistema estamos a criar a partir deste modelo, para que propósito, em que contexto, com que pessoas, e o que acontece quando ele está errado? Essa questão nem sempre pode ser respondida numa única reunião. Pode revelar que a utilização proposta é mais restrita do que o esperado, que as evidências estão incompletas, que uma função de utilizador não tem autoridade, que um contrato deixa uma fronteira importante sem dono, ou que uma integração a jusante se tornou silenciosamente o centro do sistema.

Nenhuma dessas conclusões é uma falha de inovação. São as coisas que uma instituição aprende antes de dar a um sistema o poder de moldar as opções de outra pessoa. A abordagem europeia é frequentemente descrita como um conjunto de obrigações. É também uma disciplina de nomeação: nomear o propósito, o ator, o contexto, a versão, a pessoa afetada, a limitação, as provas e a via de intervenção. Uma vez nomeadas, essas coisas podem ser testadas, alteradas e contestadas. Antes de serem nomeadas, tendem a reaparecer mais tarde como surpresa.

Um modelo pode ser capaz, cuidadosamente documentado e valioso. Também pode ser colocado num sistema que lhe exige demasiado, que esconde demasiado dos seus utilizadores ou que deixa pouco espaço para uma pessoa afetada pelo resultado. A diferença faz-se fora dos pesos. É aí que vive o trabalho difícil, e é também aí que está a oportunidade séria: construir sistemas cuja autoridade corresponda às suas provas, cujos limites sobrevivam à integração e cujos operadores ainda possam dizer não.

Fontes