A auditoria apoiada exclusivamente em planilhas e extrações manuais já não acompanha o volume e a velocidade das operações corporativas. Os métodos estritamente manuais e retrospectivos perdem tempestividade em ambientes nos quais milhares de transações de múltiplas fontes são processadas instantaneamente em nuvem, de um controle de estoque a uma liquidação financeira em milissegundos.
Diante dessa complexidade sistêmica, o papel da Auditoria Interna — fundamentado nas novas Global Internal Audit Standards (GIAS) do IPPF, no COSO (tanto em ERM quanto no ICIF) e em normas como a ISO 31000 e a ISO/IEC 27001 — deve ir além da verificação de conformidade histórica e ter como objetivo escalar o valor entregue à organização. Para isso, as áreas de Auditoria e GRC buscam estruturar ciclos de auditoria contínua para liberar os auditores das rotinas puramente operacionais e concentrar o tempo analítico no julgamento profissional, no ceticismo e na investigação — funções que as máquinas não exercem.
Da amostragem à população total: o papel da esteira de dados e do RPA
Historicamente, limitações de recursos humanos e computacionais levaram a auditoria a se apoiar em procedimentos retrospectivos, manuais e baseados em amostragem. Contudo, esse modelo apresenta limitações frente à velocidade transacional contemporânea, reduzindo a tempestividade na detecção e mitigação de riscos corporativos. Hoje, a construção de uma esteira integrada de dados e analytics, que combina extrações diretas, tratamento automatizado e scripts de validação, viabiliza que testes de detalhes, avaliações de controles gerais de TI (ITGC) e conciliações migrem da amostragem para a análise de 100% da população.
Nesse ecossistema, a Automação de Processos Robóticos (RPA) cumpre um papel específico e complementar. Diferente de grandes reestruturações sistêmicas (como a troca de um ERP), o RPA atua por meio de instâncias de software configuradas na camada de apresentação, replicando a interação humana em telas sem integração para alimentar a esteira analítica ou automatizar etapas operacionais de documentação e comunicação.
Essa transição metodológica requer, contudo, precisão técnica: testar 100% da população elimina o risco de amostragem, mas não elimina o risco não amostral. Se a extração vier incompleta, se o tratamento descartar registros indevidamente ou se a regra de controle estiver mal parametrizada, a automação apenas produzirá falsos negativos em escala. Por isso, a confiabilidade das evidências depende diretamente de controles de engenharia, como a reconciliação de volumetria entre a origem e a base testada.
Vale também estabelecer uma distinção conceitual essencial para a governança: monitoramento contínuo não se confunde com auditoria contínua. A distinção já aparece em implementações pioneiras descritas na literatura (Alles et al., 2006) e, à luz do Modelo das Três Linhas (IIA, 2020), o monitoramento contínuo é responsabilidade da 1ª e da 2ª linha na supervisão rotineira das operações e dos controles internos. Já a auditoria contínua é exercida de forma independente pela 3ª linha, que opera sua própria esteira de testes para avaliar a eficácia dos controles e o comportamento dos riscos sem assumir funções de gestão.
O caminho das pedras: framework de implementação
A transição tecnológica exige método para evitar que rotinas manuais ineficientes sejam apenas codificadas. O framework proposto por Huang e Vasarhelyi (2019), desenvolvido e avaliado em caso piloto na literatura de auditoria, organiza a adoção de automação em quatro estágios práticos:
● Seleção do procedimento: A automação exige padronização. Os alvos iniciais ideais são os procedimentos maduros, altamente repetitivos e baseados em regras objetivas, nos quais não há necessidade de julgamento subjetivo na execução do teste e os dados de entrada já estão em formato estruturado e digital.
● Modificação do procedimento (reengenharia): Raramente um procedimento de auditoria manual pode ser automatizado exatamente como é executado (as-is). É necessário aplicar reengenharia ao fluxo, separando as validações estritamente determinísticas daquelas que exigem avaliação humana, além de padronizar templates, dicionários de dados e metadados para evitar falhas de leitura e interpretação.
● Implementação: Nesta fase, as lógicas de teste são codificadas. No dia a dia da prática de Auditoria Interna, essa construção se traduz no uso integrado de tecnologias: estrutura-se a captura, limpeza e parsing de dados (ETL) com fluxos automatizados, queries em SQL, scripts em Python e fluxos no Alteryx para extrações e cruzamentos robustos, acionando o software de RPA na ponta onde não há integração direta. A opção pelo desenvolvimento in-house (construído diretamente no ambiente tecnológico do cliente e sob a governança da área de auditoria) confere flexibilidade para manutenção evolutiva e preserva a confidencialidade das informações estratégicas dentro do perímetro corporativo.
● Avaliação e operação: O fluxo automatizado deve ser testado em paralelo ao método tradicional para atestar sua completude e acurácia antes de entrar em produção. Um dos maiores desafios operacionais na auditoria contínua é a “inundação de alarmes” (alarm flood). Se as regras não forem calibradas, o excesso de falsos positivos sobrecarrega a equipe, gerando o risco real de os profissionais passarem a ignorar alertas relevantes. Estratégias como estruturação hierárquica de exceções e limiares escalonados são decisivas nessa etapa.
O auditor do futuro e o redirecionamento do esforço analítico
O receio de que a automação substitua os auditores parte de uma visão limitada da profissão. O objetivo de automatizar a esteira de dados é retirar o trabalho mecânico da rotina humana. Ao transferir o esforço de extração, conferência de bases e validações lineares para a máquina, o auditor deixa de atuar como coletor e formatador de arquivos.
Assim, com o suporte da esteira, o profissional direciona seu tempo ao capital intelectual, com aprofundamento em frentes como Forensic Data Analysis, investigação criteriosa de transações atípicas (notable items), atualização dinâmica da matriz de riscos com base em evidências da população total e comunicação de causas-raízes ao Comitê de Auditoria.
Da teoria à prática: arquitetura de uma esteira de auditoria contínua
Na prática, um robô isolado raramente sustenta um programa de auditoria contínua. O que funciona é uma esteira de dados em camadas, na qual o RPA ocupa um lugar específico e o restante do trabalho pesado fica com ferramentas mais adequadas. Pensar assim evita o erro comum de usar o robô para tudo, inclusive para o que um script ou uma query resolveriam com mais estabilidade.
Uma arquitetura de referência, que pode ser adaptada ao porte e ao nível de maturidade de cada área, costuma ter cinco camadas:
● Extração: sempre que o sistema de origem permitir, a coleta deve ser feita por queries SQL, APIs ou exportações agendadas, que são rápidas e não dependem de interface. O RPA entra quando não há outra porta de acesso, como em sistemas legados, portais web de terceiros e telas sem integração. Nesses casos, plataformas como UiPath, Automation Edge ou ElectroNeek navegam na camada de apresentação e trazem os dados até a esteira.
● Tratamento e ETL: nesta etapa os dados são padronizados, deduplicados, tipados e cruzados entre fontes. Alteryx e Python (pandas) são escolhas frequentes, e o ganho principal é o mesmo nos dois casos: a lógica de tratamento fica documentada e reexecutável, e não escondida em macros de planilha.
● Regras de controle: aqui ficam os testes propriamente ditos, escritos como regras parametrizáveis (limiares, janelas de tempo, listas de exceção) e não como valores fixos dentro do código. Quando o auditor precisa recalibrar um alerta, ele altera um parâmetro, sem mexer na lógica.
● Orquestração: agendamento, filas de itens, controle de dependências entre etapas, reprocessamento em caso de falha e registro de cada execução. Um orquestrador, seja o da própria plataforma de RPA ou uma aplicação dedicada para rodar fluxos em Python, é o que transforma um conjunto de scripts em um processo operável.
● Evidência e visualização: os resultados são gravados em uma base própria, com data de execução, versão da regra e volume processado, e consumidos em painéis de BI. O RPA pode fechar o ciclo anexando a evidência ao papel de trabalho ou abrindo o chamado para o responsável pela área auditada.
Boas práticas de engenharia para robôs de auditoria
Um robô que produz evidência de auditoria precisa, ele próprio, ser confiável. Se o resultado do teste for questionado pela área auditada, a equipe tem de conseguir demonstrar o que foi executado, quando, sobre quais dados e com qual versão da lógica. Alguns cuidados técnicos tornam isso possível:
● Credenciais e segregação de funções: senhas e tokens ficam em cofre de credenciais (como os assets do orquestrador ou um vault corporativo), nunca dentro do código ou de arquivos de configuração. O robô opera com conta dedicada e privilégio mínimo, somente leitura sempre que possível, o que também evita questionamentos sobre segregação de funções.
● Logs e trilha de auditoria: cada execução registra início, fim, origem dos dados, quantidade de registros lidos, tratados e rejeitados e o resultado de cada regra. Esses logs devem ser protegidos contra alteração e guardados pelo mesmo prazo de retenção dos papéis de trabalho.
● Reconciliação de volumetria: antes de rodar qualquer teste, a esteira compara totais de controle entre a origem e a base tratada (contagem de linhas e soma de valores, por exemplo). Se os números não fecham, a execução é interrompida e sinalizada. Esse passo simples mitiga o risco não amostral e evita concluir que “não há exceções” sobre uma base que veio incompleta.
● Tratamento de exceções: é útil separar exceções de negócio (um dado fora do padrão, que deve ir para revisão humana) de exceções de sistema (indisponibilidade, timeout, mudança de layout de tela), que pedem nova tentativa ou acionamento do time técnico. Misturar os dois tipos é uma das principais causas de robôs que falham em silêncio.
● Idempotência e reprocessamento: rodar o mesmo fluxo duas vezes sobre o mesmo período não pode duplicar achados nem alterar resultados anteriores. Isso exige chaves de execução e controle de período, e permite refazer um mês inteiro sem efeitos colaterais.
● Versionamento e ambientes: código, regras e parâmetros em repositório com controle de versão, com ambientes separados de desenvolvimento, homologação e produção. Toda mudança em regra de controle passa por teste em paralelo antes de ir para produção, na mesma lógica da fase de avaliação descrita anteriormente.
● Preferência por integrações estáveis: automações que dependem de clique em tela quebram quando o sistema muda. Sempre que houver banco, API ou arquivo estruturado disponível, essa deve ser a via principal, deixando a automação de interface para os casos sem alternativa.
● Calibração de alertas: para conter a inundação de alarmes, cada achado recebe uma pontuação de risco combinando valor, recorrência e criticidade do processo. Apenas os itens acima de determinado limiar geram notificação imediata; os demais seguem em relatório consolidado. Os limiares são revistos periodicamente com base no percentual de alertas que de fato viraram achado.
Há ainda um ponto que costuma passar despercebido: os próprios robôs e scripts entram no escopo dos controles gerais de TI (ITGC). Acessos, mudanças e operação da automação precisam ser governados com o mesmo rigor aplicado aos sistemas que ela audita.
Exemplo prático: teste de 100% da população em contas a pagar
Para ilustrar como as camadas se conectam, considere um teste clássico de contas a pagar. Em vez de selecionar uma amostra de pagamentos e conferi-los um a um, a esteira processa todos os títulos do período. A construção típica segue este desenho:
● Extração: query SQL no ERP traz títulos, pagamentos, cadastro de fornecedores e cadastro de colaboradores do período. Dados de portais de terceiros, como consulta de situação cadastral de fornecedores, são coletados por robô de RPA.
● Tratamento e privacidade (LGPD): normalização de CNPJ/CPF, padronização de nomes e contas bancárias, e junção das bases por chave de fornecedor. Como o cruzamento envolve dados pessoais e bancários de colaboradores, o processamento deve se apoiar em base legal adequada à LGPD (como o legítimo interesse do controlador na prevenção à fraude e no controle interno), definida com o encarregado de dados. O desenho também aplica minimização de dados (coleta restrita aos campos estritamente necessários ao batimento) e controle de acesso aos resultados.
● Regras: pagamentos duplicados (mesmo fornecedor, valor e datas próximas, ou mesmo número de documento com pequenas variações), fornecedores cujos dados bancários coincidem com os de colaboradores, pagamentos acima da alçada aprovada, lançamentos em fins de semana ou feriados e fornecedores com cadastro recente e alto volume financeiro.
● Pontuação e priorização: cada regra atribui um peso, e a soma define a posição do item na fila de revisão. O auditor começa pelo topo da lista, não por uma planilha de milhares de linhas.
● Fechamento do ciclo e independência: o robô anexa a evidência (extrato da regra, registros de origem, data de execução) ao papel de trabalho e envia o item ao responsável para esclarecimento. A resposta retorna à base, alimentando o painel de acompanhamento. Em linha com a separação entre 3ª linha (auditoria contínua) e 1ª/2ª linhas (monitoramento contínuo), o robô documenta a exceção e acompanha a tratativa, mas não executa bloqueios ou aprovações operacionais no ERP.
O resultado prático é uma mudança de papel, pois a máquina varre a população inteira, e o auditor dedica o tempo ao que sobrou, ou seja, aos itens que realmente exigem investigação, entrevista e julgamento.
Rumo à automação inteligente
O RPA tradicional lida bem com tarefas estruturadas e baseadas em regras, mas parte da evidência de auditoria está em documentos não estruturados (contratos, notas fiscais em PDF, comprovantes e e-mails). A evolução natural da esteira é combinar o robô com outras tecnologias, como o OCR (Optical Character Recognition) e processamento inteligente de documentos que permitem ler e estruturar esses arquivos antes dos testes. Já tecnologias como o process mining ajudam a identificar desvios de fluxo em relação ao processo desenhado e, por fim, modelos estatísticos e de aprendizado de máquina, como detecção de anomalias, complementam as regras fixas na busca por padrões que não foram codificados.
Modelos de linguagem (LLMs) também começam a aparecer, por exemplo para resumir cláusulas contratuais ou classificar justificativas de exceção. Nesses casos, o desenho precisa de limites claros: o modelo apoia a leitura e sugere, o resultado é sempre rastreável até o documento de origem e a decisão final continua com o auditor. Uma saída que não pode ser verificada não serve como evidência.
Conclusão
Sustentar testes sobre 100% da população requer uma esteira em camadas na qual SQL, APIs, ferramentas de ETL (como o Alteryx Designer) e scripts analíticos absorvam a extração e as regras de negócio, reservando o RPA para sistemas sem integração e para o fluxo de evidências. Quando essa arquitetura é combinada a disciplinas de engenharia, tais como reconciliação de volumetria para mitigar o risco não amostral, idempotência, separação entre erros de sistema e exceções de negócio e inclusão dos próprios robôs no escopo de ITGC, a auditoria contínua ganha rastreabilidade de ponta a ponta.
Como resultado, em vez de gastar tempo reconciliando planilhas ou testando amostras parciais, o auditor atua no topo de uma fila priorizada por risco, dedicando sua capacidade analítica às exceções que exigem investigação e julgamento.
Esse artigo foi escrito por Bruno Vaz (Consultor Master de Risk Advisory & Internal Audit) e Pedro Manoel de Azevedo (Consultor Master RPA de Business Performance & Transformation).
Referências Bibliográficas
● Alles, M., Brennan, G., Kogan, A., & Vasarhelyi, M. A. (2006). Continuous monitoring of business process controls: A pilot implementation of a continuous auditing system at Siemens. International Journal of Accounting Information Systems, 7(2), 137–161.
● Committee of Sponsoring Organizations of the Treadway Commission [COSO]. (2013). Internal Control — Integrated Framework. AICPA.
● Huang, F., & Vasarhelyi, M. A. (2019). Applying robotic process automation (RPA) in auditing: A framework. International Journal of Accounting Information Systems, 35, 100433.
● Institute of Internal Auditors [IIA]. (2020). The IIA’s Three Lines Model: An update of the Three Lines of Defense. The IIA.
● Institute of Internal Auditors [IIA]. (2024). Global Internal Audit Standards (International Professional Practices Framework – IPPF). The IIA.
● International Organization for Standardization [ISO]. (2018). ISO 31000:2018 — Risk management — Guidelines. ISO.
● International Organization for Standardization [ISO] & International Electrotechnical Commission [IEC]. (2022). ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO.
● Moffitt, K. C., Rozario, A. M., & Vasarhelyi, M. A. (2018). Robotic Process Automation for Auditing. Journal of Emerging Technologies in Accounting, 15(1), 1–10.
● Pereira, A. T., de Araújo, C. S., Mello, S. G. O., Roberto, J. C. A., & Cavalcante, Z. P. (2026). Auditoria Contínua e Tecnologia: O uso de análise de dados e automação para aprimorar a eficácia do controle interno. Periódicos Brasil. Pesquisa Científica, 5(4), 315–331.
