Klarna sustituyó a 700 personas por IA. Luego las volvió a contratar. Esto es lo que toda empresa debería aprender.

Estaba en una llamada con un posible cliente del sector bancario cuando estalló la noticia de Klarna. Mediados de 2025. Mi teléfono vibró: un colega me había reenviado el artículo con una sola línea: "Esto es literalmente lo que llevas diciendo".

El cliente estaba a media frase, explicándome cómo habían construido un chatbot de atención al cliente sobre GPT-4 y que "funcionaba de maravilla". Le pregunté qué aspecto tenían sus puntuaciones de CSAT. Larga pausa. "Todavía no lo medimos".

Esa pausa me lo dijo todo. Porque Klarna sí lo había medido. Y lo que descubrieron fue lo bastante devastador como para revertir una de las implantaciones de IA más publicitadas de la historia del fintech.

Esta es la versión corta: Klarna, el gigante sueco del "compra ahora, paga después" valorado en 14.600 millones de dólares, sustituyó a unos 700 agentes de atención al cliente por un asistente de IA construido sobre OpenAI. Lo anunciaron como una vuelta de honor: la IA gestionaba el 75% de todos los chats con clientes en 35 idiomas. El coste por transacción bajó un 40%. A Wall Street le encantó. Después, las puntuaciones de satisfacción del cliente cayeron un 22%. La compañía registró unas pérdidas netas de 99 millones de dólares en el primer trimestre de 2025. Y el CEO, Sebastian Siemiatkowski, admitió públicamente que la búsqueda de la eficiencia había destrozado la calidad del servicio, generando respuestas que él mismo calificó de "genéricas" e incapaces de resolver nada que exigiera un juicio real.

Empezaron a recontratar. Incluso reasignaron a ingenieros de software y a gente de marketing para atender los teléfonos.

Llevo años construyendo sistemas de IA neuro-simbólica en Veriprajna y he visto a una empresa tras otra caer en esta misma trampa. No porque la tecnología sea mala: los grandes modelos de lenguaje son genuinamente extraordinarios. Sino porque existe una confusión fundamental entre parecer correcto y ser correcto, y en los sectores regulados esa confusión acabará costándote todo.

La noche en que me di cuenta de que lo "suficientemente bueno" no lo es

Antes de entrar en la arquitectura, quiero contarte un momento que cambió mi forma de pensar sobre este problema.

Estábamos ejecutando un piloto de un sistema de cumplimiento normativo legal: no atención al cliente, sino análisis documental. Ese tipo de trabajo en el que analizas presentaciones regulatorias y cotejas políticas internas con mandatos externos. Teníamos un prototipo que usaba una configuración estándar de retrieval-augmented generation. Búsqueda vectorial, recuperación top-k, GPT generando el resumen. Era rápido. Los resultados se leían de maravilla.

Una de nuestras ingenieras, Priya, se quedó hasta tarde probando casos límite. Sobre las 11 de la noche escribió en nuestro canal de Slack con una captura de pantalla. El sistema había generado un párrafo perfectamente fluido que citaba una cláusula normativa concreta. La cláusula no existía. No era una cita mal transcrita ni una paráfrasis: era una fabricación completa. Y se leía de forma tan convincente que, si no eras experto en esa normativa concreta, jamás lo habrías detectado.

Recuerdo estar sentado en mi escritorio mirando fijamente esa captura y pensando: este es el producto que estamos a punto de lanzar. Un sistema que miente con el aplomo de un socio sénior de un bufete de abogados.

Cancelamos el piloto. Reconstruimos la arquitectura desde cero. Perdimos tres meses. Fue la mejor decisión que hemos tomado nunca.

Cuando un sistema de IA fabrica una cita legal con absoluta seguridad, el problema no es un fallo puntual: es la arquitectura. No puedes salir a base de ingeniería de prompts de unos cimientos fundamentalmente probabilísticos.

¿Qué es la "trampa del wrapper" y por qué sigue atrapando a empresas inteligentes?

Déjame explicar lo que realmente le pasó a Klarna en términos técnicos, porque la prensa económica lo interpretó mal en su mayor parte. Lo enmarcaron como "la IA todavía no está lista". Ese no es el problema. El problema es qué tipo de IA y cómo se implementó.

Un "wrapper" es una fina capa de software que se sitúa sobre un gran modelo de lenguaje de terceros. Se encarga del formato, gestiona las llamadas a la API, quizá añade algo de parseo de salida estructurada. Pero el pensamiento real —el razonamiento, el juicio, la toma de decisiones— está completamente externalizado al LLM. Tu wrapper envía un prompt, el modelo predice los tokens siguientes más probables y recibes de vuelta algo que suena como una respuesta.

Esto funciona de maravilla para una demo. Funciona de forma aceptable para tareas de bajo riesgo. Y fracasa catastróficamente en cualquier cosa que exija certeza.

La arquitectura Transformer que impulsa estos modelos utiliza un mecanismo de autoatención para ponderar la relevancia de los tokens de una secuencia y predecir qué viene a continuación. Eso es reconocimiento de patrones: reconocimiento de patrones extraordinariamente sofisticado, pero reconocimiento de patrones al fin y al cabo. No existe ningún mecanismo interno para verificar hechos contra una fuente de verdad externa. El modelo no sabe las cosas. Predice cómo una respuesta bien informada se vería.

La IA de Klarna podía restablecer contraseñas sin un solo fallo. ¿Pero cuando un cliente tenía una disputa compleja que implicaba un reembolso parcial, un desacuerdo con un comercio y normativas de protección al consumidor de dos jurisdicciones distintas? El modelo recurría por defecto a lo que yo llamo slop-spinning: generar respuestas de apariencia plausible que daban vueltas en círculo, sin resolver nunca nada, frustrando a los clientes hasta llevarlos a lo que un analista describió como un "bucle kafkiano".

Y esta es la parte que debería aterrorizar a cualquier directivo empresarial: las métricas de coste se veían estupendas durante todo el tiempo en que la experiencia se deterioraba. El coste por transacción bajó de $0.32 a $0.19. El tiempo de resolución de un chat pasó de 11 minutos a menos de 2. Si solo mirabas el panel de control, pensarías que estabas ganando, justo hasta el momento en que tus clientes empezaron a marcharse.

¿Por qué no basta con añadir mejores guardrails a un LLM?

Esta es la pregunta que más me hacen, y revela el malentendido de fondo. La gente cree que la solución son mejores prompts, más ejemplos few-shot, instrucciones de sistema más estrictas. "Basta con decirle al modelo que no alucine".

Eso es como decirle a un modelo de predicción meteorológica que no se equivoque. La naturaleza probabilística no es un defecto que haya que parchear: es el mecanismo fundamental del funcionamiento del sistema.

Una vez un inversor me lo dijo sin rodeos: "Usa GPT y añade algunas reglas encima". Le pregunté si confiaría en una calculadora que acertara el 95% de las veces. Se rió. Le dije: "Eso es lo que estás proponiendo para el cumplimiento normativo bancario". Dejó de reírse.

Los modos de fallo técnicos van más allá de la alucinación. Los wrappers carecen de lo que yo llamaría persistencia del esquema de estado. A medida que avanza una conversación, la ventana de contexto se llena. La información de las primeras fases de la conversación se comprime o se descarta. El modelo puede contradecirse dentro de una misma sesión sin ser consciente de haberlo hecho. En atención al cliente, esto significa que el agente puede verificar tu identidad en el turno 3 y volver a pedirte que te verifiques en el turno 15 o, peor aún, saltarse la verificación por completo porque el flujo de la conversación lo "convenció" de que la verificación ya se había producido.

Esta es la vulnerabilidad que yo llamo la Falacia de la Libertad Infinita. Como el LLM no tiene restricciones estructurales duras sobre lo que puede decir o hacer, un usuario lo bastante astuto —o una situación lo bastante compleja— puede empujarlo a estados que violan reglas de negocio, requisitos regulatorios o la lógica más básica. Esto no se resuelve con prompting. Necesitas un tipo de arquitectura completamente distinto.

Escribí sobre este problema en profundidad en la versión interactiva de nuestra investigación, pero la idea central es sencilla: hay que separar la voz del cerebro.

El 20% que lo rompe todo

Hay un patrón que he visto en todos los sectores en los que trabajamos y creo que explica por qué tantas implantaciones de IA siguen la trayectoria de Klarna.

En 2025, la IA puede gestionar con competencia alrededor del 80% de las interacciones rutinarias y de alta frecuencia. Restablecimientos de contraseña, consultas del estado de un pedido, respuestas básicas de preguntas frecuentes: son problemas resueltos. El 20% restante de las interacciones son las que de verdad importan. Son las disputas complejas, los casos límite, los momentos en los que un cliente está frustrado, confundido o asustado. Y son los principales motores de la reputación de marca y de la responsabilidad financiera.

Klarna optimizó para el 80% e ignoró el 20%. Las cuentas parecían obvias: automatiza lo fácil, ahorra millones. Pero el 20% es donde la confianza se construye o se destruye. Un cliente que restablece su contraseña sin fricción no se lo cuenta a nadie. Un cliente que pasa 45 minutos atrapado en un bucle de IA intentando resolver un error de facturación se lo cuenta a todo el mundo.

El 80% de las interacciones que la IA gestiona bien son invisibles para tu marca. El 20% que gestiona mal son las únicas que alguien recuerda.

La ironía es que los 10 millones de dólares iniciales que Klarna ahorró por la reducción de plantilla quedaron casi con toda seguridad empequeñecidos por el valor de vida del cliente que destruyó con experiencias degradadas. Cuando eres una empresa de 14.600 millones de dólares que se prepara para una salida a bolsa, una caída del 22% en la satisfacción del cliente no es un problema de métricas: es un problema existencial.

¿Qué significa realmente "IA determinista"?

Así que, si los wrappers son el problema, ¿cuál es la solución? Aquí es donde tengo que ponerme un poco técnico, pero prometo mantener los pies en el suelo.

En Veriprajna construimos lo que se conoce como IA neuro-simbólica. El nombre suena académico, pero el concepto es intuitivo: tomas la fluidez lingüística de una red neuronal y la restringes dentro de la lógica rígida de un motor de razonamiento simbólico. La red neuronal se encarga del trabajo "blando": entender el lenguaje natural, generar respuestas legibles para las personas, interpretar consultas ambiguas. El motor simbólico se encarga del trabajo "duro": hacer cumplir las reglas, validar la lógica, garantizar que cada salida sea trazable hasta una fuente verificada.

A esto lo llamamos el Sándwich Neuro-Simbólico. Antes de que una consulta llegue al LLM, una capa de validación de intención la contrasta con las restricciones de política y filtra entradas adversarias. Después de que el LLM genera una respuesta, un motor de validación —normalmente una Máquina de Estados Finitos o un solucionador lógico— comprueba cada afirmación contra el grafo de conocimiento y cada acción contra las reglas de negocio. Si la respuesta viola alguna restricción, no pasa. Punto.

Hay una técnica que utilizamos llamada decodificación restringida —también conocida como enmascaramiento de tokens— que me parece especialmente elegante. En lugar de dejar que el modelo genere libremente y comprobar después la salida, impedimos físicamente que ciertos tokens se generen siquiera. Si el modelo está produciendo un informe de cumplimiento fiscal, la capa simbólica garantiza que cada número se corresponda con un cálculo verificado. El modelo literalmente no puede alucinar un número, porque los tokens alucinados quedan enmascarados fuera de la distribución de probabilidad antes de que se produzca la generación.

Esto no es "añadir guardrails". Es una arquitectura fundamentalmente distinta en la que el LLM es la voz y el motor simbólico es el cerebro, y a la voz nunca se le permite hablar sin la aprobación del cerebro.

Cuando el grafo de conocimiento nos salvó de un error de 2 millones de dólares

El RAG estándar —retrieval-augmented generation— tiene un problema del que casi nadie habla. Depende de la similitud vectorial para encontrar documentos relevantes. Pero la similitud vectorial no entiende la direccionalidad. "La empresa A demandó a la empresa B" y "La empresa B demandó a la empresa A" pueden tener embeddings vectoriales casi idénticos, pero describen situaciones legales completamente opuestas.

Lo descubrimos por las malas durante un piloto legal. Nuestro sistema analizaba el historial de litigios de un cliente corporativo y la configuración estándar de RAG confundía una y otra vez los papeles de demandante y demandado. Los resultados eran fluidos, bien estructurados y peligrosamente erróneos.

Fue entonces cuando pasamos a lo que llamamos GraphRAG con citas obligatorias (Citation-Enforced GraphRAG). En lugar de volcar documentos en un almacén vectorial, los parseamos en un grafo de conocimiento: entidades conectadas por relaciones tipadas y direccionales. Cuando el sistema hace una afirmación, debe rastrearla hasta nodos y aristas concretos del grafo. Si el grafo no puede sustentar la afirmación, el sistema no la hace.

La mejora de precisión fue drástica: un 30-35% superior al RAG estándar en tareas complejas de razonamiento multisalto. Pero, lo que es más importante, nos dio algo que ninguna cantidad de ingeniería de prompts podría dar: un rastro de auditoría. Cada salida puede rastrearse a través de la ruta de razonamiento exacta, de entidad a entidad, de relación a relación. Un responsable de cumplimiento puede ver por qué el sistema llegó a una conclusión, no solo qué concluyó.

Para el desglose técnico completo de cómo funciona esta arquitectura en distintos dominios —banca, legal, manufactura—, consulta nuestro análisis técnico en profundidad.

La discusión que estuvo a punto de dividir a mi equipo

Quiero ser honesto sobre algo. Construir así es más difícil. Bastante más difícil. Y hubo un momento, hace quizá dieciocho meses, en el que mi equipo tuvo una discusión de verdad sobre si estábamos incurriendo en sobreingeniería.

Estábamos en una sala de reuniones —las pizarras cubiertas de diagramas de arquitectura— y uno de nuestros ingenieros sénior defendió que deberíamos lanzar un MVP basado en un wrapper para un cliente de manufactura. "Metamos ingresos, demostremos el concepto y endurezcamos la arquitectura más adelante". Era un argumento razonable. El cliente tenía prisa. El calendario era ajustado. Y todos los competidores de nuestro sector estaban lanzando productos wrapper y cerrando contratos.

Recuerdo el silencio cuando terminó. Entonces Priya —la misma ingeniera que había detectado la cita fantasma— sacó una diapositiva que llevaba tiempo guardándose. Mostraba tres casos reales del trimestre anterior en los que sistemas de IA basados en wrappers habían generado resultados que, de haberse ejecutado, habrían violado requisitos regulatorios. No violaciones hipotéticas. Reales, detectadas únicamente porque había humanos en el circuito.

Tomé la decisión de mantener el rumbo. Perdimos ese contrato frente a un competidor que lanzó más rápido. Seis meses después, el sistema de ese competidor produjo un incumplimiento normativo que le costó a su cliente una remediación de siete cifras. El cliente vino a nosotros.

La velocidad sin corrección no es una ventaja competitiva. Es un pasivo con la mecha retardada.

No cuento esta historia para parecer visionario. La cuento porque la presión por lanzar rápido e iterar después es enorme y, en la mayoría de los contextos de software, es el instinto correcto. Pero en los sectores regulados —banca, sanidad, legal, manufactura— "iterar después" significa "arreglarlo después de la infracción". Y las infracciones en estos dominios no vienen con un periodo de gracia.

Por qué 2026 es el año en que llega la factura

Este es el panorama macro. McKinsey descubrió que, aunque el 88% de las organizaciones usa IA, solo el 39% puede señalar un impacto positivo en los beneficios a nivel corporativo. Esa brecha está a punto de volverse insostenible.

La fase de "invertir y aprender" de la adopción de la IA ha terminado. Los directores financieros ya no preguntan "¿Estamos usando IA?". Preguntan "¿Cuál es el impacto en el EBIT?". Y para la mayoría de las organizaciones, la respuesta honesta es: "Hemos ahorrado algo de tiempo en tareas administrativas".

Eso no basta. Ahorrar tiempo en correos y presentaciones es "IA de productividad": útil, pero incremental. Lo que las empresas necesitan de verdad es "IA operativa": sistemas que eliminen fricción de dinero contante y sonante en la economía física. Evitar roturas de stock. Detectar incumplimientos normativos antes de que ocurran. Reducir los 890.000 millones de dólares que cuestan al año las devoluciones en el comercio minorista mediante pruebas virtuales precisas, en lugar de imágenes de fantasía generadas por IA que quedan preciosas pero no reflejan cómo cae realmente la tela sobre un cuerpo humano.

La historia de Klarna es instructiva aquí porque sus métricas parecían ROI. ¡El coste por transacción bajó un 40%! Pero estaban midiendo lo que no debían. Midieron el tiempo ahorrado y la plantilla reducida. No midieron la confianza erosionada ni los clientes perdidos. Cuando incluyes los costes de recontratación, el daño de marca y las pérdidas de 99 millones de dólares del primer trimestre, los "ahorros" se evaporan.

Las empresas que ganarán en 2026 son las que miden las pérdidas operativas evitadas, no las horas ahorradas. Las que despliegan una IA capaz de simular de la noche a la mañana 10.000 escenarios de disrupción en la cadena de suministro y construir manuales de recuperación ante crisis que ningún equipo humano podría producir en una década. Aquellas cuyos sistemas de IA pueden demostrar su razonamiento ante un regulador, no solo producir un párrafo convincente.

¿Y qué pasa con las personas?

La gente siempre objeta a este planteamiento: "Si la IA llega a ser tan buena, ¿qué pasa con las personas?".

Creo que la respuesta es lo contrario de lo que la mayoría espera. Las organizaciones que despliegan una IA profunda y arquitectónicamente sólida no necesitan menos personas: necesitan otras personas. La pirámide tradicional de la consultoría, con su enorme base de analistas júnior dedicados a sintetizar datos y montar presentaciones, se está desmoronando. La IA hace ese trabajo más rápido y mejor. Pero la necesidad de juicio sénior, pensamiento estratégico, supervisión ética y empatía humana genuina no solo sobrevive: se intensifica.

Lo que está emergiendo es lo que el sector llama el modelo "Obelisco": equipos más ligeros y con mayor peso experto, en los que los profesionales de carrera temprana son "facilitadores de IA" que diseñan y gestionan flujos de trabajo de IA, los profesionales de carrera intermedia son "arquitectos de encargo" que definen qué problemas merece la pena resolver, y los líderes sénior se centran en el trabajo profundamente humano de construir confianza y navegar la ambigüedad.

El asistente de IA interno de McKinsey, "Lilli", lo usa el 72% de su plantilla y ha recortado el tiempo de investigación un 30%. El "Deckster" de BCG automatiza la creación de presentaciones. Pero ninguna de las dos firmas está encogiendo. Se están reestructurando: sustituyen volumen por precisión, horas facturadas por resultados entregados.

El error de Klarna no fue usar IA. Fue usar la IA como sustituto de las personas en lugar de como amplificador de la capacidad humana. Esa distinción suena sutil. No lo es. Es la diferencia entre un ahorro de 10 millones de dólares y una pérdida de 99 millones.

La arquitectura de la confianza

Quiero cerrar con algo que me ronda la cabeza desde aquella noche en la que Priya encontró la cita fantasma.

Estamos viviendo un momento en el que los sistemas de IA pueden producir resultados indistinguibles del trabajo de un experto humano y, aun así, estar completa y confiadamente equivocados. Esto no es una limitación temporal que vaya a resolver GPT-6 o GPT-7. Es una propiedad inherente al funcionamiento de los modelos de lenguaje probabilísticos. Optimizan para la plausibilidad, no para la verdad. Y en los dominios donde la verdad importa —donde una respuesta equivocada significa un incumplimiento normativo, un diagnóstico erróneo, un precedente legal fabricado—, la plausibilidad es lo más peligroso del mundo.

La solución no es abandonar la IA. La solución es construir sistemas de IA en los que la verdad esté impuesta por la arquitectura, no esperada probabilísticamente. Donde cada afirmación se remonte a una fuente verificada. Donde el sistema literalmente no pueda generar una salida que viole las reglas del dominio en el que opera. Donde el rastro de auditoría no sea una funcionalidad: sea el cimiento.

Esto es lo que construimos en Veriprajna. No porque la IA determinista sea más fácil: es bastante más difícil. No porque quede mejor en una demo: los wrappers dan demos preciosas. Sino porque en sectores que no pueden permitirse adivinar, la única arquitectura sostenible es la que hace imposible adivinar.

Klarna aprendió esta lección al precio de 700 puestos de trabajo, una caída del 22% en el CSAT y unas pérdidas trimestrales de 99 millones de dólares. La pregunta para cualquier directivo que lea esto es sencilla: ¿quieres aprenderla de su historia o de la tuya?

El futuro de la IA empresarial no consiste en hacer más inteligentes a los modelos de lenguaje. Consiste en hacerlos responsables: arquitectónicamente, demostrablemente, inmutablemente responsables.

La era del wrapper ha terminado. Lo que viene será más difícil de construir, más lento de lanzar y merecerá cada mes extra de ingeniería. Porque, al final, el único sistema de IA que merece la pena desplegar es aquel por el que apostarías tu empresa. Y nunca deberías apostar tu empresa a un sistema que no puede mostrar su trabajo.