Hay una pregunta que casi ninguna empresa se hace antes de poner un modelo en producción, y que casi todas terminan haciéndose después, cuando ya es tarde: si este sistema toma una decisión que afecta a una persona real, ¿quién en la empresa puede explicar por qué la tomó?

No "¿funciona bien la mayoría de las veces?". Esa pregunta ya se la hicieron. La que falta es más incómoda: el día que un cliente, un empleado o un regulador pregunte "¿por qué a mí?", ¿hay alguien que pueda responder algo distinto a "así lo decidió el modelo"?

Tres formas de no tener respuesta

No guardar el rastro. El sistema decide, pero nadie registró con qué datos, qué versión del modelo o qué reglas estaban activas ese día. Seis meses después, cuando llega el reclamo, no hay forma de reconstruir qué pasó. No es que el modelo se equivocó: es que ya no se puede saber si se equivocó.

Guardar el rastro, pero no entenderlo. Esto es más común de lo que parece con modelos complejos: sí queda un registro de la predicción, pero el registro es una probabilidad y una lista de variables con pesos que no le dicen nada a la persona que tiene que responder por la decisión. Tener el dato no es lo mismo que poder explicarlo.

Entenderlo, pero no a tiempo. El equipo técnico sí puede reconstruir la decisión, con calma, en un análisis de una semana. El problema es que la pregunta llegó por escrito, con un plazo legal de respuesta de días, y la explicación por su naturaleza no puede producirse tan rápido porque nunca se diseñó para eso.

En el fondo, las tres terminan en el mismo lugar: una empresa que tomó una decisión automatizada y no puede sostenerla cuando se la cuestionan.

Por qué esto es más caro que el error mismo

Un modelo que se equivoca el cinco por ciento de las veces, si se sabe que se equivoca y hay un proceso para corregirlo, es un problema de ingeniería. Un modelo que se equivoca y nadie puede decir cuándo, con qué frecuencia, ni por qué, es un problema legal y reputacional que no se resuelve reentrenando el modelo. Se resuelve (o se evita) con decisiones de diseño que se toman antes de escribir la primera línea de código: qué variables puede usar el modelo, qué decisiones quedan fuera de su alcance por completo, y qué se registra cada vez que decide algo que le importa a una persona.

Esto no es exclusivo de modelos grandes o de lenguaje. Un sistema de puntaje simple que decide a qué clientes se les hace seguimiento prioritario tiene exactamente el mismo problema si nadie puede explicar por qué un cliente quedó afuera.

Qué significa esto en la práctica

No significa auditar el modelo una vez al año y archivar el informe. Significa, en la práctica, tres cosas concretas, hechas antes de que el sistema tome su primera decisión real. La primera es trazabilidad por diseño: cada decisión que el sistema tome sobre una persona queda registrada con lo que después va a hacer falta para explicarla, qué datos usó, qué versión estaba activa, cuál fue el resultado. La segunda son límites explícitos, documentados antes de lanzar el sistema: qué decisiones puede tomar solo y cuáles necesitan siempre una persona en el medio, no como buena intención sino como una regla que técnicamente no se puede saltar. Y la tercera, la que más se olvida, es tener un responsable con nombre y apellido (no "el equipo de datos"): alguien que, si llega la pregunta, sepa a quién le corresponde reconstruir la respuesta y en cuánto tiempo.

Nada de esto reemplaza evaluar si el modelo es preciso. Es la otra mitad del trabajo, la que casi nunca se hace porque no se ve en una demo y no mejora ninguna métrica de precisión. Se nota únicamente el día que alguien pregunta por qué, y ese es exactamente el peor momento para empezar a construirla.