Насоки на EDPB за web scraping: печелят таргетираните скрапери

EDPB току-що написа спецификация за scrapers

Европейските органи за защита на данните са казали много за AI моделите. До това лято нищо от това не казваше на един инженер какво трябва да прави даден scraper, преди да извлече първата си страница.

Guidelines 03/2026 on web scraping in the context of generative AI промени това. Европейският комитет по защита на данните прие проекта на 7 юли 2026 г., а неговата публична консултация приключва на 30 октомври 2026 г. На хартия обхватът е тесен: частни компании, които извличат лични данни за обучение или донастройване на генеративен AI. На практика това е най-подробното описание, което регулатор е публикувал, за това как се изгражда защитим процес по scraping, от критериите, които описвате преди първия request, до времевия маркер на последния запис.

Нашият прочит, след като прегледахме всички 23 страници: проектът не се интересува какви инструменти използвате. Той се интересува дали можете да кажете какво сте събрали, откъде и кога. Програмите за scraping, които могат да отговорят на това с една заявка, ще се справят без проблем. Безразборните crawlers ще срещнат затруднения с почти всеки параграф.

(Отказ от отговорност: Това не е правен съвет. Първо, позоваваме се на проект, и второ, ние сме инженери, които го четат с оглед на това какво означава от гледна точка на кода.)

Целенасочено или нецеленасочено е границата, която има значение

Параграф 8 разделя scraping процесите на два вида според това колко специфично и ограничаващо е събирането, "а не според използваните технически инструменти". Целенасоченият scraping следва критерии за събиране: домейн, език, тема. Нецеленасоченият scraping е crawler, който следва всяка намерена връзка. Опасението на Комитета е конкретно: с нарастването на опашката администраторът "има ограничени познания за това какви лични данни се събират и обработват."

Това разделение преминава през целия останал текст. Минимизирането на данните изисква да "дефинирате точни критерии за събиране" и да проведете "процес на картографиране и инвентаризация на данните", преди да започне събирането (параграф 37). Тестът за необходимост при легитимен интерес посочва, че стесняването на критериите, "вместо scraping на голяма част от интернет", може да бъде точно това, което прави обработването изобщо необходимо (параграф 52). Прозрачността изисква публикуван списък с източници, в идеалния случай с имена на домейни, URLs и дати на събиране (параграфи 30 и 31).

Система за проследяване на цени с фиксиран списък от продуктови страници на десетина домейна за търговия на дребно може да генерира всеки един от тези артефакти от конфигурационния си файл. Обхождане в ширина (breadth-first crawl) не може. Критиката на Privacy World към проекта определя точно това напрежение: задълженията са написани за администратор, който знае какво събира, точно след като Комитетът признава, че нецеленасочено обхождане може да съдържа лични данни, които не могат да бъдат инвентаризирани.

Какво означава това: ако извличате съдържание, което засяга физически лица (отзиви с потребителски имена, обяви с име и телефонен номер на брокер, дискусии във форуми), критериите ви за събиране вече са документ за съответствие (compliance artifact). Пазете ги във version control заедно със скрапера, а не в нечия глава.

Отказът на даден сайт вече се брои срещу вас

Това е частта, която ще промени най-много pipelines. Проектът изброява техническите мерки, които показват, че даден сайт ясно се противопоставя на извличането: robots.txt, ai.txt, "robots authentication to view content" и проверки, които "налагат действие, което може да бъде извършено само от човек" (параграф 37). Съветът относно данните за обучение е тези сайтове да бъдат изключени.

Същите сигнали се появяват отново при теста за балансиране на интереси. Когато хората знаят, че даден сайт използва такива мерки, а той въпреки това бива извличан, проектът посочва, че е по-малко вероятно те да очакват обработването (параграф 64). Пример 5 го казва директно: платформа със забрана в robots.txt, проверка само за хора и изрична забрана за обучение на AI означава, че нейните потребители "не могат разумно да очакват" трети страни да извличат данните им за тази цел. Обратното също не важи. Липсващият robots.txt не означава съгласие (параграф 45).

Френската CNIL стигна дотам първа. Нейният информационен документ за легитимен интерес и web scraping, публикуван за първи път през юни 2025 г., посочва, че обработването "не може да попада в рамките на разумните очаквания на субектите на данни", когато администраторът не изключва сайтове, които възразяват чрез robots.txt или проверка само за хора.

Две по-малко очевидни точки попадат сред мерките за смекчаване (параграф 66в). Едната изключва лични данни, които са видими само след вход в профила. Другата обхваща сайтове, които връщат различен изход за User-Agent на скрапер в сравнение с обикновен браузър, "особено когато услугата за извличане получава повече данни", отколкото би видял човек. Ако вашият скрапер чете по-богат вътрешен API, отколкото страницата показва, става въпрос точно за този случай.

Разгледахме машинночетимата страна на това (разширения на robots.txt, подписани ботове, сигнали за съдържание) в Search, Agent, Training: The Web's New Bot Rules, а издателите, които предпочитат да таксуват, вместо да отказват, в Pay-Per-Crawl Is Splitting the Web in Two. Проектът на EDPB е първият случай, в който регулатор третира тези сигнали като доказателство за това какво очакват хората.

Какво означава това: записвайте състоянието на robots.txt (и ai.txt, където сайтът има такъв) за всеки домейн в момента на събиране, заедно със самите данни. Ако някой попита след година защо даден източник е попаднал в набор от данни за обучение, аргументът "беше позволено в деня, когато го извлякохме" е валиден само ако сте го записали.

Скраперът може да бъде обработващ данни

Раздел 3.2.1 е кратък и лесен за пропускане. Не бива да го правите, особено ако разработвате скрапери за клиенти. Ако създавате набор от данни за обучение от името на разработчика „съгласно неговите документирани инструкции“, вие може да сте обработващ, а разработчикът да е администратор (параграф 18). Ако вие и клиентът определяте критериите за събиране заедно, може да сте съвместни администратори (параграф 20, Пример 1). Ако сте извлекли набор от данни самостоятелно и някой друг го използва повторно, всеки от вас отговаря за собственото си обработване (параграф 19).

Статията на Брайън Хенгесбо в IAPP относно проектодокумента засяга търговската страна. Когато в даден договор доставчикът е посочен като обработващ, клиентът поема дейностите по съответствие, описани в насоките, а преките задължения на самия доставчик „могат да бъдат по-ограничени и по-малко успокояващи, отколкото се смяташе досега“. Това работи и в двете посоки. Клиентът не може да прехвърли спазването на изискванията върху фрийлансъра, написал скрапера, а фрийлансър, който импровизира със списъка с източници, може по невнимание да се окаже администратор.

Какво трябва да променят екипите за данни още сега

По-голямата част от търговския скрапинг не е засегната от това. Цените, наличностите, спецификациите на продуктите и разписанията обикновено не са лични данни, така че GDPR не се прилага за тях. Проектодокументът изрично посочва, че в „смесен“ набор от данни той се прилага за частта с лични данни (параграф 13). Така че обява с име на продавач или отзив с потребителско име попада в този обхват.

За задачите, които действително събират данни за лица, ето как изискванията на проектодокумента се пренасят в даден pipeline:

Два от тези редове изискват по-подробно обяснение.

Филтрирайте по време на парсване, а не при допълнително почистване седмици по-късно. Параграф 38 посочва регулярни изрази за формати като ЕГН и телефонни номера, прилагани по време на събирането. Данните, които никога не сте съхранили, са данни, за които никога не трябва да давате обяснения, а параграф 60 заявява директно защо това е от значение за AI: след като даден модел е обучен, личните данни от него „не могат лесно да бъдат изтрити“.

Запазвайте изходния URL и времето на извличане за всеки запис. Параграф 42 изисква времеви отпечатъци за точност, но същите тези две полета отговарят на всеки последващ въпрос относно произхода на даден факт. Правилата за данните за обучение вече се затягаха съгласно AI Act (писахме за това през април) и те продължават да поставят този въпрос.

Ако разработвате за клиенти, трябва да оформите инструкциите писмено: източници, полета, изключения. Проектодокументът третира документираните инструкции като елемента, който ви прави обработващ, а не съвместен администратор, а спецификацията от една страница предотвратява бъдещи спорове за ролите.

Какво предстои след 30 октомври

Окончателният текст ще се промени, като по-съществената промяна може да дойде от Брюксел, а не от Комитета. На 21 октомври 2026 г. Съветът договори своята позиция за преговори относно Digital Omnibus, пакета, който ще измени GDPR. Според доклада на IAPP относно мандата, държавите членки добавиха "разяснения относно правното основание за обработване на лични данни и необходимостта от поддържане на подходящи гаранции" за данни за обучение на AI. Следват преговори с Европейския парламент. Каквато и да е окончателната формулировка, държавите членки искат гаранциите да останат, което сочи към балансиращ тест, много подобен на този в проекта.

Смятаме, че разделението на таргетирано и нетаргетирано събиране ще оцелее и в двата процеса, защото това е единствената част от проекта, свързана с инженерната практика, а не с правото. Регулаторът няма да чете кода на вашия crawler. Той може да изиска вашите критерии за събиране, списъка ви с източници и вашите времеви отпечатъци (timestamps), а екип, който може да ги предаде още същия следобед, няма почти нищо за оспорване.

Така че следващият въпрос, който регулатор на поверителността ще зададе за даден scraper, няма да бъде "как работи", а по-скоро: "какво му беше зададено да събира".