Школа IT юриста

⚙️ Когда мы начали глубже работать с договорными плейбуками, то поняли , что на российском рынке под плейбуком часто понимают примерно следующее: пункт договора ➡️правило проверки ➡️ рекомендуемая формулировка Полезно. Но это скорее хороший чек-лист. Полноценный договорной 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

Если у вас есть договор, с которым вы работаете чаще всего, мы бы шли так. 1️⃣ Берем договор за основу и превращаем его структуру в структуру плейбука Каждый раздел договора становится отдельным разделом плейбука. Например: ⚪️предмет ⚪️права и обязанности сторон ⚪️цена и расчеты ⚪️ответственность ⚪️интеллектуальная собственность ⚪️персональные данные ⚪️расторжение Позже у вас, скорее всего, появится еще нулевой шаг — информация, которую нужно собрать до начала проверки, и отдельные шаги по исполнению договора после подписания. 2️⃣ Каждый пункт договора переводим в правило Это можно делать вручную или с помощью ИИ. Но после этого каждое правило нужно проверить на вопрос: должно ли это условие быть в каждом договоре? Если нет — убираем. Плейбук не должен быть пересказом одного удачного шаблона. Он должен фиксировать правила, по которым юрист принимает решение. 3️⃣ Идем раздел за разделом и сразу тестируем Не стоит сначала написать 50 страниц плейбука, а потом впервые попробовать его применить. Сформировали правила по разделу — сразу проверяем. Например: ⚪️специально вносим в договор ошибку ⚪️запускаем проверку ⚪️смотрим, сработало ли правило ⚪️если нет — переписываем ⚪️повторяем, пока результат не станет стабильным Хорошее правило — это не то, которое красиво сформулировано. Хорошее правило — то, которое стабильно работает на проверке договора. 4️⃣ Параллельно собираем «нулевой шаг» По мере работы становится понятно, какой информации не хватает для нормальной проверки. Например, для SaaS-договора это могут быть вопросы: ⚪️кто правообладатель ПО ⚪️B2B или B2C модель ⚪️вид лицензии ⚪️срок ⚪️территория ⚪️количество пользователей ⚪️есть ли SLA ⚪️кто обрабатывает данные ⚪️есть ли иностранная инфраструктура Если проверку потом будет делать ИИ, эти вопросы становятся обязательным входным контекстом. Без ответа на них проверку лучше вообще не запускать. 5️⃣ После сборки сверяем правила с законодательством Отдельно собираем: ⚪️какие нормы регулируют отношения ⚪️какие из них императивные ⚪️какие диспозитивные ⚪️есть ли обязательные требования ⚪️не противоречат ли правила плейбука закону Это важный этап: внутренние правила компании не должны жить отдельно от правовой базы. 6️⃣ Делаем то же самое с судебной практикой Собираем релевантные споры и проверяем: ⚪️какие формулировки уже становились проблемными ⚪️какие условия суды признают работающими ⚪️какие риски мы не учли ⚪️нужно ли менять правила плейбука Именно здесь плейбук начинает превращаться из «нашего мнения» в систему, основанную на реальной практике. 7️⃣ Финально собираем нулевой и последующие шаги Когда основной плейбук готов, возвращаемся к началу и концу процесса. До проверки договора: какую информацию нужно получить от бизнеса. После подписания: что нужно контролировать при исполнении. Если возникает спор: какие действия запускаются, кто принимает решение, какие документы нужно собрать. В итоге хороший плейбук — это уже не инструкция «как проверить договор». Это описание всего юридического процесса вокруг него. ⚠️И последнее. Плейбук нельзя сделать один раз и забыть. Мы советуем ставить обязательный review хотя бы раз в 6–12 месяцев: ▫️изменения закона ▫️новая судебная практика ▫️новые продукты ▫️новые риски ▫️изменения бизнес-модели ▫️обратная связь от юристов, которые по нему работают Плейбук хорош не тогда, когда он длинный. А когда по нему разные юристы принимают одинаково качественные решения.

Когда мы говорим об автоматизации юридической работы, мне кажется, слишком часто обсуждаем инструменты и слишком редко — цифры. Сколько времени процесс занимает сейчас ❔ Сколько времени потребуется, чтобы его автоматизировать ❔ Через какое количество повторений инвестиция окупится ❔ И еще один вопрос, который почему-то задают совсем редко: что юристы будут делать с тем временем, которое мы им освободим? Потому что автоматизация сама по себе не является целью. Если юрист тратил четыре часа на договор, а после внедрения инструмента будет тратить час — компания получила три часа. Но экономический эффект появляется только тогда, когда понятно, куда эти три часа направить. Например, на более сложные сделки, работу с продуктом, судебные риски, взаимодействие с бизнесом или сокращение внешних расходов. И еще важный момент: при автоматизации не случится магии. Подготовительный этап вполне может занимать несколько дней, недель, а в сложных процессах — месяцев. Вот реальный пример из нашей работы. 👤 Есть юридический департамент крупной компании. Одна из регулярных задач — анализ договора генерального подряда. Договор около 70 страниц. Процесс стандартный: получить договор → проверить → внести правки → запустить согласование. Первичный анализ такого договора занимает у юриста в среднем 3–4 часа. Мы начали собирать для этого процесса плейбук. Зачем? 1️⃣ Зафиксировать правила проверки. Чтобы экспертиза не оставалась только в голове конкретного юриста и ее можно было быстро передавать новым коллегам. 2️⃣ Сделать правила обновляемыми. Изменилась судебная практика, законодательство или позиция компании — мы меняем соответствующее правило, а не пытаемся объяснить всей команде новую логику проверки. 3️⃣ Сократить время анализа каждого следующего договора. ИИ в этой конструкции нужен не для того, чтобы самостоятельно решить, «хороший» перед ним договор или «плохой». Он должен проверить договор по заранее определенным правилам компании и показать отклонения. И теперь немного цифр. На разработку и тестирование первых двух разделов плейбука ушло около 3 часов. Причем сюда входит не только написание правил. Мы проверяли, правильно ли они срабатывают на договоре, уточняли формулировки, исправляли слишком широкие или слишком узкие критерии. На завершение плейбука, по моей оценке, потребуется еще примерно 10–15 часов. То есть общая инвестиция — порядка 13–18 часов работы. Много? Если посмотреть только на создание плейбука — вполне. Но если один стандартный договор сегодня требует 3–4 часа анализа, экономика быстро меняется. ⚙️ По нашей предварительной оценке, затраты на создание плейбука могут окупиться уже примерно на пятом договоре. А шестой, десятый, двадцатый договор уже дают чистую экономию времени. И по ходу работы обнаружился еще один эффект, которого мы сначала вообще не ставили целью. 💡Плейбук начал улучшать сам договор Когда мы стали последовательно прогонять правила, стали хорошо видны: ⏩️ неоднозначные формулировки ⏩️ положения, которые дублируют друг друга ⏩️ лишние конструкции ⏩️ места, где сам текст договора создает ненужную сложность для проверки. В результате появилась еще одна задача: упростить сам шаблон договора. И это, на мой взгляд, очень важная часть автоматизации. Иногда для того, чтобы быстрее проверять документ, нужно не создавать более сложный ИИ-инструмент. Нужно сначала сделать проще сам процесс и проще документ. Поэтому, прежде чем автоматизировать очередную задачу юридического отдела, я бы посчитала четыре вещи: 📶 Сколько часов в месяц мы тратим на этот процесс сейчас? 📶 Сколько повторений такого процесса у нас происходит? 📶 Сколько часов потребуется на стандартизацию и автоматизацию? 📶 Что мы сделаем с высвободившимся временем юристов? Потому что хороший проект автоматизации — это не «мы внедрили ИИ». Это, например: было 4 часа на договор → стало 40 минут → 20 таких договоров в месяц → получили десятки часов юридической команды на более сложную работу. Вот тогда становится понятно, зачем вообще всё это делать.

Например, собрать рабочий плейбук для проверки договоров. На тренинге по ИИ мы взяли конкретную задачу: компания регулярно заключает договоры поставки с монтажом. И вместо очередного промта «проверь договор и найди риски» пошли другим путем. Сначала вместе сформулировали правила компании, по которым такие договоры должны проверяться. Например: ⏩️ договор должен оставаться именно договором поставки, несмотря на наличие монтажа ⏩️ изготовление идет по ТЗ, чертежам и размерам заказчика, и он отвечает за корректность этих данных ⏩️ производство не начинается до получения необходимых материалов и аванса ⏩️ минимальный аванс — 30% ⏩️ сроки поставки и монтажа не могут быть меньше установленных компанией ⏩️ дополнительные работы должны отдельно согласовываться и оплачиваться. А потом превратили эти правила в плейбук, по которому ИИ может проверять каждый следующий договор. Для каждого условия есть три статуса: СООТВЕТСТВУЕТ НЕ СООТВЕТСТВУЕТ ОТСУТСТВУЕТ Причем если в договоре недостаточно информации, ИИ не должен «додумывать», что все нормально. Условие признается отсутствующим и уходит юристу на доработку. Почему мне нравится эта конструкция. Плейбук — это не только инструмент проверки договора. Это точка сбора экспертизы юридической команды. Появился новый проблемный кейс — добавили правило. Изменилась позиция бизнеса — обновили правило. Нашли риск, который раньше пропускали, — зафиксировали его в плейбуке. То есть знания перестают оставаться исключительно «в голове» конкретного юриста. И есть еще следующий уровень. В такой плейбук можно добавить типовой промт-интервью, который до начала анализа задаст вопросы юристу и бизнес-заказчику: ❓ что за сделка ❓ кто контрагент ❓ насколько он важен ❓ какие коммерческие условия для бизнеса критичны ❓ чем мы готовы поступиться ❓ какие риски принять нельзя И тогда получается уже полноценный процесс: контекст сделки → вопросы → правила компании → проверка договора → рекомендации юристу. Не «100 универсальных промтов для юриста», а собственная юридическая база знаний, поверх которой работает ИИ. 💲А сам плейбук, который мы сделали на занятии, решила не прятать — отдаем целиком. Можно брать за основу и переделывать под свои типы договоров.

📅30 июля | 12:00 (МСК) Налоговые льготы для IT-компаний — это не только аккредитация. ФНС проверяет фактическую деятельность компании, структуру выручки, договоры, права на ПО и подтверждающие документы. На вебинаре разберем: ▫️ какие условия необходимо соблюдать для применения льгот ▫️ что именно проверяет ФНС ▫️ какие доходы относятся к IT-выручке ▫️ какие документы подтверждают право на льготы ▫️ как провести аудит IT-деятельности и выявить риски до налоговой проверки В конце вебинара вы получите чек-лист для самостоятельной проверки IT-деятельности и сможете задать вопросы эксперту. ⚠️Ждем вас уже завтра в 12:00 (МСК)! Регистрация : https://zarlaw.timepad.ru/event/4091330/

Юристу, который работает с 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-юрист знает не только право. Он понимает, как продукт придумывают, разрабатывают, тестируют, запускают и изменяют. Тогда договор перестает быть отдельным документом и становится частью реального процесса разработки.

📩Готовый пример: Добрый день! Откликаюсь на вакансию IT-юриста. В описании позиции меня заинтересовали задачи по сопровождению цифрового продукта, работе с договорами разработки и оформлению прав на программное обеспечение. Сейчас я самостоятельно готовлю договоры с подрядчиками, проверяю условия о передаче исключительных прав и участвую в согласовании документов с бизнес-подразделениями. Также работал с вопросами персональных данных и пользовательскими документами для сайта. Я изучил продукт компании и понимаю, что юристу в этой роли важно не только составлять договоры, но и учитывать логику сервиса, взаимодействие с партнерами и путь пользователя. Буду рад обсудить, как мой опыт может быть полезен вашей команде. Что убрать из письма ➖ «Коммуникабельный и стрессоустойчивый» без примеров ➖ пересказ всего резюме ➖ длинную историю своей карьеры ➖ комплименты компании, которые можно отправить любому работодателю ➖ фразу «у меня нет опыта, но дайте мне шанс» ➖ требования к зарплате, если об этом не просили ➖ шаблон на несколько экранов Хорошее сопроводительное письмо обычно занимает 5–8 коротких абзацев. Главное правило: Не рассказывайте работодателю все о себе. Покажите, почему ваш опыт отвечает именно на эту вакансию.

Так выглядит большинство сопроводительных писем. Проблема не в том, что оно плохое. Проблема в том, что оно ничего не добавляет к резюме и не отвечает на главный вопрос работодателя: Почему именно этого кандидата стоит позвать на собеседование? Сопроводительное письмо — это не вежливое приложение к резюме. Это короткий ответ на вакансию. Как читать вакансию Не начинайте с текста письма. Сначала разберите вакансию на четыре блока. 1️⃣ Какие задачи предстоит решать Ищите глаголы: — разрабатывать договоры — сопровождать IT-продукты — консультировать продуктовую команду — работать с персональными данными — оформлять права на программное обеспечение — вести претензионную работу — взаимодействовать с регуляторами Именно задачи, а не красивое описание компании, должны стать основой письма. 2️⃣ Какие знания нужны Например: — интеллектуальная собственность — лицензионные договоры — персональные данные — реклама — электронная коммерция — налоговые льготы для IT — платформенные модели — английский язык Не нужно переносить в письмо весь список. Выберите два-три требования, по которым у вас есть наиболее убедительное подтверждение. 3️⃣ Что для работодателя особенно важно Смотрите, что повторяется в вакансии или вынесено отдельно: — опыт именно в IT — самостоятельность — способность работать с бизнесом — умение объяснять сложное простым языком — интерес к продукту — готовность выстраивать процессы с нуля Это и есть скрытый приоритет работодателя. 4️⃣ Какой у компании продукт Перед откликом нужно понять: — что компания продает — кто ее пользователь — как она зарабатывает — какую роль в продукте выполняет юрист — какие юридические риски здесь наиболее вероятны Фраза «мне интересна ваша компания» ничего не доказывает. А фраза: «Мне интересна ваша вакансия, поскольку компания развивает B2B-платформу, где юридическая работа связана не только с договорами, но и с архитектурой продукта, распределением ответственности и обработкой персональных данных» показывает, что кандидат хотя бы изучил бизнес. ⚠️Что переносить из вакансии в письмо Не копируйте требования дословно. На каждое важное требование дайте свое подтверждение. В вакансии: «Сопровождение договорной работы». В письме: «В текущей работе я самостоятельно готовлю и согласовываю лицензионные договоры, договоры разработки и соглашения с подрядчиками». В вакансии: «Консультирование продуктовых команд». В письме: «Работал с разработчиками и product-менеджером при запуске сервиса: определял договорную модель и переводил юридические требования в задачи для команды». В вакансии: «Знание законодательства о персональных данных». В письме: «Проводил аудит форм сбора данных, готовил согласия и политику, участвовал в оформлении отношений с обработчиками». В вакансии: «Опыт в IT необязателен». В письме: «Прямого опыта в IT-компании у меня пока нет, но я изучил продукт, прошел обучение по IT-праву и могу показать проекты, в которых работал с лицензиями, ПДн и договорами разработки». Конструктор сопроводительного письма Хорошее письмо можно собрать из четырех частей. 1. Почему вы откликаетесь именно сюда Добрый день! Откликаюсь на вакансию IT-юриста, потому что мне интересна работа с цифровыми продуктами и задачами на стыке договорного права, интеллектуальной собственности и персональных данных. 2. Какие задачи из вакансии вы уже решали В вакансии указаны сопровождение договоров разработки, оформление прав на ПО и консультирование продуктовой команды. На текущем месте я готовлю договоры с разработчиками и подрядчиками, участвую в приемке результатов и проверяю оформление исключительных прав. 3. Что вы понимаете о продукте компании Я посмотрел продукт компании и обратил внимание, что юридическая функция здесь должна учитывать не только договоры, но и пользовательские сценарии, партнерские интеграции и обработку данных. 4. Что предлагаете дальше Буду рад обсудить, как мой опыт может быть полезен вашей команде. Резюме и примеры релевантных задач приложил.

Сегодня на вебинаре мы много говорили о том, что одного правильно составленного договора с самозанятым уже недостаточно. Суды смотрят не на название договора, а на фактическую модель работы. Что помогло компании отбить доначисления: ⏩️ отдельные задания и понятный результат ⏩️оплата после приемки работ ⏩️ размер вознаграждения зависел от объема ⏩️ не было постоянного графика ⏩️ не было рабочего места и включенности в штат ⏩️ компания объяснила, почему постоянный сотрудник ей не нужен. Что, наоборот, убедило суд в наличии трудовых отношений: ▫️ работа с 08:00 до 17:00 ▫️ контроль со стороны заказчика ▫️ совместная работа со штатными сотрудниками ▫️ регулярные ежемесячные выплаты ▫️ типовые договоры без конкретного объема и результата ▫️ почти весь доход самозанятых от одного заказчика ▫️ отсутствие собственных материалов, оборудования и реальной самостоятельности.  📌Главный вывод: регулярность сама по себе еще не означает трудовые отношения. Но если компания покупает не конкретный результат, а фактически рабочее время человека, договор с СМЗ не спасет. Проверять нужно не только документы, но и: ▪️ постановку задач ▪️ переписку ▪️ график ▪️ орядок контроля ▪️ выплаты ▪️ акты ▪️ доступы ▪️ фактическую роль исполнителя. Если хотите проверить модель работы с самозанятыми до запроса ФНС, оставьте заявку на аудит:  https://zarlaw.tilda.ws/anketayd См. подробнее: - Постановление АС Уральского округа от 13.05.2025 № Ф09-1232/25 по делу № А60-28456/2024; - Постановление АС Центрального округа от 27.04.2026 № Ф10-509/2026 по делу № А85-2081/2024; - Постановление АС Дальневосточного округа от 27.02.2026 № Ф03-141/2026 по делу № А04-2065/2025.

А что в таком проекте делает IT-юрист? В распределительном центре «Мираторга» автономные роботы перевозят паллеты между конвейером и зоной хранения. Они работают круглосуточно, самостоятельно заряжаются и выдерживают температуру до –20 °C. Со стороны кажется, что это исключительно задача инженеров и разработчиков. Но запуск промышленной роботизации требует серьезной юридической работы. Какие задачи решает IT-юрист ? 1️⃣Определяет предмет договора Что именно приобретает заказчик: 🟤оборудование 🟤программное обеспечение 🟤услуги по внедрению 🟤доступ к системе управления роботами 🟤техническую поддержку Важно разделить результат каждого этапа и установить критерии его приемки. 2️⃣Закрепляет требования к системе В договоре должны быть зафиксированы: ⚪️ производительность роботов ⚪️ температурный режим ⚪️ допустимый процент простоев ⚪️ требования к безопасности ⚪️ сроки реакции на сбои ⚪️ порядок масштабирования решения Формулировки «система должна работать стабильно» здесь недостаточно. 3️⃣Распределяет ответственность Кто отвечает, если робот: 🟤повредит товар или складское оборудование 🟤 остановит производственный процесс 🟤 создаст угрозу сотруднику 🟤 неправильно выполнит задачу 🟤 потеряет связь с системой управления Особенно важно разделить ответственность разработчика, поставщика оборудования, интегратора и заказчика. 4️⃣Оформляет права на программное обеспечение Нужно проверить, кому принадлежат права на: ⚪️ систему управления роботами ⚪️ доработки под конкретный склад ⚪️ интерфейсы и интеграционные модули ⚪️ техническую документацию ⚪️ данные, формируемые системой И отдельно предусмотреть, сможет ли заказчик продолжить эксплуатацию системы при прекращении отношений с интегратором. 5️⃣Регулирует работу с данными и информационную безопасность Даже если решение не интегрировано напрямую с WMS, оно получает сведения о маршрутах, заданиях, загрузке склада и движении продукции. Юристу необходимо определить: 🟤 состав передаваемых данных 🟤 места их хранения 🟤 правила доступа 🟤 требования к защите 🟤 порядок уведомления об инцидентах 6️⃣Организует опытную и промышленную эксплуатацию До полноценного запуска обычно нужны: ⚪️ пилотный проект ⚪️ программа и методика испытаний ⚪️ акт готовности инфраструктуры ⚪️ обучение сотрудников ⚪️ регламент действий при аварии ⚪️ критерии перехода в промышленную эксплуатацию 7️⃣Роботизация — хороший пример того, как меняется работа IT-юриста. Он уже не просто согласовывает договор на поставку техники. Он помогает юридически спроектировать всю систему: от пилота и прав на ПО до ответственности за остановку склада. И чем глубже технологии входят в реальные производственные процессы, тем выше цена одной неточной формулировки в договоре.

Продолжаем смотреть вакансии крупных технологических компаний не только ради возможности откликнуться, но и чтобы понять: какие компетенции сегодня действительно нужны юристу в IT-бизнесе. На этот раз Т-Банк ищет юриста, который будет заниматься объектами интеллектуальной собственности, кроме программного обеспечения. Кого ищут Юриста с опытом работы в сфере интеллектуальной собственности от трех лет, который умеет самостоятельно: ⚪️регистрировать товарные знаки в России и за рубежом ⚪️работать по национальной и Мадридской процедурам ⚪️проводить предварительные поиски и оценивать возможность регистрации обозначения ⚪️отвечать на уведомления и возражения патентных ведомств ⚪️взаимодействовать с иностранными патентными поверенными ⚪️готовить и согласовывать лицензионные договоры, договоры отчуждения, авторского заказа и соглашения о сосуществовании товарных знаков ⚪️вести претензионную и судебную работу ⚪️представлять компанию в Палате по патентным спорам. Английский нужен на уровне не ниже B2. Статус патентного поверенного будет преимуществом. Что важно увидеть юристу в этой вакансии: 1. Узкой специализации уже недостаточно Даже юристу, который занимается интеллектуальной собственностью, необходимо ориентироваться в рекламе, персональных данных, защите конкуренции и прав потребителей. В технологическом бизнесе вопросы редко существуют отдельно друг от друга. Например, запуск нового бренда может одновременно потребовать: ⚪️проверки и регистрации товарного знака ⚪️анализа рекламной кампании ⚪️оценки допустимости использования изображений и контента; ⚪️подготовки договоров с авторами и подрядчиками ⚪️проверки сайта и пользовательских документов. 2. Бизнесу нужен юрист полного цикла Недостаточно подать заявку в Роспатент или проверить договор. От юриста ждут сопровождения объекта интеллектуальной собственности на всех этапах: создание → оформление прав → использование → договоры → защита → спор. 3. Нужно уметь объяснять, а не только анализировать В вакансии отдельно указано умение формулировать правовые позиции, понятные бизнесу, готовить методические материалы и проводить обучение. Это один из главных навыков современного IT-юриста. Не просто написать: «Существует риск нарушения исключительных прав». А объяснить: ⚪️в чем именно риск ⚪️насколько он вероятен ⚪️как он влияет на запуск продукта ⚪️что нужно сделать, чтобы бизнес мог продолжить работу. 4. Интеллектуальная собственность — это не только товарные знаки Для IT-компании особенно важно правильно оформить права на программное обеспечение, дизайн, базы данных, контент и другие результаты работы сотрудников и подрядчиков. Сам факт оплаты разработки или наличие свидетельства о регистрации программы для ЭВМ еще не всегда означает, что исключительные права действительно принадлежат компании. Что проверить в первую очередь: ⚪️введен ли режим служебных произведений ⚪️ставятся ли разработчикам служебные задания ⚪️предусмотрен ли порядок передачи результатов ⚪️правильно ли оформлены отношения с подрядчиками ⚪️выплачивается ли предусмотренное законом вознаграждение авторам. Разбор того, как IT-компании оформить права на разработку, можно посмотреть в записи вебинара Школы IT-юриста: https://itpravo.tech/itcomp Вакансия Т-Банка и условия отклика: https://www.tbank.ru/career/back-office/vacancy/moscow/vedushchij-yuriskonsult-po-intellektualnoj-sobstvennosti/019f4bc9-a8f9-7448-a302-345c8adb5674/ Даже если вы пока не готовы откликаться, используйте вакансию как чек-лист: каких навыков вам не хватает до уровня ведущего юриста крупной технологической компании?

Авито ищет юриста в команду договорного отдела. Формат работы — офис в Москве или гибрид.  Что предстоит делать: ▪️ согласовывать договоры и разрабатывать шаблоны кредитных договоров, договоров по финансовым инструментам, лицензионных договоров и договоров на разработку ПО ▪️ оптимизировать договорный процесс ▪️ консультировать внутренние команды ▪️ разбирать сложные договорные задачи и предлагать подходы к их решению ▪️ унифицировать договорные подходы, готовить инструкции, чек-листы и стандартные положения ▪️ проводить внутренние юридические тренинги. Авито ждёт кандидата с опытом договорной работы от трёх лет в IT-сфере или юридическом консалтинге, в том числе с кредитными договорами. Важно уметь оценивать юридические риски не изолированно, а с учётом бизнес-процессов компании.  🔗 Описание вакансии и отклик: https://career.avito.com/vacancies/yurisprudentsiya-i-gr/19936/ Что полезно повторить перед откликом ❓ Одна из задач — сопровождение договоров на разработку программного обеспечения. Такой договор нельзя проверять как обычный договор оказания услуг. Юристу важно понять: ▫️какой именно продукт должен получить заказчик как зафиксированы требования к результату ▫️ кому будут принадлежать права на код ▫️ как проходит приёмка ▫️ передаются ли репозиторий, документация и доступы ▫️ что произойдёт при смене разработчика ▫️можно ли использовать в продукте сторонние и open source-компоненты. В Базе знаний Школы IT-юриста есть подробный материал: «Почему 80% договоров на разработку ПО опасны для заказчика: чек-лист IT-юриста» В нём разбираем, как проверить договор с разработчиком и не потерять права на продукт.  🔗 https://itpravo.tech/tpost/m3fnirsma1-pochemu-80-dogovorov-na-razrabotku-po-op Перед собеседованием попробуйте сформулировать ответы на три вопроса: ➡️Какие риски вы проверите в договоре разработки ПО в первую очередь? ➡️Как убедиться, что заказчик действительно получит права на созданный продукт? ➡️Какие условия позволят компании продолжить работу с продуктом после прекращения отношений с подрядчиком? Такая подготовка поможет показать себя не просто договорным юристом, а специалистом, который понимает IT-продукт, бизнес-процессы и последствия выбранной договорной конструкции. #вакансии #ITюрист #Авито #договоры #разработкаПО #ШколаITюриста

❗️МНОГОМИЛЛИОННЫЕ ШТРАФЫ могут убить ваш бизнес: как защитить деньги ресторана от проверок и судов Роскомнадзор начал «охоту» на рестораны: ваш бизнес — следующий в списке на проверку? В 2026 году проверки по персональным данным стали тотальными. РКН заходят туда, где проще всего найти ошибки: в сайты доставок, формы бронирования и чат-боты. 🗓 9 июля в 11:00 (мск) на практическом вебинаре ServiceGuru разберем, как перестать играть в рулетку с законом и привести базу данных в порядок. Программа вебинара: 🔹 Почему сайт, доставка и чат-боты — это главные зоны финансовой опасности. 🔹 Законный сбор данных: как правильно оформить согласия, чтобы к вам не было вопросов при проверке. 🔹 Передача данных подрядчикам: как обезопасить себя при работе со службами доставки и сервисами рассылок. 🔹 Что делать в первые 30 минут, если база «утекла» или взломана, чтобы минимизировать последствия для бизнеса. 🌟 Подарки на нашем вебинаре: • Шаблон согласия на обработку ПДн (с учетом специфики доставки и маркетинга). • Чек-лист для аудита сайта и мобильного приложения глазами Роскомнадзора. • Чек-лист для самозащиты внутренних процессов ресторана. Перестаньте рисковать прибылью ресторана. 👉 Бесплатная регистрация на вебинар

И дальше юристу нужно самому понять: ➡️ какие вопросы задать клиенту ➡️ какие риски увидеть ➡️ какие документы понадобятся ➡️ что делать сейчас, а что можно отложить ➡️ где проходят границы ответственности бизнеса Именно поэтому мы полностью перестроили обучение в Школе IT  юриста и запустили  Практикум «Юрист IT компании». Теперь его основа — не темы законодательства, а профессиональное мышление IT-юриста и обучение на кейсах. В процессе каждый слушателт в составе мини группы разбиарет кейсы, предлагает решение, а дальше мы разбираем правильность решения, особенности кейса.  Каждый модуль строится одинаково: ⚪️ мастер-класс (не лекция) ⚪️ практические материалы ⚪️ чек-листы ⚪️ реальный кейс ⚪️ живой разбор Например, вместо лекции «Договор разработки ПО» будет мастер-класс: Как проверить договор разработки ПО глазами заказчика. Вместо лекции «Персональные данные»: Как провести аудит обработки персональных данных цифрового продукта. Вместо лекции «Платформы»: Как спроектировать юридическую архитектуру цифровой платформы. По сути, мы учим не запоминать нормы, а работать так, как ежедневно работает команда консультантов. Еще один важный шаг — сейчас мы параллельно разрабатываем профессиональный стандарт IT-юриста. Именно он стал основой новой программы: сначала определяем, какими компетенциями должен обладать специалист, а затем строим обучение вокруг этих компетенций, а не вокруг отдельных законов. Если вам интересно посмотреть программу или обсудить, каких навыков сегодня действительно не хватает IT-юристам, буду рада обратной связи. Практикум стартует совсем скоро, а описание программы уже доступно на сайте Школы IT-юриста: Практикум «Юрист IT-компании» Мне особенно интересно мнение коллег, которые работают in-house или сопровождают технологические компании в консалтинге. Если бы вы сегодня заново начинали карьеру IT-юриста, какой один практический навык вы хотели бы освоить в первую очередь?

Разбирали реальный запрос Роскомнадзора. Самое интересное — регулятор начал не с документов. Он начал с сайта. Попробуйте посмотреть на сайт своего клиента так же. Чек-лист для IT-юриста 1️⃣ Есть формы сбора данных? Регистрация, обратная связь, заявки, подписки, вебинары, мероприятия, личный кабинет. Если формы есть — значит есть обработка персональных данных. 2️⃣ Понятно, на каком основании собираются данные? Роскомнадзор в запросе отдельно указал, что не увидел правовых оснований обработки персональных данных через формы сайта. Не просто форму. Именно основание обработки. 3️⃣ Есть Яндекс Метрика? Если есть — задайте себе вопрос: На каком основании происходит обработка данных пользователей через метрику? Есть ли информирование пользователя? Как это отражено в документах? 4️⃣ Есть Google Analytics? Тогда автоматически возникает следующий вопрос: Как организована трансграничная передача данных? Подавалось ли уведомление в Роскомнадзор? 5️⃣ Есть Google Forms? Или другие зарубежные формы сбора данных? Тогда следующий вопрос: Где фактически оказываются данные российских пользователей? 6️⃣ Есть cookie-баннер? И самое главное: Он реально работает или существует только для дизайна? 7️⃣ Сайт использует внешние сервисы? ⚪️Платежи ⚪️Чат-боты ⚪️CRM ⚪️Онлайн-консультанты ⚪️Сервисы рассылок ⚪️Виджеты Каждый такой сервис — потенциальный новый участник обработки данных. 8️⃣ Есть политика обработки персональных данных? Теперь сложный вопрос. Она соответствует реальным процессам? Или была скачана несколько лет назад и больше не обновлялась? 9️⃣ Вы понимаете, кто оператор? Это один из самых частых вопросов на практике. Компания считает себя обработчиком. Роскомнадзор считает оператором. Именно отсюда часто начинаются проблемы. Что происходит дальше? Если смотреть на запрос, логика Роскомнадзора выглядит примерно так: ⚪️Изучаем сайт ⚪️Находим формы ⚪️Находим метрики ⚪️Находим зарубежные сервисы ⚪️Проверяем документы ⚪️Запрашиваем подтверждение законности обработки данных 🔗Поэтому хороший IT-юрист сегодня должен уметь делать не только аудит документов. Он должен уметь провести аудит сайта и бизнес-модели глазами регулятора. ⚠️ Именно этому мы учимся на практике, когда разбираем реальные кейсы цифровых платформ и IT-компаний.

💲Мы хотим сделать напоминания о вебинарах максимально удобными для участников. Подскажите, какой формат уведомлений вы предпочитаете?