Організації, що будують рішення на хостинговій мовній моделі, отримують від постачальника модель, навчену з урахуванням безпеки, і платформу, але залишаються відповідальними за застосунок навколо неї. Microsoft, Cloud Security Alliance та EU AI Act кожен розподіляють роботу між постачальником моделі та стороною, що її розгортає, використовуючи різну термінологію й різну юридичну вагу. Ця нотатка порівнює всі три підходи й пропонує практичний розподіл для поширеного випадку моделі, що використовується через API. Вона доповнює статтю Як Anthropic тестує Claude силами червоної команди і що залишає вам, яка розглядає сторону постачальника на одному опублікованому прикладі.
Передумови: хмарна модель, поширена на ШІ
Хмарна модель спільної відповідальності закріплює кожен засіб контролю за постачальником або клієнтом залежно від типу послуги: програмне забезпечення як послуга (SaaS), платформа як послуга (PaaS) або інфраструктура як послуга (IaaS). І Microsoft, і Cloud Security Alliance (CSA) поширюють цю ідею на генеративний ШІ. Таке поширення змінює більше термінологію, ніж логіку: що нижче в стеку будує клієнт, то більше засобів контролю йому належить.
Моделі постачальників
Microsoft: платформа, застосунок і використання
Модель спільної відповідальності за ШІ від Microsoft описує застосунок із ШІ як три рівні: платформа ШІ, застосунок ШІ та використання ШІ. Рівень платформи надає модель через API і містить систему безпеки, що фільтрує небезпечні вхідні та вихідні дані. Рівень застосунку — це інтерфейс, яким користується користувач, із прив’язкою до даних (grounding), плагінами й конекторами даних, і він потребує власної системи безпеки застосунку. Рівень використання охоплює те, як люди користуються цією можливістю, і Microsoft вказує на засоби контролю ідентифікації та доступу, політики прийнятного використання й навчання користувачів. [1]
Те, яка частка кожного рівня належить клієнту, залежить від типу розгортання. Сторінка зазначає, що обов’язки різняться між SaaS, PaaS та IaaS, і рекомендує починати з пропозицій SaaS, як-от Copilot, переходити до сервісів PaaS, як-от Azure OpenAI Service, лише тоді, коли готові можливості не підходять, а створення власних моделей залишати організаціям із глибокою експертизою. Сторінка додає, що ці настанови мають ілюстративний характер, використовуються в сенсі управління й не змінюють жодної угоди з Microsoft. [1]
Microsoft: розширення для агентів
Друга сторінка Microsoft стосується агентів, які вона відрізняє від звичайної моделі, бо агент діє без схвалення людиною кожного кроку, планує й працює циклами, має пам’ять, власну ідентичність і може взаємодіяти з іншими агентами. Вона додає три рівні: оркестрація агента, інструменти й дії, а також пам’ять і стан. У її матриці відповідальності клієнт у випадку PaaS зберігає за собою інструкції та обсяг дій агента, дозволи для кожного інструмента й схвалення людиною дій зі значним впливом, тоді як середовище виконання й платформа оркестратора належать Microsoft. [2]
Сторінка перелічує обов’язки, що завжди залишаються за клієнтом: дані, ідентифікація й мінімальні привілеї, авторизація дій, нагляд людини, прийнятне використання та управління. Вона також зазначає, що автономність ніколи не зменшує відповідальності. [2]
Cloud Security Alliance: пропозиція 2023 року
У дописі в блозі від 28 липня 2023 року один із фелоу CSA запропонував модель із трьома сторонами: постачальник сервісу ШІ, користувач сервісу ШІ, що створює застосунок, і підприємство чи кінцевий користувач цього застосунку. Згідно з пропозицією, постачальник IaaS надає інфраструктуру й базові моделі, тоді як користувач відповідає за навчання, перевірку даних, фільтрування промптів і безпеку застосунку; у випадку PaaS користувач надає контекст і безпеку застосунку; у випадку SaaS користувач керує прив’язкою до даних, фільтруванням промптів і захистом інтелектуальної власності. Допис подає це як пропозицію, що розмежовує обов’язки, а не як стандарт. [3]
Право: EU AI Act розподіляє обов’язки за ролями
EU AI Act розподіляє обов’язки за ролями. Згідно з FAQ до настанов Європейської комісії, постачальник моделі ШІ загального призначення — це суб’єкт, що розробляє модель або замовляє її розроблення і випускає її на ринок під власною назвою. Обов’язки постачальника включають технічну документацію, документацію для подальших розробників про можливості й обмеження, політику дотримання авторського права та публічний підсумок навчального вмісту. Ці обов’язки застосовуються з 2 серпня 2025 року. Моделі, щодо яких презюмується системний ризик, тобто з обчисленнями для навчання на рівні 10^25 операцій з рухомою комою або вище, мають додаткові обов’язки, зокрема змагальне тестування й засоби кіберзахисту. [4]
Той самий FAQ називає 2 серпня 2026 року датою, з якої до цих постачальників застосовується примусове виконання, зокрема штрафи, а 2 серпня 2027 року — кінцевим терміном для моделей, випущених на ринок до 2 серпня 2025 року. Там також зазначено, що подальший розробник, який модифікує модель, стає постачальником лише за виняткових обставин, як-от використання понад третину початкових обчислень для навчання, тож більшість дотренувань (fine-tuning) не змінює ролі постачальника. [4]
Розгортальники, тобто організації, що використовують системи ШІ, мають окремий набір обов’язків. Аналіз юридичної фірми від 24 липня 2026 року називає обов’язками розгортальників з 2 серпня 2026 року розкриття діпфейків і повідомлення осіб про розпізнавання емоцій та біометричну категоризацію. Для систем високого ризику він називає компетентний нагляд людини, повідомлення осіб про використання ШІ та консультації з працівниками. [6] Сторінка з часовою шкалою Комісії додає, що розгортальники мають забезпечувати нагляд людини й моніторинг і повідомляти про серйозні інциденти після виходу систем на ринок. [5]
Відтермінування Digital Omnibus
Терміни для систем високого ризику перенесено. Сторінка з часовою шкалою Комісії називає 2 грудня 2027 року для систем високого ризику в чутливих сферах, як-от біометрія, працевлаштування та правоохоронна діяльність, і 2 серпня 2028 року для систем високого ризику, вбудованих у регульовані продукти, і пов’язує це з Digital Omnibus on AI, який, за її описом, набирає чинності в липні 2026 року. [5] Аналіз Norton Rose Fulbright наводить ті самі дві дати й зазначає, що Omnibus опубліковано в офіційному віснику ЄС. [6] Отже, два незалежні джерела погоджуються, що відтермінування ухвалено, а не лише запропоновано. Обов’язки постачальників моделей загального призначення й наведені вище обов’язки щодо прозорості цими двома датами не переносяться.
Розподіл роботи, коли модель використовується через API
Для випадку PaaS, коли застосунок викликає хостингову модель, джерела підтримують наведений нижче розподіл. Рядки Microsoft відповідають описаним вище рівням платформи й застосунку; рядки про тестування граничних ризиків, системну документацію та канали розкриття вразливостей відображають обов’язки постачальників за настановами ЄС і практики, які публікують постачальники моделей. Таблиця є синтезом FireAI, а не текстом жодного з джерел.
| Сфера | Сторона постачальника | Ваша сторона |
|---|---|---|
| Поведінка моделі | Навчання безпеки та узгодження (alignment) моделі | Системний промпт і обмеження застосунку |
| Тестування ризиків | Тестування граничних ризиків самої моделі | Тестування вашого застосунку, зокрема його промптів, даних та інструментів |
| Платформа | Безпека платформи та базові фільтри вхідних і вихідних даних | Перевірки безпеки застосунку щодо вмісту, плагінів і конекторів |
| Документація | Системна картка й документація для подальших розробників | Її читання й фіксування того, яку модель і версію ви розгорнули |
| Дані та інструменти | Нічого понад договір щодо API | Дані RAG, інструменти, агенти та їхні дозволи |
| Вивід | Повертає згенерований текст | Подальша обробка виводу: перевірка, екранування, схвалення людиною |
| Експлуатація | Канал розкриття вразливостей для моделі | Журналювання, моніторинг і реагування на інциденти для застосунку |
| Люди | Умови політики використання | Ваша власна політика використання й навчання користувачів |
Дві сфери є спільними в точному сенсі. Перша — prompt injection: постачальник навчає модель протидіяти ін’єктованим інструкціям, а розгортальник обмежує те, чого може досягти ін’єктована інструкція, через дозволи інструментів і доступ до даних. Сторінка Microsoft про агентів описує такий самий розподіл, радячи клієнтам вважати отриманий вміст, вивід інструментів і повідомлення інших агентів недовіреними та ставити дії зі значним впливом під контроль. [2] Друга — конфіденційність даних: постачальник встановлює умови зберігання й навчання, а розгортальник вирішує, які дані взагалі потрапляють у промпт чи індекс пошуку.
Рекомендації
- Спершу визначте тип розгортання (SaaS, PaaS чи власний хостинг) і запишіть, які рядки наведеного вище розподілу належать організації.
- Тестуйте сторону розгортальника безпосередньо: системний промпт, дані для пошуку, дозволи інструментів і обробку виводу. Тестування моделі постачальником їх не охоплює.
- Перш ніж впроваджувати модель, прочитайте системну картку постачальника, його умови зберігання даних і навчання та знайдіть його канал розкриття вразливостей.
- Обмежуйте те, що може зробити ін’єктована інструкція: інструменти з мінімальними привілеями, обмежений доступ до даних і схвалення людиною незворотних дій.
- Вирішіть, які дані можуть потрапляти в промпти, і зберігайте журнали, достатні для відтворення інциденту.
- Навчальні матеріали про рамки й red teaming наведено в курсі FireAI University про рамки безпеки ШІ та red teaming.
Значення для FireAI
Локальний застосунок чи агент, що викликає API моделі, — це програма на Mac, і її адреси видно для FireAI. «Активність» показує, які програми виходили в мережу, а «Правила» дають змогу користувачу дозволити чи заблокувати програму або конкретну адресу. Це один засіб контролю на стороні розгортальника, на одному Mac. FireAI не перевіряє промптів, не оцінює виводу моделі, не виявляє prompt injection і не оцінює, чи виконує постачальник будь-які юридичні обов’язки.
Обмеження
- Сторінки Microsoft є настановами постачальника для продуктів Azure, самі себе описують як ілюстративні й не змінюють умов договору. Текст CSA — пропозиція 2023 року.
- Ця нотатка не є юридичною консультацією. Чи є організація постачальником, розгортальником або оператором системи високого ризику за EU AI Act, залежить від фактів, яких ця нотатка не оцінює, і національні органи можуть тлумачити Акт по-різному.
- Дати Digital Omnibus узято зі сторінки з часовою шкалою Комісії та одного аналізу юридичної фірми. Сам текст регламенту для цієї нотатки не переглядався.
- Таблиця для API є синтезом, і окремі постачальники в своїх умовах розміщують деякі рядки інакше.
Яке місце тут посідають FireAI та HisnLabs
Ваш бік межі охоплює те, що залишає Mac. FireAI показує це й дає вам вирішувати.
FireAI — це власний продукт HisnLabs: ШІ-фаєрвол, який працює безпосередньо на вашому Mac. Він показує простою мовою кожне з’єднання, яке встановлюють ваші застосунки, і дає вам вирішувати, що покидає ваш Mac, — його ШІ працює локально, тож ваш трафік ніколи не надсилається ні нам, ні будь-кому іншому. Команда дослідників безпеки HisnLabs — саме вона підтримує точність цих рішень: каталогізує, які домени є звичайною телеметрією, а які — справжнім сервісом, відстежує країну та мережу за з’єднанням і навчає локальну модель (функцію FireAI Pilot) на реальних шаблонах трафіку — і нічого з цього не покидає ваш Mac.
Ви можете почитати про технічні рішення, що лежать в його основі, або спробувати FireAI протягом 17 днів на сторінці FireAI від HisnLabs.