Erros comuns de documentação técnica

Os erros habituais não são de formatação, mas de âmbito, prova, responsabilidade e controlo de alterações. Um ficheiro pode parecer completo e ser impossível de verificar. O artigo 11 do Regulamento da IA exige que os fornecedores de sistemas de alto risco preparem a documentação antes da colocação no mercado ou entrada em serviço e a mantenham atualizada. O anexo IV define o conteúdo mínimo. O Regulamento (UE) 2026/1744 simplifica a apresentação para algumas organizações menores, mas não elimina a necessidade de sustentar as afirmações.

Nem toda a empresa SaaS é fornecedora de um sistema de alto risco. Confirme primeiro o limite do sistema, o papel e a classificação.

1. Documentar o modelo em vez do sistema

Uma ficha do modelo ou do fornecedor não descreve prompts, fluxos de dados, interfaces, supervisão humana, registos e ações posteriores. Defina o limite e registe componentes, atores, entradas, saídas e controlos. Separe dados do fornecedor de factos verificados internamente. O guia do Regulamento da IA para fornecedores SaaS ajuda a estabelecer papel e âmbito.

2. Começar por um modelo narrativo

Modelos extensos geram texto plausível sobre testes e supervisão antes de existirem provas. Comece por um índice: requisito, artefacto fonte, versão, responsável, revisor, estado e evento de atualização. Escreva a explicação apenas a partir de fontes controladas.

3. Confundir políticas com provas

Uma política descreve o que deve acontecer; a prova mostra o que aconteceu numa versão concreta. Requisitos aprovados, decisões de arquitetura, registos de dados, avaliações, modelos de ameaça, aprovações de lançamento e revisões de monitorização são úteis. Cada prova deve indicar afirmação, fonte, data, versão e responsável.

4. Perder a rastreabilidade das versões

Diagramas substituídos, testes sem versão de modelo ou conjunto de dados e painéis mutáveis quebram a cadeia. Dê ao sistema um identificador estável e ligue cada artefacto a lançamento, modelo, configuração e data. A partir da produção, um revisor deve localizar requisitos, arquitetura, testes, riscos, controlos, instruções e aprovação.

5. Atribuir tudo à conformidade

A conformidade coordena o padrão e questiona afirmações fracas, mas não deve redigir factos técnicos em segunda mão. Produto é responsável pela finalidade; engenharia, pela arquitetura e alterações; dados ou ML, pelas avaliações; segurança, pelos controlos; gestão de lançamentos, pelo que foi distribuído. Um responsável central gere a cobertura sem produzir todas as provas.

6. Tratar a documentação como tarefa única

Modelos, dados, fornecedores e riscos mudam. Adicione uma verificação de impacto quando se alterem finalidade, limite, modelo, dados importantes, desempenho, supervisão, segurança, instruções ou monitorização. A revisão periódica é uma salvaguarda; o controlo principal deve ser acionado por eventos. Uma boa estrutura também acelera auditorias.

7. Medir atividade em vez de qualidade

O número de documentos ou tarefas fechadas não prova que as afirmações têm suporte. Meça a completude inicial, lacunas importantes, exceções vencidas, ligações quebradas, diferenças de versão e tempo de atualização. Se o revisor tiver de entrevistar o autor, a prova não é autónoma.

8. Aceitar afirmações do fornecedor sem verificação

Certificados e fichas podem cobrir outra versão, língua, população ou ambiente. Registe o documento exato, avalie a diferença para o seu uso e teste o comportamento relevante. Informação em falta é um risco ou lacuna, não uma base para pressupostos.

9. Esconder lacunas atrás de exceções vagas

“Completar mais tarde” não é uma decisão controlada. Registe lacuna, motivo, controlo temporário, responsável pelo risco, aprovação, correção e validade. Um modelo claro de responsabilidade de conformidade evita exceções permanentes.

Revisão focada

1. Confirmar limite, papel, classificação, finalidade e versão atual.
2. Criar o índice do anexo IV e ligar fontes controladas.
3. Amostrar uma afirmação de arquitetura, desempenho, risco, supervisão e mudança.
4. Verificar identificadores coerentes e resultados reproduzíveis.
5. Dar a cada lacuna responsável, materialidade, ação e data.
6. Integrar eventos em produto, fornecedores, segurança e lançamento.

Perguntas frequentes

Qual é a finalidade prática?

Explicar com rastreabilidade o que é o sistema, como foi desenvolvido e avaliado, quais os riscos e controlos e por que razão se consideram cumpridos os requisitos.

Quando se aplica a equipas SaaS?

O artigo 11 aplica-se a fornecedores de sistemas de alto risco. Confirme limite, papel e classificação antes de tratar o anexo IV como obrigação direta.

O que deve ser corrigido primeiro?

Finalidade, versão, arquitetura, avaliação, riscos materiais, supervisão humana, instruções e aprovação. Resolva contradições e afirmações importantes sem prova antes da apresentação.

Fontes

• Regulamento (UE) 2024/1689, em especial artigo 11 e anexo IV.
• Regulamento (UE) 2026/1744, incluindo simplificações da documentação técnica.