Un agente es una identidad: permisos, alcance y responsable

Respuesta rápida:

Mientras un modelo solo responde, el riesgo es equivocarse. Cuando ejecuta, el riesgo es ejecutar. Y lo que separa una cosa de otra no es el modelo: son los permisos con los que trabaja.

La mayoría de las organizaciones que hoy tienen agentes en marcha los han desplegado con la credencial de un humano o con una cuenta de servicio compartida. Funciona el primer día. Deja de funcionar el día que alguien pregunta quién hizo qué.

El problema de la credencial prestada

Un agente que usa la credencial de un usuario hereda todo lo que ese usuario puede hacer. No una parte: todo. Si ese usuario es un administrador —y suele serlo, porque es quien monta el piloto—, el agente puede leer nóminas mientras resuelve una incidencia de inventario.

La cuenta de servicio compartida no mejora las cosas, solo las difumina. Tres agentes distintos con la misma credencial producen un registro de auditoría donde todas las acciones parecen de la misma entidad. Cuando algo sale mal, no hay forma de saber cuál de los tres lo hizo, ni de cortarle el acceso sin cortárselo a los otros dos.

Ninguno de los dos montajes aguanta la primera auditoría seria. Y los dos son la norma.

Tres decisiones que lo cambian todo

Identidad propia por agente

Cada agente recibe su propia identidad de carga de trabajo, distinta de la de cualquier persona. No es burocracia: es lo que permite responder a «¿quién leyó este registro?» con un nombre en vez de con un encogimiento de hombros.

Esa identidad se emite, se rota y se revoca como la de un empleado. Si el agente se retira, su identidad se retira con él.

Alcance mínimo viable

A un becario no se le da acceso a toda la base de datos de recursos humanos; se le da a las tablas que necesita. Con un agente ocurre lo mismo, solo que aquí la tentación de dar acceso amplio es mayor, porque acotar requiere entender el caso de uso.

El alcance se define por objeto y por acción: qué puede leer, qué puede escribir y qué puede ejecutar. Un agente de atención que consulta pedidos no necesita poder cancelarlos. Si además puede cancelarlos, tarde o temprano cancelará uno.

Un responsable humano con nombre

Cada identidad de agente lleva asociada una persona. No un departamento: una persona. Es quien aprueba su alcance, quien recibe las alertas y quien responde si el agente hace algo que no tocaba.

Esto es lo que convierte la autonomía en algo defendible ante un comité de riesgos. No se trata de que el agente no se equivoque, sino de que haya alguien que responda cuando se equivoque.

Qué cambia en la práctica

Con las tres decisiones tomadas, aparecen capacidades que antes no existían:

• Rastro por agente: el registro de auditoría dice qué identidad tocó qué dato y cuándo, sin ambigüedad.
• Revocación quirúrgica: se corta un agente sin afectar a los demás ni a las personas.
• Revisión periódica de alcance: los permisos que se pidieron para el piloto se revisan cuando el agente pasa a producción, que es cuando suelen sobrar la mitad.
• Contención real: si un agente entra en bucle o empieza a llamar a una API mil veces, se le retiran las credenciales sin tocar el resto del sistema.

Esto conecta directamente con lo que ya hacemos en gobernanza de datos: las políticas de acceso, la clasificación de información sensible y el gobierno del dato en Palantir Foundry son la base sobre la que se apoya cualquier agente que actúe.

Los cuatro errores que más vemos

1. El agente con credenciales de su creador. Rápido de montar, imposible de auditar.
2. Permisos heredados del piloto. Se pidió acceso amplio para probar y nadie lo revisó al pasar a producción.
3. Sin propietario asignado. Cuando falla, la conversación empieza por «¿de quién era esto?».
4. Alcance por sistema en vez de por objeto. Dar acceso «al CRM» no es un alcance: es una puerta abierta.

Cómo empezar sin frenar los proyectos

No hace falta un programa de gobierno de seis meses. Hace falta empezar por un agente:

1. Inventario: qué agentes hay en marcha y con qué credenciales. Suele haber más de los que el equipo de plataforma cree.
2. Un agente, una identidad: se empieza por el que más permisos tiene.
3. Recortar el alcance hasta que el agente falle, y devolver solo lo imprescindible.
4. Asignar responsable y dejarlo escrito donde se consulte, no en un correo.
5. Poner fecha de revisión. Un alcance sin fecha de caducidad crece solo.

Cómo puede ayudar Galde

Trabajamos el gobierno de agentes como una extensión del gobierno del dato que ya existe en la organización, no como un marco paralelo. En Palantir Foundry, los agentes de AIP actúan sobre la Ontology con permisos por objeto y por acción: definimos sus identidades, sus alcances y la matriz de responsables, y lo dejamos funcionando con el equipo interno capacitado para mantenerlo. Es parte de nuestra línea de gobernanza de datos en Palantir.

Conclusión

El debate sobre autonomía de agentes se plantea casi siempre en términos de capacidad del modelo. Es el sitio equivocado. Un agente con un modelo mediocre y permisos acotados es un problema menor; un agente excelente con la credencial de un administrador es un incidente esperando fecha.

Tratar cada agente como una identidad —con su alcance y su responsable— no frena los proyectos. Es lo que permite defenderlos cuando alguien pregunta.