Prompting, RAG y agentes: qué cambia

Un equipo comienza con un asistente de IA generativa que resume políticas. Más adelante, una interfaz aparentemente igual puede responder preguntas utilizando procedimientos internos. Después, esa misma interfaz puede abrir aplicaciones, recopilar información, crear registros o activar pasos de un flujo de trabajo.

Para el usuario, los tres casos pueden parecer un chatbot.

Para un auditor, son sistemas diferentes.

La distinción más sencilla es esta:

El prompting determina cómo se orienta lo que genera el modelo. RAG añade recuperación de información. Los agentes añaden la capacidad de ejecutar o coordinar acciones.

Incluso pueden utilizar el mismo modelo de lenguaje subyacente. Lo que cambia es la arquitectura que lo rodea: la información a la que el sistema puede acceder, la autoridad que puede ejercer, las dependencias que introduce y la evidencia necesaria para evaluar si está controlado.

Por eso, prompting, RAG y agentes no deberían tratarse simplemente como tres nombres para un mismo caso de uso de IA.

Generar, recuperar, actuar

Una forma útil de comparar estos patrones es preguntar de dónde proviene la capacidad adicional.

Esto no es una escala de madurez.

Un agente no es automáticamente mejor que una solución RAG, y RAG no es automáticamente mejor que prompting. La arquitectura adecuada depende del objetivo de negocio, la información necesaria, las consecuencias de un error y el grado de autoridad que realmente necesita el sistema.

Un flujo basado en prompts, simple y bien controlado, puede ser más apropiado que una solución autónoma con un gobierno débil.

Prompting: el modelo genera, pero la persona sigue dirigiendo el flujo

Un prompt es la instrucción o entrada que una persona proporciona a un sistema de IA. Puede incluir una tarea, contexto, ejemplos, restricciones, material de referencia o un formato de salida requerido.

Para un auditor interno, el prompting puede utilizarse para:

• resumir una política;
• generar preguntas para entrevistas;
• estructurar una evaluación de riesgos;
• comparar descripciones de controles;
• identificar posibles brechas en un programa de trabajo;
• redactar o mejorar un hallazgo de auditoría.

El valor está en la flexibilidad. El usuario puede cambiar la tarea sin reconstruir el sistema, y un prompting estructurado puede mejorar de forma significativa la utilidad del resultado.

Pero un mejor prompt no convierte el resultado en una fuente autorizada.

La guía del IIA de 2026 Elaboración de prompts de IA para auditores internos destaca que el contenido generado por IA puede ser incorrecto, obsoleto o inventado y que debe verificarse de forma independiente contra fuentes fiables antes de incorporarse a papeles de trabajo, informes o entregables de asesoramiento. También subraya la necesidad de utilizar herramientas aprobadas, aplicar reglas de tratamiento de datos y documentar la revisión.

En un caso de uso basado en prompting, la frontera de control permanece relativamente cerca del usuario.

Los controles típicos incluyen:

• herramientas de IA aprobadas y reglas de uso aceptable;
• restricciones sobre información confidencial o regulada;
• directrices de prompting para tareas materiales o recurrentes;
• verificación independiente de resultados significativos;
• responsabilidad clara sobre la conclusión final;
• documentación cuando la IA contribuye de forma material al trabajo de auditoría.

La evidencia de auditoría útil puede incluir el prompt o instrucción, la información proporcionada al modelo, el resultado generado, evidencia de revisión y la conclusión humana final.

La pregunta central de auditoría es:

¿Recibió el modelo información apropiada y se verificó el resultado antes de que alguien confiara en él?

RAG: el sistema incorpora una capa de recuperación

La generación aumentada por recuperación, o RAG por sus siglas en inglés, cambia la arquitectura.

En lugar de depender únicamente del entrenamiento previo del modelo y de la información que el usuario proporciona manualmente, el sistema busca dentro de un conjunto definido de información, recupera el contenido considerado relevante y lo incorpora al contexto del modelo antes de generar una respuesta.

Para Auditoría Interna, una base de conocimiento RAG podría incluir:

• metodología de auditoría;
• políticas corporativas;
• bibliotecas de controles;
• informes de auditoría anteriores;
• guías regulatorias;
• procedimientos y normas;
• taxonomías de riesgos.

Esto puede aumentar considerablemente la utilidad del sistema. Un auditor podría preguntar: “¿Qué exige nuestra metodología antes de cerrar un hallazgo?” o “¿Qué auditorías anteriores identificaron problemas de acceso de terceros?” y recibir una respuesta sustentada en contenido interno.

RAG puede mejorar el grounding o fundamentación de la respuesta. No garantiza que sea correcta.

El sistema todavía puede recuperar una fuente incompleta, omitir el documento más relevante, utilizar una versión obsoleta, exponer información que el usuario no debería ver o generar una conclusión que vaya más allá de la evidencia recuperada. Una cita puede parecer tranquilizadora y, sin embargo, apuntar a una fuente que solo respalda parcialmente la afirmación.

Por tanto, la pregunta de control cambia.

Con prompting, el auditor pregunta principalmente si la información entregada al modelo era apropiada y si la respuesta fue revisada.

Con RAG, además debe preguntar:

¿Podemos confiar en lo que recuperó el sistema?

Esto introduce controles sobre:

• repositorios de fuentes aprobados;
• propiedad y calidad de la información fuente;
• versionado y vigencia de documentos;
• procesos de ingestión e indexación;
• permisos de acceso y segregación de contenido restringido;
• calidad y evaluación de la recuperación;
• trazabilidad entre afirmaciones generadas y fuentes de respaldo;
• pruebas después de cambios en la base de conocimiento o en la configuración de recuperación.

La evidencia de auditoría también se amplía. Puede incluir inventarios de repositorios, responsables de las fuentes, matrices de acceso, logs de ingestión, versiones de documentos, logs de recuperación, resultados de evaluaciones, cambios de configuración y muestras que demuestren si el material citado realmente respalda la respuesta generada.

Una regla útil es:

RAG no elimina el riesgo del modelo. Añade riesgo de recuperación.

Agentes: el sistema pasa de responder a actuar

El término agente de IA se utiliza de forma muy amplia, por lo que los auditores deberían evitar confiar únicamente en la etiqueta.

Una definición práctica es la de un sistema que puede perseguir un objetivo seleccionando o secuenciando pasos e interactuando con herramientas, sistemas o datos, normalmente manteniendo alguna forma de estado o memoria.

La diferencia importante es el alcance operativo.

Un copiloto puede recomendar qué debería hacer después un usuario. Un agente puede estar autorizado para hacerlo.

Por ejemplo, un agente relacionado con auditoría podría:

1. recibir un conjunto de controles para revisar;
2. localizar evidencia en repositorios aprobados;
3. identificar documentación faltante;
4. solicitar evidencia adicional;
5. actualizar un flujo dentro del sistema de gestión de auditoría;
6. preparar un borrador de papel de trabajo para revisión.

En este punto, el sistema ya no solo genera información. Participa en un proceso.

Eso cambia las consecuencias del error.

Una mala respuesta de un chatbot normalmente necesita que una persona actúe sobre ella antes de cambiar un proceso de negocio. Un agente puede crear registros, enviar mensajes, llamar herramientas de software, modificar datos o activar directamente pasos posteriores.

Para los agentes, la autoridad se convierte en un concepto central de control.

Los auditores deberían entender:

• a qué sistemas puede acceder el agente;
• qué identidad o cuenta de servicio utiliza;
• qué datos puede leer;
• qué registros puede crear, modificar o eliminar;
• qué herramientas o API puede invocar;
• qué acciones requieren aprobación humana;
• qué límites existen sobre transacciones, valor o volumen;
• cómo determina el sistema que una tarea está completa;
• qué ocurre cuando una herramienta falla o devuelve resultados inesperados;
• si las acciones pueden revertirse;
• cómo se escalan las excepciones;
• si las acciones materiales quedan registradas de forma que puedan reconstruirse posteriormente.

Esto conduce a una segunda regla útil:

Cuanto mayor sea la capacidad de un sistema de IA para actuar, menos suficiente resulta evaluar únicamente la calidad de sus respuestas.

El aseguramiento sobre agentes debe examinar también la ruta de ejecución.

La superficie de auditoría se expande en cuatro direcciones

Pasar de prompting a RAG y después a agentes cambia mucho más que la experiencia del usuario. Amplía la superficie de auditoría al menos en cuatro direcciones.

1. Contexto

Con prompting, gran parte del contexto lo proporciona directamente el usuario.

Con RAG, el sistema selecciona contexto desde repositorios.

Con agentes, el contexto también puede acumularse dinámicamente a partir de pasos anteriores, resultados de herramientas, memoria o estado del sistema.

Por tanto, el auditor pasa de probar la disciplina de entrada a evaluar también la selección de información y la gestión del estado.

2. Permisos

Un asistente basado en prompts puede necesitar acceso únicamente a la información que el usuario le entrega intencionalmente.

Una solución RAG necesita acceso controlado a repositorios.

Un agente puede necesitar credenciales y permisos en múltiples aplicaciones.

La gestión de identidades y accesos se vuelve, por tanto, cada vez más importante a medida que aumenta el alcance operativo.

3. Consecuencia

Una respuesta no sustentada de un sistema basado en prompts puede seguir siendo un borrador hasta que una persona actúe sobre ella.

Una respuesta RAG puede recibir mayor credibilidad porque parece estar fundamentada en documentación interna.

Un agente puede convertir potencialmente una inferencia incorrecta en una acción.

La pregunta de control adecuada no es solo “¿Puede equivocarse el modelo?”, sino también “¿Qué puede ocurrir después cuando se equivoca?”

4. Evidencia

En prompting, normalmente puede reconstruirse lo ocurrido a partir de la entrada, la salida y la acción del revisor.

RAG exige además evidencia de qué información se recuperó, de dónde provino y bajo qué versión o condiciones de acceso.

Los agentes requieren evidencia sobre decisiones, llamadas a herramientas, aprobaciones, acciones, excepciones y resultados.

La observabilidad se vuelve más importante a medida que aumentan la autonomía y la conectividad del sistema.

Comparación práctica para auditores

Qué aportan los principales marcos

Los marcos no necesitan convertirse en listas de verificación separadas. Ayudan a responder partes distintas del problema de control.

NIST: gestionar el riesgo a lo largo del ciclo de vida de la IA

El NIST AI Risk Management Framework y su perfil para IA generativa ofrecen una estructura de gestión de riesgos para identificar, evaluar, medir y gestionar riesgos de IA a lo largo del diseño, desarrollo, despliegue y uso.

Para esta comparación, la implicación práctica es que el perfil de riesgo debe reflejar la arquitectura real del sistema. Un asistente basado únicamente en prompts, una implementación RAG y un agente conectado a aplicaciones de negocio no deberían evaluarse como si generaran la misma exposición.

ISO/IEC 42001: gobernar el sistema de gestión que rodea a la IA

ISO/IEC 42001 es útil porque mira más allá de la precisión de los resultados. Incluye requisitos sobre roles y responsabilidades, evaluación y tratamiento de riesgos de IA, evaluación de impactos, información documentada, planificación y control operacional, gestión de cambios, monitoreo y medición, y auditoría interna.

Esto adquiere mayor importancia a medida que la arquitectura se conecta con más elementos.

Un caso de uso basado en prompts puede apoyarse especialmente en controles de uso aceptable, competencia, tratamiento de datos, revisión y verificación. Una solución RAG añade gobierno de repositorios, configuración de recuperación, acceso y mantenimiento de fuentes. Un agente extiende el control operacional hacia herramientas, permisos, aprobaciones, ejecución, monitoreo y gestión de excepciones.

COSO: tratar la IA generativa como un problema de control interno

La guía de COSO de 2026 sobre control interno efectivo sobre IA generativa refuerza una idea práctica: la adopción acelerada de GenAI cambia los flujos de trabajo e introduce riesgos que deben integrarse en el entorno de control de la organización, en lugar de tratarse como un asunto tecnológico aislado.

Esta perspectiva resulta especialmente relevante para RAG y agentes, porque muchos riesgos materiales aparecen en el proceso que rodea al modelo: accesos, configuración, cambios, aprobaciones, monitoreo y consecuencias de acciones automatizadas.

El IIA: auditar la IA de la organización y gobernar el uso propio de Auditoría Interna

El Marco de Auditoría de Inteligencia Artificial del IIA proporciona orientación basada en principios para evaluar gobierno, riesgos y controles relacionados con IA. Su guía de prompting de 2026 también deja clara la responsabilidad paralela de Auditoría Interna: gobernar su propio uso de IA, verificar resultados significativos y preservar el juicio profesional y la auditabilidad.

Estas expectativas adquieren mayor importancia, no menor, cuando Auditoría Interna pasa de prompting a RAG o a flujos agentic.

Un asistente RAG para metodología puede propagar de forma sistemática una interpretación obsoleta si el gobierno de fuentes es débil. Un agente conectado a una plataforma de gestión de auditoría puede crear un riesgo operativo mayor si sus permisos, reglas de aprobación o logs están mal diseñados.

Auditoría Interna debería hacerse a sí misma la misma pregunta que plantea a la dirección:

¿Qué autoridad adicional le dio esta arquitectura a la IA y qué control adicional introdujimos debido a ello?

Errores comunes

Un error es tratar toda solución de GenAI simplemente como “un chatbot”. Eso oculta diferencias materiales en acceso a fuentes, permisos, trazabilidad e impacto operativo.

Otro es asumir que RAG resuelve las alucinaciones. La recuperación puede mejorar la fundamentación, pero la propia recuperación puede fallar y el modelo puede interpretar o exagerar de forma incorrecta el material recuperado.

Un tercer error es tratar la revisión humana como un control completo para agentes. La revisión puede ser valiosa, pero no compensa permisos excesivos, logs ausentes, puntos de aprobación débiles o acciones que ocurren antes de que un revisor pueda verlas.

Un cuarto error es confundir sofisticación técnica con madurez. Una arquitectura más compleja no es automáticamente una arquitectura mejor controlada ni de mayor valor.

Por último, algunas organizaciones prueban el modelo pero ignoran el sistema que lo rodea. En implementaciones empresariales, debilidades de control importantes pueden encontrarse en repositorios, derechos de acceso, API, lógica de flujo de trabajo, mecanismos de aprobación, monitoreo o gestión de cambios, y no necesariamente en el modelo en sí.

Comenzar por la decisión, no por la arquitectura

Antes de elegir prompting, RAG o un agente, conviene preguntar:

1. ¿Qué resultado queremos lograr?
2. ¿Qué información necesita realmente la IA?
3. ¿Es necesario recuperar esa información automáticamente?
4. ¿La IA necesita autoridad para actuar o basta con que formule una recomendación?
5. ¿Qué ocurre si el sistema se equivoca?
6. ¿Qué evidencia demostraría que los controles funcionan eficazmente?

Esta secuencia suele conducir a una arquitectura más sencilla que comenzar directamente por la tecnología.

Y normalmente eso es una fortaleza, no una limitación.

Prompting, RAG y agentes no son simplemente tres formas de utilizar el mismo modelo. Crean entornos de control diferentes.

El prompting cambia las instrucciones y el contexto utilizados para generar. RAG añade una capa de recuperación. Los agentes añaden alcance operativo mediante herramientas y acciones.

Para los auditores, la progresión práctica no es “básico a avanzado”. Es:

generar → recuperar → actuar

Y con cada cambio, la pregunta de aseguramiento se amplía desde “¿Es fiable el resultado?” hacia una pregunta más amplia:

“¿Podemos confiar en la información, los permisos, las decisiones y las acciones que rodean a este sistema de IA?”

Fuentes

• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)
• ISO, ISO/IEC 42001:2023 — Artificial intelligence management system
• COSO, Achieving Effective Internal Control Over Generative AI
• The IIA, Artificial Intelligence Auditing Framework
• The IIA, AI Framework Support Tools
• The Institute of Internal Auditors, Elaboración de prompts de IA para auditores internos (2026).
• The Institute of Internal Auditors Netherlands and ISACA Netherlands Chapter, Internal Audit in the Age of Generative AI: A Strategic Approach to Implementing AI in Internal Audit (2026).