El fallo de 89 millones de dólares: qué hicieron mal Apple y Goldman Sachs con la IA en las finanzas

Estaba sentado en mi oficina en casa un martes por la noche del pasado octubre cuando el comunicado de prensa del CFPB apareció en mi feed. Apple y Goldman Sachs, obligados a pagar más de 89 millones de dólares por fallos sistémicos en la forma en que gestionaron las disputas de la Apple Card. Leí la orden de consentimiento dos veces. Luego la leí una tercera vez, porque no podía creer lo que estaba viendo.

El fallo central no fue una exótica ingeniería financiera que salió mal. No fue un algoritmo descontrolado tomando decisiones de préstamo discriminatorias. Fue un botón. Un formulario secundario en la app Apple Wallet que, cuando los consumidores lo dejaban incompleto, hacía que sus disputas de facturación se desvanecieran en un vacío digital. Decenas de miles de personas denunciaron cargos no autorizados, y el sistema simplemente... se los tragó. Sin investigación. Sin acuse de recibo. Sin resolución. Los consumidores se quedaron con la factura.

Me dedico a construir sistemas de IA. Mi empresa, Veriprajna, se centra en lo que llamamos IA profunda: arquitecturas neurosimbólicas que combinan la flexibilidad de los grandes modelos de lenguaje con el rigor matemático de la verificación formal. Cuando leí esa orden de consentimiento, no me sentí reivindicado. Me sentí mal. Porque todo lo que salió mal con la Apple Card era evitable. No con mejores pruebas. No con más ingenieros. Con una forma fundamentalmente distinta de pensar cómo deben construirse los sistemas de IA para los sectores regulados.

¿Qué le pasó realmente a tu disputa de la Apple Card?

Déjame guiarte por el fallo, porque los detalles importan más que la cifra del titular.

Apple y Goldman Sachs firmaron su acuerdo de colaboración en 2017. Apple sería dueña de la experiencia del consumidor: la elegante interfaz de Wallet, el sistema de mensajería, todo el front end. Goldman Sachs sería el banco detrás del telón, emitiendo crédito, procesando transacciones e investigando las disputas cuando algo salía mal.

En junio de 2020, Apple publicó una actualización del flujo de "Informar de un problema". Antes de la actualización, tocabas una transacción sospechosa, pulsabas "Informar de un problema" y se te redirigía a un chat basado en Messages con Goldman Sachs. Sencillo. Después de la actualización, Apple añadió un formulario secundario: un paso adicional que se suponía que los consumidores debían completar tras su mensaje inicial.

Aquí es donde se rompió: cuando la gente presentaba su disputa a través de Messages pero no terminaba el formulario secundario, el sistema trataba la disputa como incompleta. Nunca transmitía la reclamación a Goldman Sachs. Desde el punto de vista regulatorio, muchos de esos mensajes cumplían los requisitos de un Aviso de Error de Facturación válido bajo la Truth in Lending Act. Legalmente, deberían haber activado una investigación dentro de plazos concretos. En cambio, desaparecieron.

Decenas de miles de disputas de consumidores legalmente válidas fueron engullidas por una máquina de estados que nadie había verificado formalmente.

Recuerdo leer ese detalle y pensar en cada conversación que he tenido con directivos de servicios financieros que me dicen que sus sistemas están "probados en combate". ¿Probados en combate contra qué? ¿Contra el escenario concreto en el que un cambio de interfaz introduce un estado muerto en un flujo de trabajo distribuido? Eso no es algo que detectes con pruebas unitarias y sprints de QA.

La cláusula de 25 millones de dólares que lo rompió todo

Hay un detalle enterrado en la orden de consentimiento al que sigo volviendo. El contrato de Apple con Goldman Sachs incluía una cláusula de daños y perjuicios liquidados de 25 millones de dólares por cada retraso de 90 días que Goldman causara en el lanzamiento de la Apple Card.

Veinticinco millones de dólares. Por trimestre. Por llegar tarde.

He estado en salas donde la presión comercial deforma las decisiones de ingeniería. He visto equipos lanzar cosas que sabían que no estaban listas porque el coste del retraso parecía más concreto que el coste del fallo. Pero nunca había visto la estructura de incentivos formulada de forma tan explícita. En la práctica, a Goldman Sachs se le multaba por adelantado por ser prudente.

La Apple Card se lanzó el 20 de agosto de 2019. Los equipos internos de Goldman habían señalado preocupaciones sobre si el sistema estaba listo. Las colas de mensajes entre la app Wallet y el back-end de Goldman estaban poco probadas. Los protocolos de sincronización eran frágiles. Pero las cuentas eran simples: lanzar ahora y arreglarlo después, o pagar 25 millones de dólares y arreglarlo primero.

Lanzaron. Y durante más de un año, el sistema funcionó con un agujero que nadie podía ver desde fuera.

Pienso en esto cuando la gente me pregunta por qué Veriprajna insiste en la verificación formal antes del despliegue. "¿No es lento eso?", preguntan. "¿No puedes simplemente monitorizar en producción y detectar los problemas?". Claro. También puedes conducir sin frenos y planear esquivar los obstáculos. Funciona hasta que deja de funcionar. Y cuando deja de funcionar en los servicios financieros, hay personas reales que salen perjudicadas.

¿Por qué nadie detectó esto?

Esta es la pregunta que me persigue. Dos de las empresas tecnológicamente más sofisticadas del planeta —Apple, con su legendaria cultura de ingeniería, y Goldman Sachs, con su potencia cuantitativa— ¿y ninguna de las dos se dio cuenta de que miles de disputas estaban cayendo en un agujero negro?

La respuesta, creo, es arquitectónica. El sistema se diseñó como un relevo: Apple gestiona el front end, Goldman gestiona el back end y los mensajes fluyen entre ambos. Pero nadie era dueño del espacio entre los dos sistemas. Nadie tenía un modelo formal de qué debía ocurrir cuando una disputa entraba en el estado A ("mensaje enviado") pero nunca llegaba al estado B ("formulario completado"). En una máquina de estados bien diseñada, esa es una transición que contemplas explícitamente. En el sistema de la Apple Card, era una brecha que nadie especificó, así que nadie monitorizó.

Recuerdo una noche de trabajo hasta tarde, hace cosa de un año: mi equipo y yo estábamos construyendo un flujo de trabajo de cumplimiento para un cliente, y una de nuestras ingenieras, Priya, señaló algo parecido. Había estado modelando las transiciones de estado de un proceso de revisión documental y encontró un camino en el que un envío podía quedarse atascado indefinidamente en un estado de "pendiente de enriquecimiento" si una API de terceros agotaba el tiempo de espera. No era un error de código. El código hacía exactamente lo que se le había dicho. Era un error de diseño — un estado que la especificación no contemplaba.

Lo detectamos porque usamos herramientas de verificación formal: en concreto, modelamos los flujos de trabajo como máquinas de estados y los pasamos por solucionadores SMT que comprueban exhaustivamente todos los caminos posibles. El solucionador encontró el estado muerto de Priya en segundos. En el sistema de la Apple Card, ese estado muerto estuvo en producción durante meses.

El fracaso de la Apple Card no fue un error de código. El código hacía exactamente lo que se le había dicho. Fue un error de diseño: un estado que nadie especificó, así que nadie monitorizó.

¿Por qué no puedes usar simplemente GPT para esto?

Me hacen esta pregunta constantemente. Un inversor me la dijo casi textualmente durante una reunión de presentación: "¿Por qué no puedes simplemente ajustar (fine-tuning) GPT-4 con la normativa TILA y dejar que gestione las disputas?".

Tomé aire. Luego le pregunté: "Si GPT-4 le dice a un consumidor que su disputa se ha resuelto, pero en realidad no se ha transmitido al banco, ¿quién es responsable?".

No tenía respuesta. Nadie la tiene, porque la pregunta expone el problema fundamental de lo que yo llamo el enfoque del "mega-prompt" para la IA en sectores regulados. Coges un gran modelo de lenguaje, metes la normativa relevante en su ventana de contexto y esperas que lo maneje todo correctamente. Sin capa de gobernanza. Sin verificación formal. Sin garantía matemática de que las salidas del sistema sean coherentes con la ley.

En el caso de la Apple Card, el fallo fue un error lógico en una máquina de estados distribuida. Un envoltorio sobre un LLM no habría arreglado esto; podría haberlo empeorado. Imagina un LLM diciéndole a un consumidor con toda confianza "Tu disputa se ha enviado y está siendo investigada" cuando, en realidad, la disputa nunca salió de los servidores de Apple. Eso no es una hipótesis. Así es como se ve la alucinación en un contexto financiero, y es aterrador.

Los sitios populares que explican finanzas y el contenido sobre IA en la banca que más se comparte pasan por alto casi universalmente esta distinción. Hablan de que la IA "automatiza" el cumplimiento como si la parte difícil fuera leer la normativa. Lo difícil no es leerla. Lo difícil es demostrar que tu sistema la cumple en todos los escenarios posibles, incluidos los que aún no se te han ocurrido.

Para un análisis más profundo de cómo el fallo de Apple-Goldman se corresponde con infracciones regulatorias concretas y brechas arquitectónicas, escribí un análisis interactivo que recorre la orden de consentimiento en detalle.

Qué significa realmente "demostrablemente correcto"

Cuando digo que Veriprajna construye sistemas de cumplimiento "demostrablemente correctos", no me refiero a "muy bien probados". Me refiero a matemáticamente demostrados. Hay una diferencia, y importa enormemente.

Las pruebas comprueban escenarios concretos. Escribes una prueba que dice "si un usuario presenta una disputa y completa el formulario, verifica que llega a Goldman Sachs". Esa prueba pasa. Genial. Pero no has probado el escenario en el que el usuario presenta una disputa y no completa el formulario. O en el que lo completa pero la red pierde el paquete. O en el que llegan dos disputas simultáneamente y una sobrescribe a la otra.

La verificación formal no comprueba escenarios. Comprueba propiedades. Defines una propiedad —"toda disputa presentada debe llegar en algún momento a un estado de investigación"— y un solucionador matemático demuestra exhaustivamente que la propiedad se cumple en toda ejecución posible del sistema. Todos los caminos. Todos los casos límite. Todas las condiciones de carrera. Si hay un solo contraejemplo, el solucionador lo encuentra y te muestra exactamente cómo puede fallar el sistema.

Usamos herramientas como Imandra, que nos permite construir lo que es esencialmente un gemelo digital de la lógica de cumplimiento. El gemelo se ejecuta junto al sistema de producción y, si el código de producción intenta alguna vez una acción que se desvía del modelo verificado —como descartar una disputa por un paso de interfaz incompleto—, el sistema lo detecta en tiempo real.

Este es el tipo de enfoque que habría detectado el fallo de la Apple Card antes de que un solo consumidor se viera afectado. Durante la fase de diseño, un solucionador SMT habría identificado de inmediato que la variable "CompletedFormB" no era un campo obligatorio bajo la TILA. La lógica de transmisión lo exigía, pero la ley no. Ese desajuste es un defecto demostrable, y se habría señalado antes del despliegue.

La arquitectura que realmente construimos

Quiero ser concreto sobre cómo es en la práctica un sistema de cumplimiento de "IA profunda", porque las afirmaciones vagas sobre el "cumplimiento impulsado por IA" son parte del problema.

Veriprajna usa una arquitectura multiagente. En lugar de una IA monolítica que intenta hacerlo todo, desplegamos agentes especializados con roles y límites definidos. Piénsalo menos como contratar a un genio y más como formar un equipo donde cada uno tiene un trabajo concreto y un supervisor que revisa su trabajo.

Un Agente de Recepción se ocupa de la parte desordenada y humana: interpretar disputas en lenguaje natural. Cuando alguien escribe "Yo nunca compré este café en Seattle; ese día estaba en Londres", el agente extrae las entidades clave: la transacción, el comercio, la fecha, la naturaleza de la reclamación. Aquí es donde los LLM brillan de verdad.

Pero entonces —y aquí es donde nos apartamos de todos los enfoques basados en envoltorios que he visto— la información extraída pasa a un Motor de Políticas simbólico que no predice ni adivina. Evalúa la disputa frente a codificaciones en lógica de primer orden de la ley federal. ¿Contiene este mensaje información suficiente para constituir un Aviso de Error de Facturación válido bajo la TILA? El motor no estima. Demuestra.

Un Agente de Flujo de Trabajo hace cumplir la secuencia de operaciones. Un Agente de Verificación ejecuta comprobaciones matemáticas en tiempo real. Un Agente de Auditoría registra cada interacción en lo que llamamos una "caja de cristal": transparencia completa para los reguladores.

Y, de forma crítica, un Agente Centinela vigila exactamente el tipo de estado muerto que mató al sistema de la Apple Card. Si una disputa permanece en "enviada pero no transmitida" más allá de un umbral definido, el Centinela no espera a que un humano se dé cuenta. Determina de forma autónoma si la información existente es suficiente para continuar, la empaqueta y la transmite por un canal verificado.

En un sistema construido para el cumplimiento absoluto, es la ley —no la interfaz— la que determina si una disputa es válida. Si un consumidor te ha informado de un cargo no autorizado, la ausencia de un formulario completado es tu problema, no el suyo.

Por qué los plazos son un requisito legal, no una métrica de rendimiento

Hay otra dimensión en esto que la mayoría de los debates técnicos pasan totalmente por alto. En el cumplimiento financiero, el tiempo es ley. Regulation Z no dice solo que tienes que investigar las disputas. Dice que tienes que acusar recibo de ellas dentro de plazos concretos y resolverlas en 60 días. A Goldman Sachs se le multó en parte porque no envió los avisos de acuse de recibo dentro de esas ventanas.

Mi equipo pasó meses desarrollando lo que llamamos el análisis de Latencia Simbólica: una forma de demostrar matemáticamente que un sistema distribuido completará su trabajo dentro de un plazo regulatorio en las peores condiciones posibles. No en condiciones medias. No en el "percentil 95". En el peor caso.

La monitorización tradicional te dice si tu sistema fue lento. La Latencia Simbólica te dice si tu sistema puede ser lento. Si un cambio en el código de la interfaz aumenta el tiempo de procesamiento en el peor caso más allá de la ventana regulatoria de 60 días, el despliegue se rechaza automáticamente. No te enteras después de los hechos. Te enteras antes de lanzar.

Recuerdo la discusión que tuvimos internamente sobre si este nivel de rigor era necesario. Uno de mis ingenieros —un tipo brillante que había pasado años en un gran proveedor de nube— se opuso con fuerza. "Estás añadiendo semanas al ciclo de despliegue por un escenario que quizá nunca ocurra", dijo. Le señalé la orden de consentimiento de la Apple Card. "Ocurrió", le dije. "A Apple. A Goldman Sachs. A decenas de miles de consumidores que no hicieron nada mal".

Después de eso no discutió más.

Para el desglose técnico completo de nuestro enfoque de verificación formal, incluida la metodología Performal para los límites de latencia, consulta nuestro artículo de investigación.

"Pero esto tardaría demasiado en construirse"

La gente siempre objeta en este punto, y entiendo por qué. La Apple Card se lanzó en meses. Una arquitectura de cumplimiento formalmente verificada tarda de 18 a 36 meses hasta su optimización completa en un entorno cargado de sistemas heredados. Eso parece una eternidad en un mundo donde los competidores lanzan cada semana.

Pero déjame replantear las cuentas. Apple y Goldman Sachs pasaron años construyendo y lanzando la Apple Card. Luego pasaron años lidiando con las consecuencias: investigaciones internas, exámenes regulatorios, costes legales, daño reputacional y, en última instancia, 89,8 millones de dólares en sanciones y compensaciones a consumidores. El enfoque "rápido" no fue rápido. Fue velocidad por delante y catástrofe por detrás.

Nuestro enfoque de despliegue por fases reconoce la realidad. No puedes arrancar de cuajo los sistemas centrales de un banco. Los mainframes COBOL que llevan funcionando desde los años ochenta no van a desaparecer de la noche a la mañana. Así que integramos por capas: auditamos la arquitectura existente, construimos una pasarela de API inteligente, ejecutamos el sistema de IA en modo sombra para validar las salidas del sistema heredado y desplazamos gradualmente la autoridad de decisión a medida que se acumulan las demostraciones formales.

La primera fase —evaluación y modelado formal— dura de 14 a 20 semanas. Al terminarla, tienes un modelo matemático de tu lógica de cumplimiento capaz de detectar el tipo de fallos de estado muerto que asolaron a la Apple Card. Eso no son 36 meses. Son menos de cinco meses hasta un sistema fundamentalmente más seguro.

El momento que cambió mi forma de pensar sobre esto

Hay un momento concreto al que sigo volviendo. Fue hace unos ocho meses, y estábamos ejecutando una prueba de concepto para un cliente de servicios financieros. Habíamos modelado su flujo de resolución de disputas como una máquina de estados distribuida y estábamos ejecutando la batería de verificación formal.

El solucionador encontró once estados muertos.

Once caminos a través del sistema donde la reclamación de un consumidor podía quedarse atascada sin resolución y sin alerta. El equipo de ingeniería del cliente llevaba tres años ejecutando este sistema. Habían procesado millones de transacciones. Tenían paneles de monitorización, sistemas de alertas, auditorías trimestrales. Y nada de eso había detectado esos once agujeros.

La sala se quedó en silencio cuando les mostré los resultados. Su responsable de cumplimiento —una mujer que había pasado veinte años en regulación bancaria— miró la pantalla y dijo: "¿Cuántos consumidores cayeron en esos estados?".

No lo sabíamos. Ellos tampoco lo sabían. Eso es lo que pasa con los estados muertos en los sistemas distribuidos: si nadie los vigila, son invisibles. Los consumidores afectados quizá llamaron a atención al cliente, los marearon de un lado a otro y acabaron rindiéndose. O quizá siguen pagando cargos que nunca hicieron.

Así es como se ve el fallo de la Apple Card desde dentro. No una explosión dramática. Una acumulación lenta y silenciosa de daño que nadie puede ver hasta que un regulador fuerza la apertura de la caja negra.

Cómo serán los próximos cinco años

La acción del CFPB contra Apple y Goldman Sachs no es un hecho aislado. Es el comienzo de un ajuste de cuentas regulatorio con la forma en que las empresas tecnológicas gestionan la infraestructura financiera. A medida que la banca se vuelve más embebida —en los teléfonos, en las apps, en plataformas que originalmente no se diseñaron como servicios financieros—, la brecha entre "funciona la mayor parte del tiempo" y "se demuestra que funciona todo el tiempo" se convierte en una responsabilidad medida en cientos de millones de dólares.

Pienso en la objeción que oigo más a menudo: "¿No es la verificación formal una exageración para la mayoría de los sistemas financieros?". Y mi respuesta se ha vuelto más simple con el tiempo. La Apple Card es uno de los productos financieros de consumo más visibles del mundo, construido por dos empresas con recursos de ingeniería prácticamente ilimitados. Si ellos no pudieron detectar un estado muerto en un flujo de disputas mediante pruebas y monitorización tradicionales, ¿qué te hace pensar que tu sistema es diferente?

El sector avanza hacia lo que yo llamo Cumplimiento Absoluto: no el cumplimiento como ejercicio de marcar casillas, sino el cumplimiento como propiedad arquitectónica. Un sistema en el que la adhesión a la ley no es algo que verificas después de los hechos, sino algo que demuestras antes del despliegue. Donde la brecha entre la interfaz y la normativa se salva no con la vigilancia humana, sino con la certeza matemática.

La era del "lanza rápido y arregla después" es incompatible con los requisitos de "mueve dinero y protege a las personas" de las finanzas globales. La Apple Card lo demostró. La pregunta es si el sector aprende la lección antes o después de la próxima multa de 89 millones de dólares.

Estamos construyendo ese futuro en Veriprajna. No porque sea fácil —la verificación formal de sistemas financieros distribuidos es genuinamente difícil, y quien te diga lo contrario te está vendiendo algo—, sino porque la alternativa es lo que vimos en octubre de 2024: dos de las empresas más poderosas del mundo, un botón roto y decenas de miles de personas a las que dejaron con la factura de cargos que nunca hicieron.

Eso no es un problema de tecnología. Es un problema de ética de la ingeniería. Y la solución no es una mejor monitorización ni parches más rápidos. Es construir sistemas que sean correctos por construcción: sistemas donde las matemáticas garanticen que la disputa de ningún consumidor desaparecerá jamás en el vacío.

La multa de 89 millones de dólares ya está pagada. El coste real es la confianza que se rompió. Reconstruirla requiere más que promesas. Requiere demostración.