Безпека ШІ у 2026 році

Від розуміння ризиків ШІ до зрілої системи контролю

Коли в листопаді 2024 року ми опублікували нашу базову статтю «Безпека штучного інтелекту», головне питання для багатьох компаній звучало так: чому ШІ взагалі потребує окремої уваги з боку безпеки, управління ризиками та керівництва? Тоді було важливо пояснити фундаментальні ризики: довіру до моделі, конфіденційність, маніпуляції, непрозорість, атаки на дані, помилки у висновках і необхідність управляти ШІ протягом усього життєвого циклу. У тій статті ми розглядали моделі загроз, практичні настанови та підходи до мінімізації ризиків ШІ.

Сьогодні розмова змінилася. У 2025–2026 роках ШІ дедалі частіше перестає бути експериментом у браузері або окремою функцією продукту. ШІ почав вбудовуватися в юридичні, фінансові, інженерні, клієнтські, аналітичні та операційні процеси. LLM використовуються як внутрішні асистенти, RAG-системи отримують доступ до корпоративних документів, а ШІ-агенти підключаються до інструментів і API. Керівники очікують від таких рішень не демонстрацій, а вимірюваного бізнес-ефекту.

Через це безпека ШІ перестала бути питанням загальної обізнаності. Компаніям вже недостатньо знати, що існують ін’єкції промптів, витоки даних, галюцинації або ризик упередженості моделі. Потрібно розуміти, де саме використовується ШІ, які дані він бачить, які дії може виконувати, хто відповідає за результат, як система журналює події, як контролюються постачальники, як перевіряються зміни, і які докази зрілості можна показати аудитору, інвестору, клієнту або регулятору.

Тобто зріла безпека ШІ у 2026 році — це вже не разова перевірка моделі. Це поєднання архітектури, оцінки ризиків, управління доступами, безпеки даних, тестування, моніторингу, процесів експлуатації, стратегічного управління та регулярної переоцінки.

Глосарій AIBOM — перелік компонентів, залежностей та артефактів, пов’язаних із ШІ-системою. API — інтерфейс програмування застосунків. DAST — динамічне тестування безпеки застосунків. DevSecOps — вбудовування безпеки в розроблення, постачання та експлуатацію програмного забезпечення. DLP — запобігання витокам даних. EU AI Act — Регламент Європейського Союзу про штучний інтелект. GPAI — модель штучного інтелекту загального призначення. IAM — управління ідентифікацією та доступом. ISO/IEC — міжнародні стандарти у сфері інформаційних технологій та кібербезпеки. LLM — велика мовна модель. MCP — Model Context Protocol, стандарт підключення ШІ-асистентів до зовнішніх інструментів, даних та інтерфейсів. NIST — Національний інститут стандартів і технологій США. OWASP — відкрита спільнота й фонд, що розробляють практичні матеріали з безпеки застосунків. RAG — retrieval-augmented generation, архітектура, за якої LLM формує відповідь із використанням зовнішніх джерел знань. SAST — статичний аналіз безпеки вихідного коду. SIEM — система збирання, кореляції та аналізу подій безпеки. SOC — центр моніторингу та реагування на інциденти безпеки.

ШІ-система — це вже не лише модель

Одна з головних помилок раннього підходу до безпеки ШІ полягала в тому, що модель розглядали як головний і майже єдиний об’єкт захисту. Зараз корпоративна ШІ-система зазвичай складається з набагато більшої кількості компонентів.

До неї можуть входити LLM, RAG-контур, векторна база, документи бази знань, системні промпти, користувацькі запити, журнали діалогів, зовнішні API, агенти, плагіни, MCP-сервери, хмарні сервіси, механізми авторизації, засоби фільтрації введення й виведення, інструменти спостережуваності та процеси реагування. Помилка в будь-якому з цих шарів може призвести не просто до «неправильної відповіді», а до витоку даних, порушення бізнес-процесу, виконання небажаної дії або появи юридичного ризику.

Особливо помітно це в RAG-системах. На перший погляд RAG виглядає як зручний спосіб дати LLM доступ до актуальних корпоративних знань без перенавчання моделі. Водночас із погляду безпеки RAG створює новий критичний контур. Документи, права доступу, векторні індекси, ембединги (embeddings), механізми пошуку, правила зберігання, джерела даних і логіка добору контексту стають частиною поверхні атаки. OWASP у матеріалах із безпеки даних для генеративного ШІ прямо виділяє необхідність враховувати весь шар даних — від навчальних і донавчальних наборів до користувацьких промптів та фінальних відповідей моделі.

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

Ін’єкції промптів стали бізнес-ризиком, а не лабораторною екзотикою

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

Якщо ШІ лише відповідає користувачу, наслідки можуть обмежитися неправильною рекомендацією або розкриттям частини контексту. Однак якщо ШІ підключений до інструментів, пошти, CRM, DevOps-систем, фінансових операцій або адміністративних API, ін’єкція промпта вже може вплинути на дії системи. Тоді помилка перетворюється з інформаційного ризику на операційний.

Ін’єкції промптів – не єдиний клас ризиків для LLM-застосунків. OWASP Top 10 for LLM Applications версії 2025 виділяє також розкриття чутливої інформації, ризики ланцюга постачання, отруєння даних і моделей, небезпечну обробку виводу, надмірну автономність, витоки системних промптів, дезінформацію, неконтрольоване споживання ресурсів, а також слабкі місця векторних баз і ембедингів. Це добре показує, наскільки тема вийшла за межі класичного пентесту. Тепер перевіряти потрібно не лише форми, ролі та API, а й те, як модель інтерпретує інструкції, контекст і межі своїх повноважень.

ШІ-агенти підвищують ціну помилки

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

Саме тут з’являється якісно нова загроза: модель починає не лише говорити, а й діяти.

OWASP Agentic AI Threats and Mitigations описує агентів як автономні системи, можливості та ризики яких різко зросли завдяки інтеграції з LLM та іншим генеративним ШІ. Окремий список OWASP Top 10 for Agentic Applications 2026 уже фокусується на ризиках автономних і агентних систем, які планують та приймають рішення, а також діють у складних робочих процесах.

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

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

MCP і зовнішні інструменти розширюють поверхню атаки

MCP і подібні механізми підключення ШІ до зовнішніх інструментів швидко стали однією з найцікавіших і водночас найризикованіших зон. Вони роблять ШІ кориснішим: асистент може працювати з файлами, системами, API, внутрішніми даними та корпоративними процесами. І саме це перетворює інтеграційний шар на новий об’єкт безпеки.

OWASP у практичному керівництві з безпечного розроблення MCP-серверів підкреслює, що такі сервери є критичною точкою з’єднання між ШІ-асистентами, зовнішніми інструментами, API та джерелами даних. На відміну від звичайних API, MCP-сервери часто працюють із делегованими правами користувача, динамічними інструментами й ланцюжками викликів. Це підвищує можливу шкоду від однієї вразливості. Керівництво окремо виділяє захищену архітектуру, сувору автентифікацію й авторизацію, валідацію, ізоляцію сесій і харденінг розгортання.

На практиці це означає, що шар інструментів не можна розглядати як технічну «обв’язку» навколо моделі. Його потрібно проєктувати як повноцінну зону довіри: з розділенням читання й запису, обмеженням токенів, контролем обсягу дії, окремим журналюванням, політиками відмови, тестами зловживань і розумінням «радіуса ураження» (blast radius) — тобто максимального збитку в разі компрометації або помилки.

Ланцюг постачання ШІ стає частиною безпеки

У класичній безпеці програмного забезпечення компанії вже давно звикли думати про залежності, бібліотеки, контейнери, образи, пакети й зовнішніх постачальників. У 2025 році ця проблема вийшла на якісно новий рівень. В OWASP Top 10 ризик компрометації ланцюга постачання став одним із трьох найбільш пріоритетних класів ризиків. У 2026 році цей тренд значно посилився. У ШІ ця проблема не зникає, а ускладнюється.

ШІ-система може залежати від зовнішньої моделі, відкритих ваг, набору даних, фреймворку оркестрації, бібліотеки для виведення моделі, векторної бази, інструмента донавчання, зовнішнього переранжувальника (reranker), сервісу модерації, хмарного API, набору тестів або стороннього агента. Вразливість, підміна або непрозорість будь-якого з цих компонентів може вплинути на безпеку, відтворюваність, якість, юридичну чистоту або відповідність вимогам.

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

Регуляторний та управлінський контур став практичним

EU AI Act почав набирати чинності 1 серпня 2024 року, але тоді практичне регулювання ШІ здавалося віддаленим. Зараз для компаній, які працюють у ЄС або з європейськими клієнтами, це вже не абстракція. Окремі заборони й обов’язки щодо грамотності в сфері ШІ застосовуються з лютого 2025 року. Правила управління та обов’язки для постачальників моделей ШІ загального призначення почали застосовуватися з серпня 2025 року. Уже 2 серпня 2026 року EU AI Act набирає повної чинності, хоча для деяких випадків передбачені додаткові поетапні винятки й перехідні періоди.

Важливо не змішувати ролі організацій. Обов’язки постачальника моделі загального призначення, розробника ШІ-системи та компанії, яка впроваджує сторонній ШІ-сервіс у свої процеси, відрізняються. Для більшості клієнтів практика ШІ-комплаєнсу починається не з питання типу «чи ми є постачальником GPAI-моделі?», а з інвентаризації сценаріїв, ШІ-грамотності, заборони недопустимих практик, оцінки високоризикових кейсів, договірних вимог до постачальників і доказів контролю.

У липні 2025 року був опублікований General-Purpose AI Code of Practice — добровільний інструмент, що допомагає постачальникам моделей загального призначення демонструвати відповідність обов’язкам за EU AI Act, зокрема в блоках прозорості, авторського права, безпеки та захищеності для найбільш просунутих моделей.

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

Тут корисні різні опорні документи, хоча жоден із них не розв’язує всю задачу сам по собі. NIST AI RMF залишається зручною мовою управління ризиками ШІ та був доповнений профілем для генеративного ШІ NIST AI 600-1. Стандарт NIST SP 800-218A розвиває практики безпечного розроблення для генеративного ШІ та базових моделей ШІ на основі SSDF. Публікація NIST AI 100-2e2025 дає таксономію й термінологію атак на машинне навчання, а попередній NIST Cyber AI Profile пов’язує ШІ з управлінням кіберризиком, захистом ШІ-систем, використанням ШІ в захисті та протидією атакам, посиленим ШІ. Стандарт ISO/IEC 42001 задає вимоги до системи менеджменту ШІ, а ISO/IEC 23894 допомагає вбудувати управління ризиками ШІ в процеси організації.

Зрілий підхід не зводиться до вибору «одного правильного стандарту». Будується пов’язана система: стратегічне управління на рівні керівництва, архітектурні рішення на рівні продукту, контроль даних і доступів на рівні інженерії, тестування на рівні контрольних точок, моніторинг на рівні експлуатації та докази на рівні комплаєнсу.

Чому класичної безпеки застосунків уже недостатньо

Безпека ШІ не скасовує класичну безпеку застосунків. Навпаки, без неї неможливо побудувати надійну ШІ-систему. Вебзастосунки, API, автентифікація, авторизація, шифрування, секрети, журнали, інфраструктура, хмарна безпека, безпечне розроблення, SAST, DAST і DevSecOps залишаються обов’язковою базою.

Проблема в іншому: цієї бази вже недостатньо.

LLM може виконувати шкідливу інструкцію, яка виглядає як звичайний або невидимий текст. RAG може розкривати знання через неочевидні зв’язки між документами. Агент може виконати допустимий API-виклик у недопустимому бізнес-контексті. Вивід моделі може стати входом для іншої системи й спричинити вразливість уже на наступному кроці. Логи можуть містити конфіденційні промпти та відповіді. Постачальник моделі може змінити поведінку сервісу без звичного релізного циклу клієнта.

Тому безпека ШІ потребує розширення класичних практик. Моделювання загроз має враховувати не лише користувачів, ролі та API, а й джерела контексту, системні промпти, можливості агентів, маршрути даних, ланцюжки інструментів і точки прийняття рішень. Харденінг має включати не лише сервери й контейнери, а й налаштування моделі, обмеження інструментів, політики контексту, ізоляцію сесій, фільтри виводу, журналювання дій агента та контроль зберігання даних (data retention). Моніторинг має відстежувати не лише помилки й атаки на інфраструктуру, а й підозрілі промпти, незвичні витяги з бази знань, спроби обходу політик, зростання вартості запитів, дрейф поведінки та аномальні дії агентів.

Приватні LLM: корисний варіант, але не панацея

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

Проте локальна LLM сама по собі не робить систему безпечною.

Якщо модель має доступ до погано класифікованих документів, якщо RAG побудований без урахування прав доступу, якщо агенти отримують надмірні привілеї, якщо промпти й відповіді зберігаються без політики зберігання (retention), якщо немає моніторингу й тестування, то локальне розміщення просто переносить ризик усередину периметра. Іноді це навіть створює хибне відчуття безпеки. Компанія думає, що «дані не йдуть назовні», але не контролює, хто всередині організації може отримати до них доступ через ШІ-інтерфейс.

Тому локальні та приватні LLM потрібно розглядати як архітектурний інструмент, а не як універсальний захист. Вони особливо корисні, коли поєднуються з класифікацією даних, IAM, сегментацією, журналюванням, DLP, безпечним RAG, контролем постачання моделей, регулярною оцінкою та зрозумілою моделлю відповідальності.

Від оцінки ризиків до впровадження контролів

Для багатьох організацій природний перший крок — оцінка безпеки ШІ. Потрібно зрозуміти, де ШІ вже використовується, які дані обробляються, які постачальники залучені, чи є RAG, чи є агенти, які API підключені, які права делегуються, як побудовані логи, які вимоги застосовуються, і які ризики є найбільш критичними.

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

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

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

Що має містити зріла програма безпеки ШІ

Зріла програма безпеки ШІ починається з видимості. Компанія має розуміти, які ШІ-сценарії вже існують: публічні сервіси, внутрішні асистенти, RAG-системи, агенти, copilot-функції, моделі в продуктах, ШІ в SOC, розробленні, аналітиці, підтримці клієнтів або юридичній роботі.

Після цього з’являється можливість класифікувати ризики: які сценарії зачіпають персональні дані, комерційну таємницю, код, фінансові процеси, критичну інфраструктуру, регульовані галузі або рішення з істотним впливом на людину. Потім потрібно оцінити архітектуру — модель, дані, доступи, інтеграції, логи, постачальників, права агентів, RAG-контур, контроль виводу та процеси експлуатації.

Наступний шар — практичні контролі. До них належать обмеження доступу, перевірка джерел даних, фільтрація й валідація введення та виведення, ізоляція інструментів, роздільні права читання й запису, підтвердження людиною для високоризикових дій, безпечні налаштування MCP та API, захист секретів, журналювання, моніторинг, сценарії реагування на інциденти (incident playbooks), а також регулярне тестування.

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

Консультативний підхід замість ілюзії повної автоматизації

Ринок ШІ-безпеки швидко наповнюється інструментами: сканерами, фреймворками для red teaming, наборами тестів, обмежувачами (guardrails), засобами оцінки моделей, рішеннями для моніторингу, платформами стратегічного управління й системами збирання доказів. Ці інструменти справді корисні. SANS Secure AI Blueprint, наприклад, побудований навколо трьох напрямів — захист ШІ, безпечне використання ШІ та управління ШІ, підкреслюючи, що впровадження ШІ часто рухається швидше, ніж захисні контролі.

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

Тому правильна дорожня карта безпеки ШІ не має виглядати як лінійний список задач, які можна повністю віддати на аутсорсинг або автоматизувати однією платформою. Більш зрілий підхід — консультативний супровід. У такій моделі зовнішні експерти допомагають компанії формувати архітектурну рамку, проводити моделювання загроз, перевіряти дизайн, визначати пріоритети, пов’язувати технічні ризики з бізнес-контекстом, валідовувати рішення, оцінювати відповідність застосовним практикам і допомагати CISO, CTO, CEO або власнику продукту приймати обґрунтовані рішення.

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

Висновок: від разових перевірок до керованої програми

З моменту виходу нашої попередньої статті безпека ШІ помітно змінилася. LLM стали частиною реальних бізнес-процесів. RAG, ШІ-агенти, MCP і корпоративні інтеграції розширили поверхню атаки. Прямі й непрямі ін’єкції промптів, витоки даних, ризики ланцюга постачання, слабкі місця RAG, надмірна автономність агентів і недостатній моніторинг стали практичними проблемами, а не лише темами для досліджень. OWASP, NIST, ISO/IEC, SANS і EU AI Act сформували більш зрілий набір орієнтирів, але водночас показали: одну універсальну інженерну або регуляторну структуру для всіх ШІ-систем створити неможливо. Потрібне поєднання стратегічного управління, архітектури, контролів, тестування та експлуатації.

Для H-X Technologies це означає природний розвиток підходів. Якщо раніше базове завдання полягало в тому, щоб пояснити ризики ШІ й показати, чому ними потрібно управляти, то тепер акцент зміщується до оцінки, впровадження та супроводу. У фокусі — захищена архітектура, безпека даних, локальні або обмежені LLM для чутливих сценаріїв, харденінг ШІ-інфраструктури, контроль RAG, безпека агентів і MCP, моніторинг, стратегічне управління, а також консультативна підтримка для керівників та команд.

У найближчі роки ШІ глибше входитиме в критичні бізнес-процеси. ШІ-агенти отримають більше повноважень. Регуляторне й договірне навантаження посилиться. Стратегічне управління ШІ стане частиною корпоративного управління, а безпека ШІ дедалі тісніше інтегруватиметься з безпекою застосунків, хмар, даних, IAM, SOC, SIEM, DLP, DevSecOps і комплаєнсом.

Тому H-X розвиває напрям оцінки та впровадження безпеки ШІ: від моделювання загроз і перевірки RAG до безпеки агентів, MCP, приватних LLM, моніторингу та управлінських контролів. Наше завдання — допомагати клієнтам використовувати ШІ без втрати контролю над даними, доступами та бізнес-ризиками.

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

Впроваджуєте LLM, RAG, ШІ-агентів, MCP-інтеграції або приватні моделі? Лише плануєте? Або вже впровадили й зіткнулися з проблемами? Обговоріть із H-X Technologies задачі безпеки ШІ — ми допоможемо зрозуміти, які дані та дії потрібно взяти під контроль, які ризики перевірити першими і які заходи безпеки впровадити без зайвої бюрократії.