Для більшості компаній ризиків ШІ сім: витік даних, вигадані відповіді в документах і розрахунках, обіцянки чат-бота клієнтам від імені компанії, дії ШІ-агентів із доступом до пошти, банку чи облікових систем, інʼєкція інструкцій через листи й документи, швидше знаходження нападниками вразливостей у вашому програмному забезпеченні та порушення вимог щодо персональних даних і прозорості. Кожен із них стає керованим тоді, коли має власника серед керівників, опис робочої ситуації, першу дію і точку, де людина підтверджує результат. Дані зазвичай закріплюють за людиною, яка відповідає за захист персональних даних, розрахунки за фінансовим директором, чат-бот за комерційним директором, а агентів і оновлення програм за керівником ІТ. Усе це вміщується в реєстр на одну сторінку, який власник компанії переглядає раз на квартал.
Коротко
- Ризик ШІ без власника серед керівників нікому не належить, тому ним ніхто не займається.
- 21 жовтня 2026 року розкрили дві критичні вразливості в PHP, знайдені з допомогою ШІ, і через це оновлення програм теж стали частиною карти ризиків ШІ.
- Компанія відповідає за те, що пообіцяв клієнтам її чат-бот, тому бот має відповідати лише з перевіреної бази умов.
- ШІ-агенту дають мінімально необхідний доступ, журнал дій, можливість негайної зупинки і підтвердження людиною перед критичними діями.
- Сім ризиків, по одному рядку на кожен, складають реєстр на одну сторінку, який керівники переглядають раз на квартал.
Чому ризики ШІ в компанії потребують власника серед керівників?
Ризики ШІ розкидані між продажами, фінансами, ІТ і кадрами, і кожен відділ бачить лише свою частину. Ризиком без власника ніхто не займається, поки він не спрацює, тому всі ризики варто зібрати в одну карту і біля кожного поставити посаду конкретного керівника.
21 жовтня 2026 року розкрили дві критичні вразливості в ядрі PHP, мови програмування, на якій працює більшість сайтів. Вони дозволяють віддалено виконати код без входу в систему, а оцінка їхньої небезпеки становить 9.2 з 10. Вади сиділи в коді понад десятиліття, а знайшли їх дослідники з допомогою передових моделей ШІ. Спробу атаки помітили 17 жовтня, за чотири дні до розкриття, а після розкриття нападники почали широко використовувати вразливість. Розробник ШІ, який координував розкриття, сам визнає, що ті самі можливості допомагають і нападникам.
Виправлення вийшли того ж дня. Держоргани кібербезпеки кількох країн радили негайно оновитися, а системи, які не можна оновити, тимчасово відключити від інтернету. 22 жовтня CERT-UA пояснила, як захистити сервери. Керівник не мусить розумітися на коді, але має знати, хто в компанії відповідає за оновлення сайту і серверів і за скільки часу ця людина може їх оновити.
Візьмімо типову компанію з доставки й монтажу техніки на кілька десятків працівників. У неї є сайт із чат-ботом, менеджери пишуть листи з допомогою ШІ, бухгалтерія пробує ШІ для звірок, а ШІ-агент від підрядника читає вхідну пошту і створює заявки. Сайт роками працює на застарілій версії програм, і ніхто не памʼятає, хто відповідає за оновлення. Цей ризик бере на себе керівник ІТ, а якщо такої посади немає, операційний директор разом із підрядником. Почати варто з переліку всіх систем компанії, де працює PHP, бо ця мова часто вбудована в інші програми, і біля кожної записати, хто і в який строк її оновлює.
Хто відповідає за витік даних і персональні дані, коли працівники користуються ШІ?
Найчастіший ризик виникає без жодного злого наміру. Працівник хоче швидше впоратися із задачею і вставляє в зовнішній чат-бот таблицю клієнтів, текст договору чи прайс із закупівельними цінами. У компанії доставки так зазвичай буває, коли менеджер просить чат-бот розсортувати клієнтів за районами і завантажує туди файл з іменами, телефонами й адресами. Після цього дані вже за межами компанії.
В Україні діє закон про захист персональних даних, і він поширюється на роботу з ШІ так само, як на будь-яку іншу обробку. Добровільні рекомендації Мінцифри з відповідального використання ШІ, оприлюднені у квітні 2026 року, серед ключових ризиків називають несанкціонований доступ до даних, приховане або надмірне збирання інформації і витік через інтеграції із зовнішніми сервісами.
Цей ризик належить людині, відповідальній за захист персональних даних, разом із керівником ІТ. У малій компанії, де таких посад немає, його бере на себе власник або операційний директор. Першим кроком стає сторінка правил із переліком дозволених сервісів і даних, які лишаються всередині компанії. Далі кожен сервіс отримує мінімально необхідний доступ, тобто рівно стільки даних, скільки потрібно для задачі.
Хто відповідає за вигадані відповіді ШІ в документах, розрахунках і обіцянках клієнтам?
Мовні моделі іноді вигадують факти, цифри й посилання і подають їх так само впевнено, як правдиві. У компанії доставки бухгалтерія просить ШІ підготувати звіт із розрахунком витрат на пальне, і в підсумковій таблиці зʼявляється цифра, якої немає в первинних документах. Охайний звіт легко підписати без перевірки, і помилка переходить у бюджет.
У розрахунках власником ризику є фінансовий директор або головний бухгалтер, у документах керівник відповідного процесу. Точка підтвердження означає, що конкретна людина звіряє критичні факти й числа з первинними джерелами, перш ніж документ піде далі. Рекомендації Мінцифри окремо називають ризиками формальне підтвердження без перевірки і перекладання відповідальності на ШІ. Підпис під документом, який ніхто не читав, ризику не знімає, він лише ховає його.
Окрема історія стосується чат-бота на сайті. У лютому 2024 року канадський трибунал визнав компанію відповідальною за неправдиву інформацію про знижку, яку клієнту дав чат-бот на її сайті, і відхилив аргумент, що бот є окремою сутністю, яка відповідає сама за себе. Коли бот компанії доставки пообіцяв клієнту безкоштовний монтаж, якого немає в умовах, ця обіцянка стала проблемою компанії, а не програми.
За бота відповідає комерційний директор або керівник сервісу разом із юристом. Найважливіше налаштування: бот відповідає лише з перевіреної бази умов, а питання про гроші, строки і винятки передає людині. Якщо компанія працює з клієнтами в ЄС, варто врахувати, що з 2 серпня 2026 року людина там має знати, що спілкується з ШІ, якщо це не очевидно з самої ситуації.
Хто відповідає за ШІ-агентів, доступи та інʼєкцію інструкцій?
ШІ-агентом називають систему, яка сама виконує дії: читає пошту, створює заявки, надсилає листи, працює з обліковими програмами. Чим ширші права агента, тим дорожче коштує його помилка.
Рекомендації Мінцифри серед ризиків агентів називають несанкціоновані фінансові чи адміністративні операції, компрометацію облікових даних і каскадне поширення помилки через повʼязані системи. Помилка агента в одній системі швидко потрапляє в пошту, облік і рахунки.
Окремий ризик має власну назву. Шкідливі вказівки ховають у тексті листа, документа, вебсторінки чи у відповіді іншого інструмента, і модель сприймає їх як команду. Таку атаку називають інʼєкцією інструкцій. У міжнародному переліку головних ризиків застосунків на мовних моделях, виданому у 2026 році, вона стоїть на першому місці. Типова ситуація виглядає так: у компанію приходить лист від нібито нового клієнта, а всередині дрібним текстом схована вказівка переслати всі договори на сторонню адресу. Агент виконує її, бо не відрізняє вказівку власника від тексту листа, і документи йдуть назовні.
Відповідає за агентів керівник ІТ або відповідальний за безпеку. Якщо агента налаштовував підрядник, його обовʼязки щодо безпеки, журналу і реагування записують у договір. Захист тут складається з кількох правил: агент отримує мінімально необхідний доступ, людина підтверджує кожне надсилання назовні і кожну фінансову операцію, усі дії агента пишуться в журнал, а в компанії є людина, яка може негайно зупинити агента.
Як скласти реєстр ризиків ШІ, щоб він поміщався на одну сторінку?
Реєстр ризиків корисний, лише коли його читають, тому він має бути коротким і зрозумілим людям без технічної освіти. По кожному ризику достатньо записати пʼять пунктів:
- робочу ситуацію одним реченням, зрозумілим кожному керівнику;
- власника ризику, тобто посаду конкретного керівника, а не назву відділу;
- першу дію і точку, де людина підтверджує результат;
- ознаку, за якою видно, що ризик спрацював;
- дату наступного перегляду.
Сім ризиків із попередніх розділів займають сім рядків, і такий документ поміщається на одну сторінку. Підрядники входять у реєстр через договори: у реєстрі стоїть посада керівника, який відповідає за договір, а в договорі записано доступи, строки оновлень і дії в разі інциденту.
Рекомендації Мінцифри радять керівництву призначити відповідальних за нагляд, включно з особою, відповідальною за захист персональних даних, і експертом процесу, тобто працівником, який найкраще знає, як цей процес має працювати. У компанії доставки експертом процесу заявок буде старший диспетчер, а експертом процесу розрахунків головний бухгалтер. Вони першими помічають, що агент чи звіт поводяться дивно. Цей текст є загальною навчальною інформацією, а не юридичною чи технічною консультацією.
Що має робити власник компанії, щоб карта ризиків ШІ працювала, а не лежала в папці?
Власник компанії не веде кожен ризик сам. Раз на квартал він переглядає реєстр разом із власниками ризиків і ставить три питання: що змінилося в сервісах і доступах, чи були випадки, коли ризик спрацював або майже спрацював, і чи оновлено програми на сайті й серверах.
Кожен новий ШІ-сервіс чи агент потрапляє в реєстр до запуску, а не після.
Працівника, який чесно повідомив, що вставив у чат-бот не той файл, не карають, інакше керівництво дізнаватиметься про випадки останнім. Для компаній, що працюють з ЄС, до карти додаються ще й вимоги закону ЄС про ШІ щодо навчання працівників.
У підсумку карта ризиків ШІ працює тоді, коли кожен із семи ризиків має посаду власника, першу дію і людину на точці підтвердження, а власник компанії регулярно перевіряє, що ці люди справді знають про свою відповідальність і мають час нею займатися.
Що робити далі
- Призначте власника для кожного з семи ризиків і запишіть його посаду в реєстр на одну сторінку.
- Попросіть керівника ІТ або підрядника скласти перелік усіх систем компанії, де працює PHP, і підтвердити, що їх оновлено після 21 жовтня 2026 року.
- Затвердьте сторінку правил із переліком дозволених ШІ-сервісів і даних, які лишаються всередині компанії.
- Перевірте, з якої бази умов відповідає чат-бот на сайті, і налаштуйте передачу людині питань про гроші, строки і винятки.
- Обмежте доступи кожного ШІ-агента до мінімально необхідних і переконайтеся, що є журнал його дій і людина, яка може його негайно зупинити.