Використання Google reCAPTCHA відповідно до захисту даних

Google reCAPTCHA аналізує поведінку користувачів для виявлення ботів і завантажує ресурси з Google (США), часто вже під час завантаження форми.

reCAPTCHA — особливий випадок, оскільки мету — захист від спаму та зловживань ботами — у принципі можна обґрунтувати законним інтересом за ст. 6(1)(f) GDPR. Проте це нічого не змінює щодо § 25 TDDDG: щойно reCAPTCHA v2/v3 завантажує скрипти Google та встановлює чи зчитує ідентифікатори, що виходять за межі технічно необхідного, доступ до кінцевого пристрою потребує згоди. Судова практика тут ще неоднорідна; консервативна лінія — включити reCAPTCHA до згоди.

Практичний компроміс багатьох операторів: завантажувати reCAPTCHA лише на сторінках, які справді містять форму (контакти, вхід, реєстрація), а не глобально через шаблон. Це обмежує передавання даних випадками, коли воно виконує конкретну захисну функцію, і робить зважування інтересів стійкішим. reCAPTCHA v3, що працює на всіх сторінках для формування оцінки, з погляду захисту даних обґрунтувати значно важче.

Існують ощадливіші щодо даних альтернативи, які повністю уникають передавання до Google: hCaptcha (варіант хостингу в ЄС), Cloudflare Turnstile (без видимої капчі, без файлів cookie), Friendly Captcha (хостинг у Німеччині) або — для простих форм — серверний honeypot плюс обмеження частоти запитів. Для багатьох невеликих сайтів останнього варіанта достатньо, і він обходиться без будь-якого передавання третім особам.

Це ризик?

Захист від спаму може бути законним інтересом (ст. 6 ч. 1 п. f GDPR). Але якщо reCAPTCHA встановлює непотрібні ідентифікатори або завантажується на всіх сторінках, постає § 25 TDDDG. Передавання до США потрібно обґрунтувати.

Що ви можете зробити

• Завантажуйте reCAPTCHA лише на сторінках з формами, а не глобально.
• Розгляньте ощадливі щодо даних альтернативи (напр. hCaptcha, honeypot, обмеження на боці сервера).
• У політиці конфіденційності зазначте мету, правову підставу, Google як одержувача і передавання до США.

Поширені запитання

Чи дозволена reCAPTCHA без банера cookie?

Оцінюється неоднозначно. Оскільки reCAPTCHA завантажує скрипти Google та обробляє ідентифікатори, консервативна лінія — включити її до згоди. Деякі оператори обґрунтовують суто формове застосування законним інтересом — це ризик.

Яка альтернатива уникає передавання до Google?

Cloudflare Turnstile, hCaptcha з хостингом у ЄС або Friendly Captcha не передають дані до Google. Для простих форм часто достатньо серверного honeypot з обмеженням частоти запитів.

Чи достатньо завантажувати reCAPTCHA лише на сторінках із формами?

Це суттєво зменшує передавання даних і посилює зважування інтересів, але не знімає повністю питання згоди за § 25 TDDDG. Найважче обґрунтувати глобально працюючу reCAPTCHA v3.

Що має бути в політиці конфіденційності?

Мета (захист від спаму/ботів), правова підстава, Google як отримувач, передавання до США та його підстава, а також посилання на власні положення Google про захист даних та умови використання.

Як допомагає consentglass

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