Експертиза · Відповідність GDPR і Закон 195/2024

Ми впроваджуємо систему, яка спілкується з клієнтами в стані, в якому її можна показати контролеру, і перевіряємо це з коду, а не з анкети.

Закон nr. 195/2024 застосовується в Республіці Молдова з 23 серпня 2026 року і транспонує GDPR. Ми робимо інженерну частину: інвентаризуємо те, що система фактично збирає, перевіряємо реальну поведінку сторінки, пишемо реєстр операцій з обробки та впроваджуємо зберігання, згоду й видалення як функції, що працюють. Ми не надаємо юридичних консультацій.

Обговорити проєкт

Вже збудованоДві власні реалізації, плюс робота, зроблена на нас самих. Перша: `gdpr-scan-md`, детермінований сканер без компонента штучного інтелекту, публічний на `ongdpr.md` (перевірено через curl 06.09.2026: redirect 308 до `/ro`, потім 200 з 95.131 байтом). Має сім модулів, ваги й пороги, записані в одному файлі як єдине джерело істини, і 488 тестових випадків `it()`/`test()` у каталозі тестів двигуна. Друга: повний текст Закону 195/2024, змодельований у машинному форматі — 90 статей, 384 пункти, 408 літер, 9 розділів, 16 секцій — з MD5 PDF джерела та методом вилучення, записаними у файл, щоб цитату можна було перевірити аж до сторінки. Третій доказ, який говорить найбільше: реєстр art. 30 цього сайту, написаний для нас, із власними задекларованими обмеженнями та вісьмома пунктами, що ще відкриті. Обов’язкова примітка: ми не є юридичною фірмою і не надаємо юридичних висновків. Технічний інструмент не замінює юриста, і ми кажемо це і в продукті, не лише тут.

Закон nr. 195/2024 про захист персональних даних було ухвалено 25 липня 2024 року, опубліковано в Monitorul Oficial nr. 367-369 від 23 серпня 2024 року і він набув чинності 23 серпня 2026 року. Він транспонує Регламент (ЄС) 2016/679. Для компанії в Молдові це означає, що обов’язки, про які досі говорили як про «щось європейське», відсьогодні є місцевими обов’язками, з місцевим органом і штрафами, які обчислюються в леях або у відсотку від обороту, беручи більшу суму.

Частина, якою займаємося ми, є інженерною. Система, що спілкується з клієнтами — сайт із формою, чат-асистент, агент, який відповідає на телефонні дзвінки, CRM — збирає дані в місцях, які ніхто вже не пам’ятає після другого року. Опублікована політика говорить одне, код робить інше, а розбіжність не видно, доки хтось не запитає. Робота починається, отже, з коду та реальної поведінки сторінки, а не з анкети, заповненої кимось, хто пам’ятає, як було минулого року.

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

Результат вимірюється інакше, ніж прийнято. Не кількістю створених документів, а тим, скільки публічних тверджень залишилося в силі після перевірки. На власному нашому сайті цей досвід означав насамперед видалення: щорічний незалежний тест на проникнення, 180-денний журнал аудиту, шифрування для всіх баз даних, щоденні резервні копії поза офісом, чотирнадцять субпроцесорів і два місця розміщення — жодне не вдалося підтвердити доказом, отже жодне не залишилося на сторінці.

Відповідність GDPR і Закон № 195/2024 — інженерна частина · відео румунською, із субтитрами та розшифровкою українською

Повна транскрипція

Давайте одразу перейдемо до суті. Ласкаво просимо до нового аналізу, сьогодні ми розглядаємо величезний виклик для всього, що означає бізнес-середовище, особливо в контексті нових регламентів у Республіці Молдова. Наш абсолютний фокус сьогодні — як перевіряти відповідність прямо з коду, а не з якихось нескінченних стосів паперів. Дуже часто, коли йдеться про конфіденційність, усі дивляться на юридичні документи, викладені на сайті, але, сюрприз, документи майже ніколи не відображають технічну реальність системи, тож сьогодні ми якраз і досліджуємо, як можемо витягнути чисту правду прямо з інфраструктури. Розділ 1. Ілюзія декларативної відповідності. Або, іншими словами, що ми офіційно декларуємо на папері і що насправді робимо на практиці. Подумайте трохи, що насправді робить сайт у фоновому режимі, коли ніхто на нього не дивиться. Віртуальний асистент або інтернет-магазин розкидає дані по різних закутках, які, якщо чесно, технічна команда, ймовірно, повністю забула через два роки після запуску.

Десятки сторонніх інструментів, аналітичні скрипти, маркетингові коди — усе це тихо працює у фоні, і без технічного погляду під капот просто неможливо точно знати, хто і які дані витягує або куди їх надсилає. І ось тут і є пастка. З одного боку маємо теорію, ту статичну політику конфіденційності, незмінну роками і, найчастіше, засновану на шаблоні. А з іншого боку? А, з іншого боку — реальність. Код живий, надзвичайно динамічний, постійно оновлюється і всмоктує дані у фоновому режимі. Цей розрив між теорією і практикою невидимий, аж поки не настане жорсткий аудит або, що набагато гірше, витік безпеки, коли вже ніхто не може ігнорувати слона в кімнаті. Йдемо далі до розділу 2, MISA, а саме до Закону 195/2024, з прямим і досить жорстким впливом, починаючи з 23 серпня 2026.

Практично йдеться про європейські зобов’язання, перенесені сюди у формі місцевих, суворих правил у Республіці Молдова, а максимальна межа штрафів? 2 мільйони леїв. Так, ви правильно почули? 2 мільйони. Ці санкції спеціально створені, щоб відбивати охоту до ігнорування. Якийсь жалюгідний банер для cookie, який технічно не працює як слід, — це вже не просто помилка дизайну. Це величезна юридична й фінансова вразливість. Закон дуже чіткий і майже не прощає. Завжди застосовується найбільше значення між фіксованою сумою та відсотком від обороту. За базові зобов’язання санкції сягають 1 мільйона леїв або 1% від обороту. Але увага, ключові елементи, тобто все, що стосується згоди, прав людей і передачі даних, автоматично переходять у верхню межу, максимум 2 мільйони леїв або 2%. Ідея, яку слід запам’ятати: будь-яка технічна помилка на стороні згоди карається без жодних поблажок на максимальному рівні.

Що приводить нас до третього розділу, перевірки з коду або, як мені подобається це називати, витягування абсолютної технічної правди. З огляду на ті величезні штрафи ми просто більше не можемо покладатися на пам’ять людей чи на якісь поспіхом відмічені анкети. Рішення — в інженерії, а процес має три залізні кроки. Крок 1. Читаємо джерело. Опитуємо сервер, щоб чітко побачити, що потрапляє в пам’ять. Крок 2. Надзвичайно важливий. Натискаємо кнопку відмови від cookie і слухаємо мережевий трафік приблизно 3 секунди. Якщо інструменти у фоновому режимі продовжують смоктати дані, усе ясно, це проблема. І крок 3. Оформлюємо знаменитий Регістр діяльностей з обробки, спираючись лише на ці беззаперечні технічні докази. Так документ стає прив’язаним до реальності. Щоб усе це стандартизувати, технічні інструменти, такі як сканер GDP Scan MD, використовують фіксований математичний бал, з максимумом 1.

Але тут є одне золоте правило, дуже жорстке правило. Один-єдиний критичний елемент, що провалився, миттєво обмежує підсумковий бал до 0,49. Бам, невідповідність. Це означає, що ви можете мати найкрасивішу і найкраще написану політику конфіденційності у світі, але якщо трекер запускається до того, як відвідувач натисне «прийняти», ви провалили тест. Документи просто не можуть врятувати погано написаний код. Переходимо до розділу 4. Реальний випадок на власній платформі. Технічний аудит радикальної прозорості. Щоб довести, що це працює, команда, яка стоїть за методологією, вирішила протестувати свій власний інструмент прямо на своєму сайті. І що б ви думали? З роками на їхній публічній сторінці зібралися всілякі фантастичні корпоративні твердження. Журнал аудиту на 180 днів, шифрування абсолютно всіх баз даних, десь 14 субобробників. Звучало надзвичайно професійно, чи не так?

От тільки все це з’явилося там за інерцією. Їх просто скопіювали з одного внутрішнього документа в інший, не перевіривши, чи з основного коду ще справді актуальні ті речі. Тож вони застосували технічне правило з абсолютною суворістю. Немає первинного документа, витягнутого прямо з коду, для твердження? Видаляється! Вони провели масштабне генеральне прибирання. Купа пишномовних фраз про старі тести чи нерелевантні резервні копії зникла безслідно. Причина? Проста. Набагато, набагато безпечніше мати сторінку відповідності коротшу, чесну і на 100% прив’язану до реальних фактів, ніж dossier, повний обіцянок, які ви не можете довести у разі перевірки. Ага, і крім цього прибирання, самоаудит виявив щось захопливе, пов’язане з інтелектуальними чатботами на базі AI. Вони несуть із собою три основні ризики. 1. По-перше, вони зберігають усілякі чутливі дані, які відвідувачі кидають туди абсолютно без запиту.

2. Неминуча передача тих текстів сторонньому постачальнику моделі, зазвичай з іншої країни. І 3. Найкритичніший аспект, послухайте сюди. Запис у пам’ять браузера вже під час простого відкриття сторінки, ще до того, як людина натисне на кнопку. Єдине рішення? Зайти в код і заблокувати завантаження моделі, доки відвідувач не вирішить фактично натиснути кнопку старту розмови. Дійшли й до розділу 5, технічні та юридичні межі. Наскільки далеко йде інженерія і де треба дати професіоналам з legal робити свою роботу. Абсолютно ясно, що методологія в коді є життєво важливою, але не будемо себе обманювати, вона не вирішує абсолютно все сама по собі. Технічний інструмент займається відчутними речами. Він інвентаризує інфраструктуру, дивиться в код і виводить чіткі докази того, як поводиться система. Але, увага, він не є юридичною думкою.

Технічний інструмент не може визначати правові підстави в договорі й не тлумачить закони. Ця частина — виключна територія адвокатів. Коротко, технологія заливає надміцний бетонний фундамент із доказів, а юристи приходять і будують на ньому законність. Таке розмежування виводить на світло одну надзвичайну річ про відому статтю 30, Реєстр Діяльностей Обробки. Кажу вам секрет: живий реєстр, реально згенерований із коду, ніколи не виглядатиме бездоганно під час першого сканування. Ті рядки, позначені як неперевірені, які потребують людського, юридичного рішення, саме вони показують справжню прозорість організації. Будь-який реєстр, який із першого дня виглядає ідеальним, повним і без жодної відкритої помилки, майже в усіх випадках є дешевою ілюзією, простою заповненою за шаблоном фішкою, яка повністю ігнорує реальну складність софту. Тож, підсумовуючи все, про що я розповів, бачачи цю колосальну різницю між тим, що написано на папері, і тим, що насправді виконує машина, як у вас в організації виглядає процес перевірки?

Чи спирається відповідність на якісь запилені документи, загублені десь у підвалі сайту, чи на беззаперечні певності, витягнуті прямо з активного коду? Перейти до технічної перевірки — це не просто галочка на папері, щоб уникнути Закону 195/2024. Це найвища гарантія того, що ви справді дотримуєтеся прав людей на дані. Зміна перспективи, яка просто трансформує спосіб, у який ми думаємо про безпеку.

Що входить

Робота, за складовими

Інвентар складається з коду та з живого сервера, а не з анкети

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

Поведінкова перевірка: натискаємо кнопку відмови і слухаємо мережу

Наявність банера згоди нічого не доводить. Наш сканер знаходить банер, фактично натискає на елемент відмови і потім три секунди слухає мережевий трафік. Інструмент відстеження вважається порушенням лише якщо він уже передавав дані до будь-якої згоди і продовжує передавати після відмови, без сигналу відхиленої згоди. Сайт, який правильно реалізує відмову за замовчуванням, не карається за свої пінги без cookie — правило було додано явно, щоб не суперечити перевірці, яка винагороджує саме таку поведінку.

Реєстр діяльності з обробки, написаний як живий документ

Стаття 30 вимагає облік діяльності з обробки з цілями, категоріями осіб і даних, одержувачами, переданнями, строками видалення та описом заходів безпеки. Ми пишемо його рядок за рядком із перевіреного інвентарю, а те, що не вдалося перевірити, залишається позначеним як «неперевірено», а не заповненим із шаблону. Правило підтримки записується в документ: якщо зміна коду змінює, що збирається, кому надходить або як довго зберігається, реєстр і опублікована політика змінюються **в тому самому коміті**. Розбіжність між кодом і політикою — це саме та проблема, яка породжує документ.

Оцінка, яку можна відтворити, а не галочка

Сім категорій мають фіксовані ваги: cookie — 0,25, механізм згоди — 0,20, політика — 0,20, передання — 0,15, форми — 0,08, юрисдикція — 0,07, ідентичність оператора — 0,05 — сума точно 1,0, перевірена тестом. Провалена знахідка знижує бал у своїй категорії пропорційно до серйозності: критична 1,0, висока 0,6, середня 0,3, низька 0,15; попередження коштує половину. Понад 80 — відповідає вимогам, понад 50 — ризик, нижче — невідповідність. Усі числа зберігаються в одному файлі як єдине джерело правди, саме для того, щоб будь-хто міг відтворити розрахунок.

Жорстке правило для порушень, які відбуваються просто зараз

Одна-єдина критична провалена знахідка змушує винести вердикт «невідповідність» і обмежує бал 49, незалежно від того, що сказала б зважена формула. Причина проста: інструменти відстеження, які передають дані до згоди, або кнопка відмови, яка нічого не зупиняє, впливають на кожного відвідувача саме зараз. Ідеальна політика конфіденційності не має права піднімати середнє вище цього.

Зберігання як автоматичне завдання, що залишає слід, а не як обіцянка з політики

«Ми зберігаємо дані 24 місяці» — це твердження, яке перевіряється лише одним способом: запуском видалення. У нас журнал запитів на сайті має строк, прочитаний із конфігурації (`LEAD_RETENTION_DAYS`, за замовчуванням 730 днів) і очищується під час кожного запису. На більшій платформі очищення — це заплановане завдання, яке запускається **після** резервної копії і лише якщо вона вдалася — видалення без свіжої копії є єдиною формою видалення, з якої немає повернення — і записує рядок у таблицю виконань. Цей рядок є доказом відповідності, який вимагає art. 5 para. (2). До першого реального запуску завдання працює вхолосту щонайменше тиждень і читається журнал.

Передання: де зупиняється обов’язок і де починається

Ст. 44 п. (2) говорить, що весь розділ про передавання **не застосовується** до передавань до держав Європейського економічного простору, де не потрібні спеціальні дозволи. Це повністю змінює аналіз: розміщення в Європейському Союзі — не естетична перевага, а різниця між «нічого обґрунтовувати» і «досьє гарантій». Для решти ми перевіряємо конкретно: який постачальник що отримує, на якій підставі, і чи підходить заявлене відступлення. Приклад із нашого власного реєстру: сповіщення через Telegram є передаванням до третьої держави, і ми записали в реєстрі, що заявлене відступлення призначене для поодиноких передавань, тоді як наше є систематичним. Це визнане обмеження, з технічною альтернативою, записаною поруч.

Виявлення банера, яке не вдає, що бачить усе

Вісімнадцять відомих селекторів платформ згоди, кожен із цитованим джерелом, плюс евристика для банерів, написаних від руки — дуже поширених у малих компаніях Молдови — яка читає обчислені стилі з живої сторінки, а не зі статичного HTML. Обхід входить у відкритий shadow-DOM і в iframe, бо деякі банери живуть там повністю. Закриті shadow-root-и залишаються невидимими за конструкцією: ми прямо це зазначаємо і маємо тест, який утримує твердження на місці.

Стирання тверджень, які ми не можемо підтвердити

Найменш приємна і найкорисніша частина. Сторінка відповідності, що перелічує неіснуючі сертифікації, аудити та практики, є більшим ризиком, ніж коротка сторінка, бо кожен рядок стає перевірюваною заявою перед органом. Правило, яке ми застосовуємо: публічне твердження має один рядок у реєстрі доказів, із первинним документом — не з внутрішнім документом, який його повторює. Твердження без первинного документа прибираються, доки не з’явиться документ.

Як це виглядає

Шлях, крок за кроком.

Ми скануємо ззовні й читаємо зсередини, паралельно

Автоматичне сканування дає публічний стан за кілька секунд: передавання, cookies до згоди, реальна поведінка банера, елементи змісту політики, форми, юрисдикція, ідентичність оператора. Паралельно читається код. Ми передаємо звіт із висновками, доказами та посиланням на відповідну статтю Закону 195/2024 — і списком розбіжностей між тим, що каже опублікована політика, і тим, що робить система.

Ми пишемо реєстр і позначаємо те, що не вдалося перевірити

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

Ми виправляємо в коді те, що виправляється в коді

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

Ми передаємо досьє і процедуру, яка його підтримує в живому стані

Реєстр, процедура повідомлення про порушення, оцінка впливу там, де вона потрібна, список субпроцесорів із тим, що отримує кожен, і реєстр доказів для публічних тверджень. Плюс правило, яке тримає їх актуальними: політика і код змінюються разом. Те, що стосується юридичного тлумачення, передається юристу, з підготовленим технічним матеріалом.

Маршрут роботи з відповідності: сканування ззовні і читання коду паралельно, потім список розбіжностей між опублікованою політикою і реальною поведінкою, потім реєстр із тим, що перевірено і що лишилося відкритим, потім виправлення в коді — з повторним скануванням наприкінці, щоб різницю було виміряно, а не оголошено.

Дані

Чого торкаємося, де воно лежить і скільки лишається

Запитання, які ставить кожен, у кого є відповідальний за захист даних, — поставлені тут раніше, ніж їх поставить він.

Що фактично бачить автоматичне сканування: Лише публічну поверхню аналізованого сайту: заголовки відповіді, записані cookies, мережеві запити, які запускає сторінка, текст політики, поля форм, викликані сторонні домени. Воно не входить під обліковими даними, не заповнює форми реальними даними і не торкається зон, захищених паролем. Сканування публічного сайту — це саме те, що робить будь-який відвідувач, але з увімкненим годинником.
Як поводиться наш робот: Бюджет 45 секунд на сканування. Власний user-agent, який ідентифікується та веде на сторінку, що пояснює, що робить сканування і як відмовитися. `robots.txt` цільового сайту дотримується за замовчуванням, з окремим читанням, обмеженим 8 секундами, щоб повільний `robots.txt` не з’їдав бюджет аудиту. Перед будь-яким запитом охорона блокує внутрішні адреси, локальну мережу та метадані-пункт хмарної інфраструктури.
Що ми фактично зачіпаємо в роботі з відповідності на системі клієнта: Схема бази даних, конфігурація, код і журнали — не вміст персональних даних. Коли перевірка все ж вимагає реального прикладу (наприклад, що фактично потрапляє в сповіщення), це робиться на тестовому випадку, створеному для цього, а не на живому клієнті. Доступ надається на час роботи і відкликається наприкінці, а відкликання перевіряється.
Де зберігаються наші дані і чому це важливо: Цей сайт працює на OVHcloud, Бухарест, Румунія — Європейський економічний простір. Платформа асистентів працює на Microsoft Azure, Poland Central, підтверджено через запит до служби метаданих віртуальної машини, а не з документації постачальника. Журнали сервера ротаються щодня з 14 збереженими копіями, з обмеженими правами читання. Ці три рядки замінили набагато довший список локацій, який ми не змогли підтвердити.
Мінімізація, застосована і в нас: IP-адреса відвідувача не записується повністю: її обрізають перед зберіганням до мережевого префікса — /24 для IPv4, /48 для IPv6 — тому що опублікована політика каже, що IP-адреси анонімізуються, а твердження має бути правдивим у коді. Журнал запитів зберігається з правами 0600 у каталозі 0700. Точка перевірки стану форми повертає лише логічні значення, ніколи не токен, ідентифікатор чату чи назву бота.

Випадок

Що залишилося від сторінки з відповідності після того, як було запитано первинний документ для кожного рядка

Ситуація

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

Що ми збудували

Ми застосували одне правило: кожне публічне твердження отримує рядок у реєстрі доказів, з первинним документом — не з документом, що його повторює. Паралельно було перевірено реальну поведінку: які cookies записуються до прийняття, з очищеною пам’яттю браузера; що завантажує сторінка при відкритті; який строк збереження фактично є в коді; де розташовані сервери, шляхом запиту до служби метаданих машини, а не до документації постачальника.

Що вийшло

Відпали, серед іншого, щорічний незалежний тест на проникнення, 180-денний журнал аудиту, заявлене шифрування всіх баз даних, двофакторна автентифікація для всіх облікових записів адміністрування, щоденна резервна копія, зашифрована поза офісом, утричі більша за реальну кількість субпроцесорів і дві неіснуючі локації хостингу. Залишилися дві локації, обидві підтверджені в Європейському економічному просторі. Окремо було знайдено й виправлено реальну проблему, про яку ніхто не знав: чат-асистент завантажувався на кожному перегляді сторінки і записував сесію та історію в пам’ять браузера ще до того, як відвідувач щось попросить. Тепер він завантажується після натискання кнопки.

Чого цей випадок не каже

Отриманий реєстр не є чистим і не повинен таким бути: у ньому є вісім відкритих пунктів, позначених назвою ролі, яка має ухвалити рішення, і явно визнане обмеження про систематичний перенос, покритий винятком, задуманий для випадкових переносів. Реєстр без відкритих пунктів, написаний з першого проходу, майже завжди є реєстром, заповненим за шаблоном. Цінність документа — у рядках, що кажуть «неперевірено».

Питання

Про що нас питають, перш ніж зателефонувати

Ви надаєте юридичну консультацію?

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

З якої дати застосовується закон і який конкретний ризик існує?

Закон № 195/2024 набрав чинності 23 серпня 2026. Штрафи мають два пороги, і текст каже, що береться більше значення між сумою та відсотком: до 1.000.000 леїв або 1% від загального обороту за попередній рік для обов’язків оператора та уповноваженої особи; до 2.000.000 леїв або 2% для основних принципів обробки та умов згоди, для прав суб’єктів даних і для передавання до інших держав. Згода і права осіб у верхньому діапазоні — тому банер, який не працює, має більшу вагу, ніж здається.

Ми хостимося в Європейському Союзі. Чи маємо ще обов’язки щодо передачі?

Для передавань до держав із Європейського економічного простору — ні. Ст. 44 п. (2) прямо каже, що весь розділ про передавання не застосовується до цих передавань і що спеціальні дозволи не потрібні. Це робить вибір хостингу рішенням щодо відповідності, а не лише щодо затримки. Однак обов’язки залишаються для будь-якого постачальника з-за меж ЄЕП — включно з невеликими сервісами, які ніхто не вносить у список: сповіщення через месенджер, статистика трафіку, сервіс транзакційної пошти.

Чи потрібно нам призначати відповідального з захисту даних?

Закон вимагає цього в трьох випадках: орган або публічна установа; основні види діяльності, що передбачають регулярний і систематичний моніторинг суб’єктів даних у великих масштабах; або обробка у великих масштабах спеціальних категорій даних чи даних про кримінальні вироки. Якщо ви не підпадаєте, призначення залишається опційним — але будьте уважні до пастки, яку ми знайшли навіть у нас: якщо ви публічно заявляєте про призначеного відповідального, виникає обов’язок повідомлення, що супроводжує призначення. Опублікована позиція та внутрішня оцінка не мають права суперечити одна одній. Чи підпадаєте ви під це чи ні — це юридичне питання; ми його сигналізуємо, а не вирішуємо.

Скільки часу я маю, якщо трапляється витік?

Повідомлення до Центру подається без невиправданих затримок і, якщо можливо, не пізніше ніж протягом 72 годин від моменту, коли стало відомо; після цього строку повідомлення має супроводжуватися вмотивованим поясненням затримки. Уповноважена особа повідомляє оператора без невиправданих затримок. Складна частина не строк, а те, що має містити повідомлення: характер порушення, категорії та приблизна кількість осіб і записів, яких це стосується. Без правильного обліку того, які дані де знаходяться, 72 години витрачаються на пошук. Саме тому реєстр пишуть до інциденту.

Чи ускладнює ситуацію AI-асистент, який спілкується з клієнтами?

Так, у трьох конкретних пунктах. Перший: розмова містить те, що пише клієнт, а клієнти пишуть будь-що, включно з чутливими даними, яких ви ніколи не запитували — це вимагає явної інструкції для персоналу та строку зберігання. Другий: асистент надсилає текст до постачальника моделі, тож з’являється субпроцесор і, як правило, передача. Третій, найчастіше про нього забувають: компонент часто завантажується під час відкриття сторінки і записує в пам’ять браузера ще до того, як відвідувач щось попросив. Саме це ми виявили на власному сайті й виправили, завантажуючи лише після натискання кнопки.

Чи означає оцінка 100, що з юридичного погляду все гаразд?

Ні. Оцінка вимірює те, що можна автоматично виміряти з публічної поверхні: транспорт, cookie, поведінку банера, елементи змісту політики, форми, юрисдикцію, ідентичність оператора. Вона не бачить реальної правової підстави обробок у бекенді, договорів із субпроцесорами, обліку згод у базі даних, фактичного строку зберігання або того, як ви відповідаєте на запит про доступ. Хороша оцінка означає, що поверхня чиста. Решту перевіряють зсередини, а тлумачення залишається юридичним.

Чи можете ви просканувати наш сайт, не зламавши нічого?

Сканування — це візит, а не тест на проникнення: завантажується публічна сторінка, натискається контроль відмови в банері й слухається трафік, із загальним бюджетом 45 секунд. Робот ідентифікується власним user-agent і за замовчуванням дотримується `robots.txt` сайту. Він не авторизується, не заповнює форми реальними даними, не торкається захищених зон. Якщо ви не хочете, щоб вас сканували, блокування через `robots.txt` працює і дотримується.

Чому ви прибрали заяви зі своєї власної сторінки щодо відповідності замість того, щоб додати?

Тому що кожна публічна заява є перевірюваною декларацією. Наша сторінка перелічувала щорічний незалежний тест на проникнення, журнал аудиту на 180 днів, шифрування на всіх базах, двофакторну автентифікацію на всіх облікових записах адміністрування, щоденні зашифровані резервні копії поза офісом, чотирнадцять субпроцесорів і кілька локацій хостингу. Жодну не вдалося підтвердити первинним документом. Ми їх прибрали і залишили те, що можна показати. Короткий і правдивий dossier витримує перевірку; довгий і декоративний — ні.

На чому ґрунтуються твердження вище (25 джерел)

ongdpr.md відповідає 308 на /ro, потім 200 і 95 131 байтhttps://ongdpr.md · 2026-09-06

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

Як ми працюємо Усі послуги

Що вам хотілося б налагодити?

Розкажіть про свій процес. Разом визначимо, що варто збудувати, що можна підключити і як перевіримо результат.

Поговорімо