Школа IT юриста
Open in Telegram
Школа повышения квалификации для юристов 📌 Поможем стать нужными и быть дороже на рынке 📌 Авторские курсы Людмилы Харитоновой 📌 800+ юристов уже прошли обучение и выросли в профессии Сайт: https://itpravo.tech Для связи: info@zarlaw.ru
Show more656
Subscribers
+224 hours
+27 days
+530 days
Data loading in progress...
Similar Channels
No data
Any problems? Please refresh the page or contact our support manager.
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
September '26
September '26
+7
in 0 channels
August '26
+19
in 1 channels
Get PRO
July '26
+16
in 0 channels
Get PRO
June '26
+17
in 0 channels
Get PRO
May '26
+30
in 1 channels
Get PRO
April '26
+24
in 1 channels
Get PRO
March '26
+11
in 0 channels
Get PRO
February '26
+34
in 0 channels
Get PRO
January '26
+44
in 0 channels
Get PRO
December '25
+63
in 1 channels
Get PRO
November '25
+41
in 1 channels
Get PRO
October '25
+24
in 0 channels
Get PRO
September '25
+36
in 2 channels
Get PRO
August '25
+40
in 5 channels
Get PRO
July '25
+69
in 2 channels
Get PRO
June '25
+100
in 1 channels
Get PRO
May '25
+50
in 3 channels
Get PRO
April '25
+122
in 2 channels
Get PRO
March '250
in 0 channels
Get PRO
February '25
+104
in 1 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 09 September | +2 | |||
| 08 September | +3 | |||
| 07 September | +1 | |||
| 06 September | 0 | |||
| 05 September | 0 | |||
| 04 September | 0 | |||
| 03 September | +1 | |||
| 02 September | 0 | |||
| 01 September | 0 |
Channel Posts
Один из частых вопросов - кому вообще нужен договорный плейбук?
Только юристу, который проверяет договор?
Или его можно передать внутреннему заказчику - бизнесу?
Ответ: можно и нужно использовать шире.
📌Плейбук не имеет жестко заданной структуры. Его можно адаптировать под конкретный процесс, тип договора и даже под конкретную команду.
И именно это делает его особенно полезным.
Как минимум мы рекомендуем включать в плейбук не только правила проверки формулировок договора, но еще три больших блока.
1️⃣ Что сделать до заключения договора
Это может быть:
▫️ какие данные нужно собрать у бизнес-заказчика
▫️ какие вопросы задать до начала согласования
▫️ как проверить контрагента
▫️ какие документы запросить
▫️ какие критерии сделки проверить заранее
▫️ в каких случаях договор вообще нельзя запускать в работу без дополнительного согласования.
По сути, это чек-лист подготовки к сделке.
2️⃣ Что делать после заключения договора
И вот этот раздел часто недооценивают.
После подписания договора про его содержание очень быстро забывают.
Но именно в договоре закреплены:
▫️ правила коммуникации сторон
▫️ сроки уведомлений
▫️ порядок приемки
▫️ требования к документам
▫️ основания для изменения цены
▫️ сроки оплаты
▫️ порядок направления претензий и уведомлений.
Если бизнес-заказчик не знает этих правил, часть юридической работы, сделанной на этапе согласования, просто теряет смысл.
Поэтому плейбук может стать для бизнеса инструкцией по исполнению договора.
3️⃣ Что делать, если возник спор
❓ Кому сообщить?
❓ Какие документы сохранить?
❓ В какие сроки нужно направить уведомление?
❓ Что нельзя писать контрагенту без согласования с юристом?
❓ Когда необходимо зафиксировать нарушение?
❓ Когда подключать юридическую функцию?
Это тоже можно заранее описать.
И вот здесь плейбук перестает быть исключительно инструментом юридического отдела.
Бизнес-заказчик может использовать его как маршрут:
до договора → во время исполнения → при возникновении проблемы.
А юрист получает меньше ситуаций в формате:
«Мы уже все сделали, теперь посмотрите, что можно исправить».
На мой взгляд, именно в этом одна из самых сильных функций плейбука.
Он не только помогает быстрее проверять договоры.
Он помогает сделать работу со сделкой более управляемой для всей компании.
📅 10 сентября, 12:00
👤 Спикер - Людмила Харитонова, основатель Школы IT-юриста
⏩Регистрация на вебинар
| 2 |  Коллеги, 10 сентября в 12:00 Школа IT-юриста проведет вебинар для тех, кто устал пересобирать договоры на разработку с нуля.
Поговорим о том, как:
➕ перестать гадать - рискованно или нет
➕ защитить позицию исполнителя в спорных ситуациях
➕ и главное - получить готовый плейбук, который можно сразу адаптировать под свою компанию
А еще покажем, как с помощью ИИ проверять договоры быстрее и надёжнее.
📅 10 сентября, 12:00
🌐 Онлайн
👤 Спикер - Людмила Харитонова, основатель Школы IT-юриста
⏩Регистрация на вебинар
Приходите - заберете готовый инструмент и перестанете каждый договор изобретать заново. | 74 |
| 3 | Коллеги, 10 сентября в 12:00 Школа IT-юриста проведет вебинар для тех, кто устал пересобирать договоры на разработку с нуля.
Поговорим о том, как:
➕ перестать гадать - рискованно или нет
➕ защитить позицию исполнителя в спорных ситуациях
➕ и главное - получить готовый плейбук, который можно сразу адаптировать под свою компанию
А еще покажем, как с помощью ИИ проверять договоры быстрее и надёжнее.
📅 10 сентября, 12:00
🌐 Онлайн
👤 Спикер - Людмила Харитонова, основатель Школы IT-юриста
⏩Регистрация по ссылке
(ссылка)
Приходите - заберете готовый инструмент и перестанете каждый договор изобретать заново. | 1 |
| 4 |  💲 Мы уже проводили в Школе IT-юриста программу по налогообложению IT-компаний. Сейчас снова стали получать запросы на эту тему - и думаем о новом запуске.
Но просто повторять прежний курс не хотим.
Планируем обновить программу и сделать ее максимально прикладной: налоговые льготы IT-компаний, Сколково, РИД и НМА, работа с ФНС, налоговые проверки и другие ситуации, с которыми реально сталкивается технологический бизнес.
В программе хотим разбирать не только нормы законодательства, но и практические вопросы:
▫️ какие льготы действительно можно применять и при каких условиях
▫️ где компании чаще всего создают для себя налоговые риски
▫️ что проверяет ФНС
▫️ как связаны договоры, разработка ПО, права на РИД, НМА и налогообложение;
▫️ как подготовиться к требованиям и проверкам налоговой
▫️ какие документы и процессы должны быть внутри IT-компании.
Сейчас мы собираем предварительную группу и одновременно формируем программу нового потока.
Если тема вам актуальна - заполните короткую анкету https://forms.yandex.ru/cloud/6a9ac60590fa7b74b2714889
Это займет 3-5 минут.
Участникам предзаписи первым отправим программу, даты и специальные условия участия. | 97 |
| 5 |  3 сентября проведем новый вебинар для IT-компаний — о налоговых льготах, проверках и спорах с ФНС.
Сейчас вопрос уже не только в том, как получить льготу, а в том, как подтвердить право на нее и сохранить при проверке.
На вебинаре разберем:
⏩ какие льготы доступны IT-компаниям
⏩ чем IT-льготы отличаются от режима «Сколково»
⏩ как выбрать налоговую модель на 2027 год
⏩ какие доходы могут вызвать вопросы у ФНС
⏩ как договоры, акты и права на ПО влияют на налоговую позицию
⏩ что именно проверяет ФНС
⏩ какие документы лучше подготовить заранее
⏩ что делать, если требование уже пришло
Отдельно разберем практические ситуации:
⏩️ компания выросла, и старая налоговая модель перестала быть выгодной;
⏩️ ФНС спорит с составом IT-выручки
⏩️ ПО есть, но права на него оформлены не полностью
⏩️ разработка, продажи, сотрудники и IP находятся в разных юрлицах
⏩️ компания выбирает между IT-льготами и «Сколково»
📄 В финале дадим практический чек-лист: что IT-компании стоит проверить в налоговой модели до конца 2026 года.
3 сентября, 12:00–14:00
Онлайн.
Регистрация:
https://zarlaw.timepad.ru/event/4150188/ | 137 |
| 6 |  Мы привыкли говорить: IT-юрист, IT-право, договор на разработку, персональные данные, платформы, FinTech, AI.
Но если задать вполне академический вопрос — IT-право это самостоятельная отрасль права? — ответ оказывается совсем не очевидным.
В юридической науке существуют разные подходы. Одни исследователи говорят о цифровом праве как о самостоятельной отрасли. Другие — о комплексной отрасли «нового поколения». Третьи считают, что речь идет о части информационного права. Есть и позиция, что никакой новой отрасли вообще нет, а есть нормы гражданского, административного, трудового и других отраслей, которые применяются к технологиям.
А что тогда IT-право?
🔐 В Ассоциации юристов цифровой экономики мы предложили для дальнейшей дискуссии такую гипотезу:
ядром IT-права может быть не сама информация и даже не «цифровая форма», а отношения, возникающие вокруг жизненного цикла технологии и цифрового продукта — его создания, внедрения, эксплуатации и коммерциализации.
Тогда в один правовой контур логично собираются:
✔️ разработка ПО и цифровых продуктов
✔️ интеллектуальная собственность
✔️ данные и персональные данные
✔️ искусственный интеллект
✔️ цифровые платформы и маркетплейсы
✔️ FinTech и платежные технологии
✔️ API, SaaS и облачные сервисы
✔️ информационная безопасность
✔️ экспериментальные правовые режимы
❓Почему это важно практикующему IT-юристу?
Потому что хороший IT-юрист должен понимать не только, какую норму применить, но и как устроен сам цифровой продукт, какие отношения возникают вокруг него и почему технологический бизнес требует особой юридической архитектуры.
⏩️И отсюда возникает еще один важный вопрос:
а существует ли уже самостоятельный стандарт компетенций IT-юриста — и чем такой специалист должен отличаться от просто хорошего корпоративного юриста?
На сайте АЮЦЭ мы собрали большой обзор этой дискуссии — от ранних исследований права и информации до современных работ о цифровом и IT-праве.
Там же — подборка диссертаций, книг и научных статей, с которых можно начать изучение теории IT-права.
🚩Читать исследование:
https://lawyersnetwork.ru/it-pravo
А теперь интересно ваше мнение:
IT-право — это уже самостоятельная отрасль или все-таки профессиональная специализация, которая объединяет нормы разных отраслей? ⏬ | 148 |
| 7 |  Вебинар Школы IT-юриста: создаём плейбук для договора на разработку ПО
10 сентября в 12:00 проведу вебинар для юристов, которые сопровождают договоры на разработку программных продуктов.
Почему выбрали именно эту тему ❓
Потому что договор на разработку ПО кажется знакомым, пока проект не начинает жить своей жизнью.
Заказчик меняет требования.
Сроки сдвигаются.
Дополнительные работы никто не хочет оплачивать.
Приёмка затягивается.
Меняется команда заказчика — и всё согласованное приходится обсуждать заново.
Проект могут остановить на середине, а вопрос оплаты уже выполненной работы остаётся открытым.
И каждый новый договор снова приходится проверять практически с нуля.
На вебинаре покажу, как решить эту задачу через договорный плейбук.
Разберём:
⏩ключевые условия договора на разработку ПО именно со стороны исполнителя
⏩типовые ловушки и спорные ситуации
⏩как определить позицию компании, допустимые отклонения и «красные линии»
⏩как должна выглядеть структура рабочего плейбука
⏩как использовать его не только при согласовании договора, но и при сборе информации и дальнейшем исполнении проекта
⏩как на основе плейбука проверять договоры с помощью ИИ и Legal Tech.
Покажу структуру:
вопрос → риск → позиция компании → допустимое отклонение → красная линия → альтернативная формулировка → действие юриста.
⚠️ И главное: участники получат готовый плейбук для договора на разработку ПО со стороны исполнителя, который можно адаптировать под свою компанию и использовать в работе.
📅 10 сентября
⏰ 12:00–14:00
🌐 Онлайн
Спикер — Людмила Харитонова, основатель Школы IT-юриста, управляющий партнёр ЮК «Зарцын и партнеры».
👉 Регистрация на вебинар
Если вы регулярно работаете с договорами на разработку, приходите. Будем не просто обсуждать отдельные формулировки, а собирать систему, по которой такие договоры можно проверять быстрее и стабильнее. | 630 |
| 8 | Если вы начинаете работать с айти компанией, то первые 90 дней самые важные.
https://vc.ru/id3909923/3086688-kak-yuristu-uspeshno-adaptirovatsya-v-it-kompanii | 126 |
| 9 |  +5Что значит «юрист проектирует клиентский путь»?
В вакансии X5, которую мы разбирали в прошлом посте, среди задач руководителя юридического направления есть очень показательная формулировка:
«проектирование клиентских путей и верификация процессов сбора обязательных согласий»
Звучит уже скорее как задача product-менеджера, чем юриста.
Но именно так сегодня и выглядит работа юриста с цифровым продуктом.
Сначала: что такое клиентский путь?
Customer Journey Map, или CJM, — это карта того, как пользователь проходит через продукт: от первого контакта до покупки, использования сервиса и последующего взаимодействия с компанией.
Обычно на карте фиксируют: «этап → действие пользователя → точку контакта → ожидания → проблему → реакцию бизнеса».
Например: «увидел рекламу → пришёл на сайт → зарегистрировался → выбрал товар → оплатил → получил заказ → обратился в поддержку».
Причём нормальный CJM строится не из головы. Для него используют аналитику продукта, обращения в поддержку, интервью, отзывы и реальные пользовательские сценарии.
Но у юриста поверх этого пути появляется второй слой карты — юридический.
И вот здесь начинается самое интересное (см. картинки выше).
По итогам прохождения всех этапов получается юридический CJM. К обычной карте: «этап → действие → точка контакта → проблема» юрист добавляет свои строки: «правовое основание → документ → согласие → ПДн → договор → доказательство действия → риск → юридическое требование к продукту».
❓ Почему IT-юристу важно уметь работать с CJM? Потому что если юрист приходит в продукт только тогда, когда ему присылают готовую оферту, большая часть юридических решений уже принята без него: кнопки нарисованы, регистрация работает, данные собираются, рассылки отправляются, оплата настроена. И теперь юристу остается пытаться «наложить право» на уже работающий процесс.
⚠️ Гораздо эффективнее другой подход: сначала вместе с product-командой разбираем путь пользователя → определяем юридические требования → проектируем интерфейс и процессы → затем оформляем документы.
И, пожалуй, именно здесь проходит одна из главных границ между классическим юристом и IT-юристом, работающим с продуктом.
И это работает далеко не только в e-commerce. Так же можно проектировать клиентский путь для FinTech, EdTech, маркетплейсов, SaaS, мобильных приложений, сервисов подписки и практически любого цифрового продукта. | 151 |
| 10 | Что значит «юрист проектирует клиентский путь»?
В вакансии X5, которую мы разбирали в прошлом посте, среди задач руководителя юридического направления есть очень показательная формулировка:
«проектирование клиентских путей и верификация процессов сбора обязательных согласий»
Звучит уже скорее как задача product-менеджера, чем юриста.
Но именно так сегодня и выглядит работа юриста с цифровым продуктом.
Сначала: что такое клиентский путь?
Customer Journey Map, или CJM, — это карта того, как пользователь проходит через продукт: от первого контакта до покупки, использования сервиса и последующего взаимодействия с компанией.
Обычно на карте фиксируют: «этап → действие пользователя → точку контакта → ожидания → проблему → реакцию бизнеса».
Например: «увидел рекламу → пришёл на сайт → зарегистрировался → выбрал товар → оплатил → получил заказ → обратился в поддержку».
Причём нормальный CJM строится не из головы. Для него используют аналитику продукта, обращения в поддержку, интервью, отзывы и реальные пользовательские сценарии.
Но у юриста поверх этого пути появляется второй слой карты — юридический.
И вот здесь начинается самое интересное (см. картинки выше).
По итогам прохождения всех этапов получается юридический CJM. К обычной карте: «этап → действие → точка контакта → проблема» юрист добавляет свои строки: «правовое основание → документ → согласие → ПДн → договор → доказательство действия → риск → юридическое требование к продукту».
❓ Почему IT-юристу важно уметь работать с CJM? Потому что если юрист приходит в продукт только тогда, когда ему присылают готовую оферту, большая часть юридических решений уже принята без него: кнопки нарисованы, регистрация работает, данные собираются, рассылки отправляются, оплата настроена. И теперь юристу остается пытаться «наложить право» на уже работающий процесс.
⚠️ Гораздо эффективнее другой подход: сначала вместе с product-командой разбираем путь пользователя → определяем юридические требования → проектируем интерфейс и процессы → затем оформляем документы.
И, пожалуй, именно здесь проходит одна из главных границ между классическим юристом и IT-юристом, работающим с продуктом.
И это работает далеко не только в e-commerce. Так же можно проектировать клиентский путь для FinTech, EdTech, маркетплейсов, SaaS, мобильных приложений, сервисов подписки и практически любого цифрового продукта. | 1 |
| 11 | 3️⃣ Глубоко знать персональные данные
Именно «глубокие знания», а не просто знакомство с 152-ФЗ, отдельно указаны работодателем.
На практике это означает умение построить весь процесс:
сбор → хранение → использование → передача → уничтожение данных.
И определить:
⚪️ роли участников
⚪️ основания обработки
⚪️ необходимые согласия
⚪️ поручения на обработку
⚪️ локализацию
⚪️ трансграничную передачу
⚪️ требования к информационной безопасности
⚪️ действия при инцидентах
4️⃣ Знать рекламное законодательство
В требованиях оно стоит рядом с ПДн не случайно.
Цифровой сервис постоянно работает с:
⚪️ push
⚪️ email
⚪️ SMS
⚪️ персональными предложениями
⚪️ акциями
⚪️ рекламными интегра циями
И юрист должен понимать, где заканчивается сервисная коммуникация и начинается реклама.
5️⃣ Уметь работать с программами лояльности
Это отдельный юридический продукт:
⚪️ правила программы
⚪️ баллы
⚪️ скидки
⚪️ акции
⚪️ персональные предложения
⚪️ партнерские программы
⚪️ претензии пользователей
6️⃣ Уметь создавать юридическую модель нового бизнеса
В вакансии есть сопровождение инициатив по созданию новых направлений бизнеса.
Это одна из ключевых компетенций сильного IT-юриста.
Бизнес приходит с идеей:
«Хотим запустить новый сервис».
А юрист должен определить:
⚪️ юридическую модель
⚪️ участников
⚪️ договорную конструкцию
⚪️ пользовательские документы
⚪️ модель работы с данными
⚪️ распределение ответственности
⚪️ основные регуляторные ограничения
Не просто сказать «это рискованно», а предложить, как запустить.
7️⃣ Уметь сопровождать M&A-интеграцию
Очень интересный пункт — интеграция приобретённых бизнесов в правовой контур X5.
Здесь уже потребуются навыки:
⚪️ юридического аудита
⚪️ унификации договоров и документов
⚪️ проверки ПДн-процессов
⚪️ IP
⚪️ корпоративных вопросов
⚪️ перестройки внутренних процессов
8️⃣ Понимать ИБ, конфиденциальность и коммерческую тайну
Не обязательно самому быть специалистом по информационной безопасности.
Но нужно понимать, какие требования должны быть превращены в:
⚪️ договорные условия
⚪️ внутренние регламенты
⚪️ NDA
⚪️ режим коммерческой тайны
⚪️ процессы доступа к информации
9️⃣ Уметь управлять юридическим проектом
В требованиях прямо указаны навыки проектного управления.
То есть сильному IT-юристу сегодня нужно уметь:
⚪️ декомпозировать проект
⚪️ ставить задачи
⚪️ определять приоритеты
⚪️ собирать участников из разных функций
⚪️ контролировать сроки
⚪️ принимать решения при неполных данных
⚪️ доносить риски до бизнеса
🔟 Legal Tech и Legal Design
И отдельно интересно: знание инструментов Legal Tech и Legal Design указано как преимущество.
Это очень хороший маркер того, куда движется профессия.
Если собрать профиль кандидата
Для такой позиции нужно знать:
ГК РФ + договорное право + ПДн + реклама + цифровые продукты + пользовательские документы + программы лояльности + информационная безопасность + коммерческая тайна + Legal Tech + Legal Design + проектное управление.
И иметь ещё один важнейший навык:
уметь не только анализировать право, но и проектировать юридическую часть продукта вместе с бизнесом.
Именно поэтому мы в Школе всё чаще говорим: современный IT-юрист — это не человек, которому приносят готовый договор на проверку.
Он должен подключаться значительно раньше — в момент, когда продукт ещё проектируется.
Посмотреть вакансию на hh.ru | 149 |
| 12 |  Нашли вакансию X5 — руководитель юридического направления цифровых сервисов.
Требуется опыт от 6 лет. В подчинении — команда из 3 человек.
Но гораздо интереснее посмотреть не на стаж, а на то, какие задачи этому юристу предстоит решать.
Что будет делать юрист
В зоне ответственности:
▫️ мобильные приложения и сайты: «Перекрёсток Доставка», «Пятёрочка Доставка», 5Post и другие цифровые сервисы
▫️ пользовательские документы и оферты
▫️ проектирование клиентских путей и сбор обязательных согласий
▫️ программы лояльности
▫️ персональные данные и информационная безопасность
▫️ интеграция приобретённых бизнесов в контур X5
▫️ запуск новых бизнес-направлений
▫️ GR и нормотворчество
▫️ сложные кросс-функциональные проекты
То есть это уже далеко не классическая договорная работа.
Какие навыки за этим стоят?
1️⃣ Уметь сопровождать цифровой продукт
Юрист должен понимать, как работает сайт или приложение:
регистрация → авторизация → заказ → оплата → доставка → возврат → коммуникация с пользователем.
И на каждом этапе видеть юридические вопросы.
2️⃣ Уметь проектировать клиентский путь
Очень показательная задача в вакансии:
«проектирование клиентских путей и верификация процессов сбора обязательных согласий».
Это значит, что юрист должен уметь отвечать на вопросы:
⚪️ где пользователь принимает оферту
⚪️ когда нужно согласие на ПДн
⚪️ где необходимо отдельное рекламное согласие
⚪️ можно ли объединить согласия
⚪️ каким должен быть checkbox
⚪️ как зафиксировать акцепт
⚪️ какие доказательства останутся у компании.
Здесь юрист уже работает вместе с product, UX, разработчиками и маркетингом. | 155 |
| 13 |  ⚙️ Когда мы начали глубже работать с договорными плейбуками, то поняли , что на российском рынке под плейбуком часто понимают примерно следующее:
пункт договора ➡️правило проверки ➡️ рекомендуемая формулировка
Полезно. Но это скорее хороший чек-лист.
Полноценный договорной playbook отвечает на более сложный вопрос:
как компания принимает решения в ходе проверки и переговоров по договору и как строится работа после подписания договора?
И поэтому кроме рекомендованных формулировок в него могут входить:
1️⃣ Основная позиция компании
Почему такой договор выбран и какой вариант условий мы хотим получить в идеале.
2️⃣ Fall-back positions
Что делать, если контрагент не принимает нашу позицию.
На какую альтернативную редакцию юрист может согласиться самостоятельно?
Где заканчивается допустимый компромисс?
3️⃣ Стратегия переговоров
Какие положения обычно вызывают споры?
Где можно уступить относительно легко?
А по каким вопросам нужно отстаивать позицию компании?
4️⃣ Обоснование позиции
Почему мы вообще предлагаем контрагенту изменить условие?
Это особенно полезная часть плейбука.
Юристу не приходится писать:
«Такова позиция нашего юридического отдела».
Он получает готовую аргументацию, которую можно использовать в переговорах.
5️⃣ Точки эскалации
Плейбук должен отвечать:
▫️когда юрист принимает решение сам
▫️когда нужно подключить руководителя юрдепартамента
▫️когда вопрос должен уйти бизнес-заказчику, финансам или CEO
▫️какие отклонения от стандартной позиции вообще требуют дополнительного согласования
6️⃣ Согласование
Что происходит с договором дальше?
Кто согласовывает отклонение?
В какой последовательности?
Какие решения можно принимать автоматически?
И именно из этой части впоследствии может вырасти автоматизированный workflow согласования договора.
7️⃣Понятное объяснение юридических конструкций
Особенно если плейбуком должны пользоваться не только юристы.
Что означает ограничение ответственности?
Почему нам принципиальна определенная приемка?
Почему нельзя просто удалить гарантию или изменить порядок передачи IP?
Плейбук может переводить юридические конструкции на язык бизнеса.
8️⃣ Правила внесения изменений
Что делать, если контрагент не просто исправил нашу формулировку, а полностью заменил ее своей?
Что именно проверять?
В каких пределах текст можно менять?
Когда новая редакция требует повторного анализа?
💡И интересно посмотреть, насколько сами плейбуки распространяются в зарубежных юридических функциях.
Два разных исследования дают хороший срез ⚠️
Еще в 2018 году Sterling Miller писал, что плейбуки использовали менее 25% юридических департаментов.
Источник: Ten Things: Creating a Good Contract Playbook
А по данным LegalOn State of Contracting Survey 2025, формальные плейбуки есть уже примерно у половины внутренних юридических команд.
Среди крупных корпоративных юридических департаментов — примерно у 60%.
Но самое интересное число другое:
95% команд, использующих плейбуки, признают, что те не покрывают всю необходимую договорную работу.
Источник: LegalOn State of Contracting Survey 2025 — обзор LawNext | 81 |
| 14 |  Если у вас есть договор, с которым вы работаете чаще всего, мы бы шли так.
1️⃣ Берем договор за основу и превращаем его структуру в структуру плейбука
Каждый раздел договора становится отдельным разделом плейбука.
Например:
⚪️предмет
⚪️права и обязанности сторон
⚪️цена и расчеты
⚪️ответственность
⚪️интеллектуальная собственность
⚪️персональные данные
⚪️расторжение
Позже у вас, скорее всего, появится еще нулевой шаг — информация, которую нужно собрать до начала проверки, и отдельные шаги по исполнению договора после подписания.
2️⃣ Каждый пункт договора переводим в правило
Это можно делать вручную или с помощью ИИ.
Но после этого каждое правило нужно проверить на вопрос:
должно ли это условие быть в каждом договоре?
Если нет — убираем.
Плейбук не должен быть пересказом одного удачного шаблона. Он должен фиксировать правила, по которым юрист принимает решение.
3️⃣ Идем раздел за разделом и сразу тестируем
Не стоит сначала написать 50 страниц плейбука, а потом впервые попробовать его применить.
Сформировали правила по разделу — сразу проверяем.
Например:
⚪️специально вносим в договор ошибку
⚪️запускаем проверку
⚪️смотрим, сработало ли правило
⚪️если нет — переписываем
⚪️повторяем, пока результат не станет стабильным
Хорошее правило — это не то, которое красиво сформулировано.
Хорошее правило — то, которое стабильно работает на проверке договора.
4️⃣ Параллельно собираем «нулевой шаг»
По мере работы становится понятно, какой информации не хватает для нормальной проверки.
Например, для SaaS-договора это могут быть вопросы:
⚪️кто правообладатель ПО
⚪️B2B или B2C модель
⚪️вид лицензии
⚪️срок
⚪️территория
⚪️количество пользователей
⚪️есть ли SLA
⚪️кто обрабатывает данные
⚪️есть ли иностранная инфраструктура
Если проверку потом будет делать ИИ, эти вопросы становятся обязательным входным контекстом.
Без ответа на них проверку лучше вообще не запускать.
5️⃣ После сборки сверяем правила с законодательством
Отдельно собираем:
⚪️какие нормы регулируют отношения
⚪️какие из них императивные
⚪️какие диспозитивные
⚪️есть ли обязательные требования
⚪️не противоречат ли правила плейбука закону
Это важный этап: внутренние правила компании не должны жить отдельно от правовой базы.
6️⃣ Делаем то же самое с судебной практикой
Собираем релевантные споры и проверяем:
⚪️какие формулировки уже ⚪️становились проблемными
какие условия суды признают работающими
⚪️какие риски мы не учли
⚪️нужно ли менять правила плейбука
Именно здесь плейбук начинает превращаться из «нашего мнения» в систему, основанную на реальной практике.
7️⃣ Финально собираем нулевой и последующие шаги
Когда основной плейбук готов, возвращаемся к началу и концу процесса.
До проверки договора:
какую информацию нужно получить от бизнеса.
После подписания:
что нужно контролировать при исполнении.
Если возникает спор:
какие действия запускаются, кто принимает решение, какие документы нужно собрать.
В итоге хороший плейбук — это уже не инструкция «как проверить договор».
Это описание всего юридического процесса вокруг него.
⚠️И последнее.
Плейбук нельзя сделать один раз и забыть.
Мы советуем ставить обязательный review хотя бы раз в 6–12 месяцев:
▫️изменения закона
▫️новая судебная практика
▫️новые продукты
▫️новые риски
▫️изменения бизнес-модели
▫️обратная связь от юристов, которые по нему работают
Плейбук хорош не тогда, когда он длинный.
А когда по нему разные юристы принимают одинаково качественные решения. | 103 |
| 15 |  Когда мы говорим об автоматизации юридической работы, мне кажется, слишком часто обсуждаем инструменты и слишком редко — цифры.
Сколько времени процесс занимает сейчас ❔
Сколько времени потребуется, чтобы его автоматизировать ❔
Через какое количество повторений инвестиция окупится ❔
И еще один вопрос, который почему-то задают совсем редко:
что юристы будут делать с тем временем, которое мы им освободим?
Потому что автоматизация сама по себе не является целью.
Если юрист тратил четыре часа на договор, а после внедрения инструмента будет тратить час — компания получила три часа. Но экономический эффект появляется только тогда, когда понятно, куда эти три часа направить.
Например, на более сложные сделки, работу с продуктом, судебные риски, взаимодействие с бизнесом или сокращение внешних расходов.
И еще важный момент: при автоматизации не случится магии.
Подготовительный этап вполне может занимать несколько дней, недель, а в сложных процессах — месяцев.
Вот реальный пример из нашей работы.
👤 Есть юридический департамент крупной компании.
Одна из регулярных задач — анализ договора генерального подряда.
Договор около 70 страниц.
Процесс стандартный:
получить договор → проверить → внести правки → запустить согласование.
Первичный анализ такого договора занимает у юриста в среднем 3–4 часа.
Мы начали собирать для этого процесса плейбук.
Зачем?
1️⃣ Зафиксировать правила проверки.
Чтобы экспертиза не оставалась только в голове конкретного юриста и ее можно было быстро передавать новым коллегам.
2️⃣ Сделать правила обновляемыми.
Изменилась судебная практика, законодательство или позиция компании — мы меняем соответствующее правило, а не пытаемся объяснить всей команде новую логику проверки.
3️⃣ Сократить время анализа каждого следующего договора.
ИИ в этой конструкции нужен не для того, чтобы самостоятельно решить, «хороший» перед ним договор или «плохой».
Он должен проверить договор по заранее определенным правилам компании и показать отклонения.
И теперь немного цифр.
На разработку и тестирование первых двух разделов плейбука ушло около 3 часов.
Причем сюда входит не только написание правил.
Мы проверяли, правильно ли они срабатывают на договоре, уточняли формулировки, исправляли слишком широкие или слишком узкие критерии.
На завершение плейбука, по моей оценке, потребуется еще примерно 10–15 часов.
То есть общая инвестиция — порядка 13–18 часов работы.
Много?
Если посмотреть только на создание плейбука — вполне.
Но если один стандартный договор сегодня требует 3–4 часа анализа, экономика быстро меняется.
⚙️ По нашей предварительной оценке, затраты на создание плейбука могут окупиться уже примерно на пятом договоре.
А шестой, десятый, двадцатый договор уже дают чистую экономию времени.
И по ходу работы обнаружился еще один эффект, которого мы сначала вообще не ставили целью.
💡Плейбук начал улучшать сам договор
Когда мы стали последовательно прогонять правила, стали хорошо видны:
⏩️ неоднозначные формулировки
⏩️ положения, которые дублируют друг друга
⏩️ лишние конструкции
⏩️ места, где сам текст договора создает ненужную сложность для проверки.
В результате появилась еще одна задача: упростить сам шаблон договора.
И это, на мой взгляд, очень важная часть автоматизации.
Иногда для того, чтобы быстрее проверять документ, нужно не создавать более сложный ИИ-инструмент.
Нужно сначала сделать проще сам процесс и проще документ.
Поэтому, прежде чем автоматизировать очередную задачу юридического отдела, я бы посчитала четыре вещи:
📶 Сколько часов в месяц мы тратим на этот процесс сейчас?
📶 Сколько повторений такого процесса у нас происходит?
📶 Сколько часов потребуется на стандартизацию и автоматизацию?
📶 Что мы сделаем с высвободившимся временем юристов?
Потому что хороший проект автоматизации — это не «мы внедрили ИИ».
Это, например:
было 4 часа на договор → стало 40 минут → 20 таких договоров в месяц → получили десятки часов юридической команды на более сложную работу.
Вот тогда становится понятно, зачем вообще всё это делать. | 381 |
| 16 | Плейбук_проверки_договора_поставки_с_монтажом.pdf | 631 |
| 17 |  Например, собрать рабочий плейбук для проверки договоров.
На тренинге по ИИ мы взяли конкретную задачу: компания регулярно заключает договоры поставки с монтажом.
И вместо очередного промта «проверь договор и найди риски» пошли другим путем.
Сначала вместе сформулировали правила компании, по которым такие договоры должны проверяться.
Например:
⏩️ договор должен оставаться именно договором поставки, несмотря на наличие монтажа
⏩️ изготовление идет по ТЗ, чертежам и размерам заказчика, и он отвечает за корректность этих данных
⏩️ производство не начинается до получения необходимых материалов и аванса
⏩️ минимальный аванс — 30%
⏩️ сроки поставки и монтажа не могут быть меньше установленных компанией
⏩️ дополнительные работы должны отдельно согласовываться и оплачиваться.
А потом превратили эти правила в плейбук, по которому ИИ может проверять каждый следующий договор.
Для каждого условия есть три статуса:
СООТВЕТСТВУЕТ
НЕ СООТВЕТСТВУЕТ
ОТСУТСТВУЕТ
Причем если в договоре недостаточно информации, ИИ не должен «додумывать», что все нормально. Условие признается отсутствующим и уходит юристу на доработку.
Почему мне нравится эта конструкция.
Плейбук — это не только инструмент проверки договора. Это точка сбора экспертизы юридической команды.
Появился новый проблемный кейс — добавили правило.
Изменилась позиция бизнеса — обновили правило.
Нашли риск, который раньше пропускали, — зафиксировали его в плейбуке.
То есть знания перестают оставаться исключительно «в голове» конкретного юриста.
И есть еще следующий уровень.
В такой плейбук можно добавить типовой промт-интервью, который до начала анализа задаст вопросы юристу и бизнес-заказчику:
❓ что за сделка
❓ кто контрагент
❓ насколько он важен
❓ какие коммерческие условия для бизнеса критичны
❓ чем мы готовы поступиться
❓ какие риски принять нельзя
И тогда получается уже полноценный процесс:
контекст сделки → вопросы → правила компании → проверка договора → рекомендации юристу.
Не «100 универсальных промтов для юриста», а собственная юридическая база знаний, поверх которой работает ИИ.
💲А сам плейбук, который мы сделали на занятии, решила не прятать — отдаем целиком. Можно брать за основу и переделывать под свои типы договоров. | 653 |
| 18 |  📅30 июля | 12:00 (МСК)
Налоговые льготы для IT-компаний — это не только аккредитация. ФНС проверяет фактическую деятельность компании, структуру выручки, договоры, права на ПО и подтверждающие документы.
На вебинаре разберем:
▫️ какие условия необходимо соблюдать для применения льгот
▫️ что именно проверяет ФНС
▫️ какие доходы относятся к IT-выручке
▫️ какие документы подтверждают право на льготы
▫️ как провести аудит IT-деятельности и выявить риски до налоговой проверки
В конце вебинара вы получите чек-лист для самостоятельной проверки IT-деятельности и сможете задать вопросы эксперту.
⚠️Ждем вас уже завтра в 12:00 (МСК)!
Регистрация : https://zarlaw.timepad.ru/event/4091330/ | 170 |
| 19 |  Юристу, который работает с IT-компаниями, недостаточно знать только лицензионные договоры, персональные данные и интеллектуальную собственность.
Нужно понимать, как команда вообще создает продукт:
⚫️откуда появляются требования
⚫️почему задачи меняются по ходу проекта
⚫️что такое backlog, sprint и MVP
⚫️кто отвечает за сроки
⚫️когда результат уже можно считать готовым
⚫️почему разработчики не всегда могут заранее назвать точную цену и дату
Без этого юрист часто пишет документы в отрыве от реальной разработки.
Собрали три книги, с которых можно начать.
1️⃣ Джеймс Шор, Шейн Уорден
«Искусство Agile-разработки. Теория и практика гибкой разработки ПО»
Это книга не только про Scrum и совещания команды.
Она помогает понять саму логику гибкой разработки:
⚪️почему продукт создают итерациями
⚪️зачем команда постоянно получает обратную связь
⚪️почему требования могут меняться
⚪️как связаны Agile, DevOps и непрерывная поставка
⚪️что позволяет регулярно выпускать новые функции
Зачем это IT-юристу
После книги проще:
🟤оценивать договоры разработки по Agile
🟤описывать порядок постановки и приемки задач
🟤не требовать одно исчерпывающее ТЗ на весь проект
🟤различать изменение объема работ и обычное уточнение требований
🟤понимать, почему передача результата происходит не один раз в самом конце
Особенно полезно читать тем, кто сопровождает заказную разработку, SaaS и продуктовые команды.
Книга на Ozon
2️⃣ Владимир Завертайлов
«Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами»
Книга дает практическую картину управления IT-проектом с учетом российских реалий.
В ней разбираются:
⚪️постановка и декомпозиция задач
⚪️технические задания и backlog
⚪️управление требованиями
⚪️оценки сроков
⚪️работа собственной команды и подрядчиков
⚪️экономика проекта и продукта
⚪️ различия между Scrum, Kanban и другими подходами
Зачем это IT-юристу
Чтобы понимать, что происходит между подписанием договора и актом:
🟤кто ставит задачи разработчикам
🟤почему сроки пересматриваются
🟤где фиксируется объем работ
🟤как возникает дополнительный бюджет
🟤чем проектная работа отличается от технической поддержки;
🟤почему нельзя одинаково регулировать разработку собственной командой и внешний подряд.
Эта книга особенно полезна юристам, которые участвуют в переговорах с product- и project-менеджерами.
Книга на Ozon
3️⃣ Дэн Олсен
«MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям»
Книга объясняет, как команда переходит от идеи к продукту, который действительно нужен пользователям.
Внутри:
⚪️поиск потребностей аудитории
⚪️сегментация пользователей
⚪️ценностное предложение
⚪️создание прототипа
⚪️тестирование MVP
⚪️работа с пользовательским опытом
⚪️развитие продукта на основе обратной связи
Зачем это IT-юристу
Чтобы перестать воспринимать продукт как уже готовый набор функций.
Юрист начинает лучше понимать:
🟤 почему сначала запускают ограниченную версию
🟤какие документы действительно нужны на этапе MVP
🟤почему не стоит перегружать старт сложными юридическими конструкциями;
🟤какие риски критичны до запуска, а какие можно закрывать по мере развития;
🟤как юридические требования влияют на пользовательский путь и конверсию.
Это особенно важно для стартапов, платформ и новых сервисов внутри крупных компаний.
Книга на Ozon
🚩В каком порядке читать
Начните с «MVP», чтобы понять, зачем и для кого создается продукт.
Затем переходите к «Настольной книге project-менеджера», чтобы увидеть, как организуется работа команды.
После этого читайте «Искусство Agile-разработки» — для более глубокого понимания самого процесса разработки.
⚠️Главная мысль:
Сильный IT-юрист знает не только право. Он понимает, как продукт придумывают, разрабатывают, тестируют, запускают и изменяют.
Тогда договор перестает быть отдельным документом и становится частью реального процесса разработки. | 342 |
| 20 | 📩Готовый пример:
Добрый день!
Откликаюсь на вакансию IT-юриста. В описании позиции меня заинтересовали задачи по сопровождению цифрового продукта, работе с договорами разработки и оформлению прав на программное обеспечение.
Сейчас я самостоятельно готовлю договоры с подрядчиками, проверяю условия о передаче исключительных прав и участвую в согласовании документов с бизнес-подразделениями. Также работал с вопросами персональных данных и пользовательскими документами для сайта.
Я изучил продукт компании и понимаю, что юристу в этой роли важно не только составлять договоры, но и учитывать логику сервиса, взаимодействие с партнерами и путь пользователя.
Буду рад обсудить, как мой опыт может быть полезен вашей команде.
Что убрать из письма
➖ «Коммуникабельный и стрессоустойчивый» без примеров
➖ пересказ всего резюме
➖ длинную историю своей карьеры
➖ комплименты компании, которые можно отправить любому работодателю
➖ фразу «у меня нет опыта, но дайте мне шанс»
➖ требования к зарплате, если об этом не просили
➖ шаблон на несколько экранов
Хорошее сопроводительное письмо обычно занимает 5–8 коротких абзацев.
Главное правило:
Не рассказывайте работодателю все о себе. Покажите, почему ваш опыт отвечает именно на эту вакансию. | 233 |
