Cómo construir una capability policy que sobreviva a cambios de modelo, precio y proveedor sin regalar permisos nuevos

Paso 1 — Describe la capacidad en verbos y objetos, no en marcas. Empieza con un inventario como reademail, draftreply, sendemail, readcrm, updatecrm, browseweb, executecode, createpayment o publishcampaign. Para cada verbo indica qué objetos puede tocar y si el efecto es reversible. Evita reglas del tipo “Claude puede enviar” o “GPT puede editar”, porque el modelo cambiará más rápido que la política. El motor solo es una implementación que solicita acceso a una capability. Esta abstracción permite comparar proveedores sin trasladar permisos por accidente. También vuelve legible la arquitectura para negocio: un director entiende que un agente puede preparar una transferencia pero no aprobarla, aunque no conozca la versión del modelo.

Paso 2 — Asigna consecuencia y evidencia mínima a cada capability. Clasifica acciones por impacto, alcance y posibilidad de rollback. Una lectura interna puede requerir autenticación y logging; un envío externo quizá necesite destinatario validado; un pago exige límites, identidad fuerte y segundo canal. Define qué evidencia debe existir antes y después. Por ejemplo, updatecrm guarda recordId, campos previos y readback; sendemail conserva messageId y destinatario; publishcampaign registra assetId, presupuesto y status. La policy no pregunta si el modelo “parece seguro”. Pregunta si el runtime puede producir las pruebas obligatorias. Si una configuración no soporta el contrato, esa capability permanece deshabilitada aunque el benchmark del modelo sea excelente.

Paso 3 — Añade volumen, velocidad y duración al permiso. La autoridad no es binaria. Leer diez registros y exportar un millón son comportamientos distintos. Define límites por ventana: acciones por minuto, objetos por día, gasto, duración de sesión y paralelismo. Cuando un modelo se vuelve más barato o rápido, esos límites no se incrementan automáticamente. Esto evita que una mejora de eficiencia multiplique la superficie de error. Puedes permitir escalamiento gradual tras observar métricas. Para tareas asíncronas, incluye checkpoints donde el agente debe renovar autorización o verificar estado. La misma capability puede tener perfiles distintos para un operador humano, un agente en sandbox y una automatización nocturna con scope muy estrecho.

Paso 4 — Crea un admission test por configuración. Antes de que modelo, harness o runtime accedan a una capability, ejecútalos contra un corpus de casos normales, adversariales y de error. Mide éxito final, policy violations, tool-call precision, reintentos y comportamiento ante falta de información. No necesitas exigir perfección a todo. Define thresholds según consecuencia. Un agente que solo resume puede tolerar ciertos fallos; uno que modifica facturación debe cumplir mucho más. Guarda versión del test y resultado. Cuando cambie cualquier pieza importante del stack, repite. Esto convierte la aprobación en evidencia reproducible y evita que un upgrade de proveedor entre con las credenciales heredadas de una versión anterior.

Paso 5 — Separa el router de la autoridad. El router puede escoger la configuración más barata o rápida entre opciones ya aprobadas, pero no puede cambiar el scope. Primero la policy filtra qué modelos y runtimes son compatibles con la capability; luego el router optimiza entre ellos. Si no hay configuración válida, la tarea se detiene o degrada. Este orden es crucial. De lo contrario, un fallback ante outage puede terminar enviando datos a una región no permitida o usando un modelo sin eval de seguridad. El router resuelve eficiencia; la capability policy define autoridad. Mantener esa frontera hace que cambios de proveedor sean frecuentes y seguros en lugar de proyectos de compliance cada vez.

Paso 6 — Publica un manifest vivo y auditable. Genera para cada habilidad un documento estructurado con capabilities, scopes, límites, configuraciones aprobadas, última evaluación, owners y excepciones. La interfaz puede mostrar una versión simple, mientras el runtime consume la forma completa. Toda ampliación de permisos produce una nueva versión y deja la anterior disponible para auditoría. En Goatify, ese capabilitymanifest puede convertirse en una primitive de producto: permite al cliente ver exactamente qué puede hacer un agente y qué no. También facilita ventas enterprise porque seguridad no recibe promesas abstractas; recibe una matriz verificable. Cambiar de modelo se vuelve rutinario porque autoridad y capacidad ya estaban desacopladas.