Чим цінніші дані компанії, тим менше з них користі: чому захист і аналітика заважають одне одному
Коли компанії почали впроваджувати корпоративний ШІ, з'ясувалося, що багато з них не знають, які дані в них зберігаються, хто за них відповідає і куди їх копіюють. Раніше через це гальмувала звітність і дорожчали інтеграції. Тепер одна помилка може відкрити моделі чужі документи або відправити конфіденційну інформацію в зовнішній сервіс.
Олег Бондарчук понад 18 років працює з корпоративною інфраструктурою та хмарною безпекою, а зараз проєктує середовища Microsoft Azure для великої міжнародної перестрахувальної компанії. Він Senior Member IEEE, оцінює заявки інших інженерів на цей статус, технічні публікації та роботи учасників міжнародних технологічних конкурсів, а також пише наукові статті про кібербезпеку і штучний інтелект. В інтерв'ю він розповідає, як зробити найчутливіші дані компанії придатними для аналітики й ШІ без нових винятків із правил безпеки.
Чому найцінніші дані компанії так часто лежать без діла?
Бо їх закривають, але не описують. Клієнтську історію, страхові справи чи медичні документи ізолюють в окремих системах, і на цьому робота з ними закінчується: немає каталогу, немає власника, який відповідає за якість, немає зрозумілого способу отримати доступ. Аналітик, якому потрібні ці дані, місяцями чекає погоджень і врешті просить вивантаження в Excel, яке вже ніхто не контролює. Виходить, що захист без нормального способу працювати з даними сам штовхає людей його обходити.
Отже, безпека й аналітика справді конфліктують?
Конфліктують, коли їх проєктують різні команди в різний час. Зазвичай розробники будують систему, а перед запуском приходить служба безпеки зі списком вимог. Частину виконують, на решту оформлюють ручні винятки, і кожен наступний проєкт повторює той самий шлях. Якщо ж архітектуру даних і правила доступу проєктують разом, безпека заздалегідь визначає, хто і з якою метою може користуватися даними, тож новий звіт чи застосунок підключається за готовими правилами.
Ви створили фреймворк, за яким команди перенесли в Azure 300 застосунків, і кілька landing zones для критичних систем. Як безпека, закладена в платформу, виглядає на практиці?
Landing zone найпростіше уявити як підготовлений майданчик у хмарі. Мережеві межі, облікові записи, політики доступу та журналювання там налаштовані ще до того, як команда принесе свій застосунок. Для міграції такого масштабу це принципово: узгоджувати безпеку для кожного з 300 застосунків окремо було б нереально. Команда отримує перевірений маршрут, і контрольні перевірки на ньому спрацьовують автоматично. Той самий принцип я закладав в автоматизацію розгортання для Azure Marketplace: коли правильний шлях найпростіший, обхідні стають непотрібними.
Багато компаній вважають зашифровані дані захищеними. Чому цього мало?
Шифрування рятує, якщо хтось украв диск чи перехопив трафік. Проте обліковий запис користувача або сервісу із зайвими правами отримає дані вже розшифрованими. Тому важливіше питання: хто має доступ і навіщо. Відповідь на нього дають класифікація даних, мінімально необхідні права та керовані ідентичності замість спільних паролів. Найчутливіші поля, як-от номери страхування чи банківські реквізити, я шифрую окремо відповідно до вимог GDPR. Ще одне слабке місце: секрети й сертифікати, через які програми звертаються одна до одної. Я розробив платформу, яка стежить за строками їхньої дії та заздалегідь попереджає відповідальні команди, щоб оновлення не робили в останній момент.
У R2 Copilot ви використали RAG, щоб не передавати ШІ всю внутрішню базу. Цього достатньо для конфіденційності?
RAG працює так: документи індексуються в контрольованому середовищі, а модель на кожне запитання отримує лише кілька потрібних фрагментів. Контексту передається менше, і видно, звідки він узявся. Однак якщо пошук не враховує права користувача, асистент охоче покаже бухгалтеру документи юридичного відділу. Тому в R2 Copilot результати фільтруються за правами конкретної людини, джерела розмежовані, а кожне звернення потрапляє в журнал. Схожу логіку ми закладали в платформу цифрової ідентичності HyperID: сервіс підтверджує лише той факт, який потрібен для операції, і не отримує копію всього профілю.
Один із ваших проєктів стосувався оцифрування близько 15 мільйонів сторінок медичної та фармацевтичної документації в Казахстані. Що він показав?
Саме по собі оцифрування мало що змінює. Якщо відсканувати архів і скласти файли в сховище без моделі доступу, паперовий склад просто стає цифровим. Користь з'являється, коли документи можна швидко знайти, перевірити та використати в роботі, і водночас відомо, хто і коли їх відкривав. Тому пошук і правила доступу в таких проєктах треба продумувати одночасно зі сховищем.
Як підготувати дані до ШІ, якого бізнес ще навіть не обрав, і як зрозуміти, що це вдалося?
Вгадувати модель не потрібно. Достатньо, щоб у кожного джерела даних були власник, класифікація та контрольований інтерфейс доступу, а кожне звернення залишало слід у журналі. Тоді новий асистент отримує обмежений і задокументований доступ до потрібних даних. Результат видно за кількома показниками: скільки часу займає надання безпечного доступу, яка частка джерел має власника, скільки ручних винятків лишилося. Думаю, найближчими роками виграватимуть компанії, які швидко доведуть, звідки їхні дані, наскільки вони якісні й чи можна їх використовувати. Хоча технічна доступність даних ще не дає права ними користуватися, і цю межу інженер не може визначати сам.
Читайте нас у Facebook
Зараз читають на Інформаторі
