Зміст
Вступ
Під час обговорення корпоративного ШІ питання безпеки виникає одним із перших. Це закономірно: технічна документація, регламенти, результати експертиз і внутрішні методики часто цінніші за програмне забезпечення, що їх обробляє.
Безпеку не можна залишати окремим етапом проєкту. Якщо вона з'являється після вибору сервісів та інтеграцій, доопрацювання стають дорогими, а впровадження іноді виявляється неможливим.
Чому це важливо
Корпоративна платформа ШІ отримує доступ до критично важливих знань. Архітектурна помилка означає не лише ризик витоку, а й втрату довіри бізнесу до системи.
Локальне розгортання саме по собі не вирішує проблему. Платформа має контролювати, хто звертається до даних, які джерела може використати відповідь і як перевірити дії користувачів та сервісів.
Основне пояснення
Безпека — це система вимог, за якими перевіряють кожне архітектурне рішення. Потрібно знати, які дані використовуються, хто має право їх бачити, як підтверджуються права, як установлюється походження відповіді та як фіксуються дії.
flowchart TD
user[Користувач] --> identity[Перевірка особи]
identity --> role[Перевірка ролі]
role --> retrieval[Пошук дозволених документів]
retrieval --> llm[LLM]
llm --> answer[Перевірювана відповідь]
answer --> audit[Журналювання]
Практична модель містить щонайменше п'ять рівнів: класифікацію даних, управління доступом, контроль джерел, аудит і моніторинг. Відсутність будь-якого з них послаблює захист усієї платформи.
Ключове правило — успадкування прав: якщо працівник не може відкрити документ у системі-власнику, ШІ не має права використовувати його для підготовки відповіді.
Корпоративний приклад
Підприємство підключає ШІ до системи електронного документообігу. Хибне рішення — надати моделі доступ до всіх файлів заради зручного пошуку.
Правильне рішення застосовує чинну рольову модель під час отримання контексту. Платформа успадковує правила підприємства, не створює паралельну систему дозволів і фіксує звернення до знань для аудиту.
Приклад з промислової безпеки
Експерт працює з матеріалами обстеження небезпечного виробничого об'єкта. Документи містять технічні відомості, діагностику та внутрішні рекомендації.
ШІ може знайти пов'язані матеріали й норми, але зобов'язаний дотримуватися обмежень доступу. Кожна сформована відповідь має бути перевірюваною: експерт бачить використані документи та зберігає відповідальність за висновок.
Типові помилки
- Вважати локальне розгортання достатнім захистом.
- Давати моделі доступ до всіх даних без урахування ролей.
- Не журналювати звернення до знань і сформовані відповіді.
- Використовувати неперевірені або застарілі джерела.
- Не враховувати вимоги законодавства й внутрішніх політик.
Практичні висновки
Підготуйте модель безпеки до початку проєктування:
- класифікацію даних і правила їх використання;
- ролі користувачів та матрицю доступу;
- вимоги до перевірюваності джерел;
- правила аудиту й строки зберігання журналів;
- порядок моніторингу та реагування на інциденти.
Ця модель має бути частиною архітектурної документації, а не додатком до неї.
Ключові тези
- Безпека визначає архітектуру, а не доповнює її після запуску.
- Локальне розгортання не замінює управління доступом.
- Права користувача поширюються на контекст і результати роботи ШІ.
- Перевірюваність відповідей та аудит є обов'язковими для корпоративної платформи.
- ШІ допомагає експерту, але не знімає з нього відповідальності за рішення.