Volver a Sala de Prensa
Tendencias

Tu próximo empleado puede ser un agente de IA: pero ¿a qué debería tener acceso?

K&J Open Solutions 7 de septiembre de 2026 4 min de lectura
Tu próximo empleado puede ser un agente de IA: pero ¿a qué debería tener acceso?

Tu próximo empleado puede ser un agente de IA: pero ¿a qué debería tener acceso?

Un agente de inteligencia artificial ya no se limita a responder preguntas. Puede consultar clientes en un CRM, preparar presupuestos, revisar inventario, organizar reuniones, redactar correos y actualizar registros. En otras palabras, empieza a trabajar dentro de la empresa.

La pregunta importante, por tanto, no es solo qué modelo utilizar. Es qué puede ver el agente, qué acciones puede ejecutar y quién responde cuando se equivoca.

En 2026, este asunto ocupa un lugar central en cualquier proyecto de automatización empresarial. La referencia publicada por OWASP para aplicaciones agénticas identifica el abuso de identidad y privilegios, el uso indebido de herramientas y la manipulación del comportamiento entre los principales riesgos de estos sistemas. La seguridad debe diseñarse antes de conectar el agente con datos reales, no después del primer incidente.

Un agente de IA debe tener identidad propia

El error más habitual consiste en conectar el agente utilizando la cuenta personal de un administrador o una clave de API compartida. Esto dificulta saber quién hizo qué y puede conceder acceso a funciones que el agente nunca debería utilizar.

Un agente empresarial necesita una identidad digital diferenciada, igual que un empleado dispone de su propia cuenta. Esa identidad debe tener un propietario de negocio, una finalidad documentada, permisos concretos y una fecha de revisión o caducidad.

Las plataformas de gestión de identidades ya están avanzando en esta dirección. Microsoft Entra, por ejemplo, incorporó identidades específicas para agentes, diferenciando entre el acceso autónomo y el acceso delegado en nombre de una persona. Este modelo permite aplicar políticas, registrar la actividad y desactivar al agente sin afectar a las cuentas humanas.

La ficha mínima de cada agente debería indicar:

  • Nombre y función empresarial.
  • Departamento y responsable humano.
  • Sistemas a los que puede conectarse.
  • Datos que puede consultar o modificar.
  • Acciones que requieren aprobación.
  • Credenciales, tokens y fecha de rotación.
  • Canal para detenerlo o revocar sus accesos.

El mínimo privilegio también se aplica a la IA

El principio de mínimo privilegio establece que una identidad solo debe recibir los permisos estrictamente necesarios para desempeñar su función. La arquitectura Zero Trust de NIST añade otra idea esencial: no debe existir confianza implícita por encontrarse dentro de la red corporativa.

En un agente de IA conviene aplicar este principio en cuatro dimensiones:

  • Datos: qué clientes, expedientes, tablas o documentos puede consultar.
  • Acciones: si puede leer, crear, modificar, aprobar, enviar o eliminar.
  • Contexto: en qué horarios, procesos, departamentos o países puede actuar.
  • Impacto: qué importes, volúmenes o niveles de riesgo puede gestionar sin intervención.

No basta con conceder acceso al CRM. Hay que distinguir entre consultar una oportunidad, cambiar su estado, aplicar un descuento o eliminar el historial del cliente. Son operaciones con consecuencias muy diferentes.

Qué acceso debería tener en cada herramienta

Sistema Acceso inicial recomendable Acciones que deberían controlarse
CRM Consultar contactos asignados, resumir interacciones y crear borradores de tareas. Cambiar propietarios, exportar bases completas, borrar registros o modificar descuentos.
ERP Leer stock, estados de pedidos, facturas y datos operativos necesarios. Crear pagos, modificar cuentas bancarias, aprobar compras o alterar asientos.
Correo Buscar mensajes autorizados, clasificarlos y preparar respuestas en borrador. Enviar a destinatarios externos, reenviar adjuntos sensibles o borrar conversaciones.
Calendario Consultar disponibilidad y proponer reuniones. Cancelar citas, invitar a externos o acceder a detalles confidenciales.
Bases de datos Consultas de solo lectura mediante vistas limitadas. Ejecutar consultas libres, actualizar datos, cambiar esquemas o realizar borrados masivos.

Este diseño evita permisos binarios del tipo “acceso permitido” o “acceso denegado”. El acceso debe expresarse mediante capacidades pequeñas, específicas y revocables.

Leer, proponer y ejecutar no son la misma acción

Una forma sencilla de desplegar agentes con seguridad es separar tres niveles de autonomía.

Nivel 1: observar y recomendar

El agente consulta información y genera una recomendación, pero no cambia ningún sistema. Puede detectar oportunidades sin seguimiento, resumir incidencias o proponer fechas de reunión. Es el nivel adecuado para comenzar una prueba controlada.

Nivel 2: preparar y solicitar aprobación

El agente crea un borrador o prepara una transacción. Una persona revisa el destinatario, los datos y el impacto antes de aprobarla. Por ejemplo, puede redactar un correo comercial, pero no enviarlo; o preparar un pedido en el ERP, pero no confirmarlo.

Nivel 3: ejecutar dentro de límites

El agente actúa de forma autónoma cuando se cumplen reglas predefinidas. Puede confirmar una reunión interna, actualizar el estado de una oportunidad o responder una consulta frecuente, siempre que no se superen ciertos límites.

La autonomía debería ganarse con resultados observables. Primero se trabaja en modo lectura, después con aprobación y, finalmente, se automatizan las operaciones repetitivas que hayan demostrado un comportamiento estable.

La aprobación humana debe depender del riesgo

Pedir autorización para cada paso elimina buena parte del valor de la automatización. No pedirla nunca crea una exposición innecesaria. La solución es utilizar aprobaciones basadas en riesgo.

Un agente puede actuar sin intervención cuando la operación sea reversible, de bajo impacto y esté dentro de parámetros conocidos. La aprobación debe ser obligatoria cuando exista movimiento de dinero, acceso a información especialmente sensible, comunicación externa relevante, borrado de datos o una excepción a las políticas.

Imaginemos un agente de ventas conectado al CRM y al correo. Puede detectar que una oportunidad lleva siete días sin actividad y preparar un mensaje. Si el destinatario ya existe, no hay adjuntos y se utiliza una plantilla aprobada, podría enviarlo automáticamente. Si aparece un nuevo dominio, una petición de descuento o documentación confidencial, debe detenerse y solicitar revisión.

La pantalla de aprobación no debería mostrar únicamente un botón. Debe explicar qué acción se ejecutará, con qué datos, sobre qué sistema, por qué la propone el agente y si puede revertirse.

Credenciales temporales en lugar de llaves permanentes

Las claves de API amplias y sin caducidad resultan especialmente peligrosas: pueden copiarse, filtrarse o seguir activas después de retirar el agente. Siempre que la plataforma lo permita, conviene utilizar tokens de corta duración, permisos asociados a una identidad y credenciales gestionadas por un almacén de secretos.

Además, cada token debería estar limitado a un recurso concreto. La documentación de acceso condicional de Microsoft Entra recuerda que una clave de API puede eludir el proceso de emisión de tokens y sus políticas asociadas. Es una buena razón para evitar credenciales estáticas como mecanismo principal.

También deben establecerse límites de frecuencia, volumen y coste. Un agente que normalmente consulta veinte clientes no debería poder exportar cien mil registros sin activar una alerta.

Auditar significa poder reconstruir cada decisión

Un registro útil debe responder quién, qué, cuándo, dónde y por qué. Para cada operación conviene guardar la identidad del agente, el usuario que inició la tarea, la herramienta utilizada, los permisos aplicados, los datos consultados, la acción propuesta, el resultado y la aprobación humana, si existió.

El objetivo no es almacenar indiscriminadamente todas las conversaciones. Los registros pueden contener datos personales, secretos o información contractual. Es necesario aplicar retención limitada, cifrado, controles de acceso y enmascaramiento de campos sensibles.

Las alertas deberían detectar patrones como intentos repetidos de acceder a recursos denegados, exportaciones anómalas, cambios masivos, uso fuera de horario o llamadas a herramientas no habituales. La auditoría sirve para investigar, pero también para intervenir mientras la actividad todavía está ocurriendo.

El correo y los documentos deben tratarse como entradas no fiables

Un agente puede recibir instrucciones manipuladas dentro de un correo, una web o un documento. Este fenómeno, conocido como inyección indirecta de prompts, puede intentar convencerlo de que ignore sus reglas, revele información o utilice otra herramienta.

OWASP recomienda limitar las extensiones, funciones y permisos del agente, validar sus acciones y ejecutar las operaciones en el contexto autorizado del usuario. Su guía sobre agencia excesiva utiliza precisamente el ejemplo de un correo malicioso que intenta provocar el reenvío de información sensible.

La defensa no puede depender únicamente de que el modelo “se comporte bien”. Las instrucciones obtenidas desde fuentes externas deben considerarse datos, no órdenes. La autorización final debe aplicarse fuera del modelo, en una capa técnica que compruebe permisos y políticas antes de ejecutar cada herramienta.

Un plan de implantación en seis pasos

  1. Definir una tarea concreta: empezar con un proceso acotado y medible, no con un asistente que pueda hacerlo todo.
  2. Inventariar sistemas y datos: identificar cada CRM, ERP, buzón, calendario, base de datos y servicio externo implicado.
  3. Crear una matriz de permisos: documentar qué puede leer, proponer, ejecutar o eliminar.
  4. Separar identidades: asignar una identidad propia, credenciales temporales y un responsable de negocio.
  5. Probar escenarios adversos: incluir instrucciones ambiguas, documentos manipulados, datos incompletos y acciones fuera de límite.
  6. Revisar continuamente: analizar registros, falsos positivos, excepciones y permisos que ya no sean necesarios.

También conviene disponer de un interruptor de emergencia que permita revocar credenciales y detener ejecuciones pendientes sin depender del propio agente.

Qué está cambiando en 2026

Los agentes están empezando a gestionarse como identidades de primera clase, con inventario, patrocinador humano, ciclo de vida y políticas heredables. Esta evolución permite pasar de integraciones aisladas a un gobierno centralizado de agentes.

Al mismo tiempo, OWASP Top 10 for Agentic Applications 2026 ofrece un lenguaje común para riesgos específicos como el secuestro de objetivos, el abuso de herramientas, los privilegios excesivos y el envenenamiento de memoria o contexto.

En Europa, desde el 2 de agosto de 2026 se aplican nuevas obligaciones de transparencia para determinados sistemas de IA y comenzaron nuevas funciones de supervisión y ejecución del Reglamento de IA. La Comisión Europea mantiene un calendario diferenciado para varios usos de alto riesgo, pero sus principios de trazabilidad, supervisión humana, robustez y gestión del riesgo ya ofrecen una referencia útil para cualquier empresa.

Tres preguntas antes de abrir la puerta

¿Puede un agente utilizar la cuenta de un empleado?

Técnicamente es posible, pero reduce la trazabilidad y suele ampliar los permisos. Es preferible una identidad independiente o una delegación limitada que conserve el contexto del usuario.

¿Cuándo puede enviar correos automáticamente?

Cuando los destinatarios, plantillas, datos y circunstancias estén claramente delimitados. Los mensajes sensibles, excepcionales o dirigidos a nuevos contactos deberían requerir aprobación.

¿Es suficiente registrar las acciones finales?

No. Para comprender un incidente también hacen falta la identidad, los permisos, la herramienta, el origen de la solicitud, la decisión adoptada y la intervención humana.

El mejor agente empresarial no es el que dispone de más acceso, sino el que puede completar una tarea útil con el menor margen de actuación posible. En K&J Open Solutions ayudamos a diseñar e integrar automatizaciones con IA conectadas a los sistemas reales de la empresa, incorporando permisos, supervisión y trazabilidad desde el inicio. Ese diseño es el que convierte una demostración atractiva en una herramienta de negocio fiable.

agentes-de-ia seguridad-ia automatizacion-empresarial minimo-privilegio gobierno-de-datos transformacion-digital

¿Necesitas ayuda con tu proyecto?

Nuestro equipo de expertos está listo para ayudarte a alcanzar tus objetivos digitales.

Contactar ahora

Soporte K&J

Respuesta inmediata

👋 ¡Hola! ¿En qué puedo ayudarte hoy?