Agentes de IA para empresas: 10 controles antes de conectarlos

La demostración dura cinco minutos. Un agente abre el correo, identifica una consulta de un cliente, busca su ficha en el CRM y prepara una respuesta. Después actualiza el estado de la oportunidad y propone una reunión en el calendario. Todo parece ordenado, rápido y bastante convincente.

Pero entre «preparar una respuesta» y «enviarla» hay un cambio importante. También lo hay entre consultar una ficha y modificarla, o entre sugerir una fecha y reservarla en nombre de la empresa. La tecnología puede ser la misma; lo que cambia es el permiso y la consecuencia del error.

Ese matiz suele perderse cuando se habla de agentes de IA para empresas como si fueran empleados digitales que trabajan solos. Un agente no necesita acceso a todo para resultar útil. De hecho, cuanto más concreto sea el proceso y más limitado el acceso inicial, más fácil será comprobar si aporta valor sin exponer datos o ejecutar acciones difíciles de revertir.

Antes de conectarlo al correo, al CRM, a los archivos o a una base de datos, conviene responder diez preguntas. No sustituyen una evaluación técnica, jurídica o de protección de datos cuando sea necesaria. Sí ayudan a evitar el error más habitual: conceder autonomía antes de haber definido el proceso.

La pregunta útil no es «¿qué puede hacer el agente?».

Es «¿qué puede ver, proponer y cambiar, con qué límites y bajo la responsabilidad de quién?».

Regla práctica para agentes de IA para empresas: empezar con el permiso mínimo que permita comprobar utilidad y ampliar solo cuando los resultados aporten evidencia suficiente.

Índice

Qué es un agente de IA y en qué se diferencia de un chatbot
Diez controles antes de conectar agentes de IA a la empresa
RGPD y AI Act
Ejemplo: un agente para gestionar correos
Señales de que la empresa todavía no está preparada
Preguntas frecuentes
Primero control, después autonomía

Qué es un agente de IA y en qué se diferencia de un chatbot

Un chatbot conversa y genera contenido a partir de una petición. Un asistente puede, además, recuperar información o ayudar a una persona dentro de una aplicación. Un agente da un paso más: recibe un objetivo, selecciona herramientas, encadena acciones y puede actuar sobre sistemas externos.

La frontera no siempre es nítida. Un producto que hoy se presenta como asistente puede enviar correos, consultar un CRM o crear tareas. Otro puede llamarse agente y limitarse a producir un borrador. Para una empresa, la etiqueta comercial importa menos que las capacidades reales.

Hay tres niveles que conviene separar desde el principio:

Consultar: acceder a información y mostrarla.
Proponer: preparar una clasificación, un borrador o una acción para que alguien la apruebe.
Ejecutar: modificar un sistema, comunicarse con terceros o iniciar una operación.

Cada nivel cambia el riesgo. También cambia la evidencia que necesitamos para confiar en el sistema.

Diez controles antes de conectar agentes de IA a la empresa

1. Define una tarea concreta y un resultado aceptable

«Ayudar al equipo comercial» no es un caso de uso. «Clasificar correos entrantes y preparar un borrador de respuesta para consultas sobre disponibilidad» sí lo es.

Una tarea bien definida debería indicar:

quién es responsable del proceso;
qué información recibe el agente;
qué resultado debe producir;
cómo se comprueba la calidad;
qué situaciones quedan fuera;
qué coste tendría un error;
cuándo debe detenerse el piloto.

No todas las excepciones pueden anticiparse, pero las más previsibles sí. Si el agente gestiona consultas comerciales, una reclamación, una solicitud de ejercicio de derechos o un mensaje con documentación sensible deberían salir del flujo automático.

2. Dibuja el recorrido completo, no solo la pantalla de la demo

Un agente rara vez trabaja dentro de una única herramienta. Puede consultar correo y CRM, llamar a un modelo de lenguaje, acceder a una carpeta, utilizar un servicio de búsqueda y devolver el resultado a otra aplicación.

El esquema debe mostrar de dónde sale cada dato, dónde se procesa, qué terceros intervienen y qué acción regresa a los sistemas de la empresa. También debe incluir servicios que no aparecen en la interfaz: APIs, conectores, registros, bases vectoriales o componentes de memoria.

Si nadie puede explicar el recorrido de una consulta sencilla, todavía no es buen momento para conceder permisos de ejecución.

3. Clasifica los datos y limita el acceso

Dar acceso a «la carpeta de clientes» suele ser más cómodo que seleccionar los documentos necesarios. También es mucho más difícil de controlar.

Antes de conectar el agente, identifica si encontrará:

datos personales;
información financiera;
documentación sometida a secreto profesional;
contratos o estrategias comerciales;
credenciales o datos de autenticación;
categorías especiales de datos;
información de personas que no participan en el proceso.

Después aplica una regla sencilla: acceso solo a lo necesario para esa tarea. No a todo lo que podría resultar útil algún día.

La AEPD recomienda trabajar con políticas de acceso, catálogo de datos, filtrado de flujos y medidas de minimización. En algunos casos puede utilizarse seudonimización, una vista limitada o una copia preparada para el piloto en lugar de abrir el repositorio original.

4. Separa lectura, borrador, aprobación y ejecución

La autonomía no es un interruptor con dos posiciones. Puede aumentarse por etapas:

Nivel	Capacidad	Ejemplo
1	Leer o consultar	Recuperar la ficha de un cliente
2	Resumir o clasificar	Etiquetar el motivo de un correo
3	Preparar un borrador	Redactar una respuesta sin enviarla
4	Proponer una acción	Sugerir un cambio de estado en el CRM
5	Ejecutar con aprobación	Actualizar la ficha después de confirmación humana
6	Ejecutar dentro de límites	Enviar una confirmación para casos previamente definidos

Un piloto puede ser valioso en el nivel 2 o 3. No necesita llegar al nivel 6 para justificar su existencia.

5. Utiliza una identidad propia y aplica el menor privilegio

El agente no debería operar con las credenciales personales de alguien ni con una cuenta compartida que impida saber quién hizo qué. Conviene asignarle una identidad identificable, permisos granulares y, cuando sea posible, accesos temporales.

El principio de menor privilegio significa que cada componente recibe únicamente las capacidades necesarias. Si el agente consulta el calendario, no necesita modificar la configuración de las cuentas. Si prepara borradores, no necesita permiso de envío. Si lee una tabla, no debería poder borrarla.

También hay que revisar la posible escalada de privilegios entre herramientas. Un conector aparentemente limitado puede heredar permisos excesivos de la cuenta con la que fue configurado.

6. Decide dónde la aprobación humana es obligatoria

«Habrá una persona revisando» no es todavía un control. Hay que concretar quién revisa, qué información recibe, cuánto tiempo tiene y si puede detener la acción.

Según el impacto y el contexto, normalmente conviene exigir aprobación para:

enviar comunicaciones externas sensibles;
modificar datos maestros;
conceder descuentos o asumir compromisos;
iniciar pagos o movimientos económicos;
borrar información;
cambiar autenticación o permisos;
intervenir en decisiones sobre empleo, crédito, salud o derechos;
ejecutar una excepción fuera del patrón autorizado.

La revisión humana debe aportar algo que el sistema no aporta: contexto, criterio, responsabilidad y capacidad real de decir «no».

7. Controla memoria, registros y plazos de conservación

Un agente puede mantener contexto durante una tarea, conservar preferencias de una persona o utilizar memoria de largo plazo. A la vez, el modelo, el orquestador y las aplicaciones conectadas pueden generar sus propios registros.

Antes del despliegue, aclara:

qué recuerda el agente;
dónde se almacena esa memoria;
si se mezcla información de distintos usuarios o clientes;
qué contienen los logs;
quién puede acceder a ellos;
durante cuánto tiempo se conservan;
cómo se atiende una rectificación o supresión cuando proceda.

Guardar todo «por trazabilidad» puede crear otro problema. Los registros también contienen datos, instrucciones, fragmentos de documentos o errores que no deberían permanecer indefinidamente. La AEPD propone medidas como compartimentar la memoria, aplicar plazos estrictos y desactivar almacenamientos que no sean necesarios.

8. Prueba en un entorno limitado

La primera prueba no debería hacerse con toda la base de clientes y permisos reales de escritura.

Empieza con datos ficticios, sintéticos o minimizados. Utiliza cuentas de prueba y un entorno separado cuando sea posible. Incluye casos normales, entradas incompletas y situaciones diseñadas para provocar un fallo: un documento contradictorio, una instrucción maliciosa dentro de un archivo o una petición que sale del alcance previsto.

Además de comprobar si acierta, observa cómo falla. ¿Pide ayuda? ¿Inventa un dato? ¿Repite una acción? ¿Accede a una fuente que no debería? ¿El error queda registrado de forma comprensible?

Un modo borrador permite medir utilidad sin asumir todavía el coste de una acción automática.

9. Prepara la parada, la reversión y la respuesta a incidentes

Todo piloto debería poder detenerse con rapidez. Eso implica algo más que cerrar la ventana.

Necesitas saber cómo:

desactivar el agente;
revocar sus credenciales;
bloquear una herramienta concreta;
interrumpir una cadena de acciones;
revertir cambios cuando sea posible;
localizar las operaciones realizadas;
avisar a la persona responsable y a su suplente;
registrar y analizar el incidente.

La capacidad de deshacer condiciona el grado de autonomía razonable. Es más prudente automatizar una acción reversible y acotada que otra cuyos efectos llegan de inmediato a clientes o sistemas externos.

10. Asigna responsables y revisa el rendimiento real

El agente necesita un propietario del proceso, no solo una persona técnica que mantenga la conexión. Alguien debe decidir si el resultado sigue siendo útil y si los límites continúan siendo adecuados.

Conviene observar métricas como:

porcentaje de resultados aceptados sin cambios;
errores detectados y gravedad;
intervenciones humanas;
casos escalados correctamente;
tiempo ahorrado de forma comprobable;
coste por tarea;
incidentes y accesos no previstos.

La revisión debe repetirse cuando cambia el modelo, el prompt, una herramienta, los permisos, los datos o el propio proceso. La decisión puede ser ampliar el piloto, mantenerlo, reducir su alcance o retirarlo. Todas son decisiones válidas si se apoyan en evidencia.

RGPD y AI Act: qué revisar sin sacar conclusiones automáticas

Si el agente trata datos personales, el RGPD se aplica al tratamiento completo. No solo al modelo de lenguaje. Hay que considerar las fuentes de datos, las aplicaciones conectadas, los proveedores, las finalidades, los destinatarios, las transferencias y las medidas de seguridad.

Incorporar IA agéntica a un proceso puede hacer necesario revisar el registro de actividades de tratamiento si cambian los medios, las operaciones, los datos o los destinatarios. También puede exigir actualizar la información facilitada a las personas o los contratos con proveedores.

Una evaluación de impacto en protección de datos no es obligatoria por el mero hecho de utilizar un agente. Depende del tratamiento, de los criterios aplicables y del riesgo para los derechos y libertades. Si ya existía una evaluación, habrá que comprobar si el cambio de alcance, autonomía o fuentes de información obliga a revisarla.

Con el AI Act ocurre algo parecido: la clasificación depende del sistema y de la finalidad concreta. La palabra «agente» no convierte automáticamente una solución en un sistema de alto riesgo, ni permite descartarlo sin analizar el caso de uso.

Para no mezclar planos, puede utilizarse esta distinción:

Nivel	Aplicación al agente
Obligación legal	Cumplir el RGPD cuando el tratamiento incluye datos personales y aplicar las obligaciones del AI Act que correspondan a la clasificación y al caso de uso concretos.
Obligación condicionada	Actualizar el registro de actividades, realizar o revisar una EIPD, informar a las personas o adaptar contratos cuando el cambio real del tratamiento y los riesgos lo requieran.
Buena práctica	Aplicar menor privilegio, limitar memoria y registros, probar en un entorno controlado y mantener una supervisión proporcionada.
Recomendación de AI Structura	Empezar en modo lectura o borrador, fijar criterios de parada y aumentar autonomía solo después de revisar resultados e incidentes.

Cuando el proceso afecta a empleo, salud, crédito, vigilancia, categorías especiales de datos o decisiones con efectos relevantes sobre personas, es prudente solicitar revisión jurídica y de protección de datos antes de avanzar.

La guía sobre ChatGPT y datos de clientes explica con más detalle las preguntas sobre proveedores, licitud, minimización y conservación. Aquí el foco es distinto: qué ocurre cuando el sistema no solo recibe información, sino que también encadena pasos y actúa sobre otras aplicaciones.

Ejemplo: un agente para gestionar correos en una asesoría

Una asesoría quiere reducir el tiempo dedicado a clasificar mensajes y preparar respuestas. El buzón recibe consultas sencillas, documentación fiscal, reclamaciones y comunicaciones que pueden incluir datos sensibles.

Un despliegue gradual podría seguir estas fases:

Fase 1. Clasificación con mensajes ficticios

El agente trabaja con ejemplos preparados por el equipo. No accede al buzón real. Se comprueba si distingue una consulta administrativa de una reclamación o una comunicación urgente.

Fase 2. Lectura limitada y revisión total

Accede a una muestra controlada de mensajes reales y propone una categoría. No mueve, borra ni responde. Una persona revisa todos los resultados y registra los errores.

Fase 3. Borradores sin envío

Para consultas sencillas, prepara una respuesta basada en información aprobada. El envío sigue bloqueado. Las reclamaciones, los adjuntos sensibles y cualquier duda salen del flujo.

Fase 4. Ejecución con aprobación

El agente puede actualizar una etiqueta o crear una tarea después de la confirmación de la persona responsable. Sigue sin enviar mensajes por sí solo.

Fase 5. Automatización acotada

Solo tras obtener evidencia suficiente se valora permitir una acción automática para casos muy definidos, por ejemplo confirmar la recepción de documentación. Se mantienen límites de volumen, logs proporcionados y una ruta de parada.

En cada fase cambian los permisos, la supervisión y el impacto. Ese es el objetivo del piloto: aprender antes de ampliar la autonomía.

Señales de que la empresa todavía no está preparada

Conviene detener el despliegue si aparece alguna de estas situaciones:

nadie puede explicar el proceso completo;
se utilizarán credenciales personales o compartidas;
el agente tendrá acceso a toda la base de datos «para no limitarlo»;
no existe una persona propietaria del proceso;
no se distingue un borrador de una acción ejecutada;
los logs son inexistentes o almacenan información excesiva;
no hay una forma rápida de detener el sistema;
los cambios no se pueden localizar ni revertir;
la única salvaguarda prevista es que «alguien revisará»;
el proveedor no permite aclarar qué datos trata o conserva.

Estas señales no significan que el proyecto deba abandonarse. Indican que todavía hay trabajo de proceso y control antes de conectar el agente a información real.

Preguntas frecuentes

¿Un agente de IA es lo mismo que un chatbot?

No necesariamente. Un chatbot suele centrarse en conversar o generar contenido. Un agente puede utilizar herramientas, encadenar pasos y ejecutar acciones. La distinción práctica depende de sus capacidades y permisos, no del nombre del producto.

¿Puede un agente acceder al correo o al CRM de la empresa?

Puede hacerlo si la integración lo permite, pero el acceso debe responder a una tarea concreta. Conviene limitar buzones, campos, registros y operaciones, y separar permisos de lectura, modificación y envío.

¿Qué permisos debería tener al empezar?

Los mínimos necesarios para una prueba útil. Siempre que sea posible, comienza con lectura limitada o modo borrador, utilizando una identidad propia y sin permisos de borrado, envío o modificación irreversible.

¿Siempre hace falta supervisión humana?

El nivel y la forma de supervisión dependen del caso. En acciones sensibles o con impacto sobre personas, la intervención humana puede ser una obligación o una salvaguarda imprescindible. En tareas muy acotadas puede diseñarse una ejecución automática dentro de límites, siempre que exista seguimiento y capacidad de parada.

¿Es obligatoria una evaluación de impacto en protección de datos?

No por el simple hecho de utilizar un agente. Debe analizarse el tratamiento y el riesgo. Si concurren los criterios del RGPD para una EIPD, habrá que realizarla; si ya existe una, puede ser necesario actualizarla.

¿Qué registros conviene conservar?

Los necesarios para supervisar el funcionamiento, reconstruir acciones, gestionar incidencias y acreditar controles. No conviene almacenar de forma indiscriminada prompts, documentos o datos personales si no son necesarios. Los logs también requieren acceso limitado y plazos de conservación.

¿Cómo probar un agente sin poner datos reales en riesgo?

Utiliza datos ficticios, sintéticos o minimizados, cuentas de prueba y un entorno separado. Empieza con casos representativos y añade errores, excepciones e instrucciones adversas. Solo amplía el acceso cuando los resultados aporten evidencia suficiente.

Primero control, después autonomía

Un buen agente no es el que recibe más permisos ni el que completa la cadena más larga. Es el que resuelve una tarea útil dentro de límites que la organización entiende, puede vigilar y sabe retirar.

La implantación gradual puede parecer menos espectacular que una demo con acceso total. También permite descubrir errores cuando todavía son baratos, corregibles y reversibles. Esa diferencia importa mucho cuando el agente trabaja con datos de clientes o actúa en nombre de la empresa.

Si estás valorando un agente o una automatización con IA, AI Structura puede ayudarte a definir el proceso, los límites, la documentación y un piloto realista antes de conectarlo a sistemas críticos.

Solicitar diagnóstico

Agentes de IA en empresas: qué revisar antes de darles acceso a datos y procesos