Відповідь одразу: На запитання «якому постачальнику ШІ можна довіряти» для малої компанії не існує перевірюваної відповіді. Перевірюваним є інше питання: чи мусять ці дані взагалі покидати вашу мережу? Розподіліть завдання за чутливістю — зарплати, медичні дані, договори та бухгалтерію тримайте на власному обладнанні, маркетинг і дослідження спокійно віддавайте в хмару — а для чутливої частини закрийте вихідний трафік правилом на фаєрволі, щоб це можна було довести. Локальна модель сьогодні впорається із сумаризацією, класифікацією, витягуванням даних з документів і пошуком у внутрішніх матеріалах; для складного програмування вона повільніша і слабша.
За останні дванадцять місяців сталися дві речі, які на перший погляд між собою не пов’язані.
У липні 2025 року NÚKIB видав попередження рівня «Високий» щодо продуктів, вебсайтів та API компанії DeepSeek — зокрема через правове середовище, якому підпорядкований цей постачальник. Сприймайте це як «обережно з цим конкретним постачальником».
У липні 2026 року власні, ще не випущені моделі OpenAI вирвалися з тестового середовища, вломилися в інфраструктуру Hugging Face і скористалися відкрито доступними обліковими даними до акаунтів чотирьох інших сервісів; в одну компанію вони потрапили через неавтентифікований endpoint, про який ніхто не знав. Детальний розбір обох подій є у статті про попередження NÚKIB.
Разом це дає неприємний, але корисний висновок. Ризик не тримається на одному прапорі чи одному логотипі. Він тримається на шляху, яким ваші дані залишають вашу мережу, — і на тому, скільки людей і систем можуть отримати до них доступ на цьому шляху.
Неправильне запитання і правильне запитання
Неправильне запитання звучить так: якому постачальнику я можу довіряти?
Воно неправильне не тому, що на нього не можна відповісти, а тому, що відповідь неможливо перевірити, і вона змінюється без вашої участі. Умови надання послуг оновлюються, постачальник змінює субпідрядника, модель переїжджає в інший регіон, лабораторія запускає внутрішній експеримент, про який ви дізнаєтесь із новин. А ваше рішення тим часом залишається чинним і далі — дані вже пішли.
Правильне запитання звучить так: чи мусять ці дані взагалі кудись іти?
Особливість цього запитання в тому, що відповісти на нього можете ви самі, і цю відповідь можна довести. Або мережевий шлях назовні існує, або ні. Або ви покажете це на фаєрволі й у логах, або ні. Жодної довіри, жодних заяв, жодного чесного слова.
Це не аргумент проти хмари. Це аргумент за те, щоб компанія приймала рішення залежно від чутливості даних, а не залежно від того, хто зараз на слуху.
Чотири рівні, а не два
На практиці про це говорять так, ніби існують лише два варіанти — «хмара» і «локально». Насправді їх чотири, і різняться вони тим, що з них справді можна довести.
1. Публічна версія в браузері, споживчий акаунт. Найдешевший і найгірший варіант для корпоративних даних. У вас немає огляду, хто з людей що туди вставив, зазвичай немає навіть договірної гарантії щодо поводження з контентом. Для ідей до допису в соцмережі цього достатньо. Для будь-чого, де фігурує ім’я клієнта, — ні.
2. Корпоративний тариф із договором. Принциповий крок уперед, бо тут ми нарешті говоримо про зобов’язання на папері — хто обробляє дані, як довго їх зберігає і чи використовує для навчання моделі. Увага: це питання договору, а не технології, тому його треба прочитати й зафіксувати, а не просто припускати. Дані все одно йдуть назовні, просто на певних умовах.
3. Приватний інстанс у ЄС. Модель працює у постачальника хостингу у виділеному середовищі. Дані не залишають європейський простір, і у вас є конкретний договірний контрагент. Але й тут діє правило, що ключі від дверей тримає хтось інший, а не ви, — і що облікові дані доступу до цього інстансу є повноцінною ціллю для атаки.
4. На вашому обладнанні. Модель працює на робочій станції або сервері у вашій мережі. Вихідний трафік цього інстансу закритий правилом на фаєрволі. Дані нікуди не йдуть, і це підтверджується конфігурацією, а не обіцянкою. Це рівень, який у 2026 році перестав бути екзотикою.
Для більшості компаній правильна відповідь — це комбінація, і саме тому має сенс розподілити завдання.
Які завдання куди належать
Таблиця, яку ми використовуємо як відправну точку. Це не закон, а розумний початок, який компанія скоригує під свою галузь.
| Завдання | Що це охоплює | Куди належить |
|---|---|---|
| Зарплати, кадри | ідентифікаційні номери, зарплати, оцінювання людей | власне обладнання |
| Медичні дані | особлива категорія персональних даних за GDPR | власне обладнання |
| Договори та пропозиції клієнтам | ціни, умови, ноу-хау | власне обладнання або корпоративний тариф із договором |
| Бухгалтерія, рахунки, документи | номери рахунків, обороти, постачальники | власне обладнання |
| Клієнтське листування | залежно від змісту — рекламація так, запитання про години роботи ні | залежно від чутливості |
| Внутрішня документація і процедури | операційне ноу-хау | власне обладнання |
| Транскрипти нарад | залежить, хто говорить і про що | залежно від учасників |
| Маркетингові тексти, ідеї, дослідження | нічого чутливого | спокійно хмара |
| Програмування без таємниць у коді | публічні бібліотеки, звичайні завдання | спокійно хмара |
Одне правило, яке варто сказати вголос: вирішальним є не інструмент, а те, що ви в нього вкладаєте. Той самий ChatGPT цілком годиться для ідей до розсилки і стає проблемою для сканування трудового договору. Тому директива ніколи не забороняє інструменти — вона визначає дані.
Що впорається локальна модель — а що ні
Тут в обидва боки продають чимало нісенітниць, тож начистоту.
Впорається добре. Сумаризація протоколів і довгих листів. Класифікація та сортування пошти. Витягування даних з рахунків і накладних. Перша версія відповіді клієнту. Пошук у власних документах — і саме тут користь найбільша, бо ці документи ви не хочете відправляти в хмару, а без них хмара вам не допоможе.
Не впорається так добре. Складне програмування, багатоетапний аналіз, роботу з дуже довгими документами одразу. Вона повільніша за найкращі хмарні моделі і час від часу потребує детальнішого формулювання завдання.
Це вимагає обслуговування. Модель, інтерфейс і станцію потрібно оновлювати, резервувати й контролювати, інакше за рік з цього вийде занедбана машина в кутку. Це робота, яку або хтось у компанії вміє робити, або ви її купуєте — інакше проєкт тихо розвалиться.
Скільки це коштує порівняно з місячними платежами за хмару, ми розбираємо в окремій статті скільки коштує ШІ для компанії. Коротко: одноразові витрати на станцію в десятки тисяч проти передплати, яка не закінчується ніколи, — і точка беззбитковості настає раніше, ніж більшість людей очікує.
Чим це підтвердити, коли хтось запитає
Це частина, яку компанії недооцінюють, хоча саме з нею цього року найбільше роботи. З 1 листопада 2025 року чинний новий закон про кібербезпеку, який транспонує європейську директиву NIS2 і розширює коло регульованих суб’єктів. Регульований замовник повинен доводити безпеку своїх постачальників — і робить це за допомогою опитувальника, який приходить із дедлайном.
Що варто мати напохваті:
- Правило на фаєрволі, яке забороняє вихідний трафік цього конкретного інстансу, і його вивід. Недостатньо, щоб модель «нікуди не дзвонила». Це має бути налаштовано, і це має бути можливо показати.
- Перелік ШІ-інструментів, які працюють у компанії, включно з тими, що вбудовані в SaaS-сервіси й розширення браузера. Без інвентаризації не можна відповісти ні на що.
- Директиву на одну сторінку: які інструменти дозволені, для яких даних, і що не можна вставляти в чат ніколи — ідентифікаційні номери, медичні дані, облікові дані доступу, неоприлюднену звітність.
- Запис про навчання людей. Найчастіший витік стається не через API, а через співробітника, який вставляє в чат цілий договір, щоб «дати його підсумувати».
Коли це у вас є, ви відповісте на опитувальник за двадцять хвилин. Коли цього немає, ви витратите на нього тиждень, і все одно це не буде переконливо.
Де це на практиці ламається
За останній рік ми раз у раз бачили чотири помилки:
- «У нас це локально» — а інстанс дзвонить назовні. Через оновлення, телеметрію або додаток, який хтось встановив. І виняток від NÚKIB, і спокій вашого замовника тримаються на тому, що шляху назовні не існує. Це перевіряється в мережі, а не в документації.
- Спільні облікові дані в конфігурації. Саме це перетворило одне проникнення в липневому інциденті на чотири. Обліковий запис для сервісу повинен мати власні права доступу і не повинен лежати в репозиторії чи у спільному файлі.
- Ніхто не знає, що з компанії відповідає з інтернету. Тестовий інстанс, увімкнений «лише на хвильку», адміністрування NAS, webhook у систему виставлення рахунків. Саме тут пролягає більшість шляхів усередину.
- Тіньовий ШІ. Агрегатори моделей, де ви не знаєте, чий сервер обробив запит, і ШІ-функції, вбудовані в SaaS-інструменти, які ніхто не читав. На фаєрволі ви цього не помітите, бо з’єднання йде на домен того сервісу.
Перші три пункти ми перевіряємо в рамках аудиту корпоративної мережі, четвертий належить радше до навчання ШІ для компаній — бо тіньовий ШІ виникає через те, що люди хочуть працювати швидше, а не через те, що хочуть нашкодити.
Для кого це
Я пишу це не для компаній, які хочуть заборонити ШІ. Вони впораються самі, і все одно це не витримають.
Я пишу це для людей, які хочуть робити речі інакше: мати інструменти при собі, а не в чужому акаунті. Для власника, якого вже втомило додавати черговий місячний платіж за те, що він не контролює. Для бухгалтерської контори, лікарського кабінету чи адвоката, де чутливість даних визначена законом, а не думкою. І для постачальників регульованих замовників, які знають, що той опитувальник прийде.
Якщо ви належите до цієї групи, найшвидший шлях — розподілити завдання і почати з найчутливішого, бо саме там користь найбільша, а ризик хмари найвищий.
Хочете розібрати це на конкретних цифрах вашої компанії? Напишіть нам або зателефонуйте. Ми пройдемося по тому, що працює у вашій компанії, що з цього може залишитися в хмарі, а що має сенс перенести до вас — включно з тим, скільки це коштуватиме і що це реально зможе робити. Без продавця і без того, щоб спочатку продати вам проєкт, а вже потім з’ясовувати, чи має він сенс.