AI training preference signal: one draft, not a standard

Google's announcement on 30 October 2026 links to a document whose own boilerplate disclaims it: "This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process." The AI training preference signal is a single-revision individual Internet-Draft, not an adopted standard, and Google states an aim for 2027. Add the four robots.txt lines anyway, and keep every per-crawler rule you already have.

Here are the facts you need before anyone forwards you a headline about Google adopting an IETF standard.

• The document: draft-kelley-aipref-training-preference-signal-00, "Machine-Readable Training Preference Signal", by Kevin Kelley, published 30 October 2026, expiring 3 May 2027. Intended status: Standards Track.
• Its standing: the IETF Datatracker lists it as an Active Internet-Draft (individual) with no stream, no intended RFC status and no IESG state. It is not an AIPREF working-group document.
• What it defines: one policy token, __usage_ai-training, written inside robots.txt. The draft says it "introduces no new directive names and no new grammar", and it has no IANA actions.
• Google's position: "We aim to support this new control along with other AI providers in 2027, and will provide updates on our progress."
• Enforcement: not on the table. The AIPREF working group's approved charter lists "Technical enforcement of preferences" as explicitly out of scope.

What Google actually said on 30 October 2026

The post, Supporting a shared AI training control for websites, is by John Mueller and announces "our plans to support a shared AI training control in robots.txt". It describes the work as "based on work from the AIPREF working group at the Internet Engineering Task Force (IETF)" and builds on Google-Extended, which Google calls "the AI training control we've offered since 2023".

Two sentences in it matter operationally. First, on precedence: "When a website uses this policy token to opt out of training in its robots.txt file (and Google-Extended is not explicitly specified), Google plans to interpret that as if the publisher had disallowed Google-Extended." Second, on your existing rules: "Existing company-specific controls will continue to function alongside this new joint signal."

There is a referral consequence Google states plainly, and it is the part most summaries drop: "Websites that specifically allow Google-Extended are eligible to appear in responses and receive clicks via grounding in Gemini Apps." An opt-out is therefore a traffic decision as well as a licensing one. If your public docs or catalogue are a discovery channel, that is the trade you are making. We wrote about the same split in the agentic web and the second audience that does not click, and it applies here unchanged.

One thing Google's post does not do: name the token. The body says "a shared 'policy token'" and hyperlinks the phrase "a shared AI training control" to the Kelley draft's Datatracker page. The literal string __usage_ai-training does not appear anywhere on the page. You get the token from the draft, not from Google.

What the AI training preference signal defines, in full

The entire mechanism is a product token you place in a User-Agent group. Section 4.1 of the draft states: "This document defines the policy token __usage_ai-training." Figure 1 of the draft is the complete worked example:

User-Agent: __usage_ai-training
Disallow: /
Allow: /press-kit/

The draft glosses that as a preference "against AI training for all paths except those under /press-kit/, for which it expresses a preference in favor". The semantics in Section 4.2 are three-valued, and the third value is the useful one: a disallowed path is a preference against the described use, an allowed path is a preference in favour of it, and an absent token means no preference has been expressed. Silence is not refusal.

The token conforms to the product-token syntax in Section 2.2.1 of RFC 9309 — letters, underscore, hyphen — and "Consumers MUST match policy tokens exactly, apart from case, as for any product token". A single group may name several policy tokens on consecutive User-Agent lines, so one block can carry future tokens when they exist. There is no HTTP header and no meta tag in this draft; robots.txt is the only carrier.

Why a blanket Disallow does not opt you out

If you already have User-Agent: * followed by rules you consider restrictive, that does nothing here. The draft is explicit: "wildcard groups (i.e., User-Agent: *) MUST NOT be interpreted as matching the policy token." A preference has to be expressed in a group that names the token, by itself.

Nor is the signal a crawl control. Section 4.4 says "This policy token is not a directive for crawling behavior", and Section 4.3 treats content-usage preferences and crawl rules as "independent and orthogonal". A consumer may use preferences to inform crawling, and Section 4.5 adds that "Private agreements MAY override preferences expressed via this mechanism". So a vendor with a licence can train on content the token says no to, legitimately, by the draft's own rules.

The dependency chain nobody mentions in the headline

The draft borrows its definition of AI training from the working group's vocabulary document, where it means "Using an asset to modify the learned parameters of a generative AI model." That document is not published either. As of 1 November 2026:

Document	What it is	Status
draft-kelley-aipref-training-preference-signal-00	Defines the __usage_ai-training token	Active Internet-Draft (individual); not endorsed by the IETF; expires 3 May 2027
draft-ietf-aipref-vocab-08	Vocabulary for expressing AI usage preferences; defines "AI training"	WG document, "I-D Exists"; milestone to IESG dated 31 August 2026
draft-ietf-aipref-attach-05	Associating AI usage preferences with content in HTTP	WG document, Proposed Standard intended, "I-D Exists"
RFC 9309	robots.txt, and the product-token syntax the token reuses	Published standard

No AIPREF document is an RFC. The Kelley draft appears on the working group's page only under related Internet-Drafts, with state "New". Google's own wording concedes the sequencing: the mechanism delivers "the AI training definition developed at the IETF while multistakeholder discussions continue on the rest of the AIPREF vocabulary".

The strongest case for the other side is real, and it is Google's: this is where the industry is converging, it reflects feedback from publishers, regulators and civil society, and Google notes it is consistent with the EU Code of Practice for General Purpose AI model providers under the EU AI Act, which recognises robots.txt as a primary method for expressing machine-readable preferences. Standing at the IETF is not the only thing that makes a token load-bearing; adoption is. That argument is sound. It just does not make the token work in November 2026.

What to do with the AI training preference signal this quarter

Add the group. Three lines in robots.txt cost nothing, break nothing — no new grammar means no parser risk for crawlers that do not know the token — and they date-stamp your preference before 2027 arrives. Point the Allow at whatever you genuinely want trained on, as the draft's /press-kit/ example does; an empty carve-out is a fine answer too.

Then change nothing else. Keep Google-Extended, keep GPTBot, keep whatever per-crawler rules you landed after the Cloudflare AI crawler block in September. Google's precedence rule only maps the token onto Google-Extended when Google-Extended is not explicitly specified, so an explicit Google-Extended line stays authoritative and stays readable by a human reviewing your repo. Retiring per-crawler rules in favour of one advisory token no vendor honours yet is the one move here that can actually cost you something.

This is the wrong priority if your content is behind authentication or paywalled — robots.txt governs what a crawler may fetch, not what a licensee may do, and a private agreement overrides the signal anyway. Spend that hour on your terms of service instead.

If the decision in front of you is bigger than a robots.txt file — whether to license your catalogue, how to measure what AI assistants send you, or how to build generative AI features over your own content instead of feeding someone else's model — that is the work our AI engineering team scopes. Send us your current robots.txt and the pages that drive your signups, and we will tell you in a week what the opt-out actually costs you in referrals and what it does not.