por VendorVet (LX AI)

Documentação técnica sob o Regulamento de 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 equipes geralmente montam as peças óbvias e perdem o que os auditores abrem primeiro: resumos de conjuntos de dados, design de supervisão humana e monitoramento pós-comercialização. Trate qualquer esboço gerado como um rascunho para verificar contra o Jornal Oficial, e não como um arquivo final.

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

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 alegações de desempenho e as medidas de gerenciamento de riscos que você realmente executou. A Comissão resume o Ato como uma estrutura baseada em riscos com deveres mais pesados para usos de alto risco; comece com essa estrutura antes de criar um modelo personalizado (Comissão Europeia — Ato 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, não como um PDF de uma vez exportado na semana anterior a uma demonstração.

Ciclo de vida, não uma imagem congelada

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

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

- Confirme se o sistema é de alto risco (ou será tratado como tal) de acordo com o 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. - Abra o Anexo IV e crie uma pasta ou ticket por tema: descrição geral, especificações de design, processo de desenvolvimento, dados, gestão de riscos, testes, monitoramento e supervisão humana. - Atribua um único proprietário por tema. A propriedade compartilhada sem um nome é como as seções ficam vazias. - Faça um rascunho com o produto e a equipe de engenharia na sala. A equipe jurídica revisa as alegações; os engenheiros fornecem caminhos de evidência (configurações, dashboards, relatórios de testes). - Link cada alegação a um artefato: um resumo de conjunto de dados, um esquema de registro, um runbook, uma linha de registro de riscos. A prosa não vinculada é um cheiro. - Percorra o pacote contra o sistema ao vivo: a configuração de registro corresponde às alegações do Artigo 12? O caminho de substituição na interface do usuário corresponde ao texto do Artigo 14? - Agende um gatilho de atualização: aumento da versão do modelo, alteração do conjunto de dados, nova classe de implantador ou quase-acidente grave.

O VendorVet transforma esses temas em uma lista de verificação funcional. Ele não substitui o julgamento do órgão notificado ou o conselho. Use o produto para detectar omissões precocemente; use o Jornal Oficial para resolver argumentos.

Resumos de conjuntos de dados que as equipes de revisão pulam (Artigo 10)

O Artigo 10 espera governança de dados: os dados de treinamento, 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 afetadas pelo sistema. Os auditores procuram um resumo do que foi feito com os dados e como eles foram examinados — e não um cartão de modelo de marketing com três adjetivos.

Uma linha de verificação que diz "dados revisados" sem um resumo por trás dela falha na 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 dados pessoais estiverem no pipeline, mantenha seus papéis e bases do GDPR consistentes com a forma como você descreve o processamento em outros lugares; a biblioteca de orientação do EDPB é a verificação prática para essa linguagem (orientações e práticas recomendadas do EDPB).

Verificação — evidência de dados

- Inventário de conjuntos de treinamento / validação / teste com propriedade e data de atualização mais recente - Notas de representatividade vinculadas ao propósito pretendido (quem está no escopo, quem está fora) - Método de exame de viés e erro — mesmo que imperfeito — com risco residual declarado - Processo de rotulagem ou anotação, incluindo controles de qualidade - Regras de retenção e acesso para os próprios conjuntos de dados

Projeto de supervisão humana (Artigo 14)

O Artigo 14 solicita supervisão humana significativa: interfaces e controles que permitem que uma pessoa monitore, interprete e substitua saídas quando necessário. "Humanos permanecem no loop" não é um mecanismo. Documente o caminho de substituição específico, quem pode exercê-lo, como o sistema sinaliza que um humano deve intervir e o que acontece quando o humano estiver indisponível.

Em produtos de agente, isso geralmente significa uma parada dura antes de uma ação consequencial (publicação da lista de contratação, envio da decisão de crédito, atualização do arquivo do caso), e não um botão de aprovação decorativo que se auto-ativa após três segundos. Combine a descrição da interface do usuário com a política de tempo de execução: quais papéis, quais ambientes, quais eventos de auditoria são acionados quando a substituição é usada.

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

- Papéis de supervisão nomeados e caminho de escalonamento - Controles de interface do usuário ou API que realmente pausam ou revertem a ação de IA - Sinais / limiares que chamam para revisão humana - Treinamento ou manual de execução para as pessoas que supervisionam - Evidência de que eventos de substituição são registrados

Monitoramento e registro pós-comercialização (Artigos 12 e 72)

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

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

Erros comuns que encontramos em 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 planilha do US RMF 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 atualizada; o pacote não. - 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 provedor só se comunica consigo mesma. - Chamar uma lista de verificação de "certificada". Essa linguagem é uma afirmação exagerada. 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 continuar elaborando

Trate o pacote como um lançamento de bloqueio de alta risco quando qualquer um dos seguintes for verdadeiro:

- Nenhuma suma de conjunto de dados que uma terceira parte possa seguir - Nenhum mecanismo de supervisão humana descrito vinculado a um controle real - Retenção de registro em logs inferior a seis meses, ou logs que não podem reconstruir uma decisão - Registro de riscos com nenhum proprietário de risco residual - Propósito pretendido tão vago que o mapeamento do Anexo III é impossível

Você ainda pode enviar protótipos internos que nunca entram em contato com o uso de alto risco da UE. Seja honesto sobre o escopo por escrito. Linguagem ambígua "conformamos em espírito" é pior do que um status claro "ainda não é de alto risco / ainda não está no mercado da UE".

O que isso não é

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

Encerramento

Comece com o texto do Diário Oficial, mapeie os temas do Anexo IV para os proprietários, então preencha as três lacunas que os auditores abrem primeiro: dados, supervisão e registro. Mantenha o pacote com a versão do sistema. Quando o modelo ou o conjunto de dados for movido, mova a documentação no mesmo trem de lançamento. Para a decisão de nível de risco que fica a montante de tudo isso, leia nossa prima introdutória sobre níveis de risco do EU AI Act.

Referências

- Regulamento (UE) 2024/1689 (EUR-Lex) - Comissão Europeia — Lei de IA - Lei de IA da UE — Cronograma de implementação - Quadro de gerenciamento de riscos de IA do NIST - EDPB — Diretrizes e boas práticas do GDPR - OpenTelemetry — Observabilidade de GenAI