I. A Pergunta que Determina a Defesa
Em 1996, o Vice-Chanceler Allen, da Court of Chancery de Delaware, formulou uma pergunta que moldou três décadas de direito fiduciário corporativo: o board tinha, antes do incidente, um sistema de informação e reporte adequado para detectar o problema? A decisão In re Caremark International Inc. Derivative Litigation, 698 A.2d 959 (Del. Ch. 1996), não puniu diretores por um dano que não preveniram.
O que Caremark estabeleceu foi o padrão pelo qual a ausência de um sistema de monitoramento adequado pode, por si só, constituir falha fiduciária. Trinta anos depois, o Oxford Business Law Blog (jan/2026) publicou o argumento que a academia tem chamado de BJR 2.0: diretores serão avaliados não apenas por ter aprovado políticas, mas por terem compreendido e governado as tecnologias que suas organizações utilizam.
A Business Judgment Rule — o escudo clássico de proteção de diretores que decidem de boa-fé com base em informação razoável — está sendo reinterpretada no contexto de IA. O escudo ainda existe. O que mudou é o que o board precisa demonstrar para invocá-lo, e essa mudança não é cosmética: altera a natureza da prova que o Conselho precisa ter guardado antes do incidente.
O Richmond Journal of Law & Technology (jan/2026) identificou uma lacuna doutrinária relevante: a seção 141(e) da lei societária de Delaware, que protege diretores que confiam em pessoas com competência profissional, pressupõe um sistema de informação operado por humanos. Quando quem informa o board é um algoritmo — capaz de derivar do que foi aprovado sem decisão humana explícita —, a proteção clássica deixa de se encaixar com a mesma precisão.
[Ponto de Inflexão Fiduciária]: A governança de IA da sua organização está documentada em políticas — mas essa documentação é um retrato do que de fato ocorre, ou uma declaração de intenção que nenhum processo verifica?
II. A Evolução do Padrão — De Caremark à Supervisão Informada
O padrão Caremark opera em dois níveis. No primeiro, o board tem o dever de estabelecer sistemas de informação e reporte que permitam detectar riscos materiais antes que se tornem crises. No segundo, tem o dever de agir quando esses sistemas produzem sinais de alerta — e a omissão diante de red flags conhecidos é tratada pelos tribunais como falha fiduciária independente.
Ambos os níveis se tornam mais exigentes quando a organização depende de IA para decisões materiais. O sistema de reporte precisa incluir o monitoramento do comportamento algorítmico, não apenas dos resultados financeiros. E os red flags passam a incluir sistemas operando fora dos parâmetros aprovados sem que nenhum humano tenha decidido expandir seu escopo.
O Chief Justice da Supreme Court de New South Wales (mai/2026) articulou o princípio com precisão que transcende jurisdição: “Artificial intelligence is not a technology issue to be delegated to senior managers.” A afirmação é uma posição sobre onde reside o dever fiduciário. Quando sistemas de IA tomam ou influenciam decisões materiais, a responsabilidade de oversight não se delega ao CTO ou ao Chief AI Officer: ela repousa no board.
O que os tribunais estão consolidando separa duas situações. Na primeira, o board exerceu supervisão informada: entendeu a função objetivo antes de aprovar, definiu parâmetros documentados, nomeou proprietários e recebe métricas regularmente. Na segunda, aprovou o projeto e delegou, sem nada disso registrado. O padrão Caremark aplicado a IA distingue as duas de um modo que a versão clássica da Business Judgment Rule não cobre por completo.
Oxford Business Law Blog (jan/2026): dois deveres emergentes — AI due care (compreensão da função objetivo antes do deployment) e AI loyalty oversight (monitoramento contínuo de que o sistema opera dentro dos parâmetros aprovados). Richmond Journal of Law & Technology (jan/2026): a seção 141(e) de Delaware protege quem confia em “pessoas” com competência profissional — a IA não se encaixa na categoria. Chief Justice da Supreme Court de NSW (mai/2026): IA não é questão tecnológica a ser delegada a gestores seniores.
[Ponto de Inflexão Fiduciária]: Se o comitê de auditoria fosse chamado hoje a demonstrar os dois níveis do padrão Caremark para os sistemas de IA em produção, teria o sistema de reporte e o registro de resposta a alertas — ou apenas a ata que aprovou os projetos?
III. Custódia Arquitetada e a Lacuna entre Política e Custódia
A Custódia Arquitetada é o sistema de responsabilidade projetado antes que o agente execute, não reconstituído depois que o dano ocorre. O termo distingue duas abordagens que, vistas de fora, parecem idênticas — ambas têm política aprovada, comitê de IA e disclosure em relatório anual —, mas que produzem resultados radicalmente diferentes diante de um tribunal, de um regulador ou de uma seguradora de D&O.
Na Custódia Arquitetada, o board entra no deployment tendo documentado quatro elementos anteriores à operação: a função objetivo que o sistema otimiza; o blast radius aprovado, isto é, o alcance máximo de impacto dentro dos parâmetros autorizados; o proprietário nomeado, com autoridade e responsabilidade definidas; e os parâmetros de monitoramento, incluindo os escalation triggers que disparam revisão humana obrigatória.
Na abordagem alternativa — que os dados da McKinsey (2024) sugerem descrever os 85% de boards que não recebem métricas de IA regularmente — o deployment é aprovado como projeto de tecnologia. A aprovação existe, mas o risco de o sistema operar fora do que o board imaginou não é gerido por um sistema de custódia: é gerido pela expectativa de que ele funcione como descrito na apresentação de aprovação.
A diferença é probatória, não filosófica. Quando um litígio ou uma investigação pergunta se havia sistema de custódia adequado antes do incidente, a Custódia Arquitetada produz documentação com data anterior ao deployment. A alternativa produz a política aprovada — que os tribunais têm tratado como condição necessária, mas insuficiente, para caracterizar supervisão informada.
O CB Financial Form 8-K (mai/2026) documenta o padrão em sua expressão mais limpa: shadow AI não inventariada ingeriu dados confidenciais de clientes, nenhum executivo sabia que a ferramenta estava em uso e o board não tinha inventário de sistemas de IA. O disclosure obrigatório como “material cybersecurity incident” não resultou de um sistema sofisticado que falhou, mas da ausência de um sistema básico de custódia.
A organização consegue produzir a política aprovada em ata, o relatório de consultoria que a fundamentou e a apresentação de aprovação do sistema — que descreve capacidades em linguagem comercial, não a função objetivo efetivamente otimizada. Não consegue produzir nenhum registro, anterior ao deployment, de que o board questionou e compreendeu essa função objetivo, os parâmetros de operação ou o blast radius.
O tribunal não precisa decidir se o board sabia do problema. Basta constatar que não existia o sistema que o padrão Caremark exige — e que a política, sem o processo operacional que a tornasse verificável, era declaração de intenção sem lastro de custódia.
[Ponto de Inflexão Fiduciária]: A sua organização tem aprovação de projeto de IA — ou tem documentação de Custódia Arquitetada, com proprietário, blast radius e parâmetros de monitoramento datados antes do deployment de cada sistema?
IV. Da Origem à Arquitetura — O Que o Board Faz com Isso
A origem da accountability ativa não é um problema novo. É a aplicação de um dever fiduciário existente — estabelecer sistemas adequados de informação e reporte — a uma tecnologia que desafia os mecanismos de supervisão que os boards construíram ao longo de décadas.
Sugerimos observar que a Custódia Arquitetada não exige que o board se torne tecnicamente sofisticado em inteligência artificial. Exige que faça, para sistemas de IA, o que Caremark estabeleceu para qualquer risco material: garantir um sistema de reporte com parâmetros definidos, responsáveis nomeados, métricas chegando ao nível correto e protocolo de escalonamento para quando os parâmetros são excedidos.
Recomendamos distinguir o que o board precisa saber do que precisa garantir que a gestão demonstre. O Conselho não precisa entender o funcionamento interno do modelo; precisa entender a função objetivo — o que o sistema maximiza — e as fronteiras dentro das quais está autorizado a operar. Essa compreensão, documentada com data anterior ao deployment, é o primeiro elo da Custódia Arquitetada.
☐ Sugere-se que todo deployment de sistema de IA inclua documentação prévia da função objetivo aprovada e do blast radius — em linguagem que o board compreende, não apenas a equipe técnica.
☐ Recomenda-se que o inventário algorítmico seja apresentado ao board em base regular, atualizado a cada novo sistema ou atualização relevante do fornecedor, com proprietário nomeado em ata para cada sistema.
☐ Orienta-se estabelecer a expectativa de que métricas de IA cheguem ao board em cadência definida, com sinalização clara de quais indicadores saíram dos parâmetros aprovados e de quem foi notificado.
V. O Teste do Ácido
Se um regulador — CVM, ANPD, SEC ou CADE — intimar a sua diretoria na próxima semana útil e pedir evidência de supervisão informada sobre os sistemas de IA em operação, a organização produzirá documentação com data anterior ao deployment — função objetivo aprovada, blast radius mapeado, proprietário nomeado, métricas definidas —, ou o Conselho vai descobrir que só tem a política de governança de IA e a ata que aprovou o projeto?
🏛️ Biblioteca: Metodologia Prática
Protocolo de Custódia Arquitetada
Este protocolo organiza o roteiro mínimo para que a aprovação de um sistema de IA produza, desde o primeiro dia, a evidência datada que o padrão Caremark aplicado a IA exige.
01. Os Registros Anteriores ao Deployment
- Função Objetivo: descrição, em linguagem não técnica, do que o sistema está instruído a maximizar, aprovada e datada antes da entrada em produção.
- Blast Radius e Proprietário: alcance máximo de impacto dentro dos parâmetros autorizados, com o nome de quem responde pelo sistema e tem autoridade para interrompê-lo.
- Monitoramento e Escalonamento: métricas que chegarão ao board, com cadência, limites de tolerância e os escalation triggers que disparam revisão humana obrigatória.
02. Matriz de Evidência Fiduciária
| Nível do Dever Caremark | Evidência Esperada | Ação de Custódia Recomendada |
|---|---|---|
| Sistema de reporte | Inventário algorítmico com proprietário e blast radius por sistema | Aprovar o inventário em ata e revisá-lo em cadência definida |
| Resposta a alertas | Registro de escalonamentos e decisões tomadas | Exigir que alertas fora dos parâmetros cheguem ao comitê com prazo |
| Compreensão prévia | Função objetivo documentada antes do deployment | Condicionar a aprovação de sistemas materiais a esse registro |
03. Glossário
AI due care: dever emergente, descrito pelo Oxford Business Law Blog, de compreender a função objetivo de um sistema de IA antes de autorizar sua entrada em operação.
AI loyalty oversight: dever emergente de acompanhar continuamente se o sistema permanece dentro dos parâmetros que o Conselho aprovou.
Blast radius: a extensão máxima de impacto que um sistema pode produzir dentro dos parâmetros autorizados — a medida que orienta o nível de autorização e a cadência de revisão.
Board: o Conselho de Administração, instância em que repousa o dever fiduciário de supervisão.
Business Judgment Rule: a presunção que protege diretores que decidem de boa-fé, com informação razoável e dentro de seus poderes; a BJR 2.0 é a leitura que exige, no contexto de IA, demonstração de compreensão da tecnologia.
Caremark: precedente de Delaware (1996) segundo o qual a ausência de sistema adequado de monitoramento pode, por si só, configurar falha fiduciária.
Chief Justice: o magistrado que preside uma corte superior — aqui, a Supreme Court de New South Wales, na Austrália.
CTO: o executivo responsável pela tecnologia, a quem a supervisão fiduciária de IA não pode ser simplesmente delegada.
Custódia Arquitetada: o sistema de responsabilidade projetado antes que o agente execute, verificável por documentação datada, proprietários nomeados, parâmetros definidos e métricas em funcionamento.
D&O: o seguro de responsabilidade civil de diretores e administradores, cuja subscrição passa a considerar a qualidade da supervisão de IA.
Deployment: a entrada de um sistema em operação real, momento a partir do qual seus resultados produzem efeitos sobre o negócio.
Discovery: a fase processual em que as partes são obrigadas a apresentar documentos e registros relevantes ao litígio.
Disclosure: a divulgação obrigatória de informação relevante ao mercado ou ao regulador.
Escalation triggers: as condições previamente definidas que obrigam a levar um desvio à revisão humana, sem depender de que alguém o perceba.
Form 8-K: o formulário pelo qual companhias abertas nos Estados Unidos comunicam à SEC eventos relevantes, como incidentes materiais de cibersegurança.
Função objetivo: aquilo que o algoritmo está matematicamente instruído a maximizar — e que determina seu comportamento em situações não previstas.
Oversight: a supervisão ativa exercida pelo Conselho sobre riscos e sistemas da organização.
Red flags: sinais de alerta conhecidos cuja falta de resposta os tribunais tratam como falha fiduciária própria.
Shadow AI: ferramentas de IA adotadas por equipes sem aprovação formal, fora do inventário e sem proprietário nomeado.