Anatomía de un PLAFT auditable: del dato bruto a la decisión defendible

La pregunta del auditor ya no es “¿tienen regla para PEP?”. Es “muéstrenme la decisión tomada el 16 de marzo a las 14:27 sobre el cliente X. ¿Quién aprobó? ¿Qué regla se disparó? ¿Qué versión del modelo estaba en producción? ¿Qué base de datos se consultó? ¿Tienen captura de pantalla?”.

Quien todavía trata el PLAFT como un motor de reglas está cinco años atrasado. El PLAFT en 2026 es un sistema de evidencias. La regla existe hace décadas. Lo que cambió es la obligación de reconstruir, en cualquier momento, la cadena completa que produjo esa decisión, con la misma precisión que un log de transacción financiera.

Este texto desarma lo que vuelve efectivamente auditable un programa de PLAFT, desde el punto de vista de la ingeniería, no del marketing.

1. Linaje del dato (data lineage)

Toda decisión de PLAFT tiene un input. Ese input viene de algún lugar: un registro, una transacción, una lista restrictiva, un documento. La auditoría moderna exige que respondas, para cada decisión:

• ¿De dónde vino cada dato que alimentó la decisión?
• ¿Cuándo se capturó o recibió ese dato?
• ¿Versión de la base externa (lista, bureau, fuente oficial) en el momento de la consulta?
• ¿Si cambió después de la decisión, cuál es el impacto retroactivo?

Los programas frágiles dependen de “consulta en el momento” sin versionar el resultado. Cuando el regulador pide la evidencia tres meses después, la lista ya cambió. El cliente que era PEP en marzo puede ya no estar en la lista hoy. La respuesta correcta no es “consultamos hoy”, es “consultamos el 16/03 con la versión 2026-03-15 de la lista ONU, y acá está el snapshot almacenado”.

Implementación correcta: cada llamada a fuente externa devuelve un payload completo (no solo el resultado booleano) que se almacena con hash, versión y timestamp. La decisión referencia el ID de ese snapshot, no la consulta en tiempo real.

2. Versionado de modelo y reglas

El PLAFT evoluciona. Las reglas cambian. Los modelos se reentrenan. Los umbrales se recalibran. Cuando el regulador pregunta “¿cómo decidieron este caso?”, la respuesta correcta nunca es “estas son las reglas actuales” sino “estas eran las reglas vigentes en esa fecha, en la versión X, aprobada por el comité Y en Z”.

Componentes mínimos:

• Cada regla tiene versión semántica (v1.0.0, v1.1.0) y fecha de promoción a producción.
• Cada modelo de scoring tiene hash de pesos, datos de entrenamiento y dataset de validación registrados.
• Cada threshold tiene owner, fecha de cambio, justificación y backtest de impacto.
• Pista de aprobación con nombre, función y timestamp de quien promovió cada cambio.

No se trata de hacer commit en Git. Se trata de tener, en la base de datos de producción, un ID estable que apunta a la versión exacta que decidió cada caso, recuperable años después.

3. Explicabilidad de la decisión

La pregunta que destruye programas opacos: ¿por qué este cliente fue clasificado como alto riesgo?

Respuesta inaceptable: “el modelo devolvió score 87”.

Respuesta aceptable: “score 87 = 30 puntos por PEP indirecto (socio de empresa X), + 25 puntos por país de operación en lista gris, + 15 puntos por valor de la operación por encima del perfil habitual, + 17 puntos por patrón temporal atípico”.

Cada componente está nombrado, ponderado y justificado contra una fuente. Los modelos modernos soportan esto vía SHAP values, reglas destiladas o árboles de decisión interpretables. Las cajas negras no pasan auditoría. No importa qué tan precisas sean.

En términos prácticos, cada salida del motor debe llevar:

• Score final
• Top-N factores contribuyentes (con pesos)
• Versión del modelo
• Reglas determinísticas que se dispararon
• Señales críticas (PEP, sanción, lista interna)

Si no podés mostrar esto en una pantalla de caso, el programa no es auditable.

4. Pista de auditoría inmutable

La pista de auditoría no es un log “nice to have”. Es el producto que entregás al regulador. Todo lo que pasa alrededor de una decisión tiene que estar en un log:

• Alerta generada (cuándo, por cuál regla, con cuál score)
• Caso abierto (asignado a quién, en qué cola)
• Dossier armado (qué datos, qué fuentes)
• Análisis hecho (por quién, durante cuánto tiempo, con qué justificación)
• Decisión (qué acción, con cuál motivo categorizado)
• Comunicación a la UIF (si aplica, con número de protocolo)
• Cierre (fecha, condiciones)

Ese log tiene que ser inmutable. Editar registros después de cerrado no puede ser técnicamente posible. Soluciones comunes: write-once storage, append-only databases, hash en cadena (estilo blockchain liviano), firma criptográfica.

La Ley 25.246/2000 establece la obligación de mantener registros de operaciones sospechosas y reportarlas a la UIF. La Resolución UIF 14/2023 detalla obligaciones específicas para sujetos obligados del sistema financiero, incluyendo evidencia documental, conservación de registros y gobernanza de procesos. La Resolución UIF 41/2024 actualiza requisitos específicos para entidades del mercado de capitales y pagos electrónicos, reforzando la pista de evidencias en el ciclo de monitoreo continuo.

5. Reproducibilidad temporal

Escenario real: el auditor pide la posición de riesgo de 15.000 clientes al 30 de junio del año pasado. Tenés que reconstruir el snapshot completo de esa fecha, no la posición actual.

Esto exige:

• Event sourcing o time-travel queries en la base de riesgo.
• Snapshots periódicos guardados con integridad verificable.
• Replay capability: correr el motor actual contra datos históricos para validar consistencia.
• Backtest continuo: a cada cambio de regla, correr contra histórico y medir impacto retroactivo.

El programa que solo sabe responder “esta es la situación de hoy” tiene problema. El programa que responde “al 30/06, estos eran los 15.000 clientes con riesgo medio o alto, con este score breakdown” pasa cualquier inspección.

6. Revisión independiente y gobernanza

La última pieza es organizacional. Los modelos y reglas no pueden modificarse por quien opera el motor sin revisión independiente. La matriz típica:

• Analista de riesgo/cumplimiento: propone cambio en regla o threshold.
• Equipo de modelado: corre backtest, mide impacto contra datos reales.
• Supervisor: valida el backtest y aprueba promoción a staging.
• Comité de riesgo: aprueba promoción a producción (especialmente si el impacto es material).
• Auditoría interna: revisa periódicamente la documentación.

Cada una de esas funciones tiene que estar registrada en la pista. Quién propuso, quién testeó, quién aprobó, quién revisó. Nada de “todos somos responsables”, responsabilidad nominal.

Los errores que matan programas en auditoría

Vimos consistentemente estos patrones en mesas que tropezaron en inspección:

1. “Decisión automática” sin registro de versión. El cliente fue bloqueado. ¿Quién decidió? “El sistema”. ¿Qué versión del sistema? “La actual”. ¿Y en marzo? “Era el mismo sistema”. Sin versión, sin evidencia.

2. Listas consultadas en tiempo real sin snapshot. El cliente salió de la lista PEP entre la consulta y el pedido del auditor. La evidencia desaparece.

3. Logs en texto libre. “La analista María revisó y aprobó”. ¿Qué datos vio María? ¿Cuál fue el camino que recorrió? Sin dossier reproducible, es palabra contra palabra.

4. Reglas editadas directo en producción. Sin ambiente staging, sin revisión. El cambio se volvió producción sin que nadie supiera.

5. Backtest “lo voy a correr cuando pueda”. El modelo está en producción hace 18 meses sin nunca haber sido testeado contra datos reales. Cuando el regulador pregunta la precisión actual, nadie sabe.

6. Reporte a la UIF como tarea suelta. Un mail, un adjunto, un click. Sin integración al sistema de casos. El auditor pide el ROS de junio del año pasado. ¿Dónde está? “Lo busco en el mail.”

La pregunta real

La pregunta dejó de ser “¿hacen PLAFT?”. Es ahora “¿pueden probar cómo hacen PLAFT, caso por caso, con claridad técnica y jurídica?”.

El PLAFT auditable no es un producto que se compra. Es una arquitectura que se diseña. Ingeniería de datos rigurosa, gobernanza de modelo seria, pista inmutable de eventos, explicabilidad nativa y proceso organizacional con responsabilidad nominal.

El programa que sobrevive en 2026 no es el que tiene las reglas más sofisticadas. Es el que, cuando llega el regulador, logra entregar en minutos la evidencia defendible de cada decisión de los últimos cinco años.

Guardline fue diseñada desde el día cero con esa premisa: cada decisión genera evidencia, cada modelo tiene versión, cada dato tiene linaje, cada análisis es reproducible. Si querés verlo funcionando contra un escenario real de tu negocio, hablá con nosotros.