Заборона на зовнішні API — це не заборона на віддалену роботу. Це різні речі, і плутати їх коштує бізнесу зайвих обмежень там, де їх не повинно бути.
⚡ Коротко
- ✅ Головна ідея: VPN-тунель і виклик до хмарного AI-API — це принципово різні речі, заборона другого не означає заборону першого.
- ✅ Corporate VPN ≠ Consumer VPN: це не про зміну геолокації, а про створення приватного "коридору" у вашу внутрішню мережу.
- ✅ Архітектура без компромісів: співробітник → зашифрований тунель → внутрішній сервер → локальна LLM. Жодного пакета даних не залишає вашу інфраструктуру.
- 🎯 Ви отримаєте: розуміння, як поєднати сувору політику безпеки з реальною потребою у віддаленому доступі — без компромісів в жодну зі сторін.
- 👇 Нижче — детальні пояснення, схеми та відповіді на практичні питання
📚 Зміст статті
- 📌 Чому "без зовнішнього API" не означає "без віддаленого доступу"
- 📌 Що таке VPN і чим Corporate VPN відрізняється від звичного "VPN для Netflix"
- 📌 Як віддалений доступ вписується в архітектуру self-hosted рішення
- 📌 Хто відповідає за налаштування — ви чи ваш IT-відділ
- 📌 Скільки це коштує додатково і від чого залежить ціна
- ❓ Часті питання (FAQ)
- ✅ Висновки
Чому "без зовнішнього API" не означає "без віддаленого доступу"
Уявіть ситуацію: ваша компанія працює в критичній інфраструктурі, юридичній сфері або фінансах. Політика безпеки чітка — жодні дані не покидають вашу мережу, жодні виклики до зовнішніх хмарних AI-сервісів. Це логічне й обґрунтоване рішення, часто закріплене не просто внутрішнім регламентом, а вимогами регулятора чи договірними зобов'язаннями перед клієнтами. Але у вас є співробітники, які працюють віддалено, їздять у відрядження, хворіють вдома з ноутбуком під рукою, або просто хочуть перевірити документ ввечері замість того, щоб чекати ранку в офісі. Питання: чи означає заборона на зовнішні API, що вони назавжди прив'язані до офісного крісла?
Поширена помилка
Коли компанія формулює вимогу "жодних зовнішніх API", в голові часто виникає спрощена картина: "усе має залишатися в чотирьох стінах офісу, а значить і співробітники теж". Це логічний, але помилковий висновок. Він виникає тому, що обидва сценарії — "дані йдуть назовні" і "людина підключається ззовні" — містять слово "зовнішній", і мозок автоматично об'єднує їх в одну категорію ризику.
Насправді ж мова йде про два зовсім різних поняття:
- Куди йдуть ваші дані — чи потрапляють вони на сервери стороннього вендора (OpenAI, Google, будь-який SaaS), де вони обробляються поза вашим контролем, зберігаються за чужою політикою реtenції, і теоретично можуть використовуватися для тренування чужих моделей
- Звідки підключається співробітник — з якої фізичної точки він встановлює з'єднання з вашою системою: з офісного столу, з дому, з готельного номера в іншому місті
Це незалежні один від одного параметри, і саме тут криється джерело плутанини. Місце розташування людини під час підключення ніяк не впливає на те, чи покидають дані вашу інфраструктуру після підключення. Можна мати систему, яка ніколи, за жодних обставин, не звертається до жодного зовнішнього API — і при цьому давати доступ співробітникам з будь-якої точки світу, якщо правильно побудувати мережевий периметр навколо цієї системи.
Різниця приблизно та сама, що між "хто заходить у будівлю банку" і "куди банк відправляє гроші клієнтів". Це два окремі питання безпеки, які вирішуються різними інструментами і не повинні змішуватися в одну вимогу.
Публічний API до хмарного сервісу vs приватний тунель до власної інфраструктури
Щоб остаточно зняти уявне протиріччя, варто розглянути обидва сценарії детально — що саме відбувається з даними в кожному з них.
Виклик до хмарного AI-API. Коли система звертається до стороннього провайдера — наприклад, надсилає запит до OpenAI чи будь-якого іншого хмарного AI-сервісу — відбувається наступне: фрагмент документа або запит користувача пакується в HTTP-запит і відправляється на сервери, які фізично належать і керуються цим провайдером. Там запит обробляється на чужих потужностях, чужим програмним забезпеченням, за правилами, які диктує сам провайдер, а не ваша компанія. Дані на якийсь момент часу фізично залишають вашу інфраструктуру і опиняються під юрисдикцією та політикою іншої організації. Саме цей сценарій, і тільки він, забороняють суворі політики безпеки на кшталт "жодних зовнішніх API".
VPN-тунель співробітника до вашого сервера. Це принципово інша дія. Коли співробітник підключається через VPN, не відбувається жодного виклику до стороннього сервісу обробки даних. Натомість створюється зашифрований "коридор" між пристроєм співробітника і вашим власним сервером — тим самим, на якому і так зберігаються документи та працює локальна модель. Весь трафік цим коридором іде безпосередньо до вашої інфраструктури і назад. Жодна третя сторона не отримує доступу до вмісту цього трафіку, не обробляє його і навіть не бачить його в розшифрованому вигляді — VPN-провайдер (якщо це не власний сервер компанії) бачить у кращому випадку факт з'єднання, але не його вміст.
Тобто заборона першого сценарію логічно ніяк не поширюється на другий. Це два різні напрямки руху даних:
- У першому випадку дані рухаються назовні, до чужої інфраструктури
- У другому — людина рухається (умовно) всередину, до вашої власної інфраструктури
Їх часто плутають саме через слово "зовнішній", яке інтуїтивно здається однаковим в обох формулюваннях — хоча технічно це протилежні за напрямком процеси. Розуміння цієї різниці і є тим фундаментом, на якому будується вся архітектура безпечного віддаленого доступу, яку ми розберемо в наступних розділах.
Що таке VPN і чим Corporate VPN відрізняється від звичного "VPN для Netflix"
Більшість людей чули про VPN у контексті "подивитися Netflix США" або "обійти регіональну блокировку сайту". Це справедливо, але це лише один з можливих сценаріїв використання VPN — і зовсім не той, що потрібен бізнесу. Плутанина між цими двома сценаріями часто заважає нетехнічним керівникам зрозуміти, чому VPN взагалі розглядається як рішення для суворих вимог безпеки — адже "VPN для Netflix" асоціюється радше з обходом обмежень, ніж із захистом даних.
Consumer VPN: зміна геолокації
Коли ви в Києві вмикаєте VPN "США", ваш трафік не йде напряму до сайту, який ви відвідуєте. Замість цього він спочатку потрапляє на проміжний сервер VPN-провайдера десь у Нью-Йорку, і вже звідти йде далі в інтернет. Будь-який сайт, який ви відвідуєте, бачить IP-адресу цього проміжного сервера — і думає, що ви фізично знаходитеся там, а не в Києві.
Мета такого VPN — приховати або підмінити вашу реальну локацію під час серфінгу звичайного публічного інтернету. Кінцева точка маршруту — завжди загальнодоступний сайт чи сервіс, який в принципі відкритий для будь-кого в світі. VPN тут виконує роль "маски", а не "ключа від замкнених дверей".
Corporate VPN: тунель у закриту мережу
Corporate VPN вирішує абсолютно інше завдання. Його мета — не приховати, де ви знаходитесь, а дати вам доступ туди, куди звичайний інтернет-користувач взагалі не має доступу: у внутрішню, закриту мережу компанії, яка в принципі не видима з публічного інтернету.
Тут немає "проміжного сервера в іншій країні", який маскує вашу локацію. Натомість є пряме зашифроване з'єднання між вашим пристроєм і конкретним сервером компанії. Цей сервер зазвичай навіть не має публічної IP-адреси — тобто до нього фізично неможливо достукатися звичайним запитом з інтернету, яким би не був ваш браузер чи локація. Єдиний спосіб потрапити туди — мати правильний ключ доступу (сертифікат або конфігурацію), яку компанія видала конкретно вам.
Consumer VPN vs Corporate VPN: порівняння
| Критерій | Consumer VPN | Corporate VPN |
|---|---|---|
| Мета | Приховати/підмінити геолокацію | Дати доступ до закритої внутрішньої мережі |
| Точка призначення | Публічний інтернет (Google, Netflix, будь-які сайти) | Конкретний внутрішній сервер компанії |
| Видимість сервера ззовні | Не застосовується — йдеться про публічні сайти | Сервер часто взагалі не має публічної IP — невидимий для звичайного інтернету |
| Хто може підключитися | Будь-хто, хто оплатив підписку на сервіс | Тільки той, кому видано персональний ключ доступу |
| Типовий користувач | Приватна особа | Співробітник компанії |
Ця таблиця показує загальну картину, але всередині категорії Corporate VPN теж є вибір — зокрема, між різними протоколами. Якщо цікаво детальне порівняння WireGuard і OpenVPN для бізнесу, ми розібрали це в окремій статті.
Аналогія: "віртуальний кабель в офіс"
Найпростіше уявити Corporate VPN так: ви вдома підключаєте віртуальний мережевий кабель прямо в офісну мережу. Ваш ноутбук технічно "телепортується" всередину офісу — ви бачите ті самі внутрішні ресурси, до яких мали б доступ, сидячи за робочим столом: внутрішні сервіси, спільні папки, а в нашому випадку — інтерфейс AI-асистента на внутрішній адресі сервера.
При цьому весь інший ваш інтернет-трафік (пошта, звичайні сайти, соціальні мережі) через цей "кабель" не йде — тільки той трафік, що призначений для внутрішнього сервера компанії. Це називається split-tunneling, і саме так, як правило, і налаштовують Corporate VPN — щоб не перевантажувати внутрішній канал компанії зайвим трафіком і не сповільнювати звичайний перегляд інтернету співробітником.
Важливий нюанс: на відміну від Consumer VPN, де мета — виглядати "звідкись ще", у Corporate VPN геолокація співробітника взагалі не має значення. Хоч з Києва, хоч з готелю в іншому місті — результат один: пряме, контрольоване з'єднання з внутрішнім сервером компанії, без жодного проміжного посередника, що обробляє чи бачить дані.
Як віддалений доступ вписується в архітектуру self-hosted рішення
Тепер зберемо все разом і подивимось, як це виглядає на рівні реальної архітектури self-hosted AI-асистента — не абстрактно, а покроково, від моменту, коли співробітник відкриває ноутбук вдома, до моменту, коли він отримує відповідь на екрані.
Шлях запиту співробітника
Співробітник (вдома / у відрядженні)
│
│ 1. Вмикає VPN-клієнт
▼
Зашифрований тунель (WireGuard)
│
│ 2. Тунель встановлено до внутрішньої мережі компанії
▼
Внутрішній сервер компанії (10.x.x.x)
│
│ 3. Запит потрапляє на askyourdocs.internal
▼
┌─────────────────────────────────┐
│ Веб-інтерфейс (Spring Boot) │
│ Локальна LLM (Ollama) │
│ База документів (pgvector) │
└─────────────────────────────────┘
│
│ 4. Обробка відповіді — БЕЗ звернень назовні
▼
Відповідь тим самим тунелем → співробітнику
- Співробітник вмикає VPN-клієнт на своєму пристрої (вдома, у відрядженні — будь-де, локація не має значення)
- Встановлюється зашифрований тунель до внутрішньої мережі компанії — з цього моменту пристрій співробітника технічно "перебуває" всередині офісної мережі
- Співробітник відкриває браузер і заходить на внутрішню адресу сервера (наприклад, внутрішній DNS-псевдонім на кшталт
askyourdocs.internal) — точнісінько так само, як робив би це з робочого місця в офісі - Запит потрапляє на внутрішній сервер, де крутиться вся система — веб-інтерфейс, локальна LLM, база документів. Усі ці компоненти фізично розташовані на одному сервері або в одній внутрішній мережі компанії
- Локальна модель обробляє запит і формує відповідь без жодного звернення назовні — пошук по документах, векторний пошук, генерація тексту моделлю відбуваються локально, без жодного HTTP-запиту за межі периметра
- Відповідь тим самим зашифрованим тунелем повертається співробітнику — той самий "коридор", яким прийшов запит
На жодному з цих кроків дані не покидають периметр компанії. Немає моменту, коли фрагмент документа чи запит співробітника опиняється на сервері стороннього провайдера — весь маршрут, від першого до останнього кроку, залишається всередині мережі, яку контролює сама компанія.
Чому це критично саме для клієнтів із суворими вимогами
Для звичайного бізнесу різниця між "хмарним" і "self-hosted" рішенням часто зводиться до питання зручності — трохи довше налаштування заради трохи більшого контролю. Але для певних галузей це не питання зручності, а питання відповідності регуляторним і внутрішнім вимогам безпеки, недотримання яких має цілком конкретні наслідки:
- Критична інфраструктура — витік технічної документації, регламентів обслуговування чи схем систем може мати наслідки далеко за межами репутаційних втрат. У цій галузі часто діють окремі стандарти кібербезпеки (наприклад, IEC 62443 для промислових систем управління), які прямо регламентують ізоляцію мереж з критичними даними
- Юридична сфера — конфіденційність клієнтських документів часто закріплена договірно (NDA, умови представництва), а не просто бажана як хороша практика. Передача фрагментів документів клієнта стороннньому AI-провайдеру без явного дозволу може становити порушення цих договірних зобов'язань
- Фінанси — регуляторні вимоги до обробки даних клієнтів (залежно від юрисдикції — це може бути GDPR у Європі чи галузеві стандарти на кшталт PCI DSS для платіжних даних) зазвичай прямо забороняють передачу персональних чи фінансових даних третім сторонам без окремого дозволу чи договору про обробку даних
Зверніть увагу: наведені приклади регламентів ілюструють загальний контекст галузі, а не є юридичною консультацією щодо відповідності вашій конкретній ситуації — точну відповідність варто перевіряти з вашим compliance-відділом чи юристом.
Для таких компаній архітектура "все залишається всередині периметру, доступ — тільки через контрольований тунель" — це не додаткова опція, а базова умова, за якої рішення взагалі можна розглядати. Саме тому self-hosted підхід з VPN-доступом існує не як компроміс між безпекою і зручністю, а як спосіб отримати обидві речі одночасно: повний контроль над даними і повноцінний віддалений доступ для команди.