# Piloto de acceso de un agente de IA: métricas que justifican la ampliación Un piloto debe demostrar que las personas pueden ver, evaluar y detener las acciones externas de un agente de IA antes de concederle una autoridad más amplia. No debe limitarse a demostrar que el agente puede llamar a una API, abrir una conexión SSH o terminar una incidencia más rápido. Los equipos suelen reunir una pila de recuentos de eventos, anunciar que no se ha incendiado nada y ampliar el acceso. Eso no es una prueba. Las mediciones útiles responden a cuatro preguntas más difíciles: ¿aprobaron los humanos solicitudes que entendían?, ¿los controles detuvieron las solicitudes correctas?, ¿el agente siguió fallando de formas que indicaban un defecto de diseño?, y ¿con qué rapidez podía alguien cortar una ejecución activa? Un piloto de acceso de un agente de IA necesita un conjunto reducido de mediciones vinculadas a decisiones. Registra la tasa de aprobación, las solicitudes bloqueadas, los fallos repetidos y el tiempo hasta la revocación, pero no trates ninguna de ellas como una puntuación aislada. Cada métrica puede inducir a error si eliminas la solicitud, el objetivo, la identidad y el resultado que la rodean. ## Un piloto se amplía gracias a las pruebas de control Un piloto de acceso de un agente de IA solo está listo para ampliarse cuando el equipo puede explicar una muestra de acciones permitidas, rechazadas y fallidas, y después contener una sesión activa bajo demanda. La calidad de los resultados forma parte de la evaluación, pero no puede sustituir a las pruebas de control. Define la ampliación propuesta antes de iniciar el piloto. Deja por escrito la autoridad actual, la siguiente autoridad que se está considerando y las consecuencias externas de ese cambio. «Permitir que el agente de programación use nuestro gestor de incidencias» no es un alcance. «Permitir que este proceso de agente local firmado cree incidencias en un proyecto de prueba durante ejecuciones iniciadas por desarrolladores» sí lo es. La diferencia ofrece a los revisores algo que pueden evaluar. Mantén el primer piloto deliberadamente limitado. Restringe los procesos de agente, las personas responsables, los sistemas objetivo, las rutas de credenciales y los tipos de acción. Un alcance reducido no es una precaución burocrática. Permite saber si una solicitud inesperada procede de una tarea poco clara, una integración rota, un agente confundido o un acceso que ya era demasiado amplio desde el principio. Un registro útil del piloto responde a estas preguntas para cada acción: - ¿Qué proceso de agente hizo la solicitud y quién lo inició? - ¿Qué acción pidió realizar y contra qué objetivo identificado? - ¿Qué ruta de acceso o clase de credencial la autorizó? - ¿La permitió o rechazó una persona, y por qué? - ¿Qué resultado se obtuvo, incluido cualquier error externo? No reduzcas ese registro a «el agente usó una herramienta». Una solicitud para leer una incidencia y otra para cambiar la configuración de un despliegue pueden usar HTTP, pero crean riesgos distintos y requieren revisiones diferentes. NIST SP 800-53 Rev. 5 sitúa la revisión, el análisis y los informes de auditoría en el control AU-6. La palabra importante es «revisión». Conservar registros no cumple el propósito práctico si nadie puede reconstruir por qué ocurrió una solicitud, quién la aprobó y si tuvo éxito. En un piloto de agente, los datos de auditoría deben respaldar una decisión sobre la ampliación del acceso. Si no pueden hacerlo, son almacenamiento, no pruebas. Establece una frecuencia de revisión que los responsables realmente mantengan. Una revisión breve después de cada día activo suele funcionar mejor que una sesión extensa a final de mes, porque la tarea y las sorpresas siguen presentes. La persona que aprobó una solicitud extraña todavía puede explicar el contexto. El ingeniero responsable de la integración todavía puede reproducir el fallo. No fijes de antemano una cifra objetivo de «seguridad suficiente» sin tener una línea de base. Establece reglas de decisión. Por ejemplo, no se amplía el acceso mientras los revisores no puedan atribuir las solicitudes a un proceso iniciador, mientras las acciones de consecuencias elevadas no tengan una ruta de revocación probada o mientras los fallos repetidos sigan sin explicación. Estas reglas orientan la conversación hacia la calidad de los controles en lugar de hacia un panel complaciente. ## La tasa de aprobación mide la calidad de la revisión, no la confianza La tasa de aprobación indica si las solicitudes reciben un sí, pero no si esos síes fueron informados. Calcúlala como las solicitudes aprobadas divididas entre las solicitudes que requerían una decisión humana. Mantén las solicitudes expiradas, abandonadas y rechazadas automáticamente en campos separados, en lugar de eliminarlas sin decirlo. Una tasa alta puede significar que el agente solicita trabajo razonable en un entorno bien delimitado. También puede significar que los revisores hacen clic en las solicitudes porque están ocupados, que falta el objetivo en la descripción o que la misma solicitud aparece tantas veces que dejan de leerla. He visto sistemas de aprobación convertirse en un trámite en cuestión de días cuando cada llamada inofensiva plantea la misma pregunta. Entonces el equipo trata la única solicitud peligrosa exactamente igual que las veinte anteriores, que eran inofensivas. Lee la tasa de aprobación por segmentos. Como mínimo, separa el tipo de acción, la clase de objetivo, la sesión y el revisor. Si combinas operaciones de lectura con cambios de cuentas, o un entorno de prueba con producción, el promedio oculta la parte que necesita atención. Una tasa de aprobación del 95 % para lecturas no dice casi nada sobre si las personas revisan correctamente el 5 % restante de solicitudes que pueden cambiar el estado. Haz una pequeña revisión semanal de muestras. Elige varias aprobaciones, incluida una que haya ocurrido al final de una sesión y otra relacionada con un objetivo sensible. Pide a la persona que aprobó que responda cuatro preguntas usando el registro conservado: 1. ¿Qué pretendía hacer el agente? 2. ¿Qué proceso emitió la solicitud? 3. ¿Qué sistema externo la recibiría? 4. ¿Por qué era apropiada la aprobación en ese momento? Si la persona necesita consultar el historial del chat, el desplazamiento de la terminal u otro sistema para responder preguntas básicas, a la pantalla de aprobación le falta contexto. Si no puede responder ni siquiera con ese material, el diseño de acceso le pide certificar un trabajo que no entiende. Separa la autorización de la sesión de la aprobación de una acción sensible. La autorización de sesión responde a si un proceso recién iniciado puede actuar dentro de un límite acordado. Una decisión por acción responde a si esa operación concreta merece atención. Los equipos suelen mezclar ambas decisiones y después afirman que tienen «una persona dentro del proceso». Puede que solo hayan aprobado una vez el proceso, sin una forma útil de detectar que su trabajo cambió de naturaleza a mitad de la ejecución. El error contrario es igual de habitual: pedir aprobación para cada acción de consecuencias bajas. Ese diseño produce un recuento saludable de decisiones humanas y un hábito de revisión inútil. Reduce las solicitudes repetitivas limitando o reestructurando la ruta de acceso, no enseñando a las personas a aprobarlas más rápido. Registra el denominador con honestidad. Si un agente obtiene autoridad fuera de la ruta de aprobación, esas llamadas pertenecen al registro del piloto como excepciones, aunque la llamada haya tenido éxito. Una métrica que excluye los bypasses hace que los controles parezcan mejores por definición. ## Una denegación necesita una causa y un resultado verificado Las solicitudes bloqueadas muestran si el límite detecta trabajo que queda fuera del piloto, pero solo si clasificas el motivo del bloqueo. Tratar todas las denegaciones como victorias es una de las formas más fáciles de no aprender nada. Usa una clasificación de causas que corresponda a la siguiente acción del operador. Cuatro categorías cubren la mayoría de los casos de un piloto: - La sesión no estaba autorizada o ya había terminado. - La acción solicitada requería aprobación explícita y la persona la rechazó. - La ruta de acceso no estaba disponible porque su bóveda local o barrera estaba bloqueada. - La solicitud no coincidía con el acceso concedido deliberadamente por el piloto. Una denegación después de bloquear la bóveda local significa que alguien conservó un límite firme. Una denegación porque el usuario rechazó una solicitud puede significar que el agente se salió de su tarea, o que la descripción de la solicitud era demasiado vaga. Una denegación porque el objetivo estaba fuera del alcance puede revelar un buen límite, pero también un diseño incompleto. No mezcles estas causas en una única barra de «bloqueadas». Después, verifica el resultado externo. Una decisión de control solo importa si la acción externa no ocurrió a través de esa ruta. En una llamada API, conserva el método intentado, la categoría del endpoint y el error devuelto. En un comando SSH, conserva el host solicitado y el contexto del comando que corresponda al diseño de auditoría. No supongas que un rechazo local significa que el extremo remoto no vio nada si tu arquitectura puede emitir el trabajo antes del punto de decisión. Aquí los equipos descubren la diferencia entre prevenir y fallar. Una solicitud prevenida nunca llegó al servicio porque el límite de acceso la rechazó. Una solicitud fallida llegó al servicio y recibió un error. Ambas merecen revisión, pero cuentan historias distintas. Llamar a cada 403 un bloqueo exitoso puede ocultar que el agente intenta repetidamente cambiar un recurso que el diseño de acceso expuso accidentalmente a la red. Recorre una secuencia de revisión real cuando se produce una denegación: 1. Localiza la ejecución del agente e identifica el proceso que emitió la solicitud. 2. Lee la operación y el objetivo solicitados y compáralos con la tarea original. 3. Confirma si el control detuvo la solicitud antes de que ocurriera una acción externa. 4. Asigna una causa: ambigüedad de la tarea, comportamiento del prompt, capacidad faltante, alcance de acceso incorrecto o intento de infringir un límite. 5. Decide si debes cambiar la tarea, la configuración del agente, la concesión de acceso o nada. Esta última opción importa. Algunas solicitudes bloqueadas deben seguir bloqueadas. Un piloto suele tentar al equipo a conceder acceso después de cada intento fallido porque el agente parecía productivo hasta que llegó al límite. Eso sustituye el diseño por deriva. Busca agrupaciones de denegaciones. Diez denegaciones contra un endpoint después de una nueva versión del agente suelen apuntar a un supuesto de integración. Diez denegaciones contra objetivos sin relación pueden apuntar a una tarea que deja al modelo demasiada libertad. Las solicitudes rechazadas repetidamente después de que un revisor haya rechazado la misma intención requieren una respuesta más firme: detén la sesión, conserva el registro y revisa la tarea y las instrucciones de las herramientas antes de volver a intentarlo. ## Los fallos repetidos revelan una presión insegura para ampliar el acceso Las solicitudes fallidas repetidamente son una señal temprana de que el agente, sus instrucciones o la ruta de acceso no encajan. Cuéntalas por huella, no como un único total bruto. Una huella útil combina la categoría de operación, el objetivo, la clase de error, la versión o configuración del agente y una ventana temporal breve. Así puedes distinguir una interrupción temporal del servicio de un agente que reintenta el mismo comando no autorizado veinte veces. También muestra si un nuevo prompt o una actualización de una herramienta produjo un cambio de comportamiento. No uses los reintentos como prueba de que el agente «realmente necesita» una concesión de acceso. Los agentes repiten porque su ciclo de planificación encuentra el mismo siguiente paso aparente. El ciclo no entiende tu decisión de riesgo solo porque se haya encontrado con ella cinco veces. Conceder una credencial para terminar los reintentos enseña al equipo a ampliar el acceso cada vez que el agente presiona. Inspecciona la primera y la última aparición de cada fallo repetido. La primera te indica el supuesto original. La última muestra si el agente cambió de estrategia, se detuvo o intensificó los intentos. La diferencia importa. Un agente que detecta un error y toma una alternativa permitida puede necesitar una mejor descripción de la herramienta. Un agente que sigue sondeando un host prohibido puede necesitar una tarea más limitada y el cierre de la sesión. Registra cuatro campos para cada grupo de fallos repetidos: número de intentos, tiempo transcurrido, clase de resultado y respuesta humana. El campo de respuesta humana se omite habitualmente, lo que deja la falsa impresión de que el error terminó por sí solo. Alguien pudo cambiar un prompt, conceder acceso, reiniciar el agente o revocar la sesión. Esas intervenciones explican el resultado. Un fallo devuelto por el servicio externo no es necesariamente un problema de acceso. Los errores de autenticación pueden indicar una ruta de credenciales incorrecta. Los errores de validación suelen indicar una entrada mal formada del agente. Los límites de frecuencia pueden indicar reintentos sin control. Los errores de red pueden indicar condiciones del servicio. Trata cada categoría de forma distinta. Un equipo que concede permisos más amplios para resolver errores de validación creará más exposición y seguirá teniendo solicitudes rotas. Establece un umbral práctico de escalado basado en el patrón, no en una cifra universal. Por ejemplo, revisa de inmediato cuando la misma sesión del agente repita una denegación de acceso contra un objetivo sensible después de que una persona la haya rechazado. Revisa cuando una nueva configuración produzca una ráfaga de errores contra un servicio externo. Revisa cuando los reintentos continúen después de que el servicio haya indicado claramente al cliente que se detenga. Son reglas de comportamiento, no métricas de vanidad. Conserva un registro breve de decisiones junto a los datos sin procesar. Escribe «se corrigió la construcción del endpoint», «se mantuvo el acceso denegado» o «se terminó la ejecución y se reescribió el límite de la tarea». Ese registro hace que el piloto sea acumulativo. Sin él, cada revisión semanal vuelve a descubrir el mismo patrón de error y lo presenta como un hallazgo nuevo. ## El tiempo de revocación debe incluir el descubrimiento y la prueba El tiempo hasta la revocación mide la contención, y la contención comienza cuando alguien reconoce que una ejecución debe detenerse. Mide el intervalo desde la primera señal accionable hasta la confirmación de que esa ejecución ya no puede realizar otra acción autorizada. Un botón con la etiqueta «revocar» puede funcionar rápidamente. Eso es útil, pero solo representa un segmento del intervalo. En un incidente real, un ingeniero detecta una solicitud extraña, identifica qué sesión la posee, encuentra la autoridad para detenerla, ejecuta la acción y comprueba que el agente no puede continuar. Si la identidad de la sesión no está clara, el tiempo perdido en encontrarla pertenece a la métrica. Registra estas marcas de tiempo durante un simulacro: - La acción sospechosa apareció en el registro de revisión. - Una persona identificada decidió revocar la ejecución. - Esa persona emitió la revocación. - El sistema registró la revocación. - Una solicitud de seguimiento controlada de la misma ejecución fue rechazada. La comprobación final es la prueba. No pruebes la revocación deteniendo el proceso del agente y suponiendo que el acceso terminó. La terminación del proceso puede ocultar autorizaciones obsoletas, un segundo proceso, trabajo en cola o un operador que revocó la sesión equivocada. Usa una operación inofensiva dentro del alcance de prueba y verifica que el límite la rechaza después de la revocación. Haz este simulacro durante el trabajo normal, no solo cuando esté disponible la persona que configuró los controles. Encarga la tarea a alguien que no haya configurado el piloto. Si esa persona no puede identificar la ejecución activa a partir del registro, el proceso depende demasiado del conocimiento informal. Una ruta de revocación rápida que solo puede usar un ingeniero no ofrece una contención significativa al equipo. Distingue entre revocar una sesión y rotar una credencial. La revocación de sesión detiene una ejecución activa concreta del agente. La rotación de credenciales cambia el secreto o la autoridad y puede afectar al trabajo legítimo que la comparte. Puede que necesites ambas medidas durante un incidente grave, pero resuelven problemas distintos. Medirlas como una sola acción hace que una respuesta específica parezca lenta y una respuesta amplia parezca eficiente. Sallyport conserva un diario de sesiones para las ejecuciones de agentes con revocación instantánea, junto con un diario de actividad para las llamadas individuales. En un piloto, esta separación permite practicar cómo encontrar la ejecución, revocarla y confirmar el registro de la llamada posterior sin confundir el control de sesión con la sustitución de credenciales. Conserva el resultado del simulacro incluso cuando salga mal. Un intervalo largo revela una debilidad que se puede corregir: propiedad poco clara, etiquetado insuficiente de las sesiones, notificaciones ausentes o una acción de revocación a la que las personas no pueden acceder. Ocultar los simulacros fallidos convierte la primera revocación urgente real en la prueba que debiste ejecutar antes. ## Los registros de auditoría deben resistir los desacuerdos Un registro de auditoría solo ayuda cuando un revisor escéptico puede verificar lo que dice sin confiar en la persona que lo exportó. Los pilotos de acceso de agentes necesitan esa propiedad porque las disputas de autorización aparecen después, cuando los recuerdos y el historial de la terminal ya han cambiado. Para cada evento muestreado, un revisor debe poder conectar la ejecución del agente que lo inició, la decisión de autorización, la solicitud de acción, el resultado externo y la posterior revocación, si la hubo. Conserva el orden. Una marca de tiempo aislada puede inducir a error cuando los relojes difieren o los eventos llegan tarde. Una secuencia dentro de un registro firmado o protegido ofrece al revisor una base para reconstruir lo ocurrido. La distinción difícil está entre un registro de actividad y un registro de auditoría con evidencia de manipulación. Un registro de actividad te dice lo que la aplicación muestra actualmente. Un registro con evidencia de manipulación permite detectar un historial modificado, eliminado o reordenado. Necesitas el segundo cuando las pruebas del piloto deciden si se debe conceder un acceso más amplio. Sallyport proyecta sus diarios de sesiones y actividad desde un registro de auditoría cifrado y encadenado mediante hashes, y su comando `sp audit verify` comprueba la cadena sin conexión y sin requerir una clave de bóveda. Ejecuta la verificación como parte de la rutina de revisión, no solo después de una discusión. Una comprobación que nadie realiza no aporta confianza. ```text sp audit verify ``` Conserva el resultado de la verificación junto con el registro de revisión e indica el intervalo temporal que cubrió. Si la verificación informa de un problema, deja de usar ese registro como prueba del funcionamiento normal hasta que el equipo lo investigue. No exportes silenciosamente las entradas legibles para continuar con una hoja de cálculo. Eso conserva la apariencia y descarta la propiedad probatoria que necesitabas. Los registros de auditoría también pueden revelar cansancio de revisión. Compara el tiempo entre una solicitud y su aprobación, el contexto de la solicitud y el resultado posterior. Una aprobación extremadamente rápida no significa automáticamente descuido, especialmente en trabajos familiares de consecuencias bajas. Un patrón de aprobaciones instantáneas para objetivos desconocidos y acciones sensibles merece una conversación con el revisor y un rediseño de las solicitudes. No des a todas las personas acceso sin restricciones al contenido de auditoría sin procesar solo porque el registro ayude a supervisar. La actividad de un agente puede contener nombres de repositorios, nombres de host, metadatos de solicitudes y detalles de tareas. Define quién lo revisa, quién puede exportarlo y quién resuelve las disputas. El control de la visibilidad de la auditoría forma parte del diseño de acceso. ## Una revisión semanal debe producir decisiones, no gráficos Una revisión semanal del piloto debe terminar con decisiones explícitas sobre alcance, correcciones y responsables. Si termina con un recorrido por el panel, el equipo ha medido actividad sin cambiar su postura de riesgo. Lleva un paquete compacto: una pequeña muestra de aprobaciones, todas las denegaciones relacionadas con una acción sensible, los principales grupos de fallos repetidos, el simulacro de revocación más reciente y el resultado de la verificación de auditoría. Es material suficiente para una revisión seria sin obligar a las personas a recorrer cada solicitud rutinaria de lectura. Pide una decisión a cada responsable. El responsable de la tarea decide si el trabajo solicitado por el agente coincidía con la tarea asignada. El responsable del sistema decide si el acceso al objetivo sigue siendo apropiado. La persona responsable del mecanismo de acceso decide si el control se comportó como se esperaba. Una persona puede desempeñar varios papeles en un equipo pequeño, pero nómbralos de todos modos. La responsabilidad sin nombre se convierte en falta de atención colectiva. Escribe las decisiones en lenguaje sencillo. «Permitir la creación de incidencias en el proyecto del piloto para sesiones aprobadas» se puede probar. «Mejorar las barreras» no. Acompaña cada cambio con una medición que indique si funcionó. Si reduces las solicitudes para lecturas de consecuencias bajas, toma una muestra de las aprobaciones restantes para asegurarte de que las personas reciben suficiente contexto en las acciones importantes. Si cambias el tratamiento de los reintentos, comprueba si los fallos repetidos realmente disminuyen sin un nuevo aumento de las solicitudes bloqueadas. No amplíes todas las dimensiones a la vez. Ampliar los objetivos, añadir acciones de escritura, aceptar más procesos de agentes y eliminar aprobaciones durante la misma semana destruye la atribución. Cuando algo salga mal, nadie sabrá qué cambio lo causó. Amplía una dimensión de autoridad, obsérvala durante un ciclo de revisión y conserva una ruta de reversión. Un piloto puede terminar con la decisión de no ampliarse. Es un resultado exitoso cuando las mediciones revelan que el equipo todavía no puede revisar solicitudes, contener sesiones o explicar fallos. El mal resultado es fingir que esas carencias desaparecerán cuando el acceso sea más amplio y aumente el número de ejecuciones de agentes. ## Una autoridad más amplia debe seguir a una prueba concreta superada Amplía el acceso solo después de que la nueva autoridad propuesta haya superado una prueba concreta dentro del piloto actual. La prueba debe parecerse a la consecuencia que planeas permitir, no a un sustituto cómodo. Si planeas permitir una acción API de mayores consecuencias, prueba a los revisores con solicitudes que contengan el mismo contexto del objetivo y la misma carga de aprobación. Si planeas permitir al agente acceder por SSH a más hosts, prueba primero la atribución, el tratamiento de las denegaciones y la revocación contra un host representativo que no sea de producción. Un piloto de solo lectura no puede demostrar que las personas gestionarán correctamente los cambios en el estado externo. Escribe la decisión de ampliación como una afirmación que las pruebas puedan refutar: «El equipo puede autorizar esta clase de acción con suficiente contexto, detectar una solicitud fuera de la tarea y revocar la sesión iniciadora dentro del tiempo de respuesta acordado». Después, examina las aprobaciones, denegaciones, fallos, el simulacro de revocación y el registro de auditoría frente a esa afirmación. No promuevas un piloto porque haya aumentado su porcentaje de aprobación. Puede haber aumentado porque los revisores aprendieron los prompts, porque el agente dejó de pedir trabajos difíciles o porque el equipo eliminó silenciosamente las denegaciones del denominador. La promoción necesita pruebas representativas y un registro de excepciones. La primera acción que merece la pena tomar es sencilla y poco llamativa: elige una ejecución actual del agente, rastrea una llamada aprobada y otra denegada o fallida, y después revoca esa misma ejecución en un simulacro controlado. Si tu equipo no puede reconstruir esos eventos y demostrar que la ejecución perdió su autoridad, ampliar el acceso es prematuro.