IA e controles internos: considerações sobre a SOX para equipes financeiras

Por Jane Ha · Atualizado em 11 de outubro de 2026

IA e controles internos é a pergunta sobre como uma ferramenta de IA que toca os relatórios financeiros se encaixa nos controles que uma empresa de capital aberto deve manter sob a SOX: quem é o responsável por ela, o que ela pode fazer, como a sua saída é revisada e que evidência prova que a revisão aconteceu. A IA não cria um novo conjunto de regras. Ela acrescenta um novo tipo de ator, que pode ser rápido, inconsistente e difícil de explicar, dentro de uma estrutura de controles desenhada em torno de pessoas e sistemas determinísticos.

Este guia é para controllers, CFOs, líderes de programas SOX e gerentes financeiros que estão implantando IA em processos como contas a pagar, conciliação bancária ou o fechamento mensal. Ele faz parte da coleção AI for Finance, então comece por IA em finanças e contabilidade se quiser ver primeiro o quadro mais amplo.

Fatos Principais

• As regras da SEC exigem que a administração de um emissor avalie os controles internos sobre relatórios financeiros (ICFR) ao final de cada exercício fiscal, usando uma estrutura de controles adequada e reconhecida, estabelecida por procedimentos de devido processo (17 CFR 240.13a-15).
• A AS 2201 do PCAOB define deficiência material como uma deficiência, ou combinação de deficiências, nos ICFR que cria uma possibilidade razoável de que uma distorção relevante não seja prevenida ou detectada em tempo hábil (PCAOB AS 2201).
• A publicação do COSO de fevereiro de 2026, Achieving Effective Internal Control Over Generative AI, aplica os cinco componentes do Internal Control-Integrated Framework e classifica os casos de uso de IA generativa em oito tipos de capacidade (Journal of Accountancy).
• Em seu Spotlight de julho de 2024, a equipe do PCAOB relatou que as firmas de auditoria esperam que a IA generativa complemente os humanos, e não os substitua, e que as firmas não viam as normas de auditoria do PCAOB como obstáculos ao seu uso (PCAOB).
• Sob a AS 2201, um auditor só pode usar o "benchmarking" para um controle de aplicação totalmente automatizado se os controles gerais sobre mudanças em programas, acesso a programas e operações de computador forem eficazes e se o controle não tiver mudado desde que a linha de base foi definida (PCAOB AS 2201).

Por que a IA é uma questão de SOX, e não só de TI

A seção 404 da SOX coloca a responsabilidade sobre a administração. A regra da SEC exige que a administração avalie os ICFR a cada ano com base em uma estrutura reconhecida. O Internal Control-Integrated Framework do COSO é o que a maioria das equipes financeiras conhece. Se uma ferramenta de IA prepara um lançamento contábil, concilia uma linha bancária, redige uma divulgação ou classifica uma fatura, a sua saída flui para as demonstrações financeiras, e o ambiente de controle ao redor dela entra no escopo.

O Spotlight da equipe do PCAOB é útil aqui porque descreve o que os preparadores já vinham dizendo. Alguns usavam IA generativa para primeiras versões de documentos internos e para trabalhos repetitivos e menos complexos, como a preparação de conciliações de contas. Os preparadores também apontaram a natureza de "caixa-preta" de algumas ferramentas e a saída inconsistente, o que levanta dúvidas sobre a auditabilidade do que a ferramenta produz. E alguns auditores observaram que o uso de IA generativa pelos preparadores poderia amplificar riscos de TI já existentes, como a segregação de funções, ou criar riscos que não existiam antes.

Esses três pontos estruturam o restante deste guia: uma ferramenta usada em trabalho contábil real, uma saída que varia e riscos de controle antigos em lugares novos.

Como a AS 2201 trata a tecnologia (e por que isso importa para a IA)

A AS 2201 é a norma que os auditores externos seguem ao auditar os ICFR. Três de suas ideias moldam como os auditores vão olhar para a IA.

Uma abordagem top-down. O auditor parte do nível das demonstrações financeiras e foca nos controles em nível de entidade antes de descer até as contas significativas e suas asserções relevantes (PCAOB AS 2201). Uma ferramenta de IA que fica em um canto não financeiro e de baixo risco do negócio talvez nunca seja testada. Uma que fica dentro de uma conta significativa será.

A TI não é avaliada separadamente. A norma diz que o auditor deve entender como a TI afeta o fluxo de transações da empresa e que identificar riscos e controles dentro da TI é "parte integrante da abordagem top-down", e não uma avaliação separada. Para você, isso significa que um sistema de IA deve ser avaliado como parte do processo que ele apoia, e não em uma revisão de tecnologia isolada.

Controles automatizados dependem dos controles gerais. A AS 2201 diz que um controle automatizado geralmente teria risco menor se os controles gerais de TI relevantes forem eficazes, e permite o benchmarking de controles de aplicação totalmente automatizados quando os controles de mudança de programas, acesso e operações se mantêm. É aqui que a IA fica incômoda. Um controle automatizado tradicional se comporta do mesmo modo todas as vezes, então uma linha de base continua válida até alguém mudar o código. Um modelo cujo comportamento muda com uma atualização do fornecedor, novos dados de treinamento ou um prompt alterado não dá ao auditor esse conforto. Planeje tratar as mudanças de modelo e de prompt como você trataria mudanças de código.

Onde a IA toca o ambiente de controle

A orientação do COSO sobre IA generativa mapeia os controles pelos cinco componentes da estrutura (ambiente de controle, avaliação de riscos, atividades de controle, informação e comunicação, e monitoramento) e agrupa os casos de uso em oito tipos de capacidade: ingestão, transformação, lançamento, orquestração, julgamento, monitoramento, inteligência regulatória e interação humano-IA (Journal of Accountancy). A publicação inclui exemplos, expectativas mínimas de controle e métricas ilustrativas para cada capacidade. O COSO também publicou antes uma orientação complementar sobre automação robótica de processos, que as equipes financeiras com automações mais antigas podem ler junto com ela.

A tabela abaixo aplica esse raciocínio por capacidade ao trabalho financeiro comum. É uma ilustração de como organizar a sua própria análise, não uma cópia do mapeamento do COSO.

As perguntas de desenho de controle a fazer sobre cada ferramenta de IA

Quando uma ferramenta chega a um processo financeiro, submeta-a às mesmas perguntas que você faria sobre qualquer controle, mais algumas específicas de IA.

1. Qual é o seu papel: preparadora, revisora ou nenhum dos dois? Uma IA que redige é uma preparadora. Uma IA que revisa o trabalho de outra IA não é uma revisão independente no sentido da SOX, a menos que uma pessoa seja dona da conclusão.
2. O que o revisor humano realmente confere? Um controle que diz "o controller revisa a saída da IA" é fraco se o revisor vê apenas um resumo. Defina o que ele examina, que limite dispara um olhar mais atento e o que ele faz quando algo está errado.
3. Em que informação o controle se apoia? Se a verificação de um revisor depende de um relatório que a IA produziu, a completude e a exatidão desse relatório fazem parte do controle.
4. A saída é repetível? Se a mesma entrada pode gerar saídas diferentes, diga isso na descrição do controle e desenhe a revisão para pegar a variação.
5. Quem pode alterá-la? Modelos, prompts, fontes de recuperação e regras de negócio são configuração. Precisam de responsáveis e de registros de mudança. Trate prompts, conectores de recuperação e regras de transformação como configurações governadas.
6. O que acontece quando ela erra ou fica fora do ar? Nomeie o plano manual de contingência e a pessoa que pode pausar a ferramenta.

Controles gerais de TI para IA

Os controles gerais de TI (ITGC) cobrem o ambiente em torno das aplicações: acesso, gestão de mudanças e operações. A IA não os substitui. Ela os estica.

• Gestão de acesso. Limite quem pode usar a ferramenta, que dados ela pode ler e o que ela pode gravar. Uma conta de serviço que pode criar e aprovar um lançamento condensa a segregação de funções em uma única credencial. O Spotlight do PCAOB registra a preocupação dos auditores de que a IA poderia amplificar exatamente esse tipo de risco.
• Gestão de mudanças. Acompanhe as versões do modelo, as mudanças de prompt, as mudanças nas fontes de recuperação e as atualizações do fornecedor. Teste antes da liberação em um ambiente que não seja de produção. O Spotlight do PCAOB observa que alguns preparadores rodam a nova tecnologia em um ambiente paralelo antes da implantação, o que é um bom hábito aqui.
• Operações e monitoramento. Registre entradas, saídas e correções manuais. Fique atento à deriva: mudanças bruscas no volume, nos valores ou nas taxas de correção são sinais precoces de que o comportamento mudou.
• Risco de terceiros e de dados. Se um fornecedor hospeda o modelo, entenda que dados financeiros saem do seu ambiente e como o fornecedor os trata. O Spotlight mostra firmas definindo limites sobre o que pode ser enviado a ferramentas de IA para evitar que dados confidenciais se tornem públicos, e as equipes financeiras precisam da mesma regra para os dados do razão e as informações bancárias.

Evidência: o que um auditor vai querer ver

A evidência é onde os projetos de IA costumam ficar devendo, porque a ferramenta é feita para economizar tempo e ninguém constrói a trilha de auditoria. Planeje isso desde o início. O Spotlight descreve firmas que projetam suas próprias ferramentas de IA para documentar os dados de origem usados, e o mesmo princípio vale para a sua.

Quanto às entradas em si, a prontidão dos dados financeiros trata da qualidade dos dados que cada um desses controles pressupõe.

Como incluir uma ferramenta de IA no seu programa SOX, passo a passo

1. Faça o inventário de todos os usos de IA em finanças. Inclua as ferramentas compradas por equipes individuais e os recursos ativados dentro dos sistemas existentes. Mantenha-o atualizado, porque novos usos surgem o tempo todo.
2. Classifique por nível conforme o impacto nos relatórios financeiros. A saída chega a uma conta significativa, a uma divulgação ou a uma estimativa? As ferramentas que não chegam podem seguir uma política mais leve.
3. Atribua um responsável a cada ferramenta. Uma pessoa nomeada responde pelo escopo, pelas mudanças e pelo monitoramento.
4. Documente o processo e o controle. Atualize a narrativa e a matriz de riscos e controles para mostrar onde a IA está, o que ela faz e quem a revisa. Seja específico sobre a revisão.
5. Separe as funções. A IA não deve preparar e aprovar o mesmo item, e nenhuma conta isolada deve ter os dois direitos.
6. Monte a cobertura de ITGC. Acesso, gestão de mudanças, registro e revisão do fornecedor para a ferramenta e sua configuração.
7. Teste antes de entrar em produção. Rode em paralelo com o processo existente por alguns ciclos e compare linha a linha. Registre os resultados como evidência.
8. Converse cedo com o seu auditor externo. Compartilhe o desenho antes de o controle entrar no ar, e não nos walkthroughs do fim do ano. Para a visão da auditoria interna, veja IA na auditoria interna.
9. Monitore e refaça os testes. Acompanhe as taxas de correção, as exceções e a precisão. Repita os testes quando o modelo, o prompt ou a fonte de dados mudar.

Erros comuns

• Tratar "uma pessoa revisa" como o controle. Sem uma revisão definida, um limite e um registro, não há controle a testar.
• Deixar a IA ser dona de uma aprovação. A aprovação automática de um lançamento pelo mesmo sistema que o preparou é uma deficiência de segregação de funções esperando para ser encontrada.
• Ignorar mudanças de configuração. Uma edição de prompt ou uma atualização do modelo do fornecedor pode mudar o comportamento sem liberação de código e sem chamado.
• Nenhum inventário. A IA paralela (shadow AI) em uma equipe financeira é um risco que você não consegue avaliar se não sabe que ele existe.
• Evidência depois do fato. Registros e anotações de revisores são difíceis de reconstruir meses depois. Capture-os enquanto o controle roda.
• Supor que a garantia do fornecedor cobre você. Um relatório do fornecedor pode ajudar, mas os seus controles sobre como você usa a ferramenta continuam sendo seus.
• Esquecer a fraude. Os modelos podem ser mal utilizados ou manipulados. Veja detecção de fraude com IA em finanças para entender como a IA corta nos dois sentidos.
• Negligenciar as áreas de julgamento. Receita e áreas com muitas estimativas exigem cuidado extra; IA no reconhecimento de receita mostra onde está o julgamento.

O que medir

• Cobertura: parcela dos casos de uso de IA inventariados, com responsável e classificados por nível.
• Desempenho do controle: exceções pegas pelos revisores, taxa de correção e o tempo para resolver cada uma.
• Precisão: taxa de erro contra os documentos de origem ou os valores realizados, por ferramenta.
• Disciplina de mudanças: mudanças de modelo, prompt e regras feitas com aprovação versus sem ela.
• Prontidão de evidências: parcela dos controles com registros e aprovações completos no fim do trimestre.

Próximos passos

Se você fizer uma única coisa neste trimestre, monte o inventário e classifique cada ferramenta conforme ela chegue ou não a uma conta significativa. Depois reforce a etapa de revisão das ferramentas de nível mais alto e comece a registrar evidências já. Em seguida, decida quem é responsável por qual controle à medida que o trabalho se desloca, e deixe isso por escrito.