Artículo
Perception: autoridad para agentes
Microsoft anunció el 19 de octubre de 2026 una ampliación de Project Perception para gobernar agentes internos. La base se había presentado en julio. El foco comunicado es ajustar su autoridad mientras trabajan.
Según Microsoft, Dynamic Permissions limita la autoridad; Dynamic Agent Risk evalúa señales; Dynamic Conditional Access adapta restricciones. Perception comparte registro con Agent 365.
Una identidad no es una autorización
Reconocer qué agente está actuando ayuda a atribuirle una operación. La autorización responde otra pregunta: qué puede hacer ese agente, sobre qué recursos y durante cuánto tiempo. Un identificador reconocible no convierte cualquier acción posterior en una acción permitida.
Conviene separar tres elementos al delegar: el objetivo solicitado, los recursos necesarios y los cambios aceptados. Pedir que alguien encuentre una sala no equivale a permitirle cancelar reuniones ajenas. La diferencia se vuelve práctica cuando el sistema dispone de herramientas capaces de producir ambos resultados.
Una política útil debe poder comprobarse fuera de la explicación del agente. Por ejemplo: este agente puede consultar disponibilidad de dos salas, pero sólo crear una reserva para el horario y los recursos de la tarea vigente. La regla se contrasta con la operación concreta, no con la seguridad con que el asistente la describe.
Un caso ficticio con cuatro niveles
Imaginemos Centro Brisa, una organización completamente ficticia. Su agente coordina salas y equipos. Una persona le pide preparar una reunión de cuatro participantes, de diez a once, con un proyector. El ejemplo siguiente es un diseño didáctico propio, no una configuración probada ni una función específica atribuida a Microsoft.
El agente encuentra la sala Norte y el proyector P1 como opciones. La organización propone distinguir las siguientes facultades. Una misma herramienta podría reunir varias; la tabla las separa para discutir sus efectos.
| Nivel | Operación del ejemplo | Límite propuesto |
|---|---|---|
| Leer | Consultar disponibilidad de salas y equipos. | Ver horarios libres, sin acceder a notas privadas de reuniones ajenas. |
| Borrador | Proponer Norte y P1 para la reunión. | Preparar la propuesta sin ocupar recursos ni enviar invitaciones. |
| Escribir | Guardar la reserva acordada. | Modificar únicamente el recurso y horario autorizados, comprobando disponibilidad vigente. |
| Acción | Notificar a participantes y coordinar la entrega. | Usar destinatarios y efecto aprobados, después de verificar la reserva guardada. |
Escribir también es una acción. La última fila destaca efectos adicionales sobre personas y procesos, para que no queden implícitos al guardar un registro. Una delegación puede autorizar varios pasos desde el principio; esta propuesta no exige pedir confirmación antes de cada operación rutinaria.
Qué cambia cuando aparece otra instrucción
Supongamos que una ficha del proyector incluye una instrucción para cancelar reservas vecinas. Esa ficha puede describir un equipo, pero no es la persona que delegó la tarea ni la política de la organización. El contenido consultado no amplía por sí solo el permiso para modificar calendarios.
La respuesta proporcionada al caso sería conservar la propuesta pendiente y rechazar el cambio fuera de alcance. Si todavía está permitido consultar horarios, esa lectura puede continuar. Detener la escritura no obliga a borrar la investigación ya hecha ni a convertir cualquier anomalía en un cierre completo del servicio.
La pregunta operativa es qué cambió: una petición legítima del coordinador, un dato de disponibilidad o una instrucción encontrada dentro de un recurso. Cada categoría aporta evidencia distinta. Registrar esa diferencia permite revisar la decisión sin suponer que todo texto tiene la misma autoridad.
Para seguir pensando el alcance de los datos y los servicios utilizados, puedes consultar Claude en Bedrock y datos. Elegir un proveedor y definir qué cambios delegas son decisiones relacionadas que requieren sus propios criterios.
La evidencia que permite revisar y corregir
Una propuesta convincente no acredita que la reserva exista. Después de guardar un cambio, el registro de la tarea debería permitir comprobar el identificador de reserva, la sala, el horario y el equipo efectivamente asignados. El alcance autorizado y el resultado observado deben poder compararse.
En este diseño ficticio también se anota quién delegó, qué operación se intentó y qué respuesta devolvió el sistema de reservas. No es necesario conservar una narración interminable para responder preguntas concretas: ¿se ocupó el recurso previsto?, ¿se envió una invitación?, ¿quedó un paso pendiente?
Si el resultado es incierto, repetir la solicitud podría crear otra reserva o duplicar una notificación. Primero comprueba qué ocurrió. Si la reserva existe y el aviso falló, el paso pendiente es el aviso; volver a reservar no corrige ese problema.
Los límites de ejecución también importan. El análisis de colas y operación de inferencia trata otro aspecto: cuándo puede atenderse un trabajo. Disponer de capacidad para ejecutarlo no concede permiso para hacerlo.
Ejercicio: una sala ocupada a última hora
Continúa el mismo caso: la persona aceptó Norte y P1, pero otra reserva ocupó Norte antes de guardar el cambio. El agente encuentra libre la sala Sur, de mayor capacidad y situada en otro edificio. ¿Qué parte de la autorización original sigue siendo válida?
La respuesta depende del alcance acordado. Si se autorizó cualquier sala del mismo edificio, Sur queda fuera de esa condición. El agente puede preparar una alternativa, pero no tratarla como una sustitución ya aprobada. Si la delegación incluyera expresamente ambos edificios y mantuviera los demás requisitos, la evaluación sería diferente.
Escribe tres líneas: condición que dejó de cumplirse, efecto que todavía se permite y evidencia necesaria para continuar. Una solución razonada sería conservar el borrador, no crear una reserva incompatible y presentar el cambio relevante. Este ejercicio evalúa el alcance de una tarea, no la capacidad del modelo para inventar una justificación persuasiva.
La disponibilidad por función, las licencias y el acceso regional quedan por comprobar. La revisión de una implementación concreta debe identificar sus componentes y límites reales antes de dar por cumplido el diseño del ejemplo.
Preguntas frecuentes
¿El permiso de la persona debe copiarse entero al agente?
No hace falta que ambos tengan la misma autoridad para una tarea acotada. Define las operaciones necesarias y sus límites. Una persona puede administrar recursos que no quiere delegar en esta ocasión.
¿Un riesgo mayor significa detener todo?
No necesariamente: conviene restringir la operación cuestionada y comprobar qué sigue autorizado. La respuesta depende del alcance y la evidencia disponibles.
¿Una explicación del agente demuestra que actuó correctamente?
Puede ayudar a formular preguntas, pero el resultado y el permiso se verifican con evidencia de la tarea y del sistema que recibió la operación. Una intención declarada no sustituye esos registros.
¿Quién revisa que los límites sigan siendo adecuados?
La organización debe asignar una responsabilidad concreta y revisar excepciones observadas. Si cambian el objetivo, los recursos o los efectos delegados, también corresponde revisar el alcance; conservarlo por inercia puede dejar decisiones sin responsable.
Fuentes: Microsoft y Microsoft Security.
Para practicar decisiones de delegación y revisar ejemplos propios, visita la Comunidad IA.
