Documentação técnica: guia prático para equipes SaaS

A documentação técnica de um sistema de IA não é um resumo de arquitetura preparado no final do projeto. É o arquivo controlado que explica a finalidade do sistema, como foi construído, quais dados e modelos usa, como performa, quais riscos foram identificados, quais controles os tratam e como mudanças após o lançamento são geridas.

Para fornecedores de sistemas de IA de alto risco, o artigo 11 do AI Act exige que esse arquivo seja preparado antes da colocação no mercado ou em serviço, mantido atualizado e claro o suficiente para autoridades e organismos notificados avaliarem a conformidade. O anexo IV determina o conteúdo mínimo. Uma equipe SaaS deve, portanto, reunir evidências de produto, engenharia, dados, segurança, jurídico e qualidade durante o desenvolvimento, não reconstruí-las durante uma auditoria.

A obrigação não se aplica automaticamente a toda função com IA. O escopo depende da classificação e do papel da empresa. Documente ambos primeiro e torne o arquivo proporcional às obrigações e riscos reais.

Por que importa na prática

Uma boa documentação mostra que os testes correspondem à finalidade, liga respostas a clientes a evidências controladas e ajuda a decidir se uma mudança de modelo, dados, limiar ou workflow exige nova avaliação. O avaliador recebe uma história coerente em vez de capturas sem contexto.

Ela conecta requisitos de produto, diagramas, model cards, linhagem de dados, avaliações, registro de riscos, testes de segurança, supervisão humana, logs, incidentes, aprovações de releases e monitoramento pós-mercado. Um índice central pode apontar para essas fontes sem duplicá-las.

O trabalho também apoia as novas expectativas de AI governance para fornecedores SaaS.

Confirme o escopo

Determine se o software é um sistema de IA, se é de alto risco e qual papel a empresa exerce. Quem desenvolve e comercializa sob seu nome pode ser fornecedor. Quem usa o sistema de terceiro pode ser responsável pela implantação, mas rebranding, modificação substancial ou nova finalidade podem mudar a análise.

O alto risco pode surgir do artigo 6(1) e anexo I para produtos regulados ou componentes de segurança, ou de um caso do anexo III sob o artigo 6(2). As diretrizes preliminares publicadas pela Comissão em maio de 2026 são úteis, mas não vinculantes.

O Regulamento (UE) 2026/1744 também alterou o calendário: as seções 1, 2 e 3 do capítulo III, incluindo o artigo 11, aplicam-se a partir de 2 de dezembro de 2027 aos sistemas do anexo III e de 2 de agosto de 2028 aos sistemas do anexo I. Outras leis, contratos ou compromissos com clientes podem exigir evidências semelhantes antes.

Não confunda este arquivo com os deveres separados dos fornecedores de modelos de IA de finalidade geral previstos no artigo 53 e anexo XI. As informações do fornecedor do modelo são um insumo; o fornecedor SaaS deve documentar o sistema completo, integração, finalidade, controles e desempenho avaliado.

O que o anexo IV espera

Use-o como matriz de cobertura:

1. Identidade e finalidade: fornecedor, nome, versão, usuários, objetivo, forma de entrega, interfaces, dependências e UI.
2. Desenvolvimento: métodos, componentes de terceiros ou pré-treinados, seleção do modelo, objetivos, premissas e decisões-chave.
3. Arquitetura: componentes, interações, recursos computacionais e justificativa das escolhas.
4. Dados: origem, seleção, rotulagem, limpeza, governance, limites e conjuntos de treinamento, validação, teste ou retrieval.
5. Capacidades e limites: métricas, precisão, robustez, cibersegurança, resultados indesejados previsíveis e degradação.
6. Testes: protocolos, dados, limiares, datas, versões, resultados, falhas e correções.
7. Risco e supervisão: risk management, mitigações, risco residual, supervisão humana e instruções.
8. Ciclo de vida: versões, logging, change management, manutenção, incidentes e monitoramento pós-mercado.
9. Conformidade: normas, especificações, declaração UE e documentos do organismo notificado, quando necessários.

Cada afirmação deve levar a uma evidência concreta. Uma referência a relatório, métrica aprovada, dataset, versão e limitação residual é verificável; “o sistema é robusto” não é.

Workflow operacional

1. Crie um índice controlado

Mantenha uma linha para cada elemento do anexo IV com requisito, aplicabilidade, fonte, responsável, versão, aprovação, última revisão e próximo gatilho. “Não aplicável” exige justificativa e aprovação. Controle de acesso, histórico e referências estáveis são essenciais.

2. Atribua evidências a quem as produz

Produto cobre finalidade, usuários, contexto e usos indevidos previsíveis. Engenharia cobre arquitetura, dependências, versões e mudanças. Dados ou ML cobre linhagem, desenvolvimento, avaliações e limites. Segurança cobre ameaças, acesso, resiliência e vulnerabilidades. Jurídico e compliance cobrem classificação, papéis, mapeamento regulatório e governo documental. Um responsável central coordena sem reescrever fatos não verificados.

3. Fixe a baseline antes dos testes

Defina finalidade e versão antes de aceitar resultados. Registre modelos, prompts relevantes, fontes de retrieval, feature flags, limiares, dependências e ambiente. Para sistemas probabilísticos, preserve versão do dataset, método, limite de aceitação, data, resultados reproduzíveis e limitações.

4. Conecte riscos, controles e testes

Cada risco material deve levar a mitigação, responsável e prova de eficácia. Se o controle é humano, descreva quem revisa, quais informações recebe, se pode rejeitar o output, como escala exceções e como a execução é comprovada.

5. Integre o arquivo às releases

Cada release substancial deve avaliar o impacto documental. Mudanças em finalidade, modelo, dados, limiar, usuários, países, integrações, supervisão ou segurança podem exigir novos testes e atualizações de riscos, instruções e análise de conformidade.

Checklist mínima

A equipe deve recuperar: descrição, papel e classificação aprovados; diagramas de arquitetura e fluxo com versões; registro de modelos, bibliotecas, APIs e dependências; origem e governance dos dados; planos, métricas, limiares, resultados e limites de avaliação; riscos ligados a controles e aceitações; evidências de supervisão humana; registros de segurança, robustez, logs, incidentes e monitoramento; instruções alinhadas ao sistema testado; histórico de releases e documentos de conformidade.

Erros comuns

Um template vazio produz generalidades sem prova. Uma model card não descreve o workflow SaaS completo. Documentos do vendor são insumos, não substituem a análise da integração. Esconder limites é menos defensável que explicá-los com controles. Um calendário não basta: releases, incidentes, novos dados, usos e mudanças regulatórias disparam revisão. Questionários, páginas de produto, instruções, riscos e arquivo técnico devem descrever o mesmo sistema.

Exemplo: triagem de candidatos assistida por IA

Para uma função que classifica candidaturas, o arquivo inclui finalidade, usos não suportados, workflow do cliente, pessoas afetadas, dados, lógica de ranking, versões, grupos avaliados, métricas, limiares, revisão humana, logs, segurança e monitoramento.

Se uma avaliação mostra recall menor para um grupo relevante, preserve resultado, análise, mitigação, novo teste e decisão de risco residual. Uma mudança posterior de modelo ou limiar deve reabrir esses elementos.

FAQ

Toda empresa SaaS precisa de um arquivo do anexo IV?

Não. O artigo 11 e o anexo IV tratam de sistemas de alto risco e da obrigação principal do fornecedor. Um registro proporcional continua útil para governance e avaliações de clientes.

Documentos de engenharia podem ser reutilizados?

Sim, se forem controlados e atuais, com índice que demonstre cobertura. Evite cópias divergentes.

Quem deve ser responsável?

Um owner nomeado coordena; produto, engenharia, ML/dados, segurança, jurídico e compliance mantêm a propriedade de suas evidências.

Quando atualizar?

Quando mudarem finalidade, versões, dados, integrações, usuários, desempenho, riscos, controles ou monitoramento, antes de releases substanciais e após incidentes.

O formulário simplificado para PMEs está disponível?

O artigo 11 prevê um formulário simplificado. Verifique os materiais oficiais atuais antes de usar um template. Até haver formulário aplicável, mantenha uma matriz completa do anexo IV com evidências proporcionais.

Fontes

• Regulamento (UE) 2024/1689, especialmente artigos 6, 9–17 e 43, e anexo IV.
• Regulamento (UE) 2026/1744 com as datas alteradas.
• Projeto de diretrizes da Comissão sobre classificação de alto risco, maio de 2026.
• Diretrizes da Comissão para fornecedores de modelos de IA de finalidade geral.