Um modelo pequeno pode carregar uma grande obrigação.

O tamanho do modelo é uma propriedade de engenharia. A obrigação decorre da finalidade, do contexto, dos dados, da autoridade e das pessoas em torno do sistema.

Um modelo pequeno pode carregar uma grande obrigação.

A lei não pergunta qual é o tamanho

Abra o Regulamento da Inteligência Artificial da União Europeia e não encontrará um contador de modelos. Não há uma primeira página em que uma máquina seja pesada, medida e colocada numa gaveta jurídica arrumada. O Regulamento começa com um sistema: um sistema baseado em máquinas que opera com níveis variáveis de autonomia, pode adaptar-se após a sua disponibilização e infere, a partir dos dados de entrada, como gerar resultados, conteúdos, recomendações ou decisões que podem influenciar um ambiente físico ou virtual. A sua definição centra-se no que o sistema faz e no que os seus resultados podem alterar.

É um bom ponto de partida, porque a conversa sobre tecnologia insiste em fazer do tamanho um substituto do contexto. Um modelo mais pequeno parece modesto. Pode caber em hardware comum, responder a uma pergunta específica ou devolver um rótulo em vez de um parágrafo. São propriedades de engenharia valiosas. Podem reduzir a superfície que tem de ser testada, diminuir a necessidade de recursos de uma implementação ou facilitar a substituição de um componente. Nenhuma delas nos diz se uma pessoa pode perder um direito, um serviço, um emprego ou uma via segura por causa do rótulo.

A obrigação surge na relação entre um sistema e o mundo à sua volta. Quem utiliza o resultado. Que decisão se segue. Que dados entram no percurso. Quanta autoridade tem o sistema. Pode uma pessoa contestar o resultado. Pode alguém revertê-lo antes de o dano se tornar duradouro. Está a pessoa afetada dependente do resultado, talvez porque não existe alternativa prática. Um modelo pode ser tecnicamente pequeno e institucionalmente grande. É este o argumento deste artigo, e a palavra institucionalmente é a que carrega o peso.

Não se trata de defender que todos os classificadores sejam tratados como uma emergência pública. Trata-se de defender a proporcionalidade. Proporcionalidade não significa que os sistemas pequenos recebam um sorriso cerimonioso e nenhuma pergunta. Significa que as perguntas acompanham a consequência real. Um modelo usado para organizar uma coleção privada de notas e um modelo usado para decidir quem recebe escrutínio podem parecer semelhantes num repositório. Não são semelhantes no mundo real.

O tamanho do modelo descreve um componente. A finalidade, as pessoas afetadas e o controlo determinam a obrigação que esse componente acarreta.

Pequeno é uma medida, não um contexto

Pequeno pode significar várias coisas diferentes, e esses significados são muitas vezes trocados silenciosamente. Pode significar menos parâmetros, uma pegada de memória menor, menos computação de treino, um vocabulário restrito, um esquema de saída estreito ou uma janela de entrada curta. Pode significar que um modelo é executado num dispositivo em vez de através de um serviço remoto. Pode também significar que uma equipa atribuiu ao modelo uma tarefa restrita. Estas não são a mesma afirmação. Uma contagem minúscula de parâmetros não implica um papel social minúsculo, tal como uma contagem elevada de parâmetros não lhe diz onde o sistema pode atuar.

Há uma segunda confusão. As pessoas usam pequeno para significar local, e local para significar inofensivo. A implementação local pode melhorar o controlo sobre o movimento de dados, a disponibilidade ou a propriedade operacional. Pode também colocar uma decisão diretamente dentro de um local de trabalho, de um balcão público, de um fluxo de trabalho médico ou de um dispositivo que uma pessoa não pode abandonar facilmente. A proximidade física pode reduzir um tipo de dependência enquanto aumenta a importância das pessoas que operam o sistema. Um servidor no mesmo edifício não é uma categoria moral.

Depois há pequeno como uma promessa sobre capacidade. Um componente pode ser treinado para uma tarefa e ainda assim influenciar um processo maior. Pode apenas devolver aprovar, rever ou recusar. O fluxo de trabalho a jusante pode tratar essas três palavras como um portão. O componente não precisa de escrever um ensaio para tomar uma decisão significativa. Só precisa de ser colocado onde o próximo sistema, ou a próxima pessoa, não o possa questionar facilmente.

Para a governação, a unidade útil não é, portanto, apenas o modelo. É o modelo como implementado, com um propósito, um operador, um limite de entrada, um contrato de saída, uma ação a jusante e uma via para correção. Isso é menos arrumado do que uma tabela de classificação. Também está mais próximo da realidade. A tabela de classificação pode dizer-lhe como um modelo se saiu numa tarefa. Não pode dizer-lhe se essa tarefa era permitida, se as pessoas afetadas podiam opor-se, ou se a organização tinha autoridade para usar o resultado.

A linguagem da Comissão Europeia em torno da IA de uso geral ilustra subtilmente esta distinção. A Comissão fornece critérios técnicos para ajudar a identificar quando um modelo pode cair nas obrigações da IA de uso geral, mas também diz que os critérios são indicativos e que uma avaliação caso a caso continua a ser necessária. A orientação não está a fingir que um número pode descrever todos os papéis que um modelo pode desempenhar. Está a tentar tornar uma questão de classificação exequível sem a transformar numa teoria universal do dano.

O limiar não é o veredito

Há números no Regulamento IA, o que é uma razão pela qual as pessoas recorrem a números quando querem certeza. O artigo 51.º cria uma presunção de capacidades de alto impacto para um modelo de IA de uso geral treinado com uma quantidade cumulativa de computação superior a 1025 operações de vírgula flutuante. Essa presunção pertence à classificação de modelos de IA de uso geral com risco sistémico. Não é uma regra de que um modelo abaixo do limiar é seguro, nem uma regra de que todos os modelos acima dele causam o mesmo dano.

A orientação da Comissão sobre IA de uso geral usa um limiar indicativo diferente, acima de 1023 operações de vírgula flutuante juntamente com capacidade generativa ampla, para ajudar a identificar modelos que podem ser de uso geral. A página é explícita sobre os limites. Um modelo abaixo do indicador pode ainda assim qualificar-se se demonstrar generalidade significativa. Um modelo que o cumpra pode excecionalmente não se qualificar se lhe faltar a generalidade relevante. A orientação é uma interpretação para uma questão jurídica específica, não uma licença para todos os usos a jusante.

Estes dois limiares são úteis precisamente porque são estreitos. Ajudam as autoridades e os fornecedores a classificar uma categoria específica de obrigações relativas a modelos. Não resolvem se um modelo pequeno integrado num sistema de alto risco merece cuidado. Não resolvem se o tratamento de dados é lícito. Não resolvem se uma pessoa pode contestar uma decisão. Um limiar pode estabelecer que uma questão deve ser colocada. Não pode responder à questão que pertence a outra camada.

Os limiares técnicos também envelhecem. O Regulamento estabelece que a Comissão pode ajustar o limiar de risco sistémico em função da evolução tecnológica, incluindo melhorias algorítmicas e eficiência do hardware. As orientações da Comissão reconhecem que o seu próprio critério não é absoluto. É uma admissão sensata. Um número que parece estável numa folha de cálculo de aprovisionamento pode mudar quando a tecnologia envolvente evolui. A resposta responsável não é desconfiar de todos os números. É manter o número ligado à questão que foi concebido para responder.

Há uma lição prática para as equipas que publicam fichas de modelos ou notas internas de arquitetura. Indiquem o limiar, a unidade, a disposição legal e o limite. Digam se um número é uma presunção legal, um indicador da Comissão, uma condição de referência ou um objetivo interno de conceção. Não deixem que uma métrica adquira um significado mais amplo por ser conveniente num diapositivo. Uma métrica pequena também pode carregar uma obrigação grande. O número precisa da sua própria proveniência.

Um sistema é mais do que o modelo que contém

O Regulamento IA torna visível a fronteira do sistema. Define fornecedores e utilizadores, separa modelos de sistemas e atribui deveres ao longo de uma cadeia de valor. O fornecedor pode ser a pessoa ou organização que desenvolve um sistema, ou que o manda desenvolver, e o coloca no mercado ou o coloca em serviço em seu próprio nome. O utilizador é a pessoa ou organização que utiliza um sistema sob a sua autoridade. Estes papéis são importantes porque o mesmo componente subjacente pode estar em configurações diferentes, com responsabilidades diferentes.

Imagine um classificador de texto compacto que devolve uma de quatro categorias. O modelo não tem interface de utilizador, nem memória, nem capacidade de chamar uma ferramenta. Num contexto, organiza os documentos da própria equipa em pastas. Noutro, classifica candidaturas para um serviço público, de modo que algumas pessoas são sujeitas a escrutínio adicional. O componente pode ser tecnicamente idêntico. O segundo sistema tem uma finalidade diferente, pessoas afetadas diferentes, uma relação de poder diferente e uma necessidade diferente de explicação e reparação.

As regras de classificação de alto risco do Regulamento seguem esse tipo de diferença. Analisam se um sistema é um componente de segurança, se é utilizado numa área listada no anexo III e se representa um risco significativo para a saúde, a segurança ou os direitos fundamentais. A via das utilizações listadas não é um juízo sobre a elegância do modelo. É um juízo sobre o que o sistema está a fazer num contexto em que um resultado errado pode ter importância. Uma tarefa processual restrita pode enquadrar-se numa exceção cuidadosamente redigida, quando não influencia materialmente uma decisão, mas o fornecedor tem de documentar essa avaliação.

Esse requisito de documentação é fácil de subestimar. Uma equipa que afirma que o sistema é apenas preparatório está a fazer uma afirmação sobre causalidade. Está a dizer que o resultado não influencia materialmente a decisão que se segue. Se o revisor tratar o rótulo como motivo para abrir um processo, se o pessoal se remeter a uma classificação, ou se um requerente não tiver forma significativa de corrigir os dados subjacentes ao sinal, a influência prática pode ser maior do que a interface sugere. A palavra preparatório não pode significar invisível.

As fronteiras do sistema incluem também o maquinário rotineiro à volta de um modelo: a fonte de dados, o limiar, a fila, a pessoa que recebe o resultado, o registo que sobrevive, o contrato com o fornecedor, o processo de atualização e a via para interromper o fluxo de trabalho. Um modelo pequeno pode ser o objeto visível enquanto o risco real reside na transmissão. É por isso que uma revisão de risco que pergunta apenas o que o modelo prevê é incompleta. A questão mais difícil é o que a organização faz por causa dessa previsão.

A finalidade muda o significado do mesmo resultado

Um resultado não tem obrigação no vazio. A mesma probabilidade, categoria ou recomendação pode ser inócua numa tarefa e ter consequências noutra. Isto não acontece porque as palavras mudam de significado no dicionário. Acontece porque um resultado entra numa estrutura de decisão. Uma classificação usada para escolher quais notas de investigação ler primeiro não é o mesmo que uma classificação usada para decidir qual agregado familiar recebe uma investigação por fraude. A máquina pode usar a mesma matemática. A instituição não tem a mesma relação com as pessoas do outro lado.

O artigo 7.º do Regulamento IA enumera os critérios que a Comissão deve considerar ao adicionar ou modificar casos de utilização de alto risco. Incluem a finalidade prevista, a amplitude com que o sistema é utilizado ou suscetível de ser utilizado, a natureza e a quantidade de dados, a autonomia e a possibilidade de intervenção humana, a extensão e a intensidade de danos possíveis, a dependência do resultado, o desequilíbrio de poder, a vulnerabilidade, a reversibilidade, o benefício e a disponibilidade de vias de recurso. Lidos em conjunto, esses critérios constituem uma refutação útil ao pensamento centrado no tamanho do modelo. Descrevem uma relação, não um ficheiro de pesos.

O componente permanece pequeno enquanto a finalidade, o poder, a dependência e a reversibilidade que o rodeiam mudam a questão do controlo.

A dependência é especialmente importante. Uma pessoa pode por vezes ignorar uma recomendação, procurar outro serviço ou pedir a um colega que verifique a resposta. Uma pessoa pode também não ter alternativa prática. Se um passo de triagem automatizado determinar se um serviço é adiado, se um pedido recebe atenção ou se um trabalhador é convocado para uma reunião, a pessoa afetada pode ter de aceitar a primeira interpretação do sistema enquanto a organização decide se volta a analisar. Quanto mais pequena a decisão visível, mais fácil é passar ao lado da dependência subjacente.

Reversibilidade importa pela mesma razão. Um erro de escrita numa etiqueta interna pode ser corrigido antes de alguém depender dela. Um sinalizador de risco pode alterar a ordem pela qual um processo é tratado, e o atraso pode, por si só, tornar-se consequente. Uma negação pode levar à perda de um prazo. Uma classificação pode tornar-se a única classificação que uma equipa ocupada vê. O facto de um administrador poder tecnicamente editar uma base de dados não prova que o resultado social seja fácil de reverter. A reversibilidade técnica e a reversibilidade vivida estão relacionadas, mas não são idênticas.

É aqui que a proporcionalidade tem substância. Uma sugestão interna de baixo impacto pode precisar de um registo leve e de um responsável claro. Um sistema que influencia o acesso a um serviço público precisa de um percurso de evidência mais forte, de uma via humana informada e de uma forma de contestar a entrada e a saída. Controlos proporcionados não são a ausência de controlos. São controlos escolhidos porque a relação os merece.

Os dados mantêm as suas obrigações

O tamanho do modelo não torna os dados anónimos por atmosfera. O Parecer 28/2024 do Comité Europeu para a Proteção de Dados afirma que a questão de saber se um modelo de IA pode ser considerado anónimo deve ser avaliada caso a caso. O teste no resumo público do CEPD pergunta se é muito improvável que o modelo possa identificar direta ou indiretamente as pessoas cujos dados foram utilizados para o criar e se é muito improvável que os seus dados pessoais possam ser extraídos através de consultas. Um modelo mais pequeno pode conter menos informação, mas menos não é uma conclusão jurídica.

O CEPD também mantém em vista o contexto em torno do interesse legítimo. A sua análise aponta para a necessidade e o equilíbrio, e lista a relação entre as pessoas e o responsável pelo tratamento, a natureza do serviço, o contexto em que os dados foram recolhidos, a fonte, os possíveis usos futuros e o que as pessoas poderiam razoavelmente esperar. Esses fatores não desaparecem quando um modelo é comprimido, destilado, quantizado ou colocado atrás de uma API limpa. A compressão altera um objeto técnico. Não reescreve a história de por que os dados foram recolhidos ou o que foi dito às pessoas.

Há uma disciplina útil em ler esse parecer em conjunto com a engenharia de modelos. Pergunte para que foi o modelo treinado ou adaptado, que dados recebe em tempo de execução, quais registos são retidos e quem pode consultá-lo. Depois pergunte o que acontece a jusante. A saída é copiada para um processo. Uma classificação torna-se uma instrução. Um revisor humano vê o material de origem ou apenas o rótulo do modelo. Existe uma via para a pessoa em causa corrigir um erro factual. Estas são questões de dados e de governação, não meramente questões de exatidão.

O resumo público do CEPD também observa que a utilização de dados pessoais tratados ilegalmente no desenvolvimento de um modelo pode afetar a legalidade da implementação, a menos que o modelo tenha sido devidamente anonimizado. Essa frase resiste a uma rota de fuga familiar. Uma equipa não pode fazer desaparecer um problema dizendo que o modelo final é pequeno, que os dados já não são visíveis ou que o modelo é apenas um componente. A história legal e ética dos dados continua a fazer parte da narrativa do sistema.

Para engenheiros, isto significa que o registo de treino e o registo de implementação não devem ser tratados como universos separados. Para aquisições, significa que a declaração de um fornecedor sobre o tamanho do modelo não substitui a proveniência dos dados, a finalidade, a retenção, o tratamento de direitos ou a documentação a jusante. Para uma pessoa afetada, significa que a questão útil não é quantos parâmetros estiveram envolvidos. É o que aconteceu à sua informação e o que a organização pode fazer quando o resultado está errado.

Um sinal pequeno pode mover uma fila grande

Considere um serviço de apoio hipotético que recebe pedidos de residentes. Um classificador compacto lê a primeira mensagem e atribui um encaminhamento: informação, trabalho de rotina, revisão urgente ou tratamento especializado. O exemplo é deliberadamente banal e inteiramente ilustrativo. Não há câmara municipal identificada, nenhuma implementação real, nenhuma data e nenhuma alegação de que isto aconteceu. O objetivo é tornar visível a fronteira.

Se as categorias apenas ajudarem um trabalhador a organizar um conjunto privado de notas, o risco pode ser moderado. Se o encaminhamento urgente determinar quem recebe uma inspeção de segurança, o resultado fica agora mais próximo de uma decisão pública. Se uma palavra-chave em falta enviar o pedido de uma pessoa para trabalho de rotina, o atraso pode ser relevante, mesmo que o modelo nunca fale com o residente. Se o trabalhador puder ver a mensagem original, alterar o encaminhamento, registar o motivo e responder rapidamente a uma contestação, o sistema tem uma postura de controlo diferente daquela em que o rótulo se torna um portão oculto.

O modelo não se tornou maior. A obrigação tornou-se mais clara. Ela segue o caminho desde a entrada até à consequência. A organização deve saber o que significam as categorias, que evidências o modelo pode utilizar, quais os casos que exigem recusa ou escalonamento, quem pode anular o encaminhamento e que registo permite a um revisor posterior compreender a decisão. A modéstia do modelo não é motivo para ignorar essas questões. Pode ser um motivo para respondê-las com maior precisão, porque o contrato do componente pode ser definido de forma restrita.

Uma hipótese semelhante surge no emprego. Um modelo pequeno poderia extrair competências de um currículo, classificar uma função ou assinalar um certificado em falta. A extração parece menos consequente do que a seleção, mas a extração pode moldar a classificação que se segue. Se o resultado nunca for utilizado para decidir quem avança, o sistema pode permanecer do lado preparatório de uma fronteira. Se as pessoas tratarem o rótulo extraído como um resumo objetivo e deixarem de consultar o documento, a fronteira move-se. A obrigação vive na utilização, não no verbo escolhido para a descrição de funções do modelo.

Em ambas as ilustrações, a resposta correta não é entrar em pânico por causa de um modelo pequeno. É tornar explícita a transferência. Nomeie o propósito pretendido. Declare o que o resultado pode e não pode alterar. Preserve a fonte e a versão do modelo quando uma decisão depender delas. Dê a uma pessoa informação e autoridade suficientes para discordar. Teste os segmentos em que se espera que o sistema seja incerto. Reveja o fluxo de trabalho quando a organização alterar os dados, o limiar, o público ou a ação a jusante.

O que o acórdão neerlandês SyRI ensina realmente

A Europa já tem um exemplo documentado de um sistema de risco de aspeto compacto que carrega uma obrigação proporcional aos direitos. Em 5 de fevereiro de 2020, o Tribunal Distrital de Haia descreveu o SyRI como um instrumento governamental legal utilizado para combater a fraude em prestações, subsídios e impostos. O tribunal não decidiu o caso perguntando quantos parâmetros o sistema tinha. Avaliou o quadro jurídico à luz do artigo 8.º da Convenção Europeia dos Direitos Humanos, incluindo se a interferência na vida privada estabelecia um equilíbrio justo.

O tribunal concluiu que a legislação SyRI não passava nesse teste. Na descrição do tribunal, a utilização do SyRI era insuficientemente transparente e controlável. O quadro jurídico era, portanto, incompatível com o direito superior e não podia manter-se na sua forma existente. A página pública do processo é concisa, mas a sua lição não é pequena: quando um Estado utiliza um sistema de indicação de risco contra pessoas que podem ter pouco poder para o compreender ou contestar, o sistema necessita de um nível de visibilidade e controlo que corresponda a essa relação.

O SyRI foi um instrumento neerlandês de indicação de risco previsto na lei, não um estudo de caso sobre um modelo neuronal moderno, e a página do tribunal não nos dá uma contagem de parâmetros para discutir. É precisamente por isso que pertence aqui. O exemplo impede-nos de tratar a arquitetura do modelo como o único objeto interessante. Um motor de regras, um scorecard, um modelo estatístico ou um pequeno classificador podem todos tornar-se parte de uma decisão institucional. A questão dos direitos chega através da utilização.

O acórdão coloca também a transparência no lugar correto. Não é meramente um pedido de explicação depois de uma pessoa ter sido prejudicada. Faz parte das condições sob as quais o sistema pode ser julgado antes e enquanto opera. Se as pessoas não conseguirem ver o suficiente do propósito, da utilização de dados, das salvaguardas e da via de contestação para compreender a interferência, uma organização pode não ser capaz de demonstrar o equilíbrio justo que afirma ter alcançado.

Não há necessidade de transformar o SyRI numa analogia universal. O quadro jurídico neerlandês, os factos do caso e a Convenção Europeia são específicos. A transferência útil é mais restrita: não perguntes se um sistema é tecnicamente impressionante antes de perguntares se a sua relação institucional é visível, controlável e contestável. Uma máquina mais pequena não desculpa um silêncio maior.

A utilização a jusante é onde o rótulo viaja

Um modelo pode ser introduzido como componente e ainda assim tornar-se parte de um sistema que carrega outra obrigação. A orientação da Comissão sobre GPAI explica por que razão os fornecedores a jusante precisam de informação sobre as capacidades e limitações de um modelo. Precisam dessa informação para integrar o modelo de forma responsável e para cumprir os seus próprios deveres ao abrigo do Regulamento IA. O fornecedor do modelo e o fornecedor do sistema não estão a escrever o mesmo documento porque não estão a responder à mesma pergunta.

Esta distinção é importante quando as equipas tratam um model card como um passaporte. Um model card pode descrever arquitetura, formação, avaliação, limitações conhecidas e utilizações previstas. Não pode, por si só, descrever todos os ambientes em que uma equipa a jusante possa colocar o modelo. O sistema a jusante acrescenta um utilizador, um propósito, fluxos de dados, uma interface, papéis humanos, uma decisão e um conjunto de pessoas afetadas. Esses acréscimos podem alterar a obrigação mesmo quando os pesos do modelo permanecem intocados.

A responsabilidade também pode mudar quando uma organização modifica o propósito previsto ou faz uma modificação substancial. As disposições da cadeia de valor do Regulamento IA descrevem circunstâncias em que um ator pode assumir responsabilidades de fornecedor, incluindo alterar o propósito previsto de um sistema de IA de modo a que este se torne de alto risco. Este é um aviso útil contra a névoa contratual. Um fornecedor pode disponibilizar um componente, mas um implementador não pode fazer desaparecer a sua própria utilização chamando ao componente uma biblioteca.

A entrega prática deve, portanto, transportar mais do que uma ligação de descarregamento. Deve indicar as tarefas previstas, os limites de entrada e saída, os requisitos de integração, as informações de formação e validação quando relevantes, as limitações conhecidas e as condições sob as quais o componente não deve ser utilizado. Deve explicar o que o modelo não avaliou. Uma equipa a jusante não deve ter de inferir a ausência de uma garantia a partir da presença de um diagrama confiante.

Há uma razão humana para esta papelada. A pessoa afetada pelo sistema final não encontra um fornecedor de modelos em abstrato. Encontra uma organização que escolheu um fluxo de trabalho. A organização deve ser capaz de dizer o que o componente fez, o que a organização fez com ele e como uma pessoa pode contestar o resultado. Se as respostas viverem em três contratos e em nenhum registo operacional, o sistema não está bem integrado. Está apenas bem distribuído.

A via humana tem de ser real

A supervisão humana é muitas vezes apresentada como uma pessoa sentada junto a um ecrã. O Regulamento IA é mais exato. Para sistemas de risco elevado, a supervisão deve ser eficaz e proporcionada aos riscos, ao nível de autonomia e ao contexto de utilização. A pessoa designada para a supervisão deve ser capaz de compreender as capacidades e limitações relevantes, monitorizar anomalias, interpretar o resultado, decidir não o utilizar, ignorá-lo ou anulá-lo, revertê-lo e intervir ou parar o sistema em segurança.

Nenhum destes verbos é garantido por um modelo pequeno. Um resultado limitado pode ser mais fácil de interpretar, mas interpretar não é o mesmo que ter autoridade. Um botão de anulação que ninguém consegue usar porque a fila é demasiado grande não é supervisão eficaz. Um revisor que vê apenas uma cor ou um rótulo não consegue verificar a origem de forma significativa. Uma pessoa responsabilizada por uma decisão mas que não consegue suspender o fluxo de trabalho não é o ponto de controlo. É um espaço decorativo com forma humana no diagrama.

A supervisão proporcionada pode ser discreta. Pode ser um caminho claro para um trabalhador assinalar provas insuficientes, uma segunda verificação para uma categoria sensível, um registo do motivo pelo qual uma recomendação foi rejeitada, ou uma pausa automática quando faltam campos obrigatórios. Pode ser uma pessoa que é dona da decisão e tem tempo para investigar os casos que o sistema lhe encaminha. Os detalhes dependem do contexto. O requisito é que o caminho funcione quando o sistema está incerto, errado, indisponível ou contestado.

Para modelos pequenos, uma recusa estruturada pode ser uma vantagem. Se um classificador conseguir dizer fonte em falta, fora do âmbito ou necessita de revisão, a organização tem um evento concreto para tratar. Isso é melhor do que um parágrafo fluente que transforma silenciosamente a incerteza numa instrução. Mas a recusa continua a precisar de um responsável. Se todas as recusas se tornarem becos sem saída, o sistema apenas transferiu o ónus para alguém sem lhe dar um caminho para o ultrapassar.

O percurso humano estende-se à pessoa afetada. Uma pessoa não deve precisar da terminologia do fornecedor para contestar um resultado. A organização deve saber que informações podem ser explicadas, o que pode ser corrigido, quem analisa o caso e o que acontece enquanto a análise está em curso. Um modelo pequeno pode facilitar a descrição do rasto interno. Não reduz a importância da pessoa fora do sistema.

Controlos proporcionados continuam a ser controlos

A governação proporcionada começa por recusar dois maus acordos. O primeiro diz que todos os sistemas merecem o mesmo processo pesado, o que transforma a gestão de risco em burocracia e acaba por ensinar as equipas a esconder trabalho. O segundo diz que os modelos pequenos não merecem nenhum processo sério, o que confunde um componente limitado com uma instituição inofensiva. Uma abordagem proporcionada pergunta o que o sistema pode mudar, quem pode ser afetado e que provas permitiriam à organização corrigir um erro.

O primeiro controlo é uma declaração de finalidade que um não especialista consegue compreender. Deve indicar a tarefa, os utilizadores previstos, as pessoas afetadas, os dados de entrada permitidos, o resultado e as ações que o sistema não pode tomar. Uma finalidade como apoio à priorização é demasiado vaga se puder significar organizar uma lista de espera privada, decidir quem recebe uma inspeção estatutária ou selecionar candidatos para uma revisão disciplinar. A frase não é texto de marketing. É o limite contra o qual as alterações posteriores são verificadas.

O segundo controlo é um limite de dados de entrada e de provas. Que fontes o sistema pode ler. Que campos são autoritativos. Qual a sua atualidade necessária. O que acontece quando um valor está em falta ou entra em conflito com outra fonte. Podem os dados pessoais entrar no percurso. Que registo é conservado. Um modelo compacto pode ser rigoroso quanto aos dados de entrada e ainda assim falhar se o fluxo de trabalho envolvente alargar silenciosamente os dados. O âmbito precisa de um responsável, não apenas de um esquema.

O terceiro controlo é um contrato de resultados. Indique os rótulos permitidos, os estados de incerteza, as condições de recusa e as ações a jusante para cada resultado. Se o sistema devolver uma pontuação, diga o que a pontuação significa e o que não significa. Se devolver uma classificação, diga se a classificação é uma sugestão ou uma barreira. Se devolver uma categoria, diga quem pode alterá-la e que registo captura a alteração. Um vocabulário reduzido só é útil quando a instituição concorda em não lhe introduzir autoridade adicional.

O quarto controlo é um percurso de alteração. Atualizações do modelo, alterações de limiares, novas fontes de dados, um grupo de utilizadores diferente, um novo fornecedor ou uma ação a jusante alterada podem modificar o risco do sistema. A linguagem do ciclo de vida do AI Act é um lembrete de que a gestão de risco é iterativa. Um componente que era restrito em janeiro pode integrar uma decisão diferente em agosto. A obrigação acompanha a relação alterada, não a data do primeiro documento de conceção.

O quinto controlo é uma saída. Pode a organização pausar o componente, recorrer a um percurso humano, exportar os registos, explicar o histórico de decisões e substituir o fornecedor sem perder as provas necessárias para reparar casos. A saída não é um luxo para sistemas de grande dimensão. Um modelo pequeno pode tornar-se um ponto único de memória institucional se ninguém preservar a fonte, a versão e o percurso de decisão à sua volta.

Um processo de prova proporcionado

Um processo de prova proporcionado não é um armazém de todos os pensamentos que alguém teve sobre o modelo. É uma resposta legível às perguntas que um revisor, operador, pessoa afetada ou regulador possa razoavelmente colocar. Qual era o objetivo pretendido. Que versão foi executada. Que dados recebeu. O que devolveu. Que regra ou limiar converteu esse resultado numa ação. Quem tinha autoridade para alterar o resultado. O que aconteceu quando faltavam provas. Como pode a decisão ser reproduzida ou contestada.

Para uma sugestão de baixa consequência, o processo pode ser pequeno. Pode conter o objetivo, a fonte, a versão, a avaliação básica, o responsável, a regra de retenção e uma ligação para o percurso de correção. Para um sistema que influencia o acesso, a segurança, o emprego ou os direitos, o processo precisa de mais. Deve ligar a análise de risco aos dados e ao contrato de resultados, mostrar como funciona na prática a supervisão humana, documentar as limitações conhecidas e reter histórico operacional suficiente para investigar um resultado contestado. A proporção cresce com a consequência, não com o número de parâmetros.

Os testes devem seguir a mesma lógica. Um único valor de precisão não pode descrever a adequação de um sistema a todos os contextos. Teste os segmentos de dados e as condições que interessam ao objetivo. Inclua entradas em falta e conflituosas. Inclua casos em que a recusa é correta. Verifique se o resultado do modelo é utilizado de forma diferente por diferentes equipas. Registe o que foi medido, em que condições e o que permanece desconhecido. Um modelo com bom desempenho num conjunto de testes limpo pode estar mal colocado numa instituição desorganizada.

A monitorização não é um ornamento de painel. É assim que a organização descobre que o fluxo de trabalho real mudou. Esteja atento a alterações nos dados de entrada, taxas de discordância, taxas de recusa, alterações nas anulações humanas, novos usos a jusante e reclamações ou pedidos de correção. Os sinais exatos dependem do sistema. O princípio é estável: as provas devem incluir a relação que cria a obrigação, não apenas a pontuação interna do modelo.

Boas provas também têm uma data de validade, mesmo quando os registos são conservados durante mais tempo. Uma interpretação jurídica pode mudar. Um serviço pode chegar a uma nova população. Um fornecedor pode atualizar um modelo. Um percurso que era reversível pode ficar integrado noutro sistema. Marque o que foi avaliado, quando, por quem e em relação a que objetivo. O registo torna-se então um histórico de decisões, em vez de um certificado estático que sobrevive às condições que o tornavam significativo.

Os modos de falha dos modelos pequenos

Os sistemas pequenos falham de formas reconhecíveis. Um classificador pode falhar uma categoria porque a definição do rótulo é ambígua. Um extrator pode devolver um campo plausível da frase errada. Um modelo de ranking pode preferir casos familiares e esconder os invulgares. Um limiar pode transformar uma incerteza contínua num falso binário. Um modelo local pode funcionar de forma fiável enquanto os dados de origem estão desatualizados. Nenhuma destas falhas é automaticamente catastrófica. Cada uma torna-se importante quando o fluxo de trabalho trata o resultado como mais autoritativo do que o contrato do componente permite.

O primeiro modo de falha é a falsa modéstia. A equipa diz que o modelo apenas sinaliza, ordena ou assiste, e depois desenha o fluxo de trabalho de modo a que o pessoal raramente discorde. O rótulo torna-se uma decisão por hábito. Isto não é uma falha na contagem de parâmetros do modelo. É uma falha no modo como a instituição lida com a autoridade. A cura é tornar a passagem visível, medir as anulações e discordâncias, e dar às pessoas um caminho prático para alterar o resultado.

A segunda é a composição oculta. Um modelo pequeno pode estar ao lado de recuperação, regras, uma fila, um ranking e um serviço de notificações. Cada componente parece limitado. Juntos, podem criar um caminho de decisão poderoso. A revisão de risco deve seguir o caminho de ponta a ponta. Qual fonte entra primeiro. Qual transformação remove contexto. Qual rótulo desencadeia uma ação. Qual registo sobrevive. Qual pessoa pode parar a cadeia. A garantia ao nível do componente é necessária, mas não é a visão do sistema.

A terceira é a obrigação desatualizada. Um modelo permanece inalterado enquanto o seu propósito ou público muda. Uma equipa adiciona uma nova fonte de dados, envia o resultado para outro departamento, ou começa a usar uma ferramenta de priorização privada num fluxo de trabalho virado para o público. O cartão do modelo permanece o mesmo, por isso todos assumem que o risco é o mesmo. Não é. O propósito pretendido mudou, e o ficheiro de evidências deve mudar com ele.

A quarta é o halo do modelo pequeno. Uma fatura de recursos baixa ou uma implementação local limpa faz o sistema parecer mais responsável do que é. A organização pode ainda assim falhar em explicar o resultado, preservar a entrada, fornecer reparação, ou atribuir uma pessoa com autoridade. A eficiência técnica é bem-vinda. Não é um substituto para o controlo institucional. Um sistema pode ser barato de operar e caro de defender.

A quinta é a saída em falta. Componentes pequenos são fáceis de adicionar e difíceis de remover quando se entrelaçam num processo movimentado. Uma substituição muda as categorias, os limiares ou os registos que as equipas a jusante esperam. Se ninguém ensaiou a troca, o sistema torna-se pegajoso. O modelo pode ser pequeno, mas a migração é agora um problema público. A portabilidade pertence à primeira conversa de design, não à última reunião de aquisição.

Quando pequeno é a escolha certa de engenharia

Nada disto deve tornar-se numa campanha contra modelos pequenos. Pequeno pode ser exatamente o certo. Uma tarefa estreita com um contrato claro pode não precisar de um modelo de propósito geral. Um componente local pode manter entradas sensíveis mais perto das pessoas responsáveis por elas. Uma saída fixa pode tornar a validação e monitorização mais fáceis. Um modelo que recusa fora do seu âmbito pode ser mais seguro de compor do que um que responde a todas as perguntas com confiança graciosa.

O caso de engenharia é mais forte quando a equipa consegue nomear o que o componente não fará. Classificará apenas as categorias aprovadas. Lerá apenas os campos declarados. Devolverá evidência insuficiente quando um campo obrigatório estiver em falta. Não chamará uma ferramenta. Não tomará a decisão final. Terá uma versão e um registo de avaliação. Será substituível porque a interface e o contrato de evidência estão documentados. Essas restrições não tornam o sistema infantil. Tornam as suas responsabilidades legíveis.

Os componentes pequenos também podem favorecer uma melhor divisão do trabalho. Um modelo abrangente pode interpretar linguagem confusa ou redigir uma explicação legível por humanos. Um componente rigoroso pode extrair um campo, aplicar uma barreira de política, classificar um conjunto declarado de fontes ou verificar se um resultado obedece a uma forma conhecida. Um motor de regras ou um resolvedor pode assumir a parte que tem de ser exata. Uma pessoa pode assumir o julgamento que não pode ser reduzido com segurança. O ponto importante não é a pureza. É que cada parte tem uma função delimitada e o sistema regista como as funções se ligam.

Há uma praticidade europeia neste arranjo. As instituições raramente conseguem substituir tudo de uma vez. Precisam de sistemas que funcionem nas condições de hardware, jurídicas, linguísticas e de aquisição que realmente têm. Os componentes mais pequenos podem, por vezes, ser implementados mais perto do trabalho, avaliados com base em provas locais e substituídos sem exigir que uma organização inteira mude a sua memória. Isso é uma expectativa, não uma afirmação sobre todos os modelos pequenos. A implementação continua a precisar de prova de que o ajuste é real.

O pequeno também é útil como disciplina. Quando uma equipa não consegue resolver um problema acrescentando mais capacidade geral, tem de decidir que informação importa, que incerteza pode ser exposta e que casos exigem uma pessoa. Esse trabalho de conceção pode revelar que um modelo é desnecessário. Por vezes, o componente certo é uma restrição de base de dados, um índice de pesquisa, um registo assinado ou um formulário bem redigido. Um modelo mais pequeno pode carregar uma grande obrigação. Um não-modelo também pode.

Quando o pequeno é usado como camuflagem

O pequeno torna-se camuflagem quando é apresentado como a resposta antes de alguém ter descrito a pergunta. O discurso pode dizer que o componente é leve, local, privado, eficiente ou aberto. Esses podem ser todos factos úteis. Não dizem a uma pessoa afetada se o sistema pode ser contestado, nem a um operador se o resultado pode ser revertido, nem a um regulador se a organização compreendeu o seu propósito.

A camuflagem aparece muitas vezes na linguagem de aquisição. Ao comprador é mostrado o tamanho de um modelo, um valor de latência e um custo de inferência. O contrato diz que o fornecedor disponibiliza uma ferramenta de apoio à decisão. Ninguém escreve quais decisões, os dados de quem, que populações, que via humana ou que alterações desencadeiam revisão. Mais tarde, uma equipa interna descobre que a ferramenta se tornou uma barreira porque a fila, o prazo ou o painel tornaram conveniente obedecer à recomendação. O modelo era pequeno. A governação era mais pequena.

Outra camuflagem é a expressão humano no circuito. Uma pessoa pode tocar tecnicamente em todos os casos sem ter tempo, informação ou autoridade significativos. O circuito funciona então como um ritual de aprovação. Um modelo pequeno pode tornar isto especialmente tentador porque o resultado parece simples. Chegam três categorias, uma pessoa clica numa e a organização chama ao resultado revisto. A revisão exige a capacidade de compreender, contestar e alterar o resultado. Um clique não é, por si só, uma salvaguarda.

Uma terceira camuflagem é a afirmação de que local significa soberano. O processamento local pode ajudar com a residência, a latência e o controlo operacional, mas a soberania também diz respeito a quem pode alterar o software, deter as chaves, aceder aos registos e manter o serviço em funcionamento quando um fornecedor ou uma rede está indisponível. O modelo pequeno num dispositivo pode ser local enquanto as suas atualizações, avaliação e autoridade permanecem noutro lugar. A localização é um facto no mapa. O controlo é um facto na relação.

O antídoto não é uma forma maior. É uma forma mais nítida. Pergunte pelo propósito. Pergunte o que muda por causa do resultado. Pergunte quem pode discordar. Pergunte o que a pessoa afetada pode fazer. Pergunte que provas são conservadas. Pergunte como o sistema é suspenso, substituído e reavaliado. Se as respostas forem claras, o tamanho do modelo pode voltar ao seu devido lugar como uma escolha de engenharia entre muitas.

As perguntas de um comprador

Antes de um modelo pequeno entrar num fluxo de trabalho consequente, um comprador deve conseguir responder a uma sequência de perguntas simples. Qual é a finalidade pretendida numa frase. O que está fora do âmbito. Que pessoas podem ser afetadas, diretamente ou através de uma ação a jusante. Que dados são necessários e que dados são proibidos. O que permite cada resultado à organização fazer. O que não permite à organização fazer.

Depois, pergunte sobre a autoridade. Quem é o dono da decisão. Quem pode sobrepor-se ao modelo. Quem pode parar o fluxo de trabalho. Que informação essa pessoa vê. Quanto tempo tem. O que acontece quando discorda. A pessoa afetada é informada o suficiente para pedir uma revisão. A organização consegue corrigir tanto os dados de entrada como o resultado. Estas perguntas não são uma acusação contra o fornecedor. São a descrição mínima da instituição que compra a ferramenta.

Pergunte sobre as provas. Que versão foi executada. Que configuração de modelo e de política estava ativa. Que fontes estavam disponíveis. Que limiar ou regra transformou o resultado na ação seguinte. O que é registado quando um humano altera o resultado. A organização consegue reproduzir um caso sem fingir que uma nova execução é a antiga. Consegue exportar os registos num formato que outro sistema consiga ler. A resposta não precisa de ser uma grande plataforma. Precisa de ser um registo real.

Pergunte sobre a mudança. O que conta como uma atualização do modelo. O que conta como uma nova fonte de dados. O que acontece quando a finalidade muda. Que alterações exigem uma nova avaliação. Quem é notificado. Como são protegidas as pessoas afetadas durante uma reversão ou migração. Se o fornecedor não conseguir responder, o comprador não está a comprar um risco pequeno. Está a aceitar uma descrição pequena de um grande desconhecido.

Por fim, pergunte sobre a saída. O fluxo de trabalho consegue funcionar em segurança sem o modelo. A organização consegue recuperar os dados de entrada, os resultados, as decisões e o histórico de correções. Outro componente consegue cumprir a mesma interface sem uma nova dependência. O sistema consegue ser retirado sem deixar pessoas em suspenso. Um modelo não é verdadeiramente pequeno se a sua remoção exigir que a instituição se esqueça de como tomou decisões.

Uma breve nota nossa

Na Dweve, o Loom é um exemplo da posição de design que trazemos a esta questão. A sua descrição pública do produto apresenta pequenos componentes de linguagem como processadores em torno de um grafo de raciocínio tipado, com rastreios, reprodução e limites explícitos de recusa. Isso é uma declaração sobre a nossa arquitetura e sobre a forma como queremos que a responsabilidade de um componente seja visível. Não é prova independente, uma classificação regulamentar, uma implementação de cliente ou uma promessa de que um pequeno componente é automaticamente adequado para uma utilização consequente.

A parte útil do exemplo é o limite. Um componente pode ser pequeno e ainda assim merecer um contrato preciso. Pode ser colocado num grafo maior sem se tornar o dono de todas as decisões. Pode transportar um rastreio sem afirmar que o rastreio prova que toda a instituição agiu legalmente. Mencionamos o Loom aqui apenas para mostrar como o nosso próprio trabalho tenta manter separados a capacidade do modelo, a finalidade do sistema, as provas e a autoridade humana. A questão europeia continua a ser a mesma para nós como para qualquer outra pessoa: o que pode este sistema mudar, e as pessoas responsáveis ainda conseguem inspecioná-lo e corrigi-lo?

A obrigação é transportada pela relação

Um modelo pequeno pode ser mais fácil de executar, mais fácil de testar e mais fácil de substituir. Essas são boas razões para escolher um. Não são razões para reduzir o dever de cuidado que o rodeia. As definições e regras de risco do Regulamento IA, a orientação da Comissão sobre GPAI, a abordagem caso a caso do CEPD em relação aos dados e o acórdão neerlandês SyRI apontam todos na mesma direção prática sem se tornarem um único teste jurídico: olhar para a finalidade, o contexto, a autoridade, as provas, as pessoas afetadas e a possibilidade de reparação.

A pergunta certa não é, portanto, se o modelo é pequeno. É o que o modelo pode alterar. Se apenas ajudar uma pessoa a pesquisar as suas próprias notas, a resposta pode ser modesta. Se mudar quem recebe atenção, qual registo é considerado fiável, ou se um serviço público abre uma porta, a resposta é maior. Se a organização não conseguir explicar a transição, preservar as provas, ou dar a alguém uma via para contestar o resultado, a obrigação já ultrapassou o componente.

Uma boa governação deixa espaço para a proporcionalidade. Não exige que todos os modelos se tornem um comité. Pede à equipa que torne visíveis as relações importantes, que mantenha as afirmações ligadas às provas, e que dê às pessoas autoridade real quando o sistema está incerto ou errado. Os modelos pequenos podem ajudar nesse trabalho porque um componente delimitado pode ser nomeado e testado. Mas estar delimitado é uma conquista de design, não uma propriedade automática de ser pequeno.

O tamanho pertence ao registo de engenharia. O propósito pertence ao registo do sistema. A consequência pertence ao registo humano. Quando estes três registos podem dialogar entre si, um modelo pequeno pode ser usado com cuidado sem ser tratado como inofensivo. Quando são mantidos separados, a modéstia do modelo torna-se teatro, e as pessoas que carregam o resultado pagam pelo contexto em falta.

Fontes