Кожне поле у формі заявки — це дані, за які ти несеш відповідальність: потрібно зберігати їх безпечно, уміти пояснити, для чого вони зібрані, і в підсумку видалити. Чим більше полів «про всяк випадок», тим більше відповідальності без будь-якої користі, а ще часто менше відправлених форм, бо люди кидають посеред довгого списку.
На цій сторінці: що саме означає принцип мінімізації даних з RODO, простий тест із трьох питань для кожного поля форми, які дані фірма послуг найчастіше збирає про запас без потреби, і як збирати решту поступово — на етапі, коли дані дійсно стають потрібні.
Принцип мінімізації даних з RODO
Посібник з RODO, підготовлений Управлінням із захисту персональних даних, цитує текст ст. 5 RODO: персональні дані мають бути адекватними, відповідними та обмеженими до того, що необхідне для цілей, в яких вони обробляються — це і є принцип мінімізації даних. Та ж стаття додає ще два принципи, які стосуються форми не менше: дані мають бути правильними і за потреби оновлюватися, а також зберігатися у формі, що дозволяє ідентифікувати особу, не довше, ніж це необхідне для мети, для якої вони були зібрані (обмеження зберігання).
Три принципи, три питання
Принцип мінімізації означає, що дані мають бути обмежені необхідним. Принцип правильності вимагає, щоб дані були актуальними та виправлюваними. Принцип обмеження зберігання означає, що дані потрібно видалити, коли вони перестануть бути потрібними. Ці три принципи перетворюються на три питання до кожного поля: навіщо нам ці дані, як довго вони залишатимуться актуальними, і коли ми їх видалимо?
З трьох принципів випливають три питання, які варто поставити про кожне поле форми, перш ніж залишити його: для якої конкретної мети це поле потрібне зараз, чи залишаться дані актуальними, чи потрібно їх оновлювати, і як довго вони взагалі мають сенс. Поле, на яке немає відповіді на перше питання, не повинно залишатися у формі.
Як перевірити кожне поле у формі
На практиці це проста таблиця, яку заповнюють один раз для всієї форми, а потім повертаються до неї при кожній зміні:
| Поле | Мета зараз | Що буде без нього | Коли видаляємо |
|---|---|---|---|
| Ім'я та телефон або email | зворотний зв'язок по заявці | неможливо відповісти клієнту | після завершення обробки заявки або за політикою зберігання |
| Короткий опис справи | підбір відповіді, попередня кошторис | доведеться уточнювати по телефону з нуля | разом з контактними даними |
| Повна адреса проживання | проїзд бригади на місце | неможливо спланувати візит | разом з даними замовлення, після його завершення |
| Дата народження / PESEL | оформлення договору або іменного рахунку-фактури | неможливо скласти юридичний документ | відповідно до правил зберігання документації, не «про всяк випадок» |
Колонка «що буде без нього» тут найважливіша: якщо чесна відповідь — «нічого не буде, просто у нас було б більше даних» — поле видаляється з форми, а не з таблиці.
Поля, що збираються про запас у формах фірм послуг
При першому контакті — коли клієнт лише запитує ціну або термін — фірма послуг найчастіше зовсім не потребує: повної адреси проживання (достатньо району або міста, якщо взагалі), дати народження, номера PESEL, скану або фото документа, що посвідчує особу, а також обов'язкового поля «звідки ви про нас дізналися» — це дані, корисні для маркетингу, а не для відповіді на питання. Жодне з цих полів не заборонене саме по собі — питання в тому, чи потрібне воно саме на цьому етапі розмови.
Коли ті ж дані стають потрібними
Адреса проживання має сенс, коли бригада дійсно їде на місце — тобто на етапі запису на прийом, а не запиту ціни. NIP і повні дані для рахунку-фактури потрібні при виставленні документа продажу, не раніше. Дата народження іноді вимагається законом при конкретних послугах (наприклад, деякі фінансові чи медичні) — тоді її збирають на етапі, коли цього вимагає закон, а не профілактично при першому кліку.
Чому поле «звідки дізналися» зазвичай непотрібне
Це поле збирає дані, корисні для маркетингу, а не для відповіді на питання клієнта. Якщо фірма хоче знати, звідки приходять клієнти, вона може відстежувати це в Google Analytics або запитати по телефону — але це не має бути обов'язковим полем у формі першого контакту.
Штраф для Glovo: кінець збору даних «про всяк випадок»
Рішення UODO від 16.03.2026 показує, до чого призводить збір даних про запас. Оператор додатку Glovo (Restaurant Partner Polska) без правової підстави отримував скан-копії та фотографії посвідчень особи або паспортів користувачів додатку для перевірки особи. Голова UODO встановив, що оператор обробляв надлишкові дані, причому без правової підстави та неадекватні заявленим цілям, порушивши, зокрема, принцип мінімізації даних зі ст. 5 RODO — і призначив штраф у розмірі 5 898 064 зл, зобов'язавши також видалити зібрані таким чином дані протягом 30 днів з моменту вручення рішення.
Фразу з обґрунтування рішення варто запам'ятати дослівно: протидія шахрайству не може здійснюватися за рахунок порушення принципу мінімізації даних. Практичний висновок для малої фірми послуг: «може знадобитися» ніколи не є самостійною метою обробки даних.
Вільне текстове поле і дані особливої категорії
Вільне текстове поле у формі має свою пастку: люди пишуть у ньому більше, ніж передбачає питання, а іноді набагато більше, ніж фірма взагалі має мати. У полі «опишіть свою проблему» клієнти можуть згадати хворобу, сімейні обставини, конфлікт з іншою особою — тобто дані особливої категорії, які вимагають додаткового захисту та окремої правової підстави для обробки.
Практичне рішення полягає не в видаленні поля — воно часто найкорисніше у всій формі — а в короткій підказці поруч із ним, наприклад: «коротко опишіть, чого стосується справа; деталі обговоримо по телефону», яка природно обмежує те, що люди туди пишуть. Якщо ж у полі все одно з'являться дані особливої категорії, рішення про те, як їх далі обробляти — чи можна їх взагалі обробляти і на якій підставі — варто узгодити з інспектором із захисту даних (IOD), якщо він є у фірмі, або з юристом, що спеціалізується на RODO.
Менше полів, більше відправлених заявок — приклад на умовних числах
Скорочення форми має ще й практичний побічний ефект, окрім відповідності закону — менше людей кидають на півдорозі. Приклад на умовних числах, підстав свої: форма на сайті бачить 200 людей на місяць, які починають її заповнювати.
Різниця 70 заявок на місяць при тому самому трафіку на сайті. Це не галузева норма і не гарантія — це ілюстрація механізму: кожне додаткове поле — це ще один момент, коли хтось може закрити вкладку.
Поступовий збір даних на наступних етапах
Замість того, щоб питати все одразу, дані збираються на послідовних етапах, які й так слідують один за одним у природному ході розмови з клієнтом:
Сценарій після роботи:
- 01заявка (контакт + тема)
- →02телефонний дзвінок
- →03кошторис або запис (адреса, NIP)
- →04договір
На етапі самої заявки формі потрібно лише те, що дозволить передзвонити і зрозуміти, в чому справа. Адреса з'являється лише тоді, коли потрібно спланувати проїзд, а повні дані для рахунку-фактури — лише при виставленні самого документа.
Приховані місця збору даних
Принцип мінімізації стосується контактної форми, але точно так само стосується чат-бота на сайті, переписки в месенджері, AI-ресепшна, що приймає дзвінки, і поля «нотатки» в CRM, куди працівник вносить все, що почув від клієнта. Це місця, де персональні дані накопичуються часто непомітно.
Міністерство цифровізації нагадує, що AI Act не замінює RODO — обидва застосовуються паралельно. Чат-бот, який чесно каже, що він AI, все одно має дотримуватися принципу мінімізації при тому, що він збирає.
Заявки, що не стали клієнтами
Не кожна заявка закінчується договором, і це нормально — але дані із заявок, що ні до чого не привели, теж підпадають під принцип обмеження зберігання: зберігаються не довше, ніж це необхідне для мети, для якої вони були зібрані. Мета заявки, що не відбулася, спливає в певний момент — і фірма сама вирішує коли, і записує це рішення як політику.
Конкретний термін — три місяці, півроку, рік — залежить від галузі і від того, як довго реалістично клієнт може повернутися до теми; це рішення варто узгодити спільно з інспектором із захисту даних або юристом.
Що зробити самому за 30 хвилин
Цей аудит не вимагає жодного інструменту, крім самої форми та аркуша паперу:
- Зроби скріншот поточної форми заявки — всіх її полів, включаючи приховані або необов'язкові.
- Випиши кожне поле в таблицю з розділу вище: мета зараз, що буде без нього, коли видаляємо.
- Для кожного поля, на яке немає чіткої відповіді на перше питання, прийми рішення: прибери його з першого кроку або перенеси на етап, на якому воно дійсно стає потрібним.
- Відправ тестову заявку через свою форму і перевір, куди саме ці дані потрапляють і хто має до них доступ.
Як це виглядає, коли дані збирає система
Сценарій, у якому збір даних спроектовано по етапах:
- 01коротка форма
- →02картка в CRM
- →03відсутні дані запитуються на потрібному етапі
- →04нагадування про термін зберігання
Людині залишається рішення про те, яке поле дійсно потрібне на кожному етапі і який термін зберігання встановити для заявок, що не стали договором — система стежить за тим, щоб ці домовленості застосовувалися послідовно. CRM та автоматизації зводять телефон, форму, месенджери та картку Google в одне місце запису. Лід-форми дозволяють будувати короткі форми з умовною логікою, де наступне питання залежить від попередньої відповіді. Сайти та магазини з коротшими формами зазвичай йдуть в парі зі зрозумілішим сайтом навколо одного рішення клієнта — замовити, забронювати або зателефонувати. UX і конверсія допомагає знайти місця, де клієнти відмовляються, в тому числі через довгі форми. AI-чат-бот відповідає на питання після робочого часу і збирає контактні дані. Дані клієнтів об'єднують інформацію з різних джерел в один профіль.
Якщо ти замислюєшся, чому люди взагалі не закінчують заповнювати форму, подивися чому клієнти не залишають запитів. Про те, де фізично знаходяться дані клієнтів, читай у статті автоматизація і RODO. Про те, як обробляти всі заявки з однієї черги, ми пишемо у статті автоматизація обробки запитів. О том, что происходит с запросом после первого разговора, смотри автоматизация follow-up.
Відповіді на часті запитання
Означає принцип мінімізації даних, що форма має мати якомога менше полів?
Не зовсім — він означає, що кожне поле має мати конкретну мету, для якої воно необхідне. Іноді це означає менше полів, а іноді просто інший момент їх збору: дані переносяться з першого кроку на етап, коли вони дійсно стають потрібними, замість того, щоб питати все одразу.
Заборонене поле «звідки ви про нас дізналися»?
Воно не заборонене саме по собі, але рідко необхідне для відповіді на питання клієнта — це дані, корисні для маркетингу, а не для обробки заявки. Якщо хочеш їх збирати, варто робити це усвідомлено, з ясною метою, а не автоматично в кожній формі.
Як довго можна зберігати дані із заявки, що не стала клієнтом?
Посібник з RODO говорить про обмеження зберігання до терміну, необхідного для мети обробки, але не називає конкретного числа днів або місяців — фірма сама встановлює термін і записує його як політику, бажано після консультації з інспектором із захисту даних або юристом.
Чи потрібно відразу видаляти дані особливої категорії, введені в поле «опишіть проблему»?
Готової відповіді тут немає — це залежить від того, чи існує правова підстава для їх обробки в даному контексті. Таке рішення варто узгодити з інспектором із захисту даних або юристом, а не приймати самостійно при обробці одиничного звернення.
Чи повинен AI-чат-бот на сайті дотримуватися тих самих правил, що і форма?
Так. Принцип мінімізації даних з RODO застосовується до кожного місця, де фірма збирає персональні дані, незалежно від того, форма це, чат-бот чи переписка в месенджері. AI Act додає окрему обов'язковість прозорості — чат-бот має явно казати, що він AI — але він не замінює правила захисту даних.
Штраф для Glovo стосується і малих фірм послуг?
Розмір штрафу залежить від масштабу порушення і багатьох інших факторів, але принцип, який UODO підтвердив у цьому рішенні, стосується кожного оператора даних: протидія шахрайству або «безпека про всяк випадок» не виправдовують збору даних більше, ніж необхідно для мети.
Чи допомагає форма з умовною логікою з мінімізацією даних?
Так. Багатокрокова форма з питаннями, що залежать від попередніх відповідей, показує користувачеві лише ті поля, які для нього актуальні. Хтось, хто питає лише ціну, не бачить полів, потрібних для запису на прийом. Це реалізує принцип мінімізації в самому проектуванні форми — ти питаєш лише те, що дійсно потрібно в даному сценарії.