Relatório de lacunas de remediação antes do lançamento na UE

Porque um relatório de lacunas é importante antes do lançamento

Quando se prepara para lançar um sistema de IA na UE, deve demonstrar que cumpriu as obrigações estabelecidas na Lei de IA. Um relatório de lacunas transforma esses requisitos legais numa lista concreta de tarefas concluídas e tarefas que permanecem. Esta lista é útil para equipes internas, auditores e reguladores, pois mostra exatamente onde o trabalho é necessário. Não promete conformidade; simplesmente mostra o estado atual do esforço.

Começamos lendo o texto oficial da Lei e as diretrizes relacionadas da Comissão Europeia. Cada obrigação é copiada ipsis verbis para uma coluna de uma folha de cálculo. Ao lado de cada obrigação, adicionamos uma coluna para evidências (como um documento de política, um resultado de teste ou um comentário de código). Se a coluna de evidências estiver vazia, marcamos a linha como uma lacuna. A tabela resultante torna-se a lista de trabalho que impulsiona a remediação.

Como a Lei é escrita em linguagem jurídica, traduzimos cada sentença para ações claras. Por exemplo, "fornecer informações claras sobre as capacidades do sistema de IA" torna-se "criar uma descrição orientada para o utilizador que lista os tipos de entrada, os formatos de saída e as limitações conhecidas". Este passo de tradução evita a má interpretação e facilita a atribuição de proprietários.

Como mapeamos as obrigações do Act para controlos técnicos

O mapeamento é a atividade central que transforma o texto legal em trabalho de engenharia. Utilizamos uma tabela de três colunas: Obrigações, Controlo, Evidência. A coluna Obrigações contém a redacção exacta do Act. A coluna Controlo lista as medidas técnicas ou processuais concretas que implementámos para satisfazer essa redacção. A coluna Evidência contém uma referência a um artifacto (um link de documento, um registo de teste ou um ficheiro de configuração).

Abaixo está um exemplo da tabela que mantemos. Mostra um subconjunto de obrigações relacionadas com a transparência e a governança de dados. A tabela é mantida numa folha de cálculo partilhada para que os produtos, jurídicos e engenheiros a possam actualizar em tempo real.

Obrigações (redacção do Act) | Controlo (o que fazemos) | Evidência (artifacto) Os fornecedores devem garantir que as pessoas singulares sejam informadas de que estão a interagir com um sistema de IA (Artigo 13(1)). | Adicionar uma faixa persistente na interface de chat que leia "Está a falar com um assistente de IA". | Screenshot da faixa no ambiente de staging (link: internal/wiki/ai-banner). Os fornecedores devem disponibilizar, de forma clara e acessível, informações sobre as capacidades e limitações do sistema de IA (Artigo 13(2)). | Publicar um cartão de modelo que lista o uso pretendido, modos de falha conhecidos e métricas de desempenho. | Cartão de modelo PDF armazenado no repositório de conformidade (caminho: docs/model-card-v2.pdf). Os fornecedores devem implementar medidas de governança de dados adequadas para garantir que os dados de treinamento sejam relevantes, representativos e isentos de erros (Artigo 10(1)). | Executar um script de qualidade de dados noturno que verifique valores em falta, inconsistências de etiquetas e amostras fora da distribuição. | Registo de saída do script para o último…

A tabela torna fácil ver quais as obrigações que têm evidência e quais não. As linhas de evidência em falta tornam-se os itens na lista de trabalho de remediação. Revisamos a tabela em cada reunião de planeamento de sprint e atribuímos proprietários para fechar as lacunas.

Construir a lista de trabalhos: passos que seguimos

O nosso processo para transformar o Acto numa lista de trabalhos consiste em cinco passos repetíveis. Cada passo é realizado por uma pequena equipa cross-funcional que inclui um analista jurídico, um gestor de produto e um engenheiro.

- Recolher textos de origem – transferir a versão oficial do Journal do Acto, as perguntas frequentes da Comissão e quaisquer normas relevantes (por exemplo, as LLM Top 10 da OWASP ou o NIST AI RMF). Armazená-los numa pasta de apenas leitura. - Extrair obrigações – copiar cada frase que impõe um dever aos fornecedores para uma lista mestra. Utilizar a formulação literal; não parafrasear nesta fase. - Traduzir para ações – para cada obrigação, escrever uma frase imperativa curta que descreva o que deve ser feito para a satisfazer. Manter a tradução abaixo de 20 palavras sempre que possível. - Associar a controlos – olhar para as políticas, código e documentação existentes para ver se algum já atende à ação traduzida. Se uma correspondência existir, vincular a evidência; se não, sinalizar uma lacuna. - Priorizar lacunas – atribuir uma prioridade com base no nível de risco (alto, médio, baixo) e estimativa de esforço (pequeno, médio, grande). Lacunas de alto risco e baixo esforço são abordadas primeiro.

Repetimos o ciclo sempre que o Acto é alterado ou quando lançamos uma nova versão do modelo. A lista mestra vive numa página Confluence que só é editável pelo responsável pela conformidade, garantindo uma única fonte de verdade.

Exemplo: Obrigações de transparência (Artigo 13)

O Artigo 13 centra-se em garantir que os utilizadores sabem que estão a lidar com um sistema de IA e compreendem o que ele pode e não pode fazer. Para satisfazer este requisito, tomámos três ações concretas.

Em primeiro lugar, adicionámos um aviso visível a todos os endpoints voltados para o utilizador. O aviso aparece antes da primeira interação e permanece até que o utilizador o feche. Contém a frase exata exigida pelo Acto: "Está a interagir com um sistema de IA". O texto do aviso está armazenado no ficheiro de cordas de UI (caminho: src/i18n/pt.json) e é verificado pela nossa suíte de testes de UI automatizados.

Em segundo lugar, criámos um cartão de modelo que resume a utilização pretendida do modelo, limitações conhecidas e números de desempenho. O cartão segue o formato sugerido nas orientações de transparência do OWASP LLM Top 10. Está hospedado no nosso site de documentação interna e ligado à página de ajuda do produto.

Em terceiro lugar, configurámos uma revisão trimestral onde a equipa do produto verifica se o aviso ainda aparece após cada lançamento da UI e se o cartão do modelo reflete a versão mais recente. Qualquer desvio cria um novo item de lacuna que é adicionado à lista de trabalhos.

Exemplo: Obrigações de governança de dados (Artigo 10)

O Artigo 10 exige que os fornecedores garantam que os dados utilizados para treinamento sejam adequados e documentem as etapas tomadas para abordar vieses. Abordamos estes requisitos através de uma combinação de verificações automatizadas e documentação manual.

Executamos um pipeline de qualidade de dados todas as noites que verifica o conjunto de treinamento para valores em falta, entradas duplicadas e erros de etiqueta. O pipeline é construído utilizando componentes de código aberto e está configurado para falhar a compilação se qualquer limiar crítico for excedido. Os registos do pipeline são arquivados no nosso balde de conformidade (caminho: gs://clauseguard-compliance/data-quality/).

Para mitigação de vieses, mantemos um registo vivo que lista cada intervenção que aplicámos, como re-amostragem de grupos sub-representados ou ajuste de pesos de perda. O registo inclui a data, o motivo da alteração e o impacto medido nos métricos de equidade. Este registo satisfaz o requisito de documentação e é revisto pelo conselho de ética antes de cada lançamento de modelo.

Também nos referimos ao NIST AI RMF quando seleccionamos controlos para governança de dados.

O que isto não é

Este relatório de lacunas não é um certificado de conformidade. Não garante que o sistema de IA atenda a todos os requisitos da Lei. Não promete que os reguladores aceitarão as provas que fornecemos. Não afirma uma taxa de sucesso de 100 % na detecção de todas as possíveis lacunas. Não asserte que a lista de trabalhos nunca perderá uma questão.

Como mantemos o relatório atualizado

Manter um relatório de lacunas preciso requer atualizações regulares. Instituímos um ritmo leve que se ajusta ao nosso ciclo de sprint existente.

No início de cada sprint, o responsável pela conformidade executa um script que compara a versão atual do Regulamento (baixado do portal oficial da UE) com a lista mestra de obrigações. Quaisquer novas ou alteradas sentenças são adicionadas como novas linhas. O script também verifica os links de evidências para ver se algum mudou ou se tornou indisponível; links quebrados são sinalizados para o proprietário responsável.

Durante a retrospectiva do sprint, a equipe revisa a lista de lacunas e marca os itens como concluídos quando a evidência associada é carregada e verificada. Itens concluídos são movidos para uma aba de arquivo para que permaneçam acessíveis para auditorias, mas não bagunçam a vista ativa.

A cada trimestre, realizamos uma reunião de revisão formal com os responsáveis jurídicos, de produto e de engenharia. Nessa reunião, percorremos as lacunas de alta prioridade, confirmamos as estimativas de esforço e ajustamos os prazos, se necessário. O resultado da reunião é uma nota de atualização curta que é anexada à página do Confluence.

Referências

- OWASP LLM Top 10 para Aplicações de Modelos de Linguagem Grande - Quadro de Gestão de Riscos de IA da NIST