Resumen

  • draft-das-eu-ai-act-execution-enforcement-00, fechado el 5 de septiembre de 2026, es un Internet-Draft individual activo con destino Informational. No es una norma del IETF ni un dictamen de cumplimiento legal.
  • El diseño conserva una operación consecuente como Candidate Act sin efecto, valida condiciones configuradas, emite autoridad limitada al acto exacto y vuelve a verificarla en un Finality Sink antes del primer efecto externo protegido.
  • La sección 35 afirma que la propiedad solo cubre efectos mediados por esa frontera. Su figura de una API externa directa junto al sink excluye expresamente esa ruta.
  • La referencia Python v0.1.0 modela una única API local de registro de efectos. El repositorio y el borrador la califican como demostración, no como producto de seguridad de producción ni motor jurídico.
  • Para sostener una promesa sistémica hace falta un recibo de cierre de superficie: rutas completas, versión de cada enlace, privilegios que permiten eludirlo, excepciones y pruebas negativas por camino.

Una denegación correcta puede no decidir nada

La secuencia técnica propuesta resulta atractiva. Una IA calcula o selecciona una acción. Esa acción todavía no paga, publica, escribe, envía ni mueve una máquina. Primero se convierte en un Candidate Act. Una función protegida revisa las condiciones legibles por máquina que otra autoridad ya definió. Después emite una autorización ligada al contenido, destinatario, destino, época de política, caducidad y sink. El punto final comprueba de nuevo esos datos y consume la autorización al efectuar.

Así se evita confundir identidad con permiso. Que una carga de trabajo esté autenticada no autoriza todas sus decisiones. Que una persona aprobara 500 euros no permite cambiar luego la cifra a 5.000. Que exista un registro posterior no demuestra prevención.

Sin embargo, todo depende del verbo “pasar”. El sink solo gobierna los actos que pasan por él. El borrador lo muestra sin rodeos: el agente se bifurca hacia el sink y hacia una API externa directa. Para esta última, dice, no se establece protección de finalización.

El fallo posible no está dentro del verificador. Está en el mapa. Un servicio puede imponer autorización en el gateway ordinario mientras un usuario técnico conserva acceso directo al backend. Una publicación puede exigir aprobación por la interfaz y seguir apareciendo si alguien escribe en el almacén servido al público. Un proxy de base de datos puede mediar la cadena principal y dejar activa una conexión de emergencia. Son ejemplos analíticos, no acusaciones contra despliegues reales.

El perímetro se define por el efecto

El texto acierta al no exigir un sink para cada lectura, token o paquete. Habla de transiciones consecuentes seleccionadas. La política mínima debería concentrarse allí donde aparece el primer resultado utilizable: el cargo enviado, el mensaje transmitido, la fila confirmada, el archivo liberado o el actuador activado.

Esa selección no autoriza a proteger solo una interfaz. Si dos rutas producen la misma consecuencia, ambas pertenecen al perímetro o una debe constar como excepción. Inventariar por nombres de producto oculta equivalencias: un broker y un SDK pueden enviar el mismo mensaje; una API y una credencial de almacenamiento pueden publicar el mismo objeto; un gateway local y el servicio receptor pueden observar momentos distintos de efectividad.

La atomicidad remota agrava el problema. El borrador permite unir localmente verificación, consumo y commit. También admite que validar una solicitud de Internet no la vuelve atómica. Puede hacer falta un sink en el destinatario, idempotencia, outbox transaccional o coordinación de estados. Por eso la prueba debe observar el lugar donde el efecto se vuelve utilizable, no detenerse en un “permitido” o “denegado” del primer proxy.

Código ejecutable, conclusión limitada

La versión 0.1.0 es más útil que una arquitectura puramente dibujada. Implementa JSON canónico, SHA-256, Ed25519, prueba de posesión, épocas, nonce y consumo local con SQLite. En un escenario sintético de soporte al cliente, una sustitución de propósito se niega antes de registrar el efecto.

El README declara la premisa: el estado sin efecto existe porque la única API que registra efectos vive dentro del sink. También advierte que, en una instalación real, egreso de red, commit, pagos, archivos, herramientas y demás caminos deben mediarse de forma equivalente.

No hay que inflar esa prueba. La separación lógica ocurre en un proceso Python. No ofrece HSM o TEE de producción, alta disponibilidad, consenso distribuido, verificación formal, atomicidad remota completa ni evaluación regulatoria. Es evidencia de que un mecanismo puede funcionar bajo una topología cerrada construida para la demostración; no es evidencia de que una empresa desconocida tenga esa topología.

Un recibo que empiece por las salidas

El recibo de cierre debería formular primero la consecuencia y después recorrer hacia atrás todas sus entradas. Debe enumerar gateways, colas, conexiones, herramientas, rutas de archivos, control de nube, egreso y servicios receptores. A cada vía le asignaría un límite protegido, una identidad de sink, la versión de ruta y política, y los principales o credenciales capaces de usarla.

Las rutas de migración, lote, respaldo, administración y ruptura de emergencia no son notas al pie. Deben aparecer con la autoridad que las mantiene. Después vendrían pruebas con autorización ausente, caducada, revocada, repetida, alterada o ligada al sink equivocado. Para aprobar, ninguna ruta inventariada puede producir el efecto.

Una vía no probada queda desconocida. Una vía deliberadamente abierta estrecha la afirmación. Esta honestidad es preferible a convertir “fail-closed” en una etiqueta de componente.

El recibo es una recomendación de Daniel Kade. No decide si la regla codificada refleja bien la ley. El propio borrador deja fuera la clasificación de alto riesgo, la prohibición de prácticas, la suficiencia de supervisión humana y la conformidad general. También limita la posible labor del IETF a piezas técnicas —representación, canonicalización, evidencia, autorización, enlace, vigencia, revocación y errores—, no a interpretar legislaciones.

La enseñanza sigue la prioridad de código operativo de Heng Lu: el diseño debe someterse a una prueba observable y mínima. Un sink seguro puede negar todo lo que recibe. La gobernanza debe demostrar además que recibe todo lo que afirma gobernar.

Fuentes