Штучний інтелект прискорив вашу команду в рази. А от перевіряти за ним ви швидше не стали.
У 2026 році AI перестав бути іграшкою для чернеток. Асистент сидить у корпоративній пошті й календарі, аналітика вбудована в CRM, агент має доступ до репозиторію, боти працюють у рекламних кабінетах. Компанія фактично найняла співробітника з доступом майже до всього – без співбесіди, випробувального терміну й керівника. Тож питання вже інше: хто контролює його дії?
Класичний захист будувався навколо периметра: фаєрвол, антивірус, паролі. AI створив іншу поверхню атаки – усередині, під легальними обліковими записами й у робочий час.
Внутрішній контур: ризики, які створює власна команда
1. Борг перевірки (review debt)
Найтихіший і найпоширеніший ризик: асистент видає готовий результат за секунди, і людина поступово перестає його читати – спершу вибірково, потім зовсім. З часом у компанії може з’явитися звичка натискати «Погодити» наосліп, і жодна система захисту цього не побачить – формально все за процедурою. Обсяг рішень, які щотижня проходять через компанію, зростає швидше, ніж кількість людей, здатних їх звірити.
2. Вигадані залежності (slopsquatting)
AI, який пише код, іноді впевнено підставляє назву бібліотеки, якої не існує. Зловмисники вивчають такі вигадки й заздалегідь реєструють ці назви зі шкідливим вмістом. Розробник встановлює пакет за підказкою помічника, і чужий код опиняється у продукті. Для українського ІТ ризик подвійний: команди часто працюють на замовника, тож пакет потрапляє далі – у продукт замовника, разом із відповідальністю за контрактом.
3. Тіньовий AI та відкриті RAG-бази
Співробітник завантажує договір з NDA або базу клієнтів у сторонній сервіс – у маркетингу це вже щоденна практика: підрядник зливає клієнтську базу, копірайтер – стратегію бренду. Та сама проблема є й усередині: доступ до корпоративної RAG-бази не обмежують так само суворо, як вихідні папки, тож бот видає стажисту дані, до яких той не мав доступу. Інциденту як події не існує: ніхто нічого не зламував.
Зайві права
Коли AI стає невидимим користувачем
4. Ідентичність агента (non-human identity)
Автоматизація працює під обліковим записом живої людини. У логах дія бота виглядає як дія фінансового директора: встановити, де закінчилася людина й почався алгоритм, уже неможливо. Для бізнесу це послаблює доказову базу – і перед банком, і перед регулятором.
5. Надлишкові права (excessive agency)
Асистента підключають «щоб просто працювало» і видають доступ із запасом.
На практиці це виглядає так: помічник для звітів отримує право писати в базу, бот для листування – бачити всю історію листування власника. Асистент у рекламному кабінеті працює поруч із бюджетом, а автопостинг говорить від імені бренду.
Поки все спокійно, цього ніхто не помічає. Коли обліковий запис компрометують, зловмисник отримує готовий пульт керування компанією.
Втім, рішення для кібербезпеки малого бізнесу не мусять бути складними: досить окремого облікового запису для кожного алгоритму, зрозумілої ролі й мінімально необхідних прав.
Зовнішні вектори: від маніпуляцій алгоритмом до збитків
6. Ін’єкції промптів (prompt injection)
Атака буває прямою – зловмисник просто пише боту команду в чаті, сподіваючись, що той її виконає. Частіше спрацьовує непряма: на пошту приходить PDF-рахунок від нового підрядника, асистент відкриває його, заносить дані в облік. Та всередині документа захована інструкція: надіслати у відповідь реквізити компанії й останні листи з фінансовим відділом. Без належних фільтрів асистент може сприйняти її як команду, а не як текст документа.
7. Ланцюг постачання (supply chain risks)
Бізнес підключає плагіни, розширення та SaaS-сервіси, майже не перевіряючи, хто за ними стоїть. Класичний приклад: браузерне розширення для аналітики соцмереж отримує оновлення й тихо дістає доступ до вкладок з поштою та CRM – дозвіл на це видали при встановленні.
Для малого й середнього бізнесу це сліпа пляма. Кожна інтеграція – чужий код у ваших системах, а обирають її за зручністю й ціною, рідше – за обсягом доступу.
8. Дипфейки та шахрайство від імені керівника (CEO fraud)
Голос і відео перших осіб підробляються переконливо, а сценарій часто схожий: терміновий платіж і прохання нікому не казати. Атакують не систему, а звичку підлеглого не сперечатися з директором. Українські команди розподілені між містами й країнами, тож «зайти й перепитати особисто» часто неможливо. Саме тому правило другого каналу варто зафіксувати письмово: будь-який нетиповий платіж підтверджується окремо, і виняток не робиться ні для кого.
Що з цим робити у 2026 році
AI варто розглядати як частину інфраструктури нарівні з бухгалтерією чи платіжним шлюзом – із тими самими вимогами до перевірки. Фаєрвол і антивірус захищають периметр, але не бачать, що відбувається всередині: яку команду отримав асистент, які дані він щойно віддав і чиїми правами скористався. Тому перевірка зміщується з периметра на самі алгоритми та їхні інтеграції.
Тестування на проникнення
Тестування на проникнення і регулярний аудит показують, чи можна підсунути асистенту чужу команду, до чого він насправді має доступ і скільки часу піде на виявлення.
Складіть список усіх AI-сервісів, якими реально користується команда: майже завжди в ньому опиняються інструменти, про які керівництво не знало. Далі дайте алгоритмам окремі облікові записи, обмежені права і чіткий перелік даних, які не повинні залишати периметр. Поверніть людину в контур там, де йдеться про гроші, договори та персональні дані: жоден платіж не проходить лише за дзвінком чи підтвердженням у месенджері.
Почати можна цього тижня й без бюджету. Випишіть, до яких систем має доступ кожен AI-помічник у вашій компанії, і викресліть усе, без чого він впорається із завданням. Така перевірка часто виявляє, що доступів більше, ніж очікувало керівництво, а частина з них нікому не потрібна. І такій перевірці підлягає будь-яка критична система компанії – AI тут не виняток.
