Queremos comenzar con una idea que, en nuestra opinión, debería ocupar un lugar mucho más importante en el foco de las organizaciones cuando diseñan e implantan sistemas de compliance: no basta con hacer las cosas bien, debemos estar en las mejores condiciones para acreditar cómo las hemos hecho. Esta afirmación parece evidente, pero en la práctica no siempre ocurre así.
Cuando revisamos un sistema encontramos habitualmente políticas, procedimientos, mapas de riesgos, formaciones, canales de información, controles y órganos con responsabilidades formalmente definidas. Todo ello es necesario y cada vez mas habitual en las organizaciones.
El problema aparece cuando necesitamos reconstruir qué ocurrió realmente ante una decisión, un riesgo o una incidencia concreta: ¿Quién tomó la decisión? ¿Con qué información? ¿Qué control se aplicó? ¿Quién lo ejecutó? ¿Se supervisó? ¿Qué ocurrió cuando apareció una desviación? ¿Quedó constancia suficiente para explicar, meses o años después, por qué actuó la organización como lo hizo?
Ahí comienza, a nuestro juicio, una de las diferencias más importantes en estos momentos: Cuando tenemos un sistema que está bien documentado y cuando tenemos un sistema que puede demostrar cómo funciona.
LOS DOCUMENTOS SON EL PUNTO DE PARTIDA
En compliance penal esta cuestión resulta especialmente relevante: El artículo 31 bis del Código Penal no se conforma con la aprobación formal de un modelo de organización y gestión. La regulación exige atender a su adopción previa y a su ejecución eficaz, con las diferencias que corresponden según el supuesto concreto de responsabilidad de la persona jurídica.
Esto no significa que la empresa tenga que probar su inocencia ni que debamos invertir las reglas procesales sobre carga de la prueba. La jurisprudencia del Tribunal Supremo exige acreditar los presupuestos propios de la responsabilidad penal de la persona jurídica y ha rechazado construirla automáticamente a partir del delito cometido por una persona física.
Pero una cosa es la carga jurídica de la acusación y otra, muy distinta, la posición práctica en la que queremos encontrarnos cuando tengamos que defender nuestro sistema.
Desde esa perspectiva profesional, en BONATTI COMPLIANCE creemos que la organización debe estar preparada para acreditar tres cuestiones:
1. que el modelo existía antes de los hechos;
2. que estaba realmente implantado;
3. que funcionaba de una manera adecuada al riesgo que pretendía gestionar.
Esta tríada —existencia, implantación y eficacia— estructura el análisis que utilizamos en nuestra firma para asegurar la eficacia del programa:
- · Un manual aprobado puede demostrar que existía una política, pero acredita por sí mismo que sus controles se ejecutaban.
- · Un acta puede demostrar que un órgano trató una cuestión, incluso lo que decidió, pero será necesario comprobar después cómo se ejecutó esa decisión y qué seguimiento se realizó.
- · Una formación puede estar perfectamente documentada y, sin embargo, decirnos muy poco sobre si las personas que debían aplicar un control entendieron realmente qué tenían que hacer.
- · Y una certificación puede aportar evidencia relevante sobre el sistema, pero nunca funcionará como una prueba automática de su eficacia ni como un salvoconducto frente a la responsabilidad penal.
LA EVIDENCIA SE PRODUCE MIENTRAS EL SISTEMA FUNCIONA
Por eso no concebimos la evidencia como un archivo que completamos para prepararnos ante una auditoría, una certificación o un procedimiento judicial, sino que debería generarse como consecuencia natural del funcionamiento del sistema.
Si hemos identificado un riesgo, debería ser posible conocer qué controles hemos diseñado para gestionarlo. Si existe un control, debemos saber quién es responsable de ejecutarlo y disponer de constancia suficiente de esa ejecución. Si el control es supervisado, tendremos que conocer el resultado. Y cuando aparezca una incidencia, una desviación o una debilidad, debería poder reconstruirse qué hicimos con ella y cómo afectó posteriormente al sistema.
En BONATTI COMPLIANCE utilizamos esta secuencia como método de trabajo: riesgo, control, responsable, ejecución, supervisión, incidencia, respuesta y revisión.
No es un checklist jurisprudencial, sino una forma práctica de comprobar que detrás de la arquitectura documental encontraremos una cadena de funcionamiento perfectamente trazable.
La diferencia tratamiento es importante, porque no toda la evidencia tiene valor por el mero hecho de existir: Una carpeta con miles de documentos puede ser peor que un sistema documental más sencillo si nadie sabe relacionar esos documentos con los riesgos y decisiones que pretende acreditar.
La trazabilidad exige que la información nos permita responder a una pregunta concreta, no que acumulemos documentación indiscriminadamente.
EL MISMO PROBLEMA APARECE FUERA DEL COMPLIANCE PENAL
Esta reflexión no se limita a los modelos de prevención de delitos. Pensemos en un Sistema Interno de Información.
Podemos disponer de una plataforma técnicamente impecable, de una política aprobada y de un procedimiento que reproduce correctamente la Ley 2/2023.
Pero el funcionamiento real del sistema va a depender de cuestiones mucho más dinámicas, por ejemplo, cómo se recibe y clasifica una información, quién puede acceder, cómo se realiza el triaje, qué conflictos de interés se detectan, qué medidas de protección se adoptan, cuándo procede investigar o derivar un asunto y qué razones fundamentan cada decisión.
Por eso nuestra metdología sobre SII parte de una tesis muy concreta: el sistema debe ser una arquitectura de gobierno, proceso, prueba y protección.
El proceso de triaje nos ofrece un buen ejemplo: Cuando llega una comunicación, la primera decisión no puede ser determinar si los hechos son ciertos, antes deberemos decidir cómo tratarse esa información, qué régimen resulta aplicable, quién puede conocerla, qué garantías hay que activar y si procede investigar, archivar o derivar.
Si unos meses más tarde necesitáramos explicar aquella decisión ante una autoridad, el valor del sistema dependería de que pudiéramos reconstruir por qué se tomó y cómo fue gestionada. Eso es compliance demostrable.
NO DEBEMOS CONFUNDIR EFICACIA CON AUSENCIA DE INCIDENTES
Esta es otra cuestión que nos parece especialmente importante diferenciar, porque genera dudas en muchas organizaciones: La aparición de un incumplimiento no demuestra automáticamente que el sistema de compliance haya fracasado, porque los sistemas de Compliance gestionan riesgos, pero no pueden garantizar que ninguna persona vaya a cometer nunca una infracción.
Ante un hecho irregular deberemos analizar y dar respuesta a este conjunto de factores:
- · qué riesgo se había identificado;
- · qué controles existían;
- · cómo podían ser eludidos;
- · cuánto tiempo se mantuvo la conducta;
- · si participó la dirección;
- · qué capacidad tenía el sistema para detectarla;
- · cómo reaccionó la organización cuando tuvo conocimiento de lo ocurrido.
El incidente puede proporcionar información muy relevante sobre la eficacia del sistema, pero no podemos sustituir ese análisis por la conclusión automática de que «si ocurrió, el
compliance no funcionaba». De hecho, un sistema demuestra su madurez por la forma en que responde cuando algo falla.
Detectar una debilidad, investigar razonablemente sus causas, adoptar medidas correctoras, comprobar su ejecución y revisar posteriormente el riesgo puede resultar mucho más revelador sobre el funcionamiento real del modelo que disponer de un procedimiento que nunca ha sido puesto a prueba.
DISEÑAR PENSANDO TAMBIÉN EN LA PRUEBA
Esta es la consecuencia práctica que os queremos trasladar.
Cuando diseñamos un sistema de compliance solemos preguntarnos qué riesgos tenemos, qué obligaciones debemos cumplir y qué controles necesitamos, pero os recomendamos incorporar siempre otra pregunta: si dentro de tres años tengo que explicar esta decisión, ¿qué debería poder mostrar?
Y con esto no burocratizamos el sistema, sino más bien al contrario, nos obligamos a pensar y decidir qué evidencia merece realmente conservarse, quién debe producirla, dónde debe quedar, durante cuánto tiempo y con qué relación respecto de los riesgos y controles que pretende acreditar.
Este enfoque nos ayuda también a detectar controles que existen sobre el papel pero cuya ejecución nadie puede verificar, procedimientos que generan documentación sin utilidad y decisiones relevantes que dependen exclusivamente de la memoria de las personas que participaron en ellas.
En conclusión, la prueba no puede construirse cuando aparece el problema, sino que debe formar parte de nuestro sistema desde su mismo diseño.
Y este será uno de los temas recurrentes del Blog BONATTI COMPLIANCE: cómo pasar de sistemas correctamente documentados a sistemas capaces de acreditar, con proporcionalidad y sin burocracia innecesaria, que gestionan realmente sus riesgos.
Porque esa es, al final, la pregunta que más nos interesa cuando analizamos un sistema de compliance: ¿podemos explicar y demostrar cómo funciona?
Autor: Francisco Bonatti Bonet