Lo esencial
- La explicabilidad es la capacidad de describir, en términos que una persona pueda comprender, por qué un sistema de IA ha producido un resultado determinado. No coincide con la interpretabilidad, que se refiere al funcionamiento interno del modelo.
- Con el Reglamento europeo de IA, la explicabilidad pasa de buena práctica a obligación jurídica: el artículo 13 exige a los sistemas de alto riesgo una transparencia suficiente, y el artículo 86 reconoce a las personas afectadas un derecho a una explicación desde el 2 de agosto de 2026.
- El marco de gestión de riesgos del NIST sitúa la IA explicable e interpretable entre sus siete características de una IA fiable, y la norma ISO/IEC 42001 espera que la explicabilidad se gestione y se documente.
- Un programa de gobernanza debe producir varios tipos de explicación, que cubran la justificación, la responsabilidad, los datos, la equidad, la seguridad y el impacto, y no un único dato técnico.
- La explicabilidad es auditable. El trabajo de fondo consiste en documentar qué explicaciones ofrece, a quién y cómo las asegura a lo largo de todo el ciclo de vida de la IA.
Qué significa la explicabilidad en la IA (y qué no es)
La explicabilidad designa la facultad de describir el comportamiento de un sistema de IA en un lenguaje accesible para una persona. La distinción más útil para orientarse reaparece una y otra vez en las páginas que dominan los resultados de búsqueda. Como lo expresa Splunk, la explicabilidad responde a la pregunta de por qué un modelo ha producido un resultado, mientras que la interpretabilidad responde a cómo funciona el modelo por dentro. Ambas nociones están relacionadas, se confunden a menudo, pero no son intercambiables. Una segunda distinción afina el cuadro. El Alan Turing Institute separa la transparencia, ser abierto sobre cómo y por qué se usa un sistema, de la explicabilidad, poder ofrecer razones claras y accesibles para un resultado concreto. La transparencia es una actitud. La explicabilidad es un entregable: un relato que un público definido puede utilizar de verdad. Conviene además separar las explicaciones globales de las locales. Una explicación global describe el comportamiento de un modelo en general, en todo su espacio de entrada. Una explicación local da cuenta de una decisión concreta, el préstamo denegado o la transacción marcada. Las preguntas de cumplimiento son casi siempre locales, porque la persona afectada quiere entender su caso, no el modelo en abstracto. Una plataforma de gobernanza de la IA debe sostener ambas perspectivas, sin confundirlas nunca.
Explicabilidad e interpretabilidad
Si de esta guía solo va a retener una distinción, que sea esta, porque la demanda de búsqueda al respecto no afloja y lo que está en juego a nivel regulatorio depende de ella. La interpretabilidad es una propiedad del modelo. Una regresión lineal o un árbol de decisión corto son interpretables porque una persona puede seguir el camino de la entrada a la salida leyendo el modelo mismo. La explicabilidad es más amplia. Es la aptitud de producir un relato comprensible de un resultado incluso cuando el modelo es una red profunda cuyos pesos internos nadie puede leer directamente. El marco de gestión de riesgos del NIST propone una formulación que los equipos de gobernanza pueden adoptar: la explicabilidad se refiere a los mecanismos que subyacen al funcionamiento de un sistema de IA, mientras que la interpretabilidad se refiere al significado de su resultado en el contexto de su finalidad prevista. En la práctica, la interpretabilidad suele tratarse como un subconjunto de la explicabilidad. Cabe disponer de un relato explicable de un modelo no interpretable, y es exactamente la situación de la mayoría de las empresas.
Por qué la explicabilidad se convierte en un requisito de cumplimiento
Durante años, la explicabilidad vivió en los artículos de investigación y en los manifiestos sobre IA responsable. Ahora vive en la ley y en normas certificables, lo que cambia quién debe ocuparse de ella y por qué. El marco del NIST nombra la IA explicable e interpretable como una de las siete características de una IA fiable, junto a válida y fiable, segura, protegida y resiliente, responsable y transparente, respetuosa de la privacidad, y equitativa con los sesgos dañinos bajo control. El NIST es voluntario, pero se ha convertido en el lenguaje común del riesgo de la IA, y la mayoría de los programas de empresa anclan en él sus controles. La ISO/IEC 42001, primera norma certificable de sistemas de gestión de la IA, convierte ese lenguaje en algo auditable. La organización que busca la certificación debe demostrar que la explicabilidad está gobernada: que se considera al elegir los modelos, que se producen explicaciones allí donde las partes interesadas las necesitan, y que existe la prueba que lo respalda. El NIST dice qué abordar; la ISO 42001 aporta un sistema de gestión para demostrar que lo ha abordado. Ambos se complementan, y muchos programas hacen funcionar el marco dentro de la norma. El giro decisivo es jurídico. El Reglamento de IA convierte un grado suficiente de explicación en una obligación vinculante para los sistemas de alto riesgo y ofrece a las personas una vía para reclamarla. Es un mundo distinto de una lista de buenas prácticas, y es la razón por la que la explicabilidad pertenece ahora a una hoja de ruta de cumplimiento y no solo al backlog de los científicos de datos.
Qué exige el Reglamento de IA, por rol y por nivel de riesgo
El Reglamento no impone una obligación uniforme. Asigna deberes distintos a los proveedores y a los responsables del despliegue, y los modula según el nivel de riesgo. Establecer bien esa correspondencia es la diferencia entre un programa defendible y un ejercicio de papeleo.
Proveedores de sistemas de alto riesgo (artículo 13)
La obligación central recae en quien introduce en el mercado un sistema de alto riesgo. El artículo 13, apartado 1 dispone que «los sistemas de IA de alto riesgo se diseñarán y desarrollarán de un modo que garantice que su funcionamiento sea lo suficientemente transparente para que los responsables del despliegue interpreten y usen adecuadamente sus resultados de salida». El verbo interpretar es deliberado: el responsable del despliegue debe poder dar sentido a lo que el sistema indica. Ese deber pasa sobre todo por las instrucciones de uso. El artículo 13 exige que sean concisas, completas, correctas y claras, y su apartado 3 enumera lo que deben contener, incluidas las características del sistema, su nivel de exactitud, sus limitaciones conocidas y sus capacidades técnicas para explicar su resultado de salida. La explicación no es, pues, un añadido; forma parte de la documentación que el proveedor entrega. También sostiene el artículo 14 sobre la supervisión humana, porque una persona no puede supervisar de verdad un sistema cuyo resultado no sabe interpretar.
Responsables del despliegue y derecho a una explicación (artículo 86)
El Reglamento alcanza también a la organización que usa el sistema. El artículo 86 prevé que toda persona afectada sujeta a una decisión adoptada por el responsable del despliegue sobre la base de los resultados de salida de un sistema de alto riesgo enumerado en el anexo III, cuando dicha decisión produzca efectos jurídicos o la afecte de manera análogamente significativa y adversa para su salud, su seguridad o sus derechos fundamentales, «tendrá derecho a obtener del responsable del despliegue explicaciones claras y significativas sobre el papel del sistema de IA en el procedimiento de toma de decisiones y sobre los principales elementos de la decisión adoptada». Es un derecho de las personas y un deber de los responsables del despliegue, y resulta aplicable el 2 de agosto de 2026. Un banco, una aseguradora o un empleador que opere un sistema de alto riesgo debe estar preparado para explicar una decisión desfavorable concreta a la persona que la sufre, en términos claros, cuando esta lo solicite. Es una explicación local, a petición, con un plazo.
La transparencia del artículo 50 no es explicabilidad
Merece la pena nombrar una trampa. El artículo 50 impone deberes de transparencia a ciertos sistemas de riesgo limitado, por ejemplo avisar a una persona de que está interactuando con un asistente conversacional o etiquetar los contenidos sintéticos. Son obligaciones de información, y no equivalen a explicar una decisión. Un sistema puede cumplir la información del artículo 50 y no deber nada con arreglo a los artículos 13 u 86, y a la inversa. Trate ambas cosas como líneas distintas de su programa de cumplimiento, para que un aviso nunca se confunda con una explicación.
Los seis tipos de explicación que un programa de gobernanza debería producir
La mayoría de los contenidos de la competencia se detienen en una única explicación técnica, un gráfico de importancia de variables, y dan la tarea por concluida. Un programa de gobernanza necesita más, porque públicos distintos necesitan relatos distintos de una misma decisión. El Alan Turing Institute traza seis tipos de explicación que, en conjunto, ofrecen un cuadro completo y que se corresponden bien con lo que las autoridades y las personas afectadas piden de verdad.
- Justificación: las razones de un resultado, expresadas en términos accesibles en lugar de a través de los engranajes del modelo.
- Responsabilidad: quién responde del sistema y cómo una persona puede impugnar una decisión o pedir su revisión.
- Datos: qué datos se usaron, de dónde proceden y cómo influyeron en el resultado.
- Equidad: las medidas adoptadas para garantizar una decisión no discriminatoria, lo que vincula directamente la explicabilidad con el control de los sesgos.
- Seguridad: la exactitud, la fiabilidad, la seguridad y la robustez que hay detrás del resultado.
- Impacto: los efectos de la decisión sobre la persona y sobre la sociedad.
La misma fuente ordena la disciplina en torno a cuatro máximas: ser transparente, ser responsable, considerar el contexto y reflexionar sobre los impactos. Son compromisos operativos más que lemas. Piden a un equipo adaptar cada explicación a su público, asignar una responsabilidad clara y sopesar las consecuencias de dar, o de negar, una explicación. Una autoridad que examina una decisión desfavorable rara vez se conforma con la justificación sola; querrá también los relatos de responsabilidad, datos y equidad.
Técnicas de explicabilidad y sus compromisos de gobernanza
Las explicaciones vienen de algún sitio, y el método elegido acarrea consecuencias de gobernanza. Existen dos grandes familias. La explicabilidad intrínseca nace del uso de un modelo interpretable por diseño, como un modelo lineal, un modelo aditivo generalizado o un árbol de decisión poco profundo. La explicación es el propio modelo. El compromiso está en que estos modelos pueden rendir menos en problemas complejos. La explicabilidad a posteriori se monta sobre un modelo opaco. Técnicas como SHAP y LIME aproximan qué variables impulsaron una predicción concreta. Las explicaciones contrafactuales describen el cambio más pequeño que habría alterado el resultado, a menudo el relato más intuitivo para una persona afectada, porque responde a la pregunta de qué habría tenido que ser distinto. Los modelos sustitutos y los métodos de importancia de variables ofrecen una visión global del comportamiento. El compromiso principal enfrenta el rendimiento predictivo con la facilidad de explicación. El reflejo de elegir el modelo más exacto y añadirle después un explicador es comprensible, pero las explicaciones a posteriori son aproximaciones y pueden inducir a error si se toman por la verdad. La decisión de gobernanza no es qué técnica es la mejor en abstracto, sino cuál ofrece al público que tiene delante, una autoridad, un auditor o una persona afectada, un relato fiable para esa decisión. Deje constancia del método, de sus límites y de la razón de su elección.
Convertir la explicabilidad en un control auditable
La distancia entre un principio de IA responsable y una auditoría superada es la documentación. La explicabilidad se convierte en un control cuando puede mostrar, para un sistema dado, qué explicaciones ofrece, a quién, con qué método y quién lo aprobó. El Alan Turing Institute acompaña su principio de explicabilidad con una plantilla de gestión del aseguramiento de la explicabilidad, una herramienta iterativa para planificar, aplicar y evidenciar las actividades de explicación a lo largo del ciclo de vida, de modo que la aclaración de los resultados a las partes afectadas quede registrada en lugar de improvisarse. La estructura importa más que la plantilla concreta. Un control viable tiene cuatro partes: un registro de qué tipos de explicación debe cada sistema y a qué públicos; la técnica empleada para producir cada uno; la prueba de que la explicación estaba realmente disponible cuando se necesitó; y un responsable nombrado que la revisa a medida que el modelo cambia. Aquí es donde la explicabilidad deja de ser un asunto de ciencia de datos y se convierte en un programa. Asignar cada sistema de alto riesgo a sus obligaciones con arreglo a los artículos 13 y 86, adjuntar los artefactos de explicación y mantener la prueba al día en cada reentrenamiento es exactamente el trabajo para el que está hecha una plataforma de gobernanza de la IA. Hecho una vez, a mano, es un proyecto. Hecho de forma continua, sobre toda una cartera, exige un sistema de referencia.
Preguntas frecuentes
¿Cuál es la diferencia entre explicabilidad e interpretabilidad? La interpretabilidad es una propiedad del modelo: un modelo simple, cuya lógica una persona puede leer directamente, es interpretable. La explicabilidad es la aptitud más amplia de dar un relato comprensible de un resultado, incluso para un modelo complejo que nadie puede leer directamente. Una fórmula extendida dice que la interpretabilidad responde a cómo funciona el modelo, mientras que la explicabilidad responde a por qué surgió un resultado concreto. En gobernanza, puede deber una explicación para un modelo que en sí no es interpretable, que es la situación de la mayoría de las empresas. ¿El derecho a una explicación del Reglamento de IA ya está en vigor? Aún no. El artículo 86, el derecho de las personas afectadas a obtener del responsable del despliegue explicaciones claras y significativas sobre una decisión de alto riesgo, resulta aplicable el 2 de agosto de 2026. Las obligaciones de transparencia del artículo 13 para los proveedores de sistemas de alto riesgo siguen el calendario previsto para esos requisitos. Las organizaciones que operan sistemas de alto riesgo deberían preparar ya la capacidad de explicación, en lugar de esperar a la fecha. ¿La explicabilidad se aplica a todo sistema de IA? No. Las obligaciones vinculantes del Reglamento se centran en los sistemas de alto riesgo. Los sistemas de riesgo limitado tienen deberes de información con arreglo al artículo 50, como declarar que un contenido está generado por IA, algo distinto de explicar una decisión. Los sistemas de riesgo mínimo no tienen ningún deber específico de explicabilidad con arreglo al Reglamento. Dicho esto, el NIST y la ISO 42001 tratan la explicabilidad como una característica general de una IA fiable, de modo que la mayoría de los programas maduros aplican una versión proporcionada a toda la cartera. ¿Qué cuenta como buena explicación para una autoridad? Un solo gráfico de importancia de variables rara vez basta. Una autoridad que examina una decisión desfavorable suele querer varios relatos juntos: la justificación del resultado, quién es responsable y cómo impugnarlo, qué datos se usaron, las medidas de equidad adoptadas y la base de seguridad del resultado. Adaptar la explicación al público y documentarla cuenta tanto como el método técnico subyacente. ¿Bastan SHAP o LIME para hablar de explicabilidad? Esas técnicas son útiles, pero son aproximaciones a posteriori de un modelo opaco, no la explicabilidad entera. Pueden inducir a error si se toman como verdad exacta, y responden a una pregunta técnica, no a las preguntas de gobernanza sobre responsabilidad, datos e impacto. Úselas como uno de los insumos, deje constancia de sus límites y combinelas con la documentación y la responsabilidad que hacen auditable la explicabilidad. ¿Qué relación hay entre explicabilidad y supervisión humana? Estrecha. El artículo 14 del Reglamento exige una supervisión humana efectiva de los sistemas de alto riesgo, y una persona no puede supervisar de verdad un sistema cuyo resultado no sabe interpretar. La explicabilidad es la condición previa de la supervisión: sin un relato comprensible de por qué el sistema produjo un resultado, el ser humano en el bucle aprueba resultados a ciegas.
Conclusión
La explicabilidad ha dado el paso del principio a la obligación. Ya no basta con decir que un modelo es exacto; con arreglo al Reglamento de IA, al NIST y a la ISO 42001, una organización debe poder decir por qué un sistema llegó a una decisión, en términos que el público adecuado pueda utilizar, y demostrarlo. Los equipos que abordan esto como un problema de documentación y de gobernanza, y no como un truco técnico puntual, estarán listos para el artículo 86 en 2026 y para las auditorías que vengan después. El primer paso concreto es modesto: enumere sus sistemas de alto riesgo, decida qué explicaciones debe cada uno y a quién, y empiece a conservar la prueba. Descubra cómo la plataforma AI Sigil convierte todo esto en un control repetible.