Automatizar reportes regulatorios: trazabilidad antes que velocidad

Un reporte regulatorio no se juzga por la rapidez con que se produce sino por si su contenido puede sustentarse. Automatizarlo bien significa que cada cifra pueda rastrearse hasta su origen y que quede registro de qué versión de qué regla la produjo, porque esa es exactamente la pregunta que llega meses después.

A continuación: por qué la trazabilidad manda, qué tramos se automatizan, cómo se maneja el cambio de norma, qué exige una revisión y cómo se ordena el proyecto.

Los reportes a un ente de control comparten un perfil incómodo: consumen días de gente calificada, ocurren con periodicidad fija, siguen reglas escritas, y un error tiene consecuencias que exceden lo operativo.

Ese último rasgo cambia el criterio de diseño. En un proceso interno, la automatización se juzga por el tiempo que ahorra. Aquí se juzga primero por si el resultado puede defenderse, y solo después por lo que ahorró.

Por qué la trazabilidad manda

La pregunta que se recibe en una revisión rara vez es cuánto tardó en producirse el reporte. Es de dónde salió esta cifra, y con frecuencia sobre un periodo de hace varios meses.

Responder eso exige tres cosas que hay que decidir al construir, no al recibir la pregunta: qué registros individuales componen cada cifra agregada, qué reglas se les aplicaron, y qué versión de esas reglas estaba vigente en ese momento.

Un proceso manual, por lento que sea, suele dejar un rastro accidental: el archivo intermedio, el correo de aprobación, la hoja con las notas de quien lo armó. Una automatización mal diseñada elimina ese rastro accidental sin sustituirlo por uno deliberado, y la organización queda peor que antes en lo único que de verdad importa.

Qué tramos se automatizan

La extracción. Reunir los datos de origen con criterios de corte explícitos: qué periodo, qué estado, qué exclusiones. Es donde se introducen la mayoría de las diferencias entre dos reportes que deberían coincidir.

Las validaciones previas. Comprobar completitud, rangos, cuadres contra fuentes de control. Detectar el problema antes de generar el reporte vale mucho más que corregirlo después de haberlo presentado.

La generación en el formato exigido. Trabajo mecánico y estricto: un archivo que la autoridad rechaza por formato consume un ciclo completo de corrección y reenvío.

El expediente de soporte. Guardar, junto al reporte, el detalle que lo sustenta y la versión de reglas aplicada. Es el tramo que menos se automatiza y el que más se necesita.

Lo que no conviene automatizar sin supervisión

La presentación final. Una firma o un envío que compromete a la organización ante una autoridad debería requerir un acto humano deliberado, y no porque el cálculo sea dudoso: porque alguien tiene que asumir la responsabilidad de forma explícita.

Tampoco conviene automatizar la interpretación de una norma nueva. Cuando cambia el criterio, la primera versión se construye con revisión detallada y se compara contra el resultado manual durante uno o dos periodos, antes de confiar en ella.

Ese periodo en paralelo se percibe como trabajo duplicado y es la inversión más rentable del proyecto. Es donde aparecen las diferencias de interpretación entre lo que la norma dice y lo que el equipo venía haciendo, que suelen existir desde antes y que nadie había tenido motivo para revisar.

El cambio de norma, que es el problema real

Las reglas cambian, y ese es el escenario que rompe las automatizaciones de reporte. Un cambio de criterio en un umbral, en una clasificación o en un formato obliga a modificar la lógica, y la modificación se hace casi siempre bajo presión de plazo.

Dos decisiones de diseño reducen el daño. La primera es separar las reglas del código: umbrales, tablas de clasificación y catálogos en un lugar donde se puedan ajustar sin reconstruir el proceso completo. La segunda es versionarlas con fecha de vigencia, para que reprocesar un periodo anterior use las reglas de ese periodo y no las de hoy.

Esa segunda decisión parece exagerada hasta la primera vez que hay que rehacer un reporte de hace ocho meses. Sin vigencias, el reproceso produce cifras distintas a las presentadas, y explicar esa diferencia es mucho más incómodo que haber diseñado bien.

Por qué el cálculo no es la parte difícil

Cuando un equipo describe el trabajo de preparar un reporte regulatorio, suele centrarse en la complejidad de las reglas. Al medirlo, el tiempo casi nunca está ahí: está en reunir los datos de tres o cuatro sistemas que no coinciden entre sí y en explicar por qué no coinciden.

Esa conciliación previa es el verdadero trabajo, y es también donde nace la mayoría de los errores. Dos sistemas con criterios de corte distintos —uno por fecha de emisión, otro por fecha contable— producen cifras que difieren de forma legítima, y alguien tiene que decidir cuál aplica al reporte.

La consecuencia de diseño es clara: automatizar el cálculo sobre datos que aún no cuadran produce un reporte rápido que hay que revisar entero. Conviene resolver primero los criterios de corte y dejarlos escritos, porque esa decisión se olvida y vuelve a discutirse cada periodo con gente distinta.

Qué exige una revisión, en la práctica

Cuatro cosas, y las cuatro son más fáciles de generar que de reconstruir. El detalle que compone cada cifra. La regla aplicada y su vigencia. La evidencia de las validaciones que se corrieron y su resultado. Y el registro de aprobación: quién revisó y cuándo.

Conviene guardarlas en el momento de generar el reporte y no al recibir el requerimiento. Reconstruir a posteriori es posible y siempre deja huecos, precisamente en los periodos más antiguos, que son los que suelen preguntarse.

Esos registros contienen con frecuencia datos personales o financieros, así que su custodia y su retención se deciden junto con ciberseguridad y bajo el marco que aplique: Habeas Data (Ley 1581) en Colombia, la LFPDPPP en México.

Cómo se ordena el proyecto

Por riesgo de error, no por volumen. El reporte que más tiempo consume no suele ser el que más expone; conviene empezar por el que tiene mayor consecuencia si sale mal, porque ahí la trazabilidad rinde más.

Y por fases dentro de cada reporte: primero validaciones —que reducen el error sin cambiar el proceso—, después extracción y generación, y al final el expediente de soporte, que es el que exige más acuerdo sobre qué guardar.

El punto de partida se establece midiendo cuánto tiempo consume hoy cada reporte, cuántas correcciones exigió el último año y cuánto se tarda en responder una pregunta sobre una cifra pasada. Un assessment de automatización de procesos levanta esas cifras, y la tercera —que casi nadie mide— suele ser la que justifica el proyecto entero.

Conviene además incluir en el levantamiento una pregunta que rara vez se hace: cuántas personas saben hoy cómo se arma cada reporte. Cuando la respuesta es una, el riesgo operativo ya existe y no depende de que se automatice o no. Documentar el procedimiento suele ser el primer entregable útil, incluso antes de escribir una línea de automatización.

Preguntas frecuentes

¿Qué es lo primero al automatizar un reporte regulatorio?

La trazabilidad, no la velocidad. Cada cifra debe poder rastrearse hasta los registros que la componen, con la regla aplicada y su vigencia. Esa es la pregunta que llega en una revisión, meses después.

¿Conviene automatizar el envío a la autoridad?

No sin un acto humano deliberado. No porque el cálculo sea dudoso, sino porque alguien debe asumir explícitamente la responsabilidad de lo que se presenta.

¿Cómo se manejan los cambios de norma?

Separando las reglas del código —umbrales y clasificaciones en un lugar ajustable— y versionándolas con fecha de vigencia, para que reprocesar un periodo anterior use las reglas de ese periodo y no las actuales.

¿Por qué importa versionar las reglas?

Porque sin vigencias, rehacer un reporte de hace meses produce cifras distintas a las presentadas. Explicar esa diferencia ante una revisión es mucho más incómodo que haber diseñado la vigencia desde el inicio.

¿Qué evidencia hay que conservar?

El detalle que compone cada cifra, la regla aplicada y su vigencia, el resultado de las validaciones, y quién aprobó y cuándo. Guardarlo al generar, no al recibir el requerimiento: reconstruir después siempre deja huecos.

¿Por dónde se empieza si hay varios reportes?

Por el de mayor consecuencia si sale mal, no por el que más tiempo consume. Y dentro de cada uno, por las validaciones, que reducen el error sin cambiar todavía el proceso.