La segregación de funciones se rompe en el momento en que un agente de IA obtiene acceso de escritura a su ERP, porque el control nunca se diseñó para un actor capaz de ocupar todos los roles a la vez. El SoD clásico supone que una persona ocupa un solo puesto: el auxiliar que crea el registro maestro de proveedores no es el gerente que aprueba el pago, y quien contabiliza el asiento contable no es quien concilia la cuenta. Un agente no ocupa ningún puesto. Tiene una credencial, y esa credencial carga con los permisos que resultaron cómodos el día en que alguien conectó la integración.
El resultado previsible es una sola identidad no humana capaz de crear un proveedor, generar una orden de compra, contabilizar un asiento contable, liberarlo bajo un umbral de aprobación automática y conciliar la cuenta que acaba de tocar. Cada paso produce una línea de registro impecable y ninguno está técnicamente no autorizado. La falla es estructural, no de comportamiento, y por eso se le escapa a la mayoría de las herramientas de SoD: los conjuntos de reglas convencionales comparan asignaciones de roles humanos entre sí, y el agente sencillamente no está en el modelo de roles.
Esto está llegando ahora, no en el próximo ciclo. BlackLine llevó su sistema multiagente de conciliación Verity Prepare a disponibilidad general el 27 de julio de 2026. El Account Reconciliation Agent para Dynamics 365 Finance de Microsoft está en vista previa lista para producción. El Financial Close Agent de Workday se anunció en septiembre de 2025 para estar disponible en 2026. Los agentes ya están saliendo. Los modelos de roles que hay debajo, en su mayoría, no.
Los agentes concentran funciones por tres razones estructurales: se aprovisionan como integraciones y no como empleados, reciben alcance de tarea en lugar de alcance de rol, y se reutilizan en procesos que a ninguna persona se le permitiría abarcar.
El aprovisionamiento falla primero. Un agente llega por la vía de un proyecto y no por Recursos Humanos, así que nadie levanta una solicitud de rol ni pasa el conjunto de permisos propuesto por el conjunto de reglas de SoD que habría rechazado esa misma combinación para una persona. Recibe un usuario de API, un secreto de cliente y un paquete de permisos armado por quien necesitaba que el piloto funcionara para el viernes.
El alcance falla en segundo lugar. Los roles humanos están acotados por función y, por lo general, por entidad, centro de costos o rango de cuentas. Los permisos de un agente están acotados por verbo: "contabilizar asientos contables" se otorga como una capacidad en bruto, no como un rol atado a un libro mayor, un código de sociedad o un período. La reutilización agrava las dos cosas. La identidad que empezó en conciliación bancaria se reorienta hacia operaciones intercompañía, después a devengos, después a alta de proveedores, porque ya autentica sin problemas, y ninguna ampliación individual parece lo bastante grande como para disparar una revisión.
Una combinación tóxica para un agente es cualquier par de funciones incompatibles que sus auditores ya prueban, ahora en manos de un único principal que nunca cambia de rol. Rompa cada una de estas en el momento de otorgar los permisos, en lugar de descubrirlas a posteriori:
La pregunta de SoD para un agente no es "¿qué hizo?". Es "¿qué habría podido hacer con los permisos que tiene?". Una capacidad que un agente nunca ha ejercido sigue siendo una deficiencia de control, porque el conflicto vive en el derecho de acceso, no en el registro de actividad.
Las cuentas de servicio son la causa raíz porque se construyeron para ser amplias, estáticas y compartidas, justo lo contrario de lo que debe ser un rol con funciones segregadas. Una cuenta de servicio existe para que un proceso por lotes nunca falle a las 2 de la mañana, así que su conjunto de permisos es la unión de todo lo que alguien alguna vez necesitó y su dueño suele ser un equipo, un buzón o un ingeniero que ya no está. Ponga agentes encima y se rompen tres cosas. La atribución se derrumba, porque varios agentes se autentican como el mismo principal, así que el registro muestra que la cuenta actuó pero no qué agente ni qué prompt la impulsó. La expansión de permisos pasa inadvertida. La revocación se vuelve imposible, porque nadie puede probar qué consumidor se va a romper.
La solución es una identidad distinta, con nombre y con patrocinador para cada agente, con su propia credencial y sus propios derechos de acceso. El modelo de gobernanza de Entra Agent ID de Microsoft es una plantilla útil: cada agente recibe un objeto de directorio de primera clase, un patrocinador humano responsable de su ciclo de vida y de sus accesos, derechos entregados mediante paquetes de acceso con fecha de vencimiento, y transferencia automática del patrocinio si esa persona se va. Profundizamos en credenciales y tokens en identidad y acceso de los agentes, y en el manejo de secretos que hay detrás en nuestra práctica de Seguridad de IA.
Modele el agente como un rol definiendo primero el rol, en términos de negocio, y vinculando después exactamente un agente a ese rol. El orden importa. La mayoría de los equipos construye el agente, descubre sus permisos viéndolo fallar y rellena después una definición de rol que en realidad es la transcripción de los errores.
Una definición defendible nombra el paso del proceso del que el agente es dueño, las entidades y los rangos de cuentas dentro del alcance, los tipos de transacción que puede originar, el valor máximo sobre el que puede actuar sin una persona, los sistemas que puede leer y las cosas que jamás debe hacer. Escríbala antes de la primera línea de código de integración. Si el conjunto de permisos resultante hace saltar su conjunto de reglas de SoD, encontró el problema cuando todavía era barato. El corolario: un agente corresponde a un rol, y un proceso que abarca funciones incompatibles necesita varios agentes con identidades separadas, no un agente con una lista de herramientas más larga. Esa es la diferencia entre una automatización que sobrevive a un recorrido de SOX y una que sacan del cierre en octubre. Cuando construimos agentes de IA a medida para equipos de finanzas, la descomposición de roles ocurre antes del diseño de la automatización de procesos, no después.
Un segundo agente es un control genuino solo cuando sus modos de falla no están correlacionados con los del primero. Un revisor que corre el mismo modelo, sobre el mismo andamiaje de prompts, sobre los mismos datos y del mismo proveedor va a coincidir con el preparador casi siempre que el preparador se equivoca, porque se equivoca por las mismas razones. Eso no es preparador y revisor. Eso es un solo control contado dos veces.
La falla correlacionada es todo el riesgo. Si el preparador malinterpreta una nota bancaria ambigua, un revisor montado sobre el mismo modelo la malinterpreta de forma idéntica, y los puntajes de confianza no lo salvan porque la confianza también está correlacionada. La guía de COSO de 2026 lo dice sin rodeos: en palabras de Lucia Wind, Directora Ejecutiva y Presidenta de COSO, la IA generativa "puede equivocarse con total confianza, ser manipulada con facilidad o desplegarse fuera de los canales formales de supervisión", según el anuncio de febrero de 2026.
Un revisor automatizado se gana la condición de control cuando difiere del preparador en al menos dos dimensiones: un motor de reglas determinístico en lugar de un modelo, una fuente de verdad independiente como el estado de cuenta bancario en lugar del extracto del ERP que usó el preparador, una identidad distinta con acceso de solo lectura a la salida del preparador, y un equipo dueño distinto. La lógica determinística suele ser la más sólida, y se combina con el diseño de umbrales que cubrimos en controles determinísticos para agentes de IA en finanzas. El agente de Dynamics 365 de Microsoft, cabe destacar, recomienda una acción ante las excepciones por discrepancia en el monto del comprobante y deja la decisión de aceptar en manos de una persona, un valor por defecto razonable hasta que su historia de independencia sea sólida.
El documento Achieving Effective Internal Control Over Generative AI de COSO (Lograr un control interno eficaz sobre la IA generativa), publicado en febrero de 2026 y resumido por el Journal of Accountancy, aplica los cinco componentes conocidos del control interno a la GenAI y ordena los usos de IA en ocho categorías de capacidad: ingesta, transformación, contabilización, orquestación, juicio, monitoreo, inteligencia regulatoria e interacción entre personas e IA. Léalo como una taxonomía de roles. Contabilización, juicio y monitoreo son categorías separadas por la misma razón por la que preparador, revisor y monitor son puestos separados.
Para SOX no se exige nada nuevo en lo conceptual: el marco de 2013 ya espera que la administración segregue funciones incompatibles y seleccione controles alternativos donde la segregación resulte impracticable. Lo que cambia es la población y la evidencia. Su población de ITGC ahora incluye las identidades de los agentes, los prompts y las configuraciones de herramientas que definen su comportamiento, y el pipeline que promueve los cambios en ellos, y por eso manejamos las liberaciones de agentes como una disciplina de AI DevOps. La urgencia es real: CPA Practice Advisor, citando la encuesta Global AI in Finance de KPMG de marzo de 2026 aplicada a 1,013 líderes financieros senior, reportó que el uso activo de IA en finanzas subió del 30 por ciento en 2024 al 75 por ciento, mientras que solo el 42 por ciento calificó a su organización como plenamente lista para el aseguramiento.
Una revisión de accesos de agentes responde cuatro preguntas por agente: quién lo patrocina, qué puede hacer, qué hizo realmente y si su conjunto de derechos de acceso viola alguna regla de SoD. Empiece por el proveedor de identidad y por las tablas de autorización del ERP, no por una consola de proveedor, porque una consola de proveedor le muestra los agentes que ese proveedor conoce y nada más.
El conjunto mínimo de evidencia es todo principal no humano con acceso de escritura a los sistemas financieros, su patrocinador nombrado, sus permisos efectivos en lugar de sus roles asignados, su fecha de último uso, el historial de cambios de su prompt y de su configuración de herramientas, y la salida de su conjunto de reglas de SoD ejecutado contra esos permisos. Los permisos efectivos son la parte difícil y la parte que importa, porque los alcances heredados y los grupos anidados otorgan de forma rutinaria mucho más de lo que sugiere el nombre de un rol. Combine esto con un registro a prueba de manipulación para que la revisión tenga algo contra qué contrastar, el tema de nuestro artículo sobre evidencia de auditoría de nivel probatorio para agentes de IA.
Tres cosas cambian una vez que las identidades de agentes entran en el alcance: la población, el revisor y la pregunta. La población se amplía, porque las identidades de agentes están dentro del alcance y la revisión queda incompleta sin ellas. El revisor cambia, porque un dueño de proceso no puede juzgar si los alcances de OAuth de un agente son apropiados, así que estas certificaciones necesitan firma conjunta del dueño del proceso y de un ingeniero. Y la pregunta cambia, de "¿esta persona todavía necesita este acceso?" a "¿cambió el conjunto de permisos efectivos de este agente, y sigue correspondiendo exactamente a un rol de nuestra matriz de SoD?". Agregue dos certificaciones que no tienen equivalente humano: una verificación de inactividad que deshabilite cualquier identidad de agente sin uso durante 90 días, y una atestación de que el prompt y la lista de herramientas en producción coinciden con lo que se aprobó.
Inventaríe toda identidad no humana con acceso de escritura al libro mayor, a los libros auxiliares, a tesorería y al maestro de proveedores, y asigne a cada una un patrocinador humano con nombre y apellido. Extraiga los permisos efectivos y páselos por su conjunto de reglas de SoD existente como si cada agente fuera un empleado. Rompa cada conflicto dividiendo el agente en identidades separadas, en lugar de agregarle encima una revisión compensatoria. Retire las cuentas de servicio compartidas que use más de un agente. Después actualice su procedimiento de revisión de accesos y sus narrativas de controles SOX para cubrir las identidades de agentes, la gestión de cambios de prompts y configuraciones, y las dos atestaciones anteriores.
Infonaligy ayuda a los líderes de IT y de finanzas a diseñar modelos de roles para agentes, a descomponer combinaciones tóxicas de capacidades y a reconstruir revisiones de accesos que resistan un recorrido de SOX. Nuestro equipo de consultoría de IA trabaja desde nuestra sede en Dallas–Fort Worth de forma presencial en todo Texas y Oklahoma, y de forma remota en todo el país. Si va a poner agentes en cualquier lugar cerca del cierre, empiece por el modelo de roles, no por el piloto. Escríbanos a hello@infonaligy.com o llame al 800-985-1365.
Infonaligy trabaja con organizaciones en toda el área metropolitana de Dallas–Fort Worth, Texas y Oklahoma de forma presencial, con entrega remota en todo el país.
Comenzamos con un inventario completo de las identidades no humanas que tienen acceso de escritura a sus sistemas financieros, y después extraemos los permisos efectivos en lugar de los nombres de los roles asignados y los pasamos por su conjunto de reglas de SoD existente. Donde un agente tenga una combinación tóxica de capacidades, la descomponemos en identidades separadas, con credenciales separadas y patrocinadores separados, en lugar de taparla con un paso más de revisión. Luego reescribimos su procedimiento trimestral de revisión de accesos, sus narrativas de controles SOX y su proceso de gestión de cambios para cubrir las identidades de agentes, los prompts y las configuraciones de herramientas. El trabajo es neutral en cuanto a proveedores y se adapta al ERP, al proveedor de identidad y a la plataforma de agentes que ya utiliza.
Infonaligy