Chặn AI train dữ liệu website: AIPREF của IETF đề xuất Content-Usage, tôi bắt được bẫy cú pháp y/n trên robots.txt của beru.io.vn

Muốn chặn AI train dữ liệu website nhưng vẫn cho Google, ChatGPT hay Perplexity index để trả lời câu hỏi người dùng — robots.txt kiểu Allow/Disallow không làm được việc đó, vì nó chỉ kiểm soát được crawl, không kiểm soát được mục đích dùng dữ liệu sau khi đã crawl. IETF vừa cập nhật hai draft của working group AIPREF vào ngày 19/8/2026 để bịt đúng lỗ hổng này, bằng một HTTP field mới tên Content-Usage. Tôi fetch robots.txt thật của beru.io.vn, đối chiếu với spec, dựng lại đúng cú pháp bằng một parser RFC 9651 thật trong Node.js, và phát hiện ra một chỗ mà chính cú pháp "trông đúng" lại hoàn toàn vô nghĩa với máy — kể cả khi bạn copy y hệt convention mà Cloudflare đã bắt cả triệu website dùng từ một năm trước.

Vấn đề: robots.txt chỉ nói được "được vào" hay "không được vào"

Disallow và Allow trong robots.txt — Robots Exclusion Protocol, chuẩn hoá thành RFC 9309 năm 2022 — chỉ trả lời đúng một câu hỏi: bot này có được crawl đường dẫn này hay không. Nó không có chỗ nào để nói "được crawl để index cho search, nhưng đừng lấy để train model". Vấn đề này không mới — nó là lý do Cloudflare, hồi tháng 9/2025, tự đưa ra một directive robots.txt riêng gọi là Content-Signal, và cũng là lý do IETF lập hẳn một working group tên AIPREF (AI Preferences) để chuẩn hoá chuyện này thay vì để mỗi CDN, mỗi công ty tự bịa một cú pháp.

Tôi vận hành beru.io.vn như một CMS Next.js + Prisma tự viết, robots.txt của nó liệt kê tên riêng từng bot AI — GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended, meta-externalagent — từ hồi viết bài về xác minh crawler AI. Nhưng liệt kê tên bot không có nghĩa là điều khiển được hành vi của nó theo mục đích sử dụng. Đây chính là khoảng trống mà AIPREF nhắm tới.

AIPREF là gì, và hai tài liệu vừa cập nhật ngày 19/8/2026

AIPREF là working group của IETF, mục tiêu ghi trong milestone của group là đưa ra "Standard track protocol specification(s) to associate the AI-related preferences" — tức một cách chuẩn, máy đọc được, để gắn preference về việc dùng AI vào nội dung web. Hai tài liệu cốt lõi của group, cả hai đều vừa ra revision mới ngày 19/8/2026:

• draft-ietf-aipref-vocab-07 — "A Vocabulary For Expressing AI Usage Preferences", tác giả Paul Keller (Open Future) và Martin Thomson (Mozilla, editor). Đây là tài liệu định nghĩa các nhãn (label) và giá trị hợp lệ.
• draft-ietf-aipref-attach-05 — "Associating AI Usage Preferences with Content in HTTP", tác giả Gary Illyes (Google) và Martin Thomson (Mozilla). Đây là tài liệu định nghĩa cách gắn preference đó vào HTTP response và vào robots.txt.

Cả hai đều còn ở trạng thái Internet-Draft, IESG state "I-D Exists" — nghĩa là chưa phải RFC, chưa qua các bước cuối của quy trình chuẩn hoá IETF, dù mục tiêu công bố là Proposed Standard. Tôi không tìm thấy tài liệu nào của hai draft này nói về adopter hay tình trạng triển khai thực tế — tức là tính đến thời điểm viết bài, tôi chưa kiểm chứng được có crawler AI thương mại nào (GPTBot, ClaudeBot, PerplexityBot...) đã thực sự đọc và tuân theo Content-Usage hay chưa. Ai đọc bài này cần nhớ rõ ranh giới đó: đây là một spec đang hình thành, không phải luật đã có ai chấp hành.

Vocab hiện tại — theo đúng Section 4 của draft-ietf-aipref-vocab-07 — chỉ định nghĩa hai category, không hơn:

• 4.1, AI Model Training (train-ai): nguyên văn "Using an asset to modify the learned parameters of an AI model that is used to generate synthetic content in one or more modalities."
• 4.2, Search (search): nguyên văn "Use of an asset in an application where the primary purpose of the application is to select assets and direct users to the location of those assets."

Không có nhãn cho "dùng làm input lúc trả lời" kiểu RAG hay grounding — điều mà Cloudflare gọi là ai-input. Section 4.3 nói rõ mọi mở rộng vocab sau này phải qua một RFC chuẩn hoá riêng, và "the definition of the extension MUST define how any potential overlap between usage categories is resolved" — tức không được tự thêm nhãn tuỳ tiện mà không nói rõ nó chồng lấn với train-ai/search ra sao.

Content-Usage: một HTTP field, dùng cú pháp RFC 9651

draft-ietf-aipref-attach-05 định nghĩa field HTTP tên Content-Usage. Nguyên văn Section 2: "The Content-Usage field is a structured field dictionary, as defined in Section 3.2 of [FIELDS]. This field follows the vocabulary and processing rules in [VOCAB]." [FIELDS] ở đây là RFC 9651 — Structured Field Values for HTTP, công bố tháng 9/2024, thay thế RFC 8941 — chuẩn định nghĩa cách serialize các kiểu dữ liệu phức tạp (list, dictionary, số, boolean, chuỗi Unicode...) vào một HTTP header cho gọn và an toàn hơn cú pháp tự do trước đây.

Ví dụ trong spec, dùng nguyên văn như một HTTP response:

HTTP/1.1 200 OK
Date: Wed, 23 Apr 2025 04:48:02 GMT
Content-Type: text/plain
Content-Usage: train-ai=n

This is some content.

Field này áp dụng cho từng response cụ thể — đúng chất representation metadata theo RFC 9110 Section 8.2, tức là mô tả bản thân dữ liệu trả về, không phải mô tả cả site. Spec cũng nói rõ một điểm dễ bị hiểu nhầm — Section 2: "The Content-Usage field does not have any special effect on caching." Tức là đặt header này không tự động khiến CDN hay proxy xử lý cache khác đi, nó chỉ là một khai báo, không phải một cơ chế thực thi.

Song song đó, attach-05 cũng thêm một rule mới cho robots.txt, áp dụng theo path thay vì theo từng response. Ví dụ nguyên văn trong spec:

User-Agent: *
Allow: /
Content-Usage: train-ai=n
Content-Usage: /ai-ok/ train-ai=y

Đọc theo path-matching giống hệt cách Allow/Disallow đang hoạt động — dòng nào match dài hơn thì thắng. Và một ràng buộc quan trọng ở Section 3.1: "Usage preferences apply only to those resources that can be crawled according to Allow/Disallow rules; no preferences are implied for resources that are disallowed." Nói cách khác, Content-Usage không phải cửa sau để mở lại quyền crawl — nếu path đã bị Disallow, khai báo train-ai=y trên path đó vô nghĩa, vì bot còn chưa được phép đọc nó để mà train.

Test thật: robots.txt của beru.io.vn hiện không có cách nào diễn đạt điều này

Tôi fetch trực tiếp https://beru.io.vn/robots.txt ngay lúc viết bài này, đây là toàn bộ nội dung, không rút gọn:

User-Agent: *
Allow: /
Allow: /api/openapi.json
Allow: /.well-known/
Disallow: /admin/
Disallow: /api/

User-Agent: GPTBot
User-Agent: OAI-SearchBot
User-Agent: ChatGPT-User
User-Agent: ClaudeBot
User-Agent: Claude-User
User-Agent: PerplexityBot
User-Agent: Google-Extended
User-Agent: Applebot-Extended
User-Agent: meta-externalagent
User-Agent: Bingbot
Allow: /
Allow: /api/openapi.json
Allow: /.well-known/
Disallow: /admin/
Disallow: /api/

Host: https://beru.io.vn
Sitemap: https://beru.io.vn/sitemap.xml

Nhìn kỹ sẽ thấy một điều khá vô lý về mặt thiết kế: file này đã tốn công liệt kê riêng từng tên bot — GPTBot (training crawler của OpenAI), OAI-SearchBot và ChatGPT-User (hai crawler dùng cho tính năng search/browsing của ChatGPT, mục đích khác GPTBot), ClaudeBot (training), Claude-User (dùng khi người dùng yêu cầu Claude fetch một trang cụ thể), PerplexityBot (search)... nhưng rule áp cho tất cả các bot này là y hệt nhau: Allow: /, Allow: /api/openapi.json, Allow: /.well-known/, Disallow: /admin/, Disallow: /api/. Không có dòng Content-Usage nào cả.

Nói cách khác: file đã phân biệt được danh tính bot (biết GPTBot khác PerplexityBot), nhưng chưa phân biệt được mục đích — nếu muốn nói "PerplexityBot cứ index để trả lời search, nhưng GPTBot đừng lấy nội dung này để train", robots.txt hiện tại của site hoàn toàn không có công cụ để diễn đạt câu đó. Đây đúng là khoảng trống mà AIPREF sinh ra để lấp — không phải một khiếm khuyết riêng của beru.io.vn, mà là giới hạn chung của toàn bộ hệ sinh thái robots.txt trước khi có Content-Usage.

Tôi cũng fetch .well-known/api-catalog — endpoint theo RFC 9727, api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs — vốn đã có sẵn trên site từ loạt bài trước về agent-discoverability:

{"linkset":[{"anchor":"https://beru.io.vn/api","service-desc":[{"href":"https://beru.io.vn/api/openapi.json","type":"application/openapi+json"}],"service-doc":[{"href":"https://beru.io.vn/api-docs","type":"text/html"}],"status":[{"href":"https://beru.io.vn/api/health","type":"application/json"}]}]}

Đây là hạ tầng cùng họ — cùng là cách khai báo máy-đọc-được cho agent — nhưng phục vụ mục đích khác: api-catalog nói "API của tôi nằm ở đâu", còn Content-Usage sẽ phải nói "nội dung của tôi được dùng vào việc gì". Hai thứ không thay thế nhau.

Cloudflare đã có "phiên bản" của mình từ một năm trước — và nó không tương thích trực tiếp

Đây là phần dễ gây nhầm lẫn nhất nếu chỉ đọc lướt tin tức: Cloudflare đã công bố Content-Signal — một robots.txt directive riêng — ngày 24/9/2025, tức là gần một năm trước AIPREF ra Content-Usage. Cú pháp nguyên văn từ blog chính thức của Cloudflare:

User-Agent: *
Content-Signal: search=yes, ai-train=no
Allow: /

Ba nhãn của Cloudflare là search, ai-input (dùng làm input lúc trả lời truy vấn, kiểu RAG/grounding), và ai-train — nhiều hơn AIPREF một nhãn (ai-input chưa tồn tại trong vocab IETF). Và giá trị dùng là yes/no, không phải y/n. Cloudflare release chính sách này dưới giấy phép CC0 để khuyến khích áp dụng rộng, và trong bài blog họ nói rõ sẽ "continue to work in standards bodies to develop and standardize solutions" — tức bản thân Cloudflare cũng xem đây là bước đệm, không phải điểm đến, và có tham chiếu tới chính AIPREF working group như hướng đi chuẩn hoá lâu dài.

Vấn đề là: tên field khác nhau (Content-Signal so với Content-Usage), tên nhãn khác nhau (ai-train so với train-ai), và quan trọng nhất — giá trị khác nhau (yes/no so với y/n). Một website đã làm theo hướng dẫn của Cloudflare từ năm ngoái, nếu giờ đổi tên field thành Content-Usage mà giữ nguyên thói quen viết yes/no, sẽ tạo ra một dòng cú pháp hợp lệ về mặt cấu trúc RFC 9651 — nhưng vô nghĩa về mặt ngữ nghĩa AIPREF. Tôi verify chuyện này bằng code thật ở phần dưới, không suy đoán.

search=y có che được AI Overviews, ChatGPT search hay Perplexity không? Không hẳn

Đây là chỗ liên quan trực tiếp tới AI Overviews, ChatGPT search, Perplexity — mảng GEO mà rất nhiều người làm SEO/content ở Việt Nam đang quan tâm — và cũng là chỗ tôi thấy bị hiểu sai nhiều nhất nếu chỉ đọc tên nhãn search mà không đọc kỹ định nghĩa. Section 4.2 của draft-ietf-aipref-vocab-07 không chỉ định nghĩa "search" bằng một câu, mà đi kèm hai điều kiện và một loại trừ quan trọng.

Điều kiện thứ nhất, nguyên văn: "Where the presentation of an asset in search output -- if selected for presentation -- includes a direct reference or link to the original location from which the asset was retrieved." Tức kết quả phải có link dẫn ngược về nguồn gốc. Điều kiện thứ hai, về excerpt: "When excerpts from the asset are displayed they serve to assist users in evaluating the relevance of the result" — đoạn trích chỉ nhằm giúp người dùng đánh giá độ liên quan của kết quả, đúng kiểu snippet 10-kết-quả-xanh truyền thống của Google. Và loại trừ, nguyên văn, ngắn gọn nhưng quan trọng nhất: "This category does not include the use of assets to generate summaries."

Đọc kỹ câu loại trừ này thì AI Overviews của Google, câu trả lời tổng hợp của ChatGPT search, hay câu trả lời được Perplexity viết lại từ nhiều nguồn — đều là hành vi "generate summaries" từ nội dung đã crawl, tức đều nằm ngoài phạm vi category search như vocab hiện định nghĩa. Một website khai báo Content-Usage: search=y, train-ai=n với kỳ vọng "vậy là tôi cho phép AI search dùng nội dung của mình" có thể đang lầm: theo đúng chữ của spec, việc dùng nội dung để tổng hợp thành một đoạn trả lời AI Overview không phải là search, cũng không phải train-ai (không có việc học tham số model ở đây) — nó rơi vào một loại hành vi mà vocab hiện tại, với đúng hai category đã định nghĩa, chưa có tên gọi. Theo đúng thuật toán Section 6.5 đã trích ở trên, một use case không khớp category nào đã khai báo thì preference cho use case đó là "unknown", không phải "allowed".

Đây chính xác là khoảng trống mà nhãn ai-input của Cloudflare — "Use as input to AI models at query time, including retrieval, grounding, or RAG-style answers" — được sinh ra để lấp, và Cloudflare đã có nhãn này từ 24/9/2025. AIPREF, tính đến bản 19/8/2026, vẫn chỉ dừng ở hai category train-ai/search, chưa có category riêng cho retrieval-augmented generation hay answer-synthesis. Section 4.3 nói rõ mở rộng vocab phải qua một RFC chuẩn hoá riêng, nghĩa là site operator không thể tự chế thêm một nhãn thứ ba và mong crawler tuân thủ hiểu nó — phải chờ (hoặc vận động) chính working group bổ sung.

Nói cách khác: nếu mục tiêu là kiểm soát việc content bị AI Overviews/ChatGPT search/Perplexity tóm tắt lại, Content-Usage bản hiện tại của IETF chưa phải công cụ đúng việc — nó xử lý tốt bài toán "cho index kiểu công cụ tìm kiếm cổ điển" và "cho/không cho train model", nhưng bỏ ngỏ đúng bài toán nóng nhất của GEO hiện nay.

Cái bẫy y/n: cú pháp hợp lệ không có nghĩa là preference có tác dụng

Đây là phần tôi tự tay dựng lại để kiểm chứng, không lấy từ bài viết tổng hợp nào khác. Content-Usage là một Dictionary theo RFC 9651, nên tôi cài thư viện structured-headers — một parser JavaScript triển khai đúng RFC 9651/RFC 8941, chạy 2805 unit test lấy từ bộ test suite chính thức của HTTP Working Group (httpwg/structured-field-tests) theo README của package — rồi thử parse vài dòng, bao gồm cả ví dụ đúng trong spec lẫn những lỗi rất dễ mắc phải trong thực tế:

import { parseDictionary } from 'structured-headers';

function tryParse(label, header) {
  console.log(`
--- ${label} ---`);
  console.log('input:', header);
  try {
    const dict = parseDictionary(header);
    for (const [key, [value, params]] of dict) {
      console.log(`  key=${JSON.stringify(key)} value=${JSON.stringify(value)} (type=${typeof value})`);
    }
  } catch (e) {
    console.log('  PARSE ERROR:', e.message);
  }
}

tryParse('vocab example (valid)', 'train-ai=y, search=n');
tryParse('common mistake: yes/no (convention của Cloudflare)', 'train-ai=yes, search=no');
tryParse('common mistake: JSON true/false', 'train-ai=true, search=false');
tryParse('Structured Field boolean thật (?1/?0)', 'train-ai=?1, search=?0');

Chạy bằng node test.mjs, output thật, không chỉnh sửa:

--- vocab example (valid) ---
input: train-ai=y, search=n
  key="train-ai" value={"value":"y"} (type=object)
  key="search" value={"value":"n"} (type=object)

--- common mistake: yes/no (convention của Cloudflare) ---
input: train-ai=yes, search=no
  key="train-ai" value={"value":"yes"} (type=object)
  key="search" value={"value":"no"} (type=object)

--- common mistake: JSON true/false ---
input: train-ai=true, search=false
  key="train-ai" value={"value":"true"} (type=object)
  key="search" value={"value":"false"} (type=object)

--- Structured Field boolean thật (?1/?0) ---
input: train-ai=?1, search=?0
  key="train-ai" value=true (type=boolean)
  key="search" value=false (type=boolean)

Điểm mấu chốt: cả bốn dòng đều parse thành công, không dòng nào bị PARSE ERROR. Về mặt cú pháp RFC 9651 thuần tuý, yes, no, true, false đều là Token hợp lệ — Dictionary không quan tâm nội dung token là gì, chỉ cần đúng hình dạng token. Một linter hay validator chỉ kiểm tra cú pháp RFC 9651 sẽ cho tất cả các dòng trên pass sạch.

Nhưng AIPREF vocab không dừng ở lớp cú pháp. draft-ietf-aipref-vocab-07 Section 6.5 mô tả rõ thuật toán xử lý, nguyên văn: "If the value is a Token with a value of y, the associated preference is to allow that category of use. If the value is a Token with a value of n, the associated preference is to disallow that category of use. Otherwise, the preference for that category is unknown." Tức là chỉ literal y và n mới có nghĩa. Mọi Token khác — yes, no, true, false, hay chính cú pháp boolean thật của RFC 9651 là ?1/?0 — đều rơi vào nhánh "otherwise", kết quả là unknown, tương đương với việc hoàn toàn không khai báo gì.

Và Section 5 nói rõ hệ quả của "unknown" khi có nhiều statement chồng lên nhau (ví dụ một khai báo ở HTTP header, một khai báo khác ở robots.txt cho cùng path): "If any statement of preference indicates that the usage is disallowed, the result is that the usage is disallowed. Otherwise, if any statement of preference allows the usage, the result is that the usage is allowed. Otherwise, the preference for that category is unknown." Ưu tiên tuyệt đối cho "disallow" — chỉ cần một nguồn nói "n" là toàn cục bị chặn — nhưng khi không có nguồn nào nói rõ ràng, kết quả cuối vẫn là "unknown", và spec không ép crawler phải xử lý "unknown" theo hướng nào, việc đó tuỳ chính sách riêng của mỗi bên vận hành crawler.

Rủi ro thực tế ở đây khá cụ thể: ai đó quen tay viết yes/no theo đúng convention Cloudflare đã phổ biến cả năm nay, giờ đổi field name sang Content-Usage cho "chuẩn IETF" nhưng quên đổi giá trị, sẽ có một dòng robots.txt trông hoàn toàn hợp lý, không báo lỗi ở bất kỳ công cụ kiểm tra cú pháp nào, nhưng crawler tuân thủ đúng draft-ietf-aipref-vocab-07 sẽ đọc nó y hệt như thể dòng đó không tồn tại.

Vậy viết đúng thì trông như thế nào

Dựa đúng cú pháp trong hai spec, một block minh hoạ theo đúng chuẩn — tôi nhấn mạnh đây là ví dụ tôi tự soạn để đúng cú pháp, không phải khẳng định beru.io.vn đã triển khai, vì tôi không có quyền truy cập hạ tầng server để deploy thay đổi robots.txt hay cấu hình response header:

User-Agent: *
Allow: /
Allow: /api/openapi.json
Allow: /.well-known/
Disallow: /admin/
Disallow: /api/
Content-Usage: search=y, train-ai=n

Theo đúng Section 6.5, dòng này nói: mọi bot được phép crawl (theo Allow ở trên) có thể dùng nội dung cho search (search=y), nhưng không được dùng để train model (train-ai=n). Muốn khác nhau theo path thì dùng dạng path-scoped như ví dụ trong attach-05:

Content-Usage: train-ai=n
Content-Usage: /blog/ train-ai=y

Ở đây /blog/ được mở lại quyền train riêng, ghi đè rule mặc định — đúng cơ chế longest-match giống Allow/Disallow. Muốn áp cho một response cụ thể thay vì cả path, dùng header HTTP:

Content-Usage: train-ai=n, search=y

đặt trong response headers của chính trang đó. Cả ba cách đều hợp lệ cú pháp — nhưng cái tôi vừa kiểm chứng ở trên cho thấy hợp lệ cú pháp chỉ là điều kiện cần, không phải điều kiện đủ.

Còn thiếu gì để đây thực sự "có hiệu lực"

Ba giới hạn cần nói rõ, để không ai đọc bài này rồi tưởng nhầm là đã có luật chặn AI train dữ liệu website:

Thứ nhất, đây là honor system, giống hệt robots.txt suốt hơn 30 năm qua. Content-Usage không có cơ chế mã hoá hay xác thực nào đi kèm để ép crawler phải tuân theo — nó là một khai báo, crawler tôn trọng hay không là lựa chọn của bên vận hành crawler đó. Đây cũng chính là lý do tồn tại một hướng đi khác hẳn: Web Bot Auth (IETF, xác thực bot bằng chữ ký số Ed25519 theo RFC 9421) giải quyết bài toán "bot này có đúng là nó tự nhận không", còn AIPREF giải quyết bài toán "bot này được phép dùng nội dung vào việc gì" — hai lớp vấn đề khác nhau, không lớp nào thay được lớp kia. Có xác thực được danh tính bot mà không có preference thì cũng vô ích, và ngược lại có preference rõ ràng mà bot có thể giả danh thì preference cũng chỉ áp dụng được với bot trung thực.

Thứ hai, tôi không kiểm chứng được crawler thương mại nào — GPTBot, ClaudeBot, PerplexityBot, Google-Extended — đã đọc và tuân theo Content-Usage ở thời điểm viết bài. Tài liệu OpenAI, Anthropic, Google công bố cho các bot này (mà tôi đã fetch để đối chiếu ở một bài viết trước) không nhắc tới field này. Việc một spec IETF ở dạng Internet-Draft tồn tại không đồng nghĩa các bên vận hành crawler đã implement nó — đây là khoảng cách thường bị bỏ qua khi tin tức tóm tắt một spec mới mà không kiểm tra adoption thực tế.

Thứ ba, có một hướng phát triển xa hơn đáng chú ý nhưng còn rất sớm: draft-wallace-aipref-grant-binding-02, cập nhật ngày 18/8/2026 — đây là individual draft, chưa phải tài liệu chính thức của working group AIPREF, nên độ chín thấp hơn hẳn hai draft vocab/attach. Nó đề xuất một lớp phía trên AIPREF: cấp "grant" — chứng chỉ có chữ ký số dạng Verifiable Credential, ký bằng JSON Web Signature, có thể thu hồi qua status list — để chủ sở hữu nội dung có thể gỡ riêng lệnh cấm train cho một bên cụ thể (ví dụ: đồng ý cho một nhà nghiên cứu train trên dữ liệu của mình dù Content-Usage mặc định là train-ai=n), mà bên nhận grant có thể tự verify được mà không cần liên hệ lại người cấp. Đây là hướng thú vị để theo dõi, nhưng ở giai đoạn cá nhân đề xuất, còn xa mới tới lúc trở thành spec chính thức.

Vì sao việc này quan trọng với người làm web ở Việt Nam ngay bây giờ

Với một CMS tự viết như beru.io.vn — hay bất kỳ site Next.js/Laravel nào đang tự quản routing và response header, kể cả các dự án thương mại điện tử trong danh mục dự án của tôi — thêm một dòng Content-Usage vào robots.txt hay vào middleware xử lý response header không tốn công sức kỹ thuật lớn, vì bản chất chỉ là ghi thêm một dòng text hoặc set thêm một header, tương tự cách hạ tầng DevOps & server hiện tại của site này đang set các header bảo mật khác. Nhưng viết đúng cú pháp không đảm bảo có tác dụng thật — hai điều kiện tách biệt hoàn toàn: (1) cú pháp phải đúng theo RFC 9651 lẫn vocab của draft-ietf-aipref-vocab-07 — tức bắt buộc dùng y/n, không phải thói quen yes/no hay true/false; và (2) phải có crawler ở đầu bên kia thực sự implement và tôn trọng field này, điều mà tại thời điểm viết bài tôi chưa tìm được bằng chứng xác nhận cho bất kỳ crawler AI thương mại lớn nào.

Nếu quyết định thử áp dụng, việc đầu tiên đáng làm không phải là tin vào một đoạn text trông giống ví dụ trong spec, mà là tự parse thử bằng một implementation RFC 9651 thật — như cách tôi vừa làm với structured-headers — trước khi tin rằng dòng mình viết ra có nghĩa. Một dòng cú pháp "trông đúng" theo mắt người đọc hoàn toàn có thể là một no-op tuyệt đối với máy, và cách duy nhất để biết chắc là chạy thử, không phải đọc lướt rồi đoán.

Trang dịch vụ DevOps & Server Management của tôi là nơi loại cấu hình response header và robots.txt này thường được xử lý cho khách hàng — và một trong các dự án thương mại điện tử tôi từng triển khai, Rang Dong Store, cũng là kiểu site có traffic bot AI đáng kể mà câu hỏi "có nên khai báo train-ai=n hay không" sẽ sớm phải được trả lời, một khi các crawler lớn thực sự bắt đầu đọc field này.