O caso Nubank e a IA na operação: o problema não é automatizar, é definir até onde a IA pode ir

Em junho de 2026, clientes do Nubank receberam uma comunicação que nenhuma instituição financeira gostaria de enviar por engano: uma mensagem informando que o Banco Central teria decretado a liquidação extrajudicial da própria instituição.

A informação era falsa.

O Nubank continuava operando normalmente, e o Banco Central negou que houvesse qualquer processo de liquidação. A mensagem, porém, não chegou por um perfil falso, um golpe de phishing ou um canal externo. Ela partiu da própria estrutura de comunicação do banco.

O episódio rapidamente virou notícia e levantou uma pergunta inevitável para qualquer empresa que esteja colocando inteligência artificial, automações e agentes para atuar na operação:

Como uma informação de tamanha gravidade conseguiu percorrer um sistema interno e chegar ao cliente por um canal oficial?

Existe uma resposta tentadora: concluir que inteligência artificial é perigosa demais para participar da operação.

Essa conclusão é simples — e pouco útil.

O episódio levanta uma questão mais importante: quanto maior a consequência de uma ação, maiores precisam ser os controles ao redor da tecnologia que pode executá-la.

O problema não é uma empresa utilizar IA na operação. O problema é colocar uma IA dentro da operação sem definir com clareza de onde vêm os fatos, quais decisões ela pode tomar, quais ações pode executar e em que momento uma pessoa precisa assumir.

O que aconteceu com a mensagem de liquidação do Nubank

Em 12 de junho de 2026, clientes do Nubank relataram o recebimento de mensagens por canais oficiais informando uma suposta liquidação extrajudicial da instituição pelo Banco Central.

Segundo apuração do Broadcast reproduzida pelo UOL, cerca de 20 mil clientes teriam recebido a comunicação. O número foi reportado pela imprensa; o Nubank, em seu posicionamento público, limitou-se a dizer que a ocorrência atingiu um grupo pequeno de clientes.

O Banco Central negou a existência de qualquer processo de liquidação do Nubank.

No dia seguinte, a instituição detalhou sua explicação. Em posicionamento publicado no próprio site, o Nubank afirmou que um desenvolvedor acionou por engano um fluxo de comunicação relacionado à liquidação de instituições financeiras.

Segundo a nota oficial, não havia uma instituição real vinculada àquele fluxo e, nessa ausência, o nome do próprio Nubank apareceu como preenchimento padrão.

A empresa afirmou ainda que o episódio não afetou a segurança, a estabilidade da operação ou o funcionamento dos serviços.

Até aqui, temos a versão confirmada publicamente pela instituição.

Onde a inteligência artificial entra nessa história

Uma reportagem da Folha de S.Paulo, publicada em 13 de junho, acrescentou outra camada ao caso.

Segundo a reportagem, trocas de mensagens internas vistas pelo jornal indicavam que o sistema envolvido era operado com inteligência artificial e que uma falha de automação poderia ter levado ao preenchimento do nome Nubank quando nenhuma instituição real estava associada ao fluxo.

A própria Folha ressalta que o Nubank não comentou especificamente essa hipótese de participação da IA.

A reportagem também relatou que conversas internas apontavam para a possibilidade de um segundo problema: o atendimento automatizado, também baseado em IA, teria confirmado a suposta liquidação para alguns clientes que procuraram esclarecimentos. Novamente, trata-se de uma informação reportada pela Folha a partir de fontes e mensagens internas, não de uma confirmação pública do Nubank.

Essa distinção importa.

Não estávamos dentro da operação do Nubank e não precisamos fingir que sabemos exatamente qual sequência técnica produziu o incidente.

Podemos analisar o que foi confirmado, considerar as hipóteses reportadas pelo mercado e, principalmente, extrair uma lição de arquitetura que vale independentemente da causa exata daquele episódio.

A conclusão errada seria: “IA não deveria participar da operação”

Se uma tecnologia comete um erro visível, é natural que a primeira reação seja reduzir sua autonomia.

Mas empresas usam software, integrações e automações em suas operações há décadas. Todos esses sistemas podem falhar. Pessoas também falham. Dados chegam incompletos. APIs ficam indisponíveis. Regras mudam. Um desenvolvedor pode acionar o fluxo errado.

A arquitetura de um sistema sério não deveria depender da hipótese de que nenhuma dessas coisas vai acontecer.

Ela deveria partir da hipótese oposta:

Alguma coisa, em algum momento, vai falhar. O projeto precisa definir antecipadamente até onde essa falha pode chegar.

Por isso, o episódio do Nubank não é um argumento para retirar inteligência artificial das operações.

É um argumento para implementar inteligência artificial de forma responsável.

Isso significa abandonar uma visão binária em que a empresa precisa escolher entre “IA fazendo tudo” e “humano aprovando tudo”. A decisão correta depende do processo, do impacto e do tipo de ação que está sendo automatizada.

Já discutimos essa lógica em IA em vendas simples e complexas: o nível adequado de autonomia muda conforme a natureza da decisão. Uma tarefa previsível e reversível pode admitir muito mais autonomia do que uma ação que cria obrigação comercial, financeira ou reputacional.

Colocar um modelo para conversar com clientes é simples. Transformá-lo em parte segura da operação é engenharia.

O problema não é acesso. É autoridade

Uma das confusões mais comuns na implementação de agentes de IA é tratar acesso e autoridade como se fossem a mesma coisa.

Não são.

Imagine uma IA conectada à operação comercial de uma empresa. Em relação a um preço, ela pode assumir responsabilidades muito diferentes:

1. Consultar o preço cadastrado no sistema;
2. Informar esse preço ao cliente;
3. Sugerir internamente uma condição de desconto;
4. Conceder um desconto dentro de uma política definida;
5. Alterar o preço cadastrado no sistema.

Tecnicamente, todas essas ações podem fazer parte de um agente integrado.

Operacionalmente, representam níveis completamente diferentes de autoridade.

A mesma distinção aparece em praticamente qualquer processo:

• a IA pode consultar estoque sem poder alterá-lo;
• pode ler uma política comercial sem ter permissão para criar exceções;
• pode preparar uma resposta sem necessariamente enviá-la;
• pode identificar que um pedido precisa ser cancelado sem ter autoridade para cancelá-lo;
• pode recomendar uma condição especial sem conseguir concedê-la sozinha.

Dar acesso à IA não significa dar autoridade à IA.

Essa separação é central porque os modelos atuais são capazes de interpretar linguagem, combinar contexto e tomar decisões com flexibilidade. Isso é justamente o que os torna tão úteis — e também o que torna inadequado tratá-los como uma regra fixa de software.

Quanto maior a consequência da decisão, maior precisa ser o controle ao redor dela.

Talvez o “caso Nubank” da sua empresa nunca apareça no jornal

Uma falsa comunicação de liquidação extrajudicial é um caso extremo porque envolve uma instituição financeira, um regulador e uma mensagem capaz de assustar clientes em escala.

O pequeno e médio negócio provavelmente nunca enfrentará algo parecido em magnitude.

Mas a natureza do problema pode aparecer todos os dias em escala menor.

Talvez o equivalente do caso Nubank na sua empresa seja um agente comercial que:

• oferece 15% de desconto quando a política autoriza no máximo 5%;
• informa um preço antigo porque não consultou a fonte oficial;
• promete disponibilidade de um produto que já saiu do estoque;
• garante entrega para amanhã sem validar a capacidade logística;
• apresenta uma condição de parcelamento que a empresa não pratica;
• aceita uma troca fora da política definida;
• responde uma objeção usando uma premissa comercial que nunca foi autorizada;
• atribui ao produto uma característica que ele não possui;
• promete ao cliente que uma exceção será aprovada antes de alguém realmente aprová-la.

Nenhum desses casos provavelmente vai gerar uma manchete nacional.

Ainda assim, todos podem gerar perda de margem, conflito com o cliente, retrabalho, quebra de confiança ou obrigação comercial que a equipe terá de resolver depois.

Para o gestor, pouco importa se a causa técnica recebeu o nome de “alucinação”, “contexto insuficiente”, “falha de integração” ou “interpretação equivocada”.

O problema operacional é mais simples:

O cliente recebeu, por um canal oficial da empresa, uma informação que não deveria ter recebido.

E essa possibilidade precisa ser tratada antes de o agente começar a atender clientes.

A IA precisa saber onde está a verdade

Modelos de linguagem são excelentes para interpretar contexto e produzir linguagem. Eles não deveriam ser tratados como banco de dados oficial da empresa.

Se um cliente pergunta o preço de um produto, a resposta não deveria depender de o modelo “lembrar” qual preço apareceu em um documento ou em uma instrução escrita meses atrás.

A IA deveria consultar a fonte oficial naquele momento.

O mesmo vale para:

• preço;
• estoque;
• prazo de entrega;
• condições de pagamento;
• dados cadastrais;
• situação de um pedido;
• políticas comerciais;
• histórico de atendimento;
• informações contratuais;
• documentos internos que mudam ao longo do tempo.

Para quem utiliza o sistema, isso pode parecer apenas uma boa resposta no WhatsApp.

Por trás dela, porém, existe uma diferença arquitetural importante.

Uma implementação simples pode pedir ao modelo: “responda com base no que você sabe sobre nossos produtos”.

Uma implementação responsável pode determinar: “quando a pergunta envolver preço, consulte a tabela oficial; quando envolver estoque, consulte o sistema de estoque; quando envolver situação do pedido, consulte o pedido correspondente; se a fonte estiver indisponível, não invente a resposta”.

A empresa não precisa conhecer os nomes técnicos usados para construir essa camada.

Precisa apenas exigir o resultado correto:

Fatos operacionais devem vir das fontes oficiais da empresa. A IA interpreta esses fatos; não deveria inventá-los.

É por isso que uma boa implementação de IA frequentemente envolve muito mais do que o próprio modelo. Bancos de dados, integrações, documentos internos, sistemas de gestão e serviços já utilizados pela empresa precisam participar da arquitetura.

O agente passa a trabalhar dentro da operação, e não ao lado dela tentando reproduzir de memória o que a operação sabe.

Fonte de verdade não resolve tudo

Conectar a IA às informações corretas reduz uma classe importante de erros, mas não resolve o problema inteiro.

Um agente pode consultar corretamente que um produto custa R$ 100 e ainda oferecer R$ 70 sem autorização.

Pode descobrir que existem três unidades no estoque e prometer entrega no mesmo dia sem saber que o último horário de expedição já passou.

Pode encontrar a política de troca correta e interpretar incorretamente uma exceção.

Pode acessar todo o histórico de um cliente e mesmo assim executar uma ação que deveria depender de aprovação humana.

Por isso, uma arquitetura responsável precisa combinar pelo menos três dimensões.

1. Fonte de verdade

De onde vêm os fatos?

Preço, estoque, pedidos, políticas, contratos e informações cadastrais precisam ter fontes identificáveis e atualizadas.

A IA pode interpretar e combinar essas informações, mas não deveria ser a origem arbitrária de um fato operacional que já existe em outro sistema.

2. Limite de autoridade

O que a IA pode decidir?

Uma empresa pode permitir que o agente responda preços livremente, conceda descontos até determinado limite e encaminhe qualquer exceção acima desse valor para aprovação.

Em outro processo, talvez a IA possa sugerir a decisão, mas nunca tomá-la.

A fronteira não precisa ser igual para toda a empresa.

Ela precisa ser proporcional ao risco de cada ação.

3. Controle de execução

O que a IA pode efetivamente fazer?

Existe diferença entre concluir que um pedido deveria ser cancelado e ter permissão para cancelar o pedido.

Entre sugerir uma resposta e enviá-la.

Entre identificar um possível desconto e aplicá-lo.

Entre detectar uma inconsistência cadastral e sobrescrever o dado existente.

Uma arquitetura madura separa raciocínio de execução quando essa separação reduz risco.

Fonte de verdade + limite de autoridade + controle de execução.

Essa combinação é muito mais importante para a segurança operacional do que simplesmente escolher um modelo “mais inteligente”.

Nem toda decisão precisa de aprovação humana

Defender implementação responsável não significa transformar todo agente em uma interface que pede autorização a uma pessoa antes de cada resposta.

Se isso acontecer, boa parte do ganho da automação desaparece.

Considere uma loja em que um cliente pergunta:

“Vocês têm esse batom disponível e quanto custa?”

Se preço e estoque estão disponíveis em fontes confiáveis, não existe motivo operacional para uma pessoa precisar aprovar a resposta.

A IA pode consultar os sistemas e responder imediatamente.

Agora imagine a continuação:

“Se eu levar quatro, consegue fazer 20% de desconto?”

A partir daí, a autoridade muda.

Talvez a política comercial permita automaticamente 5% para aquela categoria. O agente pode ter autonomia para conceder esse limite.

Talvez qualquer condição acima disso exija aprovação de um gerente.

O sistema não precisa escolher entre “IA decide tudo” e “IA não decide nada”.

Pode funcionar assim:

Pergunta de estoque → consulta e responde automaticamente.

Desconto dentro da política → concede automaticamente.

Exceção comercial → coleta contexto e encaminha para aprovação.

Isso é muito diferente de simplesmente escrever no prompt: “não dê descontos altos”.

A regra relevante pode existir fora do modelo e ser aplicada como parte do sistema.

Responsabilidade não significa reduzir a IA a um assistente inútil. Significa dar autonomia proporcional ao risco.

É a mesma lógica que discutimos ao analisar quando realmente faz sentido implementar IA em uma empresa: antes da ferramenta, é preciso entender o processo, distinguir o que é regra objetiva do que exige interpretação e decidir onde uma pessoa precisa continuar responsável.

O que deve acontecer quando a IA não sabe

Muitos agentes são construídos com uma expectativa implícita perigosa: qualquer mensagem recebida precisa terminar em uma resposta definitiva.

Operações reais não funcionam assim.

Existem momentos em que a melhor resposta de um sistema é reconhecer que não possui autoridade ou informação suficiente para continuar sozinho.

Uma implementação responsável precisa prever cenários como:

• a fonte oficial está temporariamente indisponível;
• duas fontes retornaram informações conflitantes;
• a pergunta está fora do escopo autorizado;
• o cliente solicitou uma exceção;
• a ação envolve um valor acima do limite configurado;
• a conversa entrou em um tema sensível que exige julgamento humano;
• a IA não encontrou evidência suficiente para afirmar o que o cliente perguntou.

Nesses casos, o comportamento correto pode ser pedir uma informação adicional, interromper a execução, registrar a pendência ou transferir a conversa para uma pessoa.

O ponto central é que a falha também precisa ser desenhada.

Não basta desenhar o caminho ideal em que todos os sistemas respondem corretamente e o cliente faz perguntas previsíveis.

É preciso decidir o que acontece quando a realidade sai desse caminho.

Uma IA que sabe parar pode ser mais valiosa do que uma IA instruída a sempre encontrar uma resposta.

O que uma implementação responsável de IA precisa definir

Antes de colocar um agente em contato com clientes, dados ou sistemas internos, uma empresa deveria conseguir responder algumas perguntas práticas.

1. De onde a IA obtém cada informação importante?
2. Quais sistemas e documentos podem ser considerados fontes oficiais?
3. O que ela pode apenas sugerir?
4. O que ela pode decidir sozinha?
5. Quais ações ela tem permissão para executar?
6. Quais limites comerciais, financeiros ou operacionais são absolutos?
7. Em quais situações uma pessoa precisa assumir?
8. O que acontece quando uma integração fica indisponível?
9. Como o sistema trata informações conflitantes ou incompletas?
10. É possível descobrir depois o que foi consultado e qual ação foi executada?
11. Quem pode alterar regras, permissões e limites?
12. Como uma mudança é testada antes de atingir clientes reais?

Essa lista revela por que integrar IA à operação é diferente de testar um bom prompt.

Um protótipo normalmente busca provar que a IA consegue executar uma tarefa.

Um sistema usado no dia a dia da empresa precisa provar que ela consegue executar a tarefa dentro das regras reais da operação, inclusive quando alguma coisa dá errado.

Ter acesso à mesma IA não significa ter o mesmo sistema

A inteligência artificial ficou extraordinariamente acessível.

Hoje, um gestor pode abrir ChatGPT, Claude, Gemini ou outra ferramenta e experimentar em minutos capacidades que poucos anos atrás exigiriam uma equipe especializada.

Essa democratização é positiva.

Também é relativamente simples obter acesso a APIs, conectar um canal de atendimento e criar um protótipo capaz de conversar com clientes.

O salto de complexidade aparece depois.

A IA precisa consultar preços reais.

Precisa reconhecer clientes existentes.

Precisa buscar pedidos.

Precisa conhecer políticas atualizadas.

Precisa ter permissões diferentes para leitura e execução.

Precisa saber quando parar.

Precisa transferir contexto para uma pessoa sem fazer o cliente recomeçar a conversa.

Precisa registrar o que aconteceu.

Precisa continuar se comportando corretamente quando um sistema externo falha.

É nesse ponto que o modelo deixa de ser uma demonstração e passa a fazer parte da infraestrutura operacional da empresa.

Os modelos estão se tornando cada vez mais acessíveis. A arquitetura responsável ao redor deles não acontece automaticamente.

Ter acesso ao mesmo modelo que uma empresa de tecnologia utiliza não significa ter o mesmo sistema.

Da mesma forma que contratar um servidor em nuvem não substitui engenharia de infraestrutura, obter uma chave de API de inteligência artificial não resolve arquitetura, integrações, permissões, observabilidade e desenho de processo.

Onde a WKing entra

A WKing não parte da pergunta “qual chatbot vamos instalar?”.

A implementação começa pela operação que a tecnologia vai tocar.

Antes de escolher modelo, ferramenta ou fornecedor, precisamos entender:

• qual trabalho a IA realmente precisa executar;
• quais informações ela precisa consultar;
• quais sistemas já possuem essas informações;
• qual autonomia o processo suporta;
• quais ações criam risco comercial, financeiro ou operacional;
• onde uma regra objetiva é melhor do que uma decisão probabilística;
• quando a interpretação da IA agrega valor;
• em quais pontos uma pessoa precisa continuar responsável;
• como o contexto será preservado durante um handoff;
• como ações e exceções serão registradas e acompanhadas.

Só então a arquitetura começa a ser definida.

Em alguns projetos, isso significa permitir que a IA consulte documentos oficiais antes de responder.

Em outros, significa conectar atendimento, CRM, estoque, pedidos e dados comerciais para que o agente trabalhe sobre informações reais.

Pode significar criar ferramentas específicas que a IA consegue acionar, limitar parâmetros que ela pode enviar, exigir aprovação em determinadas ações ou impedir tecnicamente que uma decisão ultrapasse uma política da empresa.

Para o gestor, os nomes técnicos dessas camadas são secundários.

O resultado esperado é concreto:

A IA trabalha dentro da operação, com informações confiáveis, autonomia definida e limites compatíveis com a responsabilidade que recebeu.

É justamente por isso que a WKing existe no mercado.

Não para vender acesso a um modelo de inteligência artificial que qualquer empresa já pode acessar, mas para transformar essa capacidade em um sistema que faça sentido dentro de uma operação real.

IA responsável não é IA com medo

Existem dois extremos igualmente pouco úteis na discussão sobre inteligência artificial em empresas.

O primeiro é concluir que, como modelos podem errar, nenhuma decisão deveria ser automatizada.

O segundo é testar um agente em alguns cenários, perceber que ele responde muito bem e concluir que está pronto para receber autonomia irrestrita na operação.

Uma operação madura não precisa escolher nenhum dos dois.

Ela pode automatizar agressivamente aquilo que é previsível, de baixo risco e fácil de validar.

Pode usar IA para interpretar aquilo que regras convencionais tratariam mal.

Pode conectar o agente diretamente às fontes corretas de informação.

Pode permitir execução quando a consequência é controlada.

E pode exigir uma pessoa quando julgamento, exceção, dinheiro, compromisso ou reputação justificarem essa barreira.

O caso da falsa mensagem de liquidação do Nubank chama atenção justamente porque o resultado foi extraordinário.

Mas a pergunta que ele deixa para qualquer empresa é cotidiana:

Quando uma pessoa errar, quando a IA interpretar algo errado, quando um dado faltar ou quando uma integração falhar, até onde esse erro terá permissão para chegar?

A resposta não deveria ser “até o cliente e depois a gente corrige”.

É para definir essas fronteiras que existem arquitetura, engenharia, controles e desenho de operação.

Inteligência artificial na operação não precisa ser sinônimo de imprudência.

Quando implementada de forma responsável, ela pode assumir cada vez mais trabalho sem receber autoridade maior do que aquela que o processo realmente suporta.

Tecnologia para operações reais.