Los agentes de inteligencia artificial están transformando la forma en que las empresas automatizan procesos, consultan información y utilizan aplicaciones informáticas.
A diferencia de un sistema que simplemente responde preguntas, un agente de IA puede seleccionar herramientas, consultar bases de datos, analizar documentos y ejecutar tareas para alcanzar determinados objetivos.
Esta capacidad ofrece oportunidades para mejorar la productividad y reducir determinadas actividades manuales.
Sin embargo, también introduce nuevos desafíos.
¿Qué ocurre cuando un agente interpreta incorrectamente una instrucción? ¿Qué sucede si utiliza información equivocada? ¿Puede modificar datos empresariales sin autorización o acceder a información confidencial?
Estas preguntas son fundamentales para cualquier organización interesada en implementar agentes autónomos.
Los riesgos de los agentes de inteligencia artificial no se limitan a generar respuestas incorrectas. También incluyen problemas de seguridad, privacidad, permisos, ejecución, costes y supervisión.
En esta guía analizaremos las principales limitaciones técnicas y operativas de los agentes de IA, con ejemplos empresariales y estrategias para desarrollar soluciones más seguras y fiables.
¿Cuáles son los principales riesgos de los agentes de inteligencia artificial?
Los agentes de IA pueden presentar diferentes riesgos dependiendo de su arquitectura, herramientas y nivel de autonomía.
Entre los más importantes encontramos:
- Generación de información incorrecta o alucinaciones.
- Interpretación equivocada de instrucciones.
- Ataques de prompt injection.
- Acceso excesivo a aplicaciones y datos.
- Divulgación de información confidencial.
- Ejecución de acciones no deseadas.
- Errores acumulativos en procesos de varios pasos.
- Costes y consumo de recursos inesperados.
- Problemas de privacidad y cumplimiento normativo.
- Dificultades de supervisión, evaluación y auditoría.
Estos riesgos pueden combinarse.
Por ejemplo, una interpretación incorrecta puede provocar la selección de una herramienta inadecuada y terminar modificando un registro empresarial.
Por ello, la seguridad debe considerarse un elemento fundamental de la arquitectura y no una función añadida al finalizar el desarrollo.
1. Alucinaciones: cuando un agente genera información incorrecta
Una de las limitaciones más conocidas de los modelos generativos es la posibilidad de producir información falsa, incompleta o no respaldada por las fuentes disponibles.
Este fenómeno se conoce habitualmente como alucinación de inteligencia artificial.
Un modelo puede generar una respuesta convincente que contiene datos incorrectos.
En un chatbot informativo, esto puede provocar que un usuario reciba información equivocada.
En un agente capaz de ejecutar herramientas, las consecuencias pueden ser mayores.
Ejemplo empresarial
Imaginemos un agente conectado a un CRM.
El usuario solicita:
«Prepara un informe sobre las oportunidades comerciales que tienen una probabilidad de cierre superior al 70 %».
Si el agente interpreta incorrectamente los datos, puede presentar oportunidades que no cumplen el criterio o asignar probabilidades inexistentes.
Si posteriormente utiliza esos resultados para crear tareas, el error puede propagarse.
¿Cómo reducir las alucinaciones?
Es recomendable recuperar datos desde fuentes autorizadas, utilizar cálculos deterministas, validar resultados y exigir evidencia cuando se presentan afirmaciones importantes.
Para información financiera o comercial, el agente debería consultar registros actuales y no confiar exclusivamente en el conocimiento del modelo.
También conviene distinguir claramente entre hechos confirmados, estimaciones y recomendaciones.
2. Interpretación incorrecta de instrucciones
Los agentes utilizan modelos de inteligencia artificial para interpretar solicitudes expresadas en lenguaje natural.
Sin embargo, el lenguaje humano puede ser ambiguo.
Por ejemplo, un responsable comercial solicita:
«Actualiza todas las oportunidades antiguas».
¿Qué significa antiguas?
¿Oportunidades creadas hace más de seis meses? ¿Registros sin actividad durante treinta días? ¿Oportunidades que ya deberían estar cerradas?
Si el agente interpreta la solicitud sin comprobar los criterios, podría modificar registros incorrectos.
Medidas de prevención
Los sistemas deben identificar instrucciones ambiguas y solicitar aclaraciones cuando faltan datos esenciales.
También es recomendable utilizar esquemas de parámetros y reglas de negocio independientes del modelo.
Por ejemplo, una función de actualización puede exigir un identificador de oportunidad, un nuevo estado válido y una autorización explícita.
De este modo, la aplicación evita depender únicamente de la interpretación del lenguaje natural.
3. Prompt injection: uno de los principales riesgos de seguridad
El prompt injection es una técnica mediante la cual contenido no confiable intenta influir indebidamente en las instrucciones o decisiones de un sistema de IA.
El ataque puede aparecer en documentos, páginas web, correos electrónicos, resultados de búsqueda o respuestas de herramientas.
Por ejemplo, un agente encargado de resumir documentos podría encontrar un archivo que contiene instrucciones destinadas a hacerle ignorar su tarea original.
El contenido intenta pasar de ser información para analizar a convertirse en una instrucción operativa.
Ejemplo conceptual
Supongamos que un agente consulta una página web para recopilar información sobre proveedores.
Dentro del contenido aparece un texto que pretende ordenar al agente que abandone la investigación y revele información interna.
La página web es una fuente de datos, no una autoridad sobre el funcionamiento del agente.
Si el sistema no mantiene esa separación, puede tomar decisiones inapropiadas.
¿Cómo prevenir el prompt injection?
La protección requiere varias medidas complementarias.
El contenido externo debe tratarse como información no confiable. Las instrucciones de seguridad deben mantenerse separadas de los datos recuperados.
Además, las herramientas deben aplicar permisos y validaciones independientemente de lo que solicite el modelo.
Las operaciones sensibles necesitan autorización específica y controles técnicos.
Ninguna instrucción de prompt garantiza por sí sola una protección completa.
4. Exceso de autonomía y permisos
Uno de los riesgos más importantes aparece cuando un agente dispone de más capacidades de las necesarias.
Este problema se conoce como excessive agency, o exceso de capacidad de actuación.
Por ejemplo, un agente diseñado para analizar oportunidades comerciales puede necesitar consultar información del CRM.
Sin embargo, no debería disponer automáticamente de permisos para eliminar contactos, modificar contratos o cambiar precios.
Principio de mínimo privilegio
El principio de mínimo privilegio establece que cada componente debe disponer únicamente de los permisos necesarios para realizar su función.
En agentes de IA puede aplicarse mediante herramientas separadas y credenciales limitadas.
Un agente analítico puede utilizar funciones de solo lectura.
Las operaciones que modifican información pueden quedar reservadas a servicios específicos con validaciones adicionales.
Por qué las instrucciones no son suficientes
Una instrucción como «no elimines registros» ayuda a orientar al modelo, pero no debe considerarse un control de autorización.
La aplicación debe impedir técnicamente que una herramienta ejecute operaciones prohibidas.
El modelo puede proponer una acción; el servidor debe decidir si esa acción está permitida.
5. Divulgación de información confidencial
Los agentes empresariales pueden trabajar con información sensible.
Por ejemplo, datos personales, documentos comerciales, contratos, registros financieros o información interna de clientes.
Cuando un agente utiliza herramientas de búsqueda y bases de datos, existe el riesgo de recuperar información que no debería estar disponible para determinado usuario.
Ejemplo con varias organizaciones
Imaginemos una plataforma SaaS que presta servicios a distintas empresas.
Cada organización dispone de sus propios documentos y registros.
Si el sistema de recuperación no aplica correctamente los filtros de autorización, un agente podría acceder a documentos de otra empresa.
Esto representa un fallo de aislamiento entre organizaciones.
Controles recomendados
La aplicación debe autenticar al usuario, verificar los permisos de cada operación y aplicar restricciones de acceso en la capa de datos.
Los identificadores de usuario y organización deben proceder del contexto de autenticación del servidor.
No deben aceptarse simplemente porque el modelo los incluya en una llamada a una herramienta.
También conviene minimizar los datos enviados a modelos y servicios externos.
6. Ejecución de acciones incorrectas
Un agente puede interactuar con aplicaciones capaces de modificar información.
Por ejemplo, puede actualizar un registro, enviar una comunicación o crear una tarea.
Estas operaciones producen efectos que pueden ser difíciles de revertir.
Ejemplo de envío de correos
Un agente comercial genera una respuesta para un cliente.
Si dispone de permisos de envío automático, una dirección incorrecta o un contenido inadecuado puede provocar consecuencias comerciales o de privacidad.
Human-in-the-loop
Una estrategia útil consiste en incorporar revisión humana dentro del flujo de ejecución.
El agente prepara la operación y el sistema solicita aprobación antes de ejecutarla.
Por ejemplo, puede redactar un correo, pero no enviarlo hasta que una persona autorizada lo confirme.
Las acciones especialmente sensibles deben gestionarse mediante mecanismos de aprobación que verifiquen la identidad y los permisos del aprobador.
7. Errores acumulativos en procesos de varios pasos
Los agentes autónomos pueden utilizar un ciclo de ejecución para realizar varias operaciones consecutivas.
El agente consulta una herramienta, interpreta el resultado y selecciona la siguiente acción.
Si una etapa produce información incorrecta, el error puede influir en decisiones posteriores.
Ejemplo de análisis empresarial
Un agente recopila datos de ventas, calcula indicadores y genera un informe.
Si la primera consulta recupera un período incorrecto, los cálculos posteriores pueden ser técnicamente correctos pero producir conclusiones equivocadas.
Estrategias de reducción
Es recomendable validar los resultados en puntos importantes del proceso.
También pueden utilizarse esquemas estructurados, comprobaciones de coherencia y funciones deterministas.
En procesos críticos conviene registrar qué datos se utilizaron y qué herramientas participaron.
Esto facilita identificar el origen de los errores.
8. Consumo excesivo y costes inesperados
Los agentes de IA pueden generar costes asociados al uso de modelos, herramientas e infraestructura.
Un agente que realiza múltiples consultas puede consumir más recursos que una aplicación que genera una única respuesta.
Los costes pueden depender de factores como número de tokens, modelo seleccionado, llamadas a herramientas, almacenamiento y servicios externos.
¿Qué ocurre cuando un agente entra en un ciclo?
Un sistema mal configurado puede repetir consultas innecesarias o intentar resolver indefinidamente una tarea.
Esto puede incrementar el coste y la latencia.
Cómo controlar los costes
Los sistemas deberían establecer límites máximos de turnos, tiempos de ejecución, presupuestos y operaciones.
También conviene utilizar funciones tradicionales para tareas que no requieren un modelo de lenguaje.
Por ejemplo, calcular el importe de una factura mediante código es normalmente más predecible que solicitar el cálculo directamente a un LLM.
La optimización debe considerar tanto el coste por ejecución como el porcentaje de tareas completadas correctamente.
9. Privacidad y protección de datos
Los agentes pueden recopilar, consultar y almacenar información personal.
Esto introduce obligaciones relacionadas con la privacidad y, según el contexto, con normativas de protección de datos.
En empresas que operan dentro de la Unión Europea, el Reglamento General de Protección de Datos (RGPD) es especialmente relevante.
Entre las cuestiones que deben evaluarse se encuentran la finalidad del tratamiento, la minimización de datos, los períodos de conservación, la seguridad y los derechos de las personas.
Riesgos de la memoria persistente
Un agente con memoria puede conservar información entre sesiones.
Si almacena información innecesaria o desactualizada, aumenta el riesgo de privacidad.
Por ello, es recomendable definir políticas para seleccionar recuerdos, limitar su conservación y facilitar su eliminación.
Servicios externos
Cuando se utilizan APIs de modelos o proveedores de infraestructura, también deben evaluarse las condiciones contractuales, las ubicaciones de tratamiento de datos y las responsabilidades de cada proveedor.
La implementación técnica debe coordinarse con la evaluación jurídica y organizativa correspondiente.
10. Falta de observabilidad y auditoría
Una aplicación empresarial necesita comprender qué operaciones realiza el agente.
La observabilidad permite registrar herramientas utilizadas, resultados, errores y consumo de recursos.
Esto es especialmente importante cuando un agente ejecuta tareas de varios pasos.
¿Qué información conviene registrar?
Las trazas pueden incluir identificadores de ejecución, herramientas utilizadas, duración, estado final y errores.
Cuando es necesario, también pueden conservarse referencias a decisiones de aprobación.
Sin embargo, los registros deben evitar almacenar indiscriminadamente credenciales o información sensible.
La observabilidad debe diseñarse junto con los controles de privacidad.
¿Qué riesgos son más importantes según el tipo de agente?
Los riesgos cambian dependiendo de las capacidades disponibles.
| Tipo de agente | Riesgo especialmente relevante |
|---|---|
| Agente informativo | Respuestas incorrectas |
| Agente RAG | Recuperación de contenido malicioso o no autorizado |
| Agente CRM | Modificación incorrecta de registros |
| Agente de correo | Envío no autorizado |
| Agente de programación | Ejecución insegura de código |
| Agente financiero | Errores en cálculos u operaciones |
| Sistema multiagente | Propagación de errores y permisos |
| Agente autónomo prolongado | Costes, ciclos y pérdida de control |
Esta clasificación es orientativa. Un mismo agente puede presentar varios riesgos simultáneamente.
¿Cómo diseñar una arquitectura segura de agentes de IA?
Una arquitectura empresarial debe separar las decisiones propuestas por el modelo de las operaciones ejecutadas por el sistema.
El modelo puede seleccionar una herramienta, pero la aplicación debe comprobar que la operación esté autorizada.
Capa de autenticación
Identifica al usuario que solicita la operación.
Capa de autorización
Comprueba si el usuario y el agente disponen de permisos suficientes.
Capa de herramientas
Expone únicamente las funciones necesarias y valida sus argumentos.
Capa de ejecución
Aplica límites de tiempo, recursos y número de operaciones.
Capa de aprobación
Detiene las acciones sensibles hasta recibir autorización.
Capa de datos
Protege la información mediante controles de acceso, cifrado cuando corresponda y aislamiento entre organizaciones.
Capa de observabilidad
Registra los eventos relevantes para investigar errores y analizar el rendimiento.
Estas capas permiten desarrollar sistemas más controlables que aquellos que dependen exclusivamente de instrucciones escritas en un prompt.
Ejemplo práctico: proteger un agente conectado a un CRM
Imaginemos una empresa que desea utilizar un agente para analizar oportunidades comerciales.
El agente necesita consultar contactos, revisar actividades y preparar recomendaciones.
Podemos implementar tres niveles de control.
Primer nivel: lectura autorizada. El agente consulta oportunidades mediante una función que devuelve exclusivamente los registros accesibles para el usuario.
Segundo nivel: preparación de cambios. Si el agente considera necesario actualizar una oportunidad, genera una propuesta estructurada.
Tercer nivel: autorización. Un servicio verifica los permisos y, cuando corresponde, solicita aprobación antes de ejecutar la modificación.
De este modo, el agente puede proporcionar recomendaciones útiles sin disponer de acceso ilimitado al CRM.
¿Cómo evaluar los riesgos antes del despliegue?
Las empresas deberían realizar una evaluación de riesgos antes de incorporar agentes a procesos importantes.
El análisis comienza identificando las tareas, los datos utilizados y las acciones disponibles.
Después se estudian los posibles errores y sus consecuencias.
Por ejemplo, una respuesta incorrecta sobre un producto puede tener un impacto limitado.
En cambio, una operación financiera no autorizada puede producir consecuencias importantes.
También deben evaluarse la probabilidad del problema, los controles disponibles y el riesgo residual.
El marco NIST AI Risk Management Framework propone abordar estos desafíos mediante funciones de gobernanza, identificación, medición y gestión de riesgos.
¿Qué métricas permiten medir la seguridad y fiabilidad de un agente?
La evaluación debe incluir indicadores operativos y de seguridad.
| Métrica | Objetivo |
|---|---|
| Tasa de finalización | Medir tareas completadas correctamente |
| Precisión de resultados | Detectar respuestas incorrectas |
| Errores de herramientas | Identificar fallos operativos |
| Acciones bloqueadas | Medir intentos de operaciones no autorizadas |
| Incidentes de privacidad | Detectar accesos o divulgaciones indebidas |
| Coste por tarea | Controlar el consumo |
| Latencia | Evaluar el rendimiento |
| Intervenciones humanas | Medir necesidades de supervisión |
| Recuperación de errores | Evaluar continuidad operativa |
Las métricas deben definirse antes del despliegue y revisarse durante el funcionamiento.
Buenas prácticas para implementar agentes de IA seguros
Antes de poner un agente en producción, conviene establecer una serie de controles mínimos.
- Definir claramente qué problema debe resolver.
- Utilizar el menor número posible de herramientas.
- Aplicar permisos mínimos y separación entre usuarios.
- Validar los argumentos y resultados de herramientas.
- Tratar documentos y contenidos externos como información no confiable.
- Incorporar aprobación humana para acciones sensibles.
- Limitar los turnos, tiempos y costes de ejecución.
- Registrar eventos y errores relevantes.
- Realizar pruebas con entradas ambiguas y maliciosas.
- Supervisar el comportamiento y actualizar los controles cuando cambien los riesgos.
Estos principios permiten reducir problemas previsibles, aunque no eliminan completamente la posibilidad de fallos.
Preguntas frecuentes sobre los riesgos de los agentes de IA
¿Cuáles son los principales riesgos de los agentes de inteligencia artificial?
Los principales riesgos incluyen alucinaciones, interpretación incorrecta, prompt injection, acceso excesivo, errores de ejecución, divulgación de información, costes inesperados y problemas de privacidad.
¿Qué es prompt injection en agentes de IA?
Es una técnica mediante la cual contenido no confiable intenta modificar indebidamente las instrucciones o acciones de un sistema de inteligencia artificial.
¿Los agentes de IA pueden modificar datos sin autorización?
Un sistema mal diseñado podría permitirlo. Por ello, las operaciones deben protegerse mediante controles técnicos de autenticación, autorización y validación.
¿Qué significa excessive agency?
Describe situaciones en las que un sistema basado en IA dispone de demasiadas capacidades, permisos o autonomía para realizar la tarea asignada.
¿Cómo evitar alucinaciones en agentes de IA?
No existe un mecanismo que garantice eliminarlas completamente. Sin embargo, recuperar información autorizada, utilizar cálculos verificables y validar resultados puede reducir su impacto.
¿Es obligatorio supervisar todos los agentes?
No todas las operaciones necesitan aprobación humana individual. El nivel de supervisión debe depender del riesgo de las acciones.
¿Los sistemas multiagente son más seguros?
No necesariamente. La especialización puede facilitar la separación de permisos, pero la coordinación también introduce nuevos riesgos de comunicación y propagación de errores.
¿Qué es human-in-the-loop?
Es un mecanismo que incorpora intervención humana en determinados puntos del proceso, especialmente antes de ejecutar operaciones sensibles.
¿Cómo controlar los costes de un agente?
Mediante límites de turnos, presupuestos, monitorización del consumo y selección adecuada de modelos y herramientas.
¿Puede una pequeña empresa implementar agentes de IA seguros?
Sí, siempre que seleccione aplicaciones proporcionadas a sus recursos, establezca permisos apropiados y pruebe el sistema antes de permitir operaciones importantes.
Conclusión
Los agentes de inteligencia artificial ofrecen nuevas posibilidades para automatizar procesos empresariales y desarrollar aplicaciones capaces de trabajar con herramientas y datos.
Sin embargo, también presentan limitaciones que deben comprenderse antes de su implementación.
Los errores de interpretación, las alucinaciones, los ataques de prompt injection y los permisos excesivos pueden afectar a la seguridad y la fiabilidad.
Además, la ejecución autónoma introduce desafíos relacionados con costes, supervisión, privacidad y auditoría.
La solución no consiste en evitar la inteligencia artificial, sino en diseñar arquitecturas que mantengan el control sobre sus acciones.
Esto requiere combinar modelos de IA con buenas prácticas de ingeniería de software, autenticación, autorización, validación, observabilidad y evaluación continua.
Un agente de IA empresarial no debe medirse únicamente por lo que es capaz de hacer, sino también por lo que puede hacer de forma segura, correcta y controlada.
En Agentes y Automatización continuaremos explorando cómo diseñar y desarrollar sistemas inteligentes que aporten valor real a las empresas sin comprometer la seguridad y la fiabilidad de sus procesos.
Anexo técnico: controles de seguridad para un agente desarrollado con Python
Una medida fundamental consiste en impedir que el modelo ejecute directamente operaciones sensibles.
La documentación oficial del OpenAI Agents SDK distingue entre controles automáticos (guardrails) y aprobaciones humanas. Los primeros permiten validar entradas, salidas y herramientas; las segundas permiten detener una ejecución antes de realizar una acción sensible.
Ejemplo: validar una operación de actualización del CRM
El siguiente código ilustra cómo separar las propuestas de un agente de los permisos efectivos del usuario.
from dataclasses import dataclass
ESTADOS_PERMITIDOS = {
"nuevo",
"contactado",
"en_negociacion",
"cerrado"
}
@dataclass(frozen=True)
class Usuario:
id: int
organization_id: int
permisos: frozenset[str]
def validar_actualizacion(
usuario: Usuario,
oportunidad: dict,
nuevo_estado: str,
aprobado: bool
) -> dict:
"""
Valida una actualización antes
de ejecutar cambios en el CRM.
"""
if "crm:update" not in usuario.permisos:
raise PermissionError(
"El usuario no tiene permisos"
)
if (
oportunidad["organization_id"]
!= usuario.organization_id
):
raise PermissionError(
"Acceso a otra organización"
)
if nuevo_estado not in ESTADOS_PERMITIDOS:
raise ValueError(
"Estado comercial no válido"
)
if not aprobado:
return {
"status": "pending_approval",
"opportunity_id": oportunidad["id"],
"proposed_status": nuevo_estado
}
return {
"status": "validated",
"opportunity_id": oportunidad["id"],
"new_status": nuevo_estado
}
usuario = Usuario(
id=10,
organization_id=100,
permisos=frozenset({"crm:update"})
)
oportunidad = {
"id": 250,
"organization_id": 100,
"estado": "nuevo"
}
resultado = validar_actualizacion(
usuario,
oportunidad,
nuevo_estado="contactado",
aprobado=False
)
print(resultado)
El ejemplo comprueba los permisos, el ámbito de organización, el estado solicitado y la condición de aprobación.
No modifica ninguna base de datos: únicamente devuelve una decisión de validación.
En producción, la autorización y la aprobación deben comprobarse mediante información verificada en el servidor. No debe permitirse que el modelo establezca libremente el valor aprobado=True.
También sería necesario comprobar que el registro existe, que pertenece realmente a la organización, que la transición de estado está permitida y que la aprobación corresponde a la operación exacta solicitada. La actualización definitiva debería realizarse mediante una transacción segura, evitando ejecuciones duplicadas.