AIPREF (AI usage preferences)

AIPREF (AI Preferences) is the IETF working group's effort to standardize a machine-readable way for content owners to express how their content may be used by AI systems¹. The preference is carried by a Content-Usage signal, attached either as an HTTP response header or as a rule in robots.txt, and it draws on a small controlled vocabulary: as of the current drafts, the categories are train-ai (use in AI model training) and search (use in search-style applications that direct users back to the source), each set to y (allow) or n (disallow)²³.

The point of AIPREF is to replace the confusing array of non-standard, vendor-specific signals (assorted noai meta tags, custom robots directives, terms-of-service clauses) with one interoperable vocabulary. It sits at a specific layer of the stack: it declares a usage preference, not the requester's identity and not an enforcement guarantee. The working group charter puts authenticating or authorizing crawlers explicitly out of scope¹, which is exactly the boundary that Web Bot Auth occupies. AIPREF answers "what may be done with this content"; Web Bot Auth answers "who is asking."

Status in 2026

AIPREF is genuinely emerging, and both of its halves are adopted working-group documents that are still pre-standardization. An Internet-Draft is work in progress that may change, expire, or be replaced before it becomes an RFC, and a draft revision auto-expires six months after posting; that expiry is a routine part of the process, not a signal the work has been abandoned. The vocabulary draft, draft-ietf-aipref-vocab, is a current working-group document on the Proposed Standard track (revision 06, expiring October 2026); it defines the train-ai and search categories and their y/n values, and notes in its own text that it does not yet have full consensus². The attachment draft, draft-ietf-aipref-attach, which defines the Content-Usage header and the robots.txt Content-Usage rule, is also an adopted working-group document, carrying an August 2026 milestone to send a standards-track specification to the IESG; its latest published revision (-04, October 28, 2025) has lapsed under that six-month rule, with no newer revision posted yet³. Several adjacent individual drafts (real-time bindings, content-bound consumption preferences, display-based preferences, exclusions) are tracked but not adopted.

So the working group is active on both halves, but neither is finalized: the vocabulary lacks full consensus, and the most recent header specification sits in a lapsed revision. The syntax can still change before it standardizes, so the practical state is "watch and prepare," not "deploy."

A second honest caveat: AIPREF is a preference, not an obligation. Like robots.txt before it, it expresses what a content owner would like automated systems to do; whether a given AI company honors train-ai=n is a function of that company's policy and the surrounding legal and regulatory environment, none of which the signal itself can compel. The drafts define the preference vocabulary; they do not establish that major AI-training or AI-search products will honor these values. Setting search=y or search=n records an intent whose effect depends entirely on voluntary adoption by those products.

How to apply

The useful framing is to place AIPREF correctly among the signals you already control, and to avoid over-implementing an unfinished spec:

• Locate it as the preference layer, not access or identity. A site can carry several independent signals: robots.txt for crawl access, llms.txt for AI-readable guidance, AIPREF for usage preference, and Web Bot Auth for requester identity. They answer different questions and coexist; AIPREF can even ride inside robots.txt as a Content-Usage rule.
• Track the working group rather than ship an unfinished header. The Content-Usage header's most recent specification sits in a lapsed draft revision, so it is not a stable target yet. If you experiment today, treat any robots.txt Content-Usage line (using the current train-ai/search vocabulary) as a non-stable, experimental signal, and monitor the working group for syntax changes before relying on it.
• Separate preference from enforcement in your own planning. Setting train-ai=n records an intent; it does not stop training. Treat it as a documented, machine-readable statement of preference, and rely on contracts, licensing, or technical access control where you need an actual barrier rather than a request.

What to skip:

• Implementing the Content-Usage header as though it were a finished standard. Its most recent specification sits in a lapsed draft revision; the syntax may still change before publication.
• Treating AIPREF as an opt-out that guarantees your content is excluded from AI training. It is a preference signal whose effect depends on voluntary compliance.
• Conflating AIPREF with crawler verification. AIPREF does not tell anyone who the requester is; that is a different problem with a different (also emerging) standard.

How it relates to other concepts

• Complementary to Web Bot Auth: AIPREF is the preference half (what you may do with the content), Web Bot Auth is the identity half (cryptographically verifying which crawler is asking). The AIPREF charter putting crawler authentication out of scope is what makes the two cleanly complementary rather than overlapping.
• A complementary preference layer alongside legacy robots.txt and llms.txt: robots.txt governs whether a resource may be fetched; llms.txt offers a curated AI-readable map; AIPREF expresses what the fetched content may be used for. AIPREF is not a successor to robots.txt (it reuses robots.txt as one of its carriers); it answers a different question alongside it.
• Part of the AI access, identity, discovery, and usage-preference signal family alongside AI crawler bots (the agents these signals are aimed at) and discovery-side protocols like IndexNow. Together these form the surface a publisher has over how AI systems discover, fetch, identify against, and use a site. AIPREF itself is the usage-preference signal in that family, not an access-control or enforcement mechanism.
• Upstream of generative engine optimization decisions: a site that signals train-ai=n but search=y is making a deliberate choice to stay visible in AI search while declaring a preference against training use, a distinction GEO strategy increasingly has to reason about explicitly.