Como equipes financeiras podem implantar aplicativos criados com IA sem vazar dados financeiros

Quando a empresa de segurança RedAccess foi procurar aplicativos criados com ferramentas de programação com IA e publicados na própria hospedagem dessas ferramentas, encontrou mais de 5.000 praticamente sem nenhuma segurança ou autenticação. Entre as telas compartilhadas com a Wired estavam “diversos registros comerciais e financeiros de várias outras empresas”. Aplicativos criados com IA para equipes financeiras podem acabar no mesmo tipo de endereço aberto, com o razão geral, a folha de pagamento e resultados ainda não divulgados por trás dele.

Amjad Masad, CEO da Replit, respondeu: “Aplicativos públicos acessíveis na internet são o comportamento esperado”. Ele tem razão sobre o mecanismo. Na minha leitura, a exposição veio de uma configuração de visibilidade e uma revisão ignorada, ambas ao alcance de quem criou a ferramenta.

TL;DR

• Uma ferramenta financeira criada com IA pode vazar dados por meio de seis erros de implantação, todos ao alcance de quem a criou: um link público, senhas e chaves deixadas no código ou no histórico do chat, acesso de nível administrativo ao banco de dados, lançamentos contábeis sem um segundo aprovador, dados enviados a serviços externos e mudanças de cálculo que ninguém registrou.
• Cada erro tem uma correção, a maioria aplicada pela mesma ferramenta de IA que criou o aplicativo, e uma verificação simples que prova que a correção funcionou, como uma gravação que o banco de dados recusa ou uma senha antiga que deixou de funcionar.
• Mantenha uma ferramenta financeira em uma rede privada por padrão, adicione login corporativo quando pessoas de fora do setor financeiro precisarem dela e entregue-a à TI quando ela lançar no razão sem um segundo aprovador, tocar em dados de cartões ou fornecer números para demonstrações financeiras no escopo da SOX.
• A região do servidor determina onde fica o armazenamento primário do VPS do aplicativo, mas backups, logs e serviços de terceiros podem criar cópias em outros locais; se a configuração como um todo está em conformidade é uma questão separada. Leve os referenciais da sua região à sua equipe de conformidade.

Os erros de implantação que vazam dados financeiros

Uma ferramenta financeira criada com IA pode vazar dados por meio de seis erros de implantação: deixá-la em um link público, manter credenciais no código ou no chat, conectar com acesso administrativo quando o acesso somente leitura bastaria, lançar sem um segundo aprovador, enviar dados financeiros a serviços externos e alterar cálculos sem nenhum registro. Cada um é um padrão que uma demonstração recompensa.

Cada correção abaixo vem com um prompt para a ferramenta de IA que criou o aplicativo; altere os campos entre colchetes antes de colar. Os prompts são pontos de partida não testados, escritos para este artigo, e o fato de sua ferramenta de IA dizer que fez uma alteração não prova nada. A verificação abaixo de cada prompt é a prova. Execute os prompts no código e em um conjunto de dados de exemplo ou sintético, e nunca cole registros reais ou chaves ativas no chat.

Deixar a ferramenta no link público do criador de aplicativos com IA

Um painel de previsão de caixa deixado público na hospedagem do criador de aplicativos com IA pode ser aberto por qualquer pessoa que tenha o endereço, junto com tudo o que ele mostra: vencimentos de contas a pagar, orçamento versus realizado e os resultados do trimestre antes de serem divulgados. A reportagem da Wired sobre as descobertas da RedAccess descreve como os pesquisadores localizaram esses aplicativos com buscas simples no Google e no Bing pelos domínios dos fornecedores de IA.

Alguns desses aplicativos só pediam que os visitantes fizessem login com qualquer endereço de e-mail. Um login que aceita qualquer endereço de e-mail não é controle de acesso.

Retire os dados reais da hospedagem do fornecedor. Até que a ferramenta rode em um servidor que você controla (a próxima seção explica onde), desenvolva e demonstre usando um conjunto de dados sintético ou a sandbox ou empresa de teste do seu ERP, se ele tiver uma, nunca uma exportação real. Implante novamente depois de fazer a mudança, porque o endereço hospedado serve a última versão implantada, seja ela qual for.

Crie dados sintéticos compatíveis com as tabelas e colunas lidas pelo aplicativo: [liste tabelas e colunas, por exemplo vendors, invoices, journal_lines].

Use nomes fictícios de fornecedores e clientes, contas bancárias fictícias e valores em [moeda] coerentes com livros reais: cada lançamento fecha, e os totais auxiliares batem com [a conta de controle de fornecedores / clientes].

Aponte o aplicativo para esses dados, não uma exportação real, e liste cada arquivo ou configuração alterado.

Não me peça registros reais.

Confirme o resultado: abra o endereço hospedado pelo fornecedor em um navegador sem login, ou peça a um colega de fora do setor financeiro que faça isso, e confirme que ele mostra apenas dados sintéticos, uma tela de login ou absolutamente nada. Depois, procure nos arquivos de dados do aplicativo e no repositório três nomes de fornecedores ou clientes tirados do seu ERP real e confirme que não há nenhuma correspondência. Por fim, execute o balancete ou a visão de resumo do aplicativo e confirme que o total de débitos é igual ao total de créditos.

Deixar credenciais do ERP, do feed bancário e do banco de dados no código ou no chat

Se uma credencial ativa estiver armazenada ali, qualquer pessoa que consiga ler o histórico do chat, o repositório ou o arquivo de configuração do MCP também poderá usá-la para acessar o ERP, o banco de dados financeiro ou a integração do feed bancário. O MCP é o conector que permite que uma ferramenta de IA como o Claude se comunique diretamente com o ERP ou com um banco de dados, e o arquivo de configuração dele é mais um lugar onde uma senha pode ficar.

O State of Secrets Sprawl 2026 da GitGuardian encontrou 24.008 segredos únicos expostos em arquivos de configuração do MCP, 14% deles strings de conexão de bancos de dados PostgreSQL. Nos commits públicos do GitHub, o mesmo relatório constatou que commits coassinados pelo Claude Code vazavam segredos a aproximadamente o dobro da taxa de referência, e acrescenta que o fator humano também continua sendo crítico.

Apagar a mensagem do chat não desfaz a exposição: qualquer pessoa com uma cópia do chat, do repositório ou do histórico dele ainda tem o valor. Para cada senha, chave ou token que já tenha ficado em um desses lugares, emita um novo no console de administração do ERP, do banco de dados ou do feed bancário e desative o antigo. É isso que significa rotacionar uma credencial.

O aplicativo então lê suas credenciais na inicialização a partir de variáveis de ambiente (configurações nomeadas mantidas fora do código), fornecidas pela camada de implantação, que é a ferramenta que compila e executa o aplicativo no seu servidor. O HashiCorp Vault é o próximo passo quando várias ferramentas compartilham segredos e precisam de rotação a partir de um único lugar.

As cópias de senhas da própria equipe devem ficar em um gerenciador de senhas feito para pessoas, como o Vaultwarden; o aplicativo em execução lê seus valores do ambiente. Comece encontrando todos os segredos fixos que o código gerado por IA contém.

Audite este projeto em busca de segredos fixos no código. Encontre todas as senhas, chaves de API, tokens de acesso e strings de conexão, inclusive em arquivos .env, notebooks, arquivos de configuração do MCP e no código que se conecta a [nome do ERP / provedor do feed bancário / banco de dados financeiro].

Substitua cada valor no código por uma variável de ambiente nomeada e me dê a lista com os nomes das variáveis.

Garanta que nenhum arquivo com valores reais seja incluído em commits no repositório e liste cada commit do histórico do repositório em que um desses valores aparece.

Mostre-me apenas as localizações. Não imprima nenhum valor secreto.

Confirme o resultado: teste você mesmo a senha ou o token antigo, ou peça à TI que teste, e espere que seja recusado. Depois, procure os valores antigos nos arquivos atuais do projeto e confirme que não há nenhum. Uma correspondência que ficou no histórico só deixa de conceder acesso depois que você confirmar que o valor foi revogado ou expirou.

Conectar com o login de administrador do criador quando a ferramenta só precisa ler

Um painel que mostra a análise por idade das contas a receber não deve poder alterar o razão geral. Se a ferramenta se conecta com o login administrativo do criador, herda os privilégios dessa conta. Uma chave secreta do Supabase, ou a antiga chave service_role, fornece acesso elevado aos dados do projeto e ignora Row Level Security, por isso não deve ser usada para acesso comum somente leitura. Um relatório criado para uma única análise por idade pode então expor todo o razão geral, incluindo as tabelas de folha de pagamento.

A capacidade de gravação é onde isso se torna caro. A análise de 1.072 aplicativos criados com IA da Symbiotic Security, usando Supabase, encontrou 172 que permitiam a qualquer pessoa excluir registros sem autenticação, 172 que permitiam a qualquer pessoa alterar registros existentes e 39 com tabelas totalmente legíveis por qualquer pessoa que possuísse a chave pública.

Dê à ferramenta uma credencial somente leitura limitada às tabelas que ela lê. No ERP ou no banco de dados, isso significa um usuário de integração dedicado: uma conta separada criada para a ferramenta, com acesso de leitura aos objetos de que o relatório precisa e nada mais. No Supabase, ative a Row Level Security (a regra do banco de dados que decide quais linhas cada solicitação pode ver) em todas as tabelas expostas que a ferramenta usa e revise também as concessões de tabela: as concessões decidem se um papel pode sequer fazer select, insert, update ou delete. Para um aplicativo financeiro somente leitura, o papel que ele usa não deve ter operações de gravação de que não precisa. A chave publicável pode ficar no código do navegador quando a RLS e as concessões de privilégio mínimo estão corretas. As chaves secretas e as antigas chaves service_role ficam no servidor e devem ser reservadas a tarefas de backend que realmente precisam de acesso elevado e impõem sua própria autorização.

Nota: Uma chave publicável do Supabase, ou a antiga chave anon, visível no JavaScript da página é normal. A documentação de chaves de API do Supabase diz que ela só alcança o que a Row Level Security permite. A chave secreta ignora a Row Level Security, por isso nunca deve aparecer em nada que seja enviado a um navegador.

Liste cada leitura e cada gravação que este aplicativo faz em [nome do ERP ou do banco de dados], agrupadas por tabela ou objeto.

Altere o aplicativo para que ele leia apenas [as tabelas de que precisa] e se conecte com uma credencial separada somente leitura fornecida por uma variável de ambiente, nunca com o meu próprio login.

Se o aplicativo usa Supabase: ative a Row Level Security em todas as tabelas expostas que ele acessa. Liste as concessões de select, insert, update e delete para anon e authenticated. Para este aplicativo somente leitura, remova as concessões de gravação que não forem necessárias; se outro aplicativo de produção depender de alguma delas, sinalize-a em vez de alterá-la. Depois, escreva políticas para que visitantes sem login não possam ler nada e usuários com login só possam ler [regra, por exemplo, linhas do próprio centro de custo], e confirme que nenhuma chave secreta ou antiga chave service_role aparece em qualquer arquivo enviado ao navegador.

Liste as políticas que você criou.

Confirme o resultado: usando a credencial da ferramenta, tente uma gravação, como editar um registro de teste, e espere uma recusa. No Supabase, solicite as linhas de uma tabela financeira sem estar logado e espere um resultado vazio ou um erro.

Deixar a ferramenta lançar no razão sem um segundo aprovador

Um importador de lançamentos contábeis que lança diretamente, ou um gerador de arquivos de pagamento que envia direto ao banco, faz de quem o executa ao mesmo tempo preparador e aprovador. Um bug duplica um mês inteiro de apropriações. Um campo alterado envia o pagamento de um fornecedor para a conta errada. Essa é a quebra de segregação de funções que o setor financeiro se recusa a permitir entre duas pessoas, e um software criado com um assistente de IA não ganha nenhuma exceção.

O dano não fica no aplicativo. Um lote errado vai parar nos livros, onde desfazê-lo exige um lançamento de correção e uma explicação no fechamento, e quando a ferramenta lança com o login do próprio criador, cada lançamento duplicado leva o nome dele.

A ferramenta criada com IA lê e prepara; os lançamentos e a liberação de pagamentos acontecem no próprio fluxo de aprovação do ERP, aprovados por alguém que não seja a pessoa que executou a ferramenta. Todo motor contábil em que já trabalhei trata o lançamento e sua aprovação como dois eventos com dois responsáveis, e uma ferramenta criada com IA merece o mesmo tratamento.

Na prática, transforme cada lançamento direto em um lançamento em rascunho ou em uma importação preparada que aguarda aprovação dentro do ERP. A ferramenta continua fazendo a parte trabalhosa (mapeamento, validação, montagem do lote), e a aprovação fica no ERP, ao lado de todas as outras aprovações de que o fechamento depende. Se o ERP não tiver etapa de aprovação para importações, o resultado da ferramenta passa a ser um arquivo que uma segunda pessoa revisa em relação ao resumo do lote e importa ela mesma.

Uma ferramenta que precisa lançar automaticamente, gerar arquivos de pagamento ou alterar dados bancários de fornecedores deve ficar com a TI, nas condições da próxima seção.

Liste todos os pontos em que este aplicativo cria, edita ou lança [lançamentos contábeis / faturas / pagamentos] em [nome do ERP].

Altere cada um deles para que o aplicativo grave um lançamento em rascunho ou uma importação preparada que precise ser aprovada em [nome do ERP] antes de ser lançada. Se [nome do ERP] não tiver etapa de aprovação para importações, gere um arquivo de importação e não lance nada.

Remova qualquer caminho de código que lance ou libere um pagamento sem essa aprovação.

Para cada lote, produza um resumo com o número de linhas, o total de débitos e o total de créditos.

Liste tudo o que ainda lança diretamente para que eu possa revisar.

Confirme o resultado: execute um lote com dados de exemplo. Nada deve aparecer como lançado até que um segundo usuário o aprove no ERP. Depois, compare o resumo do lote com o que o ERP mostra para esse lote: o número de linhas, o total de débitos e o total de créditos devem bater exatamente. Uma diferença de uma linha é uma conciliação que falhou, não um problema de arredondamento.

Enviar dados financeiros a serviços fora do seu controle

Um recurso de comentário de variações que envia o extrato completo do razão geral a uma API de IA entrega cada linha a terceiros. Dois caminhos mais discretos também levam dados para fora: um script de analytics na página, que informa cada visita ao fornecedor, e um rastreador de erros ou log que guarda os corpos completos das solicitações, onde linhas da folha de pagamento, dados bancários de clientes e números ainda não divulgados podem acabar.

Em uma ferramenta interna criada pelo setor financeiro, mantenha resultados ainda não divulgados e a folha de pagamento fora de chamadas a terceiros, a menos que o serviço e o fluxo exato de dados tenham sido aprovados explicitamente pelo processo de fornecedores, segurança e conformidade da sua organização. Para todo o resto, liste cada destino e envie a cada chamada apenas os campos de que ela precisa. Se um serviço externo armazena o que recebe ou treina modelos com esses dados é uma questão para quem assina os contratos com fornecedores, verificada nos próprios termos desse fornecedor. Se a equipe quiser saber com que frequência a ferramenta é usada, uma ferramenta de analytics auto-hospedada como o Umami mantém essas visualizações de página no seu próprio servidor.

Liste todos os lugares para onde este aplicativo envia dados fora de [nosso servidor], incluindo APIs de IA, scripts de analytics, rastreamento de erros, e-mail, webhooks e arquivos de log.

Para cada destino, liste exatamente quais campos ele recebe.

Sinalize tudo o que contenha [valores da folha de pagamento / números de contas bancárias / resultados não divulgados / nomes de clientes].

Para cada item sinalizado, mostre como enviar menos campos ou nenhum, e faça a alteração somente depois que eu confirmar.

Confirme o resultado: acione cada recurso uma vez com dados de exemplo que contenham um número de conta fictício reconhecível e um valor de folha de pagamento fictício. Procure os dois valores no rastreador de erros e nos logs e espere não encontrar nada. Para a rota da API de IA, faça o aplicativo registrar em log o corpo da solicitação de saída durante essa execução de exemplo, procure os mesmos dois valores no log e espere não encontrar nenhum deles, com apenas os campos que você aprovou presentes. Desative esse registro em log depois.

Alterar cálculos sem registro nem conciliação

Em uma calculadora de apropriações ou em um validador de waterfall de receitas, o código é o controle. Altere uma fórmula e os números que chegam ao fechamento mudam junto, e sem controle de versão ninguém consegue dizer quem mudou o quê, nem quando.

Em uma discussão no r/ClaudeAI de uma firma de contabilidade (CPA) sobre ferramentas internas que ela criou com o Claude Code, um comentarista foi direto ao apontar o limite: “'contador + claude code' funciona até chegar aos requisitos de trilha de auditoria. Esse é o teto real”.

Fixe o comportamento atual antes de mudar qualquer coisa; depois que as saídas estiverem fixadas, a lógica pode melhorar sem que os totais se desviem sem ninguém perceber. Mantenha o código sob controle de versão, que registra cada alteração com seu autor e data.

Escreva testes que executem a ferramenta em um arquivo de exemplo fixo e comparem os resultados com uma baseline registrada, para que o código precise passar por uma conciliação antes que qualquer mudança seja liberada. Um teste fixado protege tudo o que registra, inclusive erros, então concilie os totais da baseline com os totais do ERP para aquele período antes de confiar neles.

Exija que uma segunda pessoa revise qualquer mudança na lógica de cálculo e concilie cada execução em produção com os próprios totais do ERP.

Coloque este projeto sob controle de versão, se ainda não estiver, e liste quais arquivos contêm lógica de cálculo.

Escreva testes que executem o aplicativo em [arquivo de exemplo] e registrem as saídas atuais: número de linhas e totais por [conta / entidade / período].

Antes de salvar as saídas registradas, mostre-me os totais para que eu possa conciliá-los com [nome do ERP] para [período].

Toda mudança nesses totais deve fazer um teste falhar.

Não altere a lógica de cálculo enquanto escreve os testes.

Confirme o resultado: altere um cálculo de propósito, uma regra de arredondamento, por exemplo, e confirme que um teste falha. Reverta a alteração e confirme que todos os testes voltam a passar.

Privado por padrão, login corporativo quando mais pessoas precisarem, TI para o razão

Dados financeiros reais nunca ficam na hospedagem da ferramenta de IA. Para implantar com segurança um aplicativo financeiro criado com IA apenas para a equipe financeira, coloque-o em um servidor que você controla, acessível somente por uma rede privada. Adicione login corporativo quando pessoas de fora da equipe precisarem dele e entregue-o à TI quando qualquer item da lista abaixo for verdadeiro.

Um VPS é um servidor virtual alugado cujo sistema operacional e pilha de software você controla. Uma rede privada (uma tailnet, nos termos do Tailscale) conecta dispositivos aprovados a esse servidor. Para manter a ferramenta fora da internet aberta, você ainda precisa bloquear o acesso público de entrada ao aplicativo, por exemplo, com o firewall do servidor, e expô-lo apenas pela interface da VPN ou da tailnet. Um provedor de identidade guarda as contas de usuário da empresa, e um proxy reverso é o porteiro à frente do aplicativo que faz cada solicitação passar primeiro pelo login.

A hospedagem da própria ferramenta de IA fica fora da tabela pelos motivos explicados no primeiro erro. O mesmo vale para uma plataforma de implantação corporativa como a Northflank, adequada a organizações maiores que já têm orçamento para fornecedores de plataforma e para as avaliações que eles exigem. Isso é mais contrato do que uma ferramenta departamental com poucos usuários precisa.

Na minha experiência, o Tailscale é a mais rápida de implantar entre as duas opções de rede privada, mas o próprio Tailscale hospeda o serviço de coordenação. O WireGuard é a opção totalmente auto-hospedada.

Meu motivo para tornar a rede privada o padrão: uma ferramenta que não responde pela internet não pode ser encontrada por uma busca nem atacada pela página de login, enquanto uma página de login escrita pela ferramenta de IA é tão boa quanto o código escrito pela IA por trás dela. Se você precisar expor o aplicativo além da rede privada, o login corporativo acrescenta uma camada de autenticação gerenciada à frente dele, e é por isso que ele vem em segundo lugar.

Quando os responsáveis por orçamento precisarem de acesso, substitua o login próprio da ferramenta pelo login corporativo, também chamado de single sign-on (SSO): as pessoas usam a conta da empresa que já têm, então desativar essa conta bloqueia novos logins; configure a revogação de sessões, o logout back-channel ou durações de sessão adequadamente curtas para que as sessões existentes não continuem ativas. O prompt usa OIDC, um protocolo padrão de login compatível com o Authentik e o Keycloak.

Substitua o login próprio deste aplicativo pelo login corporativo por meio de [Authentik / Keycloak / nosso provedor de identidade] usando OIDC.

Leia o grupo de cada usuário no login.

Permita [as páginas da folha de pagamento] somente a membros de [nome do grupo] e imponha essa regra no servidor em cada página, cada exportação e cada endpoint de API, não apenas no menu.

Recuse toda solicitação que não venha com um login válido.

Confirme o resultado: entre com uma conta de teste que não esteja no grupo, solicite diretamente a página restrita e o endereço da exportação ou da API correspondente e espere uma recusa em ambos. Depois, desative a conta de teste no provedor de identidade e confirme que ela não consegue iniciar uma nova sessão. Confirme também que uma sessão existente é revogada ou expira dentro do prazo que você configurou.

Algumas ferramentas não devem ficar com a equipe de forma alguma. Entregue a ferramenta à TI ou à engenharia quando qualquer uma destas condições for verdadeira:

1. Ela lança no razão geral ou em outro sistema oficial de registro sem que uma pessoa aprove no ERP.
2. Gera arquivos de pagamento, libera pagamentos ou altera dados bancários de fornecedores.
3. Sua saída alimenta as demonstrações financeiras de uma empresa registrada na SEC, o que pode trazer a ferramenta para o controle interno sobre relatórios financeiros (ICFR). Discuta isso com a auditoria interna antes que ela seja usada no fechamento; para emissores sujeitos à SOX Section 404(b), o auditor externo também pode testar os controles relevantes.
4. Armazena, processa ou transmite dados de cartões de pagamento.
5. Avalia capacidade de crédito de pessoas físicas.
6. Ninguém na equipe vai assumir a aplicação de patches, as revisões de acesso e a desativação da ferramenta.

A sexta condição pesa mais do que parece. Com a auto-hospedagem, você assume atualizações, backups e monitoramento, e uma ferramenta financeira que ninguém mantém fica mais segura com a TI. A TI pode ser mais lenta; esse é o preço da governança que essas condições exigem.

Nos níveis 1 e 2, um servidor, uma camada de implantação, uma rede privada e, no nível 2, um provedor de identidade precisam estar prontos antes que alguém abra a ferramenta, e uma equipe financeira sem engenheiro precisa montar tudo isso por conta própria. No nosso Linux VPS, você tem acesso root. O Coolify e o WireGuard estão disponíveis como implantações de um clique; o Tailscale é instalado com o instalador oficial de um único comando, e o Authentik roda a partir do stack oficial em Docker Compose. As horas da equipe podem então ir para as correções acima, em vez de construir a infraestrutura de implantação do zero. Nossas localizações incluem Frankfurt e Amsterdã na UE, Londres no Reino Unido e várias cidades dos EUA, o que permite escolher a região do armazenamento primário do VPS do aplicativo; se essa escolha é aceitável continua sendo uma decisão da equipe de conformidade.

Regras para verificar com sua equipe de conformidade, por região

Os referenciais aplicáveis dependem dos dados que a ferramenta acessa e de onde estão a empresa e as pessoas cujos dados ela contém. Uma tabela de folha de pagamento com salários de funcionários da UE e um cronograma de receitas que alimenta as demonstrações financeiras de uma empresa listada nos EUA podem se enquadrar em referenciais diferentes.

Nada neste artigo é orientação jurídica. A tabela abaixo lista referenciais para levar à sua equipe de conformidade e não determina se algum deles se aplica a você.

Na linha da SOX, a AS 2201 é o padrão do PCAOB para a atestação do auditor à qual se refere a Section 404(b) da Lei Sarbanes-Oxley, e ela inclui os controles sobre lançamentos contábeis e ajustes feitos no processo de relatórios financeiros de fim de período entre os controles que o auditor avalia ao tratar do risco de fraude. Fora dessas regiões, comece pelo site do órgão regulador nacional de proteção de dados. A localização de um servidor determina onde fica o armazenamento primário dele; ela não diz onde estão cada backup, log ou cópia de terceiros, e não atende, por si só, a nenhum dos referenciais acima.

Perguntas frequentes

Vibe coding é seguro para ferramentas financeiras?

Pode ser, depois que as lacunas deixadas por uma demonstração forem fechadas; eu interpreto as evidências mais como um problema de implantação do que de programação. Uma ferramenta financeira é mais arriscada que um projeto pessoal porque lê o ERP e pode gravar nos livros. Quando ela passa a lançar sem um segundo aprovador, lidar com pagamentos ou tocar em dados de cartões, ela pertence à TI.

O que é shadow AI em finanças?

Shadow AI são ferramentas de IA ou aplicativos criados com IA usados com dados da empresa sem o conhecimento ou a aprovação da TI, como um painel de previsões conectado ao ERP que a TI nunca viu. O Cost of a Data Breach Report 2025 da IBM constatou que organizações com altos níveis de shadow AI tiveram custos médios de violação US$ 670.000 maiores do que aquelas com nível baixo ou nenhum, segundo o anúncio da IBM.

O que devemos mostrar à auditoria interna ou ao auditor externo?

Leve quatro coisas antes que a ferramenta seja usada no fechamento: onde ela roda e quem pode acessá-la, o histórico de alterações com os testes de saídas fixadas, como os lançamentos são aprovados no ERP e as evidências de conciliação que batem cada lote com os totais do ERP. O que o auditor exige é decisão dele; esses itens dão a ele algo concreto para avaliar.

Quem é responsável por uma ferramenta financeira criada com IA depois que a pessoa que a criou sai?

Nomeie um responsável em finanças e um contato técnico antes do lançamento. Execute a ferramenta com credenciais de serviço, não com o login pessoal do criador, e encaminhe o acesso pelo login corporativo. Desativar a conta de quem sai bloqueia novos acessos; sessões existentes são revogadas ou expiram conforme a política de sessões. Desativar a ferramenta significa desligar suas credenciais, guardar o que a política de retenção exige, excluir o restante e encerrá-la.