Herramientas para el armado de un programa de cumplimiento efectivo. Informes Técnicos de Autoevaluación de Riesgos de los sujetos obligados (IT AER).
Por Gabriel Guinle, Graduado de la Certificación Internacional en Ética y Compliance (AAEC – UCEMA)
Las opiniones expresadas en este contenido pertenecen exclusivamente al autor y no reflejan necesariamente la postura, opinión oficial ni las políticas de la Asociación Argentina de Ética y Compliance (AAEC).
Introducción
SCRUM es un marco ligero que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptables aplicable a problemas complejos. Cabe asimismo destacar que sus características se enmarcan en: a) simple; b) incompleto y se basa en la inteligencia colectiva de sus usuarios.
La Dirección de Supervisión de la Unidad de Información Financiera (UIF), es responsable de supervisar el cumplimiento de los regímenes informativos relacionados con las evaluaciones de riesgos y analizar su calidad y respectivas gestiones de riesgo, realizadas por los sujetos obligados.
Desarrollo del caso
Conforme el último reporte emitido por la UIF, las principales falencias y observaciones detectadas en los Informes Técnicos de autoevaluación de riesgos – 2025, IT AER , fueron las siguientes:
- Ausencia de metodología: la falta de metodología puede conducir a falta de transparencia, calidad y reducir la credibilidad del informe.
- Metodología deficiente en la evaluación de riesgos (enfoque basado en riesgos EBR).
- Ausencia de elementos imprescindibles: contenidos mínimos que revisten de rigurosidad al informe (v.g., alcance, riesgo, ambiente externo e interno, período etc.)
- Falta de análisis de factores riesgo: comprende aspectos como ausencia de escalas de calificación, falta de transparencia en la ponderación, falta de evaluación de riesgos inherentes y residuales, análisis incompleto.
- Deficiencia en la especificidad y evaluación de controles mitigantes: descripción genérica de medidas mitigantes y omisión de un detalle específico de implementación y abordaje de los riesgos identificados por factor de riesgo.
- Falta de resultados derivados de tareas de control asociados a la ausencia de un análisis de efectividad e implementación sobre riesgos residuales.
Para adentrarnos en esta temática es dable destacar que el objetivo de mejorar la capacidad y adaptabilidad de una organización inicia con la necesidad de un cambio. Esta necesidad nos introduce en lo que denominaríamos un cambio organizacional y en principio comprende o se basa en dos jugadores fundamentales:
a) Aquellos quienes requieren un cambio;
b) Aquellos quienes son proclives al cambio.
Pero antes de desarrollar estos conceptos nos conviene interpretar que constituye una gestión de cambio. En principio, cabe mencionar que la pertinencia de una gestión de cambio, la mayoría de las veces se encuentra presente un grado de incertidumbre sobre algún asunto o cuestión. Debemos reconocer que hay dos factores que influyen en un cambio organizacional:
i) Factores externos que provocan o disparan el cambio (v.g. competencia global, clientes, competidores y proveedores);
ii) Factores internos que influyen en el proceso (v.g. Misión, valores, objetivos, planes organizacionales).
Si decidiéramos identificar a los pilares fundamentales y transversales que influyen en un proyecto de cambio, estos podrían agruparse de la siguiente forma: a) Gestión de la comunicación b) Gestión de los interesados c) Gestión de la formación.
Pero; ¿qué es la gestión de cambio? Para responder este interrogante debemos pensar primeramente en cuál es su objetivo, el cual podríamos definir como aquel tendiente a “gestionar y reajustar la transición de las personas en el cambio de hábitos y evitar, de ser posible, disminuir la productividad”.²
Esto implica abordar la proactividad, la globalización y el ser digitales. El cambio organizacional “ágil” consiste en un enfoque orientado a mejorar la capacidad de una organización con el objetivo de transformarlas en adaptables y que brinden rápidas respuestas a los cambios en su entorno mediante el empleo de prácticas ágiles con una mentalidad orientada al cliente y a la mejora continua. Fundamentalmente, se apoya en los principios y prácticas de la metodología ágil, desarrollada inicialmente para diseños de software y posteriormente extendido a diversos ámbitos o sectores específicos.
El “Manifiesto por el desarrollo Ágil del Software” estableció 4 valores y 12 principios para el desarrollo del software ágil.³
Pero, una pregunta surge instantáneamente, ¿cómo logramos trabajar en un proyecto de forma ágil? La respuesta, podría resumirse en estos 3 puntos básicamente:
- Llevando a cabo un desarrollo iterativo a partir de la definición del alcance del proyecto trabajando como un equipo Cross-funcional.
- Haciendo Sprint semanales y reuniones periódicas para evaluar el avance del Sprint Backlog (lista de tareas del sprint).
- Establecer productos que sean potencialmente entregables en cada sprint.
Es momento de adentrarnos en la metodología SCRUM. Esta metodología se apoya en el trabajo en equipo, la colaboración y la comunicación, pudiendo aplicarse a cualquier proyecto que requiera un marco ágil y flexible, basándose en un enfoque iterativo e incremental para gestionar proyectos.
Se desarrolla en tres etapas fundamentales:
- Fomento de la transparencia
- Adaptación
- Entrega temprana y frecuente de productos o soluciones
A modo de simplificación, podríamos definir la dinámica de la metodología SCRUM de esta manera:
- Reunión del Product Owner con el cliente.
- Planificar el sprint.
- Ejecución del sprint.
- Reunión con el cliente,
- Retrospectiva del Sprint
- Conclusiones
i.- Planificación de Sprint: Los proyectos se gestionan mediante «Sprints», (es decir, períodos cortos de tiempo (generalmente de una a cuatro semanas) durante el cual un equipo trabaja para completar un conjunto específico de tareas del Product Backlog). Cada sprint comienza con una planificación dentro de la cual el equipo identifica los objetivos y define las tareas básicas para cumplirlos.
ii.- Ejecución del Sprint: El trabajo en equipo se enfoca sobre los requisitos y funcionalidades definidas e indicadas previamente al Scrum Master por el Product Owner, siguiendo las indicaciones definidas en la planificación del Sprint. Esto requiere de una colaboración estrecha entre los miembros del equipo con el fin de completar tareas y alcanzar objetivos propuestos en el Sprint, haciendo reuniones de seguimiento (dayly scrums) donde el equipo de trabajo evalúa el avance del sprint y discute aquellas dificultades e inconvenientes que se hayan producido.
iii.- Revisión del Sprint: El Product Owner evalúa el trabajo realizado durante el Sprint, donde queda definido un producto viable mínimo. Finalizando el Sprint, se inicia una revisión del mismo, cuyo resultado sustenta la presentación al cliente del trabajo realizado o al equipo de gestión del proyecto.
iv.- Retrospectiva del Sprint: El equipo de trabajo evalúa qué salió bien y qué resultó mal, estableciendo pautas a mejorar durante el próximo Sprint. Estas vistas hacia atrás son una práctica fundamental y reúne lecciones aprendidas del equipo sobre mejoras y reconoce logros. Además, motiva a revisar aquello que salió bien y aquello que podría haber sido mejor, involucrando y respetando los aportes de todos los miembros del equipo, permitiendo definir un plan de mejora para la iteración siguiente y para proyectos futuros.
Para ello se podría: a) Confeccionar una lista de oportunidades clasificadas por nivel de importancia y urgencia. b) Adicionar aquellas tareas necesarias para alcanzar aquellas mejoras. c) Aplicar y difundir estas ideas en el momento apropiado al equipo de trabajo.
Herramientas para el armado de un Programa de Cumplimiento
En el marco del Enfoque Basado en Riesgo (EBR) implementado por la UIF, la Dirección de Supervisión cumple un rol central en evaluar no solo el cumplimiento formal de las presentaciones, sino la efectividad real de los sistemas de prevención de los sujetos obligados. En la práctica, esto implica tres ejes clave:
- Calidad de la Autoevaluación de Riesgos: Revisa que el Informe de Autoevaluación de Riesgos (y la Metodología de Evaluación) refleje de manera consistente los factores de riesgo propios del sujeto obligado (clientes, productos/servicios, canales de distribución y zonas geográficas).
- Gestión y Mitigación: Analiza que las políticas, procedimientos y controles internos (los manuales de prevención, planes de capacitación, auditorías) sean proporcionales a los riesgos identificados.
Compliance Backlog: Es la lista única y priorizada de todas las necesidades del programa (políticas, procedimientos, herramientas de screening, canales de denuncia, capacitaciones, matrices de riesgo).
En mi firme convicción que diseñar e implementar un Programa de Cumplimiento Corporativo (Compliance) utilizando la metodología Agile / Scrum constituye una excelente estrategia. En lugar de desarrollar un manual gigante e inoperante durante un año (enfoque tradicional Waterfall o desarrollo en cascada, que involucra un modelo de gestión de proyectos lineal y secuencial), este enfoque permite generar valor funcional desde las primeras semanas, ajustarse rápido a nuevas regulaciones (como resoluciones de la UIF) y adaptar los controles a la operativa real de la empresa.
1. Mapeo de Roles: Scrum vs. Compliance
Para lograr que el marco funcione, debemos adaptar las responsabilidades clave del marco Scrum a la gestión de Compliance:
| Rol Scrum | Adaptación en Compliance | Responsabilidades Principales |
|---|---|---|
| Product Owner (PO) | Chief Compliance Officer (CCO) | Define la visión, prioriza los riesgos normativos/operativos en el Backlog, interactúa con los Stakeholders (Directorio, Auditores, UIF, Reguladores) y valida que los entregables cumplan con los criterios regulatorios. |
| Scrum Master (SM) | Facilitador de Compliance / Agilista | Remueve bloqueos (ej. falta de insumos de TI, demoras en legales), cuida la metodología, asegura el ritmo de trabajo y protege al equipo de interrupciones externas. |
| Development Team | Equipo Multidisciplinario de Compliance | Especialistas en Legal, Riesgos, Procesos, Datos/TI, Capacitación y Auditoría. Son quienes investigan, redactan procedimientos, automatizan controles y dictan capacitaciones. |
2. Artefactos Scrum Aplicados a Compliance
- Compliance Backlog: Es la lista única y priorizada de todas las necesidades del programa (políticas, procedimientos, herramientas de screening, canales de denuncia, capacitaciones, matrices de riesgo).
- Sprint Backlog: Subconjunto de tareas seleccionadas del Backlog priorizado para ser ejecutadas y entregadas en un Sprint (usualmente ciclos de 2 a 3 semanas).
- Incremento: Una política aprobada, un proceso probado e implementado, o un módulo de capacitación completado y listo para ser usado por la organización.
3. Plan de Implementación por Sprints (Roadmap del Programa)
Planteamos una hoja de ruta dividida en 4 Sprints iniciales de 2 semanas cada uno (2 meses en total) para dejar operativo un Mínimo Producto Viable (MVP) del Programa de Cumplimiento.
Sprint 1: Fundamentos y Evaluación Inicial de Riesgos
• Objetivo: Establecer el tono de la alta dirección (Tone at the Top) y definir el mapa de riesgos base. Entregables /Incrementos:
- Código de Ética y Conducta redactado y aprobado por el Directorio. Matriz de Riesgos Inicial (Mapeo de riesgos PLA/FT, corrupción, fraude, etc.). Estructura del Compliance Backlog consolidada.
Sprint 2: Debida Diligencia y Conozca a su Cliente / Proveedor (KYC/KYP)
• Objetivo: Implementar los controles de entrada para contrapartes críticas. Entregables /Incrementos:
- Procedimiento ágil de Debida Diligencia para Clientes y Proveedores de alto riesgo.
- Formulario digital de Declaración Jurada de PEPs (Personas Expuestas Políticamente).
- Integración o prueba piloto con herramienta automatizada de listas restrictivas/PEP.
Sprint 3: Canal de Denuncias y Gestión de Conflictos de Interés
• Objetivo: Habilitar mecanismos de detección e integridad interna. Entregables / Incrementos:
- Canal de Denuncias Éticas (Línea Transparente) configurado con garantía de confidencialidad y no represalias.
- Protocolo de investigación interna y régimen disciplinario básico.
- Política y formulario digital de Declaración de Conflicto de Interés y Obsequios.
Sprint 4: Capacitación, Medición y Mejora Continua
• Objetivo: Desplegar el programa a la cultura organizacional y evaluar resultados. Entregables / Incrementos:
- Módulo e-leaming o taller presencial corto (15 min) para el personal de mayor riesgo.
- Dashboard/Tablero de Control para el CCO (KPls y KRls de cumplimiento).
- Primer reporte formal presentado al Directorio / Comité de Auditoría.
4. Cadencia de Ceremonias Agile
1. Sprint Planning (Inicio de Sprint • 2 horas): El CCO (PO) presenta las historias del Backlog priorizadas según regulación/riesgo. El equipo define qué se compromete a entregar en las 2 semanas.
2. Daily Standup (Diario -15 minutos): Sincronización rápida respondiendo 3 preguntas:
- ¿Qué hice ayer para el objetivo del Sprint?, ¿Qué haré hoy? , ¿Tengo algún bloqueo (normativo, operativo, tecnológico)?
3. Sprint Review (Final de Sprint -1 hora): El equipo demuestra los productos funcionales creados a los Stakeholders (ej. el Canal de Denuncias funcionando, el manual iterado). No se muestran diapositivas abstractas, se muestran procesos aplicables.
4. Sprint Retrospective (Final de Sprint -1 hora): El equipo evalúa cómo trabajó internamente: ¿qué funcionó?, ¿qué cuellos de botella hubo con las áreas operativas?, ¿cómo podemos agilizar el próximo Sprint?
5. Criterios de Aceptación (Definition of Done – DoD)
Un entregable del Programa de Cumplimiento solo se considera «HECHO» (Done) cuando cumple obligatoriamente con estos 4 puntos:
- Alineación Normativa: Legal/Compliance valida que cumple con la regulación vigente (resoluciones UIF, ley corporativa, etc.).
- Prueba Operativa: El proceso fue probado con un usuario real del negocio y no detiene la operación injustificadamente.
- Documentación Registrada: El procedimiento o política cuenta con su versión archivada y trazable para futuras inspecciones.
- Comunicación I Lanzamiento: El personal afectado fue notificado o capacitado sobre el nuevo control.
Ventaja clave de este enfoque:
En lugar de esperar 6 u 8 meses para «lanzar» el programa formalmente, al finalizar el Sprint 1 la empresa ya tiene su Código de Ética y Matriz de Riesgo operativos. Al finalizar el Sprint 3, ya cuenta con canal de denuncias y controles de lavado/KYC activos, reduciendo el riesgo sancionatorio sustancialmente en poco tiempo.
Takeaways
Exponer claramente en el ambiente de trabajo las conclusiones alcanzadas, estableciendo cual fue la mayor dificultad y cuales las lecciones aprendidas durante el proceso de adaptación considerando un punto de vista ágil. En Anexo adjunto, podrá accederse a un modelo de programa de cumplimiento con SCRUM – Marco Ágil para la Gestión de Riesgos, Integración Normativa y Supervisión Corporativa Eficiente.
.
¹ Informe_tecnico_de_autoevaluaciones_de_riesgo_2025.pdf
² https://www.ealde.es/factores-gestion-del-cambio-direccion-de-proyectos/
³ http://agilemanifesto.org/iso/es/manifesto.html
