SaaS Agreements: ключевые положения

SaaS Agreements: ключевые положения международных технологических контрактов Практическое руководство для технологических компаний и их клиентов

Главное

Международный SaaS-контракт — это не подписка на программный продукт. Это распределение рисков, обязанностей и ответственности в непрерывно меняющейся регуляторной среде.

Главный вопрос не в том, сколько стоят лицензии. Главный вопрос — сохраняет ли контракт коммерческий смысл через два-три года действия, когда меняются технологии, применимое право или модель обработки данных.

Поэтому эффективная работа с SaaS-соглашениями начинается с трёх проверок:

• Кто за что отвечает в цепочке обработки данных и перед регуляторами.
• Что произойдёт при остановке сервиса, утечке данных или смене провайдера.
• Где именно и по каким правилам будут разрешаться споры, если контракт перестанет работать.

Если эти три вопроса не решены на этапе построения договора, компания может получить не просто убытки, а полную потерю доступа к критически важной инфраструктуре или санкции регулятора.

Когда необходима глубокая проработка SaaS-соглашения

Глубокая контрактная работа требуется, если:

• технологическая компания выводит SaaS-продукт на рынок ЕС;
• корпоративный клиент приобретает облачное решение с обработкой чувствительных данных;
• сервис построен на публичном облаке с трансграничной передачей персональных данных;
• в продукт встроены компоненты искусственного интеллекта, подпадающие под EU AI Act;
• SaaS подлежит требованиям отраслевого регулирования (финансы, здравоохранение, критическая инфраструктура);
• обработка данных затрагивает несколько юрисдикций с различными правовыми режимами;
• подписывается Data Processing Agreement (DPA) как часть основного контракта;
• планируется exit или миграция от одного облачного провайдера к другому;
• обсуждается ограничение ответственности, которое может оставить заказчика без эффективного средства правовой защиты;
• SaaS-проект требует соблюдения DORA, NIS2 или кибер-стандартов ЕС.

Ошибка, которую совершают большинство сторон

Многие компании начинают с вопроса:

Какой SLA по доступности прописать?

Это неправильный первый вопрос.

Правильный вопрос:

Какая комбинация договорных механизмов обеспечит непрерывность бизнеса, законность обработки данных и реальную возможность переключиться на другого провайдера без катастрофических потерь?

Иногда ключевым оказывается не процент аптайма, а обязательство по портированию данных. Иногда — не размер штрафных баллов за простой, а право на досрочное расторжение при повторяющихся инцидентах. Иногда — не лимит ответственности, а исключения из него для нарушений data privacy. Международный SaaS-контракт требует не шаблона, а архитектуры рисков.

Шаг 1. Определить правовую природу предоставляемого решения

Прежде всего необходимо чётко понять: что именно предоставляется — услуга, лицензия или их гибрид. От этого зависят:

• интеллектуальная собственность;
• ответственность за качество;
• гарантии;
• налоговые последствия;
• возможность удержания права собственности.

Квалификация SaaS как услуги (service) в большинстве правопорядков ЕС означает, что заказчик не получает копию программы, а использует функциональность удалённо. Это снижает риски, связанные с исчерпанием прав, но переносит акцент на гарантии качества сервиса и непрерывность доступа.

Шаг 2. Зафиксировать модель развёртывания и трансграничную передачу данных

SaaS-решение может быть развёрнуто:

• в публичном облаке (AWS, Azure, GCP);
• в частном облаке заказчика;
• в гибридной инфраструктуре.

В каждом варианте критически важно определить:

• где физически размещаются данные (data residency);
• кто и из какой юрисдикции осуществляет техническую поддержку;
• происходит ли передача персональных данных в третьи страны, требующая механизмов защиты согласно GDPR (Standard Contractual Clauses, Binding Corporate Rules, adequacy decision).

Европейские регуляторы внимательно анализируют трансграничные потоки, и отсутствие в контракте ясного описания архитектуры передачи данных — самостоятельный комплаенс-риск.

Шаг 3. Выстроить работающее соглашение об уровне обслуживания (SLA)

SLA в международном контракте — это не только цифры доступности. Оно должно включать:

• методику расчёта доступности (исключая плановое техобслуживание);
• время реакции, время устранения, эскалацию;
• кредиты за простой (service credits), которые должны быть реальной компенсацией, а не номинальной скидкой;
• право на расторжение при хронически низком качестве;
• измеримые показатели производительности (latency, throughput);
• прозрачность мониторинга и право заказчика на независимый аудит качества.

Без права на экстренный выход и без обязанности провайдера содействовать миграции SLA не защищает бизнес заказчика.

Шаг 4. Оценить роли и обязательства по GDPR и Data Processing Agreement

SaaS-провайдер, обрабатывающий персональные данные, почти всегда выступает обработчиком (processor). Заказчик — контролёром (controller). Договор должен:

• чётко фиксировать предмет, цели, характер и сроки обработки;
• содержать перечень типов данных и категорий субъектов;
• возлагать на провайдера обязательство обрабатывать данные исключительно по документированным инструкциям;
• предусматривать предварительное согласие на привлечение суб-процессоров;
• гарантировать помощь в выполнении запросов субъектов данных и уведомлении об утечках;
• предусматривать удаление или возврат данных по окончании договора.

В ЕС DPA не является опциональным приложением — это обязательный элемент SaaS-контракта, перекос в котором может повлечь солидарную административную ответственность.

Шаг 5. Разобраться с правами на данные и интеллектуальной собственностью

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

• кому принадлежат данные, загружаемые клиентом (обычно — клиенту);
• кому принадлежат производные данные, аналитика, метаданные;
• может ли провайдер использовать обезличенные данные для улучшения продукта или обучения моделей ИИ;
• какие лицензии получает заказчик на интерфейс, интеграционные модули и документацию;
• обязательства провайдера не использовать данные клиента для конкурирующих продуктов.

В условиях развития EU Data Act право клиента на портирование данных между облачными провайдерами скоро станет императивным требованием, и контракт должен либо учитывать его, либо готовить стороны к неизбежному изменению.

Шаг 6. Проверить ограничение ответственности и его исключения

В SaaS типичный лимит ответственности провайдера — 12-месячная плата за сервис. Это может быть катастрофически низко. Стороны должны согласовать:

• исключения из лимита: нарушения конфиденциальности, data privacy, умысел, грубая неосторожность, нарушение прав интеллектуальной собственности;
• режим ответственности за действия субподрядчиков;
• индемнификацию в пользу заказчика по искам третьих лиц;
• ответственность за штрафы регуляторов, наложенные вследствие вины провайдера.

Слабое место многих SaaS-контрактов — ситуация, когда убытки клиента от простоя в тысячи раз превышают стоимость сервиса, а лимит оставляет его без возмещения. Здесь необходима индивидуальная архитектура, а не шаблон.

Шаг 7. Изучить условия прекращения и выхода (Exit Plan)

Контракт должен описывать не только начало работы, но и её окончание. Exit-механизмы включают:

• срок и формат возврата всех данных клиента;
• обязательство провайдера обеспечить портирование в стандартном машиночитаемом формате;
• период переходной помощи (transition assistance) — обычно 3–12 месяцев после прекращения;
• порядок уничтожения данных провайдером и сертификат удаления;
• стоимость услуг перехода: многие провайдеры скрывают её в непрозрачных тарифах.

В регулируемых секторах ЕС право на беспрепятственную миграцию скоро станет не пожеланием, а регуляторной обязанностью.

Шаг 8. Учесть новые регуляторные требования к технологиям в ЕС

Современный SaaS-контракт не может игнорировать быстро растущий массив общеевропейских норм:

• AI Act — если SaaS содержит компоненты ИИ, необходимо определить категорию риска, обязанности по прозрачности и человеческому надзору, а также возможность запрещённых практик;
• Digital Services Act (DSA) — если провайдер выполняет роль посреднической платформы, появляются дополнительные обязательства;
• Cyber Resilience Act — требования кибербезопасности к программным продуктам с выходом на рынок ЕС;
• Data Act — обязательное обеспечение переключения между облачными провайдерами и доступа к данным, генерируемым устройствами.

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

Шаг 9. Выбрать применимое право и механизм разрешения споров

В международном SaaS возможны несколько подходов:

• исключительная подсудность судам страны провайдера;
• арбитраж (ICC, LCIA, SCC, DIS);
• гибридные оговорки.

Выбор зависит от:

• переговорных позиций сторон;
• локации активов и центров обработки данных;
• необходимости конфиденциальности;
• перспективы принудительного исполнения в юрисдикциях, где находится клиент.

Важно помнить: GDPR и DSA применяются экстерриториально, поэтому выбор права, не связанного с ЕС, не освобождает от европейского публичного регулирования.

Шаг 10. Разработать стратегию управления контрактом на всём сроке

SaaS-контракт не статичен. Он требует:

• регулярной проверки соответствия обработки данных заявленным целям;
• актуализации списка суб-процессоров;
• мониторинга изменений регуляторного ландшафта;
• плана пересмотра SLA по мере роста критичности сервиса;
• механизма эскалации операционных проблем до юридически значимых уведомлений.

Слабое контрактное управление делает даже качественно составленный договор со временем неработоспособным.

Баланс интересов: провайдер vs заказчик

Как усилить позицию до подписания SaaS-контракта

Лучшая защита начинается на стадии Due Diligence и запроса предложений (RFP):

• запросить и проанализировать типовой DPA провайдера до коммерческих переговоров;
• включить в RFP конкретные требования к портированию данных и сертификации безопасности (ISO 27001, SOC 2);
• провести внутреннюю классификацию данных и определить, какие из них вообще допустимо передавать в облако;
• проверить страну инкорпорации провайдера и его конечных бенефициаров на санкционные риски;
• смоделировать сценарий экстренного отключения сервиса и оценить, насколько контрактные механизмы обеспечивают непрерывность;
• закрепить обязанность провайдера страховать профессиональную ответственность на согласованную сумму.

Типичные ошибки при заключении SaaS-соглашений

1. Использовать шаблон без адаптации к GDPR и Data Act — приводит к иллюзии законности при реальных нарушениях.
2. Смешивать в договоре понятия лицензии и услуги — создаёт неопределённость с правами на ПО и данные.
3. Не проверять цепочку суб-процессоров — риск утечки данных через непроверенного субподрядчика.
4. Игнорировать обязательства по уведомлению об инцидентах — нарушение сроков по GDPR (72 часа).
5. Принимать лимит ответственности «в размере платы за месяц» при обработке критически важных данных.
6. Забывать о праве на аудит — без него невозможно проверить реальное соблюдение условий безопасности.
7. Не согласовывать механизм выхода — заказчик оказывается в технологической ловушке.
8. Оставлять без внимания право провайдера в одностороннем порядке менять условия — допустимо только с чётким периодом уведомления и правом прекращения.
9. Не учитывать AI-специфику — модели могут обучаться на данных заказчика без явного согласия.
10. Не закладывать механизм адаптации к новым регуляторным актам ЕС — контракт устаревает в момент вступления в силу нового регламента.

Чек-лист для сторон SaaS-контракта

Перед подписанием необходимо ответить на 15 вопросов:

1. Определены ли роли контролёра и процессора в соответствии с GDPR?
2. Где физически размещены данные и все их резервные копии?
3. Существует ли письменное разрешение на трансграничную передачу?
4. Каков реальный SLA и методика его расчёта?
5. Прописана ли процедура уведомления о нарушениях безопасности?
6. Какие данные считаются конфиденциальными и как они защищены?
7. Кому принадлежат агрегированные и аналитические данные?
8. Какие исключения из ограничения ответственности согласованы?
9. Есть ли право на аудит и кто за него платит?
10. Что происходит с данными при расторжении договора?
11. Обязан ли провайдер содействовать миграции и сколько это стоит?
12. Учтены ли требования AI Act, DSA, Data Act, если они применимы?
13. Какой суд или арбитраж будет рассматривать спор?
14. Можно ли передать контракт при реструктуризации бизнеса?
15. Каков механизм внесения изменений в DPA и основной договор?

Как выглядит сильная контрактная стратегия

Сильная стратегия обычно включает пять уровней:

1. Business & Data Mapping Понимание бизнес-процессов, потоков данных и критичности сервиса до начала переговоров.
2. Regulatory Mapping Определение всех применимых сегодня и в обозримом будущем норм ЕС, от GDPR до Cyber Resilience Act.
3. Contractual Architecture Построение чёткой, непротиворечивой системы SLA, DPA, лицензионных условий, ответственности и exit-плана.
4. Operational Integration Встраивание контрактных требований в рабочие процедуры обеих сторон (инструкции по безопасности, регламенты уведомлений).
5. Pre-Conflict & Dispute Strategy Наличие заранее определённой последовательности действий при инциденте, нарушении SLA или регуляторной проверке, включая эскалацию и медиацию.

Без пятого уровня даже идеально написанный контракт может не защитить бизнес в момент кризиса.

FAQ

Обязательно ли заключать отдельный DPA к SaaS-контракту?По GDPR — да, если провайдер обрабатывает персональные данные по поручению заказчика. DPA может быть частью основного договора, но должен быть юридически обособлен и отвечать требованиям ст. 28 GDPR.

Может ли провайдер использовать данные клиента для обучения ИИ?Только при наличии явного, отдельного согласия, зафиксированного в контракте. Без этого использование данных для собственных целей провайдера, включая обучение моделей, является нарушением целей обработки.

Что делать, если SaaS-провайдер отказывается менять свой шаблон?Необходимо ранжировать риски и определить критические недопустимые положения. Иногда разумнее согласиться на стандартный документ, но получить дополнительные гарантии через страхование, сертификации и права аудита, чем потерять контракт, не имея реальных рычагов влияния.

Как обеспечить исполнение exit-обязательств, если провайдер в предбанкротном состоянии?Включать в контракт право на эскроу-депонирование исходного кода (если это применимо) или на заблаговременное получение данных в стандартном формате на регулярной основе. В критических случаях рассматривать требование о банковской гарантии на период перехода.

Распространяется ли DORA на SaaS-контракты?Если клиент является финансовой организацией ЕС, DORA (Digital Operational Resilience Act) напрямую регулирует контракты с поставщиками ИКТ-услуг, включая SaaS. Контракт должен содержать положения, предписанные DORA, и допускать прямой аудит со стороны регулятора.

Как ограничить одностороннее изменение условий провайдером?Прописать, что изменения, затрагивающие предмет обработки, SLA, цену или права на данные, вступают в силу только после письменного согласия клиента или дают клиенту безусловное право на расторжение без штрафов и с полной поддержкой миграции.

Связанные услуги

• Technology, Digital Business & Data Protection
• International Commercial & Tech Contracts
• Artificial Intelligence, AI Act & Emerging Tech Regulation
• Cross-Border Data Transfers & GDPR Compliance
• IT Disputes, Cloud & Software Litigation
• Cybersecurity, DORA & NIS2 Compliance
• Commercial IP & Licensing

Связанные материалы

• Как построить законную схему трансграничной передачи данных в ЕС
• DPA под GDPR: 12 ошибок, которые лишают договор силы
• EU AI Act: что изменится для SaaS-продуктов с компонентами ИИ
• Data Act и право на переключение между облачными провайдерами
• Ограничение ответственности в IT-контрактах: что работает в Европе
• Exit plan в SaaS: как обеспечить реальную возможность уйти
• SLA в международном облачном контракте: коммерческий инструмент, а не формальность
• Налоговые и регуляторные риски SaaS-модели в разных юрисдикциях ЕС
• Как проверить технологического партнёра перед интеграцией

Вывод

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

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

В международных технологических контрактах побеждает не тот, кто настоял на своей редакции, а тот, кто заранее предусмотрел, как контракт поведёт себя в момент регуляторной проверки, инцидента безопасности или экстренной миграции.