Уявіть: ви керуєте юридичною фірмою з 40 юристів, в базі — 15 000 договорів і конфіденційних угод. Хтось пропонує вам систему, яка за секунди знайде потрібний документ і відповість на запит. Звучить ідеально. Але одне уточнення змінює все: щоб це запрацювало, всі ваші договори потрібно вивантажити на сервери американської компанії.
Чи комфортно вам із цим?
Саме це питання — де фізично обробляються ваші документи і хто до них має доступ — визначає вибір між двома підходами до розгортання RAG-системи (RAG, Retrieval-Augmented Generation — технологія, яка дає AI-асистенту можливість відповідати на запити, спираючись на вашу корпоративну базу знань).
З одного боку — хмарний RAG: швидкий старт, жодних серверів, все обробляється у провайдера. З іншого — self-hosted RAG (або on-premise RAG): модель і дані на вашій власній інфраструктурі, повний контроль, але вища складність.
Ця стаття дасть практичну відповідь без DevOps-жаргону. Не «що таке RAG» — для цього є наш вступний матеріал. Тут — бізнес-рішення: коли self-hosted справді необхідний, коли хмара достатня, і що обирають компанії 20–200 людей без власної IT-команди.
Два способи запустити RAG — в чому принципова різниця
Перш ніж порівнювати ціни та безпеку, важливо зрозуміти, що саме відрізняє ці два підходи на практиці, а не в теорії.
Хмарний RAG: ваші документи обробляються на серверах провайдера
У хмарній моделі ви завантажуєте документи до сервісу (наприклад, через OpenAI API, Azure OpenAI, Amazon Bedrock або спеціалізований RAG-сервіс). Сервіс перетворює ваші тексти у векторні представлення (embeddings), зберігає їх у своїй базі і використовує для відповідей на запити.
Для вас це виглядає просто: завантажив документи, підключив до інтерфейсу, AI відповідає. Технічно — за лаштунками провайдера відбувається складна обробка, за яку він несе відповідальність.
Що це означає практично: – Ваші документи (або їхні фрагменти) фізично передаються на сервери провайдера – Провайдер зазвичай гарантує, що не використовує ваші дані для навчання моделей — але ці гарантії прописані в договорі, а не вбудовані технічно – Зупинка сервісу або зміна умов провайдером безпосередньо впливає на вашу роботу
Self-hosted RAG: модель і дані залишаються на вашій інфраструктурі
При self-hosted підході весь стек розгортається на вашому обладнанні або у вашому приватному хмарному оточенні. LLM-модель (наприклад, Llama, Mistral або Qwen) запускається локально, векторна база зберігається на вашому сервері, всі запити обробляються всередині вашої мережі.
Дані фізично не покидають ваш контур — це принципова відмінність, а не маркетингова обіцянка.
Що це означає практично: – Потрібен сервер із достатньою обчислювальною потужністю (або GPU для великих моделей) – Потрібна людина, яка налаштує і буде підтримувати систему – Ви повністю контролюєте дані, але й повністю відповідаєте за надійність системи
Гібридна модель: embeddings у хмарі, документи вдома
Це третій варіант, про який рідко говорять конкуренти, але який є реальною практикою для багатьох компаній. Архітектура виглядає так: зовні відправляються тільки запити або векторні представлення (anonymized embeddings), а самі документи та LLM-модель залишаються локально.
Приклад: ви використовуєте хмарну API для перетворення тексту у вектори (це не розкриває змісту документів), але сам пошук і генерація відповідей відбуваються на вашому сервері. Або навпаки — відкриті корпоративні документи (регламенти, загальні FAQ) обробляються в хмарі, а конфіденційні договори залишаються on-premise.
Гібрид дозволяє знайти баланс між зручністю хмари і захистом критичних даних. Детальніше про вибір архітектури — у статті про RAG vs fine-tuning.
Коли self-hosted — не перевага, а необхідність
Є ситуації, коли вибір на користь self-hosted RAG — це не питання переваг, а питання відповідності вимогам. Хмарний варіант просто не підходить.
GDPR і EU-клієнти: коли хмара юридично проблематична
Якщо ваша компанія працює з клієнтами або партнерами з Євросоюзу і обробляє їхні персональні дані, ви потрапляєте під дію GDPR (General Data Protection Regulation). Цей регламент вимагає, зокрема, що персональні дані резидентів ЄС зберігаються та обробляються або всередині ЄС, або у країні з адекватним рівнем захисту.
Це означає, що якщо ваш RAG-провайдер — американська компанія (OpenAI, AWS, Google), яка обробляє дані на серверах у США без відповідних угод про передачу даних (SCCs, Standard Contractual Clauses), ви потенційно порушуєте GDPR.
Що є персональними даними? Набагато більше, ніж здається: імена та контакти клієнтів у договорах, медична інформація, фінансові дані фізичних осіб, навіть IP-адреси. Якщо ваша корпоративна база містить такі дані — проконсультуйтесь із юристом щодо відповідності хмарної обробки. Self-hosted або EU-hosted рішення прибирає цю проблему автоматично.
Медицина, фінанси, юридичний бізнес: регуляторний контекст України
Три галузі, де вибір deployment-моделі часто не є вашим особистим рішенням — він продиктований регулятором.
Медицина: медичні дані пацієнтів в Україні захищені Законом «Про захист персональних даних» і галузевими підзаконними актами. Відправка медичних записів на зовнішні сервери без належних договорів і заходів безпеки — ризик не лише репутаційний, але й юридичний.
Фінанси: банки, страховики, інвестиційні компанії в Україні регулюються НБУ і НКЦПФР. Ці регулятори мають вимоги до зберігання і обробки фінансових даних клієнтів. Деякі типи даних взагалі не можуть оброблятися на зовнішніх платформах без спеціальних дозволів.
Юридичний бізнес: адвокатська таємниця — конституційно захищений принцип. Якщо ваші клієнтські справи, стратегії захисту або конфіденційні угоди потрапляють у хмару без гарантій ізоляції — це ризик, який жоден відповідальний юрист не прийме.
Компанії з EU-замовниками: що вони очікують від вашої IT-безпеки
Якщо ви виграли контракт із польською, німецькою або британською компанією, очікуйте, що на якомусь етапі з’явиться питання: де обробляються наші дані і які у вас заходи безпеки?
Великі EU-компанії все частіше включають у контракти з аутсорсерами вимоги щодо data residency (де фізично зберігаються дані) і security compliance (SOC 2, ISO 27001 або просто internal security policy). Self-hosted RAG або managed private cloud є сильним аргументом у перемовинах: «наша AI-система не відправляє ваші дані нікуди».
Ризик vendor lock-in: платіжна залежність від зарубіжних API
Це специфічна для України тема, яку жоден конкурент не підіймає.
Ваш бізнес-процес залежить від OpenAI API. Що відбувається, якщо: – OpenAI обмежує доступ для певних регіонів або типів карт (вже траплялось у 2022–2023) – Міжнародні платіжні системи знову обмежують транзакції з України (непрогнозований ризик) – Нестабільний інтернет або DDoS-атаки виводять із ладу зовнішні API на кілька годин (реальна UA-специфіка) – Провайдер змінює умови або підвищує ціни — і у вас немає альтернативи
Self-hosted RAG повністю усуває цю залежність. Система працює навіть без інтернету, якщо потрібно.
Коли хмарний RAG — правильний вибір
Self-hosted — не завжди краще. Є ситуації, де хмарний RAG є оптимальним і навіть єдино розумним рішенням.
Немає IT-команди або DevOps — хмара дозволяє запустити за 2–3 тижні
Розгортання і підтримка self-hosted RAG потребує технічної компетенції: налаштування сервера, вибір і запуск моделі, конфігурація векторної бази, моніторинг, оновлення. Якщо у вас немає людини, яка може взяти на себе цю відповідальність, — хмарний RAG запускається набагато швидше і без технічного болю.
Для компанії з 30 людей, де IT — це один адміністратор на аутсорсі, хмара не просто зручніша. Вона може бути єдиним реалістичним варіантом на початку.
Документи не є конфіденційними — хмара достатньо безпечна
Не всі корпоративні документи однаково чутливі. Якщо ваша база знань — це публічні регламенти, відкриті прайс-листи, загальні інструкції для персоналу, FAQ для клієнтів — відправляти їх у хмару цілком безпечно.
Питання не в тому, «чи безпечна хмара взагалі», а в тому, «що саме ми туди відправляємо». OpenAI і Google мають сертифікації безпеки (SOC 2, ISO 27001) і підписують угоди про обробку даних (DPA). Для нечутливих корпоративних документів цього більш ніж достатньо.
Потрібно тестувати і змінювати підхід — хмара гнучкіша на старті
На початку впровадження RAG мало хто точно знає, яка архітектура підійде для конкретної бази документів. Хмарний варіант дозволяє швидко спробувати різні підходи: змінити розмір фрагментів документів (chunking), спробувати іншу embedding-модель, перейти від одного провайдера до іншого.
Self-hosted вимагає набагато більше зусиль на кожну зміну конфігурації. Для пілотного проекту — хмара як полігон є розумним вибором навіть для компаній, які планують перейти на self-hosted після підтвердження цінності.
Обсяг запитів низький — хмара дешевша до певного порогу
Хмарні API тарифікуються за використанням. Якщо ваша система отримує до 5 000–10 000 запитів на місяць, хмарні витрати можуть бути значно нижчими, ніж капітальні витрати на сервер і зарплата адміністратора. Точку беззбитковості розглянемо детально нижче.
Порівняльна таблиця: self-hosted vs хмарний RAG за 8 критеріями
| Критерій | Хмарний RAG | Self-hosted RAG |
|---|---|---|
| Вартість старту | Низька: $0–500 на налаштування, оплата за використання | Висока: $3 000–8 000 на сервер + $1 000–3 000 на налаштування |
| Вартість масштабування | Зростає лінійно з кількістю запитів; може стати дорогим при великих обсягах | Фіксована інфраструктура; вартість запиту падає зі зростанням обсягу |
| Конфіденційність даних | Дані передаються провайдеру; захист — на рівні договору | Дані не покидають вашу інфраструктуру — технічна гарантія |
| Відповідність GDPR | Вимагає DPA з провайдером; ризик при обробці EU-даних | Відповідність значно простіша при EU-hosted або on-premise |
| Технічні вимоги | Мінімальні: достатньо розробника або технічного менеджера | Потрібен DevOps або системний адміністратор; GPU для великих моделей |
| Час до запуску | 2–4 тижні для пілоту | 4–10 тижнів для production-ready системи |
| Гнучкість налаштування | Обмежена параметрами провайдера; модель змінити не можна | Повна: вибір моделі, архітектури, розміру контексту |
| Ризик залежності від провайдера | Високий: зміна умов, обмеження доступу, зростання цін | Відсутній після розгортання |
Скільки це коштує — орієнтири для українського бізнесу
Цифри нижче — ринкові орієнтири, не комерційна пропозиція. Конкретні розрахунки залежать від обсягу вашої бази документів, кількості користувачів і вимог до якості.
Хмарний RAG: що входить у підписку і де прихований ріст витрат
Базовий хмарний RAG-пілот для компанії 30–50 людей: – API-витрати (OpenAI GPT-4o або Anthropic Claude): орієнтовно $150–400/міс при помірному навантаженні (2 000–8 000 запитів/міс) – Векторна база (Pinecone, Weaviate Cloud або аналог): $25–100/міс залежно від обсягу – Налаштування та інтеграція: разова оплата підряднику $1 500–4 000
Де ростуть витрати непомітно: якщо ваші документи великі (наприклад, 500-сторінкові звіти) або кількість запитів зростає — рахунок за API може подвоїтися або потроїтися за квартал. Слід закладати не фіксовану суму, а механізм моніторингу витрат.
Self-hosted: одноразові витрати на сервер + обслуговування
Типова конфігурація self-hosted RAG для компанії 20–100 людей: – Сервер з GPU (наприклад, RTX 4090 або A100 — залежно від розміру моделі і кількості паралельних запитів): $3 000–8 000 (RTX 4090) або $15 000–25 000 (A100) — одноразово – Open-source LLM-модель (Llama 3, Mistral, Qwen): безкоштовно – Векторна база (Qdrant, Milvus, pgvector): безкоштовно або до $100/міс у managed варіанті – Налаштування та розгортання: $3 000–8 000 разово – Обслуговування: 4–8 годин/міс системного адміністратора
Сервер RTX 4090 дозволяє запускати моделі до 32 млрд параметрів у стиснутому вигляді (4-bit quantization) з прийнятною якістю для більшості бізнес-задач. Для enterprise-масштабу з сотнями паралельних запитів потрібен A100/H100 — але це вже інший рівень інвестицій.
Точка беззбитковості: коли self-hosted стає дешевшим
Орієнтовний розрахунок для бізнесу без власного GPU:
| Показник | Хмарний | Self-hosted (RTX 4090) |
|---|---|---|
| Початкові витрати | $2 000 (налаштування) | $11 000 (сервер + налаштування) |
| Щомісячні витрати | $300–500 (API + база) | $100–200 (електроенергія + адмін) |
| Точка беззбитковості | — | ~18–24 місяці |
Якщо ваш обсяг запитів малий і ви не плануєте масштабувати систему протягом 2 років — хмара дешевша. Якщо обсяг великий або у вас є вимоги до конфіденційності — self-hosted окупається швидше.
Managed self-hosted: третій варіант — ваші дані, чужа інфраструктура
Окремий підхід, який часто ігнорують: managed self-hosted або private cloud. Ви не купуєте власний сервер — натомість орендуєте виділену (не shared) інфраструктуру в EU-дата-центрі. Ваші дані фізично ізольовані від інших клієнтів провайдера, але технічне обслуговування — на ньому.
Орієнтовна вартість: $500–2 000/міс залежно від конфігурації. Це проміжний варіант між хмарним (дешевше, але менше контролю) і self-hosted (дорожче, але повний контроль).
Матриця рішення — 5 запитань для власника компанії
Дайте відповідь на кожне питання чесно — і ваш вибір стане очевидним.
1. Чи є у вашій базі персональні дані клієнтів, медична, юридична або фінансова інформація?
Якщо так — self-hosted або managed private cloud. Хмарний варіант вимагає детального юридичного аналізу і, найімовірніше, виключення цих документів із RAG-системи.
2. Чи є у вас IT-фахівець, який може адмініструвати сервер?
Якщо ні (або є лише аутсорс-адміністратор на часткову зайнятість) — починайте з хмари або managed self-hosted. Self-hosted без відповідальної технічної людини перетвориться на проблему, а не рішення.
3. Яку приблизну кількість запитів до системи ви очікуєте на місяць?
До 10 000 запитів/міс — хмара, найімовірніше, дешевша. Від 30 000–50 000 запитів/міс і вище — розрахунок TCO (Total Cost of Ownership, сукупна вартість володіння) часто показує перевагу self-hosted.
4. Чи є у вас EU-клієнти з явними або неявними вимогами до GDPR-відповідності?
Якщо так — або self-hosted, або EU-hosted хмарне рішення (наприклад, Azure EU регіони з підписаним DPA). Американські провайдери без відповідних угод юридично ризиковані.
5. Чи критична для вас незалежність від зовнішніх сервісів?
Якщо ваш бізнес-процес не може дозволити собі «сервіс недоступний 2 години» або ви маєте досвід проблем з міжнародними платежами — self-hosted з резервним доступом до мережі є стратегічно правильнішим рішенням.
Що таке managed self-hosted і чому це компроміс
Цей варіант заслуговує окремого пояснення, тому що він закриває найпоширенішу заперечення проти self-hosted: «ми не хочемо купувати і підтримувати власний сервер».
У managed self-hosted схемі провайдер (або AI-партнер, такий як Directoria) розгортає всю RAG-інфраструктуру у виділеному хмарному оточенні — наприклад, у AWS Frankfurt або Azure Netherlands. Ваші дані фізично ізольовані: жоден інший клієнт не має доступу до вашого оточення.
При цьому технічне обслуговування, оновлення моделей, моніторинг — все це на стороні провайдера. Ви отримуєте API-доступ або готовий інтерфейс.
Що ви отримуєте: – Дані залишаються в EU (або у вибраній юрисдикції) – Відповідність GDPR значно простіша – Немає потреби в DevOps-команді – Технічне обслуговування — не ваша проблема
Що втрачаєте порівняно з on-premise self-hosted: – Певний рівень довіри до провайдера все ж необхідний – Вищі місячні витрати порівняно з власним сервером у довгостроковій перспективі
Для більшості компаній 20–100 людей з EU-клієнтами managed self-hosted є оптимальним балансом між захистом даних і операційною простотою.
3 помилки при виборі deployment-моделі
«Self-hosted = дешевше» — до певного обсягу це неправда
Найпоширеніша помилка — вважати, що self-hosted автоматично економить гроші. Насправді на малих обсягах і без власної технічної команди self-hosted може виявитися дорожчим: сервер, налаштування, адміністрування, оновлення. OpenAI API за $300/міс може бути дешевшим, ніж сервер за $5 000 + IT-підрядник за $500/міс.
Порівнювати потрібно не ціну підписки vs ціну заліза — а TCO за 12 місяців, включаючи всі витрати: залізо, налаштування, обслуговування, час вашої команди.
«Хмара ненадійна» — OpenAI API має uptime 99.9%+, проблема інша
Хмарні провайдери — надійніші, ніж більшість корпоративних серверних кімнат. OpenAI, Azure, Google Cloud мають redundancy, автоматичні failover, цілодобовий моніторинг. Ваш власний сервер у серверній кімнаті офісу — найімовірніше, ні.
Реальна проблема хмари не в надійності сервісу, а в залежності від зовнішнього контуру: платіжні обмеження, зміна умов, припинення роботи на ринку. В українських реаліях це актуальніше, ніж downtime провайдера.
«Ми вирішимо це пізніше» — міграція з хмари у self-hosted коштує дорожче старту
Почати в хмарі і потім мігрувати — реалістичний план. Але якщо ви вже побудували великий корпус векторних представлень документів і налаштували інтеграції під конкретного провайдера, міграція займає час і гроші.
Краще запитати про deployment-модель на старті, навіть якщо ви починаєте з хмари: проектуйте архітектуру так, щоб міграція у майбутньому була простішою — наприклад, використовуйте стандартизовані формати зберігання і open-source векторні бази, які працюють і в хмарі, і on-premise.
Докладніше про вибір векторної бази і архітектуру зберігання — у статті «Векторні бази даних для бізнесу».
Як ми підходимо до вибору deployment-моделі в Directoria
Перш ніж рекомендувати клієнту хмару або self-hosted, ми проводимо структурований аналіз. Ось як це виглядає на практиці.
Крок 1: Аудит документів і даних. Ми аналізуємо, які саме документи плануються для RAG-системи: чи є серед них персональні дані, медична або фінансова інформація, конфіденційні угоди. Це визначає базові вимоги до deployment-моделі ще до будь-яких технічних рішень. Докладніше про послугу — на сторінці AI-аудиту.
Крок 2: Оцінка регуляторних вимог. Ми уточнюємо, чи є у клієнта EU-замовники, чи підпадає компанія під галузеве регулювання (медицина, фінанси, право), чи є явні або неявні вимоги до GDPR-відповідності.
Крок 3: Розрахунок TCO на 12 місяців. Для кожного сценарію (хмара / self-hosted / managed self-hosted / гібрид) ми рахуємо повну вартість: інфраструктура, налаштування, обслуговування, ліцензії, час команди. Це дає реальне порівняння, а не маркетингові цифри.
Крок 4: Рекомендація та обґрунтування. На основі аналізу даємо конкретну рекомендацію з поясненням trade-offs. Більшість компаній 20–100 людей отримують один з трьох варіантів: хмарний пілот → потім вирішити про self-hosted; managed self-hosted одразу; або гібридна архітектура для баз з різним рівнем чутливості даних.
Крок 5: Пілот з фіксованою ціною. Рекомендовану модель реалізуємо у форматі пілоту за 2–4 тижні. Пілот вирішує конкретну задачу (наприклад, пошук по базі договорів або відповіді на запити підтримки) — щоб ви побачили реальну цінність перед масштабуванням. Автоматизація документообігу з RAG-системою детально описана на сторінці послуги.
Часті питання
Чи можна спочатку запустити хмарний RAG, а потім перейти на self-hosted?
Так, і це поширена практика. Хмарний пілот дозволяє швидко перевірити цінність RAG-системи для вашого бізнесу без великих інвестицій. Після підтвердження цінності — розраховуєте TCO і вирішуєте. Важливо: на стадії пілоту проектуйте архітектуру без жорсткої прив’язки до провайдера — використовуйте стандартні формати, відкриті специфікації. Тоді міграція займе тижні, а не місяці.
Які моделі підходять для self-hosted RAG без GPU-кластера?
Для невеликих компаній без серйозного GPU реалістичні варіанти: Llama 3.2 3B або 8B, Mistral 7B, Qwen 2.5 7B у стиснутому вигляді (4-bit або 8-bit quantization). Ці моделі запускаються на сучасному сервері з 16–24 ГБ відеопам’яті (RTX 4090) і дають прийнятну якість для більшості корпоративних задач. Для складніших документів і вищих вимог до точності — потрібні більші моделі (32B+) і відповідне залізо.
Чи є self-hosted RAG варіант для компанії без IT-відділу?
Якщо у вас немає штатного технічного фахівця — пряме self-hosted підходить лише при залученні зовнішнього підрядника на налаштування та підтримку. Альтернатива — managed self-hosted: ви отримуєте переваги ізоляції даних, але технічне обслуговування повністю на підряднику. Щомісячний контракт на підтримку self-hosted системи — від 8 000–15 000 ₴/міс, залежно від складності.
Хмарний RAG і GDPR — чи це сумісно?
Сумісно, але з умовами. Провайдер повинен підписати з вами Угоду про обробку даних (Data Processing Agreement, DPA). Сервери повинні бути розташовані в ЄС або у країні з адекватним рівнем захисту даних. У вашій базі не повинно бути особливих категорій персональних даних (медичних, біометричних) без додаткових заходів захисту. Azure, Google Cloud і AWS мають EU-регіони і стандартні DPA — і теоретично сумісні з GDPR при правильному налаштуванні. Але «теоретично» і «пройде перевірку регулятора» — різні речі. Якщо GDPR-відповідність критична — проконсультуйтесь із юристом.
Що таке «managed self-hosted» і скільки це коштує?
Managed self-hosted — це виділена приватна інфраструктура (не shared cloud), яку провайдер або AI-партнер розгортає та обслуговує для вас. Ваші дані фізично ізольовані, технічна підтримка — на провайдері. Орієнтовна вартість: від $500 до $2 000/міс залежно від розміру бази, кількості запитів і вибору провайдера. Для компаній, яким важлива ізоляція даних, але немає IT-команди — оптимальний баланс.
Як зрозуміти, що self-hosted RAG окупається?
Орієнтир: порівняйте місячні витрати на хмарний RAG (API + база + підтримка) з амортизованою вартістю self-hosted (сервер / 36 місяців + обслуговування). Якщо хмарний варіант дорожчий — self-hosted окупиться. Крім прямих витрат, рахуйте непрямі: скільки коштує компанії 1 година простою при недоступності зовнішнього API? Скільки вартує потенційне регуляторне порушення при обробці конфіденційних даних у хмарі? При правильному обліку цих ризиків ROI self-hosted часто виявляється кращим, ніж показує пряме порівняння витрат.
Висновок
Вибір між self-hosted і хмарним RAG — це не технічне, а бізнес-рішення. Технологія однакова в обох випадках. Питання в тому, де вона запускається, хто за неї відповідає і чи відповідає це вашим вимогам до безпеки, регуляторного середовища і операційної спроможності.
Більшість компаній 20–100 людей без власної DevOps-команди правильно стартують з хмарного пілоту — і переходять на self-hosted або гібрид після підтвердження цінності та зростання обсягів. Виняток — юридичні, медичні, фінансові компанії і бізнеси з EU-клієнтами: для них self-hosted або managed private cloud часто є обов’язковою умовою, а не перевагою.
Перший практичний крок — AI-аудит за 5 днів. За цей час ми аналізуємо вашу документну базу, оцінюємо регуляторні вимоги і готуємо рекомендацію по архітектурі з розрахунком TCO на 12 місяців: хмара, self-hosted або гібрид — з конкретними цифрами для вашого кейсу. Замовити AI-аудит.
