Edición en Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Compara los controles de acción de un proveedor de agentes de IA antes de comprar

> Antes de una revisión humana de compra, compara identidades, aprobaciones, permisos de herramientas, registros, flujos de datos y pruebas de fallos de un proveedor de agentes de IA con tu perfil de riesgo escrito.

By BIG CHANGE Editorial

Published: 2026-10-19T15:30:34.881Z
Updated: 2026-10-19T15:30:34.881Z
Canonical: https://bigchange.ai/blog/ai-agent-vendor-action-controls-evidence

![Conceptual charcoal illustration of a completely blank five-column comparison worksheet clipped to an angled wooden reading stand, beside a closed unmarked folder.](https://bigchange.ai/api/media/file/agent-vendor-blank-comparison-worksheet-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual vendor evidence, security finding, audit, test or purchase decision is depicted.

Un agente de IA que actúa en cuentas conectadas puede cambiar datos o activar procesos empresariales. Antes de elegir un proveedor, el responsable del negocio y quien revise la seguridad pueden comparar los controles de **un flujo de trabajo propuesto** con los requisitos escritos de la organización. El resultado es un registro de pruebas con fecha. Una pregunta sin respuesta sigue pendiente; una afirmación comercial no demuestra por sí sola que se detendrá una acción. El método se basa en el [NIST AI Risk Management Framework Playbook](https://airc.nist.gov/airmf-resources/playbook/) y en la [AI Agent Security Cheat Sheet de OWASP](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html); ninguno ha evaluado al proveedor candidato.

## El gran cambio

- **Qué cambió:** Comprar un agente puede incluir acciones delegadas en los sistemas del negocio. El comprador necesita saber quién puede hacer actuar al agente, sobre qué y con la aprobación de quién.
- **Por qué importa:** El comprador puede relacionar cada acción propuesta con un control identificado y sus pruebas. Eso ofrece al responsable del negocio y al revisor de seguridad una base concreta para limitar el acceso o suspender la compra.
- **Qué observar:** La decisión depende de pruebas para la versión exacta del producto y el flujo de trabajo. Un control descrito en la documentación aún puede necesitar una demostración supervisada antes de que el revisor lo acepte para el uso previsto.

## Reúne cuatro elementos

Utiliza el perfil de riesgo escrito existente y aprobado por tu organización. Debe identificar al responsable del negocio, el resultado previsto, los datos y destinos permitidos, las acciones autorizadas, la autoridad de aprobación, las consecuencias inaceptables y las condiciones de parada. Si no existe, pide a las personas responsables que lo definan antes de evaluar al proveedor. Esta guía no puede fijar su tolerancia al riesgo por ellas.

[La orientación MANAGE 3.1 del NIST](https://airc.nist.gov/airmf-resources/playbook/manage/) pide aplicar la tolerancia al riesgo de la organización a los sistemas de IA de terceros y documentar sus controles. El Playbook ofrece sugerencias voluntarias, no una lista universal de compras. Las preguntas siguientes sobre controles de acción también se apoyan en la orientación de OWASP para la seguridad de agentes. Estos marcos señalan preguntas útiles; las pruebas del propio proveedor deben responderlas.

Nombra un proveedor candidato y el producto y versión de despliegue exactos que estudias. Consigue la documentación actual y las pruebas que el proveedor esté autorizado a compartir. Da acceso al registro comparativo al revisor de seguridad y al responsable de compras. Guarda los archivos sensibles de arquitectura o pruebas en un lugar privado aprobado; la hoja puede enlazarlos en vez de copiar secretos.

## 1. Convierte el flujo en requisitos

Enumera cada acción propuesta del agente, su sistema de destino y los datos que debe leer o cambiar. Separa la lectura de la escritura y de las acciones visibles fuera o irreversibles. Para cada una, copia el requisito pertinente del perfil de riesgo escrito: identidad permitida, alcance de herramientas y destinos, aprobación, registro, tratamiento de datos, interrupción y recuperación. Anota el responsable del perfil y su fecha.

Crea una fila por requisito. Así lo desconocido queda visible y no enterrado en una puntuación general del proveedor. La prohibición de acceder a una cuenta concreta merece una fila tanto como una acción permitida.

## 2. Rastrea quién actúa y qué puede ejecutarse

Pregunta qué persona, cuenta de servicio o identidad de agente inicia cada acción, dónde se guardan las credenciales y si un agente puede pasar una solicitud a otro. Identifica el componente que comprueba el permiso en la ejecución. Compara los permisos reales de las herramientas del proveedor con las herramientas, operaciones, cuentas y destinos autorizados por el perfil. Solicita pruebas de configuración o arquitectura aplicables a esta versión; una frase en una instrucción es una prueba débil de un límite obligatorio.

Para las acciones que requieren aprobación, pregunta qué ve el revisor antes de ejecutar y cómo se vincula la aprobación al actor, la llamada exacta a la herramienta, el destino y los parámetros. Averigua qué ocurre si caduca, se rechaza, se usa dos veces o cambia la acción solicitada. Registra cómo revocar el acceso y quién puede detener una ejecución activa. Una pantalla de aprobación y una comprobación en la ejecución responden preguntas diferentes; pide pruebas de ambas si el perfil exige ambas.

## 3. Sigue los datos y el registro de acciones

Dibuja el recorrido propuesto desde la entrada hasta el modelo, las herramientas, los destinatarios externos, las copias guardadas y los registros. Pregunta qué datos recibe cada componente, quién puede recuperarlos y cómo funcionan su conservación y eliminación. Incluye subencargados o transferencias entre sistemas relevantes para tu perfil. Marca una pregunta sin respuesta sobre destino o conservación como **desconocida**; no deduzcas protección de la privacidad de una declaración general de política.

Solicita un registro de ejecución para la versión correspondiente. ¿Puede el revisor conectar un actor y una versión de política con la llamada propuesta a la herramienta, la aprobación o denegación, el destino exacto y el resultado? Comprueba si el registro muestra solo una decisión, una ejecución real o ambas. Una captura, una exportación de configuración y un historial completo de eventos demuestran cosas distintas. Anota las ocultaciones que impiden comparar, sin introducir credenciales ni datos personales en la hoja.

## 4. Pide pruebas de fallos

Solicita pruebas vinculadas a la versión de una acción permitida y de las rutas de fallo exigidas por el perfil: aprobación denegada o caducada, herramienta o destino fuera de alcance, ejecución interrumpida y, cuando corresponda, fallos del registro o de la comprobación de políticas. Anota qué se probó, cuándo, con qué políticas y ajustes de herramientas, el resultado esperado y el observado. Un plan de pruebas pide evidencia; no es un resultado observado.

El revisor de seguridad responsable decide si hace falta una demostración supervisada y autoriza su alcance. Usa entradas y cuentas permitidas fuera de producción. No conectes sistemas en servicio solo para completar una hoja de compras. Si el proveedor no puede aportar pruebas, registra la carencia y la próxima solicitud en vez de imaginar un resultado.

## 5. Registra la decisión y el trabajo pendiente

En cada fila, marca **ajuste al requisito** solo si las pruebas aportadas responden al requisito escrito para esta versión y flujo. Marca **brecha** si lo contradicen, o **desconocido** si faltan pruebas o son demasiado débiles. Anota los registros contradictorios y quién debe resolverlos. Después, el responsable del negocio y el revisor de seguridad responsable registran su decisión real: pedir más pruebas, solicitar aprobación para un piloto limitado, aplazar o rechazar. Una fila que se ajusta al requisito es un juicio sobre las pruebas, no una garantía de seguridad ni un sustituto del proceso de compra de la organización.

Mantén el registro fechado y revisa las filas afectadas cuando cambien el flujo, la versión del producto, la política, las cuentas conectadas o los destinos de los datos. Un piloto posterior necesita su propia autorización, límites y revisión.

| Requisito del perfil escrito | Pruebas del proveedor, versión y fecha | Tipo de prueba y qué demuestra | Ajuste al requisito, brecha o desconocido | Revisor y próxima acción |
| --- | --- | --- | --- | --- |
| [Un requisito de acción o control] | [Enlace privado o referencia documental; versión; fecha] | [Afirmación, configuración, registro de evento o demostración observada; limitación] | [Elige una opción y explica] | [Nombre, solicitud de pruebas o decisión] |

**Cabecera del registro:** flujo y responsable; versión del perfil de riesgo y fecha de aprobación; producto candidato y versión de despliegue; fecha de revisión; revisor de seguridad; responsable de compras; ubicación de pruebas restringidas. **Registro de decisión:** decisión, filas pendientes, límites aceptados o controles compensatorios, responsable de aprobación y motivo de la próxima revisión. Deja estos campos vacíos hasta que las personas responsables los revisen realmente.

Las orientaciones públicas usadas para formular estas preguntas están disponibles gratuitamente. Preparar la comparación requiere tiempo del personal y los revisores. Las pruebas del proveedor, el acceso confidencial y una demostración autorizada pueden añadir costes o limitar lo verificable; obtén las condiciones reales del candidato. Este ejercicio documental no prueba a un proveedor ni establece cumplimiento legal o un umbral universal de compra.

## Fuentes y lecturas adicionales

1. [NIST AI RMF Playbook, Manage](https://airc.nist.gov/airmf-resources/playbook/manage/) respalda aplicar la tolerancia al riesgo propia de la organización a los recursos de IA de terceros, documentar los controles y evaluarlos. La página dice que se está actualizando AI RMF 1.0 y después se actualizará el Playbook; no indica fecha de revisión de la página. No evalúa a este proveedor.
2. [Introducción del NIST AI RMF Playbook](https://airc.nist.gov/airmf-resources/playbook/) describe las sugerencias como voluntarias y dice que el Playbook no es una lista que deba seguirse íntegramente. La hoja es una síntesis de BIG CHANGE para la tarea indicada al lector.
3. [OWASP AI Agent Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) trata herramientas con alcance limitado, autorización en la ejecución, aprobaciones ligadas a acciones, registros, protección de datos y pruebas de validación vinculadas a versiones. La página actual no indica versión ni fecha de publicación. Sus recomendaciones son categorías de pruebas, no demostración de que un proveedor las implemente.

## Sources

- [NIST AI RMF Playbook, Manage](https://airc.nist.gov/airmf-resources/playbook/manage/) — MANAGE 3.1 respalda aplicar la tolerancia al riesgo de la organización a los recursos de IA de terceros y documentar controles. La página actual de AI RMF 1.0 Playbook dice que hay una revisión pendiente; no da fecha de revisión. No valida a un proveedor.
- [NIST AI RMF Playbook](https://airc.nist.gov/airmf-resources/playbook/) — La introducción dice que las sugerencias son voluntarias y que el Playbook no es una lista completa ni una secuencia prescrita. La hoja comparativa es una síntesis editorial.
- [OWASP AI Agent Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) — Las secciones 1, 4, 6, 8 y 9 informan las preguntas sobre herramientas limitadas, aprobación ligada a acciones, registros, tratamiento de datos y pruebas vinculadas a versiones. Página actual sin versión ni fecha de publicación; las recomendaciones no demuestran eficacia del proveedor.