EDPB выпустил спецификацию для скраперов
Европейские органы по защите данных много говорили об AI-моделях. Но до этого лета ни один документ не объяснял инженеру, что именно должен делать скрапер перед тем, как запросить первую страницу.
Руководство 03/2026 по веб-скрапингу в контексте генеративного AI изменило ситуацию. Европейский совет по защите данных принял проект 7 июля 2026 года, а его общественные консультации завершаются 30 октября 2026 года. На бумаге область применения узкая: частные компании, собирающие персональные данные для обучения или дообучения генеративного AI. На практике это самое подробное описание того, как выстроить юридически защищенный процесс скрапинга, от критериев перед первым запросом до метки времени на последней записи, когда-либо опубликованное регулятором.
Наш вывод после изучения всех 23 страниц: проекту все равно, какие инструменты вы используете. Важно то, можете ли вы объяснить, что именно вы собрали, откуда и когда. Скраперы, способные ответить на это одним запросом, будут в порядке. Неограниченные краулеры столкнутся со сложностями почти в каждом абзаце.
(Отказ от ответственности: это не юридическая консультация. Во-первых, речь идет о проекте документа, а мы инженеры, которые анализируют его влияние на код.)
Целевой или нецелевой сбор: ключевая граница
Пункт 8 делит скрапинг на два типа в зависимости от точности и жесткости критериев сбора, "а не от используемых технических средств". Целевой скрапинг следует четким критериям: домен, язык, тема. Нецелевой скрапинг представляет собой краулер, переходящий по каждой найденной ссылке. Опасение регулятора понятно: по мере роста очереди контролер данных "обладает ограниченной информацией о том, какие именно персональные данные собираются и обрабатываются".
Это разделение проходит через весь текст. Принцип минимизации данных требует "определить точные критерии сбора" и провести "процесс инвентаризации и картирования данных" до начала сбора (пункт 37). Тест на необходимость в рамках законного интереса указывает: сужение критериев, "вместо скрапинга широкого сегмента интернета", может быть тем фактором, который вообще делает обработку необходимой (пункт 52). Требования к прозрачности обязывают публиковать список источников, желательно с доменными именами, URL и датами сбора (пункты 30 и 31).
Трекер цен с фиксированным списком страниц товаров на дюжине ритейл-доменов может сгенерировать все эти артефакты прямо из своего конфигурационного файла. Поиск в ширину этого сделать не может. Критика проекта от Privacy World точно подмечает это противоречие: обязательства написаны для контролера, который точно знает, что собирает, сразу после признания регулятора в том, что нецелевой краулер может содержать персональные данные, которые он не способен инвентаризировать.
Что это значит: если вы собираете данные, затрагивающие людей (отзывы с именами пользователей, объявления с именем и телефоном риелтора, ветки форумов), ваши критерии сбора становятся артефактом комплаенса. Храните их в системе контроля версий рядом со скрапером, а не в чьей-то голове.
Отказ сайта теперь играет против вас
Именно эта часть изменит большинство пайплайнов сильнее всего. В проекте перечислены технические меры, явно указывающие на то, что сайт против скрапинга: robots.txt, ai.txt, «аутентификация роботов для просмотра контента», а также проверки, которые «требуют действия, доступного только человеку» (пункт 37). Рекомендация для обучающих датасетов: исключать такие сайты.
Те же сигналы учитываются при проверке баланса интересов. Когда пользователи знают, что сайт использует эти механизмы, а его все равно парсят, согласно проекту, они с меньшей вероятностью будут ожидать обработки своих данных (пункт 64). Пример 5 описывает это прямо: если на платформе есть запрет в robots.txt, проверка на человека и заявленный запрет на обучение AI, это означает, что ее пользователи «не могут обоснованно ожидать», что третьи стороны будут скрапить их данные для этой цели. Обратное правило не работает. Отсутствие robots.txt не означает согласия (пункт 45).
Французский регулятор CNIL пришел к этому первым. Его методическое руководство по законному интересу и веб-скрапингу, впервые опубликованное в июне 2025 года, гласит: обработка «не может отвечать разумным ожиданиям субъектов данных», если контролер не исключает сайты, запрещающие доступ через robots.txt или проверку на человека.
Среди мер по снижению рисков есть два менее очевидных пункта (пункт 66c). Первый исключает персональные данные, доступные только после входа в систему. Второй относится к сайтам, отдающим скраперу другой ответ, отличный от ответа обычному браузеру, «в частности, если сервис скрапинга получает больше данных», чем увидел бы человек. Если ваш скрапер читает более детальный внутренний 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 короткий, и его легко пропустить. Этого делать не стоит, особенно если вы пишете скрейперы для клиентов. Если вы собираете обучающий датасет по поручению разработчика "согласно его документированным инструкциям", вы можете считаться обработчиком (processor), а разработчик контролером (controller, пункт 18). Если вы определяете критерии сбора вместе с клиентом, вы можете стать совместными контролерами (пункт 20, Пример 1). Если вы собрали датасет самостоятельно, а кто-то другой его переиспользует, каждый отвечает за свою часть обработки данных (пункт 19).
Брайан Хенгесбо в колонке для IAPP о проекте рекомендаций подчеркивает коммерческую сторону. Когда договор определяет подрядчика как обработчика, клиент берет на себя комплаенс, описанный в документе, а прямые обязанности самого подрядчика "могут оказаться более узкими и менее обнадеживающими, чем предполагалось". Это работает в обе стороны. Клиент не может переложить комплаенс на фрилансера, написавшего скрейпер, а фрилансер, выбравший список источников на свое усмотрение, рискует случайно стать контролером.
Что командам данных стоит изменить уже сейчас
Большей части коммерческого скрейпинга это не касается. Цены, складские остатки, характеристики товаров и расписания обычно не являются персональными данными, поэтому GDPR на них не распространяется. В проекте четко указано, что в "смешанных" датасетах правила применяются к персональной части (пункт 13). То есть карточка товара с именем продавца или отзыв с никнеймом пользователя попадают под действие регламента именно в этой части.
Для задач, где данные людей все-таки собираются, требования проекта транслируются в пайплайн следующим образом:
| Требование проекта | В вашем пайплайне |
|---|---|
| Критерии сбора данных | Паттерны URL для каждого задания |
| Фильтрация по синтаксису | Дроп через Regex на этапе парсинга |
| Записи с таймстемпами | Поле fetched_at в каждой строке |
| Список источников | Домены в конфигурации |
| Учет запретов на сбор | Логирование состояния robots.txt |
Две строки из таблицы требуют отдельного внимания.
Фильтруйте данные на этапе парсинга, а не во время очистки спустя недели. В пункте 38 прямо указаны регулярные выражения для таких форматов, как номера соцстрахования и телефоны, применяемые прямо во время сбора. Данные, которые вы не сохранили, не придется объяснять, а пункт 60 прямо говорит, почему это критично для AI: после обучения модели удалить из нее персональные данные "не так просто".
Сохраняйте исходный URL и время получения (fetch time) для каждой записи. В пункте 42 таймстемпы требуются для обеспечения точности, но эти же два поля снимут любые будущие вопросы об источнике факта. Требования к обучающим выборкам уже ужесточались в рамках AI Act (мы писали об этом в апреле), и там возникает тот же самый вопрос.
Если вы разрабатываете решения для клиентов, фиксируйте инструкции письменно: источники, поля, исключения. Согласно проекту, именно документированные инструкции определяют вас как обработчика, а не совместного контролера. Спецификация на одну страницу избавит от споров о ролях в будущем.
Что произойдет после 30 октября
Окончательный текст изменится, и более серьезные корректировки могут поступить из Брюсселя, а не от Совета. 21 октября 2026 года Совет согласовал свою переговорную позицию по Digital Omnibus, пакету поправок к GDPR. Согласно отчету IAPP о мандате, государства-члены добавили «разъяснения относительно законных оснований для обработки персональных данных и необходимости соблюдения надлежащих мер предосторожности» для обучающих данных AI. Далее предстоят переговоры с Европейским парламентом. Какими бы ни оказались итоговые формулировки, страны-участницы настаивают на сохранении защитных мер, что указывает на тест на баланс интересов, аналогичный предложенному в этом проекте.
Мы считаем, что разделение на таргетированный и нетаргетированный сбор сохранится в обоих процессах, поскольку это единственная часть проекта, касающаяся инженерии, а не юриспруденции. Регулятор не станет читать код вашего краулера. Он может запросить критерии сбора, список источников и таймстемпы, и команде, способной предоставить эти данные в тот же день, практически не о чем спорить.
Поэтому следующий вопрос регулятора к разработчикам скрапера будет звучать не «как это работает», а скорее «что именно ему было поручено собирать».