Qué es la explicabilidad de un modelo de IA (XAI)

Un cliente reclama y nadie en la empresa puede decir por qué el modelo decidió eso

En una entidad financiera de tamaño mediano en Perú, el área de riesgos rechazó el crédito de un cliente recurrente que llevaba tres años pagando a tiempo. El cliente reclamó. El área comercial escaló el caso. Y cuando pidieron una explicación al equipo de datos, la respuesta fue: el modelo lo calificó por debajo del umbral. Nadie pudo decir qué variable pesó más, si el sistema comparó bien la información o si simplemente arrastró un dato viejo. El comité de riesgos terminó aprobando el crédito a mano, sin saber si el modelo tenía razón o si acababan de pasar por encima de una alerta legítima.

Esto pasa todos los días en empresas que ya metieron IA en decisiones que afectan personas: aprobar o negar un crédito, priorizar o descartar un candidato, marcar una transacción como fraude, decidir qué reclamo se atiende primero. El modelo funciona, entrega un resultado, y en la mayoría de los casos ese resultado es razonable. El problema aparece el día que alguien pregunta por qué, y la empresa no tiene una respuesta que sostenga frente al cliente, frente a un auditor interno o frente a un regulador. Ahí es donde se nota que se compró precisión y no se compró control.

El error de fondo no es técnico, es de gestión: se evalúa un modelo por qué tan bien predice, y casi nunca por qué tan bien se puede explicar lo que predijo. Se contrata al proveedor que promete el mejor porcentaje de acierto y se asume que la explicación es un detalle que se resuelve después, si es que se resuelve. Cuando llega el reclamo, la auditoría o la exigencia regulatoria, ya es tarde para diseñar la explicabilidad: había que pedirla desde el contrato.

Qué es la explicabilidad, en criterio de negocio

La explicabilidad no es un informe técnico que solo entiende el equipo de datos. Es la capacidad de la empresa de reconstruir, en lenguaje que un cliente, un auditor o un regulador puedan seguir, por qué un modelo llegó a una decisión concreta. No es dar la fórmula completa del algoritmo. Es poder decir, con evidencia, qué pesó en esa decisión específica y por qué el resultado tiene sentido con la información disponible.

En la práctica, esto se traduce en algo muy concreto: cuando el cliente del ejemplo anterior reclama, la empresa debería poder mostrar, en minutos, qué variables influyeron en el rechazo, si esas variables eran correctas y estaban vigentes, y qué habría pasado si una de ellas hubiera sido distinta. Si esa reconstrucción toma semanas, depende del único ingeniero que entiende el modelo, o simplemente no existe, la empresa no tiene explicabilidad. Tiene un modelo que funciona mientras nadie pregunta.

Esta capacidad es una de las patas de lo que se conoce como IA responsable, junto con el control del sesgo algorítmico y la posibilidad real de someter el modelo a una auditoría de IA. Sin explicabilidad, las otras dos se quedan sin material de trabajo: no puedes auditar ni corregir un sesgo que no puedes ver.

La tensión real entre precisión y explicabilidad

Hay una tensión de diseño que casi ningún proveedor menciona en la demo: los modelos más complejos, los que suelen dar mejor precisión, son también los más difíciles de explicar. Una red neuronal con muchas capas puede detectar patrones que un modelo simple no ve, pero esos patrones viven en una combinación de pesos internos que no se traduce fácil a una frase como rechazado por ingresos insuficientes. Un modelo más simple, como un árbol de decisión o una regresión, es más fácil de leer, pero puede perder precisión frente a patrones complejos. Si quieres entender por qué estos modelos son tan difíciles de interpretar por dentro, ayuda repasar primero qué es una red neuronal.

El error es tratar esto como una ley fija: si quieres explicabilidad, resígnate a perder precisión. No siempre es así. Hay técnicas que generan explicaciones razonables sobre modelos complejos sin cambiar el modelo, y hay procesos de negocio que necesitan mucha menos precisión de la que el proveedor vende, pero sí necesitan mucha más explicación de la que el proveedor ofrece. La pregunta que debería hacer cualquier empresa antes de elegir modelo no es solo qué tan preciso es, es qué tanto necesito poder explicar esta decisión, y si este modelo me lo permite.

Dónde pesa más cada lado de la balanza

• Aprobación o rechazo de crédito: exige explicación variable por variable, porque afecta directamente el acceso de una persona a un servicio financiero.
• Selección o descarte de candidatos: exige poder mostrar qué criterios pesaron, porque un error no explicado se convierte en un riesgo de discriminación.
• Detección de fraude en transacciones: tolera más opacidad si hay un proceso humano de revisión antes de bloquear o reportar a alguien.
• Recomendación de contenido o producto: tolera bastante más opacidad, porque el impacto de una mala recomendación es bajo y reversible.
• Priorización interna de tickets o leads: puede vivir con explicaciones parciales si el resultado se puede corregir manualmente sin fricción.

Explicar el modelo completo no es lo mismo que explicar una decisión puntual

Aquí se mezclan dos preguntas distintas que casi nadie separa. Una es cómo funciona este modelo en general, que se responde con la lógica global: las variables que más peso tienen en promedio, el tipo de datos con los que se entrenó. Otra, muy distinta, es por qué este cliente, en este momento, con estos datos, recibió este resultado, que exige una explicación local, específica de ese caso puntual.

Un proveedor puede entregarte un documento bien armado sobre cómo funciona el modelo en general y seguir sin poder responder la pregunta que realmente te va a hacer un cliente o un regulador, que es sobre su caso concreto. Esa confusión es la que deja expuestas a las empresas: creen que tienen explicabilidad porque tienen un manual técnico, cuando lo que necesitan es la capacidad de reconstruir, caso por caso, la decisión puntual que alguien está cuestionando.

Lo mínimo que debe traer una explicación a nivel de decisión

• Qué variables pesaron más en ese caso específico, no en el promedio general del modelo.
• Con qué valores entró esa persona o esa transacción al sistema en el momento exacto de la decisión.
• Qué habría cambiado el resultado, es decir, el escenario alternativo más cercano a ese caso.
• Quién puede revisar y, si corresponde, revertir esa decisión aplicando criterio humano.
• En qué fecha y con qué versión del modelo se tomó la decisión, para poder rastrearla después.

El criterio que decide cuánta explicabilidad necesitas: el impacto sobre la persona

No todas las decisiones automatizadas merecen el mismo nivel de explicación. El criterio que uso para ordenar esto es simple de enunciar y difícil de aplicar con disciplina: cuanto mayor es el impacto de la decisión sobre una persona concreta, más exigible es la explicación. Un modelo que decide qué banner mostrar en una web puede equivocarse cien veces sin que nadie salga afectado de verdad. Un modelo que decide si alguien accede a un crédito, un trabajo, un tratamiento o un seguro, no tiene ese margen.

Esto no es una postura ética abstracta, es una forma de priorizar el trabajo de gobierno de IA cuando los recursos son limitados. Ninguna empresa mediana tiene tiempo ni presupuesto para hacer auditable cada modelo que usa. Sí puede, y debe, identificar cuáles tres o cuatro modelos tocan decisiones de alto impacto sobre personas y poner ahí el esfuerzo de explicabilidad, dejando los modelos de bajo impacto con un nivel de control más liviano.

Vale aclarar algo que se suele pasar por alto: varias de las normativas que regulan la IA en las empresas ya avanzan hacia exigir algún nivel de explicación para decisiones automatizadas de alto impacto sobre personas. Eso significa que este criterio de impacto no es solo una buena práctica interna, es cada vez más un piso que la empresa tendrá que sostener frente a un tercero, con o sin ganas.

Niveles de impacto que conviene distinguir

• Impacto alto: acceso a crédito, empleo, salud, seguros o cualquier servicio esencial para la persona.
• Impacto medio: decisiones que afectan la experiencia o el costo de un cliente, pero son reversibles sin gran daño.
• Impacto bajo: personalización de contenido, ordenamiento de resultados, decisiones puramente operativas internas.
• Impacto acumulado: decisiones individualmente pequeñas que, repetidas sobre el mismo grupo de personas, generan un patrón de riesgo.
• Impacto reputacional: decisiones que, aunque de bajo costo económico, generan un daño de imagen si se hacen públicas sin explicación.

Cuando el proveedor te dice que la caja negra es normal, no lo aceptes sin más

Hay una respuesta que se repite en reuniones con proveedores de IA cuando se les pregunta por qué el modelo decidió algo: así funcionan las redes neuronales, es una caja negra, es normal no saber exactamente por qué. Es cierto que hay modelos técnicamente difíciles de interpretar en su totalidad. No es cierto que eso libere a la empresa que los usa de la responsabilidad de poder explicar sus decisiones.

Que un modelo sea complejo por dentro no significa que no existan formas de generar una explicación razonable de sus resultados hacia afuera. Existen enfoques pensados justamente para eso: producir una explicación aproximada, verificable y suficiente para el nivel de riesgo de la decisión, sin necesidad de abrir cada parámetro del modelo. Cuando un proveedor usa la complejidad técnica como excusa para no dar ninguna explicación, lo que en realidad está diciendo es que no invirtió en esa capa, no que sea imposible construirla.

Esto también tiene relación directa con el sesgo algorítmico: si nadie puede explicar por qué el modelo decidió algo, tampoco nadie puede confirmar si ese algo estuvo influido por un sesgo que la empresa jamás detectó.

Preguntas que le harías a cualquier proveedor antes de firmar

• Pídele que reproduzca, delante tuyo, la explicación de una decisión real ya tomada por el modelo.
• Pregunta qué pasa cuando la explicación generada contradice lo que el área de negocio esperaba ver.
• Exige que la explicación quede documentada y asociada a esa decisión, no solo disponible si alguien la pide.
• Verifica si existe una ruta de revisión humana antes de que la decisión afecte a la persona, no después.
• Pregunta qué pasa con las decisiones tomadas antes de que existiera esta capacidad de explicación, y si son rastreables.

Mi criterio

Cuándo priorizar la explicabilidad ahora y cuándo puede esperar

No toda empresa necesita el mismo nivel de explicabilidad hoy mismo. Depende de qué tan expuesta está la decisión automatizada al escrutinio de un cliente, un auditor o un regulador, y de qué tan reversible es el daño si el modelo se equivoca.

Señales de que necesitas priorizar la explicabilidad ahora

• Tu modelo decide sobre crédito, empleo, salud, seguros o acceso a un servicio esencial.
• Ya recibiste un reclamo o una consulta de un cliente pidiendo justificación de una decisión automatizada.
• Operas en un sector con supervisión regulatoria activa sobre el uso de algoritmos.
• Nadie en la empresa, fuera del equipo técnico, puede explicar en una frase cómo decide el modelo.
• El modelo influye en decisiones que después revisa legal, cumplimiento o un auditor externo.

Señales de que puedes tolerar menos explicabilidad por ahora

• El modelo opera en decisiones internas de bajo impacto, reversibles sin costo real para nadie.
• Existe una persona que revisa y puede corregir cada decisión antes de que afecte a un cliente.
• El error del modelo cuesta tiempo o dinero interno, pero no afecta derechos ni el acceso de una persona.
• El volumen de decisiones es bajo y cada una se puede revisar manualmente sin esfuerzo extra.
• Estás en una etapa de piloto interno, sin impacto todavía sobre clientes reales ni sobre terceros.

El orden correcto: dolor, proceso, dato y recién ahí la herramienta

El orden que sostengo para cualquier proyecto de IA aplica igual acá. El punto de partida no es la herramienta de explicabilidad, es el dolor: una decisión automatizada que alguien no puede justificar cuando se lo piden. De ahí se pasa al proceso, definiendo quién necesita explicar qué decisión, a quién y en qué plazo, antes de tocar una sola línea de código. Después viene el dato: qué información entra al modelo, si esa información es correcta, está vigente y es defendible, porque una explicación construida sobre datos sucios no protege a nadie. Recién al final entra la herramienta, la que genera la explicación técnica, y su rol es soportar ese proceso, no reemplazarlo.

Las empresas que compran explicabilidad como si fuera un módulo que se instala terminan con un reporte que nadie lee y la misma vulnerabilidad de siempre: un modelo que funciona hasta que alguien pregunta por qué. La explicabilidad no es un lujo de gobierno corporativo para cuando la empresa crezca. Es la diferencia entre poder sostener una decisión automatizada frente a quien te la cuestione, o tener que revertirla a ciegas porque nadie sabe qué pasó adentro.