por VendorVet (LX AI)

Documentação técnica sob o Acto IA

De acordo com o Regulamento (UE) 2024/1689, os prestadores de alto risco devem manter documentação técnica que demonstre conformidade antes da colocação no mercado. As equipas frequentemente reúnem as peças óbvias e perdem o que os auditores abrem primeiro: resumos de conjuntos de dados, design de supervisão humana e monitorização pós-mercado. Trate qualquer esboço gerado como um rascunho para verificar contra o Jornal Oficial, e não um depósito final.

O que a obrigação de documentação abrange efetivamente

O Artigo 11 e o Anexo IV estabelecem o conteúdo da documentação para sistemas de alto risco. O pacote abrange o propósito pretendido, as escolhas de design, o histórico de desenvolvimento e testes, as afirmações de desempenho e as medidas de gestão de riscos que foram efetivamente executadas. A Comissão resume o Acto como um quadro baseado em riscos com deveres mais pesados para usos de alto risco; comece com essa estrutura antes de inventar um modelo personalizado (Comissão Europeia — Acto de IA).

O texto vinculativo é o regulamento em si no EUR-Lex (Regulamento (UE) 2024/1689). Blogs e apresentações secundárias são úteis apenas após você poder apontar para o artigo e a linha do anexo que suporta cada afirmação. Trato a documentação como um conjunto de arquivos vivo sob controle de versão, e não como um PDF de uma única vez exportado na semana anterior a uma demonstração.

Ciclo de vida, e não uma imagem congelada

Se o modelo muda, o conjunto de treinamento é atualizado ou um controlo de segurança é reorganizado, a documentação deve mostrar a diferença. Notas de alteração, proprietários e datas são tão importantes quanto a primeira redação. Quando um implantador pergunta "qual foi a compilação em produção na terça-feira?", você deve responder a partir do mesmo registo que suporta a conformidade — e não a partir de uma conversa no Slack.

Fluxo de trabalho passo a passo que utilizamos antes de considerar um pacote "pronto"

- Confirmar que o sistema é de alto risco (ou será tratado como tal) nos termos do Artigo 6 / Anexo III antes de criar uma árvore de documentação. Se não for de alto risco, não exagere a completude do Anexo IV na cópia de vendas. - Abrir o Anexo IV e criar uma pasta ou bilhete por tema: descrição geral, especificações de design, processo de desenvolvimento, dados, gestão de riscos, testes, monitorização e supervisão humana. - Atribuir um único proprietário por tema. A propriedade compartilhada sem um nome é como as secções ficam vazias. - Redigir com o produto e a engenharia na sala. A equipa jurídica analisa as alegações; os engenheiros fornecem percursos de evidências (configurações, dashboards, relatórios de testes). - Associar cada alegação a um artefacto: um resumo de conjunto de dados, um esquema de registo, um livro de execução, uma linha de registo de riscos. A prosa não associada é um cheiro. - Percorrer o pacote contra o sistema ao vivo: a configuração de registo corresponde às alegações do Artigo 12? O caminho de anulação na UI corresponde ao texto do Artigo 14? - Agendar um gatilho de atualização: aumento da versão do modelo, alteração do conjunto de dados, nova classe de implementação ou quase-acidente grave.

O VendorVet transforma estes temas num checklist funcional. Não substitui o julgamento do órgão notificado ou do conselho. Utilize o produto para detectar omissões precocemente; utilize o Jornal Oficial para resolver argumentos.

Resumos de conjuntos de dados que as equipas de revisão saltam (Artigo 10)

O Artigo 10 espera uma governança de dados: os dados de treino, validação e teste devem ser relevantes e representativos para o propósito pretendido, com exame de viés e lacunas que poderiam prejudicar o desempenho para as pessoas que o sistema afetará. Os auditores procuram um resumo do que os dados foram utilizados e como foram examinados — e não um cartão de modelo de marketing com três adjetivos.

Uma linha de verificação que diz "dados revistos" sem resumo por trás dela falha a primeira revisão séria. Escreva o resumo para que um novo engenheiro possa responder: domínios de origem, janelas de tempo, viés conhecidos, regras de exclusão e como as etiquetas foram produzidas ou auditadas. Se os dados pessoais estiverem no pipeline, mantenha os seus papéis e bases do GDPR consistentes com a forma como descreve o processamento em outros lugares; a biblioteca de orientações do EDPB é a verificação prática para essa linguagem (orientações e boas práticas do EDPB).

Verificação — evidência de dados

- Inventário de conjuntos de treino / validação / teste com propriedade e data de última atualização - Notas de representatividade ligadas ao propósito pretendido (quem está no âmbito, quem está fora) - Método de exame de viés e erro — mesmo que imperfeito — com risco residual declarado - Processo de etiquetagem ou anotação, incluindo controlos de qualidade - Regras de retenção e acesso para os próprios conjuntos de dados

Desenho de supervisão humana (Artigo 14)

O Artigo 14 pede supervisão humana significativa: interfaces e controlos que permitem a uma pessoa monitorizar, interpretar e anular outputs quando necessário. "Os humanos mantêm-se no loop" não é um mecanismo. Documente o caminho de anulação específico, quem pode exercê-lo, como o sistema sinaliza que um humano deve intervir e o que acontece quando o humano não está disponível.

Em produtos de agente, isto muitas vezes significa uma paragem forçada antes de uma ação com consequências (publicação da lista de seleção de contratação, envio de decisão de crédito, atualização do processo), e não um botão de aprovação decorativo que se auto-ativa após três segundos. Emparelhe a descrição da interface do utilizador com a política de tempo de execução: quais papéis, quais ambientes, quais eventos de auditoria são acionados quando a anulação é utilizada.

Lista de verificação — evidências de supervisão

- Papéis de supervisão nomeados e caminho de escala - Controlos de interface do utilizador ou API que realmente pausam ou revertem a ação da IA - Sinais / limiares que chamam para revisão humana - Formação ou livro de instruções para as pessoas que supervisionam - Evidências de que os eventos de anulação são registados

Monitorização e registo pós-comercialização (Artigos 12 e 72)

O Artigo 12 exige registo automático suficiente para rastreabilidade, com um período de retenção mínimo de seis meses para sistemas de alto risco. O Artigo 72 acrescenta deveres de relato de incidentes graves. As equipas documentam o modelo e esquecem o plano de evidências de tempo de execução. Emparelhe a documentação com a configuração de registo real para que os dois concordem.

Se já executar observabilidade de GenAI, mapeie spans e eventos para as perguntas que uma revisão pós-comercialização irá fazer: qual classe de entrada, qual versão do modelo, qual decisão de política, qual ação humana. As convenções de GenAI da OpenTelemetry são uma referência prática de engenharia para nomear esses campos de forma consistente em todos os serviços (OpenTelemetry — observabilidade de GenAI). O Acto não exige OTel; traços consistentes tornam as alegações do Artigo 12 mais fáceis de defender.

Erros comuns que encontramos nos pacotes de documentação

- Escrever para o folheto, não para o anexo. Diagramas bonitos que nunca citam os temas do Anexo IV desperdiçam tempo de revisão. - Copiar uma folha de trabalho do RMF dos EUA e renomeá-la para "pacote do AI Act". O Quadro de Gestão de Riscos de IA da NIST é útil para o vocabulário de processo (NIST AI RMF), mas não é um substituto para o conteúdo do Artigo 11 / Anexo IV. - Documentar o modelo de ontem. A produção já foi movida; o pacote não foi. - Deixar as instruções do deployer vazias. A transparência do Artigo 13 para os deployers é fácil de ser ignorada quando a equipe do fornecedor só se comunica consigo mesma. - Chamar uma lista de verificação de "certificada". Essa linguagem é uma afirmação exagerada. As listas de verificação reduzem o risco de omissão; elas não certificam a conformidade.

Critérios de decisão: enviar o pacote versus manter a elaboração

Considere o pacote como bloqueador de lançamento para um lançamento de alto risco quando qualquer uma das seguintes condições for verdadeira:

- Não há resumo de conjunto de dados que uma terceira parte possa seguir - Não há mecanismo de supervisão humana descrito ligado a um controlo real - Retenção de registos inferiores a seis meses, ou registos que não conseguem reconstruir uma decisão - Registo de riscos com nenhum proprietário de risco residual - Propósito pretendido tão vago que o mapeamento do Anexo III é impossível

Ainda é possível enviar protótipos internos que nunca tocam o uso de alto risco da UE. Seja honesto sobre o âmbito por escrito. Linguagem ambígua "conformamos em espírito" é pior do que um estatuto claro "ainda não é de alto risco / ainda não está no mercado da UE".

O que isto não é

Esta página não é um aconselhamento jurídico, não é uma avaliação de um organismo notificado e não é uma garantia de que o seu sistema está em conformidade com o Regulamento (UE) 2024/1689. O VendorVet não afirma uma cobertura de 100%, não inventa taxas de vitória dos clientes e não substitui um conselheiro ou uma avaliação de conformidade quando uma é necessária. Uma lista de verificação ajuda-o a montar e verificar temas; o dever vinculativo permanece a documentação descrita no Artigo 11 e no Anexo IV, detida por pessoas qualificadas na sua organização.

Encerramento

Comece com o texto do Jornal Oficial, mapeie os temas do Anexo IV para os proprietários, em seguida, preencha as três lacunas que os auditores abrem primeiro: dados, supervisão e registo. Mantenha o pacote versionado com o sistema. Quando o modelo ou o conjunto de dados se move, mova a documentação no mesmo comboio de lançamento. Para a decisão de nível de risco que se situa a montante de tudo isto, leia o nosso primer irmão sobre níveis de risco do EU AI Act.

Referências

- Regulamento (UE) 2024/1689 (EUR-Lex) - Comissão Europeia — Acto AI - Acto AI da UE — Cronologia de Implementação - Quadro de Gestão de Riscos de IA da NIST - EDPB — Diretrizes e boas práticas do GDPR - OpenTelemetry — Observabilidade do GenAI