Cloudflare Pay-Per-Crawl 2026: AI developer cần biết gì - BKGlobal

Hook dự án: RAG tài chính, lý do team chúng tôi bắt đầu quan tâm

Hai tuần trước, team chúng tôi vận hành hệ thống RAG hỗ trợ nhân viên support của một khách hàng tài chính, phục vụ trả lời nhanh về sản phẩm và điều khoản. Dữ liệu nguồn đến từ bốn nguồn: knowledge base nội bộ, FAQ công khai trên website khách hàng, tin tức thị trường từ các trang báo chí, và biên bản họp công bố thông tin từ các cơ quan quản lý.

Trong buổi review định kỳ, tụi mình phát hiện ra ba tín hiệu đáng lo:

Tỷ lệ crawl thành công từ hai trang báo chí lớn giảm từ 94% xuống 71% chỉ trong một tháng
Một số trang bắt đầu trả về 403 kèm header mới mà chúng tôi chưa từng thấy
Chi phí bandwidth tăng 30% vì phải retry nhiều lần

Khi đào sâu, nguyên nhân không phải do code team bị lỗi. Đó là Cloudflare đang âm thầm phân loại lại Internet, và các AI crawler như của tụi mình bị xếp vào nhóm "mixed-use", sắp tới sẽ bị chặn mặc định. Quyết định kiến trúc phải thay đổi, và thay đổi ngay từ bây giờ, không phải đợi đến 15/9/2026.

Bối cảnh: năm 2026, lần đầu tiên bot vượt người trên Internet

Tháng 7 năm 2026, Cloudflare công bố một cột mốc đáng chú ý: lần đầu tiên trong lịch sử Internet, lưu lượng bot đã vượt lưu lượng người dùng thật. Dự kiến ban đầu là sẽ xảy ra vào năm 2027, nhưng thực tế đến sớm hơn một năm.

Matthew Prince, CEO Cloudflare, viết trong thông báo của mình: "Bây giờ phần lớn traffic trên Internet là non-human, chúng tôi cần đi xa hơn và nhanh hơn để một hệ sinh thái bền vững có thể hình thành."

Đây không phải tuyên bố mang tính kỹ thuật - nó là tuyên bố mang tính chính sách nền tảng. Cloudflare đang nói: chúng tôi sẽ phân loại lại Internet, và các AI company phải trả tiền cho dữ liệu mà họ dùng.

Với một team đang xây dựng hệ thống AI như chúng tôi, đây là dấu hiệu rõ ràng: luật chơi đang thay đổi, và việc thay đổi sẽ định hình lại cách chúng tôi thiết kế pipeline.

Cụ thể Cloudflare làm gì

Bước 1: Phân loại crawler từ 15/9/2026

Theo chính sách mới, Cloudflare sẽ mặc định chặn các "mixed-use crawler" trên bất kỳ trang nào có quảng cáo. Trừ khi chủ site chủ động cấu hình cho phép.

Các crawler bị ảnh hưởng là những crawler vừa dùng cho search, vừa cho AI agent, vừa cho training data. Đây là loại crawler phổ biến nhất hiện nay.

Quy tắc này áp dụng cho:

Khách hàng mới của Cloudflare
Site mới của khách hàng hiện tại
Tất cả khách hàng dùng gói miễn phí

Bước 2: Tách bạch search bot và AI bot

Crawler cho Google Search (Googlebot) sẽ vẫn hoạt động bình thường. Nhưng crawler cho AI training và AI service (như Google Extended) sẽ bị tách ra, và cần có sự đồng ý riêng từ chủ site.

Cloudflare gọi thẳng Google ra: "Search engine lớn nhất thế giới có quyền truy cập vào lượng thông tin gấp 2 lần các AI company khác, vì họ làm cho khách hàng khó discover được mà không bị dùng cho AI."

Google phản hồi bằng việc nhắc đến bot Google Extended, cho phép site owner opt-out khỏi việc bị dùng cho training và sản phẩm AI như Gemini Apps hay Vertex API. Việc dùng Googlebot không bị ảnh hưởng, nhưng Googlebot cũng crawl cho AI features như AI Overviews và AI Mode - một vùng xám.

Bước 3: Pay-Per-Crawl tiến hóa thành Pay-Per-Use

Cloudflare đã ra mắt Pay-Per-Crawl từ vài năm trước - một marketplace cho phép website tính phí AI bot khi scrape. Bây giờ, mô hình này đang tiến hóa thành Pay-Per-Use: publisher được trả tiền khi nội dung của họ tạo ra giá trị, không chỉ khi nó được fetch.

Hai đối tác đầu tiên: Ceramic.ai và You.com. Khi publisher opt-in, họ được trả khi nội dung xuất hiện trong AI search results của Ceramic, hoặc khi You.com truy cập premium content của họ.

Tại sao điều này quan trọng với AI developer

Với team BKGlobal đang xây RAG pipeline và AI agent, ba thay đổi này có ý nghĩa thực tiễn rõ ràng.

1. Dữ liệu để train và retrieve sẽ đắt hơn

Nếu team bạn đang crawl web data để build knowledge base, bạn sẽ phải đối mặt với hai rào cản:

Kỹ thuật: nhiều site sẽ chặn bot mặc định, bạn cần cấu hình đặc biệt để được vào
Pháp lý: ngay cả khi vào được, việc dùng content cho training có thể phải trả phí

Đối với RAG pipeline dùng cho support chat hoặc knowledge management nội bộ, đây là vấn đề nghiêm trọng. Bạn có thể vẫn crawl được trong thời gian ngắn, nhưng chi phí sẽ tăng theo từng tháng tùy thuộc vào mức độ publisher áp giá, đặc biệt khi scale lên nhiều domain.

2. Agent scraping sẽ cần identity rõ ràng

AI agent tự động truy cập web (để đặt vé, so sánh giá, tổng hợp tin tức) sẽ bị chặn mặc định nếu chủ site không cho phép.

Điều này buộc team phải:

Đăng ký identity cho agent bot với Cloudflare
Phân biệt rõ ba lớp: tuân thủ robots.txt (quy tắc kỹ thuật), Cloudflare bot policy (quy tắc hạ tầng), và license sử dụng nội dung (quy tắc pháp lý)
Có thể phải trả phí cho mỗi request khi publisher bật Pay-Per-Use

Với team đang xây agent cho khách hàng doanh nghiệp Việt Nam (một trong những focus của chúng tôi), điều này có nghĩa là thiết kế agent phải tính đến chi phí dữ liệu ngay từ đầu, không phải giải quyết sau.

3. Kiến trúc RAG cần chiến lược dữ liệu đa dạng

Một nguồn dữ liệu duy nhất từ web crawl sẽ không còn đáng tin cậy. Team chúng tôi đã và đang chuyển sang chiến lược:

First-party data: ưu tiên dữ liệu nội bộ của khách hàng (log, ticket, knowledge base nội bộ) làm nguồn chính
Licensed data: cho những nguồn cần freshness cao, đăng ký API chính thức thay vì crawl
Crawled data: chỉ dùng cho những site cho phép, có cơ chế cache và cập nhật hiệu quả
Synthetic data: dùng AI generate ra training data cho các tác vụ cụ thể

Sự kết hợp này giảm phụ thuộc vào một nguồn duy nhất và tăng tính ổn định của pipeline.

Hướng dẫn cụ thể cho team Việt Nam

Từ kinh nghiệm đang áp dụng tại BKGlobal, đây là checklist chúng tôi khuyến nghị:

Audit hiện trạng

Trước khi thay đổi gì, team cần biết team đang dùng dữ liệu từ đâu:

- Liệt kê tất cả nguồn dữ liệu cho RAG/training
- Với mỗi nguồn: có API chính thức không, có license không, 
  hay đang crawl thuần?
- Với mỗi nguồn crawl: có đang bị chặn không (status code, rate limit)?
- Chi phí hiện tại cho mỗi nguồn là bao nhiêu?

Phân loại rủi ro

- Nguồn nào có thể bị chặn trong 6 tháng tới?
- Nguồn nào có thể phải trả phí?
- Nguồn nào đã có sẵn API thay thế?

Thiết kế lại pipeline

Với mỗi nguồn có rủi ro cao, lên kế hoạch thay thế:

Nếu có API: chuyển sang API, dù có tốn phí
Nếu không có API: liên hệ trực tiếp data owner để thỏa thuận
Nếu không thay thế được: dùng nguồn đó cho prototyping, không cho production

Thêm observability

Một điều chúng tôi thấy team hay bỏ qua: không log được bao nhiêu request crawl bị fail. Khi Cloudflare thay đổi chính sách, team chỉ biết khi pipeline bắt đầu trả về kết quả rỗng.

Chúng tôi đã viết một service .NET nhỏ để track chính xác từng domain, có cảnh báo sớm khi tỷ lệ 4xx tăng:

// CrawlerHealthMonitor - chạy nền, ghi nhận từng request crawl
public sealed record CrawlAttempt(
    string Domain,
    DateTimeOffset Timestamp,
    int StatusCode,
    TimeSpan Latency,
    bool CacheHit,
    string? PaywallHint
);

public static class CrawlHealthAnalyzer
{
    public static IReadOnlyList<DomainHealthReport> DetectDegradation(
        IEnumerable<CrawlAttempt> recent,
        TimeSpan window)
    {
        var cutoff = DateTimeOffset.UtcNow - window;
        var byDomain = recent
            .Where(a => a.Timestamp >= cutoff)
            .GroupBy(a => a.Domain);

        return byDomain
            .Select(g => new DomainHealthReport(
                Domain: g.Key,
                TotalRequests: g.Count(),
                ForbiddenRate: g.Count(a => a.StatusCode is 403 or 429)
                               / (double)g.Count(),
                AvgLatency: TimeSpan.FromMilliseconds(
                    g.Average(a => a.Latency.TotalMilliseconds)),
                PaywallDetected: g.Any(a => a.PaywallHint is not null)))
            .Where(r => r.ForbiddenRate > 0.20 || r.PaywallDetected)
            .ToList();
    }
}

Service này tự động cảnh báo team khi tỷ lệ 4xx vượt 20% hoặc khi phát hiện header paywall mới. Chính nhờ vậy, hai tuần trước khi Cloudflare công bố chính sách, team đã chủ động điều chỉnh pipeline trước khi khách hàng nhận ra dữ liệu bị thiếu.

Chuẩn bị cho agent identity

Nếu team có agent scraping, hãy chuẩn bị:

User-Agent string rõ ràng, có link đến trang contact
Tuân thủ robots.txt (đọc và parse thật, không bỏ qua)
Cache aggressive để giảm số request
Sẵn sàng trả phí qua Pay-Per-Crawl khi cần

Bài học từ dự án thực

Team BKGlobal có một dự án RAG cho khách hàng trong lĩnh vực tài chính, mục tiêu là hỗ trợ nhân viên support trả lời nhanh về sản phẩm. Dữ liệu nguồn đến từ nhiều nơi:

Knowledge base nội bộ (first-party, an toàn)
FAQ công khai trên website (có thể bị ảnh hưởng bởi Cloudflare policy)
Tin tức thị trường từ các trang báo chí (nhiều trang sẽ bị ảnh hưởng)

Khi chúng tôi nghe về chính sách Cloudflare, team đã ngồi lại và đánh giá lại kiến trúc. Quyết định:

Knowledge base nội bộ vẫn là nguồn chính, không thay đổi
FAQ công khai: cache toàn bộ, refresh theo lịch, chấp nhận độ trễ vài giờ
Tin tức thị trường: đăng ký API chính thức của 1-2 nguồn uy tín, không crawl nữa
Có một fallback: nếu không lấy được tin tức, hệ thống sẽ thông báo "không có dữ liệu fresh" thay vì trả lời với dữ liệu cũ

Quyết định này có chi phí ban đầu cao hơn (mất phí API), nhưng ổn định hơn nhiều trong dài hạn.

Góc nhìn dài hạn

Cloudflare chỉ là một trong nhiều bên đang định hình lại luật chơi. Anthropic mới đây đạt thỏa thuận bản quyền 1.5 tỷ USD với publishers. EU AI Act bắt đầu enforcement từ tháng 8 năm 2026. Nhiều tổ chức truyền thông lớn đã kiện các AI company về vi phạm bản quyền.

Tất cả những điều này đều đi cùng một hướng: dữ liệu có giá, và ai muốn dùng thì phải trả.

Với team đang xây AI ở Việt Nam, đây không phải tin xấu. Đây là cơ hội:

Các doanh nghiệp Việt có lượng dữ liệu first-party lớn (e-commerce, fintech, telecom) sẽ có lợi thế rõ ràng
Các team xây dựng dữ liệu có tổ chức, có license, sẽ được đánh giá cao hơn trong mắt khách hàng
Các giải pháp AI nội địa dùng dữ liệu trong nước sẽ có thêm không gian phát triển

Điểm quan trọng nhất: đừng xây hệ thống AI phụ thuộc vào dữ liệu team không kiểm soát. Đó luôn là nguyên tắc tốt, và bây giờ nó càng quan trọng hơn.

Kết luận

Cloudflare Pay-Per-Crawl và sự tiến hóa thành Pay-Per-Use là một bước ngoặt, không phải một sự kiện đơn lẻ. Nó nằm trong xu hướng lớn hơn: dữ liệu trên Internet đang được định giá, và các AI company đang dần chấp nhận điều đó.

Với AI developer, đây là lúc để:

Audit lại tất cả nguồn dữ liệu
Phân loại rủi ro và chi phí
Thiết kế pipeline với chiến lược đa dạng hóa
Thêm observability cho crawling layer
Chuẩn bị identity cho agent

Nếu team bạn đang xây dựng hệ thống AI, đừng chờ đến khi Cloudflare chặn request đầu tiên. Hành động sớm sẽ giúp bạn tiết kiệm cả thời gian lẫn tiền bạc trong 6-12 tháng tới.

Bạn đang xây dựng hệ thống AI với dữ liệu crawl? Team BKGlobal viết bài này dựa trên kinh nghiệm thiết kế RAG pipeline trong nhiều dự án tài chính và e-commerce. Nếu bạn muốn trao đổi về kiến trúc cụ thể, có thể mở issue trên GitHub repo hoặc liên hệ trang tech.bkglobal.vn.

Bài liên quan trên tech.bkglobal.vn:

Son Do - BKGlobal Tech Team

#BKGlobal #ung-dung-ai #ai-trends #rag-llm-integration #ai-agent #senior-dev

Research document (citation source reference)

(no reference document available)

Cloudflare Pay-Per-Crawl: cuộc chiến dữ liệu mới ảnh hưởng đến AI developer thế nào