Договор · Чек-лист · До подписания

Договор на автоматизацию: что проверить до подписания

4 августа 2026 · 12 мин чтения

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

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

Короткий ответ: договор на автоматизацию держится на пяти вещах - конкретный предмет с приложением-ТЗ, оплата этапов за принятый результат, письменные критерии приёмки, права на код и доступы у заказчика, письменный порядок изменений. Без них сумма в договоре значит мало: вы платите за процесс, а не за результат.

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

Предмет договора: почему «автоматизация бизнес-процессов» - это плохо

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

Рабочий предмет ссылается на приложение: «Исполнитель выполняет работы, состав, объём и результат которых определены в Приложении № 1 (Техническое задание), являющемся неотъемлемой частью Договора». Содержательное переезжает в приложение, где его можно менять отдельным документом, не переподписывая договор.

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

Приложение с ТЗ: документ, который делает предмет проверяемым

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

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

Этапы и оплата: за принятый результат, а не за календарь

Самая дорогая ошибка платёжного раздела - привязка транша к дате. «50% при подписании, 50% до 30 сентября» означает, что второй платёж наступает независимо от сделанного. Отказаться можно, но позиция уже проиграна: срок наступил, а критерия «не сделано» в договоре нет.

Здоровая схема: работа разбита на этапы, у каждого есть результат, который можно посмотреть, оплата привязана к акту этапа. Дата остаётся, но как срок исполнителя, а не как триггер платежа. Аванс нормален, вопрос в размере: разумно, когда предоплата покрывает первый этап с осязаемым результатом. Сто процентов вперёд оставляют вас без рычагов.

Полезная деталь - потолок этапа: сумма, выше которой счёт не выставляется без письменного согласования. Из чего складывается смета, разбирает статья про стоимость автоматизации.

Критерии приёмки: что считается словом «работает»

Типовой текст: «Услуги считаются оказанными надлежащим образом, если в течение 3 (трёх) дней с даты направления акта Заказчик не представил мотивированных возражений». Три момента против вас: срок мал и календарный, отсчёт идёт от письма, а не от передачи работающего решения, а слово «мотивированных» без определения позволяет отклонить ваши замечания.

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

Сами критерии пишутся по формуле «событие плюс измеримое условие плюс поведение при отклонении». Не «бот работает», а «на 20 тестовых заявках карточка создаётся не позже 60 секунд, менеджеру уходит уведомление, повтор с тем же телефоном за сутки не создаёт дубль». Договоритесь и о данных приёмки: показ трёх идеальных примеров не доказывает ничего.

Права на код и доступы: кому принадлежит результат

Кому принадлежат права «по умолчанию», зависит от вида договора и его формулировок: в одних случаях право заказчика презюмируется, в других остаётся у исполнителя. Полагаться на умолчание не стоит. Нужна прямая формулировка о переходе прав на сценарии, конфигурации, исходный код и документацию с момента подписания акта по этапу. Вариант «после полной оплаты» на длинном проекте означает, что вы месяцами платите за то, что вам не принадлежит.

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

Доступы - вторая половина вопроса и часто более важная. Проверьте: на кого оформлены аккаунты и домены, кто платит за подписки, где живёт решение. Здоровая схема - аккаунты на заказчика, исполнителю доступ на время работ, как в сценарии выдачи доступов сотрудникам; требования к хранению ключей описаны в статье про безопасность автоматизации. Передаваемое в конце оформляют перечнем: логины, ключи API, экспорт сценариев, схема, инструкция. Без резервных копий передача рискует свестись к пустому аккаунту - как устроено регулярное резервирование, видно в сценарии копий рабочих процессов.

Данные: что с ними происходит во время работ и после

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

Если через сценарий идут персональные данные, добавляется поручение на обработку по 152-ФЗ: телефон и адрес получателя - уже персональные данные, и ответственность оператора остаётся на вас, о чём подробно статья про безопасность данных и 152-ФЗ. Строка нужна и для языковых моделей: куда уходят тексты запросов, хранятся ли они, используются ли для обучения. Чувствительные данные держат в своём контуре, как в разборе n8n на собственном сервере.

Гарантийный период: что входит, а что нет

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

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

В цифрах проверьте длительность (частый ориентир для одного сценария - 1-3 месяца с даты акта), срок реакции и устранения, канал обращений. «Напишем в чат» - не канал: нужна фиксация с датой.

Поддержка после гарантии: отдельный договор, а не добрая воля

Гарантия закрывает ошибки, но не жизнь системы: сервер, оплата сервисов и моделей, наблюдение за сбоями, мелкие правки. Это эксплуатация, в нашем прайсе - 4-15 тыс. ₽ в месяц за сценарий, отдельная строка бюджета, а не часть цены внедрения.

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

Ответственность: простой и утечка

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

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

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

Порядок изменений: кто платит за новые хотелки

Изменения будут: часть требований видна только тогда, когда система заработала на реальных данных. Вопрос не в том, как их избежать, а как оформлять. Рабочая схема: любое изменение объёма идёт письменным запросом с сутью правки, влиянием на срок и ценой; до подписания исполнитель его не делает, а заказчик не ждёт. Эта бумага отделяет уточнение (входит в объём, потому что ТЗ было неоднозначным) от новой работы (не входит, потому что этого в ТЗ нет). Мелочь оговаривают отдельно: правки до часа идут без бумаг. Частые провалы здесь разобраны в статье про ошибки при автоматизации.

Расторжение: что заказчик забирает с собой

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

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

Акты и закрывающие документы: самозанятые и ИП

Автоматизацию часто делают самозанятые и ИП. Разница - в закрывающих документах, и её лучше учесть до подписания.

Самозанятый. Расход подтверждает чек из приложения «Мой налог» на вашу компанию, приёмку - акт: нужны оба. В договор стоит вписать две обязанности: выдавать чек по каждой оплате и письменно сообщить об утрате статуса. Иначе о слетевшем режиме вы узнаёте, когда расход уже не подтверждён.
ИП. Закрывают счёт и акт. Уточните систему налогообложения и наличие НДС: цена «55 000 ₽» с НДС и без - разные деньги, и это должно быть в договоре.
Компания. Договор, счёт, акт, при необходимости универсальный передаточный документ. Вопрос здесь другой: есть ли у подписанта право подписи.

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

Чек-лист: пройти чужой договор за 20 минут

Идите по пунктам с открытым файлом и поиском по тексту. Каждый пункт - да или нет. Три «нет» и больше - договор стоит вернуть на правку до оплаты.

Предмет ссылается на приложение. Есть слова «Приложение № 1» и «неотъемлемая часть», а не только общая фраза про автоматизацию.
ТЗ идентифицируемо. У приложения есть номер, дата и подписи сторон; это тот самый файл, а не «версия из чата».
Есть список того, что не входит. В ТЗ выделены границы объёма с перечнем отложенного.
Этапы имеют результат. У каждого написано, что вы увидите в конце, а не только длительность.
Оплата привязана к акту. Найдите в платёжном разделе слово «акт»: одни календарные даты рядом с суммами - красный флаг.
Срок приёмки от 5 рабочих дней. Проверьте слово «рабочих» и точку отсчёта: доступ к результату, а не отправка акта.
Критерии приёмки есть письменно. Проверяемые утверждения вида «событие плюс условие плюс что при отклонении», а не «система работает корректно».
Описан порядок устранения замечаний. Есть срок на исправление и правило повторной проверки: иначе одно замечание подвешивает этап.
Права на код переходят заказчику. Прямая формулировка с привязкой к акту этапа и оговорка о сторонних лицензиях.
Аккаунты и доступы на вас. Указано, где живёт решение, на кого зарегистрированы сервисы и что передаётся при сдаче.
Данные: хранение и удаление. Есть конфиденциальность и обязанность удалить копии, а при персональных данных - поручение на обработку.
Гарантия описана списком. Указаны срок, что входит и что нет, время реакции и канал обращений.
Поддержка вынесена отдельно. Свой договор или приложение: состав работ, цена, включённый объём, порядок выхода.
Ответственность симметрична и ограничена. Неустойка с обеих сторон, потолок назван, утечка выведена из-под ограничения.
Изменения и расторжение расписаны. Новые работы оформляются письменно с ценой и сроком; при выходе вы забираете исходники, доступы и документацию.

Разбор договоров на потоке автоматизируется отдельно - об этом статья про анализ договоров с ИИ. Но один договор быстрее пройти руками.

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

Это не юридические образцы, а направление правки. Точные формулировки под вашу ситуацию собирает юрист.

Было	Чем плохо	Стало
«Исполнитель оказывает Заказчику услуги по автоматизации бизнес-процессов»	Предмет не проверить: подходит и контур из пяти сценариев, и одно уведомление в чат	«Исполнитель выполняет работы, состав, объём и результат которых определены в Приложении № 1 (Техническое задание), являющемся неотъемлемой частью Договора»
«Услуги считаются оказанными надлежащим образом, если Заказчик не направил мотивированных возражений в течение 3 (трёх) дней с даты направления акта»	Молчание становится приёмкой, срок календарный и идёт от письма, а не от доступа к результату	«Заказчик проверяет результат этапа по критериям приёмки (Приложение № 2) в течение 5 (пяти) рабочих дней с даты предоставления доступа и письменного уведомления о готовности»
«Оплата: 50% в течение 3 дней с даты подписания Договора, 50% в срок до 30 сентября 2026 года»	Второй платёж наступает по календарю независимо от того, сделано что-либо	«Оплата этапа производится в течение 5 (пяти) рабочих дней с даты подписания Сторонами акта приёмки соответствующего этапа»
«Исключительные права на результат работ принадлежат Исполнителю; Заказчику предоставляется право использования»	Правки, перенос и развитие возможны только через исполнителя, и цена зависимости растёт	«Исключительные права на созданные по Договору сценарии, конфигурации, исходный код и документацию переходят Заказчику с момента подписания акта по этапу; перечень сторонних компонентов и лицензий - в Приложении № 3»
«Исполнитель не несёт ответственности за любые убытки Заказчика, возникшие в связи с использованием результата работ»	Обнуляет и качество, и конфиденциальность: раздел о неразглашении становится декларацией	«Ответственность Исполнителя ограничена стоимостью этапа, в рамках которого допущено нарушение; ограничение не применяется к разглашению конфиденциальной информации и персональных данных»

Итог

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

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

Договор описывает, что вам обязаны передать. Как проверить это на приёмке и что забрать на руки, чтобы не зависеть от одного человека, - в статье про приёмку и передачу автоматизации.

Частые вопросы

Можно ли подписывать договор, если техзадание ещё не готово?

Можно, но тогда предметом первого этапа делают само обследование и написание ТЗ, а не разработку. Схема выглядит так: отдельный этап на разбор процесса с оплатой за документ, а объём, цена и срок основных работ определяются после того, как ТЗ подписано обеими сторонами как приложение. Опасен обратный порядок: договор сразу на всю разработку с устным обещанием согласовать ТЗ по ходу. В этом случае предмет остаётся резиновым в обе стороны, и на приёмке спор упирается в то, кто что имел в виду в переписке.

Что делать, если подрядчик не отдаёт исходный код?

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

Хватит ли счёта и акта, если исполнитель - самозанятый?

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

Не готовы обсуждать проект? Оцените выгоду сами: калькулятор ROI автоматизации - 1 минута, без контактов. Или заберите чек-лист «Что автоматизировать первым».