I. A Dívida Técnica que a Aprovação Sozinha Acumula
A arquitetura de custódia precede a governança demonstrável. O board que aprova o deployment de um sistema de IA sem exigir que essa arquitetura esteja em pé aprova um sistema sobre o qual, depois, não terá como demonstrar supervisão — terá apenas como demonstrar que houve aprovação.
A diferença é técnica antes de ser jurídica. Supervisão demonstrável depende de registro: o que o sistema fez, com qual autorização, em qual versão e como a organização respondeu. Nada disso pode ser reconstituído depois do incidente se a infraestrutura que o produz não foi configurada antes.
Os cinco instrumentos deste blueprint são os elementos que o Conselho pode requerer como pré-condição ao deployment de qualquer sistema de IA material. São específicos o suficiente para a engenharia implementar e verificáveis o suficiente para o board auditar.
[Ponto de Inflexão Fiduciária]: Para o próximo sistema de IA material que sua organização colocará em produção, os requisitos de custódia estão na especificação técnica — ou apenas na política de governança?
II. Fundamentos Normativos e a Segregação de Funções Algorítmica
O primeiro instrumento é a segregação de funções aplicada ao ciclo de vida de sistemas de IA. A segregação de funções é princípio clássico de controle interno: quem inicia uma operação não deve ser quem a aprova. No contexto algorítmico, o risco que ela endereça não é fraude, mas deriva de função objetivo sem supervisão independente.
Quatro funções precisam ser distinguíveis. A definição da função objetivo — quem decide o que o sistema maximiza. A validação técnica — quem verifica que a função foi implementada como definida e testa resultados problemáticos. A aprovação de deployment — quem autoriza a produção, com quais parâmetros e qual blast radius. E o monitoramento em produção — quem acompanha o comportamento e tem autoridade para pausar.
Em organizações menores, as mesmas pessoas podem exercer mais de uma função; o que a segregação proíbe é que uma única função indistinta agrupe as quatro, tornando impossível identificar, em caso de incidente, qual delas falhou. O board exerce a quarta função — e, sem métricas em cadência definida, tem apenas a aparência dela.
NIST AI RMF 1.0 (NIST AI 100-1, jan/2023, em revisão): define quatro funções de gestão de risco de IA — Govern, Map, Measure e Manage — com requisitos de documentação, responsabilidade nomeada e avaliação de impacto; a adoção não é exigência legal, mas é evidência de cuidado razoável amplamente reconhecida. ISO/IEC 42001:2023: primeiro padrão internacional de sistema de gestão para inteligência artificial, com requisitos de documentação, controle e auditoria. Oxford Business Law Blog (jan/2026): tribunais esperam de boards a evidência de processo informado que os padrões técnicos descrevem, não apenas a aprovação do resultado.
[Ponto de Inflexão Fiduciária]: Nos sistemas materiais da sua organização, é possível dizer quem exerceu cada uma das quatro funções — ou todas elas estão concentradas na mesma equipe, sem registro separado?
III. Audit Trail Obrigatório e a Metodologia de Blast Radius
O segundo instrumento é o audit trail. Não é o log técnico do servidor: é o registro legível por profissionais de governança que permite reconstruir o que o sistema fez, com qual autorização, em qual versão e como a organização respondeu.
Por evento, o audit trail captura a decisão ou recomendação produzida, com data e hora; o contexto de entrada, identificando tipo e origem do dado, sem armazenar dado pessoal além do que a regulação permite; a ação da pessoa responsável — aceitou, recusou ou modificou; a versão do modelo, incluindo componentes de terceiros; e a configuração ativa no momento.
Por evento de configuração, registra cada atualização de versão com responsável e avaliação de impacto na função objetivo, cada acionamento do protocolo de escalação com a resposta dada, e cada decisão de manter o sistema em operação após anomalia, com justificativa. Relatórios de progresso, atas de aprovação e trocas de e-mail não são audit trail.
A ISO/IEC 42001:2023 exige retenção de informação documentada compatível com o ciclo de responsabilidade aplicável; esta série recomenda, para sistemas com blast radius material, retenção mínima de cinco anos, com acesso controlado e integridade verificável — porque registro alterável retroativamente não é evidência.
O terceiro instrumento é a metodologia de blast radius. O blast radius é o alcance máximo de impacto que o sistema pode produzir dentro dos parâmetros autorizados, considerando o pior resultado possível dentro do que ele está autorizado a fazer.
O mapeamento percorre cinco etapas: escopo de decisão, com população afetada e impacto unitário máximo; agregação, projetando o impacto total se o pior resultado persistir pelo período máximo antes da detecção; classificação de risco em baixo, médio ou material; calibração de controles proporcional à classe; e revisão por gatilho, quando escopo, volume ou função objetivo mudam.
O NIST AI RMF chama esse exercício de avaliação de impacto e o situa na função Map. Vale registrar o que a jurisprudência acrescenta: a avaliação que não chega ao board antes do deployment não produz defesa fiduciária, porque o que o tribunal verifica é se o Conselho compreendeu o risco que aprovava.
Dezoito meses depois, o sistema atende quatro áreas, foi integrado a dois outros sistemas e processa dezenas de milhares de decisões mensais. Nenhuma decisão explícita ampliou seu escopo: a adoção cresceu por conveniência, uma equipe após a outra, e nenhum gatilho de recálculo foi acionado.
Quando um resultado sistematicamente incorreto é detectado, o board descobre que os controles vigentes eram os de um sistema de risco médio, enquanto o blast radius real já era material havia meses. A falha não estava no modelo, e sim na ausência do gatilho que obrigaria a reclassificar — e a reclassificação é o que teria exigido Ponto de Intervenção, retenção estendida e reporte mensal.
[Ponto de Inflexão Fiduciária]: Algum sistema da sua organização opera hoje com controles calibrados para a classe de risco que ele tinha na aprovação, e não para a que tem agora?
IV. Pausa Legível e a Matriz de Custódia
O quarto instrumento é a pausa legível — a legible friction do World Economic Forum traduzida em requisito de implementação. Um ponto de pausa que se resolve com a confirmação de um botão não é pausa legível: é interrupção nominal que não produz supervisão.
Sugerimos quatro condições para que a pausa seja legível: quem autoriza compreende, em linguagem não técnica, o que o sistema propõe fazer; tem informação suficiente para decidir, e não apenas para confirmar recebimento; tem autoridade real de recusa, sem que a recusa crie obstrução que pressione pela aprovação; e a autorização é registrada com identidade, data, hora e ação autorizada.
Quatro antipadrões recorrentes merecem atenção: a confirmação em lote, em que centenas de recomendações são aprovadas com um clique; a notificação de continuação, em que o silêncio vira autorização; a pausa sem informação, que pergunta “continuar?” sem dizer o que vem depois; e o prazo impossível, que exige em minutos uma decisão que demandaria horas de análise.
Recomendamos calibrar a implementação por categoria de ação: ações de baixo impacto executam de forma autônoma com registro; ações de impacto moderado são propostas e autorizadas por lote, com amostra revisada individualmente; ações de alto impacto individual exigem revisão caso a caso; e ações fora dos parâmetros aprovados param até escalação documentada.
O quinto instrumento é a Matriz de Custódia, que integra os quatro anteriores em requisitos mínimos por classe de risco. Sistemas de baixo risco pedem entrada básica no inventário, proprietário identificável, escopo documentado e reporte anual. Sistemas de risco médio pedem função objetivo documentada, proprietário com autoridade de pausa, audit trail obrigatório com retenção mínima de três anos e reporte trimestral.
Sistemas materiais pedem histórico de versões no inventário, proprietário com autoridade de pausa e dever de escalação, blast radius aprovado pelo board antes do deployment, audit trail com cinco anos e integridade verificável, Pontos de Intervenção definidos e reporte mensal ou por evento. A matriz não é estática: quando o sistema muda de classe, os controles da nova classe precisam existir antes de ele continuar operando.
☐ Sugere-se exigir, como pré-condição de deployment de sistema material, as quatro funções segregadas e documentadas, o audit trail configurado e o blast radius aprovado pelo board.
☐ Recomenda-se submeter os pontos de pausa a teste de legibilidade — informação suficiente, autoridade real de recusa e registro da autorização — rejeitando confirmações em lote e prazos incompatíveis com análise.
☐ Orienta-se adotar a Matriz de Custódia como referência de controles por classe de risco e requerer notificação ao Conselho sempre que um sistema migrar de classe.
V. O Teste do Ácido (Code Review)
Se um auditor técnico independente abrir hoje a arquitetura dos seus sistemas materiais de IA, encontrará as quatro funções segregadas com registro, o audit trail dos últimos doze meses, o blast radius aprovado e a autorização humana registrada nos pontos de pausa, ou o Conselho vai descobrir que a documentação que o tribunal pediria precisa ser produzida às pressas depois do incidente?
🏛️ Biblioteca: Metodologia Prática
Especificação Técnica da Arquitetura de Custódia
Esta especificação resume o que a engenharia precisa entregar e o que o Conselho precisa verificar antes de autorizar a produção de um sistema de IA material.
01. Checklist Técnico de Pré-Deployment
- Funções Segregadas: função objetivo, validação, aprovação e monitoramento registrados separadamente, com responsável identificável em cada uma.
- Audit Trail Configurado: eventos de decisão e de configuração capturados, com versão do modelo, configuração ativa e integridade verificável.
- Blast Radius Classificado: impacto agregado calculado, classe de risco definida, controles calibrados e gatilhos de recálculo escritos.
02. Matriz de Custódia por Classe de Risco
| Classe | Audit Trail | Pausa e Reporte |
|---|---|---|
| Baixo | Recomendado; escalações sempre registradas | Sem pausa obrigatória; reporte anual |
| Médio | Obrigatório, retenção mínima de três anos | Pausa em ações de impacto moderado; reporte trimestral |
| Material | Obrigatório, cinco anos, integridade verificável | Pontos de Intervenção definidos; reporte mensal ou por evento |
03. Glossário
Audit trail: o registro contínuo e legível para governança do que o sistema fez, em qual versão e com qual autorização.
Blast radius: o alcance máximo de impacto de um sistema dentro dos parâmetros autorizados, base da classificação de risco.
Board: o Conselho de Administração, que exerce a função de monitoramento na segregação algorítmica.
Deployment: a entrada de um sistema em operação real.
Framework: o conjunto estruturado de práticas de gestão de risco, como o NIST AI RMF.
Função objetivo: aquilo que o algoritmo está matematicamente instruído a maximizar.
ISO/IEC 42001:2023: o primeiro padrão internacional de sistema de gestão de inteligência artificial, com requisitos de documentação, controle e auditoria.
Legible friction: a pausa projetada na arquitetura de decisão em que a autorização humana precisa ser informada, e não mera confirmação.
Matriz de Custódia: a referência editorial desta série que define controles mínimos por classe de risco do sistema.
NIST AI RMF: o framework de gestão de risco de IA do instituto de padrões norte-americano, organizado nas funções Govern, Map, Measure e Manage.
Ponto de Intervenção: o momento em que a supervisão humana é obrigatória antes de uma ação de alto impacto.
SoD: a segregação de funções — princípio de controle interno pelo qual iniciar e aprovar uma operação não cabem à mesma função.
XAI: a inteligência artificial explicável, que registra de forma compreensível o raciocínio de uma recomendação.