Cómo auditar la decisión de un modelo de IA

Un auditor pidió el porqué de una decisión que tomó un modelo de IA que la empresa había comprado, no construido. La respuesta que recibió fue un porcentaje de confianza. Un porcentaje no es una razón: es la medida de qué tan seguro estaba el modelo de poder equivocarse igual.

Carlos Andrés Ramírez · 2026-09-02

Casi todo lo que se ha escrito sobre auditar decisiones de IA está pensado para quien construyó el modelo. Explica cómo leer la importancia de cada variable, cómo redactar una ficha técnica del modelo, cómo guardar el registro de entrenamiento. Es información real y útil, y sirve para una minoría de empresas: las que tienen un equipo propio operando un modelo propio. La mayoría no está ahí. Compra una plataforma con una interfaz encima y un contrato debajo, y el modelo que decide vive en la infraestructura de otro.

Ese hueco no es un detalle técnico. Es la diferencia entre poder responder a un auditor y no poder. Cuando el modelo es tuyo, puedes bajar hasta el dato, la versión y el criterio. Cuando lo compraste, lo único que tienes es lo que el proveedor decidió entregarte en el contrato, y casi ningún contrato de compra de IA que he revisado menciona la palabra auditoría.

El síntoma

¿Cómo se audita una decisión que tomó un modelo de IA?

La respuesta que circula hoy viene del lado de quien construye modelos: explicabilidad técnica, importancia de variables, fichas de modelo. Ninguna de esas herramientas fue pensada para responder lo que pregunta un auditor, un regulador o un abogado, que no quiere saber cómo piensa el modelo en general. Quiere reconstruir una decisión concreta, tomada un día concreto, sobre una persona o un caso concreto, y saber si alguien pudo haberla revisado antes de que produjera efecto.

El panel del proveedor muestra la precisión general del modelo, no el motivo de un caso individual.
El registro de cada decisión vive dentro de la plataforma del proveedor, con una retención de semanas, no de años.
Nadie en la empresa puede decir qué versión del modelo tomó la decisión de hace seis meses, porque el proveedor lo actualiza sin avisar.
El contrato de compra obliga al proveedor a entregar el resultado, nunca el razonamiento detrás de un caso puntual.
Cuando llega una reclamación o una auditoría, la única respuesta disponible es que el sistema lo decidió así, y esa frase no convence a ningún regulador.

El problema detrás

La trazabilidad que pide un auditor no es la que ofrece un proveedor de IA.

Un proveedor de IA se mide a sí mismo en conjunto: precisión del modelo, tasa de error, tiempo de respuesta. Son números que prueban que el sistema funciona como un todo, y no dicen nada sobre un caso puntual. Un auditor no pregunta si el modelo acierta casi siempre. Pregunta por qué acertó o falló en este caso, con esta persona, en esta fecha, y si alguien tuvo la oportunidad de corregirlo antes de que el efecto fuera irreversible.

Y aquí está la parte que ninguna demo de proveedor menciona: cuando compras la IA en vez de construirla, la trazabilidad no es tuya. Es del contrato que firmaste, y si ese contrato no la exige por escrito, no existe. No hay ingeniero interno que la reconstruya después, porque los datos del caso ni siquiera están en tu infraestructura. Están en la del proveedor, y el proveedor decide cuánto guarda y durante cuánto tiempo.

Auditar una decisión de IA no es explicar cómo piensa el modelo en general. Es poder reconstruir, caso por caso, qué información tuvo, qué decidió y quién pudo haberla corregido.
BECOME

El marco

¿Qué tiene que existir para poder auditar una decisión de IA, la compres o la construyas?

Las cinco piezas siguientes se negocian antes de firmar con un proveedor, no después de un incidente. Pedidas después, ningún proveedor las entrega gratis, y alguna, la versión exacta del modelo que decidió un caso pasado, ya no se puede reconstruir si no se guardó desde el primer día.

Registro de caso: El dato exacto que entró, la decisión exacta que salió y la marca de tiempo, para cada caso individual. No la métrica agregada del modelo: el expediente de esa decisión en concreto.
Versión: Qué versión exacta del modelo tomó esa decisión. Un proveedor que actualiza el modelo sin versionarlo hace imposible reproducir, seis meses después, qué razonamiento produjo un resultado concreto.
Punto de intervención: El momento del proceso en el que una persona pudo revisar o revertir la decisión antes de que produjera efecto, y si en ese caso lo hizo o dejó pasar el resultado del modelo sin mirarlo.
Cláusula de exportación: La obligación contractual, firmada antes de comprar, de entregar el registro de cualquier caso cuando la empresa lo pida, no solo cuando el proveedor decida compartirlo o cuando el contrato termine.
Dueño interno: Una persona con nombre, no un equipo genérico de tecnología, responsable de poder reconstruir cualquier decisión pasada cuando la pida un auditor, un regulador o un cliente que reclama.

Ninguna de las cinco exige construir el modelo en casa. Exige negociarlas antes de firmar, con el mismo rigor con el que se negocia una cláusula de nivel de servicio o una de propiedad del dato. La empresa que compra IA sin esas cinco no está ahorrando el coste de construir. Está aplazando el coste de no poder explicar, el día que alguien pregunte, por qué el sistema decidió lo que decidió.

Coge la última decisión importante que tomó una IA comprada a un proveedor, un rechazo de crédito, un descarte de candidato, una alerta de fraude, y pide el registro completo de ese caso puntual. Si lo único que existe es un porcentaje de confianza, no hay trazabilidad. Hay una caja negra con el logo de otra empresa.

Preguntas frecuentes

¿Cómo se audita una decisión que tomó un modelo de IA?

Reconstruyendo el caso concreto, no explicando el modelo en general: qué dato entró, qué versión del modelo lo procesó, qué salió y si una persona tuvo la oportunidad de revisar o revertir el resultado antes de que produjera efecto. Sin esas cuatro piezas guardadas desde el momento en que ocurrió el caso, la auditoría no se puede hacer después, por bien documentado que esté el modelo en general.

¿Se puede auditar una decisión de un modelo de IA que la empresa compró y no construyó?

Solo si el contrato con el proveedor lo obligó por escrito antes de firmarlo. La trazabilidad de un modelo comprado depende de lo que el proveedor decida guardar y entregar, y la mayoría de contratos de compra de IA no mencionan la palabra auditoría. Negociar esa cláusula después de un incidente ya es tarde: los datos del caso que hace falta reconstruir puede que el proveedor nunca los haya guardado.

¿Qué diferencia hay entre explicabilidad técnica y trazabilidad de una decisión?

La explicabilidad técnica dice cómo funciona el modelo en general: qué variables pesan más, con qué precisión acierta en conjunto. La trazabilidad de una decisión reconstruye un caso puntual: qué información tuvo el sistema ese día concreto, qué decidió y quién pudo haberlo corregido. Un modelo puede tener una ficha técnica impecable y ningún caso individual reconstruible, y eso es justo lo que un auditor detecta primero.

¿Quién debería poder reconstruir una decisión de IA cuando lo pide un auditor?

Una persona con nombre y responsabilidad asignada, no un equipo genérico de tecnología ni el propio proveedor sin supervisión. Si nadie en la empresa puede decir, sin llamar al proveedor y esperar días, qué pasó en un caso concreto, la empresa no tiene trazabilidad interna: depende por completo de la buena voluntad de otro para responder ante un regulador.

Diseñemos tu trazabilidad de decisiones

De la idea a la operación

Escalar con control exige decidir antes los límites, la supervisión y la trazabilidad. Añadirlos después es reconstruir.

Sobre el autor

Carlos Andrés Ramírez — Director de Transformación

Especialista en transformación y reinvención de negocios. Director de Programas Especializados y docente de Inteligencia Artificial en la Escuela de Postgrado de la UPC.