La explicabilidad es un contrato, no un dashboard

A un auditor no le interesa un gráfico SHAP. Un auditor quiere saber — para esta decisión, en esta fecha, sobre esta persona — qué regla se aplicó, qué contexto estaba cargado en ese momento exacto, quién tenía autoridad para anularla y dónde está el comprobante. Eso no es un problema de visualización. Es un problema de contrato. La mayoría de las herramientas de “IA explicable” responden una pregunta distinta a la que un regulador efectivamente va a hacer, y la brecha entre esas dos preguntas es donde los programas de compliance silenciosamente se desploman. Este texto trata de cerrar esa brecha tratando la explicabilidad como una obligación de runtime, no como una funcionalidad de reporte añadida al final.

TL;DR:

• Los gráficos de importancia de variables explican un modelo en general; los auditores preguntan por una decisión en particular, y son problemas distintos.
• Toda decisión productiva debería llevar cuatro cosas: identidad del actor, contexto cargado al momento de la decisión, regla aplicada y resultado registrado — todas reproducibles meses después.
• Cuando la cadena de evidencia es un subproducto de la operación normal, la auditoría deja de ser un proyecto y se vuelve una consulta.

La falacia del dashboard

La generación actual de herramientas de explicabilidad fue construida para científicos de datos, no para reguladores, y la diferencia importa más de lo que se suele admitir. Los gráficos SHAP, las curvas de dependencia parcial, los mapas de atención y las barras de importancia de variables son instrumentos de diagnóstico — ayudan a un modelador a entender el comportamiento de una función sobre una distribución. No responden la pregunta que un regulador realmente hace, que es estrecha, específica y casi siempre retrospectiva. El regulador quiere saber qué pasó en un caso, no qué tiende a pasar en general. Un gráfico que dice “el ingreso fue la variable más importante en promedio” es una investigación interesante. No es evidencia.

Esto es la falacia del dashboard: la suposición de que la interpretación agregada de un modelo puede sustituir la rendición de cuentas por decisión individual. No puede. Las dos operan sobre objetos distintos. La interpretación del modelo describe una función; la rendición de cuentas por decisión describe un evento. Un evento tiene una marca de tiempo, un sujeto, un actor, una foto de los inputs, una versión de política, un resultado y un efecto colateral sobre la vida de alguien. Reducir ese evento a un gráfico de barras es un error de categoría, y los auditores, los tribunales y los defensores del consumidor están cada vez mejor para detectarlo.

Hay también un problema de segundo orden. Los dashboards los leen humanos que ya confían en el sistema. Las personas que más necesitan la explicabilidad — el cliente afectado, el regulador externo, el oficial de cumplimiento interno que se unió seis meses después de que la decisión se tomó — no tienen acceso al dashboard, no saben leerlo y no lo aceptarían como evidencia aunque lo tuvieran. Necesitan un registro. Un registro que sea durable, direccionable, consultable y atado a un evento específico. El formato de ese registro no es una visualización. Es un contrato: una promesa documentada de que para cada decisión consecuente, ciertos campos siempre van a existir, siempre van a estar al alcance y siempre van a reconstruirse a la misma respuesta cuando se vuelvan a ejecutar.

El paso del dashboard al contrato reformula todo el problema. La pregunta ya no es “¿podemos explicar este modelo?” — es “para cualquier decisión que este sistema haya tomado alguna vez, ¿podemos producir, a demanda, las cuatro cosas que esa decisión llevó?” La siguiente sección trata de esas cuatro cosas.

Las cuatro cosas que toda decisión debe llevar

Una decisión no es un número. Una decisión es un evento con procedencia, y la procedencia tiene cuatro componentes irreducibles. Sommatic los trata como la carga mínima que cualquier acción consecuente debe producir, sea que la acción haya venido de un Workflow, un Agent, un Task completado por un revisor humano o un comando emitido a través del Command Center. Sin los cuatro, la decisión no es auditable, y una decisión no auditable es — desde la perspectiva del regulador — indistinguible de una decisión que no ocurrió.

Primero, la identidad del actor. Toda decisión tiene un actor. A veces el actor es un revisor humano que aprobó un reembolso. A veces es un agente que clasificó un documento entrante. A veces es un workflow programado que se ejecutó a las 02:14 UTC porque un trigger se disparó. El registro debe decir cuál, con suficiente especificidad para que ese actor pueda ser localizado, cuestionado, suspendido o auditado individualmente. Las decisiones anónimas no son decisiones; son accidentes.

Segundo, el contexto cargado al momento de la decisión. Este es el campo más subestimado en la IA en producción. Una decisión tomada hoy contra una política que estaba vigente el 14 de enero debe, seis meses más adelante, poder reconstruirse contra la política tal como estaba el 14 de enero — no como está hoy. El Knowledge Center versiona las políticas, la ejecución del agente toma una foto de qué versión se cargó, y el rastro de Explainability ata ambas cosas. Sin contexto versionado, cada cambio de modelo reescribe silenciosamente la historia, y “¿qué sabía el sistema en ese momento?” se vuelve incontestable.

Tercero, la regla aplicada. No “el modelo arrojó 0.83.” La regla. Si el workflow dice “rechaza si el score es mayor a 0.75 a menos que el cliente esté en el cohorte A,” el registro debe mostrar qué rama se ejecutó y por qué. Las decisiones operativas se rigen por lógica componible, y la lógica debe ser inspeccionable por ejecución, no solo por versión. Por eso Sommatic guarda el grafo de nodos ya resuelto junto con la ejecución, no solo una referencia a la definición del workflow.

Cuarto, el resultado registrado. ¿Qué ocurrió de verdad aguas abajo? ¿Se rechazó el reclamo, se marcó la transacción, se negó el acceso? ¿Se envió una notificación, se actualizó un registro, se llamó a un sistema downstream? El resultado cierra el ciclo. Una decisión que no produjo efecto observable es, a efectos de auditoría, una decisión que no ocurrió. Los resultados deben quedar atados a la decisión originaria con un identificador de correlación que sobreviva a través de servicios, colas y reintentos.

Estos cuatro campos no son opcionales. Son el contrato.

El replay como unidad de confianza

El logging es necesario pero insuficiente. Un log te dice que algo pasó. Un replay te permite probar qué pasó — volviendo a ejecutar la misma decisión contra el mismo contexto y confirmando el mismo resultado. La diferencia importa porque los logs se degradan: las marcas de tiempo se desfasan, los formatos cambian, los campos se renombran, los servicios se reescriben, y el significado de un valor almacenado hace seis meses raramente es el mismo que el significado de ese valor hoy. El replay evita el problema de la degradación reconstruyendo el evento mismo, no solo su descripción.

El replay es la unidad de confianza porque es falsable. Si un regulador pregunta “¿los mismos inputs producirían el mismo rechazo hoy?”, una respuesta basada en logs es una afirmación; una respuesta basada en replay es evidencia. El modelo de ejecución de Sommatic está construido para esto: cada corrida de workflow toma una foto de la configuración resuelta, los knowledge resources cargados, los prompts del agente al momento de la ejecución y los inputs humanos provenientes de cualquier Task en la cadena. Seis meses después, la misma corrida puede rehidratarse contra la misma foto — no contra la política de hoy, los prompts de hoy o el conocimiento de hoy — y comparar el resultado. Si el replay diverge del resultado registrado, eso ya es un hallazgo, y uno serio.

Hay una razón más profunda por la que el replay importa. Las fallas de compliance más dañinas no son las que el sistema hizo mal a sabiendas. Son aquellas en que el sistema hizo lo correcto en el momento y después fue derivando silenciosamente, sin que nadie lo notara, hasta que un regulador sacó un caso de hace seis meses y las respuestas ya no cuadraban. El replay atrapa la deriva. El logging no.

El replay también reformula la relación entre ingeniería y compliance. Cuando el equipo de ingeniería puede volver a ejecutar cualquier decisión histórica a demanda, el equipo de compliance deja de ser un consumidor downstream de artefactos incompletos y pasa a ser un par con acceso directo de consulta. La unidad de confianza se mueve de “documentamos nuestro proceso” a “puedes correrlo tú mismo.” Ese cambio es pequeño en el lenguaje y grande en la postura, y los reguladores sienten la diferencia en los primeros diez minutos de cualquier revisión seria.

De la auditoría-como-proyecto a la auditoría-como-consulta

La mayoría de los programas empresariales de auditoría operan en modo proyecto. Llega un trimestre, un equipo se moviliza, se recolecta evidencia de una docena de sistemas, se arman hojas de cálculo, se toman capturas de pantalla, se redactan narrativas y se produce una carpeta. La carpeta se lee una vez, se archiva, y el equipo se disuelve hasta el siguiente trimestre. El costo de cada auditoría es enorme, la evidencia ya está desactualizada cuando se revisa, y la brecha entre lo que el sistema efectivamente hizo y lo que la carpeta dice que hizo se ensancha con cada ciclo.

La alternativa es la auditoría-como-consulta: la cadena de evidencia es un subproducto de la operación normal, accesible en cualquier momento, por cualquier parte autorizada, con la misma fidelidad sin importar si la pregunta se hace un día o un año después del evento. No hay carrera trimestral porque no hay trimestre. La auditoría es solo una serie de consultas contra un sustrato que siempre iba a estar ahí.

Esto es alrededor de lo que Sommatic está construido. La capacidad de Explainability no es una capa de reporte que corre encima de la operación — es la operación. Cada ejecución de workflow emite por defecto un rastro de explicabilidad. Cada Task registra al revisor, los inputs que vio, la decisión que tomó y el tiempo que tardó. Cada llamada de agente toma una foto de su prompt, sus herramientas y el conocimiento cargado. Omnisearch abarca todo el sustrato, de modo que la pregunta “muéstrame cada decisión sobre el cliente X en los últimos 18 meses que un humano haya anulado” es una consulta, no un proyecto.

Las consecuencias son prácticas. La planta de compliance deja de escalar linealmente con el volumen operativo, porque responder una pregunta de auditoría es una búsqueda, no una investigación. Los equipos de ingeniería dejan de temer la temporada de auditoría, porque no son el cuello de botella. Los reguladores obtienen respuestas más rápidas y más completas, lo que tiende a acortar el compromiso en lugar de alargarlo. Y la organización desarrolla una ventaja silenciosa pero durable: una memoria que sobrevive a la rotación de equipos, a los cambios de proveedor y a la inevitable reescritura de la documentación interna. La auditoría-como-consulta no es una funcionalidad de compliance. Es una disciplina operativa que de paso satisface el compliance.

Cómo se ve esto: un reclamo rechazado, seis meses después

Considera un escenario concreto. Una aseguradora de salud usa Sommatic para triar los reclamos entrantes. Un workflow ingiere cada reclamo, un agente lo clasifica contra la política, los casos límite se enrutan a un revisor humano a través de un Task, y el resultado final — aprobado, rechazado o escalado — se escribe de vuelta en el sistema de registro de reclamos. El volumen es de decenas de miles por semana. El workflow lleva casi un año en producción. Una mañana, seis meses después del hecho, un regulador abre una queja: el reclamo número 4471829 fue rechazado en noviembre, la reclamante disputa el rechazo, y el regulador quiere una rendición completa de cómo se tomó esa decisión.

En una configuración tradicional, esa pregunta dispara un proyecto de varias semanas. Ingeniería extrae logs de tres sistemas. Compliance entrevista al equipo de operaciones. Alguien intenta reconstruir qué versión de la política estaba vigente en noviembre. El equipo de modelos produce un gráfico SHAP que nadie encuentra convincente. Se arma una narrativa, se cubren los huecos con palabras y se entrega una respuesta parcial semanas después, casi siempre con salvedades.

En una configuración Sommatic, la misma pregunta es una consulta. Un analista abre Omnisearch, busca el reclamo 4471829 y aterriza en la corrida del workflow. La corrida muestra la marca de tiempo, la fuente del trigger y el grafo de nodos ya resuelto tal como se ejecutó aquel día de noviembre. El nodo del agente muestra el prompt exacto que se usó, la versión de la política cargada desde el Knowledge Center en ese momento — no la versión actual, la versión de noviembre — y la salida estructurada que el agente produjo. El siguiente nodo, una regla de enrutamiento, muestra por qué el reclamo fue enviado a un revisor humano en lugar de ser auto-aprobado: el score cruzó un umbral definido en el workflow en ese momento. El registro del Task muestra la identidad del revisor, los inputs que vio en pantalla, los documentos de respaldo que consultó, la decisión que ingresó y el tiempo que dedicó. La escritura final hacia el sistema de reclamos muestra el identificador de correlación y la respuesta del sistema downstream confirmando que el rechazo quedó registrado.

El analista vuelve a ejecutar la corrida contra su foto. El resultado coincide. El rastro de Explainability se exporta como un único documento — actor, contexto, regla, resultado, cada campo con marca de tiempo y firmado — y se envía al regulador esa misma tarde.

La respuesta del regulador, en nuestra experiencia, es cualitativamente distinta a lo que los equipos están acostumbrados a recibir. La conversación se mueve de “necesitamos más información” a “tenemos lo que hace falta.” La disputa se mueve de “el sistema es opaco” a una discusión sustantiva sobre la política misma. El reclamo rechazado puede seguir siendo una conversación difícil, pero es una conversación sobre el fondo, no sobre la evidencia. Ese cambio — de defender el proceso a discutir la decisión — es lo que un contrato de explicabilidad efectivamente compra.

La conversación con el regulador que se vuelve posible

El reclamo rechazado es una forma de esta conversación. Hay otras. Una transacción marcada en una operación de pagos: qué regla del workflow disparó la marca, qué contexto se cargó desde las listas de sanciones y el historial del cliente, qué revisor la liberó o la confirmó, y qué pasó con los fondos. Una decisión de acceso denegado en un contexto de seguridad física o de identidad: qué versión de la política estaba vigente, qué atributos se evaluaron, qué agente o regla produjo el deny, y si un humano tenía la autoridad para anularlo. Un préstamo rechazado, una cuenta cerrada, un payout pausado, un beneficio retenido — cada decisión consecuente tiene la misma forma, y los mismos cuatro campos son todo lo que separa “te respondemos luego” de “aquí está el registro completo.”

El punto no es que Sommatic prevenga las disputas. No lo hace. El punto es que cuando las disputas llegan, la conversación está acotada. El sistema no está en juicio; la decisión sí. Esa acotación es lo que hace que las operaciones de alto riesgo puedan correr a escala sin producir la cola regulatoria que históricamente ha forzado a las empresas a frenar el ritmo o a sacar a los revisores humanos del circuito por completo. Con un contrato de explicabilidad en su lugar, ninguno de esos dos sacrificios es necesario. El sistema corre rápido, los humanos quedan en el circuito donde deben estar y la evidencia siempre está disponible.

Para esto está la capa cognitiva organizacional. No para sacar el juicio, sino para que todo acto de juicio — humano o de máquina — sea direccionable después, por alguien que no estaba en la sala cuando ocurrió. Ese es el estándar al que los reguladores están convergiendo, y los sistemas que lo cumplan van a operar con un grado de libertad que los que no lo cumplan van a pasar la próxima década perdiendo.

El contrato tiene una propiedad más que vale la pena nombrar. Compone. Un workflow construido hoy, con cinco nodos y un único revisor humano, produce la misma forma de evidencia que un workflow rehecho el año que viene con treinta nodos, tres agentes y cuatro revisores en dos regiones. Los campos no cambian. El modelo de replay no cambia. La interfaz de auditoría-como-consulta no cambia. Cuando se incorporan nuevas capacidades a través del Node Marketplace, o se introducen nuevas Operational Apps para revisión humana, heredan el contrato por construcción. Esa estabilidad es lo que hace viable el compliance de largo aliento. Los equipos pueden evolucionar sus operaciones de forma agresiva sin que cada evolución se convierta en un nuevo pasivo de auditoría, porque el sustrato que prueba lo que ocurrió fue diseñado una vez, en la base, y cada capa por encima hereda las mismas garantías.

→ Cómo Sommatic hace Explainability