Editorial Goatify: la gobernanza debe seguir a la capacidad porque el precio y el acceso cambian mucho más rápido que las políticas

El riesgo de una capacidad no permanece estable cuando su economía cambia. Las noticias de hoy muestran cuatro formas distintas de difusión. Un modelo frontier puede ejecutar trabajo complejo con menor costo; un servicio criminal puede empaquetar razonamiento sobre buzones para operadores menos expertos; una capa pequeña puede multiplicar eficiencia de inferencia; y un laboratorio universitario puede poner infraestructura empresarial al alcance de estudiantes. Ninguno de estos movimientos es negativo por sí mismo. El problema aparece cuando una organización conserva políticas diseñadas para una época donde esa capacidad era cara, rara o difícil de operar. La gobernanza debe asumir que lo excepcional se vuelve cotidiano. Si una acción potente cuesta diez veces menos, probablemente se ejecutará mucho más.

Las listas de modelos aprobados envejecen más rápido que los contratos de capacidad. Una política que dice “modelo X puede hacer esto y modelo Y no” mezcla identidad comercial con riesgo operativo. Mañana una versión nueva puede alterar velocidad, herramientas o capacidad sin que el nombre del flujo cambie demasiado. Conviene describir capacidades: puede leer correo, inferir relaciones, escribir código, controlar navegador, iniciar transacciones, trabajar de forma asíncrona o acceder a datos regulados. Cada una recibe condiciones de uso. El modelo es una implementación que debe demostrar que cumple esas condiciones. Así, un upgrade no hereda automáticamente todos los permisos de su predecesor y un modelo barato no convierte mayor volumen de ejecución en mayor autoridad.

El costo es una variable de seguridad porque determina frecuencia. Los controles suelen tratar presupuesto como asunto financiero separado de seguridad. Pero reducir costo por tarea puede multiplicar el número de runs, la duración y la cantidad de objetos procesados. Una habilidad que era razonable diez veces al día puede convertirse en cien mil ejecuciones automáticas. Aunque la tasa de error individual permanezca igual, el número absoluto de fallos crece. Por eso el capabilitypolicy debería incluir volumen: cuántas acciones, sobre cuántos activos y durante qué ventana. La difusión responsable no frena el ahorro; convierte el ahorro en escala controlada. Un cliente puede automatizar más sin dejar que frecuencia y autoridad crezcan juntas por accidente.

El acceso también cambia el perfil del adversario. EvilTokens ilustra cómo empaquetar reconocimiento y fraude reduce experiencia requerida. El mismo fenómeno ocurre legítimamente cuando herramientas empresariales simplifican coding, análisis o automatización. La política debe considerar quién puede activar una capacidad, no solo si la capacidad existe. Roles, límites, aprobaciones y entornos de prueba permiten ampliar acceso sin entregar el mismo poder a todos. Para formación, un estudiante puede usar un sandbox agresivo sin tocar sistemas reales. Para ventas, un operador puede preparar una campaña sin controlar facturación. Para desarrollo, un agente puede escribir un diff sin hacer merge. Democratizar capacidad funciona mejor cuando la superficie de efectos sigue segmentada.

Necesitamos un registro vivo de capacidad y no un PDF anual. Cada habilidad debería publicar una ficha versionada: acciones posibles, datos que puede leer, herramientas, límites, frecuencia, pruebas superadas, incidents conocidos y configuraciones aprobadas. Cuando cambia modelo, optimizador o runtime, la ficha se reevalúa. No hace falta convertir esto en burocracia manual; puede derivarse de manifests y evals. La ventaja es que seguridad, compras y producto comparten un objeto operativo. Si mañana una actualización vuelve más barato el trabajo de larga duración, podemos decidir si sube el volumen permitido sin tocar otras capacidades. La gobernanza se vuelve continua y ligada a evidencia, no una revisión periódica que llega meses después del cambio técnico.

Nuestra dirección. Goatify debería implementar capability governance como capa transversal. Una habilidad no recibe permiso porque use un proveedor confiable; recibe permisos específicos porque una configuración verificable ha demostrado condiciones concretas. El router puede cambiar modelos según costo, pero jamás ampliar scopes. Los planes comerciales pueden aumentar volumen o velocidad sin cambiar autoridad sensible. Y cada actualización relevante dispara evals de regresión antes de llegar a producción. Esta arquitectura nos permite aprovechar la caída brutal de costos que viene con los nuevos modelos sin caer en una trampa: confundir IA más accesible con IA que merece más poder. La capacidad puede democratizarse; la autoridad debe seguir siendo explícita.