La IA explicable, o XAI, reúne métodos para que las personas puedan entender por qué un sistema produjo un resultado y comprobar si la explicación representa de verdad su funcionamiento. En una pyme, eso se traduce en poder reconstruir qué datos entraron, qué respuesta salió, qué límites activan una revisión y quién tomó la decisión final. Una explicación clara no demuestra que la respuesta sea correcta: hay que contrastarla con la evidencia y el proceso real.
Una explicación útil tiene que ser comprensible y fiel al sistema
El NIST organiza la explicabilidad en cuatro principios: el sistema ofrece razones o evidencias; la explicación tiene sentido para quien la recibe; representa fielmente el proceso que generó el resultado; y el sistema reconoce los límites en los que puede operar. No existe una explicación única válida para todos: la que necesita una persona usuaria no es necesariamente la que necesita quien mantiene el sistema. Estos principios aparecen en el informe NISTIR 8312 sobre IA explicable.
Por eso, pedirle a un modelo generativo que escriba “por qué decidió esto” no basta. El texto puede sonar convincente sin probar que esa fue la causa real. La explicación debe apoyarse en elementos que puedan comprobarse: el documento de origen, los campos utilizados, una regla aplicada, la versión de una tarifa o el fragmento documental que respalda una respuesta.
La explicabilidad tampoco exige mostrar cada cálculo interno de un modelo complejo. Para una pyme, suele ser más útil dejar claro qué información y reglas influyeron en la salida, cuándo el sistema no debe continuar y cómo una persona puede corregirla. IBM describe la IA explicable y sus técnicas; esta guía lleva la idea a controles que se pueden pedir y probar en un proceso de negocio.
Seis preguntas muestran si puedes reconstruir una decisión
Elige un caso concreto, no una demostración preparada. Toma una salida real o de prueba y comprueba si el equipo puede responder estas seis preguntas:
- ¿Qué información recibió el sistema? Conserva la entrada relevante, su origen y, cuando importe, la versión del documento, regla o modelo utilizado.
- ¿Qué resultado produjo exactamente? Guarda la salida original antes de que una persona la edite, apruebe o envíe.
- ¿Qué evidencia o factores respaldan el resultado? Deben poder revisarse contra la fuente real. Si se usa una puntuación de confianza, pregunta cómo se midió y qué significa; una frase de seguridad escrita por el propio modelo no es una medida.
- ¿Qué hace que el proceso se detenga? Define por adelantado los datos ausentes, contradicciones, excepciones y niveles de impacto que requieren revisión o bloqueo.
- ¿Quién revisa y quién decide? Identifica a la persona responsable, qué puede cambiar y qué acciones requieren su aprobación antes de ejecutarse.
- ¿Qué queda registrado? Debe poder reconstruirse qué se propuso, qué se corrigió, quién tomó la decisión y cuándo, con una política de acceso y conservación adecuada a los datos.
Si una respuesta clave depende de que alguien recuerde lo que pasó, la trazabilidad todavía tiene un hueco. No hace falta guardar todos los datos para siempre, pero sí decidir qué registro se necesita para investigar un error y protegerlo de forma adecuada.
Este test recoge para una pyme los principios del NIST, no es una certificación ni un estándar oficial. El NIST advierte que las explicaciones dependen de quién las necesita y para qué; ajusta el detalle y los registros al uso concreto.
Los controles cambian según la tarea
Los ejemplos siguientes son escenarios de diseño, no resultados de proyectos de clientes. Sirven para mostrar qué evidencia pedir y dónde debe detenerse el proceso.
| Uso | Evidencia que debería quedar | Cuándo pasa a una persona |
|---|---|---|
| Extraer campos de una factura | Documento original, dato extraído, ubicación de origen y regla de validación aplicada | Si falta un dato, el documento no se lee bien o los importes no cuadran con el pedido o la factura |
| Preparar una propuesta de precio | Datos usados, versión de la tarifa, fórmula, descuentos permitidos y borrador resultante | Si falta un coste, se sale del margen autorizado o cambia el alcance solicitado; la oferta no se envía sin aprobación |
| Redactar una respuesta de atención al cliente | Respuesta propuesta y versión o fragmentos de la documentación que la respaldan | Si no encuentra una fuente válida, hay contradicciones o la consulta requiere una excepción o compromiso comercial |
En los tres casos, una puntuación alta del modelo no sustituye la revisión del impacto. El punto de control se define por lo que puede ocurrir si la salida es errónea, no solo por lo seguro que parezca el sistema.
La revisión humana debe ocurrir antes del daño difícil de revertir
Un flujo operativo automatiza la preparación y reserva a una persona las decisiones con consecuencias importantes. La persona revisora necesita ver la entrada original, la salida propuesta y el motivo concreto por el que el sistema se detuvo. Si solo recibe una respuesta sin contexto, no puede comprobarla con eficiencia.
Para tareas de bajo riesgo y fáciles de deshacer, puede ser razonable permitir que el sistema continúe y revisar una muestra después. Para una oferta que crea un compromiso, un pago o una comunicación sensible, la aprobación debe ocurrir antes de enviar o ejecutar. La revisión posterior no deshace un error irreversible.
En automatización documental, este criterio se concreta en el flujo explicado en Automatizar documentos sin perder la revisión humana.
Una puntuación de confianza solo sirve si se ha comprobado
Algunos sistemas asignan una puntuación de confianza a sus resultados. No la trates automáticamente como una probabilidad de acierto: su significado depende del sistema y debe comprobarse con ejemplos representativos del trabajo real. Si el proveedor no puede explicar cómo se calibró o qué errores deja fuera, úsala como una señal más, no como permiso para actuar sin revisión.
Una política sencilla puede separar tres rutas: continuar y revisar por muestreo en casos rutinarios; pedir revisión cuando hay una excepción; y bloquear cuando falta información esencial o el resultado puede causar un perjuicio difícil de corregir. Los umbrales deben probarse con casos reales y revisarse si cambian los datos, las reglas o el modelo.
Empieza con una decisión y prueba el registro de extremo a extremo
Escoge una tarea frecuente cuyo error puedas detectar y corregir. Define qué salida genera valor, quién responde por ella y qué casos se excluyen. Después prueba casos normales y excepcionales, incluidos datos incompletos y contradictorios. Comprueba las seis preguntas anteriores antes de conectar la salida con un pago, un envío o una decisión externa.
Mide por separado la calidad del resultado, las correcciones humanas y el tiempo que requiere la revisión. Si el sistema se equivoca de forma repetida, la causa puede estar en la fuente, las reglas, la integración o el modelo. No reduzcas la supervisión hasta que las pruebas del proceso justifiquen ese cambio. Para evaluar el efecto en el negocio, consulta también Cómo medir si la IA de tu pyme está dando resultados.
Preguntas frecuentes
¿La IA explicable garantiza que la respuesta sea correcta? No. Explicar un resultado y acertar son cuestiones distintas. Comprueba la salida con datos representativos, valida que la explicación refleje el proceso real y define cómo corregir o detener el sistema.
¿Una pyme necesita un modelo interpretable para usar IA? No necesariamente. Puede usar un modelo complejo, pero debe elegir controles proporcionales al impacto: conservar evidencia útil, fijar límites, revisar excepciones y registrar las decisiones que importan. Si no puede hacerlo con el modelo elegido, conviene cambiar el diseño o reducir el alcance.
¿Por dónde empiezo a evaluar un proveedor? Pide que demuestre el recorrido de un caso: entrada, salida, evidencia, excepción, revisión y registro. Puedes comparar esa prueba con los demás criterios de la guía Cómo elegir una empresa de desarrollo de software con IA en España.
Cómo se elaboró esta guía
OSIX Tech publica esta guía como orientación práctica para empresas que evalúan o implantan automatizaciones con IA. La explicación de los principios se basa en el informe NISTIR 8312 y en la guía de IBM citados arriba; la lista de seis preguntas y los escenarios de uso son una síntesis editorial para revisar procesos de negocio. Los ejemplos son ilustrativos y no describen resultados de clientes. Esta guía no evalúa un sistema concreto ni determina obligaciones legales aplicables a un caso particular.
Fuentes
- NISTIR 8312: Four Principles of Explainable Artificial Intelligence
- IBM: ¿Qué es la IA explicable (XAI)?