Cada proveedor en cada panel está diciendo la palabra 'agentic', pero la mayoría no puede explicar qué cambia realmente cuando dejas de tratar la GRC como un archivador y empiezas a tratarla como un sistema fluido. He pasado años en el lado ofensivo, en equipos rojos y morados, rompiendo los controles que los equipos de GRC juraban que funcionaban. Los mismos hallazgos, las mismas brechas, diferentes trimestres. Así que cuando digo que la IA agentica está a punto de remodelar la forma en que opera la GRC, no estoy vendiendo una palabra de moda: te estoy diciendo a qué le prestaría atención si todavía estuviera tratando de evadir tus controles.
Qué significa realmente 'agentic' aquí
La automatización no es nueva en GRC. Llevamos años scripteando la recopilación de evidencias y acoplando RPAs a los flujos de trabajo. El problema es que la mayor parte solo movía el trabajo pesado más rápido, seguía produciendo artefactos estáticos, se ejecutaba según un horario y respondía a la única pregunta que la GRC heredada sabe hacer: '¿Este control pasó?'. Un agente es diferente en tres aspectos específicos: tiene autonomía (actúa cuando se cumple una condición, sin esperar a que un humano inicie una tarea), tiene contexto (trabaja sobre el estado real de tu programa, no sobre una captura de pantalla del trimestre anterior) y ejecuta múltiples pasos (analiza, decide y actúa en secuencia, en lugar de volcar una fila en un informe para que tú la tramites después).
Los sistemas que estamos gobernando ya se han vuelto agenticos. La nube es elástica, la identidad es fluida, la infraestructura es efímera, la IA es no determinista y la CI/CD nunca se detiene. Los atacantes lo descubrieron hace tiempo, pero demasiados programas de cumplimiento siguen intentando gobernar sistemas en tiempo real con suposiciones puntuales. Agentico no significa entregar el juicio a un loro estocástico: de hecho, la mayor parte del trabajo debe seguir siendo determinista. El modelo proporciona razonamiento, resumen y orquestación. Tus controles, umbrales y decisiones políticas deben seguir viniendo de los humanos.
Francamente, este es uno de los mejores casos de uso de la IA en ciberseguridad. La GRC está llena de trabajo repetitivo de alto volumen realizado sobre líneas base conocidas. Eso es exactamente el tipo de problema en el que las máquinas sobresalen. Ya confiamos en la IA para ayudarnos a detectar anomalías, priorizar alertas y examinar montañas de telemetría. Usarla para ayudar a los analistas a identificar brechas de evidencia o rastrear la desviación de controles no es el salto radical que algunos pretenden. En resumen: la IA no debe reemplazar el juicio, sino dar a los profesionales más oportunidades para aplicarlo de forma creativa.
Tres cosas que realmente cambian
El trabajo del analista pasa de recopilar a gestionar. Nadie se dedica a GRC porque sueñe con perseguir capturas de pantalla y actualizar hojas de cálculo manualmente. El trabajo del analista cambia, pero no como la gente teme. Los agentes no convierten a los profesionales en supervisores pasivos; no los reemplazan, les devuelven el tiempo para aplicar el juicio donde realmente importa.
El cumplimiento pasa de periódico a continuo. Históricamente, los ciclos anuales y trimestrales existían porque los humanos no podían evaluar continuamente cada control y cada cambio. Los agentes expanden drásticamente esa capacidad, haciendo práctica la evaluación continua donde antes solo eran posibles las revisiones periódicas. En el momento en que esa restricción desaparece, '¿estamos cumpliendo ahora mismo?' se convierte en una pregunta que realmente puedes responder, no en una instantánea que defiendes tres meses después de que dejó de ser cierta.
La confianza se convierte en el cuello de botella. Ten en cuenta: aprobar/suspender es un resultado de cumplimiento; la confianza es un resultado de seguridad. La gente subestima esto porque, una vez que el esfuerzo es barato, la pregunta difícil es si confías en lo que hizo el agente y puedes probarlo, o si simplemente has trasladado el trabajo manual al impuesto de verificación. Eso es un problema de gobernanza, y es el que merece tu atención.
Cómo se ve construir uno
La teoría es fácil de consumir y archivar. Aquí está la versión concreta, usando Anecdotes Agent Studio, el constructor sin código que mi equipo puso en acceso anticipado. La mecánica es el punto, así que sigue la estructura aunque uses otra cosa. El desarrollo de un agente se reduce a tres decisiones:
- Elige un desencadenante: la condición que despierta al agente. Puede ser un horario (ejecutarse cada lunes) o un evento en tu programa (un nivel de riesgo cambia, o la evidencia de un control se vuelve obsoleta más allá de un umbral de actualización que hayas definido). Prefiero los desencadenantes por evento, porque se activan en el momento en que algo cambia, en lugar de esperar a la siguiente ejecución programada, lo que hace que la monitorización sea continua en lugar de periódica.
- Describe el trabajo en inglés sencillo: escribes la instrucción como se la darías a un analista junior, sin necesidad de código. Por ejemplo, para el control A.8.5 de ISO 27001:2022 (autenticación segura), la instrucción podría ser: 'Cuando la evidencia de MFA para A.8.5 tenga más de 24 horas, consulta el proveedor de identidad para obtener la política de cumplimiento de MFA actual, compárala con la línea base de MFA requerida por la organización, y si algún grupo ha dejado de cumplir, abre un hallazgo y asigna una tarea de remediación al propietario del control'. Puedes empezar desde una receta predefinida o escribir la tuya propia.
- Despliega y observa: ahora rastrea lo que el agente hace realmente cuando se activa ese desencadenante. Lee la política de MFA en vivo desde tu proveedor de identidad a través del plugin conectado (Okta, Entra ID, etc.), obtiene el estado de cumplimiento actual para cada grupo, lo compara con la línea base de A.8.5 que definiste, y descubre que un grupo de administradores recién aprovisionado se creó sin una política de MFA adjunta. Abre un hallazgo, adjunta la instantánea de la política que obtuvo como evidencia, la vincula a A.8.5 y asigna la remediación al propietario de IAM. Cada uno de esos pasos queda registrado en un registro de ejecución: el evento desencadenante, los datos que leyó, la comparación que realizó, la decisión que tomó y la acción que ejecutó. Esa sola ejecución es la diferencia entre 'aprobamos A.8.5 en la última evaluación' y 'A.8.5 se cumple ahora mismo, y aquí está la evidencia con marca de tiempo'.
La parte en la que los de seguridad insistirán (correctamente)
Si tu instinto al leer esto fue 'no voy a entregar decisiones de cumplimiento a una caja negra', bien, mantén eso. La GRC agentica es defendible por una razón: el trabajo es observable. Un registro de ejecución útil captura el desencadenante que se disparó, las entradas exactas que el agente leyó, la regla o línea base contra la que evaluó, la decisión que tomó y por qué, la acción que ejecutó y la evidencia que tocó, todo con marca de tiempo. Ese registro es lo que te permite reconstruir cualquier decisión después del hecho y entregarla a un evaluador sin tener que fiarte de la palabra del agente.
Dos reglas de alcance lo mantienen seguro: otorga al agente el mínimo privilegio (acceso de solo lectura a los sistemas que evalúa y acceso de escritura solo a los objetos GRC que puede crear, como hallazgos y tareas), y supedita cualquier acción importante a una persona. Detectar desviaciones y abrir un hallazgo puede ejecutarse sin supervisión; cerrar un riesgo o marcar un control como efectivo debe derivarse a un humano para su aprobación. Planifica que el agente se equivoque, porque un modelo no determinista a veces lo hará. Si abre un hallazgo sobre A.8.5 que resulta ser un falso positivo, el registro muestra exactamente qué leyó y concluyó, así que corriges la instrucción en lugar de adivinar. Una acción que puedes rastrear es una acción que puedes revertir, y por eso el registro importa más que el modelo.
Por dónde empezar
No empieces por tu control de mayor riesgo. Empieza por la tarea que requiere mucho esfuerzo y poco juicio, esa que tu equipo hace de la misma forma todas las semanas y odia. Piensa en detección de brechas de evidencia, extracción de hallazgos de informes de auditoría o generación de reglas de análisis para evidencias que no tienen un procedimiento de prueba. Prueba el patrón ahí, lee los registros, genera confianza y luego expande. Si quieres profundizar en esto, es la agenda completa del GRC Data & AI Summit 2026 el 12 de agosto, un evento virtual gratuito donde líderes de seguridad, riesgo y cumplimiento analizan lo que realmente requiere estar preparado para agentes. No volví a GRC porque fuera cómodo; volví porque estaba inacabado. Los agentes son la primera vez que las herramientas empiezan a igualar la velocidad, escala y naturaleza interconectada de los sistemas que intentamos gobernar. Mi consejo: construye el aburrido primero. Luego cuéntame qué cambió.
> La IA no debe reemplazar el juicio. Debe dar a los profesionales más oportunidades para aplicarlo de forma creativa.
Deja una respuesta