El registro de agentes de IA: una plantilla de inventario multiplataforma para Copilot, Agentforce y agentes personalizados

Qué controla el Registro de agentes de IA¶

Utilice el registro como la lista conciliada de sistemas de agentes de la organización y sus límites operativos. Cada registro conecta un identificador de agente estable con un propósito comercial, propietarios responsables, versión actual, autoridad delegada, ruta de aprobación, evidencia y estado de revisión. El registro sustenta cuatro preguntas recurrentes: qué agentes existen, quién responde por ellos, qué pueden hacer y qué registro prueba la respuesta.

La unidad útil es una configuración de agente implementada o desplegable con una identidad distinta o un límite de autoridad. Cree registros separados cuando dos entornos, identidades, versiones o procesos comerciales tengan permisos o reglas de aprobación diferentes. Agruparlos bajo una misma marca oculta los límites que necesita un revisor de acceso o un respondedor de incidentes.

Incluya agentes activos, pilotos, reclutados, suspendidos y retirados mientras sus registros sigan siendo relevantes. Registre copilotos que recomiendan o redactan, agentes que llaman a herramientas o API, flujos de trabajo de agentes programados, agentes de proveedores disponibles para los empleados y orquestadores personalizados que pueden seleccionar o secuenciar acciones. Registre el sistema incluso cuando la clasificación sea incierta; Utilice el campo de limitaciones para preservar la incertidumbre.

• En alcance: agentes creados por proveedores, agentes creados por empleados, agentes personalizados, agentes integrados, flujos de trabajo de agentes y aplicaciones de agentes con un propósito o límite de autoridad distinto.
• Registros separados: instancias de producción y prueba con diferentes datos, identidades, herramientas, propietarios o políticas de aprobación.
• Estados del ciclo de vida: propuesto, borrador, piloto, activo, suspendido, retirado y desconocido.
• Brechas abiertas: identidad faltante, propietario no resuelto, lista de herramientas incompleta, datos de seguimiento no disponibles y metadatos de proveedores no verificados.

Descargar e iniciar el registro¶

El AI Agent Register CSV se abre en herramientas de hoja de cálculo y se importa a sistemas comunes de gobernanza, gestión de activos, datos y emisión de tickets. La primera fila de datos es sintética y está claramente marcada como EXAMPLE-001. Cópielo para conocer el nivel de detalle esperado y luego elimínelo antes de publicar su población.

Mantenga un valor por campo siempre que sea posible. Utilice identificaciones estables, nombres de sistemas canónicos, fechas ISO, enlaces de evidencia duraderos y roles con nombre. Registre el límite de implementación en environment. Registre el rol o la persona que completó la revisión en reviewed_by, junto con last_reviewed_at. Cuando se desconoce un valor, escriba unknown, asigne un propietario para el espacio y use next_review_due para establecer una fecha de cierre. Una celda vacía puede parecer completa después de una importación masiva.

La versión 1.0 de la plantilla incluye los seis campos de control requeridos más los campos de descubrimiento, entorno, atestación de revisión, identidad, liberación, monitoreo, revocación, retención y límites de reclamo. Agregue columnas específicas de la organización después del conjunto de estándares para que las exportaciones futuras de proveedores y los envíos de unidades de negocios sigan siendo comparables.

Los seis campos de control obligatorios¶

Un registro está listo para revisión cuando estos seis campos contienen respuestas operativas. Un título de trabajo, nombre de producto o enlace de política pueden contribuir a una respuesta; rara vez completa uno. Nombra la persona o equipo que opera el control y el límite exacto que posee.

Utilice una escala de autonomía operativa¶

La autonomía pertenece al registro porque cambia el diseño del control. Utilice la escala de cinco niveles que aparece a continuación como abreviatura operativa interna y conserve la definición en lenguaje sencillo al lado del nivel. Un nivel por sí solo no puede describir un flujo de trabajo complejo.

Esta escala es una convención de gobernanza para el triaje. No lleva ninguna clasificación legal, conclusión de seguridad o certificación. Un agente A1 que redacta una decisión consecuente puede requerir una revisión más estricta que un agente A3 que realiza una acción de mantenimiento reversible. Evalúe el impacto, la reversibilidad, las personas afectadas, la sensibilidad de los datos y la autoridad con el nivel.

Registrar permisos como una cadena de autoridad¶

Comience con la identidad del agente: entidad de servicio, identidad de carga de trabajo, usuario del agente, cliente OAuth, propietario de la clave API o sesión delegada del usuario final. Luego, nombre cada herramienta y acción, el alcance del recurso, el límite de los datos, la fuente de credenciales, la restricción de tiempo o propósito y la política que permite su uso. La [guía de permisos del agente de IA] (/blog/ai-agent-permissions) proporciona un método de revisión de acceso más profundo.

Mantenga la autoridad asignada y observada en campos separados. La autoridad asignada proviene de IAM, conjuntos de permisos, configuración de conectores, repositorios de políticas, manifiestos de herramientas y reglas de aprobación. La autoridad observada proviene de ejecuciones, seguimientos, registros de puerta de enlace API, registros de auditoría de bases de datos, registros de entrega de mensajes y cambios de estado posteriores. Las diferencias entre los dos se convierten en hallazgos de revisión.

El registro resume la autoridad actual y señala sus fuentes. Los registros de IAM, políticas, control de fuentes y tiempo de ejecución conservan su propia autoridad. Actualice el resumen después de un cambio de concesión, herramienta, identidad, modelo, solicitud, datos, implementación o flujo de trabajo.

• Identidad: ID estable, tipo de identidad, emisor, propietario de la credencial y entorno.
• Autoridad de herramienta: herramienta o API, acciones permitidas, restricciones de recursos y acciones denegadas.
• Autoridad de datos: conjuntos de datos, campos, jurisdicciones, sensibilidad, retención y límites de exportación.
• Delegación: principio del patrocinio, finalidad, alcance, duración y vía de revocación.
• Uso observado: período de seguimiento, última marca de tiempo observada, acciones ejercidas y concesiones no probadas.

Sistemas de mapas afectados y efectos posteriores.¶

Enumere todos los sistemas que el agente puede leer, cambiar, notificar o provocar que otro componente cambie. Incluya la aplicación empresarial visible y la ruta menos visible a través de índices de búsqueda, almacenes de vectores, colas, programadores, servidores de herramientas, puertas de enlace, almacenes de archivos, bases de datos, correo electrónico, chat y API externas.

Registra efectos a nivel de acción. El “acceso CRM” oculta si el agente lee un caso, cambia un derecho, emite un crédito o envía un mensaje al cliente. La acción determina los requisitos de aprobación, seguimiento, evidencia y reversión.

Vincular la delegación entre agentes explícitamente. Cuando un agente le pide a otro agente o flujo de trabajo que actúe, registre ambos sistemas y la autoridad transferida entre ellos. El registro inicial debe identificar la acción delegada; el registro posterior debe identificar el principal y la política que lo aceptó.

Escribir reglas de aprobación que se puedan ejecutar¶

Un campo de aprobación necesita la acción, la condición de activación, el aprobador requerido, la ventana de respuesta y el resultado. “La persona en el bucle” deja cada parte sin resolver. Escriba reglas como: "Los reembolsos superiores a 250 EUR se detienen antes de la ejecución; un líder del equipo de operaciones del cliente los aprueba o rechaza; la solicitud vence después de cuatro horas; el rechazo no crea ningún cambio posterior".

Nombre el propietario de la supervisión humana para el flujo de trabajo y los roles de decisión autorizados para cada puerta. Registre lo que ve el revisor, qué alternativas puede elegir, cómo detiene el flujo de trabajo y cómo se registran las anulaciones. Conserve la decisión, la justificación, la versión de la política, la liberación del agente, las referencias de entrada, las marcas de tiempo y el resultado posterior en la ubicación de la evidencia.

La aprobación protege la acción sólo cuando el agente no puede pasar por alto la puerta. Verifique la ruta de ejecución y pruebe el rechazo, el tiempo de espera, la revocación, las solicitudes duplicadas y las fallas posteriores. Una declaración de política por sí sola no puede demostrar su cumplimiento.

Elija ubicaciones de evidencia que sobrevivan la revisión¶

Señale cada registro hacia evidencia duradera para la publicación y el período mencionados. Las fuentes útiles incluyen instantáneas de identidad y concesión, configuración aprobada, decisiones de políticas, registros de aprobación, seguimientos de llamadas de herramientas, estado antes y después, registros de incidentes, revisiones de cambios, revisiones de acceso y resultados de retención o eliminación.

Utilice referencias que un revisor autorizado pueda recuperar después de que cambie el equipo operativo. Registre el sistema de registro, el identificador de objeto o consulta, el período de retención, el mecanismo de integridad, el propietario del acceso y las lagunas de recopilación conocidas. Una URL del panel sin una consulta o un período estable crea un trabajo de reconstrucción evitable.

KLA puede mantener el registro operativo en el Registro de agentes, conectar capacidades declaradas a través del Catálogo de herramientas, enrutar decisiones consecuentes a través del Decision Desk, rastrear efectos en el Lineage Explorer y retener artefactos de revisión en la Sala de evidencia. La cobertura aún depende de los sistemas integrados, la evidencia recopilada y los controles configurados. El registro no proporciona ninguna certificación ni conclusión legal.

Complete los registros de Microsoft Copilot y Agent Builder¶

Comience con el inventario de Power Platform para los recursos de Copilot Studio y Microsoft 365 Copilot Agent Builder creados en Power Platform. Exporte el nombre para mostrar del mapa e inventario, el ID de la plataforma, el entorno, el creador o propietario, el estado de publicación, la autenticación, los conectores, las operaciones del conector, los canales y las capacidades al esquema común.

Concilie esa exportación con la [vista del agente del centro de administración de Microsoft 365] (https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-copilot-agents-integrated-apps?view=o365-worldwide), las identidades y subvenciones de Entra, los registros de implementación y la evidencia de ejecución. Microsoft explica que las dos superficies de administración responden a diferentes preguntas de población: el inventario de Power Platform cubre los agentes creados en Power Platform, incluidos los borradores; la vista de Microsoft 365 cubre los agentes disponibles para los usuarios inquilinos en un conjunto más amplio de fuentes.

Conserve las limitaciones documentadas de Microsoft en limitations_and_open_questions. El esquema de inventario de Copilot Studio excluye los agentes V1 clásicos, puede omitir campos de identidad, refleja la configuración publicada cuando existe un borrador más reciente y limita los recursos de capacidad detallados. Esos límites hacen que la reconciliación sea parte del control.

• Exporte el inventario de Power Platform con ID y campos de entorno estables.
• Exporte o revise agentes disponibles a través del centro de administración de Microsoft 365.
• Únase a las identidades, subvenciones, propietarios y controles de credenciales de la aplicación o agente de Entra.
• Resuelva operaciones de conector para acciones comerciales y límites de datos.
• Compare los conectores y las concesiones asignados con los seguimientos de ejecución recientes.
• Agregue registros clásicos, personalizados, de terceros, borradores e inaccesibles como espacios explícitos.

Completar registros de Salesforce Agentforce¶

Utilice Configuración y Agentforce Studio para enumerar las definiciones de agentes y los ID estables. Salesforce documenta cómo recuperar un ID de agente de Agentforce, incluido el objeto BotDefinition utilizado por los agentes actuales. Una cada definición a su entorno, estado del ciclo de vida, temas o acciones, acceso a datos, implementación y propósito comercial.

Registre el usuario del agente de Agentforce, el perfil, los conjuntos de permisos, el contexto de API o aplicación conectada y cada acción invocada. Concilie los datos de administración con [metadatos de origen de Agentforce DX] (https://developer.salesforce.com/docs/ai/agentforce/guide/agent-dx-set-up-env.html), cambios de versiones, registros de auditoría e interacciones en tiempo de ejecución. Los metadatos de origen ayudan a identificar el diseño declarado; Las identidades, los permisos y los rastros muestran el límite operativo.

Mantenga los registros de Salesforce y Microsoft en el mismo esquema de control de seis campos. Los ID y la configuración específicos de la plataforma siguen siendo valiosos, mientras que los campos normalizados permiten al propietario revisar los agentes en todos los procesos comerciales y proveedores.

Encuentre agentes personalizados y sombra de IA¶

Los agentes personalizados y creados por los empleados rara vez llegan a través de un punto final de inventario. Cree la población de candidatos a partir de repositorios, plataformas de implementación, identidades de cargas de trabajo, puertas de enlace API, cuentas de proveedores de modelos, catálogos de servidores MCP y herramientas, programadores, colas, administradores de secretos, datos de observabilidad, integraciones de navegador o colaboración, adquisiciones, gastos, aplicaciones SSO, tickets de soporte y registros de arquitectura.

Busque señales operativas: llamadas de API de modelos combinadas con llamadas de herramientas, identidades no humanas que llaman a sistemas comerciales, trabajos de LLM programados, dependencias de SDK de agentes, manifiestos de herramientas, tarjetas de agentes, mensajes con instrucciones de acción y mensajes de aprobación recurrentes. Validar candidatos con los técnicos y dueños de negocio antes de asignarles ciclo de vida y autonomía.

La [guía oculta de riesgos de IA] (/blog/shadow-ai-compliance-risk) cubre la admisión y la respuesta para sistemas no declarados. Mantener el registro inicial incluso cuando se desconozca el propietario. Los campos de propietario, identidad, permiso y evidencia no resueltos definen el trabajo pendiente de contención e investigación.

Ejecute un ciclo de población reproducible¶

Un registro se vuelve confiable mediante la conciliación. Mantenga la fecha de extracción, la fuente, el método de consulta o exportación, el recuento de registros, las exclusiones, las uniones, las reglas duplicadas, el revisor y las diferencias no resueltas para cada ciclo.

• 1. Defina el alcance. Nombre los entornos, las unidades de negocio, las plataformas, las pilas personalizadas, los estados del ciclo de vida y la fecha actual.
• 2. Extraer. Conserve los archivos fuente sin procesar del proveedor, IAM, repositorio, adquisiciones, puerta de enlace y tiempo de ejecución con marcas de tiempo.
• 3. Normalizar. Asigne ID estables y campos de plataforma a la plantilla común sin descartar los ID de origen.
• 4. Coincidencia. Une definiciones de plataforma con identidades, propietarios, implementaciones, herramientas, sistemas, políticas y evidencia.
• 5. Deduplicar. Mantenga registros separados cuando los límites de entorno, autoridad, aprobación o publicación difieran.
• 6. Verificar. Solicite a los propietarios técnicos y comerciales que confirmen el propósito, el impacto, el estado actual y las brechas no resueltas.
• 7. Observar. Compare la autoridad asignada con un período definido de llamadas a herramientas y efectos posteriores.
• 8. Remediar. Asignar propietarios faltantes, subvenciones excesivas, aprobaciones ausentes, sistemas desconocidos y lagunas en la evidencia.
• 9. Attest. Registre el revisor en reviewed_by, la fecha en last_reviewed_at, las fuentes, las excepciones y la próxima revisión o activador de cambio.

Establecer cadencia de revisión y cambiar activadores¶

Elija un intervalo de revisión máximo basado en el riesgo y vuelva a abrir el registro cuando se produzca un cambio importante. Los flujos de trabajo de alto impacto o alta autonomía pueden necesitar controles continuos de población y revisiones frecuentes del propietario. Los asistentes estables que solo trabajan en draft pueden justificar un intervalo más largo.

Utilice activadores de eventos para salida del propietario, nuevo entorno, cambio de modelo o versión, cambio de identidad o permiso, nueva herramienta o dominio de datos, umbral de aprobación modificado, nueva comunicación externa, excepción de política, incidente, comportamiento inexplicable, cambio de capacidad del proveedor y retiro. Registre el desencadenante y la respuesta del revisor.

La retirada requiere una pasada de control final: deshabilitar implementaciones y programaciones, revocar identidades y credenciales, eliminar concesiones de herramientas, preservar la evidencia requerida, actualizar dependencias y asignar acciones de eliminación o retención. Mantenga el registro retirado visible durante el período de evidencia aplicable.

Mantener las obligaciones de la Ley de IA de la UE y registrar las reclamaciones con precisión¶

Un registro interno de agentes de IA respalda la gobernanza y puede respaldar el trabajo realizado para la Ley de IA de la UE. Es un artefacto separado del registro formal en la base de datos de la UE. El Artículo 71 rige la base de datos de la UE para sistemas de IA de alto riesgo específicos, con datos de registro específicos de cada función y sistema. Confirmar cualquier deber del Artículo 49 o del Artículo 71 a través del texto legal vigente y asesoría calificada.

El Artículo 26 establece deberes para quienes implementan sistemas de IA de alto riesgo. Los registros relevantes pueden incluir instrucciones de uso, supervisión humana asignada, controles de datos de entrada, monitoreo, registros bajo el control del implementador, avisos de incidentes o riesgos, información de los trabajadores y cooperación. La aplicabilidad depende del sistema, la función y los hechos.

Utilice article_26_applicability para capturar una evaluación calificada o review required. El campo en sí demuestra que no hay clasificación ni cumplimiento. Siga la [lista de verificación del implementador del Artículo 26] (/blog/eu-ai-act-article-26-deployer-obligations-runtime-checklist) para la revisión a nivel de obligación y conserve la lista de verificación completa con la evidencia del registro.

Límites de reclamo para el registro completo¶

Describa el resultado completo como una población conciliada para las fuentes, entornos, unidades de negocio y fecha de prueba. Indique los métodos de extracción, los puntos ciegos conocidos, los registros no resueltos y el porcentaje de registros con propietarios verificados, identidades, permisos, reglas de aprobación y evidencia recuperable.

Evite el “inventario empresarial completo” a menos que una conciliación independiente respalde ese alcance exacto. Las exportaciones de los proveedores tienen límites documentados. La observación en tiempo de ejecución tiene una ventana de tiempo. Los agentes latentes pueden no dejar rastro. Las identidades compartidas pueden oscurecer la atribución. Los agentes creados por empleados y alojados externamente pueden permanecer fuera de las rutas de descubrimiento administradas.

La plantilla organiza el trabajo de gobernanza. No proporciona garantía de seguridad, evaluación de la conformidad, registro legal ni asesoramiento legal. Esas conclusiones requieren sus propios criterios, evidencia, pruebas y revisores responsables.