Cuando tu agente de IA se une al equipo

Del aprendizaje al control de acceso

En mi artículo anterior, describí la construcción de un agente de IA que aprende entre sesiones. Un agente con memoria estructurada, un bucle de autocorrección y un sistema de acumulación de experiencia de una ejecución a otra.

En el momento en que otras personas necesitaron acceso, el problema cambió por completo. Ya no se trataba de si el agente podía aprender. Se trataba de quién tenía derecho a enseñarle.

Qué pasa cuando tu equipo accede a un agente de IA

La mayoría de los artículos sobre agentes de IA se centran en lo que el agente puede hacer. Muy pocos hablan de lo que sucede cuando alguien que no es su creador empieza a utilizarlo.

Construí un bot de Slack. La idea era sencilla: darle al equipo una forma de interactuar directamente con el agente: hacer preguntas, solicitar análisis, obtener informes. Sin terminal. Sin código. Solo Slack.

Funcionó de inmediato. Y ahí es donde apareció el verdadero problema.

El chat libre con un agente de IA es una interfaz poderosa. También es un riesgo. Si cualquier persona del equipo puede escribirle cualquier cosa al agente, cualquiera puede accidentalmente sobrescribir su memoria, modificar su comportamiento o desencadenar acciones no previstas. El agente no juzga la autoridad. Procesa las entradas.

La pregunta no era si el equipo debía tener acceso. La pregunta era: ¿qué tipo de acceso?

Control de acceso basado en roles para agentes de IA

Terminé implementando un sistema de roles. Tres niveles: administrador, analista, observador.

El observador puede leer informes y ver lo que el agente produce. Nada más. Sin comandos, sin chat, sin influencia sobre el comportamiento.

El analista puede hacer más. Puede hacer preguntas. Puede ejecutar comandos predefinidos. Y, este es el punto importante, puede escribir en la memoria del agente. Pero solo a través de un comando explícito, no mediante una conversación libre. Si un analista escribe una instrucción de memorización en el formato correcto, el agente la guarda. Si intenta escribirla como un mensaje informal, el sistema la ignora.

El administrador tiene acceso sin restricciones. Chat libre, comandos directos, escrituras en memoria, cambios de configuración.

Suena como un modelo de permisos estándar. Pero la distinción que importa no es quién puede leer o escribir. Es quién puede enseñar. Porque cada entrada en la memoria cambia lo que el agente sabe. Y lo que el agente sabe moldea cada producción futura.

Por qué la memoria de un agente de IA se convierte en una base de conocimiento compartida

Esto es algo que no aprecié completamente hasta que lo vi en la práctica.

En el artículo anterior, describí la capa de memoria estructurada: un archivo que el agente lee antes de cada ejecución, con las lecciones de sesiones anteriores. Lo que no dije es qué pasa cuando esa memoria se vuelve compartida.

En el momento en que varias personas contribuyen a la memoria del agente, deja de ser una herramienta personal. Se convierte en una base de conocimiento compartida. Cada entrada afecta cada sesión futura, no solo para la persona que la escribió, sino para todos los que interactúan con el agente.

El acceso no controlado a esa memoria es un riesgo real. No porque la gente tenga malas intenciones. Sino porque el agente no distingue entre un insight metodológico cuidadosamente considerado y un comentario casual escrito sin pensar. Trata ambos como verdades equivalentes.

El acceso a la memoria solo por comando para los analistas fue el compromiso. Se puede contribuir. Pero se hace de forma deliberada, en un formato estructurado, y queda registrado.

Qué pasa cuando el agente se equivoca de metodología

Esta me tomó por sorpresa.