O Bug de US$ 89 Milhões: O Que Apple e Goldman Sachs Não Entenderam Sobre IA no Setor Financeiro
Eu estava sentado no meu escritório em casa numa terça-feira à noite, em outubro passado, quando o comunicado do CFPB apareceu no meu feed. Apple e Goldman Sachs, obrigadas a pagar mais de US$ 89 milhões por falhas sistêmicas na forma como lidaram com as contestações do Apple Card. Li a ordem de consentimento duas vezes. Depois li uma terceira vez, porque eu não conseguia acreditar no que estava vendo.
A falha central não foi alguma engenharia financeira exótica que deu errado. Não foi um algoritmo desgovernado tomando decisões discriminatórias de crédito. Foi um botão. Um formulário secundário no app Apple Wallet que, quando deixado incompleto pelos consumidores, fazia com que suas contestações de fatura sumissem em um vazio digital. Dezenas de milhares de pessoas relataram cobranças não autorizadas, e o sistema simplesmente... engoliu tudo. Sem investigação. Sem acusação de recebimento. Sem resolução. Os consumidores ficaram com a conta na mão.
Eu construo sistemas de IA para viver. Minha empresa, a Veriprajna, foca no que chamamos de deep AI — arquiteturas neurossimbólicas que combinam a flexibilidade dos grandes modelos de linguagem com o rigor matemático da verificação formal. Quando li aquela ordem de consentimento, não senti nenhuma satisfação por estar certo. Me senti mal. Porque tudo o que deu errado com o Apple Card era evitável. Não com testes melhores. Não com mais engenheiros. Com uma forma fundamentalmente diferente de pensar como sistemas de IA devem ser construídos para setores regulados.
O Que Realmente Aconteceu com a Sua Contestação do Apple Card?
Deixe-me guiá-lo pela falha, porque os detalhes importam mais do que o número da manchete.
Apple e Goldman Sachs assinaram seu acordo de parceria em 2017. A Apple seria dona da experiência do consumidor — a interface elegante da Wallet, o sistema de mensagens, todo o front end. O Goldman Sachs seria o banco atrás da cortina, emitindo crédito, processando transações e investigando contestações quando algo desse errado.
Em junho de 2020, a Apple lançou uma atualização do fluxo de trabalho "Report an Issue". Antes da atualização, você tocava em uma transação suspeita, clicava em "Report an Issue" e era direcionado a um chat baseado no Messages com o Goldman Sachs. Simples. Depois da atualização, a Apple acrescentou um formulário secundário — uma etapa extra que os consumidores deveriam concluir após sua mensagem inicial.
Foi aqui que quebrou: quando as pessoas enviavam sua contestação pelo Messages mas não concluíam o formulário secundário, o sistema tratava a contestação como incompleta. Ele nunca transmitia a reclamação ao Goldman Sachs. Do ponto de vista regulatório, muitas dessas mensagens se qualificavam como Avisos de Erro de Faturamento válidos sob o Truth in Lending Act. Legalmente, elas deveriam ter disparado uma investigação dentro de prazos específicos. Em vez disso, elas desapareceram.
Dezenas de milhares de contestações de consumidores legalmente válidas foram engolidas por uma máquina de estados que ninguém havia verificado formalmente.
Lembro de ler esse detalhe e pensar em cada conversa que tive com executivos de serviços financeiros que me dizem que seus sistemas são "testados em combate". Testados em combate contra o quê? Contra o cenário específico em que uma mudança de interface introduz um estado morto em um fluxo de trabalho distribuído? Esse não é o tipo de coisa que você pega com testes unitários e sprints de QA.
A Cláusula de US$ 25 Milhões Que Quebrou Tudo
Há um detalhe enterrado na ordem de consentimento ao qual eu não paro de voltar. O contrato da Apple com o Goldman Sachs incluía uma cláusula penal de US$ 25 milhões para cada atraso de 90 dias que o Goldman causasse no lançamento do Apple Card.
Vinte e cinco milhões de dólares. Por trimestre. Por atrasar.
Já estive em salas onde a pressão comercial distorce decisões de engenharia. Já vi times entregarem coisas que sabiam não estar prontas porque o custo do atraso parecia mais concreto do que o custo da falha. Mas nunca vi a estrutura de incentivos explicitada de forma tão clara. O Goldman Sachs foi essencialmente multado antecipadamente por ser cauteloso.
O Apple Card entrou no ar em 20 de agosto de 2019. Times internos do Goldman haviam sinalizado preocupações sobre a prontidão do sistema. As filas de mensagens entre o app Wallet e o back-end do Goldman estavam subtestadas. Os protocolos de sincronização eram frágeis. Mas a matemática era simples: lançar agora e consertar depois, ou pagar US$ 25 milhões e consertar antes.
Eles lançaram. E, por mais de um ano, o sistema rodou com um buraco que ninguém conseguia ver de fora.
Penso nisso quando as pessoas me perguntam por que a Veriprajna insiste em verificação formal antes da implantação. "Isso não é lento?", perguntam. "Você não pode só monitorar em produção e pegar os problemas?" Claro. Você também pode dirigir sem freios e planejar desviar dos obstáculos. Funciona até não funcionar. E quando não funciona em serviços financeiros, pessoas reais se machucam.
Por Que Ninguém Percebeu Isso?
Essa é a pergunta que me assombra. Duas das empresas tecnologicamente mais sofisticadas do planeta — a Apple, com sua lendária cultura de engenharia, e o Goldman Sachs, com seu poder de fogo quantitativo — e nenhuma das duas notou que milhares de contestações estavam caindo em um buraco negro?
A resposta, eu acho, é arquitetural. O sistema foi projetado como um retransmissor: a Apple cuida do front end, o Goldman cuida do back end, e as mensagens fluem entre eles. Mas ninguém era dono do espaço entre os dois sistemas. Ninguém tinha um modelo formal do que deveria acontecer quando uma contestação entrava no estado A ("mensagem enviada") mas nunca chegava ao estado B ("formulário concluído"). Em uma máquina de estados bem projetada, essa é uma transição que você contempla explicitamente. No sistema do Apple Card, era uma lacuna que ninguém especificou e, portanto, ninguém monitorou.
Fiquei até tarde há cerca de um ano — minha equipe e eu estávamos construindo um fluxo de trabalho de compliance para um cliente, e uma das nossas engenheiras, Priya, sinalizou algo parecido. Ela estava modelando as transições de estado de um processo de revisão de documentos e encontrou um caminho em que um envio poderia ficar preso indefinidamente em um estado de "enriquecimento pendente" se uma API de terceiros desse timeout. Não era um bug no código. O código fazia exatamente o que lhe foi mandado. Era um bug no design — um estado que a especificação não contemplava.
Nós pegamos isso porque usamos ferramentas de verificação formal — especificamente, modelamos fluxos de trabalho como máquinas de estados e os passamos por solvers SMT que checam exaustivamente todos os caminhos possíveis. O solver encontrou o estado morto da Priya em segundos. No sistema do Apple Card, aquele estado morto rodou em produção por meses.
A falha do Apple Card não foi um bug no código. O código fazia exatamente o que lhe foi mandado. Foi um bug no design — um estado que ninguém especificou e, portanto, ninguém monitorou.
Por Que Você Não Pode Simplesmente Usar GPT Para Isso?
Recebo essa pergunta o tempo todo. Um investidor me disse quase isso, palavra por palavra, durante uma reunião de pitch: "Por que você não pode só fazer fine-tuning do GPT-4 nas normas do TILA e deixar que ele cuide das contestações?"
Respirei. Então perguntei a ele: "Se o GPT-4 disser a um consumidor que a contestação dele foi resolvida, mas na verdade ela não foi transmitida ao banco, quem é o responsável?"
Ele não tinha resposta. Nem ninguém mais tem, porque a pergunta expõe o problema fundamental do que eu chamo de abordagem do "mega-prompt" para IA em setores regulados. Você pega um grande modelo de linguagem, enfia a regulamentação relevante na sua janela de contexto e torce para que ele lide com tudo corretamente. Sem camada de governança. Sem verificação formal. Sem garantia matemática de que as saídas do sistema são consistentes com a lei.
No caso do Apple Card, a falha foi um erro de lógica em uma máquina de estados distribuída. Um wrapper de LLM não teria consertado isso — poderia ter piorado. Imagine um LLM dizendo confiantemente a um consumidor "Sua contestação foi enviada e está sendo investigada" quando, na realidade, a contestação nunca saiu dos servidores da Apple. Isso não é hipotético. É assim que a alucinação se parece em um contexto financeiro, e é aterrorizante.
Os sites populares que explicam finanças e o conteúdo amplamente compartilhado sobre IA em bancos quase universalmente ignoram essa distinção. Eles falam sobre IA "automatizando" o compliance como se a parte difícil fosse ler as normas. A parte difícil não é lê-las. A parte difícil é provar que o seu sistema as cumpre em todos os cenários possíveis, inclusive cenários que você ainda nem imaginou.
Para um olhar mais profundo sobre como a falha Apple-Goldman se mapeia a violações regulatórias específicas e lacunas arquiteturais, escrevi uma análise interativa que percorre a ordem de consentimento em detalhes.
O Que "Comprovadamente Correto" Realmente Significa
Quando digo que a Veriprajna constrói sistemas de compliance "comprovadamente corretos", não quero dizer "muito bem testados". Quero dizer matematicamente provados. Há uma diferença, e ela importa enormemente.
Testes checam cenários específicos. Você escreve um teste que diz "se um usuário envia uma contestação e preenche o formulário, verifique que ela chega ao Goldman Sachs". Esse teste passa. Ótimo. Mas você não testou o cenário em que o usuário envia uma contestação e não preenche o formulário. Ou em que ele preenche, mas a rede derruba o pacote. Ou em que duas contestações chegam simultaneamente e uma sobrescreve a outra.
A verificação formal não checa cenários. Ela checa propriedades. Você define uma propriedade — "toda contestação enviada deve eventualmente alcançar um estado de investigação" — e um solver matemático prova exaustivamente que a propriedade vale em toda execução possível do sistema. Todo caminho. Todo caso de borda. Toda condição de corrida. Se existir um único contraexemplo, o solver o encontra e mostra exatamente como o sistema pode falhar.
Usamos ferramentas como o Imandra, que nos permite construir o que é essencialmente um gêmeo digital da lógica de compliance. O gêmeo roda ao lado do sistema de produção e, se o código de produção alguma vez tentar uma ação que se desvie do modelo verificado — como descartar uma contestação por causa de uma etapa incompleta na interface — o sistema pega isso em tempo real.
Esse é o tipo de abordagem que teria pego o bug do Apple Card antes que um único consumidor fosse afetado. Durante a fase de design, um solver SMT teria identificado imediatamente que a variável "CompletedFormB" não era um campo obrigatório sob o TILA. A lógica de transmissão o exigia, mas a lei não. Essa incompatibilidade é um defeito comprovável, e teria sido sinalizada antes da implantação.
A Arquitetura Que Realmente Construímos
Quero ser específico sobre como um sistema de compliance de "deep AI" se parece na prática, porque afirmações vagas sobre "compliance movido a IA" são parte do problema.
A Veriprajna usa uma arquitetura multiagente. Em vez de uma IA monolítica tentando fazer tudo, implantamos agentes especializados com papéis e fronteiras definidos. Pense nisso menos como contratar um gênio e mais como montar um time em que todos têm um trabalho específico e um supervisor conferindo o serviço.
Um Agente de Recepção cuida da parte bagunçada e humana — interpretar contestações em linguagem natural. Quando alguém escreve "Eu nunca comprei esse café em Seattle; eu estava em Londres naquele dia", o agente extrai as entidades-chave: a transação, o estabelecimento, a data, a natureza da reivindicação. É aqui que os LLMs realmente brilham.
Mas então — e é aqui que divergimos de toda abordagem baseada em wrapper que já vi — as informações extraídas passam para um Motor de Políticas simbólico que não prevê nem adivinha. Ele avalia a contestação à luz de codificações em lógica de primeira ordem da legislação federal. Esta mensagem contém informação suficiente para constituir um Aviso de Erro de Faturamento válido sob o TILA? O motor não estima. Ele prova.
Um Agente de Fluxo de Trabalho impõe a sequência de operações. Um Agente de Verificação roda checagens matemáticas em tempo real. Um Agente de Auditoria registra cada interação no que chamamos de "caixa de vidro" — transparência completa para os reguladores.
E, de forma crítica, um Agente Sentinela monitora exatamente o tipo de estado morto que matou o sistema do Apple Card. Se uma contestação fica em "enviada mas não transmitida" por mais tempo do que um limite definido, o Sentinela não espera que um humano perceba. Ele determina autonomamente se a informação existente é suficiente para prosseguir, a empacota e a transmite por um canal verificado.
Em um sistema construído para compliance absoluto, é a lei — não a interface — que determina se uma contestação é válida. Se um consumidor lhe informou sobre uma cobrança não autorizada, a ausência de um formulário preenchido é problema seu, não dele.
Por Que o Tempo É uma Exigência Legal, Não uma Métrica de Desempenho
Há outra dimensão nisso que a maioria das discussões técnicas ignora por completo. Em compliance financeiro, tempo é lei. A Regulation Z não diz apenas que você tem de investigar contestações. Ela diz que você tem de acusar o recebimento delas dentro de períodos específicos e resolvê-las em até 60 dias. O Goldman Sachs foi multado em parte porque não enviou os avisos de acusação de recebimento dentro desses prazos.
Minha equipe passou meses desenvolvendo o que chamamos de análise de Latência Simbólica — uma forma de provar matematicamente que um sistema distribuído concluirá seu trabalho dentro de um prazo regulatório sob condições de pior caso. Não condições médias. Não "percentil 95". Pior caso.
O monitoramento tradicional diz se o seu sistema esteve lento. A Latência Simbólica diz se o seu sistema pode ficar lento. Se uma mudança no código da interface aumentar o tempo de processamento de pior caso além do prazo regulatório de 60 dias, a implantação é automaticamente rejeitada. Você não descobre depois do fato. Você descobre antes de lançar.
Lembro da discussão que tivemos internamente sobre se esse nível de rigor era necessário. Um dos meus engenheiros — um cara brilhante que passara anos em um grande provedor de nuvem — resistiu com força. "Você está acrescentando semanas ao ciclo de implantação por causa de um cenário que talvez nunca aconteça", disse ele. Apontei para a ordem de consentimento do Apple Card. "Aconteceu", eu disse. "Com a Apple. Com o Goldman Sachs. Com dezenas de milhares de consumidores que não fizeram nada de errado."
Depois disso, ele não discutiu mais.
Para o detalhamento técnico completo da nossa abordagem de verificação formal, incluindo a metodologia Performal para limites de latência, veja nosso artigo de pesquisa.
"Mas Isso Demoraria Demais Para Construir"
As pessoas sempre resistem nesse ponto, e eu entendo por quê. O Apple Card foi lançado em meses. Uma arquitetura de compliance formalmente verificada leva de 18 a 36 meses para otimização completa em um ambiente dominado por sistemas legados. Isso parece uma eternidade em um mundo em que os concorrentes lançam toda semana.
Mas deixe-me reformular a matemática. Apple e Goldman Sachs passaram anos construindo e lançando o Apple Card. Depois passaram anos lidando com as consequências — investigações internas, exames regulatórios, custos jurídicos, dano reputacional e, por fim, US$ 89,8 milhões em penalidades e ressarcimento a consumidores. A abordagem "rápida" não foi rápida. Foi velocidade na largada e catástrofe na chegada.
Nossa abordagem de implantação em fases reconhece a realidade. Você não pode arrancar os sistemas centrais de um banco. Mainframes COBOL que rodam desde os anos 1980 não vão sumir da noite para o dia. Então integramos em camadas: auditar a arquitetura existente, construir um gateway de API inteligente, rodar o sistema de IA em modo sombra para validar as saídas do sistema legado e, gradualmente, transferir a autoridade de decisão à medida que as provas formais se acumulam.
A primeira fase — avaliação e modelagem formal — leva de 14 a 20 semanas. Ao final dela, você tem um modelo matemático da sua lógica de compliance capaz de pegar o tipo de bug de estado morto que assolou o Apple Card. Isso não são 36 meses. São menos de cinco meses até um sistema fundamentalmente mais seguro.
O Momento Que Mudou Como Eu Penso Sobre Isso
Há um momento específico ao qual eu não paro de voltar. Foi há cerca de oito meses, e estávamos rodando uma prova de conceito para um cliente de serviços financeiros. Havíamos modelado o fluxo de trabalho de resolução de contestações deles como uma máquina de estados distribuída e estávamos rodando a suíte de verificação formal.
O solver encontrou onze estados mortos.
Onze caminhos pelo sistema em que a reclamação de um consumidor podia ficar presa sem resolução e sem alerta. O time de engenharia do cliente rodava esse sistema havia três anos. Eles tinham processado milhões de transações. Tinham dashboards de monitoramento, sistemas de alerta, auditorias trimestrais. E nada disso havia pego esses onze buracos.
A sala silenciou quando mostrei os resultados a eles. A chefe de compliance deles — uma mulher que passara vinte anos em regulação bancária — olhou para a tela e disse: "Quantos consumidores caíram nesses estados?"
Nós não sabíamos. Eles também não sabiam. Essa é a questão dos estados mortos em sistemas distribuídos: se ninguém está de olho neles, eles são invisíveis. Os consumidores afetados podem ter ligado para o atendimento, sido enrolados e, por fim, desistido. Ou podem ainda estar pagando por cobranças que nunca fizeram.
É essa a cara da falha do Apple Card por dentro. Não uma explosão dramática. Um acúmulo lento e silencioso de dano que ninguém consegue ver até que um regulador force a abertura da caixa-preta.
Como Serão os Próximos Cinco Anos
A ação do CFPB contra Apple e Goldman Sachs não é um evento isolado. É o começo de um acerto de contas regulatório sobre como as empresas de tecnologia lidam com a infraestrutura financeira. À medida que o setor bancário se torna mais embarcado — em telefones, em apps, em plataformas que não foram originalmente projetadas como serviços financeiros — a lacuna entre "funciona na maior parte do tempo" e "comprovadamente funciona o tempo todo" se torna um passivo medido em centenas de milhões de dólares.
Penso na objeção que mais ouço: "A verificação formal não é exagero para a maioria dos sistemas financeiros?" E minha resposta ficou mais simples com o tempo. O Apple Card é um dos produtos financeiros de consumo mais visíveis do mundo, construído por duas empresas com recursos de engenharia essencialmente ilimitados. Se elas não conseguiram pegar um estado morto em um fluxo de trabalho de contestações por meio de testes e monitoramento tradicionais, o que faz você pensar que o seu sistema é diferente?
O setor está caminhando para o que eu chamo de Compliance Absoluto — não compliance como exercício de marcar caixinha, mas compliance como propriedade arquitetural. Um sistema em que a aderência à lei não é algo que você verifica depois do fato, mas algo que você prova antes da implantação. Onde a lacuna entre a interface e a regulamentação é preenchida não por vigilância humana, mas por certeza matemática.
A era do "lance rápido e conserte depois" é incompatível com as exigências de "mover dinheiro e proteger pessoas" das finanças globais. O Apple Card provou isso. A questão é se o setor aprende a lição antes ou depois da próxima multa de US$ 89 milhões.
Estamos construindo esse futuro na Veriprajna. Não porque seja fácil — a verificação formal de sistemas financeiros distribuídos é genuinamente difícil, e quem lhe disser o contrário está vendendo alguma coisa. Mas porque a alternativa é o que vimos em outubro de 2024: duas das empresas mais poderosas do mundo, um botão quebrado e dezenas de milhares de pessoas deixadas com a conta na mão por cobranças que nunca fizeram.
Isso não é um problema de tecnologia. É um problema de ética na engenharia. E a solução não é monitoramento melhor nem correções mais rápidas. É construir sistemas que sejam corretos por construção — sistemas em que a matemática garante que a contestação de nenhum consumidor jamais sumirá em um vazio.
A multa de US$ 89 milhões já foi paga. O custo real é a confiança que foi quebrada. Reconstruí-la exige mais do que promessas. Exige prova.