Resumen

  • draft-smith-opsawg-ai-network-governance-01 afirma que comunicar restricciones a la IA no sustituye su aplicación programática e independiente.
  • La propuesta compatible, la RPC aceptada y el rollback solicitado son afirmaciones distintas de la autorización efectiva y del estado final del servicio.

El modelo recomienda una acción que existe en el catálogo. El parámetro cae dentro del rango. El objetivo no aparece en la lista protegida. El guardarraíl devuelve «permitido».

Todavía faltan las preguntas que importan.

¿Qué versión del catálogo se consultó? ¿La lista del operador ya incluía la última revocación? ¿El contador sobrevivió al reinicio? ¿La configuración que se resumió en el prompt era la misma que usó el ejecutor? ¿La operación cambió realmente el dispositivo? ¿Mejoró el servicio?

La revisión 01 de draft-smith-opsawg-ai-network-governance, publicada el 27 de septiembre de 2026, acierta al separar recomendación y ejecución. Es un Internet-Draft individual activo, sin flujo RFC, respaldo formal de la IETF ni consenso de grupo de trabajo. El encabezado indica intención informativa. No es una norma ni una demostración de despliegue.

El alcance reúne cuatro condiciones: el sistema corre en el dispositivo o accede directamente a su plano de gestión; consulta un servicio de IA externo; puede modificar configuración o estado sin aprobación humana por acción; y emplea NETCONF, RESTCONF, gNMI u otra interfaz normalizada. Una herramienta que solo aconseja queda fuera.

El servicio externo analiza contexto y devuelve una propuesta estructurada. El agente local recoge telemetría, detecta la anomalía, evalúa la propuesta y opera el equipo. El servicio de IA no debe tener acceso directo al dispositivo. La separación es valiosa, pero convierte al agente local en el punto privilegiado donde se cruzan política, historial y credenciales.

El Action Registry fija las acciones implementadas, sus parámetros, riesgo y reversibilidad. La Operator Allow List selecciona las autorizadas en ese despliegue. Una sugerencia fuera del registro se descarta y el modelo no puede inventar tipos nuevos. Los parámetros se validan al margen de la confianza declarada.

El borrador pide incluir en el prompt acciones admitidas y bloqueadas, objetivos protegidos, límites y techo de riesgo. Esto evita propuestas inútiles y facilita que la IA explique una escalada. Pero el texto insiste: la comunicación no sustituye la aplicación programática. Cada propuesta pasa por una validación independiente. Además, la defensa debe repetirse en prompt, parser, guardarraíl y punto de interacción.

Esa frase impide que la ingeniería de prompts se disfrace de control de acceso. También obliga a producir un comprobante por acción. Debe unir la política aprobada, versiones de registro y listas, reglas de objetivos, rangos, riesgo, contadores, degradación, revocación, propuesta, resultado del parser, decisión, validación final, operación autenticada, estado previo, respuesta, verificación fresca y desenlace de rollback o escalada.

Guardar solo el hash del prompt no resuelve el problema. El prompt es una proyección para un tercero: puede omitir secretos, resumir patrones o describir un presupuesto anterior. Guardar solo «guardarraíl superado» tampoco permite saber qué entradas hicieron verdadero el veredicto.

Los límites convierten esta necesidad en un problema de estado. El apéndice propone, entre otros valores, cinco acciones por hora como predeterminado y veinte como máximo, tres acciones por objetivo al día y hasta cinco, además de límites de consultas y reintentos. Son propuestas, no umbrales universales demostrados. No hay en las fuentes congeladas una base empírica para toda red.

Decir que una acción es la quinta de la hora requiere eventos completos, orden temporal, definición de ventana y continuidad tras la conmutación. Cooldown, reintentos, revocación y nivel de degradación también viven en la historia.

El borrador aconseja controles sin estado cuando sea posible, derivados de una auditoría persistente para que un reinicio no borre los contadores. Esto no elimina el estado; lo deposita en el registro y en la función que lo proyecta. Integridad, orden, retención, relojes y activación de políticas pasan a ser parte de la seguridad.

Los ejemplos de fallo seguro son correctos: si no se consultan los contadores, asumir el límite agotado; si falla la coincidencia de objetivos, asumir el objetivo protegido; si el registro no está disponible, bloquear. Lo desconocido no debe convertirse en permiso.

Después está el dispositivo. El agente debe capturar el estado anterior, recoger telemetría nueva y volver atrás si la condición no mejora o empeora. Los datos en caché o suprimidos no valen como verificación.

Pero una captura de configuración no recupera paquetes descartados, sesiones rotas, una cola ya consumida ni temporizadores remotos. El rollback es otra operación hacia delante sobre un sistema que sigue cambiando. Necesita respuesta, lectura posterior y evidencia de servicio propias.

Algo parecido ocurre con el requisito de un solo objetivo. Una interfaz o instancia puede pertenecer a un dominio compartido. La sintaxis puede ser local mientras el efecto viaja por convergencia y redistribución del tráfico.

El tratamiento de la inyección de prompt parte de datos generados por el dispositivo: logs o descripciones pueden influir al modelo. Sanear ayuda. La defensa arquitectónica es mantener a la IA como consejera y validar independientemente. Por eso una prueba debe recorrer parser, catálogo, objetivos, rangos, contadores, ejecución y failover; no basta con mostrar una negativa del modelo.

El borrador denomina a la auditoría mecanismo principal de responsabilidad y recomienda integridad y retención externa. Allí debe residir el comprobante de política. Registrar la configuración al arrancar es útil, pero no explica qué política efectiva admitió una acción después de varias recargas.

Los autores dicen que los conceptos proceden de experiencia operacional en producción. Es una declaración de autor, no un estudio independiente con población, métricas o resultados. Los números y supuestos siguen necesitando validación local.

La especificación inicial mínima de Heng Lu orienta el núcleo verificable: la IA no amplía el vocabulario; el estado desconocido cierra; el agente no cambia sus reglas; toda mutación identifica la autoridad exacta. La separación de capas impide confundir «permitido» con estado físico. La primacía del código en marcha exige lectura posterior y servicio observado.

Fuentes