ШІ, кібербезпека та ІТ-контракти – посібник для бізнесу

Від Mallbutiken · Факти перевірено 30 вересня 2026 р. · Приблизно 12 хвилин на читання

ШІ, захист даних, SaaS-договори, NIS2 та безперервність бізнесу — це не окремі острови документації. Вони перетинаються у межах одних і тих самих практичних питань: які системи можна використовувати, які дані можна обробляти, які вимоги висувати до постачальника, хто відповідає за ризики та як продовжувати роботу, якщо сервіс зникне?

Який документ вирішує яке питання?

Політика ШІ та управління ШІ: розділяйте регулювання використання та системні ризики

Політика ШІ відповідає насамперед на питання користувачів: які інструменти дозволені, яку інформацію можна вводити, коли потрібен контроль з боку людини, як обробляється зовнішня публікація та що робити працівнику в разі інциденту?

Управління ШІ (AI Governance) є ширшим поняттям. Воно вимагає від організації здатності інвентаризувати ШІ-системи, визначати свою роль відповідно до Регламенту про ШІ, оцінювати кейси використання, розподіляти відповідальність та відстежувати зміни у постачальників з часом.

Регламент ЄС про ШІ базується на ризиках та ролях. Тому помилково думати, що один документ робить компанію «відповідною AI Act». Документація повинна відображати, які системи організація фактично розробляє, надає або використовує.

ШІ та персональні дані швидко перетинаються

Якщо ШІ-інструмент обробляє персональні дані, управління ШІ має бути пов'язане з процесами GDPR. Перевірте, серед іншого, мету, правову підставу, ролі щодо обробки даних, мінімізацію даних, питання третіх країн та необхідність оцінки впливу згідно з GDPR.

GDPR та договори з обробниками: почніть з фактичної ролі

Легко сприймати DPA як додаток, який завжди слід надсилати ІТ-постачальнику. Правильним першим кроком є оцінка того, хто саме визначає мету та засоби обробки персональних даних.

Коли постачальник обробляє персональні дані від імені клієнта, застосовується стаття 28 GDPR та обов'язкове регулювання обробки. Договір повинен охоплювати інструкції, безпеку, субпідрядників, підтримку відповідальної особи, видалення/повернення даних та можливість аудиту.

SaaS-договір: пов'яжіть сервіс, дані, безпеку та вихід

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

Наприклад, запитайте:

• Що саме входить у підписку?
• Як вимірюється доступність?
• Які рівні інцидентів та часові рамки реагування застосовуються?
• Де зберігаються дані і які субпідрядники використовуються?
• Які засоби контролю безпеки можна перевірити?
• Як клієнт може експортувати дані та припинити використання сервісу?

Якщо сервіс обробляє персональні дані, SaaS-договір пов'язується з DPA. Якщо клієнт підпадає під дію закону про кібербезпеку, вимоги до безпеки та ланцюга постачання можуть бути суттєво посилені.

NIS2 та закон про кібербезпеку: постачальник — частина карти ризиків

Шведський закон про кібербезпеку (2025:1506) набув чинності 15 січня 2026 року. Для організацій, на які поширюється закон, заходи безпеки мають стосуватися аналізу ризиків, управління інцидентами, безперервності діяльності та кризового менеджменту, безпеки ланцюга постачання, безпеки при закупівлі/розробці/обслуговуванні, моніторингу, кібергігієни, криптографії та контролю доступу.

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

Не до всіх постачальників слід висувати однакові вимоги

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

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

BIA та план безперервності: від вимог до фактичної стійкості

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

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

Методична підтримка Шведського агентства цивільного захисту описує аналіз впливу, оцінку ризиків, заходи та планування безперервності як частини цілісного процесу управління безперервністю діяльності.

Практичний робочий порядок для компаній

1. Інвентаризація. Перелічіть критичні процеси, ІТ-послуги, ШІ-системи, потоки даних і постачальників.
2. Класифікація. Яка інформація та діяльність є найбільш цінними або критичними за часом?
3. Оцінка ролей та вимог закону. Роль згідно з GDPR, роль згідно з AI Act, застосування NIS2 та будь-які галузеві вимоги.
4. Пріоритезація розривів. Починайте там, де фактичний ризик і вплив на бізнес є найбільшими.
5. Внутрішнє управління. Політики, ролі, затвердження та навчання.
6. Зовнішнє регулювання. SaaS, DPA, вимоги безпеки та інші умови постачальників.
7. Планування збоїв. BIA, резервні процедури та план безперервності.
8. Тестування та моніторинг. Документація повинна призводити до вимірюваного контролю та вдосконалення.

Приклад: компанія впроваджує HR-систему на базі ШІ

Одна й та сама закупівля може вимагати кількох перспектив. Управління ШІ оцінює використання ШІ та ризики системи. Політика ШІ вказує, які функції дозволено використовувати працівникам. Оцінка GDPR картографує персональні дані та ролі. SaaS-договір регулює послуги, SLA та вихід. Оцінка безпеки перевіряє доступ та ланцюг постачання. BIA визначає, наскільки система є критичною для бізнесу, а план безперервності описує резервну процедуру на випадок збою системи.

Мета не в тому, щоб створити максимальну кількість документів. Мета в тому, щоб одна й та сама реальна система була послідовно керована на всіх релевантних рівнях управління та контрактів.

Контрольний список для керівництва

• Чи знаємо ми, які саме ШІ-системи та критичні ІТ-послуги використовуються?
• Чи є відповідальний за кожну критичну систему та постачальника?
• Чи задокументовані ролі обробки даних та потоки даних?
• Чи перевірили ми, які системи можуть містити конфіденційну інформацію?
• Чи існують вимірювані SLA та вимоги безпеки там, де бізнес залежить від постачальника?
• Чи відомі критичні субпідрядники та потоки даних у треті країни?
• Чи визначила організація свої найбільш критичні за часом види діяльності?
• Чи існують реалістичні резервні процедури та цілі відновлення?
• Чи тестуються безперервність та безпека на практиці?
• Чи існує процедура для змін: нові функції ШІ, постачальники, інтеграції та умови договорів?
• Чи отримує керівництво регулярні звіти про ризики, інциденти та відкриті завдання?

Потрібно структурувати управління ШІ?

Пакет управління ШІ від Mallbutiken містить шість шаблонів у форматі Word/PDF та реєстр ШІ в Excel для інвентаризації систем, оцінки ризиків, контролю постачальників тощо. Ціна в магазині: 199 крон.

Переглянути пакет управління ШІПереглянути шаблони для ШІ

Поглиблення за областями