La gobernanza de agentes de IA define quién responde por el agente, qué puede hacer, qué condiciones requieren revisión y cómo se verifica la ejecución. Para equipos de revenue, la unidad práctica es una acción: modificar un registro, recomendar una oferta, contactar a un prospecto o preparar una decisión comercial. Una política resulta útil cuando esos límites existen en el flujo operativo.
El AI Risk Management Framework de NIST es un recurso voluntario para incorporar confiabilidad al diseño, desarrollo, uso y evaluación de sistemas de IA. Ofrece una referencia más amplia de gestión de riesgos; adoptar esta guía no establece cumplimiento, certificación ni conformidad con el marco. AI RMF de NIST.
Empezar por la acción y su responsable
Describir la acción prevista de forma verificable. “Ayudar a ventas” oculta demasiadas posibilidades. “Preparar una modificación de CRM desde una fuente aprobada para un revisor identificado” delimita tarea y autoridad. Identificar quién aprueba el alcance y quién puede suspenderlo.
Documentar los datos necesarios, el sistema receptor y la consecuencia de un error. Una sugerencia y un compromiso externo requieren tratamiento distinto. No asignar un nivel de permisos indiferenciado a todas las herramientas por el hecho de que las invoque el mismo agente.
Incluir operaciones correctas además de fallos. Si nadie puede explicar una acción válida, será difícil investigar una controvertida. Conservar contexto suficiente para reconstruir la decisión sin almacenar datos personales innecesarios.
Convertir permisos en límites efectivos
Pedir prudencia en un prompt no equivale a disponer de una herramienta que rechace operaciones no autorizadas. Nuestra práctica propuesta consiste en limitar herramientas, acceso a datos y parámetros de acción en el sistema de ejecución. La intención declarada del agente no debe eludir esos controles.
Un asistente hipotético de ofertas puede consultar opciones elegibles y preparar una recomendación, mientras una aprobación separada controla excepciones. El revisor recibe fuente, acción propuesta y motivo del escalamiento. Si cambian las condiciones después de aprobar, debe existir una comprobación definida; la aprobación anterior no constituye autoridad permanente.
Es un patrón operativo para evaluar, no una afirmación sobre una capacidad específica de AIOS ya desplegada. Una evaluación de producto debe comprobar qué controles están configurados y se aplican realmente en el entorno del cliente.
Hacer que la revisión sea concreta
Una aprobación útil presenta objeto afectado, cambio exacto, evidencia actual y consecuencia relevante. “Aprobar al agente” es demasiado amplio. Si el revisor no distingue qué ocurrirá, la aprobación apenas resuelve incertidumbre.
Definir cuánto tiempo aplica y qué cambios la invalidan. Especificar qué sucede si nadie responde, falta una fuente o hay instrucciones contradictorias. Según la tarea, puede corresponder dejar un borrador, pausar o transferir. El silencio no debe interpretarse automáticamente como autorización.
Para operaciones repetidas de bajo impacto, el equipo puede definir una política acotada en lugar de revisar cada instancia. Esa política sigue necesitando responsable, límites comprobables y capacidad de detener ejecución. La elección depende de tarea y consecuencias, no de una preferencia general por mayor o menor autonomía.
Evaluar trabajo normal y excepciones
Crear pruebas a partir de la tarea permitida y sus límites: entradas válidas, contexto ausente, registros contradictorios, condiciones vencidas y acceso denegado. Registrar el comportamiento esperado antes de probar. Mantener los fallos junto a los éxitos; una demostración correcta puede ocultar excepciones sin evaluar.
Verificar resultados en el sistema receptor. La guía de continuidad de contexto explica por qué un enlace o una transferencia no demuestran recepción de información. Una traza que dice “completado” necesita contrastarse con el estado real de la operación.
Revisar pruebas al cambiar herramientas, políticas o fuentes. Asignar responsable de investigar anomalías y definir recuperación. Detener un agente evita nuevas acciones; no revierte automáticamente las ya aceptadas por otros sistemas.
Pedir evidencia al evaluar el producto
Solicitar demostraciones de una acción permitida, una denegada, una aprobación cuyas condiciones cambiaron y un destino fallido. Examinar sus registros. Estos ejercicios revelan más del modelo operativo que una declaración general de preparación empresarial.
Explorar AIOS y definir la revisión de un flujo de revenue, sus límites de autoridad y su evidencia de finalización. Esta guía propone criterios de evaluación; no certifica un despliegue ni presenta mejoras comerciales atribuidas.
Gobernanza y evaluación de agentes
Para convertir estos límites en una bandeja operativa, adapta el expediente y los estados de nuestro flujo de aprobación de agentes de IA.
