La IA y los controles internos: consideraciones de SOX para los equipos de finanzas

Por Jane Ha · Actualizado el 11 de octubre de 2026

La IA y los controles internos es la cuestión de cómo encaja una herramienta de IA que interviene en la información financiera dentro de los controles que una empresa que cotiza en bolsa debe mantener bajo SOX: quién es responsable de ella, qué se le permite hacer, cómo se revisa su resultado y qué evidencia demuestra que la revisión ocurrió. La IA no crea un nuevo conjunto de reglas. Agrega un nuevo tipo de actor, uno que puede ser rápido, inconsistente y difícil de explicar, dentro de un marco de control diseñado en torno a personas y sistemas deterministas.

Esta guía está dirigida a contralores (controller), CFOs, líderes de programas SOX y gerentes de finanzas que están implementando IA en procesos como cuentas por pagar, la conciliación bancaria o el cierre de mes. Forma parte de la colección AI for Finance, así que comience con la IA en finanzas y contabilidad si prefiere ver primero el panorama más amplio.

Datos clave

• Las reglas de la SEC exigen que la gerencia de un emisor evalúe el control interno sobre la información financiera (ICFR) al cierre de cada ejercicio fiscal, usando un marco de control adecuado y reconocido, establecido mediante procedimientos de debido proceso (17 CFR 240.13a-15).
• La norma AS 2201 del PCAOB define una debilidad material como una deficiencia, o una combinación de deficiencias, en el ICFR que crea una posibilidad razonable de que una incorrección material no se prevenga o no se detecte oportunamente (PCAOB AS 2201).
• La publicación de COSO de febrero de 2026, Achieving Effective Internal Control Over Generative AI, aplica los cinco componentes del Internal Control-Integrated Framework y clasifica los casos de uso de IA generativa en ocho tipos de capacidad (Journal of Accountancy).
• En su Spotlight de julio de 2024, el personal del PCAOB informó que las firmas de auditoría esperan que la IA generativa complemente a las personas, y no las reemplace, y que las firmas no veían las normas de auditoría del PCAOB como impedimentos para usarla (PCAOB).
• Según AS 2201, un auditor puede usar el "benchmarking" para un control de aplicación totalmente automatizado solo si los controles generales sobre los cambios de programas, el acceso a los programas y las operaciones informáticas son eficaces y el control no ha cambiado desde que se fijó la línea base (PCAOB AS 2201).

Por qué la IA es una cuestión de SOX y no solo de TI

La sección 404 de SOX pone la responsabilidad en la gerencia. La regla de la SEC exige que la gerencia evalúe el ICFR cada año frente a un marco reconocido. El Internal Control-Integrated Framework de COSO es el que la mayoría de los equipos de finanzas conoce. Si una herramienta de IA prepara un asiento contable, concilia una línea bancaria, redacta una revelación o clasifica una factura, su resultado fluye hacia los estados financieros, y el entorno de control que la rodea queda dentro del alcance.

El Spotlight del personal del PCAOB es útil aquí porque describe lo que los preparadores ya decían. Algunos usaban IA generativa para primeros borradores de documentos internos y para trabajo repetitivo y menos complejo, como preparar conciliaciones de cuentas. Los preparadores también señalaron la naturaleza de "caja negra" de algunas herramientas y la inconsistencia de los resultados, lo que plantea dudas sobre la auditabilidad de lo que produce la herramienta. Y algunos auditores observaron que el uso de IA generativa por parte de los preparadores podía amplificar riesgos de TI existentes, como la segregación de funciones, o crear riesgos que antes no existían.

Esos tres puntos enmarcan el resto de esta guía: una herramienta usada para trabajo contable real, resultados que varían y viejos riesgos de control en lugares nuevos.

Cómo trata AS 2201 la tecnología (y por qué importa para la IA)

AS 2201 es la norma que siguen los auditores externos cuando auditan el ICFR. Tres de sus ideas determinan cómo mirarán los auditores la IA.

Un enfoque de arriba hacia abajo. El auditor parte del nivel de los estados financieros y se concentra en los controles a nivel de entidad antes de descender a las cuentas significativas y sus afirmaciones relevantes (PCAOB AS 2201). Una herramienta de IA ubicada en un rincón no financiero y de bajo riesgo del negocio quizá nunca se pruebe. Una que opere dentro de una cuenta significativa, sí.

Las TI no se evalúan por separado. La norma dice que el auditor debe entender cómo afectan las TI al flujo de transacciones de la empresa, y que identificar los riesgos y controles dentro de las TI es "una parte integral del enfoque de arriba hacia abajo" y no una evaluación separada. Para usted, eso significa que un sistema de IA debe evaluarse como parte del proceso al que da soporte, y no en una revisión tecnológica aislada.

Los controles automatizados se apoyan en los controles generales. AS 2201 dice que un control automatizado generalmente sería de menor riesgo si los controles generales de TI relevantes son eficaces, y permite el benchmarking de controles de aplicación totalmente automatizados cuando los controles de cambios de programas, de acceso y de operaciones se sostienen. Aquí la IA se vuelve incómoda. Un control automatizado tradicional se comporta igual cada vez, así que una línea base sigue siendo válida hasta que alguien cambia el código. Un modelo cuyo comportamiento cambia con una actualización del proveedor, nuevos datos de entrenamiento o un prompt modificado no le da esa tranquilidad al auditor. Planifique tratar los cambios de modelo y de prompt como trataría los cambios de código.

Dónde toca la IA el entorno de control

La guía de COSO sobre IA generativa asigna controles a los cinco componentes del marco (entorno de control, evaluación de riesgos, actividades de control, información y comunicación, y monitoreo) y agrupa los casos de uso en ocho tipos de capacidad: ingesta, transformación, contabilización, orquestación, criterio, monitoreo, inteligencia regulatoria e interacción humano-IA (Journal of Accountancy). La publicación incluye ejemplos, expectativas mínimas de control y métricas ilustrativas para cada capacidad. COSO también ha publicado una guía complementaria anterior sobre automatización robótica de procesos, que los equipos de finanzas con automatización más antigua pueden leer junto con esta.

La tabla siguiente aplica ese enfoque por capacidades al trabajo financiero habitual. Es una ilustración de cómo organizar su propio análisis, no una copia del mapeo de COSO.

Las preguntas de diseño de control que debe hacer sobre cada herramienta de IA

Cuando una herramienta llega a un proceso financiero, aplíquele las mismas preguntas que haría sobre cualquier control, más algunas específicas de la IA.

1. ¿Cuál es su rol: preparador, revisor o ninguno? Una IA que redacta es un preparador. Una IA que revisa el trabajo de otra IA no es una revisión independiente en el sentido de SOX, a menos que una persona se responsabilice de la conclusión.
2. ¿Qué verifica realmente el revisor humano? Un control que dice "el contralor revisa el resultado de la IA" es débil si el revisor solo ve un resumen. Defina qué examina, qué umbral activa un examen más detallado y qué hace cuando algo no cuadra.
3. ¿En qué información se apoya el control? Si la verificación de un revisor depende de un informe que produjo la IA, la integridad y exactitud de ese informe forman parte del control.
4. ¿El resultado es repetible? Si la misma entrada puede dar resultados distintos, dígalo en la descripción del control y diseñe la revisión para detectar la variación.
5. ¿Quién puede modificarla? Los modelos, los prompts, las fuentes de recuperación y las reglas de negocio son configuración. Necesitan responsables y registros de cambios. Trate los prompts, los conectores de recuperación y las reglas de transformación como configuraciones gobernadas.
6. ¿Qué ocurre cuando se equivoca o está caída? Nombre el respaldo manual y a la persona que puede pausar la herramienta.

Controles generales de TI para la IA

Los controles generales de TI (ITGC) cubren el entorno que rodea a las aplicaciones: acceso, gestión de cambios y operaciones. La IA no los reemplaza. Los estira.

• Gestión de accesos. Limite quién puede usar la herramienta, qué datos puede leer y qué puede escribir. Una cuenta de servicio que puede crear y aprobar una contabilización colapsa la segregación de funciones en una sola credencial. El Spotlight del PCAOB registra la preocupación de los auditores de que la IA podría amplificar precisamente este tipo de riesgo.
• Gestión de cambios. Dé seguimiento a las versiones del modelo, los cambios de prompt, los cambios en las fuentes de recuperación y las actualizaciones del proveedor. Pruebe antes de la liberación en un entorno que no sea de producción. El Spotlight del PCAOB señala que algunos preparadores ejecutan la nueva tecnología en un entorno paralelo antes de implementarla, lo cual es un buen hábito aquí.
• Operaciones y monitoreo. Registre las entradas, los resultados y las modificaciones. Vigile la deriva: los cambios repentinos en el volumen, los importes o las tasas de modificación son señales tempranas de que el comportamiento ha cambiado.
• Riesgo de terceros y de datos. Si un proveedor aloja el modelo, entienda qué datos financieros salen de su entorno y cómo los maneja el proveedor. El Spotlight muestra a firmas que fijan límites sobre lo que puede cargarse en las herramientas de IA para evitar que datos confidenciales se hagan públicos, y los equipos de finanzas necesitan la misma regla para los datos del libro mayor y la información bancaria.

Evidencia: qué querrá ver un auditor

La evidencia es donde los proyectos de IA suelen quedarse cortos, porque la herramienta se construye para ahorrar tiempo y nadie construye la pista de auditoría. Planifíquela desde el inicio. El Spotlight describe a firmas que diseñan sus propias herramientas de IA para documentar los datos fuente subyacentes utilizados, y el mismo principio se aplica a las suyas.

Para los insumos de base, la preparación de los datos financieros cubre la calidad de datos que cada uno de estos controles da por supuesta.

Cómo incorporar una herramienta de IA a su programa SOX, paso a paso

1. Haga el inventario de cada uso de IA en finanzas. Incluya las herramientas compradas por equipos individuales y las funciones activadas dentro de sistemas existentes. Manténgalo al día, porque aparecen usos nuevos constantemente.
2. Clasifique por niveles según el impacto en la información financiera. ¿El resultado llega a una cuenta significativa, a una revelación o a una estimación? Las herramientas que no lo hacen pueden seguir una política más ligera.
3. Asigne un responsable para cada herramienta. Una persona designada responde por el alcance, los cambios y el monitoreo.
4. Documente el proceso y el control. Actualice la narrativa y la matriz de riesgos y controles para mostrar dónde está la IA, qué hace y quién la revisa. Sea específico sobre la revisión.
5. Separe las funciones. La IA no debería preparar y aprobar el mismo elemento, y ninguna cuenta debería tener ambos derechos.
6. Establezca la cobertura de ITGC. Acceso, gestión de cambios, registros y revisión del proveedor para la herramienta y su configuración.
7. Pruebe antes de la puesta en marcha. Ejecute en paralelo con el proceso existente durante algunos ciclos y compare línea por línea. Registre los resultados como evidencia.
8. Hable con su auditor externo desde temprano. Comparta el diseño antes de que el control entre en operación, no en los recorridos de fin de año. Para la visión de la auditoría interna, consulte la IA en la auditoría interna.
9. Monitoree y vuelva a probar. Dé seguimiento a las tasas de modificación, las excepciones y la precisión. Repita las pruebas cuando cambie el modelo, el prompt o la fuente de datos.

Errores comunes

• Tratar "una persona lo revisa" como el control. Sin una revisión definida, un umbral y un registro, no hay control que probar.
• Dejar que la IA sea dueña de una aprobación. La aprobación automática de una contabilización por el mismo sistema que la preparó es una deficiencia de segregación de funciones a la espera de ser descubierta.
• Ignorar los cambios de configuración. Una edición de prompt o una actualización del modelo del proveedor puede cambiar el comportamiento sin lanzamiento de código ni ticket.
• Sin inventario. La IA en la sombra (shadow AI) en un equipo de finanzas es un riesgo que no puede evaluar si no sabe que existe.
• Evidencia a posteriori. Los registros y las notas del revisor son difíciles de reconstruir meses después. Captúrelos mientras el control se ejecuta.
• Suponer que la garantía del proveedor lo cubre a usted. Un informe del proveedor puede ayudar, pero sus controles sobre cómo usa la herramienta siguen siendo suyos.
• Olvidar el fraude. Los modelos pueden usarse mal o manipularse. Consulte detección de fraude con IA en finanzas para ver cómo la IA corta en ambos sentidos.
• Pasar por alto las áreas de criterio. Los ingresos y las áreas con muchas estimaciones requieren un cuidado adicional; la IA en el reconocimiento de ingresos muestra dónde reside el criterio.

Qué medir

• Cobertura: proporción de casos de uso de IA inventariados, con responsable y clasificados por nivel.
• Desempeño del control: excepciones detectadas por los revisores, tasa de modificaciones y tiempo para resolver cada una.
• Precisión: tasa de error frente a los documentos fuente o los datos reales, por herramienta.
• Disciplina de cambios: cambios de modelo, prompt y reglas realizados con aprobación frente a sin ella.
• Preparación de la evidencia: proporción de controles con registros y aprobaciones completos al cierre del trimestre.

Siguientes pasos

Si hace una sola cosa este trimestre, construya el inventario y clasifique cada herramienta según si llega a una cuenta significativa. Luego endurezca el paso de revisión de las herramientas de nivel más alto y empiece a registrar la evidencia desde ahora. Después decida quién es responsable de cada control a medida que el trabajo cambia de manos, y déjelo por escrito.