GDPR у skills та rules для AI-агентів (та асистентів розробки)

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

GitHub Copilot, Claude Code, Cursor: усі вони сьогодні пишуть код, який щодня торкається персональних даних. Це моделі користувачів, логування, API-ендпоінти, retention-джоби, ML-пайплайни (і багато-багато інших елементів систем).

Тому питання вже не «чи варто вчити мого AI-асистента вимогам GDPR», а «як саме це технічно зробити»; і багато хто зараз робить це через skills і rules.

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

Rules of Engagement: що таке Skill (Claude) і rule (Copilot/Cursor) і коротко про їхню механіку

Обидва механізми вирішують одну задачу: дати AI-асистенту стійкий контекст, який не залежить від пам’яті конкретної розмови.

Skill (походить від Anthropic, Claude) — це папка з файлом SKILL.md (метадані: назва + опис) плюс опціональні references/, scripts/, assets/. Ключова ідея лежить у поступовому зборі контексту:

• спочатку модель бачить лише коротку назву й опис (щоб знати, чи скіл релевантний для поточної задачі), і
• лише коли задача справді підпадає під опис, підвантажує повний вміст SKILL.md (і інші довідкові файли, якщо є потреба).

Це організовані папки з інструкціями, скриптами та ресурсами, які агенти можуть виявляти й динамічно завантажувати для кращої роботи над конкретними задачами. Формат наразі вже став відкритим стандартом (Agent Skills), тож той самий SKILL.md сьогодні читають і Claude Code, і низка інших агентських CLI.

Rule / custom instructions (Copilot, Cursor та інші) працює дещо простіше: зазвичай це файл або набір файлів, які додаються в контекст автоматично, без тригера-опису. Наприклад, у GitHub Copilot це

• .github/copilot-instructions.md (завантажується завжди, для всього репозиторію) плюс
• модульні .github/instructions/*.instructions.md, кожен з яких має поле applyTo з glob-патерном (тобто правило діє лише для файлів, що підпадають під конкретний шлях, як applyTo-патерни: applyTo: ’/src/api/’ дозволяє обмежувати правило до піддиректорії).

Cursor має власний .cursor/rules/*.mdc з аналогічними globs і прапорцем alwaysApply.

Є й крос-інструментальні формати: наприклад, AGENTS.md, який намагаються підтримувати одразу кілька агентів інших виробників.

GDPR може вкладатися у формі обох. Важливо тільки правильно це зробити: GDPR потрібен не завжди і не всюди, та й може інколи мати доволі непередбачуване застосування.

Чому ми взагалі говоримо про GDPR як частину контексту

Бо GDPR складний і не має вичерпного переліку вимог. Це реалізується через широко сформульовані статті 5 (принципи), 25 (data protection by design / by default), 32 (безпека обробки даних), 46 (безпека передачі даних), і можуть непрямо висновуватися з інших (наприклад, статей 12-22 про права субʼєктів даних, або статтю 6 про згоду на збір і обробку даних).

У традиційній розробці GDPR починався ще з бізнес-аналізу («на якому ринку працюватиме ця система? хто буде її користувачами?») та архітекторського моделювання (закладання функціоналу під зміну та видалення даних, планування lineage / provenance, визначення рівня якості даних тощо) до тестування та підтримки. Зазвичай це виглядало як «add deletion pipeline because gdpr». У ще традиційнішій розробці GDPR взагалі ігнорувався і додавався уже як окремі фікси за бюджет (і ресурси) безпеки та лігалу; виправдовувалось це як браком обізнаності більшості розробників про юридичні тонкощі визначення персональних даних, так і відсутністю конкретних вимог від замовника.

Зараз стало складніше: один розробник уже може працювати над більшою частиною системи, ніж йому традиційно відводилось, і має думати про вплив своєї роботи на всю систему. GDPR і є якраз екстерналією цього віялового впливу на систему: якщо джоба не бачить певної таблички в базі, то система не в комплаєнсі з, скажімо, статтею 15 (бо ми не можемо дати клієнту копію всіх його даних, як того вимагає закон) або 17 (бо не видалимо щось з його даних, що повинні були б), і статтею 25 (бо система тоді не data protected by design).

Є і чисто AI-agentic-зумовлені особливості комплаєнсу з GDPR.

• AI-асистент генерує рішення про персональні дані десятки разів на день: як назвати поля в схемі, чи логувати email, чи ставити retention на таблицю (і який, якщо так). За замовчуванням агент, якого підняли без консультацій з DPO чи лігалом, не знає ні правової підстави обробки, ні внутрішньої політики retention компанії, притаманних для конкретної системи чи процесу. Без явного правила модель або мовчки ігнорує це питання, або вгадує, і обидва варіанти небезпечні, бо агент не має уявлення про ризик-апетит компанії щодо комплаєнсу і часто не має інформації про обіцянки, які даються клієнтам у DPA.
• Помилка на рівні коду масштабується. Якщо AI один раз запропонував логувати повне тіло запиту з імейлом користувача, то команда це прийме як патерн і наступні 50 ендпоінтів повторять ту саму помилку, бо асистент буде «вчитись» на існуючому коді репозиторію.
• Shift-left буде дешевшим рішенням, ніж рефакторинг всієї системи. Виправити відсутність RetentionExpiresAt на етапі дизайну схеми коштує рядок коду; виправити це постфактум на проді, коли дані вже накопичились без юридичної підстави, в рази складніше (і дорожче). Для DPO компанії це багато роботи до поточного навантаження: оцінка ризику, потенційне DSAR-навантаження (бо і скарги на порушення GDPR пишуть вже теж агенти), і розмова з наглядовим органом.

Тому у команд є кілька шляхів:

• перетворення норм GDPR (і не тільки) на квазітехнічне правило: написання і погодження на рівні окремих команд системних промптів, guardrails, чи і взагалі policy-as-code під AI Act, GDPR і галузеві вимоги, вимоги контрактів з клієнтами, фреймворків та сертифікацій та інших вимог; і водночас
• рамка, у якій інженери самі безпечно пишуть промпти й правила з чіткими межами того, що заборонено, що вимагає юридичного ревʼю та як документувати відповідність.

Як GDPR може виглядати у системі скілів і системних промптів

Доволі інтуїтивно, але головна практична ідея тут — не один величезний файл «GDPR для всіх випадків і команд», а сегментація за процесом/доменом, як і будь-яка інша інженерна модуляризація.

Є сенс подивитися, чи підійде командам на проєкті така розбивка, наприклад:

Окремо варто винести AI/ML-шар, бо GDPR і AI Act тут переплітаються: та сама high-risk обробка часто вимагає й DPIA, і FRIA одночасно, тоюто потребує і правової підстави, і управління AI-ризиком. Це означає, що skill для ML-пайплайну повинен містити не лише GDPR-правила (мінімізація, анонімізація), а й AI Act-тригери (коли зупинитись і покликати людину, щоб остання приймала якісь юридично важливі рішення).

Які патерни включення GDPR у skills/rules вже є на GitHub

Готовий інженерний GDPR-скіл у офіційному репозиторії github/awesome-copilot. Скіл gdpr-compliant побудований саме як «перекладач закону в правило»: він орієнтований на розробників, архітекторів, DevOps та техлідів і використовує наробітки CNIL для розробників і статтями 5, 25, 32, 33, 35 GDPR. Структурно це MUST / MUST NOT списки й таблиці за темами: принципи ст. 5, privacy by design, мінімізацію даних, обмеження мети, retention-дефолти (наприклад, окремі рядки для auth-логів, сесійних токенів, платіжних записів, і щоб кожен зі своїм терміном був), правила API-дизайну, правила логування, хешування паролів, керування секретами, різниця анонімізації й псевдонімізації, робота з тестовими даними. Завершується він таблицею антипатернів і чеклистом для PR-ревʼю. Довші деталі винесені в окремі references/-файли (data-rights, security, operations), щоб за потреби агент міг туди занурюватися.

Спеціалізовані бази privacy-скілів. Є проєкти, що йдуть далі одного файлу й будують структуровану базу: структурована, машинозчитувана база privacy-скілів для AI-агентів із 280+ процедурами комплаєнсу, що покривають GDPR, CCPA, EU AI Act, HIPAA, LGPD, PIPL та індійський DPDP Act, за відкритим стандартом agentskills.io, сумісна з Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI та понад 26 іншими платформами. Це показовий сигнал сам у собі: команди, що хочуть працювати на глобальний ринок, рухаються до мультиюрисдикційних, а не лише GDPR-специфічних наборів правил.

Фрагментація форматів і спроби її зняти. Оскільки кожен інструмент має свій формат (.github/copilot-instructions.md, .cursor/rules/*.mdc, CLAUDE.md, AGENTS.md), з’явились конвертери, що синхронізують одні й ті самі правила між форматами, аби команда, що працює одночасно в Copilot і Claude Code, не писала GDPR-правила двічі.

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

Звідси можна виснувати і типові помилки при написанні таких skills/rules для своїх систем:

• Копіпаст готового публічного GDPR-скіла без адаптації під реальний RoPA компанії. Наприклад, дефолтні retention-таблиці: це орієнтир, а не факт про вашу компанію. Ваші строки зберігання даних будуть залежати від ресурсів (скільки грошей є на зберігання даних і операції з ними), контрактів (наприклад, якщо клієнт з вами тільки на певний проміжок часу або має право у будь-який час вимагати видалення якихось даних), або від закону (наприклад, якщо софт вимагає СОРМ). Якщо ваш DPO визначив один строк для конкретної категорії даних, а скіл каже інше (бо, наприклад, відштовується від строку позовної давності у країні, який найчастіше зустрічається в інтернеті), то асистент буде генерувати порушення за замовчуванням.
• Підміна юридичної оцінки технічним правилом. Keyword-based MUST/MUST NOT добре ловить очевидне (пароль у логах), але не ловить контекстуальні юридичні питання: чи є законна підстава, чи сумісна вторинна мета обробки з первинною, чи буде це достатнім мітігейшеном ризиків з DPIA тощо. Це не гіпотетична проблема: потрібні дуже вивірені guardrails, бо юридичний ризик є контекстуальним, доменно-специфічним і часто невидимим на рівні окремого слова чи фрази. Відповідь чатбота користувачеві без жодного забороненого слова все ще може створювати відповідальність для компанії.
• Один величезний файл «на все» замість точкових правил і принципів: наприклад, правило для інфраструктури може намагатися одночасно регулювати і Terraform, і фронтенд-форми, через що агент або ігнорує частину системи, або застосовує правило не туди, куди було б потрібно. Виходить салат з овочей, батогів і пряників: половина салату буде не в мисці, а інша половина нарізана або занадто дрібно, або занадто великими шматками (тобто подекуди система отримуватиме неоптимальні рішення: пропущену регуляцію в місцях, де вона була б потрібна, або дуже детальні правила там, де можна було б вирішити вручну силами сапорту за потреби).
• Відсутність власника й версійності. GDPR-скіл, написаний дуже натхненним учасником команди, мігрує з проєкту в проєкт, не оновлюється, коли змінюється позиція регуляторного органу чи EDPB чи еволюціонує власна архітектура компанії (наприклад, з’явилось нове сховище персональних даних поза RoPA). Окремоб проблемою стане і намагання автоматизувати версійність скіла: якщо він оновлюється самостійно агентом без критичної вичитки людиною, бо зʼявився якийсь новий опініон регуляторного органу або структура в системі, то можна створити собі правила, які створюють для команії додаткові юридичні обовʼязки в обхід юридичного відділу і менеджменту (переклав всі ціни у валюті країн ЄС та локалізував всі сайти всіх продуктів = попав під GDPR у тій частині бізнесу, яка мала б бути лише на США; додатковий комплаєнс, хоча менеджмент і лігали не планували цього і не закладали ризики штрафів у ризик-апетити компанії).
• Конфліктні правила між різними інструментами однієї команди (або кількох команд). Copilot-інструкція каже одне, Claude-скіл каже трохи інше, бо їх писали різні люди в різний час без єдиного джерела правди; сама система писалась під конкретний ринок, але десь сталась автоматизація скіла даними з дикого інтернету і юридичними оцінками реддіторів. У результаті отримуємо повний форт буаяр між сабагентами замість логічної системи комплаєнсу.
• Немає стоп-слова. Хороший скіл повинен вміти сказати «це потребує DPIA / юридичного ревʼю», а не намагатись «самосертифікувати» відповідність AI-генерованого рішення, вигадуючи якісь міфічні позиції регуляторних органів (які давно скасовані або замінені іншими законами чи позиціями). Або ж агент матиме велику спокусу викрутитись і вигадати якесь неоптимальне рішення у коді чи інфраструктурі, аби тільки не кликати людину розбиратися з трейд-оффом або не створювати «некомплаєнтне» рішення.

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

Хороші практики для GDPR-aware skills і автоматизації комплаєнсу

Але досить про погане. Давайте трішки і про хороше: якщо вже критикувати, то треба приносити і пропозиції, вірно?

Можемо почати з наступного:

• Пишіть як таску для людини без бажання працювати, а не юридичною прозою з закону. Кожен пункт закону — це, в ідеалі, окреме, перевірюване MUST/SHOULD правило з конкретним технічним наслідком: не «дані повинні зберігатись не довше необхідного», а «кожна таблиця з персональними даними має поле RetentionExpiresAt, обчислене при вставці; інформація береться з (посилання на таблицю в RoPA або на спеціальний документ з строками ретеншена саме для цих даних)».
• Сегментуйте за процесом і лімітуйте правила (знов applyTo/globs, але вже востаннє на цей текст): краще, щоб розробка, тестування, інфраструктура, AI/ML мали свої окремі скіли (а то і не один). Попрацюйте тут з вашим data protection officer: нехай допоможе кастомізувати законодавство під конкретні системи та пріоритетні архітектурні вимоги.
• Використовуйте поступове розкриття контексту: зробіть короткий SKILL.md з «золотим правилом» і посиланнями на references/ для глибоких тем (DSAR-флоу, шифрування, incident response). Не перевантажуйте контекст системи процесами, які для неї неактуальні: агенту розробки варто знати, що система логування потрапить під вимоги GDPR робити копії чи видаляти дані при зверненні субʼєкта даних, але він не повинен сліпо виконувати видалення чи копіювати дані інших людей (наприклад, дії суперадмінів з налаштування таблиць логування, але не взаємодії з даними конкретного користувача). Ідея логування ж у тому, що вони мають бути повними, чи не так? То чи буде лог мати якусь цінність, якщо дані звідти можна так просто видалити? Не давайте агенту бити молотком там, де треба натиснути тонкою голкою (або голками забивати цвяхи).
• Один source of truth, синхронізований у формати кожної з команд: якщо частина команди на Copilot, частина на Claude Code, то набори правил доведеться, скоріш за все, тримати в одному місці й генерувати похідні файли на вимогу, а не редагувати кожен окремо. Памʼятайте про нестримне бажання колег автоматизувати вже автоматизоване (самооновлення скілів агентами з лінивого піддакування людини) і форт буаяр агентів, які не можуть узгодити таску і комплаєнс.
• Вбудовуйте «стоп-крани» й ескалацію. Правило повинно вміти сказати «зупинись і запитай DPO/юриста», коли йдеться про (в залежності від контексту системи, звісно) спеціальні категорії даних, масовий профайлінг, потребу в новому використанні раніше зібраних даних чи нову third-party інтеграцію. У компанії навряд чи настільки багато грошей, щоб виконувати всі вимоги всіх законів (або заплатити компенсації всім постраждалим), якщо вона почне заради незначного покращення функціоналу почне комплаїтися з зайвим для неї законодавством (наприклад, з правилами AI Act у частині high-risk AI-систем заради надійнішої авторизації на сайті замовлення канцелярії в офіс).
• Тестуйте скіли та правила теж! Регулярно прокручуйте свої скіли з комплаєнсу на набір атак (jailbreak, prompt injection, обхід guardrails тощо) і тримайте під рукою playbook, який команда прогонює на власній системі, щоб виявити розриви в комплаєнсі. Тобто скіл потрібно валідувати так само, як і будь-який інший продукт. Комплаєнс — життєво важлива функція для життя компанії, тож і ставитися до нього треба відповідно.
• Призначайте скілам власника й цикл ревʼю, залучайте DPO та юристів. Можете сформувати навіть комітет або пошукати інженера-юриста, який міг би бути присутнім в архітектурних рішеннях команди як зовнішній privacy-архітектор для ревʼю нових фіч і скілів та брав участь у дизайн-сесіях.
• Прив’язуйте правила до реального RoPA/DPIA-реєстру компанії, а не до шаблонів з інтернету. Але при цьому подбайте, щоб DPO або юристи мали актуальну інформацію в цих документах: пройдіть по своїй системі, зробіть для них окремого агента з доступами, який міг би підтвердити, що інформація в RoPA не застаріла.

Замість епілогу: підводні камені і думки на подумати

Камінчик перший. Skill/rule — це все-таки частіше за все контекст, а не контроль. Модель може «забути» інструкцію в довгій розмові чи великому діффі, у той час як реальний контроль вимагає й CI/CD-перевірки на рівні пайплайну («лінтер для комплаєнсу»). Не сприймайте скіл як guardrail, це може дорого обійтися.

Мультиюрисдикційність як окремий гострий камінчик. Продукт із користувачами в ЄС, США й Ізраїлі не може обійтись одним GDPR-скілом. У вас в юридичному зоопарку додається CCPA, різні AI Act-режими й локальні закони про захист даних, які вимагають різних, іноді конфліктних правил. Деякі правила будуть ховатися у законі про конкуренцію, банкрутство, контракти чи навіть податки. Правило «комплаєнс з найсуворішим законом, щоб покрити всі» інтуїтивно спокусливе, але практично помилкове.

Памʼятайте, що сам агент теж повинен бути в комплаєнсі. Логи промптів, історія чату, кеш AI-асистента можуть самі містити персональні дані користувачів, і на цей шар поширюються ті самі обов’язки, що AI-асистент допомагає впроваджувати для продукту. Забули — вважайте, що на камінчику підскользнулись і впали в регуляторне болото, і добре, якщо не по саму шию.

До речі, остерігайтесь затхлих водойм. Гайденси регуляторів, підзаконні акти і власна архітектура компанії змінюються швидше, ніж більшість команд оновлює свої rules/skills-файли. Без явного власника й ревʼю-циклу файл, написаний рік тому, тихо стає джерелом дезінформації для AI.

Повернемось до питання відповідальності утопаючих. Навіть ідеально написаний скіл не знімає принцип accountability (ст. 5(2) GDPR) з компанії, бо AI не може бути «відповідальною особою». Фінальне рішення про DPIA, законну підставу чи adequacy transfer-механізму залишається за компанією, якщо ви в ЄС, або і конкретною посадовою особою (якщо ви ненароком потрапили під NIS2, бо не слідкували за своїми агентами).

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