Юридический чек-лист для владельцев ресторанов: безопасное сотрудничество с IT-поставщиками без штрафов и утечек

Юридический чек-лист для владельцев ресторанов: безопасное сотрудничество с IT-поставщиками без штрафов и утечек

У большинства рестораторов слово «юрист» ассоциируется с проверкой Роспотребнадзора, спорами с арендодателем или договором с поставщиком продуктов. IT-поставщики — разработчики сайтов и приложений, интеграторы iiko и R‑keeper, подрядчики по доставке, лояльности, оплате и эквайрингу — исторически воспринимаются как технические подрядчики, к которым «ходят с ТЗ, а не с юристом». В 2026 году это одна из самых дорогих управленческих иллюзий. Каждый такой подрядчик получает доступ к персональным данным гостей, платежной информации, кассовым операциям, иногда — к камерам и системам контроля персонала. Любая ошибка в договоре превращается либо в штраф от регулятора, либо в репутационную катастрофу, либо в финансовые потери при споре о сроках и качестве.

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

Главные юридические риски при работе с IT-поставщиками

Прежде чем разбирать пункты договора, важно увидеть картину целиком. Юридические риски в IT-сотрудничестве ресторана делятся на пять больших групп, и большинство владельцев осознанно контролируют только одну — финансовую.

Персональные данные гостей и сотрудников

Это самый болезненный блок. Сайт ресторана собирает данные о бронированиях, доставке и заказах; мобильное приложение — историю заказов и предпочтения; CRM — контакты и поведение гостей; система лояльности — бонусы, дни рождения, иногда паспортные данные для акций «18+»; POS-система — данные кассовых операций. Формально у ресторана — своя база, у подрядчика — своя роль обработчика. Но по факту оператор всё равно несёт основную ответственность перед Роскомнадзором и гостями.

Главная ошибка — «у нас всё на серверах подрядчика, значит, это его проблема». Закон говорит иначе: оператор отвечает за то, чтобы обработка велась по закону, даже если технически её ведёт другое лицо. Это значит, что в договоре с разработчиком сайта, интегратором iiko, поставщиком CRM или платформы доставки должны быть прописаны цели обработки, перечень данных, меры защиты, порядок уничтожения, ответственность подрядчика за утечку и уведомления регулятора.

Платежи и финансовая ответственность

Вторая болезненная зона — деньги. Эквайринг, онлайн-оплата на сайте, оплата через приложение, интеграции с агрегаторами доставки, бонусные программы с денежным эквивалентом, безналичные чаевые — всё это финансовые потоки, которые идут через IT-инфраструктуру. Если сервис «упал» в пятничный вечер, ресторан теряет выручку; если эквайринг оформлен на подрядчика, а не на юрлицо ресторана, налоговая может задать неприятные вопросы; если деньги за доставку «зависли» на счёте агрегатора из-за смены условий, владелец вынужден судиться.

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

Интеллектуальная собственность и права на код

Третья группа рисков — то, что ресторатор обычно не замечает до момента разрыва. Кому принадлежит сайт, мобильное приложение, дизайн, база гостей, макеты меню, фото, видео, фирменный стиль, который заказывался у подрядчика? Кто имеет право использовать логотип, товарные знаки, контент после расторжения договора? Может ли подрядчик показать ваш ресторан в портфолио? Может ли разработчик продать ваш сайт «как шаблон» другому клиенту?

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

Сроки, SLA и реальные штрафы

Четвёртая группа — операционная. Договор с IT-подрядчиком почти всегда содержит красивые слова о сроках: «запустим за 30 дней», «аптайм 99,9%», «время реакции 1 час». Юридически важно не то, что написано в коммерческом предложении, а то, что зафиксировано в договоре: какие сроки считаются существенными, что такое «запуск» (с чьей подписью, по какому акту), какие KPI у SLA, какие штрафы за нарушение и как они соотносятся с общей стоимостью.

Типичный разговор владельца: «Они обещали запустить доставку к 1 числу, а запустили 15-го, и ничего нельзя сделать». Почти всегда — потому что в договоре не было привязки сроков к штрафам и существенным условиям, а формулировка «срок запуска — 30 рабочих дней» была размыта оговорками «после согласования ТЗ, при условии оплаты, по графику подрядчика».

Конфиденциальность и коммерческая тайна

Пятая, часто недооценённая зона. IT-подрядчик видит финансы ресторана (через CRM и аналитику), маржинальность блюд (через интеграцию с iiko), зарплаты (если подключают HR-модули), гостевую базу, стратегические планы (через переписку и ТЗ). Без соглашения о конфиденциальности и режиме коммерческой тайны он формально может использовать эту информацию: нанимать к себе ваших сотрудников, открывать конкурента, продавать данные гостей агрегаторам. И главное — ресторан не сможет предъявить ничего, кроме общих фраз о «добросовестности».

Что обязательно должно быть в договоре с IT-поставщиком

Переходим к конкретике. Ниже — не абстрактные советы, а набор пунктов, которые должны быть в договоре (или в приложениях к нему) при работе с любым IT-подрядчиком ресторана: разработчиком сайта, интегратором iiko, поставщиком CRM, платформой лояльности, системы бронирования, эквайринга, доставки, чаевых, отзывов. Уровень детализации зависит от критичности системы для бизнеса, но базовый набор — одинаков.

Предмет договора: не «оказывать услуги», а конкретный результат

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

Правильно — разделять договор на блоки:

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

В приложении — подробное техническое задание с перечнем экранов, функций, интеграций. Без ТЗ в приложении договор превращается в «вы понимаете по-своему, подрядчик — по-своему».

Сроки: существенные условия и пошаговые дедлайны

Сроки в IT-договоре — это якорь, за который ресторан может «тянуть» в случае проблем. Сделайте три вещи.

Первое — разбейте общий срок на этапы: согласование концепции, дизайн, прототип, разработка, тестирование, запуск, опытная эксплуатация. У каждого этапа — своя дата и свой акт. Это позволяет не платить за всё сразу и видеть, на каком шаге проект «просел».

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

Третье — зафиксируйте, с чьей стороны задержка. Почти все срывы в IT-проектах ресторанов — это «ждём от вас контента», «не согласовали ТЗ», «не прислали доступы». В договоре должно быть: «Заказчик обязан предоставить … в течение X рабочих дней. Непредоставление в срок переносит сроки Подрядчика на соответствующий период». И обязательно — конкретный список того, что должен предоставить ресторан (логотип, фото, меню, реквизиты, доступы к домену, хостингу, iiko и т.д.).

Стоимость, порядок оплаты и изменение тарифов

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

Что должно быть в договоре:

• фиксированная стоимость этапов работ с разбивкой по актам;
• перечень того, что входит в стоимость, и что считается «дополнительными работами»;
• условия и порядок изменения стоимости сопровождения: например, не чаще одного раза в год, на величину не выше официальной инфляции, с уведомлением не менее чем за 60 дней и правом ресторана отказаться без штрафов;
• порядок возврата оплаты при расторжении за неисполнение обязательств — в какой срок, на какой счёт, с какой формулировкой.

Права на результат: исключительная передача, исходники, документация

Это ключевой блок, к которому рестораторы почти никогда не возвращаются, пока не начинается «расставание» с подрядчиком. Стандартный пункт договора «права на результат работ передаются Заказчику в момент оплаты» юридически слаб: не указано, какие именно права, в каком объёме, передаются ли исходные коды, дизайн-макеты, доступы к репозиториям, аккаунтам разработчиков, доменам.

Правильная формулировка — ближе к такой:

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

Конфиденциальность и режим коммерческой тайны

Этот блок часто подменяется общей фразой «стороны обязуются не разглашать конфигурационную и коммерческую информацию». Юридически бесполезная фраза: не определено, что считается конфиденциальным, каковы последствия нарушения, в какие сроки возвращаются носители.

Минимальный набор:

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

Персональные данные: поручение на обработку

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

В договоре или отдельном соглашении должны быть:

• формулировка: «Подрядчик является обработчиком персональных данных и осуществляет обработку по поручению Заказчика (оператора) в целях …, в объёме …, с использованием …»;
• перечень обрабатываемых данных: ФИО, телефон, e-mail, адрес доставки, история заказов, платежные данные, бонусы и т.д.;
• обязанность подрядчика соблюдать принципы и правила обработки, принимать меры защиты, предусмотренные ФЗ-152 и приказами ФСТЭК/ФСБ;
• обязанность уведомить ресторан об утечке в течение 24 часов с момента обнаружения;
• ответственность подрядчика за убытки ресторана, связанные с утечкой, в том числе за штрафы Роскомнадзора и репутационный ущерб (в пределах разумного);
• порядок уничтожения данных при расторжении и подтверждение уничтожения актом.

Ответственность, штрафы и ограничения

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

Что стоит зафиксировать:

• за нарушение сроков запуска — штраф в процентах от стоимости этапа за каждый день просрочки (например, 0,1–0,5% в день, но не более 10–20% от стоимости);
• за нарушение SLA — снижение ежемесячной платы за сопровождение или фиксированный бонус за каждый час простоя;
• за утечку персональных данных — компенсация убытков, включая штрафы регулятора и расходы на PR-сопровождение кризиса;
• за нарушение конфиденциальности — фиксированный штраф + убытки;
• за нарушение исключительных прав — запрет на использование и компенсация убытков.

Одновременно — зафиксируйте ограничение общей ответственности подрядчика (liability cap). Обычно это 50–100% от стоимости договора. Без такого ограничения подрядчик либо не подпишет договор, либо заложит в цену тройной запас прочности.

Расторжение: процедура, последствия, «отступные»

Ещё один блок, к которому возвращаются, когда всё уже плохо. В договоре должны быть:

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

Применимое право и подсудность

По умолчанию — российское право, арбитражный суд по месту нахождения ответчика. Но для IT-споров разумно зафиксировать:

• применимое право — право Российской Федерации;
• обязательный досудебный претензионный порядок — 30 календарных дней;
• подсудность — по выбору ресторана (по месту нахождения истца или ответчика);
• язык документов и коммуникации — русский;
• валюта расчётов — российский рубль.

Типичные уловки в договорах IT-поставщиков и как их избежать

Даже зная, какие пункты нужны в договоре, ресторан рискует столкнуться с уловками, которые на первый взгляд выглядят безобидно. Ниже — самые распространённые.

«Все права принадлежат разработчику до полной оплаты»

Очень частая формулировка. Формально — логично: не заплатил, не получил права. Но в сочетании с «передача прав осуществляется по отдельному акту» превращается в инструмент давления. Ресторан оплатил 100%, акт не подписан, подрядчик говорит: «Акт не подписан, значит, передача прав не состоялась, ваш сайт — наш». Решение — в договоре: «Моментом перехода исключительных прав является факт оплаты, подтверждённый платежным поручением. Подписание акта не является условием перехода прав».

«Подрядчик вправе привлекать субподрядчиков»

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

«Сопровождение осуществляется по заявкам в мессенджере»

Звучит удобно, юридически — ловушка. Чат в Telegram или WhatsApp — не документооборот. Доказать, что заявка была подана в срок, что подрядчик её получил, что он не выполнил обязательства, — почти невозможно. В договоре: «Заявки на сопровождение направляются через систему [helpdesk/трекер/электронная почта]. Моментом получения заявки считается … . Отсутствие ответа в течение X часов означает согласие с заявкой».

«Срок запуска — по согласованию сторон»

Прямая дорога к бесконечному проекту. Замените на конкретные даты или формулу: «X рабочих дней с даты подписания Договора / с даты предоставления Заказчиком материалов / с даты подписания ТЗ».

«Тарифы могут изменяться с уведомлением за 30 дней»

Без ограничений — подрядчик поднимет цены в любой момент, а ресторан «успеет» уйти только через 30 дней после уведомления. В договоре: «Изменение тарифов возможно не чаще 1 раза в год, на величину не выше индекса потребительских цен Росстата, с уведомлением за 60 дней. При повышении более чем на Y% Заказчик вправе расторгнуть договор без штрафов».

«Подрядчик не несёт ответственности за косвенные убытки»

Стандартная фраза, но в IT-контексте её нужно ограничить. Косвенные убытки — это, например, потерянная выручка из-за упавшего сайта. Если оставить формулировку без оговорок, ресторан не получит ничего за реальные потери. Решение — исключение: «Ограничение не применяется к убыткам, вызванным утечкой персональных данных, нарушением конфиденциальности, нарушением исключительных прав Заказчика».

«Акты считаются подписанными, если в течение 5 рабочих дней не поступили возражения»

Приёмка без подписи — частая практика. Но без подписи и без активных действий по приёмке (проверка, тестирование) — это риск подписать акт, по которому подрядчик «сдал» неработающий сайт. В договоре: «Акт считается подписанным, если Заказчик не направил мотивированных возражений в течение … рабочих дней. Заказчик вправе провести приёмку в течение … рабочих дней с даты получения акта. В случае мотивированного отказа Стороны составляют протокол с перечнем доработок и сроками».

Как правильно оформлять доступы, домены и аккаунты

Отдельная зона риска — технические доступы, которые ресторан часто «забывает» юридически зафиксировать. В результате при смене подрядчика начинается хаос: домен оформлен на физлицо программиста, аккаунт в App Store и Google Play — на почту подрядчика, репозиторий с исходниками — в его GitHub, хостинг — в его личном кабинете.

Домены и хостинг

Домен ресторана должен быть зарегистрирован на юридическое лицо ресторана (или на ИП, если это индивидуальный предприниматель). Никогда — на физлицо, в том числе на директора или владельца лично. Хостинг — на юрлицо, с доступом по логину-паролю у ответственного сотрудника ресторана, а не подрядчика. Если подрядчик сам управляет хостингом — в договоре прямо пропишите: «При расторжении договора Подрядчик обязан в течение … рабочих дней передать Заказчику все доступы, включая логины, пароли, коды двухфакторной аутентификации, API-ключи».

Аккаунты в сервисах

App Store, Google Play, Яндекс.Касса (ЮKassa), CloudPayments, Tilda, Bitrix, amoCRM, iiko, R‑keeper, сервисы аналитики, чат-боты — все аккаунты должны быть на ресторан, а не на подрядчика. Если аккаунт заводил подрядчик — сразу после запуска передавайте права: меняйте владельца, добавляйте администраторов от ресторана, отключайте доступ подрядчика (или оставляйте отдельный «подрядческий» аккаунт, но не основной).

Репозитории и исходные коды

Для сайтов и приложений — заведите собственный аккаунт на GitHub/GitLab/Bitbucket, попросите подрядчика перенести туда репозиторий сразу после сдачи этапа. Доступ — у вашего технического директора или внешнего IT-консультанта, не только у подрядчика.

Доступы к POS, CRM, аналитике

В iiko, R‑keeper, 1С, amoCRM, Bitrix, Google Analytics, Яндекс.Метрика должны быть отдельные аккаунты сотрудников ресторана. Подрядчику — отдельная роль с минимально необходимыми правами, с регулярной ротацией паролей и журналированием действий.

Что делать, когда сотрудничество уже идёт, а договор — слабый

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

Шаг 1. Провести аудит текущих договоров и доступов

Составьте реестр всех IT-подрядчиков: сайт, приложение, iiko, R‑keeper, CRM, лояльность, доставка, эквайринг, чаевые, отзывы, бронирование, аналитика, маркетинг, SEO. По каждому — действующий договор, срок, предмет, стоимость, ответственные, доступы. Это занимает 1–2 дня, но даёт ясную картину: где договор «сильный», где — формальный, где его вообще нет.

Шаг 2. Закрыть критичные дыры дополнительными соглашениями

Не нужно сразу перезаключать все договоры. Достаточно подписать дополнительные соглашения по самым болезненным точкам:

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

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

Шаг 3. Перевести домены, аккаунты, репозитории на ресторан

Это самая практическая и часто самая сложная часть. Подрядчики сопротивляются — по понятным причинам: «пока аккаунты у нас, нас сложнее заменить». Но интересы ресторана — в обратном. По каждому активу — план-график перевода на юрлицо ресторана, с конкретными сроками и ответственным сотрудником.

Шаг 4. Ввести внутренний регламент работы с подрядчиками

Документ на 5–7 страниц, который фиксирует внутренние правила ресторана: как согласовываются ТЗ, как принимаются работы, как оформляются акты, кто имеет право подписывать, как контролируются сроки, как ведётся переписка, как фиксируются доступы. Это не юридический документ, а управленческий — но он сильно снижает количество «стихийных» решений, которые потом превращаются в юридические проблемы.

Шаг 5. Зафиксировать KPI и SLA там, где их не было

Даже если в договоре нет формального SLA, его можно зафиксировать в виде приложения или дополнительного соглашения. Минимум: время реакции на заявку (1 час — критичные, 4 часа — обычные, 24 часа — плановые), время восстановления сервиса (4 часа — критичные, 24 часа — обычные), ежемесячный отчёт по аптайму, штрафы за нарушение. Подрядчики, которые работают «в белую», обычно соглашаются — это повышает доверие и снимает конфликты.

Особенности работы с конкретными категориями IT-поставщиков

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

Интеграторы iiko и R‑keeper

Эти подрядчики получают доступ к кассовым данным, складским остаткам, себестоимости, зарплатам. В договоре обязательно — поручение на обработку персональных данных сотрудников, NDA по коммерческой информации (закупочные цены, фудкост, условия с поставщиками), фиксация прав на доработки (кто владеет кастомными модулями, отчётами, интеграциями). При смене интегратора — отдельная процедура передачи: лицензионные ключи, доступы к облаку iiko/R‑keeper, базам, кастомным настройкам. Подрядчик не должен «привязывать» ресторан к себе через эксклюзивные лицензии или закрытые модули.

Разработчики сайтов и приложений

Здесь — максимальный риск по интеллектуальной собственности. Ключевые пункты: исключительные права на код, дизайн, контент; передача исходников, репозиториев, макетов; права на домен, аккаунты в App Store и Google Play; использование в портфолио — только с письменного согласия; гарантия, что код не содержит заимствованных компонентов с ограниченными лицензиями. В договоре на разработку приложения — отдельно: политика поддержки после запуска, обновлений, публикации в сторах, кто платит за аккаунты разработчиков, как часто выпускаются обновления.

Платформы доставки и агрегаторы

Самые «тонкие» отношения: вы зависите от платформы, платформа — от вас, но условия диктует платформа. Юридически важно: кто является платежным агентом, в какие сроки перечисляются деньги, какая комиссия и как она меняется, что происходит с гостевой базой при отключении (принадлежит ресторану или платформе), как обрабатываются персональные данные гостей, кто отвечает за утечку, какие штрафы за нарушение условий. Плюс — зафиксировать право ресторана на собственный канал доставки (сайт, приложение) и отсутствие эксклюзивности, если это не противоречит коммерческой модели.

Сервисы лояльности, CRM, маркетинга

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

Эквайринг, оплата, чаевые

Финансовые сервисы требуют максимальной прозрачности. В договоре: кто является платежным агентом, по какой лицензии работает, где и как хранятся платежные данные (PCI DSS, если применимо), кто несёт ответственность при сбое, в какие сроки перечисляются деньги, как устроена отчётность, какие штрафы за нарушение условий. Для чаевых — отдельный блок: кто распределяет, как часто, в какие сроки, как облагается налогом, как документируется. Часто чаевые сервисы — это партнерство с банком-эквайером, и условия «спрятаны» в оферте банка, а не в вашем договоре с платформой. Это нужно учитывать.

SEO, маркетинг, отзывы

Здесь риск — не в данных, а в методах. В договоре: запрет на «чёрные» методы SEO (покупка ссылок, дорвеи, накрутки), которые могут привести к санкциям поисковиков; запрет на заказные фейковые отзывы; ответственность подрядчика за репутационный ущерб в случае санкций; право на аудит методов; право собственности на созданный контент (тексты, фото, видео). Отдельно — кто владеет аккаунтами в Яндекс.Бизнесе, Google Business Profile, на площадках отзывов; как они передаются при расторжении.

Чек-лист: что проверить в договоре с IT-поставщиком

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

Блок 1. Предмет и сроки

• Предмет договора сформулирован как конкретный результат, а не «оказание услуг».
• Техническое задание — в приложении, подписано обеими сторонами.
• Этапы работ с конкретными датами и актами приёмки.
• Существенные сроки зафиксированы (запуск, передача прав, запуск в эксплуатацию).
• Определена ответственность за задержку со стороны ресторана (доступы, контент, согласования).
• Определена ответственность за задержку со стороны подрядчика (штрафы, право на расторжение).

Блок 2. Стоимость и оплата

• Стоимость зафиксирована по этапам, в рублях, с НДС или без — однозначно.
• Условия и порядок изменения тарифов на сопровождение — ограничены по частоте и размеру.
• Порядок возврата оплаты при расторжении — зафиксирован.
• Условия «дополнительных работ» — ограничены (только с письменного согласования).
• Условия приёмки и подписания актов — однозначные, с правом мотивированного отказа.

Блок 3. Права на результат

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

Блок 4. Персональные данные

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

Блок 5. Конфиденциальность

• Перечень конфиденциальной информации — конкретный, а не «любая информация».
• Обязательства действуют не менее 3 лет после расторжения.
• Подрядчик обеспечивает конфиденциальность со стороны своих сотрудников и субподрядчиков.
• Штраф за нарушение конфиденциальности — фиксированная сумма или компенсация убытков.
• Порядок возврата/уничтожения носителей при расторжении — зафиксирован.

Блок 6. Ответственность и расторжение

• Штрафы за срыв сроков — в процентах от стоимости этапа.
• Штрафы за нарушение SLA — снижение платы или фиксированный бонус.
• Существенные нарушения, дающие право на расторжение, — перечислены.
• Процедура уведомления о расторжении — однозначная (срок, форма, основание).
• Последствия расторжения: возврат оплаты, передача доступов, исходников, документации, данных — в конкретный срок.
• Запрет подрядчику блокировать доступ после расторжения.
• Ограничение общей ответственности — разумное, с исключениями для утечек, конфиденциальности, прав.

Блок 7. Процедурные вопросы

• Применимое право — российское.
• Претензионный порядок — обязательный, с конкретным сроком.
• Подсудность — по выбору ресторана.
• Язык документов — русский.
• Порядок внесения изменений в договор — письменно, по согласованию.
• Уведомления — в письменной форме, с подтверждением получения.

Типичные ошибки владельцев при работе с IT-поставщиками

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

«Подписали договор, не читая»

Самый частый сценарий. Подрядчик присылает «свой шаблон», владелец подписывает, потому что «они все так работают», «времени нет», «юрист занят». В результате — все риски на ресторане, все штрафы — в пользу подрядчика, никаких прав на код, никакой ответственности за утечку. Решение — выделить 2–3 часа на чтение договора или передать его на экспресс-анализ внешнему юристу. Стоимость — десятки тысяч рублей, экономия — миллионы.

«Договор подписал директор, а работает с подрядчиком маркетолог»

Классическая проблема: директор подписал договор, в котором всё хорошо, а на практике маркетолог общается с подрядчиком напрямую, согласовывает «допработки» в мессенджере, подписывает акты по e-mail. Формально директор ничего не знает, фактически — обязательства возникают. Решение — доверенность на представителя ресторана, четкий регламент согласований, запрет на устные договоренности без письменного оформления.

«Нет акта — нет оплаты»

И обратная ошибка: ресторан платит по счетам, не подписывая акты, не проводя приёмку. В результате подрядчик считает работы сданными, ресторан — нет, а доказать, что что-то не сделано, сложно. Решение — внутренний регламент: сначала приёмка и акт, потом оплата; без акта оплата только авансовая, предусмотренная договором.

«Доверяем подрядчику, потому что он давно с нами»

Лояльность — это хорошо, но юридически она ничего не значит. Подрядчик, с которым ресторан работает 5 лет, может сменить владельца, сменить команду, обанкротиться, быть продан, начать работать «на два фронта». Договор — это способ сохранить отношения даже при смене людей. Долгосрочное сотрудничество не отменяет необходимости сильного договора; наоборот, в долгосрочных отношениях договор должен быть особенно тщательным.

«У нас маленький ресторан, до нас никому нет дела»

Для регулятора размер бизнеса не имеет значения. Штрафы за утечку персональных данных — до 6 млн рублей для юрлиц, за повторную — до 18 млн. Штрафы за отсутствие необходимых документов у оператора ПД — до 1 млн. Репутационные потери для маленького ресторана — еще более критичны, потому что у него нет запаса прочности. Поэтому юридическая гигиена важна и для одиночного кафе, и для сети.

«Мы договорились устно, потом оформим»

В IT-проектах «потом» не бывает. Согласования, доступы, доработки, изменения — всё происходит в моменте, а юридическое оформление откладывается на «когда будет время». В результате — ресторан платит за то, что не заказывал, подрядчик делает то, что не обсуждалось, а доказать свою правоту невозможно. Решение — любое изменение, даже мелкое, оформляется письменно (e-mail с подтверждением, доп. соглашение, заявка в трекере). Это занимает 10 минут, экономит — месяцы.

Что делать, если проблема уже случилась

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

Утечка персональных данных

Первое — зафиксировать факт: дата, время, объём, какие данные, сколько субъектов. Второе — уведомить подрядчика по договору (в течение 24 часов с момента обнаружения — это его обязанность по 152-ФЗ, и его ответственность). Третье — оценить, нужно ли уведомлять Роскомнадзор и субъектов данных (по закону — да, если утечка массовая или касается специальных категорий данных). Четвёртое — зафиксировать убытки и направить претензию подрядчику. Пятое — при необходимости — обратиться в суд. На этом этапе нужен юрист, специализирующийся на IT и персональных данных.

Подрядчик не отдаёт доступы и исходники

Первое — направить письменное требование со ссылкой на договор (поручение на обработку, передача прав, конфиденциальность). Второе — зафиксировать факт отказа. Третье — направить досудебную претензию с требованием передать доступы в течение 5–10 рабочих дней и компенсацией убытков. Четвёртое — обратиться в суд. С 2024 года в России действует механизм обеспечительных мер в IT-спорах: можно через суд обязать подрядчика передать доступы ещё до рассмотрения иска по существу. Но для этого нужно, чтобы в договоре была соответствующая обязанность.

Срыв сроков и некачественная работа

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

Подрядчик требует доплату, не предусмотренную договором

Без подписанного допсогласования или заявки — доплата незаконна. Если подрядчик отказывается работать без доплаты, ресторан вправе расторгнуть договор и требовать возврата оплаты за невыполненные работы. Главное — не идти на уступки под давлением: «заплатите сейчас, потом разберёмся» всегда заканчивается «разбираться» в пользу подрядчика.

Как выстроить долгосрочные отношения с IT-поставщиками без юридических рисков

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

Несколько практических принципов, которые стоит заложить в работу с IT-поставщиками:

1. Сильный договор на старте — дешевле, чем судебные споры потом. 30–50 тысяч рублей на юридическую проработку договора — это инвестиция, которая окупается при первом же конфликте.
2. Регламент работы с подрядчиками — обязателен. Без него — стихийные решения, юридические дыры, потеря контроля.
3. Регулярный аудит IT-активов — раз в год. Договоры, доступы, домены, аккаунты, репозитории — всё должно быть в реестре и под контролем.
4. Отдельный ответственный за IT-безопасность и юридическую гигиену. Это может быть сам владелец, директор по развитию, технический директор, внешний IT-консультант. Главное — чтобы был один человек, который отвечает за «всё, что связано с IT-поставщиками».
5. Внешний юрист на ретейнере. Не нужно держать штатного юриста по IT, но иметь контакт внешнего специалиста, который знает вашу специфику, — обязательно. Это дешевле, чем разовые обращения, и быстрее, чем поиск юриста в момент кризиса.

Что сделать на этой неделе: пошаговый план для владельца

Если у вас нет времени читать длинные материалы и хочется конкретных действий «на сейчас» — вот минимальный план, который закрывает 80% рисков.

Шаг 1. Составьте реестр IT-подрядчиков. Один документ, в котором перечислены все подрядчики, договоры, сроки, контакты, доступы. Это даст ясность: с кем вы работаете, на каких условиях, что нужно проверить.

Шаг 2. Проверьте, на кого оформлены домены и ключевые аккаунты. Домен ресторана, аккаунты в App Store и Google Play, в CRM, в iiko/R‑keeper, в эквайринге, в сервисах аналитики. Если что-то оформлено на физлицо или на подрядчика — поставьте задачу переоформить.

Шаг 3. Проверьте три ключевых договора. Возьмите договоры с разработчиком сайта/приложения, с интегратором iiko или R‑keeper, с платформой лояльности или доставки (те, что критичны для бизнеса). Откройте блоки про персональные данные, права на результат, конфиденциальность, ответственность. Если они «пустые» — ставьте задачу подготовить дополнительные соглашения.

Шаг 4. Зафиксируйте внутренний регламент работы с подрядчиками. Документ на 3–5 страниц: кто согласовывает ТЗ, кто подписывает акты, как ведётся переписка, как оформляются изменения, как контролируются сроки.

Шаг 5. Найдите внешнего юриста по IT-праву. Один контакт, который знает вашу специфику, готов в течение 1–2 дней дать экспресс-оценку договора или подготовить дополнительное соглашение.

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

Юридическая защита в IT-сотрудничестве — это не паранойя и не «лишние расходы». Это способ сохранить бизнес, репутацию и деньги в ситуации, когда каждый второй процесс завязан на внешнего подрядчика. Чем раньше вы наведёте порядок в договорах, доступах и регламентах, тем меньше сюрпризов вас ждёт в будущем. А если сюрпризы всё-таки случатся — тем увереннее вы сможете на них реагировать.