Кейс: SaaS-контракт из Кыргызстана: 9 ключевых пунктов

Ситуация: SaaS-стартап с заказчиком из Германии и пробелами в контракте

В конце 2025 года к нам обратилась бишкекская IT-компания — резидент ПВТ, разрабатывающая платформу для автоматизации HR-процессов в среднем бизнесе. Компания заключила годовой SaaS-контракт с немецким заказчиком на сумму около €180 000. Через четыре месяца после запуска заказчик направил претензию: в платформе произошёл инцидент с персональными данными сотрудников, и заказчик потребовал возмещения убытков, угрожая расторжением и публичным уведомлением надзорного органа в Германии.

Клиент обратился к нам с двумя вопросами. Первый — есть ли у заказчика основания для расторжения и взыскания убытков по условиям контракта. Второй — как защититься от повторения подобных ситуаций в будущих контрактах. Анализ выявил девять структурных уязвимостей в тексте действующего договора. Каждая из них могла стать точкой входа для претензий или судебного иска. Разбор этих уязвимостей и стал основой данного кейса.

Для понимания масштаба: немецкий заказчик ссылался одновременно на кыргызское право (применимое по контракту) и на GDPR, утверждая, что кыргызская компания как обработчик данных нарушила требования регламента. Это классическое противоречие в трансграничных SaaS-контрактах — контракт написан под одну юрисдикцию, а фактические обязательства вытекают из другой.

ПВТ-резидентство даёт экономию налоговой нагрузки около 80% против общего режима — именно поэтому большинство бишкекских IT-компаний, работающих на экспорт, выбирают этот статус. Но налоговые преимущества не решают контрактные риски: структура договора — отдельная задача, не зависящая от налогового режима.

Задача: что именно защищает (и не защищает) типовой SaaS-контракт?

Типовой SaaS-контракт, скачанный из открытого источника или адаптированный без юридического анализа, как правило, закрывает три очевидных блока: предмет договора, порядок оплаты и условия расторжения. Он не закрывает шесть менее очевидных блоков, каждый из которых при трансграничной сделке становится уязвимостью.

В анализируемом контракте отсутствовало соглашение об обработке данных (Data Processing Agreement, DPA) как отдельный документ или приложение. Стороны ограничились общей фразой о соблюдении «применимого законодательства о защите данных». Эта формулировка неработоспособна: она не определяет ни перечень обрабатываемых категорий данных, ни цели обработки, ни технические меры защиты, ни порядок уведомления при инцидентах.

Вторая уязвимость — отсутствие SLA (Service Level Agreement) с измеримыми параметрами. Контракт содержал общее обязательство «обеспечить доступность платформы», без указания процента uptime, окон технического обслуживания и порядка компенсации при нарушении уровня сервиса. Когда платформа упала на 11 часов в рабочее время, заказчик потребовал возмещения убытков — контракт не давал исполнителю ни защиты, ни чёткого регламента для ответа.

Третья уязвимость — неопределённость применимого права в части регуляторных требований. Контракт содержал оговорку о праве КР, но не разграничивал, какое именно право регулирует обработку персональных данных — кыргызское или право страны заказчика. При наличии немецкого субъекта данных GDPR применяется независимо от выбора права в контракте: это экстерриториальный регламент.

Пункт 1: применимое право — почему «право КР» недостаточно для трансграничного SaaS?

Выбор применимого права в SaaS-контракте с иностранным заказчиком — не формальность. Кыргызское гражданское право хорошо регулирует обязательственные отношения: заключение, исполнение, расторжение, ответственность. Но оно не регулирует GDPR, не охватывает стандарты кибербезопасности по NIS2 и не определяет, как обрабатывать запросы субъектов данных из ЕС.

Правильная конструкция для трансграничного SaaS выглядит так: кыргызское право регулирует коммерческую часть контракта (оплата, SLA, интеллектуальная собственность, ограничение ответственности), а отдельное DPA-приложение прямо указывает, что обработка персональных данных граждан ЕС осуществляется в соответствии с GDPR. Эти два блока не противоречат друг другу — они регулируют разные аспекты отношений.

Для заказчиков из США релевантна аналогичная конструкция: основной контракт — под кыргызским правом, DPA — с указанием стандартов CCPA (штат Калифорния) или SOC 2, если заказчик требует этот сертификат. Наличие таких оговорок не усложняет договор, а делает его исполнимым при возникновении претензий.

В анализируемом кейсе отсутствие DPA-приложения было использовано заказчиком как аргумент в пользу того, что кыргызская сторона не выполнила обязательства GDPR-процессора. Суд в Германии такой аргумент, как правило, принял бы: отсутствие DPA само по себе является нарушением GDPR при трансграничной передаче данных. Контракт пришлось срочно дополнять DPA-приложением в рамках переговоров об урегулировании претензии.

Пункт 2: SLA и uptime — как не отдать заказчику рычаг давления?

SLA — это не дополнительный документ «для больших компаний». Для SaaS-провайдера это основной инструмент управления ответственностью. Без SLA любой простой платформы становится основанием для претензий на полное возмещение убытков заказчика — без потолка и без регламента.

Стандартный SLA для B2B SaaS включает четыре элемента. Первый — целевой показатель uptime: как правило, 99,5% или 99,9% в месяц (за вычетом плановых окон обслуживания). Второй — определение «простоя»: не любая недоступность, а только та, которая подтверждена системой мониторинга провайдера или независимым инструментом. Третий — порядок компенсации: кредиты на счёт следующего периода, а не денежные выплаты. Четвёртый — исключения: форс-мажор, атаки типа DDoS, действия третьих лиц.

В анализируемом случае SLA отсутствовал полностью. Заказчик трактовал 11-часовой простой как «существенное нарушение» по Гражданскому кодексу КР и настаивал на расторжении с возвратом предоплаты. По кыргызскому праву существенность нарушения оценивает суд — без SLA у исполнителя не было объективного критерия, чтобы оспорить эту квалификацию. Наличие SLA с компенсацией в виде кредита за один день обслуживания закрыло бы претензию автоматически.

Практический вывод: SLA должен быть приложением к основному контракту, а не отдельным документом «по запросу». Заказчик подписывает его одновременно с основным договором — это снимает риск спора о том, является ли SLA обязательным для обеих сторон.

Пункт 3: ограничение ответственности — конкретные формулировки

Ограничение ответственности — самый коммерчески значимый пункт SaaS-контракта. Без него кыргызский провайдер несёт неограниченную ответственность за убытки заказчика, включая косвенные потери, упущенную выгоду и штрафы, наложенные на заказчика регулятором третьей страны.

Гражданский кодекс КР допускает договорное ограничение ответственности между предпринимателями. Для B2B SaaS стандартная конструкция: совокупная ответственность провайдера ограничена суммой платежей за 12 месяцев, предшествующих событию, повлёкшему убытки. Косвенные убытки, упущенная выгода, репутационный ущерб, штрафы регуляторов — прямо исключены.

Формулировка должна быть исчерпывающей. Недостаточно написать «ответственность ограничена суммой договора» — это порождает спор о том, что считать суммой договора (годовой платёж, остаток, всё когда-либо уплаченное). Чёткая ссылка на 12-месячный период до инцидента убирает любую неопределённость.

В анализируемом кейсе контракт содержал ограничение ответственности, но с оговоркой «кроме случаев грубой небрежности». Заказчик квалифицировал инцидент с данными как грубую небрежность — что открыло дорогу к требованиям без потолка. Формулировка «грубая небрежность» без её определения в контракте — классическая ловушка: её содержание будет толковать суд в пользу потерпевшей стороны.

Пункты 4–6: интеллектуальная собственность, конфиденциальность и порядок изменений

Пункт 4 — интеллектуальная собственность. В SaaS-контракте провайдер предоставляет лицензию на использование ПО, но не передаёт исходный код и не отчуждает права на платформу. Это базовое правило, которое часто нарушается размытыми формулировками. Фраза «заказчик получает все права на результаты работ» в контексте SaaS означает отчуждение — что юридически несовместимо с моделью подписки.

Контракт должен чётко разграничивать три категории: предсуществующая ИС провайдера (платформа, базовый код, алгоритмы), данные заказчика (остаются собственностью заказчика), кастомизации под заказчика (права определяются отдельно — либо провайдер сохраняет права с лицензией заказчику, либо происходит частичное отчуждение за дополнительное вознаграждение). В анализируемом кейсе этот раздел отсутствовал, что заказчик попытался использовать для обоснования права на исходный код модуля, разработанного специально под его нужды.

Пункт 5 — конфиденциальность. Стандартное NDA в составе контракта должно определять: что является конфиденциальной информацией, какой срок действия обязательства (как правило, 3–5 лет после окончания контракта), кто считается «получателем» (сотрудники, подрядчики, аффилированные лица), и в каких случаях раскрытие допустимо (требование суда или регулятора). Для IT-компании конфиденциальность — двусторонняя: заказчик также обязан защищать технические данные провайдера.

Пункт 6 — порядок изменений функциональности. SaaS-провайдер вправе обновлять платформу, но если обновление убирает функцию, на которую заказчик рассчитывал, возникает спор о существенном изменении предмета договора. Контракт должен определить: уведомление за сколько дней, какие изменения считаются «существенными» (требующими согласия), а какие — «улучшениями» (провайдер решает самостоятельно). В анализируемом кейсе этот пункт отсутствовал — заказчик ссылался на изменение интерфейса как на дополнительное основание претензии.

Travel Rule обязателен для всех VASP в Кыргызстане — без него лицензия под угрозой. Для SaaS-компаний, работающих в криптовалютном сегменте и планирующих получить VASP-лицензию Финнадзора, контрактная структура должна дополнительно учитывать требования к идентификации контрагентов и хранению данных о транзакциях. Подробнее — в материале IT-право и виртуальные активы в Кыргызстане: ПВТ и VASP.

Пункты 7–9: расторжение, арбитраж и экспортный контроль

Пункт 7 — расторжение и последствия. В SaaS-контракте различают три основания расторжения: по инициативе заказчика без нарушений (с уведомлением за 30–90 дней), по инициативе заказчика из-за нарушений провайдера (с правом на cure period — как правило, 30 дней для устранения нарушения), и расторжение по инициативе провайдера при неплатеже. Каждое основание влечёт разные последствия: возврат предоплаты, компенсация, порядок миграции данных заказчика.

Порядок миграции данных — отдельный критический элемент. Заказчик должен получить свои данные в машиночитаемом формате в течение разумного срока (как правило, 30–60 дней) после расторжения. Без этого пункта провайдер может столкнуться с иском о принудительном предоставлении данных и возмещении убытков от невозможности их использования. В анализируемом кейсе этот пункт отсутствовал, что существенно осложнило переговоры.

Пункт 8 — порядок разрешения споров. Для трансграничного SaaS государственный суд Кыргызстана — не оптимальный выбор: его решения не исполняются автоматически в большинстве стран ЕС. МТС при ТПП КР работает по регламенту ЮНСИТРАЛ, его решения исполняются в 172 странах по Нью-Йоркской конвенции 1958 года. Альтернатива — арбитраж в нейтральной юрисдикции (Стокгольм, Гонконг, Сингапур), если заказчик настаивает. Место арбитража влияет на место проведения слушаний, но не на применимое право — это разные параметры, которые нужно согласовывать отдельно.

Пункт 9 — экспортный контроль и санкционные оговорки. Для кыргызских IT-компаний, работающих с заказчиками из ЕС и США, санкционная оговорка стала обязательным элементом контракта после 2022 года. Заказчики из западных юрисдикций включают в договоры обязательства провайдера не использовать субподрядчиков из санкционных списков и не обрабатывать данные на инфраструктуре в странах под ограничениями. Несоблюдение этих условий может повлечь расторжение контракта заказчиком без какой-либо компенсации провайдеру. Для кыргызской компании, привлекающей субподрядчиков из России или Беларуси, это реальный операционный риск.

Резиденты ПКИ Кыргызстана при заключении SaaS-контрактов с иностранными заказчиками сталкиваются с теми же девятью уязвимостями. Налоговый режим (1–2% единого налога) не влияет на контрактные требования: структура договора определяется не режимом налогообложения, а типом отношений и юрисдикцией заказчика.

Решение БЕКЕМ: как был урегулирован спор и что изменили в контракте?

Работа по кейсу велась по двум направлениям одновременно: урегулирование текущей претензии немецкого заказчика и разработка новой контрактной документации для будущих сделок.

По претензии. Анализ инцидента показал, что утечки данных в техническом смысле не произошло: произошёл несанкционированный доступ к журналам активности, не содержавшим персональных данных в смысле GDPR. Это принципиальное разграничение позволило переквалифицировать инцидент из «нарушения безопасности данных» в «инцидент доступности сервиса». На этом основании мы провели переговоры с заказчиком: претензия была снята, стороны согласовали DPA-приложение, компенсацию в виде кредита на 30 дней обслуживания и продление контракта на льготных условиях.

По контрактной документации. Мы разработали пакет из трёх документов: основной SaaS-договор по кыргызскому праву, DPA-приложение с учётом GDPR-требований для ЕС-заказчиков, SLA-приложение с параметрами uptime 99,5%, окнами обслуживания и порядком кредитной компенсации. Дополнительно были структурированы разделы по ИС, конфиденциальности, порядку изменений и санкционной оговорке. Новый пакет прошёл согласование с немецким юридическим консультантом заказчика в течение двух недель.

Обратитесь к материалу об открытии банковского счёта для нерезидента в КР — этот вопрос возникает параллельно с контрактной структурой при выходе на зарубежных заказчиков: платёжный маршрут (SWIFT, корреспондентский счёт, банк в КР) нужно согласовывать до подписания договора, а не после получения первого инвойса.

По итогам работы клиент получил контрактную документацию, которую без изменений принял второй европейский заказчик — финская компания — в марте 2026 года. Юридическая часть переговоров заняла три рабочих дня вместо трёх недель, как это было с немецким заказчиком. Разница — в том, что документация была готова до начала переговоров, а не создавалась в их процессе.

Результат и выводы: что изменилось для клиента?

Количественный результат. Претензия немецкого заказчика на возмещение убытков в размере €45 000 была урегулирована без денежных выплат. Контракт был продлён на второй год. Экономия на судебных издержках и риске расторжения годового контракта составила, по консервативной оценке, не менее €150 000 с учётом потенциальной упущенной выручки второго года.

Системный результат. Компания перешла от разовой реакции на претензии к проактивной контрактной политике. Новый шаблон документации охватывает все девять пунктов, разобранных в этом кейсе, и адаптируется под конкретного заказчика за один-два рабочих дня. Это снизило юридические транзакционные издержки при заключении каждого нового контракта.

Структурный вывод для IT-компаний из Кыргызстана. SaaS-контракт с иностранным заказчиком — не стандартный договор оказания услуг. Он регулирует три разных слоя отношений: коммерческий (оплата, SLA, расторжение), регуляторный (защита данных, санкционный комплаенс) и технологический (ИС, доступ, интеграции). Каждый слой требует отдельной проработки, и ни один из них не закрывается типовым шаблоном из интернета.

Дополнительную сложность создаёт то, что кыргызские IT-компании часто работают одновременно с несколькими юрисдикциями — ЕС, США, СНГ. Требования к контракту для каждой из них различаются: не по базовой структуре, но по специфическим оговоркам. Решение — модульная контрактная документация с базовым шаблоном и юрисдикционными приложениями. Подробнее о регуляторной среде для цифровых проектов в КР — в материале аналитического раздела БЕКЕМ и на странице практики IT-право и виртуальные активы.

Читайте также о криптовалютном резерве Кыргызстана и законе 2025 года о государственном запасе — изменения в регулировании виртуальных активов непосредственно влияют на контрактную структуру для SaaS-компаний, работающих в криптосегменте.