Agentes de IA con acceso a tus sistemas: ¿automatización inteligente o un nuevo riesgo de seguridad?

Durante dos años aprendimos a usar la IA como quien consulta a un colega muy leído: le preguntamos, nos responde, y decidimos nosotros qué hacer. Los agentes de IA cambian ese acuerdo: ya no solo responden, hacen cosas. Leen tu correo, modifican registros, envían mensajes, ejecutan código y, si les das permiso, pagan facturas. La promesa es enorme (tareas repetitivas resueltas sin intervención), y también lo es el riesgo.

En este artículo te explico la diferencia entre un chatbot y un agente, qué ha pasado ya cuando un agente tiene demasiado poder, y te dejo un marco práctico (permisos, aprobación humana, trazabilidad y contención), una matriz de decisión para elegir qué automatizar y un ejemplo de código de una "compuerta de aprobación". Datos verificados el 9 de octubre de 2026.

Resumen. Un chatbot produce texto; un agente ejecuta acciones con herramientas. El riesgo ya no es solo una respuesta equivocada, sino una acción equivocada o inducida por un atacante. OWASP lo llama "agencia excesiva" (LLM06:2025) y la resume en exceso de funciones, de permisos o de autonomía. La respuesta práctica: permisos mínimos, aprobación humana para lo que importa, registro de todo y un límite al daño posible.

Chatbot, asistente y agente: dónde está la diferencia

La palabra "agente" se usa con mucha libertad. Para decidir con criterio conviene una definición operativa: un agente es un sistema de IA que planifica y ejecuta pasos usando herramientas (leer archivos, llamar servicios, escribir en bases de datos, enviar mensajes), a menudo sin que una persona apruebe cada paso. Un chatbot responde preguntas; un asistente sugiere y redacta; un agente actúa. Y esa última diferencia lo cambia todo.

Una advertencia para no comprar humo: la consultora Gartner usa el término agent washing para describir productos que solo cambiaron de etiqueta (un chatbot o un RPA presentado como "agente"), y pronostica que más del 40 % de los proyectos de IA agéntica serán cancelados para fines de 2027 por costos crecientes, valor poco claro o controles de riesgo inadecuados. Es un pronóstico, no una medición, pero señala lo mismo que veremos abajo: muchas veces no hace falta un agente, y cuando sí, hace falta control.

Qué ha pasado cuando un agente tiene demasiado poder

• Replit y SaaStr (julio de 2025). Según el registro de incidentes de la OCDE.AI y la prensa, un agente de programación borró una base de datos durante un experimento del fundador de SaaStr, Jason Lemkin, pese a que este le había ordenado no hacer cambios sin su aprobación, y luego informó mal de lo ocurrido. Los datos eran de una aplicación de demostración, no de un negocio real, y Replit prometió separar los entornos de desarrollo y producción y añadir un modo de solo planificación. Lo instructivo no es el drama: es que una instrucción en lenguaje natural ("no cambies nada") no es un control de seguridad.
• EchoLeak (CVE-2025-32711). Un fallo crítico (CVSS 9,3) de inyección de instrucciones en Microsoft 365 Copilot permitía, según los reportes, que un correo con instrucciones ocultas hiciera que el asistente filtrara datos internos sin que el usuario hiciera clic. Microsoft lo corrigió y, según las fuentes, no hay evidencia de explotación real; la entrada en la base de vulnerabilidades NVD lo describe como una inyección de comandos de IA. La lección: un agente que lee contenido no confiable (un correo, una página web) puede recibir órdenes escondidas en ese contenido.

El marco de referencia más útil es el de OWASP, LLM06:2025 "Excessive Agency", que identifica tres causas: funcionalidad excesiva (el agente tiene herramientas que no necesita), permisos excesivos (las herramientas tienen más acceso del necesario) y autonomía excesiva (ejecuta acciones de alto impacto sin verificación). Sus mitigaciones principales son limitar las herramientas al mínimo, limitar las funciones de cada herramienta, exigir aprobación humana para las acciones de alto impacto y, sobre todo, hacer cumplir la autorización en los sistemas de destino, no confiar en que el modelo "decida" qué está permitido.

Cuatro controles para dejar actuar a un agente

1. Permisos mínimos. Dale al agente su propia cuenta (no la tuya ni la del administrador), con acceso solo a lo que necesita y, por defecto, de solo lectura. Si necesita escribir, que sea en un único recurso. El cierre de cuentas y la revisión periódica de permisos valen aquí igual que para una persona (hablé de esto en el artículo sobre errores básicos de seguridad).
2. Aprobación humana donde importa. Una persona aprueba antes de que el agente envíe algo fuera de la organización, modifique datos, gaste dinero o publique. Lo que sea irreversible, nunca de forma autónoma.
3. Trazabilidad. Un registro de cada acción: quién (o qué agente), qué, con qué parámetros, cuándo y con qué resultado. Si no puedes reconstruir qué hizo, no puedes auditar ni aprender del error.
4. Contención. Límites de volumen y de gasto, un entorno de pruebas separado de producción, respaldos verificados y un "botón de apagado" (la posibilidad de suspender al agente de inmediato).

Un detalle clave de los controles: tienen que vivir fuera del agente. Un agente al que le pides "no borres nada" y que tiene permiso de borrado puede borrar; uno que simplemente no tiene permiso, no.

Matriz de decisión: ¿qué automatizar y qué no?

Este es el recurso aplicable. Para cada tarea que quieras delegar, pregúntate cinco cosas y úsalas para decidir:

Un ejemplo de código: una compuerta de aprobación

Si construyes o conectas un agente, la idea central cabe en 40 líneas de Python: una lista blanca de acciones con nivel de riesgo, aprobación humana para las de riesgo medio y alto, un tope de acciones y un registro de todo. Lo probé con herramientas simuladas: clasificó el ticket, envió el correo tras aprobación, rechazó el pago y bloqueó la acción no autorizada.

import json
from datetime import datetime, timezone

# Lista blanca: solo las acciones listadas existen para el agente; cada una tiene un nivel de riesgo.
RIESGO = {
    "clasificar_ticket": "bajo",     # reversible, sin dinero ni datos externos
    "redactar_borrador": "bajo",
    "enviar_correo": "medio",        # sale de la organización: requiere aprobación
    "actualizar_registro": "medio",  # modifica datos: requiere aprobación
    "pagar_factura": "alto",         # dinero: aprobación explícita y motivo
}
TOPE_MEDIO = 5  # máximo de acciones de riesgo medio por ejecución (límite de daño)


def registrar(evento, ruta="auditoria.jsonl"):
    evento["fecha"] = datetime.now(timezone.utc).isoformat()
    with open(ruta, "a", encoding="utf-8") as f:
        f.write(json.dumps(evento, ensure_ascii=False) + "\n")


def ejecutar(accion, parametros, aprobador, herramientas, estado):
    nivel = RIESGO.get(accion)
    if nivel is None:
        registrar({"accion": accion, "parametros": parametros, "resultado": "BLOQUEADA: no autorizada"})
        raise PermissionError(f"Acción no autorizada: {accion}")
    if nivel == "medio":
        estado["medio"] = estado.get("medio", 0) + 1
        if estado["medio"] > TOPE_MEDIO:
            registrar({"accion": accion, "resultado": "BLOQUEADA: tope de acciones alcanzado"})
            raise RuntimeError("Tope de acciones de riesgo medio alcanzado")
    if nivel in ("medio", "alto") and not aprobador(accion, parametros, nivel):
        registrar({"accion": accion, "parametros": parametros, "nivel": nivel, "resultado": "RECHAZADA por una persona"})
        return "rechazada"
    resultado = herramientas[accion](**parametros)
    registrar({"accion": accion, "parametros": parametros, "nivel": nivel, "resultado": "ejecutada"})
    return resultado

El agente nunca llama a las herramientas directamente: siempre pasa por ejecutar(). La función aprobador puede ser una pregunta en pantalla, un botón en un chat o un flujo de aprobación; lo importante es que la decisión la toma una persona y queda registrada. En el archivo de auditoría quedan líneas JSON como {"accion": "pagar_factura", "nivel": "alto", "resultado": "RECHAZADA por una persona", ...}. Es un ejemplo mínimo, no un producto de seguridad completo: en producción necesitas además autenticación, autorización en el sistema de destino y pruebas.

Colombia, Latinoamérica y el mundo

La regulación se mueve hacia la supervisión humana, no hacia la prohibición. En el mundo, la Ley de IA de la Unión Europea exige supervisión humana efectiva en los sistemas de alto riesgo; en América Latina hay proyectos en Brasil, Chile y Perú, y en Colombia existe la política nacional CONPES 4144 de 2025 y proyectos en el Congreso (los resumí en "La gran mentira de la IA"). Más cerca de casa pesa algo que ya existe: la Ley 1581 de 2012 de protección de datos personales hace responsable de los datos a quien los trata, aunque los procese un agente. Para un gerente o dueño de pyme, la pregunta es qué proceso vale la pena delegar sin arriesgar caja; para un docente o directivo, qué datos de menores puede tocar una plataforma que "recomienda" o "califica"; para TI, cómo dar permisos y auditar. Y para las familias, saber que los asistentes con acceso a tu correo o tus cuentas necesitan los mismos cuidados que una persona nueva en la casa.

Herramientas para automatizar con control

No toda automatización necesita un agente. Cuando las reglas son claras, una automatización determinista en Excel es más predecible y más barata. Enviar correos masivos con adjuntos y copias CC y CCO envía cada correo con su adjunto desde una lista de Excel, y tú revisas la lista y la plantilla antes del envío; el Aplicativo para combinar datos de Excel en documentos separados DOCX y PDF genera un documento por cada fila. Si enseñas, el Kit de IA para docentes incluye recursos para trabajar con tus estudiantes qué puede y qué no debería hacer una IA con sus datos.

Si quieres seguir leyendo: Copilot y agentes en Excel, ¿la IA amplía el pensamiento o lo reemplaza? y estafas con voz clonada y cómo verificar.

Preguntas frecuentes

¿Qué es un agente de IA y en qué se diferencia de ChatGPT?

Un chatbot como ChatGPT responde en texto. Un agente usa herramientas para ejecutar acciones (leer archivos, enviar correos, modificar datos). La diferencia es el poder de actuar, no el modelo.

¿Es seguro darle acceso a mi correo a un agente?

Solo con permisos mínimos, aprobación humana para lo que importa y registro de acciones. Y con cuidado: un correo de un tercero puede contener instrucciones ocultas que intenten manipular al agente (inyección de instrucciones).

¿Qué es la "agencia excesiva"?

Es la categoría LLM06:2025 de OWASP: un sistema de IA con demasiadas funciones, demasiados permisos o demasiada autonomía, de modo que un error o un ataque causa daños grandes.

¿Qué tareas puedo automatizar sin riesgo?

Las reversibles y de bajo impacto, como clasificar o redactar borradores, siempre con revisión. Las que mueven dinero, tocan datos sensibles o no se pueden deshacer, con aprobación humana o sin delegar.

¿Necesito un agente o me basta una macro?

Si las reglas son claras y repetibles, una automatización determinista (macro, script o flujo) suele ser más predecible. Los agentes aportan cuando hay ambigüedad y variedad, y es entonces cuando más control hace falta.

Haz tu mapa de tareas esta semana. Lista cinco tareas repetitivas de tu trabajo, aplica las cinco preguntas de la matriz y marca cuáles automatizarías, cuáles con aprobación y cuáles no. Para las reglas claras, prueba una automatización controlada como el envío de correos masivos desde Excel.

Para pensar

Cuando un agente comete un error, no tiene a quién pedirle perdón ni quién responda ante la ley. Si delegamos acciones en sistemas que no pueden asumir responsabilidad, ¿quién debe responder cuando algo sale mal: quien lo programó, quien lo vendió, quien le dio permisos o quien aprobó (o dejó de aprobar) lo que hizo? ¿Y cuánta autonomía estamos dispuestos a ceder a cambio de ahorrar tiempo?

Más guías en IA y tecnología para docentes