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

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

Quando você se prepara para lançar um sistema de IA na UE, você deve mostrar que atendeu às obrigações estabelecidas na Lei de IA. Um relatório de lacunas transforma esses requisitos legais em uma lista concreta de tarefas concluídas e tarefas que permanecem. Essa lista é útil para equipes internas, auditores e reguladores, pois mostra exatamente onde o trabalho é necessário. Ele 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 literalmente em uma coluna de planilha. 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 se torna a lista de trabalho que impulsiona a remediação.

Como a Lei é escrita em linguagem jurídica, traduzimos cada sentença em ações claras. Por exemplo, "fornecer informações claras sobre as capacidades do sistema de IA" se torna "criar uma descrição voltada para o usuário que lista tipos de entrada, formatos de saída e limitações conhecidas".

Como mapeamos as obrigações do Ato para controles técnicos

O mapeamento é a atividade principal que transforma o texto legal em trabalho de engenharia. Usamos uma tabela de três colunas: Obrigações, Controle, Evidências. A coluna de Obrigações contém a redação exata do Ato. A coluna de Controle lista as medidas técnicas ou procedimentais concretas que implementamos para atender a essa redação. A coluna de Evidências contém uma referência a um artefato (um link de documento, um log de teste ou um arquivo de configuração).

Abaixo está um exemplo da tabela que mantemos. Ela mostra um subconjunto de obrigações relacionadas à transparência e governança de dados. A tabela é mantida em uma planilha compartilhada para que os times de produto, jurídico e engenharia possam atualizá-la em tempo real.

Obrigações (redação do Ato) | Controle (o que fazemos) | Evidências (artefato) Os provedores devem garantir que as pessoas naturais sejam informadas de que estão interagindo com um sistema de IA (Artigo 13(1)). | Adicionar uma faixa persistente na interface de chat que leia "Você está conversando com um assistente de IA". | Screenshot da faixa no ambiente de staging (link: internal/wiki/ai-banner).

Os provedores devem tornar disponível, 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 liste 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 provedores devem implementar medidas de governança de dados apropriadas para garantir que os dados de treinamento sejam relevantes, representativos e livres de erros (Artigo 10(1)). | Executar um script de qualidade de dados noturno que verifique valores ausentes, inconsistências de rótulo e amostras fora de distribuição. | Log de saída do script para o último…

A tabela facilita a visualização de quais obrigações têm evidências e quais não têm. As linhas de evidências ausentes se tornam os itens na lista de trabalho de remediação. Revisamos a tabela em cada reunião de planejamento de sprint e atribuímos proprietários para fechar as lacunas.

Construindo a lista de trabalho: etapas que seguimos

Nosso processo para transformar o Ato em uma lista de trabalho consiste em cinco etapas repetíveis. Cada etapa é realizada por uma pequena equipe multifuncional que inclui um analista jurídico, um gerente de produto e um engenheiro.

- Coletar textos-fonte – baixar a versão oficial do Journal do Ato, as Perguntas Frequentes da Comissão e quaisquer padrões relevantes (por exemplo, o OWASP LLM Top 10 ou o NIST AI RMF). Armazená-los em uma pasta somente leitura. - Extrair obrigações – copiar cada sentença que impõe um dever aos provedores em uma lista mestra. Usar a redação literal; não parafrasear nesta etapa. - Traduzir para ações – para cada obrigação, escrever uma sentença imperativa curta que descreva o que deve ser feito para satisfazê-la. Manter a tradução abaixo de 20 palavras, quando possível. - Corresponder a controles – olhar para 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 Ato é alterado ou quando lançamos uma nova versão do modelo. A lista mestra vive em uma página do Confluence que pode ser editada apenas pelo líder de conformidade, garantindo uma única fonte de verdade.

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

O Artigo 13 se concentra em garantir que os usuários saibam que estão lidando com um sistema de IA e entendam o que ele pode e não pode fazer. Para atender a isso, tomamos três ações concretas.

Primeiro, adicionamos um aviso visível a cada endpoint voltado para o usuário. O aviso aparece antes da primeira interação e permanece até que o usuário o dismissa. Ele contém a frase exata exigida pela Lei: "Você está interagindo com um sistema de IA". O texto do aviso é armazenado no arquivo de strings de UI (caminho: src/i18n/pt.json) e é verificado por nossa suíte de testes de UI automatizada.

Segundo, criamos um cartão de modelo que resume o uso pretendido do modelo, limitações conhecidas e números de desempenho. O cartão segue o formato sugerido na orientação de transparência do OWASP LLM Top 10. Ele é hospedado em nosso site de documentação interno e vinculado à página de ajuda do produto.

Terceiro, configuramos uma revisão trimestral onde a equipe 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 provedores garantam que os dados utilizados para treinamento sejam apropriados e documentem as etapas tomadas para abordar vieses. Atendemos a esses requisitos por meio de uma combinação de verificações automatizadas e documentação manual.

Executamos um pipeline de qualidade de dados a cada noite que verifica o conjunto de treinamento para valores ausentes, entradas duplicadas e erros de rótulo. O pipeline é construído usando componentes de código aberto e está configurado para interromper a compilação se qualquer limite crítico for excedido. Os logs do pipeline são arquivados em nosso bucket de conformidade (caminho: gs://clauseguard-compliance/data-quality/).

Para mitigação de vieses, mantemos um registro vivo que lista cada intervenção que aplicamos, como reamostragem de grupos sub-representados ou ajuste de pesos de perda. O registro inclui a data, o motivo da alteração e o impacto medido nas métricas de equidade. Esse registro atende ao requisito de documentação e é revisado pelo conselho de ética antes de cada lançamento de modelo.

Também nos referimos ao NIST AI RMF quando selecionamos controles para governança de dados. As categorias do framework (Governar, Mapear, Medir, Gerenciar) nos ajudam a verificar se nosso pipeline cobre todos os aspectos necessários.

O que isso não é

Este relatório de lacunas não é um certificado de conformidade. Ele não garante que o sistema de IA atende a todos os requisitos da Lei. Ele não promete que os reguladores aceitarão as evidências que fornecemos. Ele não afirma uma taxa de sucesso de 100 % em encontrar todas as possíveis lacunas. Ele não afirma que a lista de tarefas 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 encaixa em nosso ciclo de sprint existente.

No início de cada sprint, o líder de conformidade executa um script que compara a versão atual do Ato (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 foi movido ou se tornou indisponível; links quebrados são marcados para o proprietário responsável.

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

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

Referências