AIPREF en la fecha limite: auditoria del vocabulario que los agentes deben leer

Dos drafts del IETF vencen en el IESG el 31 de agosto de 2026. Uno de ellos advierte en su portada que su contenido no refleja el consenso del working group. Leimos cada revision, implementamos el algoritmo de resolucion y lo apuntamos a 10.000 dominios.

Antes de que un agente pague algo, hace un fetch. Nuestras auditorias previas cubrieron lo que pasa despues de que el fetch tiene precio: el handshake de x402, el rail de settlement, los caps de la wallet. Esta cubre la capa de arriba. Si el publisher queria ese fetch, y si ese deseo esta escrito en una forma que una maquina pueda parsear.

La respuesta del IETF a esa pregunta es el working group AI Preferences, AIPREF. Fue chartereado el 9 de abril de 2025 en el area Web and Internet Transport, con Mark Nottingham y Suresh Krishnan como chairs. Sus dos entregables son un vocabulario para expresar preferencias y un mecanismo para adjuntarlas al contenido. Ambos tienen como milestone el 31 de agosto de 2026 para llegar al IESG.

Eso es dentro de dos dias contando desde la fecha de este post. Asi que los auditamos.

Dos documentos, una fecha limite

La pagina de documentos del working group lista draft-ietf-aipref-vocab, hoy en revision 07, y draft-ietf-aipref-attach, en revision 05. Ambos son Standards Track. Ambos se refrescaron el 18 de agosto de 2026 y llevan la fecha interna 19 de agosto de 2026. Ambos expiran el 20 de febrero de 2027.

El historial de revisiones es lo primero que vale la pena leer. Los dos documentos entraron en In WG Last Call el 4 de septiembre de 2025. Los dos volvieron a WG Document el 3 de noviembre de 2025. Ninguno reentro en last call. En el datatracker su estado IESG hoy es I-D Exists, el estado que significa que el IESG no empezo a procesarlos.

Despues el draft de attachment se quedo quieto. La revision 04 se publico el 28 de octubre de 2025; el documento expiro el 1 de mayo de 2026; la revision 05 llego el 18 de agosto de 2026. Nueve meses y medio entre revisiones, tres y medio de ellos expirado, para el documento que define el nombre del header HTTP y la directiva de robots.txt que todos deberian emitir.

El draft del vocabulario es el mas notable de los dos. Desde la revision 06 lleva una Note to Readers, antes del Status of This Memo, que citamos completa:

As detailed below, this is a working document. Its contents DO NOT REFLECT CONSENSUS of the Working Group either in whole or part. Presense or absense of any particular text does not indicate consensus, and this document is published solely as a basis of further discussion.

La seccion 4, la que define las categorias, lo repite localmente: "NOTE: This section does not yet have consensus." Revisamos cada revision de la 00 a la 07. La nota aparece por primera vez en la 06, publicada el 27 de abril de 2026, y sobrevive en la 07. No aparece en el draft de attachment.

La division es informativa. Donde poner la preferencia esta resuelto. Que se puede decir, no. Y lo que un agente autonomo necesita es lo segundo.

El vocabulario se hizo mas chico

Catorce meses de revisiones se movieron en una sola direccion. Extrajimos la seccion 4 de cada revision publicada:

// draft-ietf-aipref-vocab, seccion 4, por revision

-01  Text and Data Mining · AI Training · Generative AI Training
     · Search · AI Inference
-02  Automated Processing · AI Training · Generative AI Training
     · AI Use · Search
-03  Automated Processing · AI Training · Generative AI Training · Search
-04  Automated Processing · Foundation Model Production
     · AI Output · Search
-05  Foundation Model Production · Search
-07  AI Model Training (train-ai) · Search (search)

La revision 01, del 18 de junio de 2025, definia AI Inference como "the act of using one or more assets as input to a trained AI/ML model as part of the operation of that model (as opposed to the training of the model)." Esa frase es una descripcion precisa de lo que pasa cuando un agente hace fetch de una pagina y la pasa a un modelo a traves de un gateway. Se elimino en la revision 03. Sus sucesoras bajo otros nombres — AI Use en la 02, AI Output en la 04 — se eliminaron a su vez.

Lo que sobrevive en la revision 07 son dos categorias. AI Model Training es "using an asset to modify the learned parameters of an AI model that is used to generate synthetic content in one or more modalities." Search es el uso en una aplicacion "where the primary purpose of the application is to select assets and direct users to the location of those assets", condicionado a enlazar de vuelta y a que los excerpts sirvan para evaluar relevancia. Y despues, explicitamente: "This category does not include the use of assets to generate summaries."

Entonces un agente que resume no esta haciendo Search. Tampoco esta entrenando. Bajo el vocabulario que el IETF esta a dos dias de someter, un agente autonomo que hace fetch de una pagina para responder una pregunta no cae en ninguna categoria definida.

La palabra "agent" no aparece en ninguna revision del draft del vocabulario.

La revision 07 quito la escalera

Hasta la revision 06 habia un mecanismo que cubria parcialmente el hueco. Las categorias anidaban, y las preferencias bajaban por la jerarquia. La seccion 5 de la revision 06 resolvia una preferencia en tres pasos: gana la declaracion explicita; si no, si la categoria es subconjunto propio de otra, se recursa al padre; si no, unknown. Las extensiones estaban restringidas en consecuencia: "Any future extensions to this vocabulary MUST NOT introduce additional categories that include existing categories defined in the vocabulary." Solo subconjuntos, nunca superconjuntos.

La revision 07 elimina las dos mitades. El algoritmo de resolucion son ahora dos frases sin recursion: gana la declaracion explicita, "Otherwise, the preference for that category is unknown." La regla de extension paso a ser "The definition of the extension MUST define how any potential overlap between usage categories is resolved."

La consecuencia es concreta. Bajo la revision 06, un publisher que escribiera un disallow amplio habria cubierto categorias mas estrechas definidas despues. Bajo la revision 07, toda categoria futura arranca en unknown, sin importar lo que el publisher ya dijo. Y el documento se niega a tapar el hueco: "One approach for dealing with an unknown outcome is to assign a default value. This document takes no position on what default might be assigned."

La revision 07 tambien reescribio la seccion de alcance como una lista de cosas que la especificacion no hace. No "ensure that preferences are followed", no "address if, how, or when preferences should be followed or not-followed", y no "address technical, legal, contractual, or other mechanisms that might create a stronger requirement to follow or not follow preferences."

El draft de attachment hizo un movimiento menor en la misma direccion. La revision 04 decia "Servers MUST retain any preferences associated with a request" cuando ese contenido se sirve despues. La revision 05 dice "Servers can use any preferences associated with a request." Un MUST paso a ser un can.

Que dice la web realmente

Las especificaciones son baratas de leer y caras de verificar. Asi que el 29 de agosto de 2026 crawleamos los primeros 10.000 dominios del Majestic Million, pidiendo /robots.txt sobre HTTPS con redirects seguidos, y contando solo respuestas con status 200 y content type no HTML. Calificaron 6.760 dominios.

Los tres deployments de Content-Usage valen nombrarlos, porque son solo tres. launchpad.net y semafor.com emiten los dos Content-Usage: ai=n. Esa clave no existe en el vocabulario actual. Es el ejemplo de draft-ietf-aipref-attach-00, del 27 de mayo de 2025, reemplazado por train-ai=n en la revision 02 hace catorce meses. Ambos sitios citan la misma fuente en un comentario de robots.txt: robotstxt.com/ai, un generador de plantillas que describe Content-Usage como una directiva que "Google has proposed" y que sigue trayendo el ejemplo viejo.

El tercero es follow.it, que emite Content-Usage: bots=y, train-ai=n dentro de un bloque marcado # START nuxt-robots. Lo genera el modulo @nuxtjs/robots, cuya documentacion dice que la directiva "follows the IETF AI Preferences specification" y ofrece cuatro categorias: bots, train-ai, ai-output, search. Dos de ellas no estan en la especificacion. ai-output existio solo en la revision 04, entre octubre y diciembre de 2025. bots nunca existio en ninguna revision.

En el subconjunto del top 1.000, 741 dominios tenian un robots.txt legible. Uno sirvio un header de respuesta HTTP Content-Signal. Ninguno sirvio un header Content-Usage. Tambien revisamos el registro IANA de HTTP Field Names el mismo dia: 260 entradas, y ni Content-Usage ni Content-Signal estan entre ellas. Toda la seccion de IANA considerations del draft de attachment es ese unico registro, todavia pendiente.

Correr la especificacion contra el mundo real

Contar directivas no es lo mismo que leerlas. La seccion 6 de la revision 07 define la serializacion como un structured-field dictionary de RFC 9651: las claves son las etiquetas de categoria, los valores son los tokens de un byte y y n, y la seccion 6.4 dice que las etiquetas desconocidas MUST be ignored. Asi que implementamos las secciones 5 y 6 en unas treinta lineas y pasamos por ahi cada directiva que recolectamos.

from http_sfv import Dictionary, Token

CATEGORIES = ("train-ai", "search")   # vocab-07, seccion 4

def resolve(field_value):
    d = Dictionary(); d.parse(field_value.encode("ascii"))
    out = {}
    for c in CATEGORIES:
        v = getattr(d.get(c), "value", None)
        # clave ausente, valor no-token, o token distinto de y/n -> unknown
        out[c] = {"y": "allow", "n": "disallow"}.get(
            str(v) if isinstance(v, Token) else None, "unknown")
    ignored = [k for k in d.keys() if k not in CATEGORIES]
    return out, ignored

Contra las 419 lineas de Content-Signal que recolectamos de 396 dominios, el resultado es inequivoco: cero producen una preferencia definida para alguna de las dos categorias. Lo causan dos mismatches independientes. La clave esta invertida — Cloudflare escribe ai-train, el vocabulario define train-ai, asi que 413 de las lineas aportan una clave que hay que ignorar. Y el alfabeto de valores difiere — en las 419 lineas contamos 598 instancias de yes, 376 de no, 268 de reference, y cero de y o n. Incluso search, la unica etiqueta que ambos vocabularios escriben igual, resuelve a unknown, porque yes es un token de structured field perfectamente valido que simplemente no es y.

A las lineas de Content-Usage les va marginalmente mejor. Dos resuelven a unknown en ambas categorias, porque ai es una clave ignorada. Una resuelve: follow.it da train-ai=disallow, y search=unknown.

Un dominio en el top 10.000, salido de un default de framework. Esa es la superficie legible actual del vocabulario de AI preferences del IETF.

La spec de vendor tiene la categoria que los agentes necesitan

La asimetria no es solo de adopcion. Es de expresividad. La documentacion de managed robots.txt de Cloudflare, actualizada el 3 de agosto de 2026, define tres signals. search y ai-train mapean a grandes rasgos con el par del IETF. El tercero no mapea con nada:

ai-input: inputting content into one or more AI models (e.g., retrieval augmented generation, grounding, or other real-time taking of content for generative AI search answers).

Esa es la categoria AI Inference eliminada, viva en produccion. En el top 1.000, 16 de los 23 dominios con Content-Signal expresan una preferencia sobre ai-input. En los 10.000 completos, la clave aparece 135 veces. Cloudflare tambien esta probando un cuarto campo, content-use, con tres valores — immediate (interactuar pero no guardar nada), reference (indexar, citar, enlazar de vuelta), full (resumir y reproducir) — y trae use=reference en el default gestionado. Contamos 268 instancias en el mundo real.

El encuadre difiere tanto como el vocabulario. El bloque gestionado de Cloudflare abre con "As a condition of accessing this website, you agree to abide by the following content signals" y cierra declarando que las restricciones son reservas expresas de derechos bajo el articulo 4 de la Directiva UE 2019/790. Esta escrito como un contrato. El vocabulario del IETF se niega explicitamente a abordar mecanismos contractuales, y el charter de AIPREF pone fuera de alcance "technical enforcement of preferences", "application layer protocols for authenticating or authorizing clients and/or crawlers", "establishment of registries of preferences relating to content" y "auditing and other transparency measures for AI training".

La documentacion de Cloudflare no menciona al IETF, ni AIPREF, ni Content-Usage en ninguna parte. Revisamos la pagina renderizada: cero ocurrencias de cada uno.

La exclusion de registries merece su propia frase. Como los registries estan fuera del alcance del charter, la revision 07 dice "This document has no IANA actions", y extender el vocabulario requiere "a standards-track RFC that updates this document." Agregar una categoria para retrieval de agentes no es un registro. Es un RFC.

Nadie en el working group habla de dinero

Mientras tanto, lo que el charter excluye se esta escribiendo igual, como submissions individuales.

draft-reilly-aipref-compliance-00, del 2 de agosto de 2026, define un AI Usage Compliance Record: una estructura que liga el asset recuperado, la preferencia vigente en el momento del retrieval y la categoria de uso que la entidad procesadora le asigno, con un esquema de agregacion para que una sola firma cubra cantidades muy grandes de registros. Ese es el rastro de auditoria que el charter excluye.

draft-wallace-aipref-grant-binding-02, del 18 de agosto de 2026, esta mas cerca de nuestro problema. Observa que una preferencia "expresses a reservation. It does not, by itself, provide a verifiable, revocable record of a specific grant that lifts a preference for a specific party." Propone una credencial revocable y verificable offline que nombra una parte, un asset y una categoria de uso. Y aclara sin rodeos que "is not an enforcement or access-control mechanism."

Un grant que levanta una reserva para una parte nombrada es, economicamente, una compra. Asi que buscamos la otra mitad. En los diez documentos de la pagina de AIPREF — los dos drafts del working group y las ocho submissions individuales — x402 aparece cero veces, 402 como status code aparece cero veces, micropayment aparece cero veces, y la palabra payment aparece exactamente una vez: en draft-reilly-aipref-compliance-00, en la lista de lo que no cubre.

El grep inverso es igual de limpio. El monorepo de x402 en HEAD e398a9e, del 28 de agosto de 2026, tiene cero ocurrencias de aipref, content-usage, content-signal, train-ai, ni siquiera robots.txt. El repositorio de la especificacion de MCP en HEAD ca4ab30 y el de A2A en HEAD f63dbb4 tienen cero ocurrencias de aipref.

Dos capas que se necesitan, sin una sola referencia en ninguna direccion.

Que significa para LLM4Agents

LLM4Agents es el gateway al que un agente llama cuando quiere un modelo, y el rail sobre el que paga. Cuando un agente hace fetch de una pagina y empuja el texto a un completion, nuestro gateway es la entidad procesadora en los terminos de AIPREF. Eso nos pone del lado receptor de cada uno de estos hallazgos.

El primero es que la senal es casi ilegible hoy. Una implementacion conforme de la revision 07 extraeria una preferencia de un dominio de cada 10.000. Quien despliegue solo soporte de AIPREF y llame compliant a su camino de retrieval esta desplegando un no-op. La senal real esta en otro lado. Parseamos los grupos de reglas de los 737 dominios del top 1.000 con robots.txt legible: 250 nombran un crawler de entrenamiento y 199 le sirven un Disallow: / completo, mientras que 195 nombran un fetcher de clase agente y 138 bloquean alguno por completo. 62 de ellos bloquean entrenadores y dejan sin bloquear a todos los fetchers de agente. Los publishers estan trazando la linea entre entrenar y leer que el vocabulario no puede expresar, y la trazan con nombres de bot.

El segundo es que la categoria en la que operamos no existe en el estandar. Nuestro trafico es retrieval en tiempo de inferencia, y el IETF elimino esa categoria en septiembre de 2025 y quito, en agosto de 2026, la regla de subsuncion que habria dejado que una preferencia mas amplia la cubriera por implicacion. Bajo la revision 07 la respuesta honesta para un fetch de retrieval de agente es unknown, y el documento se niega a decir a que default equivale unknown. Esa es una decision de politica empujada al operador del gateway, y deberiamos tomarla deliberadamente y no por omision.

El tercero es donde esta la oportunidad. El grant binding describe una credencial que levanta una reserva para una parte nombrada, y se niega a decir como esa parte llega a merecerla. x402 responde exactamente esa pregunta para un cliente walk-up sin relacion previa: cotizar un precio en el 402, liquidar en stablecoins, servir el contenido. Un publisher que hoy escribe ai-input=no dice que no porque la unica alternativa es consumo sin precio. Un 402 convierte eso en un precio. La distancia entre los dos documentos es un mercado, y ninguno de los dos lados escribio el puente.

Como mantenerse en la frontera

Concreto, ordenado por lo que hariamos primero.

Leer los tres vocabularios, resolver de forma determinista, loguear el desacuerdo. Nuestro camino de fetch deberia parsear Content-Usage, Content-Signal y el License: de RSL, y registrar cual de ellos hablo en cada retrieval. El crawl dice que la relacion de cobertura es de 132 a 1 a favor del vendor, asi que una implementacion que solo lea el campo standards-track esta ciega por construccion. La seccion 6.6 de la revision 07 permite formatos alternativos siempre que el mapeo este definido; nadie definio el mapeo de Content-Signal, asi que deberiamos publicar el nuestro: rename de clave, alfabeto de valores, y una declaracion explicita de que ai-input no tiene equivalente IETF.

Elegir un default explicito para unknown y ponerlo en la API. La especificacion se niega a hacerlo. Cada retrieval por nuestro gateway deberia llevar una terna resuelta — allow, disallow, unknown — para training, search e input en tiempo de inferencia, y unknown tiene que resolver a una postura documentada que el caller pueda ver y sobreescribir. El silencio no es consentimiento, y tampoco es rechazo; es un campo sobre el que el operador del agente tiene que poder razonar.

Emitir el compliance record antes de que alguien lo exija. La estructura del draft de Reilly — asset, preferencia vigente en el retrieval, categoria asignada — esta cerca de lo que nuestro camino de billing ya sabe, porque ya registramos que se pidio y que se cobro. Ligar la preferencia que leimos al pago que liquidamos es una adicion chica a un recibo existente, y es el artefacto que convierte "respetamos preferencias" en algo que un publisher puede verificar. Compone con los atributos de telemetria que ya emitimos.

Prototipar el camino grant-por-pago contra un publisher real. Tomar un dominio que publique ai-train=no, ofrecer una excepcion con precio sobre x402, y liquidarla. El draft de grant binding aporta la forma de la credencial; x402 aporta el rail; la pieza que falta es un resource server que trate una liquidacion pagada como el evento que emite la credencial. Eso es un prototipo de fin de semana y un dato genuinamente nuevo, porque hoy ningun draft de ninguno de los dos ecosistemas referencia al otro.

Seguir el milestone del 31 de agosto y el estado de last call, no el numero de revision. La senal a vigilar no es un draft nuevo. Es si el vocabulario reentra en WG Last Call y si la Note to Readers desaparece. Mientras esa nota siga ahi, la seccion 4 no esta cerrada, y cualquier categoria sobre la que construyamos supuestos de producto todavia puede cambiar.