Більшість розмов про захист даних у контексті керування AI починаються не з того місця. Вони запитують, які сертифікати має постачальник, яких субобробників він перелічує, у якому регіоні розташована його хмара. Це справжні запитання. Але для конкретної категорії інструментів, які спостерігають за вашими AI-агентами — виявляють кожного агента, кожну сесію, кожну модель та MCP-сервер у вашій інфраструктурі й картографують, до чого може дістатися кожен із них — під сподом ховається фундаментальніше запитання: чи отримує сам інструмент керування ваші дані взагалі коли-небудь?
Якщо відповідь «так», ви щойно створили нового обробника, нову копію чутливого матеріалу, нове місце, яке можна зламати, проти якого можна видати судову повістку або яке можна змусити «дзвонити додому». Якщо відповідь «ні» — структурно, за задумом — то більшість похідних запитань щодо GDPR стають значно меншими. Саме в цьому полягає аргумент на користь self-hosting AI-платформи, і його варто сформулювати точно, без перебільшень.
Гарантія приватності, що насправді має значення, — структурна, а не сертифікат
Звіт SOC 2 чи сертифікат ISO 27001 повідомляють вам, що постачальник має процеси навколо даних, які він зберігає. Це корисно, але це твердження про керування доступом до ваших даних. Значно сильніша гарантія — взагалі не зберігати ці дані. Ви не можете злити, неправильно обробити чи бути зобов’язаним розкрити те, чого ніколи не отримували.
Self-hosting дає саме це. Коли площина керування працює всередині ваших власних хостів, кластерів чи хмар — зокрема повністю air-gapped, без вихідного трафіку — чутливий матеріал, який вона спостерігає, ніколи не перетинає ваш периметр. Постачальник не є субобробником ваших операційних даних, бо постачальник їх ніколи не бачить. Це архітектурний факт, а не обіцянка з політики, яку вам доведеться перевіряти аудитом.
Щоб було зрозуміло, на якому етапі перебуває продукт: Olivares AI ще не випущений. Він не сертифікований за SOC 2, ISO/IEC 27001, EU AI Act чи будь-якою іншою системою, і жодного аудиту не триває. Продукт спроєктований у напрямку контрольних цілей, які перевіряють ці системи — журналювання аудиту, контроль доступу, цілісність, шифрування, керування змінами — тож він готовий до аудиту, коли настане час. Аргумент щодо резидентності нижче не залежить від жодної сертифікації, і саме в цьому суть.
Зв’язки, а не корисне навантаження
Ключове проєктне рішення — це те, що саме зберігається. Інструмент керування AI має розуміти, хто до чого може дістатися. Йому не потрібні ані вміст запитів, ані тіла промптів, ані секрети чи персональні дані, що проходять через ці звернення.
Тож граф зберігає зв’язки, а не корисне навантаження: відношення доступу між агентом і ресурсом та чи є цей доступ читанням (R) або читанням/записом (RW). data-export-job → prod-postgres (RW) — це зв’язок. Рядки, які прочитала ця задача, не зберігаються. Карта фіксує, що агент дістався об’єкта в s3://billing-exports; вона не копіює сам експорт.
| Зберігається (карта доступу) | Не зберігається |
|---|---|
| Ідентичність агента (роль / назва застосунку) | Значення облікових даних, токени, ключі |
Ресурс, до якого звернулися (prod-postgres) | Тіла запитів, рядки результатів |
| Тип доступу — R або RW | Корисне навантаження промптів і відповідей |
| Позначка часу, результат, рівень впевненості | Секрети, PII у передачі |
Вхідні дані, які можуть нести секрети чи персональні дані, редагуються й проходять сканування на секрети перед тим, як щось буде записано, тож редагування відбувається на межі збору, а не як пізніше прибирання. Те, що ви не зберігаєте, ви не можете злити — а те, що ви не можете злити, не розширює вашого периметра обробки згідно з GDPR.
Як дані залишаються всередині периметра
Три властивості тримають це чесним в експлуатації:
Спостереження за принципом read-first. Колектор спостерігає через сигнали, які ви вже й так виробляєте — журнали застосунків та аудиту, OpenTelemetry і eBPF як резервне джерело істини на рівні ядра. Він не є проксі в шляху даних агента, тож бачить форму доступу, а не вміст, і якщо він відмовляє, то ніколи не ламає продакшн. Немає обов’язкового «посередника», який копіює ваш трафік.
Жодної телеметрії «додому». Принцип secure-by-default означає відсутність «дзвінків додому». Телеметрія постачальника вимкнена, доки ви явно її не увімкнете. Нічого про ваше середовище — ані назви агентів, ані карта доступу, ані лічильники використання — не надсилається назад постачальнику за замовчуванням.
Air-gapped з нульовим вихідним трафіком. У відключених, регульованих чи засекречених мережах площина керування працює повністю локально, з офлайн-перевіркою ліцензування. Шляху назовні немає, крапка. Для вимоги резидентності даних, яка каже, що дані ЄС мають залишатися на інфраструктурі ЄС під вашим контролем, air-gapped self-hosted-розгортання — це найбуквальніша можлива відповідь: дані не рухаються, бо їм нікуди рухатися.
Зберігання та очищення налаштовуються, тож ви контролюєте, як довго зберігається навіть карта доступу.
Відповідність статті 28 GDPR — чесно
Стаття 28 GDPR регулює відносини контролер–обробник і те, що має охоплювати угода про обробку даних. Доречне спостереження полягає в тому, що в self-hosted-розгортанні звичайне відношення «постачальник як обробник» ваших операційних даних здебільшого розчиняється: оскільки інструмент працює у вашій інфраструктурі й ніколи не отримує цих даних, у більшості розгортань ви залишаєтеся контролером і обробником власних даних у власному середовищі.
Це не робить угоду про обробку даних безглуздою. Комерційні відносини все одно виграють від формалізації обов’язків — щодо ланцюга постачання програмного забезпечення, щодо доступу до підтримки, щодо будь-якого майбутнього керованого компонента. Угода про обробку даних згідно зі статтею 28 доступна на запит для корпоративних закупівель. Змінюється обсяг: немає переліку місць, куди було відправлено ваші персональні дані, бо їх ніколи не відправляли. Це значно коротша й значно легша для захисту розмова з DPO або відділом закупівель, ніж «довіртеся нашому переліку субобробників».
Це структурний аргумент, тож ставтеся до його меж із тією самою чесністю. Self-hosting перекладає відповідальність за резидентність та обробку на вас; він її не усуває. Ви все одно захищаєте хост, контролюєте зберігання й керуєте тим, хто може читати карту доступу — а ця карта сама по собі чутлива, і саме тому кожен привілейований перегляд її проходить аудит, а компоненти автентифікуються один перед одним за допомогою mutual TLS. Продукт зводить поверхню постачальника майже до нуля; він не звільняє оператора від відповідальності.
Висновок
Якщо регулятор, DPO чи ваша власна служба безпеки запитає «куди йдуть наші дані, коли ми впроваджуємо цей інструмент керування AI», найсильніша можлива відповідь — «нікуди — вони ніколи не залишають периметр, і інструмент їх ніколи не бачить». Ця відповідь випливає з архітектури: self-hosted-виконання, зберігання за принципом «зв’язки, а не корисне навантаження», редагування перед записом, відсутність телеметрії «додому» та air-gapped-робота з нульовим вихідним трафіком. Сертифікат може підтвердити гарні процеси; він не може зрівнятися з гарантією даних, які так і не були отримані.
Якщо ви хочете повну, чесну версію цієї позиції — зокрема ще-не-сертифікований стан відповідності та те, як сюди вписується угода про обробку даних згідно зі статтею 28 GDPR — перегляньте /security. Якщо ви радше прочитали б код, який підкріплює це твердження, повний продукт можна розгорнути локально під ліцензією AGPL-3.0 на сторінці /open-source.