Скрейпінг для тренування генеративних моделей ШІ. Як взаємодіяти учасникам по різні боки процесу

Для навчання генеративних моделей потрібні масиви даних. Залежно від потреб, часто для збору даних використовується скрейпінг сайтів. 

Скрейпінг для тренування генеративних моделей ШІ. Як взаємодіяти учасникам по різні боки процесу

Скрейпінг – це спосіб автоматизованої обробки даних з сайтів, який дозволяє швидко збирати великі обсяги інформації за допомогою спеціальних сервісів, розширень браузера, додатків, окремих бібліотек. Ці інструменти зчитують вебсторінки для подальшого використання в аналітиці, маркетингу, машинному навчанні чи моніторингу тенденцій, цін тощо. Цей “просунутий копіпаст” допомагає автоматизувати збір і накопичити великий обсяг даних відносно невеликими зусиллями. 

У цій статті я розгляну, як “скрейпити” наскільки це можливо законно з точки зору приватності, і як вибудувати відносини між розробниками ШІ та власниками вебсайтів так, щоб враховувалися інтереси обидвох сторін. 

Правове регулювання 

Чим більше з’являтиметься технологій, тим більше норм застосовуватимуться за аналогією. Регулювання сфери “наперед”, до того, як технології виникнуть, зробить такі рішення адаптивними для обходу законодавства, а самі закони – не ефективними. 

Законів, які безпосередньо регулюють скрейпінг, немає. Найбільш дотичні акти, які впливають на шляхи і можливості скрейпінгу, – це акти у сферах: 

  • приватності;
  • інтелектуальної власності;
  • розгортання технологій та ризиків в цифрові часи (DMCA та CFAA);
  • безпосередньо ШІ (європейський AI Act); 
  • а також саморегулювання ШІ індустрії. 

Спільно вони створюють рамку “to go” і “no go” для розробників ШІ і навіть користувачів ШІ систем. 

З моменту одомашнення сервісів з генеративним ШІ тривають дискусії про етичність розробок та правові прогалини, які часто зводяться до порушень прав інтелектуальної власності. 2-3 роки тому почали з’являтися перші спори щодо скрейпінгу, а зараз суди ухвалюють перші остаточні рішення. У них часто визнають скрейпінг порушенням, наприклад: 

  • порушенням авторських прав – LinkedIn v. hiQ Labs, Thomson Reuters v. Ross Intelligence, Facebook, Inc. v. Power Ventures, Inc., та ін., X Corp. v. Bright Data Ltd., NYT v. OpenAI; 
  • порушенням умов користування сайту – Canadian Legal Information Institute (“CanLII”) v. Clearway Management Ltd. та ін.;
  • порушенням «browsewrap» і «clickwrap» договорів – X Corp. v. Bright Data Ltd..

NYT v. OpenAI ще очікують на остаточне рішення, а спір між Meta Platforms, Inc. v. BrandTotal Ltd нещодавно врегулювався конфіденційною мирною угодою. Якими б різними не були початкові вимоги сторін чи фінальні рішення, усі ці кейси формують бізнес-практику і правову “терпимість” до скрейпінгу. 

Ролі учасників & підстави обробки 

Аналізуючи GDPR чи UK GDPR, ми можемо прослідкувати однакову логіку: 

  • Розробник повинен бути зареєстрованим на території ЄС/Великої Британії або скрейпити сайти, які містять персональні дані резидентів ЄС/Великої Британії, щоб підпадати під дію закону ЄС чи ВБ. 
  • Власник вебсайту підпадатиме під дію GDPR чи UK GDPR, коли оброблятиме (збиратиме, публікуватиме тощо) дані резидентів з ЄС чи Великої Британії або ж сам буде зареєстрований на території країн ЄС чи у ВБ, незалежно від того, де знаходитимуться його користувачі.

Роль Розробників

Розробники будуть контролерами щодо даних, якщо вони самостійно визначають обсяг персональних даних і засоби, за допомогою яких збирають дані для навчання (тренування) своїх моделей. Зараз регулятори розглядають легітимний інтерес як найбільш відповідну підставу обробки. Це зобов’язує розробників документувати процеси та проводити два оцінювання: 

  • Data Protection Impact Assessment (DPIA) – оцінювати ризики при потенційній обробці даних та 
  • Legitimate Interests Assessments (LIA) – оцінювати використання легітимного інтересу як підстави обробки.

Британський регулятор ICO допускає використання легітимного інтересу як належної підстави для обробки. У ЄС, Рада EDPB (консультативний орган з питань приватності) опублікувала рекомендаційне рішення, де також визнала, що розробники можуть посилатися на легітимний інтерес, якщо доведуть, що: 

  • їхні інтереси переважатимуть над інтересами та правами суб’єктів даних;
  • збір даних методом скрейпінгу – єдиний можливий варіант, щоб досягти мети (тобто – зібрати саме цей тип даних для тренувального датасету);
  • інтерес в обробці повинен бути законним, а не гіпотетичним (спекулятивним).

Однак раніше Нідерландський регулятор (AP) заперечував, що легітимний інтерес буде належною підставою, оскільки інтерес розробників як суто комерційний інтерес не переважуватиме ризики для прав і свобод суб’єктів даних. З невідомих причин роз’яснення AP не доступне на сайті. З одного боку, це може вказувати зміну позиції регулятора. З іншого ж, дискусії у цьому напрямку аж ніяк не послаблюють вимоги з документування DPIA та LIA для обґрунтування легітимного інтересу.

Роль власників вебсайтів 

Власники вебсайтів зазвичай самостійно визначають, в якому обсязі потрібно відображати дані на сайті, дбають про захищеність сайту, а відтак про захищеність самих даних. Відповідно вони підпадають під визначення контролера. Часто вони публікуватимуть дані користувачів на підставі виконання договору або закону, рідше – якщо користувач надав згоду або існує легітимний інтерес. 

Здебільшого власники вебсайтів не зацікавлені у скрейпінгу. Особливо з їхнім небажанням можна погодитися, коли на сайті багато візуальних об’єктів або й інших творів, захищених авторським правом. Однак ринок вільний та конкурентний, а тому власники вебсайтів можуть йти на зустріч розробникам — тобто надавати дані для скрейпінгу. Канадський регулятор (OPC) зазначає, що це така ж “робоча схема” скрейпінгу чи для комерційних, чи суспільно корисних цілей, якщо тільки власник вебсайту зможе: 

  • довести законність підстав скрейпінгу;
  • прозоро повідомляти про це користувачів;
  • за потреби отримувати додаткову згоду від людей, чиї дані так оброблятимуться. 

Також OPC рекомендує надавати скрейперам доступ через API, оскільки це дозволить власникам вебсайтів мати більший контроль над даними. 

Інтереси суб’єктів даних 

У відносинах між розробниками і власниками вебсайтів звичайні користувачі не зовсім самостійні учасники. Вони зазвичай не підозрюватимуть, що їхні дані скрейпляться, а ймовірність випадкового упізнання власних даних у результатах роботи ШІ – дуже низька. Виходить, що власники вебсайтів мимоволі представляють інтереси користувачів, відповідальні за їх безпеку, і щобільше за реалізацію їхніх прав. 

Якщо власники вебсайтів зацікавлені у скрейпінгу, вони повинні забезпечити законну підставу, не маскувати своїх намірів та повідомляти про це користувачів. Якщо ж власники проти скрейпінгу, – прийдеться інтегровувати багаторівневу безпеку. 

За GDPR, контролери та процесори повинні впроваджувати адміністративні та технічні заходи безпеки, що відповідають ступеню ризику. З адміністративного боку, власники вебсайтів можуть передбачати в умовах використання сайтом положення про заборону скрейпінгу. Такі положення матимуть юридичну силу, їхнє порушення буде порушенням договору (умов використання). Але на практиці це положення не буде ефективним – воно не вбереже сайт від скпейпінгу. Власники вебсайтів повинні одночасно впроваджувати технічні заходи, які унеможливлюватимуть парсинг, і якісно прописувати умови використання, які в майбутньому можуть полегшити обстоювання прав на контент. Не менш важливо, що сукупність різних практик як знижуватиме ризик скрейпінгу, так і берегтиме від потенційного штрафу. 

У 2023 році 16 регуляторів (Австралія, Канада, Великобританія, Китай, Норвегія, Швейцарія, Нова Зеландія, Колумбія, Марокко, Джерсі, Аргентина, Мексика, Іспанія, Гернсі, Монако, Ізраїль) опублікували спільну позицію про скрейпінг та захист приватності. Ці регулятори визнали, що загальнодоступні, опубліковані на сайтах дані все одно підлягають захисту з точки зору персональних даних, а масове вилучення персональних даних, які містять особисту інформацію, може розглядатися як витік даних. На противагу, поєднання адміністративних та технічних заходів безпеки у позиції називали “багаторівневим технічним та процедурним контролем.”

Отож, розділяючи технічні рішення на сектори інфраструктурної безпеки рекомендують

  • використовувати фаєрволи та блокувати підозрілий трафік на сайт;
  • обмежувати та контролювати доступ до API;
  • обмежувати JavaScript на стороні клієнта;
  • убезпечувати дані і у мобільних застосунках. 

Французький регулятор, CNIL, також радить

  • використовувати robot.txt або ai.txt файли, які унеможливлюватимуть парсинг;
  • застосовувати анонімізацію та псевдонімізацію до зібраних даних; 
  • обмежувати доступ до наповнення сайту користувачам без облікового запису;
  • мінімізувати типи даних, які збираються власником сайту загалом, або фільтрувати та видаляти непотрібні категорії одразу після збору (банківські операції, геолокацію) чи до моменту публікації (конфіденційні дані, дані неповнолітніх), якщо вони не потрібні. 

Збираємо пазл докупи

У процесі скрейпінгу власники сайтів і розробники мають майже дзеркальні обов’язки. Якщо перші вирішили обмежити доступ до даних та встановили технічні обмеження на сайті, якщо їхній контент захищається авторськими правами чи містить персональні дані, – розробники повинні розуміти ці обмеження. 

Щобільше, перешкоди на етапі забору інформації ускладнюють і описову, операційну роботу, де потрібно обґрунтувати законність використання даних. І навпаки: якщо власники вебсайтів прозорі у своїх намірах продавати інформацію, комунікують про це з суб’єктами даних і надають усі opt-out можливості – розробники отримують зелене світло. Погодження на відправному етапі не лише спрощує доступ до даних, але й полегшує оформлення необхідних оцінок та дозволів, оскільки тоді не потрібно фантазувати над суспільним інтересом чи продумувати потенційну стратегію захисту у випадку спору. 

6 Підписатись на новини