Коли IT-компанія вирішує виходити за кордон, перші питання зазвичай звучать так: де зареєструвати компанію, як знайти офіс, кого найняти і скільки коштуватиме локальний бухгалтер.
Юридичні питання часто залишають «на потім».
І це може бути дорогою помилкою.
Тому що вихід на новий ринок — це не просто відкриття ще однієї юридичної особи. Компанія фактично заходить у нове правове середовище, де по-іншому можуть працювати правила оподаткування, захисту персональних даних, укладення договорів, IP, реклами, ліцензування та роботи з локальними партнерами.
Особливо це стосується технологічного бізнесу.
Один і той самий SaaS-продукт може продаватися в Україні, ЄС, Казахстані, Кенії чи Південній Африці. Але юридична модель його роботи в кожній із цих країн може відрізнятися.
Тому перед виходом на новий ринок варто пройти не один юридичний чекліст, а послідовно відповісти на кілька базових запитань.
Перша помилка — автоматично вважати, що для роботи в іншій країні потрібно реєструвати місцеву юрособу.
Не завжди.
У деяких випадках бізнес може продавати свої послуги або SaaS-продукт із уже наявної компанії. В інших — знадобиться дочірня компанія, філія або інша форма локальної присутності.
Все залежить від бізнес-моделі.
Наприклад, зовсім по-різному виглядатимуть ситуації, коли компанія:
Тому перше питання має звучати не:
«Де зареєструвати компанію?»
а:
«Яку присутність ми реально плануємо мати в цій країні?»
Саме від цього вже залежить структура.
Наступне питання — податки.
І тут важливо не звести все до ставки корпоративного податку.
Для міжнародного IT-бізнесу потрібно окремо проаналізувати:
Останній пункт особливо важливий.
Компанія може не мати локальної юридичної особи, але її фактична діяльність у країні за певних обставин може створити податкову присутність.
Наприклад, ризик може виникнути через локальних співробітників, агентів, офіс або характер діяльності представників компанії.
Тому схема:
«Ми не реєструємо компанію — отже, місцевих податків немає»
не працює як універсальне правило.
Для класичного SaaS відповідь часто може бути негативною.
Але все змінюється, якщо продукт працює у регульованій сфері.
Наприклад:
Причому назва продукту сама по собі нічого не вирішує.
Наприклад, компанія може називати себе FinTech, але з юридичного погляду бути:
Тому правильний алгоритм:
Business model → Regulatory classification → Licence → Compliance requirements.
Спочатку потрібно зрозуміти, що саме робить продукт з юридичного погляду, і тільки після цього перевіряти ліцензійні вимоги.
Це один із пунктів, який особливо легко недооцінити.
У компанії вже може бути GDPR compliance, Privacy Policy і стандартні Data Processing Agreements.
Але це не означає, що цих документів автоматично достатньо для нового ринку.
У різних країнах діють власні правила захисту персональних даних.
Наприклад, у Південній Африці діє POPIA, у Кенії — Data Protection Act, а в країнах Центральної Азії діють власні режими захисту персональних даних.
Так, між ними є багато спільного.
Але відрізнятися можуть:
Тому для міжнародної компанії правильна модель виглядає приблизно так:
Global Privacy Framework + Local Gap Assessment.
Не потрібно щоразу будувати privacy compliance з нуля. Але й просто копіювати європейську політику в нову країну — погана стратегія.
Це питання варто поставити ще до запуску продукту.
Наприклад:
Користувач знаходиться в Казахстані.
Компанія зареєстрована в Україні.
Основний cloud — у ЄС.
Резервні копії — в іншому регіоні.
До системи мають доступ розробники з кількох країн.
Чи відповідає така архітектура місцевому законодавству?
Відповідь залежатиме від конкретної юрисдикції та категорії даних.
Саме тому data localisation і cross-border data transfers — це вже не тільки питання юристів із privacy.
Це питання product architecture.
Якщо юридичні обмеження виявити після запуску, змінювати технічну архітектуру може бути значно дорожче…
Далі буде.
Підписуйтесь на наші канали у соціальних мережах:
Зв'яжіться з нами: business@avitar.legal
Віолетта Лосєва
,
