¿Necesita un agente de IA identidad propia?

Sí. Un agente que trabaja con el usuario y la contraseña de un empleado deja de ser distinguible de ese empleado, y con eso la empresa pierde tres cosas a la vez: saber quién hizo qué, limitar lo que puede hacer y apagarlo sin afectar a una persona.

Carlos Andrés Ramírez ·

Sí. Un agente que trabaja con el usuario y la contraseña de un empleado deja de ser distinguible de ese empleado, y con eso la empresa pierde tres cosas a la vez: saber quién hizo qué, limitar lo que puede hacer y apagarlo sin afectar a una persona.

Piensa en un agente que concilia pagos contra facturas en un cierre contable. Alguien de finanzas lo conecta a los sistemas con su propio usuario, porque es lo más rápido: no hay que pedir nada a IT y el piloto arranca ese mismo día. Funciona bien. Tres meses después, el agente procesa miles de movimientos por semana y en el registro de auditoría todos llevan el nombre de esa analista.

Es un atajo razonable cuando el agente es un experimento, y se vuelve un problema cuando deja de serlo. Un sistema de acceso está diseñado para responder una pregunta: qué persona hizo esto. Si el agente entra como una persona, la respuesta sigue existiendo y es falsa.

La respuesta corta

¿Necesitan los agentes de IA una identidad y credenciales propias, distintas a las de un empleado?

Sí, y la razón no es de seguridad en abstracto. Un agente con identidad propia es un actor que la empresa puede nombrar, acotar y retirar. Un agente con las credenciales de un empleado es una extensión invisible de esa persona, con sus mismos permisos, sin su criterio y sin nadie que lo haya decidido de forma explícita. Las tres consecuencias que siguen son las que justifican el gasto de configurarlo bien.

Primer apoyo

Con credenciales compartidas, el registro deja de decir quién decidió

Cuando un auditor, un regulador o el propio comité de riesgos pregunta quién aprobó un movimiento, la respuesta sale del registro de acceso. Si el agente y la analista comparten usuario, ese registro mezcla dos tipos de actor que se comportan distinto: una persona que revisa diez casos al día con atención, y un agente que ejecuta mil sin cansarse y sin preguntarse nada. Separarlos después, a mano, caso por caso, es una investigación y no una consulta.

Hay además un efecto sobre la persona. La analista queda como autora de decisiones que no tomó. Si una de ellas sale mal, tiene que demostrar que no fue ella, en un sistema que dice lo contrario. Cualquiera que haya vivido un cierre con una diferencia sin explicar sabe lo que cuesta eso.

Segundo apoyo

Un empleado tiene permisos para su puesto, no para lo que un agente puede hacer con ellos

Los permisos de una persona se calibran para una persona. La analista puede ver todas las cuentas del área porque a veces necesita consultar cualquiera, y puede ejecutar pagos hasta cierto monto porque lo hace de uno en uno, con tiempo para dudar. Un agente con esos mismos permisos hereda la amplitud, pero no el freno. Puede recorrer todas las cuentas en un minuto y encadenar pagos hasta el límite de cada uno, sin que nada en el sistema lo distinga de un día normal de trabajo.

Una identidad propia permite aplicar el principio de mínimo privilegio, que consiste en darle al agente solo el acceso que su tarea necesita y nada más. El agente de conciliación necesita leer facturas y movimientos y proponer asientos. No necesita iniciar pagos. Con credenciales de la analista tiene ese permiso igual. Con las suyas, no lo tiene, y el perímetro del agente queda en el sistema y no en la confianza.

Tercer apoyo

Apagar un agente no debería exigir cambiar la contraseña de una persona

El día que algo falla, la primera pregunta es cómo se detiene. Si el agente usa el usuario de una empleada, la única forma limpia es bloquear ese usuario, y eso la deja sin acceso a su propio trabajo mientras se investiga. Lo habitual es no hacerlo, porque cuesta demasiado, y el agente sigue corriendo mientras alguien decide. Con una identidad propia, se revoca esa credencial y solo esa. La persona sigue trabajando y el agente queda parado en un paso.

El mismo problema aparece cuando la persona cambia de puesto o se va de la empresa. Su usuario se desactiva, como corresponde, y el agente que dependía de él deja de funcionar sin aviso, o peor, alguien reactiva el acceso para que el proceso no se caiga. Una identidad de agente tiene su propio ciclo de vida: alguien la crea, alguien responde por ella y alguien la retira.

Un agente con las credenciales de un empleado no tiene permisos propios. Tiene los de otra persona, sin que ella lo haya decidido.

BECOME

Qué hace falta

Una identidad de agente son cuatro decisiones, no una herramienta

Casi todos los sistemas corporativos ya permiten crear cuentas de servicio o identidades no humanas, así que lo difícil no es la tecnología. Es decidir cuatro cosas antes de conectar el agente.

Una identidad por agente
Cada agente tiene su propia cuenta, con un nombre que lo identifica como agente en cualquier registro. No se comparte entre agentes distintos, porque entonces vuelve el mismo problema de atribución un nivel más arriba.
Permisos escritos desde la tarea
Se parte de lo que el agente hace y se le da exactamente eso. Si más adelante necesita más, alguien lo pide y alguien lo aprueba. Lo contrario, empezar con los permisos de una persona y quitar después, casi nunca se hace.
Un responsable con nombre
Una persona concreta responde por esa identidad: sabe qué puede hacer, revisa periódicamente que sigue siendo necesario y decide cuándo se retira. Sin responsable, las cuentas de agente se acumulan y nadie se atreve a borrarlas.
Credenciales que caducan
Las claves del agente se renuevan con una frecuencia definida y se pueden revocar de inmediato. Una credencial que no caduca es, en la práctica, un permiso que alguien olvidó que concedió.

Nada de esto frena al agente. Lo que cambia es que cada acción suya queda a nombre de un actor identificable, con un perímetro conocido y con un interruptor que no afecta a nadie más.

Pide a IT la lista de agentes y automatizaciones que hoy corren en la empresa y, para cada una, con qué usuario entran. Todo lo que aparezca con el nombre de una persona es un agente sin identidad propia, y ese es tu primer backlog.

Preguntas frecuentes

¿Puede un agente de IA usar el usuario de un empleado?

Puede, y en muchas pruebas piloto se hace porque es lo más rápido. El coste aparece después: el registro atribuye a la persona lo que hizo el agente, el agente hereda permisos pensados para un humano y no se puede detener sin bloquear a esa persona. Sirve para un experimento acotado y no para un proceso en producción.

¿Qué es una identidad no humana y en qué se diferencia de la de un empleado?

Es una cuenta que representa a un sistema, un servicio o un agente y no a una persona. Se diferencia en que no tiene un puesto del que heredar permisos, no se desactiva cuando alguien se va de la empresa y necesita un responsable humano designado, porque ella no puede responder por sí misma.

¿Qué permisos debe tener un agente de IA?

Los que su tarea exige y ninguno más. Se escribe primero qué hace el agente, se le concede ese acceso y cada ampliación pasa por una aprobación explícita. Es más lento al principio y mucho más barato cuando hay que explicar, ante un auditor o ante un cliente, qué podía hacer el agente y qué no.

¿Cómo se detiene un agente de IA que se comporta mal?

Revocando su credencial propia, que es posible solo si la tiene. Con una identidad independiente, el corte es inmediato y no afecta al trabajo de ninguna persona. Con credenciales compartidas, hay que elegir entre dejarlo correr mientras se decide o bloquear a un empleado, y esa fricción suele retrasar la decisión.

Revisemos con qué identidad trabajan tus agentes

De la idea a la operación

Un agente llega a operar cuando alguien define sus límites, sus excepciones y quién responde por el resultado. Eso se diseña y se construye.

Sobre el autor

Carlos Andrés Ramírez — Director de Transformación

Especialista en transformación y reinvención de negocios. Director de Programas Especializados y docente de Inteligencia Artificial en la Escuela de Postgrado de la UPC.

LinkedIn