En casi toda conversación sobre automatización financiera en una empresa sujeta a SOX llega un momento en que alguien dice: "Nos encantaría automatizar esto, pero es un control clave." La sala se queda en silencio, el proyecto se posterga "hasta después de la auditoría" y el equipo vuelve a hacer el trabajo a mano.
A veces esa cautela está justificada. Casi siempre, no. SOX no prohíbe la automatización — y las normas de auditoría de hecho contemplan enfoques de prueba específicos, a menudo más livianos, para los controles automatizados que para los manuales. Lo que el cumplimiento SOX sí exige es que puedas demostrar que el control está bien diseñado, que el sistema que lo rodea está gobernado y que la evidencia existe. Eso es un problema mucho más manejable que "SOX no nos deja".
Esto aplica a empresas que cotizan en EE. UU. bajo la Sección 404, a empresas que preparan una salida a bolsa y, muy especialmente en Latinoamérica, a subsidiarias de grupos listados en EE. UU., cuyos procesos locales forman parte del entorno de control de la casa matriz. Si tu operación en México, Colombia, Chile o Argentina reporta a un grupo estadounidense, tus controles probablemente están dentro del alcance aunque tu empresa no cotice.
Primero, un cambio de enfoque: SOX evalúa controles, no herramientas
No existe tal cosa como un "software que cumple SOX". El cumplimiento SOX es una propiedad de tu control interno sobre la información financiera (ICFR), normalmente evaluado con el marco COSO. Una herramienta puede hacer que un control sea más fácil o más difícil de evidenciar, pero el auditor evalúa tu control: el riesgo que cubre, con qué precisión lo cubre y si operó durante todo el período.
Eso cambia la pregunta. En lugar de "¿Está permitida esta automatización?", la pregunta correcta es "¿Qué control ejecuta este proceso y cómo vamos a demostrar que funciona?"
Qué prueban realmente los auditores en un control automatizado
Bajo la norma AS 2201 del PCAOB — la que rige las auditorías de control interno de empresas que cotizan en EE. UU. — probar un control automatizado se reduce, en general, a cinco cosas.
1. Un diseño de control claro, vinculado a un riesgo concreto
El auditor quiere saber qué puede salir mal (por ejemplo, pagar una factura de proveedor que no coincide con una orden de compra aprobada), qué aseveración de los estados financieros afecta, qué hace el control al respecto y con qué precisión: la tolerancia en monto o porcentaje a partir de la cual una partida se marca como excepción. Muchos controles manuales están documentados de forma vaga ("Cuentas por pagar revisa las facturas"). Automatizar te obliga a definir la regla de manera explícita, algo que los auditores suelen valorar.
2. Controles generales de TI (ITGC) alrededor del sistema
Aquí está la mayor parte del trabajo real. Los ITGC suelen cubrir tres áreas:
- Accesos: Quién puede modificar la lógica, los umbrales o los datos maestros, y quién puede aprobar excepciones. Las cuentas de servicio que usa la automatización deben tener solo los permisos necesarios.
- Gestión de cambios: Los cambios en reglas, scripts o configuración se solicitan, prueban, aprueban y despliegan por alguien distinto de quien los escribió — con registro de cada paso.
- Operación: Las ejecuciones programadas se monitorean. Si una falla, alguien se entera y lo resuelve; nada se omite en silencio.
Si los ITGC son efectivos, el auditor puede confiar en que el control automatizado sigue comportándose igual que cuando lo probó. Si no lo son, todas las demás pruebas se vuelven mucho más difíciles.
3. Una "prueba de uno" sobre la lógica
Para un control manual que se ejecuta a diario, el auditor normalmente selecciona una muestra considerable de instancias a lo largo del año. Para un control automatizado respaldado por ITGC efectivos, en general puede probar cada escenario relevante una sola vez — una coincidencia limpia, una diferencia, una partida fuera de tolerancia, un duplicado — y concluir que la lógica funciona. La AS 2201 también describe el "benchmarking": si la lógica no cambió y los ITGC siguen siendo efectivos, las pruebas anteriores pueden mantenerse con menos trabajo en los años siguientes.
Esta es la parte que más se subestima. Un control automatizado bien gobernado suele ser más barato de auditar que el proceso manual al que reemplaza.
4. Integridad y exactitud de los datos que entran y salen
Los auditores llaman a los reportes y datos usados en un control información producida por la entidad (IPE). Si tu automatización concilia un archivo bancario contra un extracto del ERP, el auditor querrá evidencia de que el extracto está completo (entraron todas las transacciones) y es exacto (nada se alteró en el camino). La respuesta práctica: conteos de registros y totales de control capturados automáticamente en cada traspaso.
5. Evidencia de cómo se gestionaron las excepciones
Para todo lo que la automatización deriva a una persona, el auditor evalúa el paso humano como cualquier control de revisión: quién revisó, cuándo, con qué información, qué decidió y si hubo seguimiento. Una revisión sin rastro de lo que realmente se revisó es un control débil — venga la partida de un agente o de una planilla.
El auditor no pregunta si el trabajo lo hizo una máquina. Pregunta si puedes demostrar que se hizo correctamente, mediante un proceso autorizado, cada vez que importaba.
Lo que SOX no exige: los supuestos que frenan proyectos
"Una persona tiene que volver a revisar cada transacción automatizada."
No. Revisar de nuevo todo lo que produce la automatización agrega costo sin agregar precisión — y un revisor que aprueba cientos de partidas por día sin mirarlas puede ni siquiera constituir un control válido. Lo que se exige es un control diseñado. Muchas veces eso significa que la lógica automatizada resuelve las partidas dentro de tolerancias definidas y las excepciones pasan a una persona. Dónde fijas ese umbral es, en sí, la decisión de control clave, como analizamos en nuestro artículo sobre responsabilidad de los agentes de IA.
"Un proceso automatizado no puede tener ningún error."
Los controles se evalúan según si están bien diseñados y operan de forma efectiva, y las deficiencias se clasifican por severidad: deficiencia, deficiencia significativa o debilidad material. Cuando la automatización marca algo que no puede resolver y una persona lo resuelve, eso es el control funcionando. Lo que los auditores penalizan son los errores que pasan sin ser detectados.
"La IA no puede formar parte de un proceso relevante para SOX."
Nada lo prohíbe. Pero la respuesta de un modelo no siempre es idéntica ante la misma entrada, y eso no encaja bien en una prueba de uno. El diseño más limpio en la práctica: el modelo propone; las reglas configuradas y la aprobación humana deciden. El modelo extrae campos, sugiere coincidencias o clasifica documentos; umbrales y reglas de derivación deterministas definen qué se registra automáticamente y qué pasa a revisión. Esas reglas son verificables. La sugerencia del modelo se convierte en un insumo del control, no en el control. Explicamos este patrón en nuestro análisis de conciliación bancaria.
"No podemos cambiar un control a mitad de año."
Reemplazar un control manual por uno automatizado durante el año es habitual. Tu auditor necesita ver el nuevo control operando durante un período suficiente antes de la fecha de evaluación — cuánto depende de la frecuencia con que se ejecuta — junto con documentación de cuándo se hizo el cambio y cómo se gestionó la transición. Es un ejercicio de planificación, no una razón para esperar un ciclo de auditoría completo.
"Los auditores tienen que aprobar la automatización antes de construirla."
Los auditores externos no pueden diseñar tus controles; las reglas de independencia lo impiden. Pero sí puedes — y deberías — presentarles el diseño previsto y preguntarles cómo planean probarlo. Si esa conversación ocurre temprano, elimina la mayor parte de la incertidumbre que de otro modo aparece en pleno trabajo de campo. En subsidiarias, conviene incluir también al equipo de control interno de la casa matriz.
Checklist previo a la auditoría para cualquier proceso automatizado
Si puedes responder cada punto con evidencia, y no solo con intenciones, estás en buena posición:
- Riesgo y precisión: ¿Qué riesgo y aseveración cubre este control, y a partir de qué tolerancia marca una partida?
- Accesos: ¿Quién puede cambiar la lógica, los umbrales o los datos de referencia, y se revisan esos accesos periódicamente?
- Registro de cambios: ¿Cómo se solicitan, prueban, aprueban y despliegan los cambios, y puedes mostrar el rastro?
- Monitoreo de ejecuciones: ¿Cómo sabes que cada ejecución programada ocurrió, y qué pasa si una falla?
- Integridad de datos: ¿Cómo demuestras que los datos de entrada estaban completos y eran exactos?
- Evidencia de excepciones: Para cada excepción derivada, ¿puedes mostrar quién la revisó, cuándo y qué decidió?
- Documentación: ¿Podría alguien nuevo en el proceso explicarle al auditor la narrativa y la configuración sin que esté presente quien lo construyó?
Un punto adicional: si un proveedor externo aloja u opera parte del proceso, pregúntale temprano a tu auditor cómo obtendrá confianza sobre los controles de ese proveedor — normalmente mediante un reporte SOC 1 o pruebas directas. Esa es una de las razones por las que algunos equipos de finanzas prefieren ejecutar la automatización dentro de su propia infraestructura.
Son decisiones de diseño, no detalles para el final. Cuando definimos el alcance de una automatización, las tratamos como parte de la construcción: un dashboard de auditoría que registra cada decisión y su aprobador, acceso por equipos, derivación de excepciones con human-in-the-loop, hosting en la nube o local según lo que prefieran tus equipos de TI y auditoría, y documentación entregada junto con el sistema.
En resumen
SOX no pregunta si un proceso es manual o automatizado. Pregunta si el control está diseñado para detectar lo que importa, si el sistema que lo rodea está gobernado y si puedes demostrar ambas cosas. Un control automatizado bien construido suele responder esas preguntas con más claridad que el proceso manual al que reemplaza — un log es mejor testigo que la memoria.
Los proyectos que se frenan suelen frenarse por supuestos que nadie verificó. Lleva el checklist anterior a tu contralor y a tu responsable de auditoría, recorran juntos un proceso candidato, y sabrás rápidamente si el obstáculo es real. Si todavía estás eligiendo ese candidato, nuestra guía para elegir un primer proyecto representativo complementa bien este artículo.
Este artículo es una guía general, no asesoramiento de auditoría ni legal. La metodología de tu auditor externo es la que define cómo se probarán tus controles específicos.