Принцип «Не нашкодь» починається з того, де ви зберігаєте дані

У червні 2025 року старшого директора Microsoft France під присягою запитали у Сенаті Франції, чи може він гарантувати, що французькі державні дані, які зберігаються у французьких дата-центрах Microsoft, ніколи не будуть передані органам влади США. Він не зміг цього гарантувати. Він пояснив, що Microsoft оскаржує такі запити, коли це можливо, і публікує відповідну статистику. Але гарантії не існує.

Стенограма є загальнодоступною.

Того дня розвіялася зручна ілюзія. Багато з нас діяли, спираючись на оптимістичне припущення, що резидентність даних є достатньою — що якщо сервери розташовані у Франкфурті чи Парижі, то наші бенефіціари захищені, а наші операції є безпечними. І Microsoft, і Google пропонують хостинг в ЄС і серйозно ставляться до відповідності GDPR. Це дійсно так.

Це не є критикою саме американських сервісів. Я сам користуюся кількома з них, і деякі є чудовими. Але ми працюємо в секторі, де діє першочерговий принцип — «Не нашкодь». У 2026 році дотримання принципу «Не нашкодь» починається з того, де ви зберігаєте дані.

Два ризики, а не один

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

Постачальники послуг зі США зобов'язані дотримуватися вимог Управління з контролю за іноземними активами (OFAC), і це дуже реальне занепокоєння. У серпні 2026 року лідери ЄС були змушені публічно висловити підтримку Міжнародному кримінальному суду після чергового раунду санкцій США. Мандатований міжнародний орган зіткнувся з ризиком втрати доступу до сервісів через рішення, ухвалене в зовсім іншій юрисдикції.

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

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

Отже, що насправді знаходиться у вашій хмарі?

Почніть звідси, перш ніж обговорювати постачальників або міграцію.

Запитайте себе чесно: що там знаходиться? Не те, що згідно з політикою має там бути. А те, що там є насправді.

З мого досвіду відповідь завжди одна й та сама і завжди гірша, ніж очікувалося. Списки бенефіціарів у Excel на SharePoint. Примітки до кейсів у документах Word на OneDrive. Інформація щодо захисту в ланцюжках електронної пошти. Реєстраційні дані в папці, яку хтось створив для реагування у 2019 році і ніколи не закрив.

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

Роками нам це сходило з рук, тому що ніхто не міг одночасно здійснити пошук по всьому масиву даних.

Цьому прийшов кінець.

Copilot не створив проблему, але зробив її видимою.

Copilot і Gemini показують усе, до чого має доступ особа, яка ставить запитання. Не те, про що вона знала, що може бачити. А те, що вона може бачити.

Більшість орендарів (тенантів) НУО мають десятиліття хаотичного розростання дозволів. Сайти, якими ділилися з «усіма в організації» під час сплеску активності. Папки, успадковані від закритого проєкту. Файли, які технічно можуть читати триста людей, але які практично поховані там, де ніхто б їх ніколи не шукав.

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

І ця функція з'явилася через примітки до випуску, а не в результаті рішення про закупівлю. Ніхто цього не обиравав. Вона просто з'явилася.

Перш ніж увімкнути будь-якого AI-асистента у вашому орендарі, проведіть аудит дозволів. Це дешево, займає дні, а не місяці, і є цінним незалежно від того, чи увімкнете ви коли-небудь AI, — адже вразливість вже існує. Copilot лише підсвітив її.

Ярлик, який не працює

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

Я розумію цей інстинкт. Але це все одно неправильно з трьох причин.

Анонімізація дає збій. Повторна ідентифікація за сукупністю атрибутів є добре відомим явищем, і з кожним роком це стає легше. Місцезнаходження, вікова група, склад домогосподарства, дата отримання допомоги — поєднайте достатню кількість слабких ідентифікаторів у невеликій вибірці кейсів, і ви отримаєте ім'я. Якщо ваш «анонімізований» набір даних витікне або Copilot виявить його, ви не уникнете відповідальності.

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

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

Відповідь полягає не в тому, щоб зберігати менше. А в тому, щоб зберігати це належним чином.

Надзвичайні бази даних для надзвичайних випадків

Ця проблема вже вирішена, і вирішена нашим власним сектором.

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

У мене є робочі демо-версії, якщо ви хочете побачити їх, а не лише прочитати про них: dhis2.baena.info та femr.baena.info.

Суть не в цих конкретних інструментах. Суть у тому, що спеціалізовані рішення кращі за універсальні, і що наш сектор вже має спеціалізовані варіанти, якими ми регулярно нехтуємо на користь папки в SharePoint лише тому, що вона вже там була.

Дві пастки на виході

Пастка перша: адаптація комерційної ERP-системи. Я бачив, як організації укладали контракти на впровадження корпоративних ERP-рішень або серйозно інвестували в розробку на Power Apps. Бажаю удачі.

Невідповідність є структурною. Комерційне програмне забезпечення створене для бізнес-економіки, яка підраховує та виставляє рахунки за доходи. НУО витрачають кошти. Уся логіка працює у зворотному напрямку — гранти, бюджетні статті, обмеження донорів, критерії відповідності, звітування відповідно до пропозиції. Кожне з цих понять доводиться «натягувати» на модель даних, розроблену для доходів. Це завжди вимагає більше роботи, ніж закладено в оцінці, а сама оцінка вже була причиною, чому ви обрали цей шлях.

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

Те, що дійсно змінилося, — це вартість розробки. ШІ зробив створення спеціалізованих інструментів значно дешевшим. Процеси в НУО стали більш модульними, ніж раніше. А зрілі бази даних з відкритим вихідним кодом, такі як PostgreSQL, означають, що ваші дані залишаються сумісними та портативними, а не замкненими всередині чиєїсь ліцензії.

Чи варто вам залишати Microsoft і Google?

Ні. І це кажу я, людина, яка самостійно розміщує майже все.

Для організації середнього розміру, яка десятиліттями працювала на M365 або Workspace, міграція всієї інфраструктури нереалістична і не є ефективним використанням вашого політичного капіталу. Електронна пошта, документи, фінансова адміністрація, HR — залиште їх там. Оберіть опції з кордонами даних ЄС, чесно задокументуйте те, що залишається відкритим, і рухайтеся далі.

Але не залишайте все як є. Розділіть проблему:

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

З цього випливають дві речі, і обидві стосуються неперервності, а не конфіденційності.

• Майте план Б і запишіть його. Що станеться, якщо завтра тенант стане недоступним для всієї організації? У кого є контактний список, якого немає в Outlook? Яке країнове представництво все ще може авторизувати переказ коштів? Більшість організацій ніколи не ставили цього запитання. Це займає пів дня, нічого не коштує і є найдешевшою роботою щодо забезпечення безперервності бізнесу, доступною вам.
• І тримайте копію «під матрацом». Не все, але архів, реєстраційні записи, файли закритих проектів. Хмара має бути резервом, а не єдиною копією.

У березні 2026 року Nine PBS, громадський мовник у Сент-Луїсі, втратив доступ приблизно до 50 терабайтів матеріалів, що охоплюють сімдесят років місцевої телевізійної історії. Їхній постачальник хмарного сховища спочатку замовк, а згодом припинив існування. У цьому випадку йшлося не про одного з гіперскейлерів, а про малого спеціалізованого постачальника, з яким вони щороку поновлювали контракт з 2019 року. П'ятдесят терабайтів поміщаються на комерційному NAS менше ніж за ціною ноутбука. Ось і весь урок.

Кожна організація працює по-різному, але основні принципи є універсальними. Світ змінюється, і хоча єдиний «Гуманітарний хмарний сервіс» зрештою може стати рішенням, його розробка не звільняє нікого від негайних зобов'язань.

На решту часу відведено годинник

Умови грантів Microsoft вже змінювалися одного разу. 1 липня 2025 року безкоштовні гранти на Business Premium та Office 365 E1 для неприбуткових організацій завершилися; їх замінили 300 безкоштовних місць Business Basic та знижки до 75%. Організації, які чекали до дати поновлення, постраждали. Урок полягає не в цінах — він у тому, що весь ваш операційний стек тримався на пожертві, а не на контракті, а пожертви змінюються в односторонньому порядку. Цей перехід відбувається не зовсім гладко: постраждало понад 170 000 неприбуткових організацій, і видання Slate запитало, чи Microsoft винна у втраті даних.

Нещодавні зміни в ліцензуванні Microsoft скасовують безкоштовний рівень Business Premium, змушуючи НУО або платити за настільні додатки та розширену безпеку, або знижуватися до безкоштовного рівня лише для вебу, що серйозно ускладнює польові операції офлайн. Крім того, Microsoft тепер суворо дотримується правила 85% активності: нездатність підтримувати постійну активність облікового запису може призвести до скасування всієї виділеної організації безкоштовної ліцензії. Коли ці ліцензії знижуються або скасовуються, пов'язані дані остаточно видаляються протягом 30–90 днів, що робить незалежну інфраструктуру резервного копіювання з власним хостингом необхідною для захисту інституційної пам'яті.

Тим часом Закон ЄС про дані повністю скасовує плату за перехід між хмарними сервісами з 12 січня 2027 року. Контракт, який ви підпишете цього кварталу, все ще діятиме на ту дату. Якщо він містить застарілі умови виходу (egress), багаторічні блокування та автоматичні поновлення, настане дедлайн, і ви виявите, що все ще пов'язані економікою, яку цей закон мав демонтувати.

Я пишу окрему статтю про суверенітет ШІ для НУО. Це складніша проблема, і хороша новина полягає в тому, що це саме той рівень, де у вас ще є простір для маневру. Слідкуйте за оновленнями.

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