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

На прошлой неделе начался поток Практикума «Юрист IT». Обучение мы построили, как работу над кейсами в мини группах и разбор этих кейсов с лекторами. Первый кейс направлен на то, чтобы построить дорожную карту юридических задач IT компании (с учетом стадии и развития, стратегических задач, ЦА). Мы уверенны, что юрист должен не просто решать задачи, которые ему ставит фаундер, а быть инициатором таких задач с учетом прежде всего бизнеса и его специфики. И вот сегодня на HH попалась вакансия, которая идеально описывает раннюю стадию IT проекта. Что стоит отразить в сопроводительном письме: ⚪️вы понимаете, на какой стадии они сейчас и что их ждет дальше; ⚪️с учетом стадии первые задачи на 3-6 мес; ⚪️основные юридические риски, с которыми стоит работать на этой стадии. Кстати, какие юридические задачи вы бы заложили на 3-6 мес с учетом описания в вакансии? Давайте за наиболее полный ответ мы разыграем скидку на новый поток Практикум в 20 %?

Мы провели вебинар «Цифровые платформы платформы в 2026: новые требования и ответственность» Разобрали: ▫️какие новые понятия подарил нам закон о платформенной экономике; ▫️что сделать, что стать цифровой платформой; ▫️кто и как будет вести реестр посреднических цифровых платформ; ▫️новые требования для маркетплейсов, которые нужно внедрить всем (даже если вы не попадаете в реестр); ▫️принципы функционирования цифровой платформы и почему они влияют на подход к зонам ответственности платформы. Смотреть

📎Сегодня проводим вебинар про мастермайнд для IT-юристов Если вы работаете с IT-проектами и хотите: ▪️ разбирать реальные кейсы вместо теории ▪️уверенно закрывать вопросы по договорам, данным, налогам и рекламе ▪️получать обратную связь от практикующих экспертов ▪️ и находить решения, которые реально применимы в работе Приходите — покажем, как это работает на практике и за счёт чего даёт результат. Расскажем: ▫️ как устроен мастермайнд ▫️ какие задачи решают участники ▫️какой результат вы получаете Регистрируйтесь сейчас, чтобы успеть попасть в поток.: https://itpravo.tech/mastermind

Дорогие коллеги! 🙌 Начинаем наш вебинар через 5 минут. 💡Успейте подключиться. Ссылка: https://zarlaw.timepad.ru/event/3890813/

💲IT-юрист: чек-лист по адаптации документов и архитектур платформы к Закону о платформенной экономике 🚩Новый закон о платформенной экономике требует от онлайн-сервисов пересмотра архитектуры платформ и документации. Наш чек-лист поможет IT-юристам и разработчикам: проверить соответствие платформы новым требованиям, адаптировать внутренние процессы и снизить юридические риски. Практические советы и пошаговые рекомендации для безопасной работы вашей платформы. Читать статью →

💲 Коротко о главном: Маркетплейсы и агрегаторы ждут не штрафы, а слом бизнес-модели. 📌Новое регулирование меняет ответственность, платежи и статус платформы. Регестрация: https://zarlaw.timepad.ru/event/3890813/

Кейс: «Кто владеет продуктом, если компании ещё нет?» Учиться интереснее и проще на кейсах. Согласны. Вот один из интересных, который составлен на основе реальных событий (правда все совпадения случайны). 📎Контекст Создаётся B2B-платформа. 3 ко-фаундера: • сами пишут код • сами делают продукт • юридического лица пока нет (так как до монетизации еще далеко и нужно выбрать, что регистрировать) На разработку еще 3 - 6 месяцев и далее планируется запуск 🚀 Через 1 - 2 месяца: 🔺планируется привлечение фрилансеров (они находятся в РБ и Казахстане) 🔺оплату будет производить один из фаундеров Дополнительно: 🔺один из фаундеров (Иванов) уже привлёк двух сотрудников из своей другой компании 🔺они участвуют в разработке в свободное время. Но так как большой загрузки в основной компании нет, им за это не доплачивают. Основатели считают, что это зачтется потом в инвестиции Иванова В будущем: 🔺планируется создание компании 🔺запуск монетизации 🔺подача в Сколково (гранты + инвестиционная привлекательность) Вопрос❗️ Вы — юрист проекта. Что вы делаете прямо сейчас? Какие вопросы зададите основателям? Какие риски видите?

Уже завтра 🚀 Регистрация: https://zarlaw.timepad.ru/event/3890895/

Отдаем наш мини-курс по IT-праву в добрые руки! 💘💘💘 Мы знаем, как сложно бывает подступиться к теме IT: непонятные термины, другие бизнес-модели и куча нюансов с данными. Поэтому мы открыли доступ к курсу «IT-юрист: как перейти в IT и начать работать с технологическим бизнесом». 💡Это идеальный «входной билет» в нишу. Без лишней воды разбираем, как юристу стать ценным активом для бизнеса, а не «тормозом» процессов. 👍Учиться бесплатно тут: https://itpravo.tech/minigotoit

А твое слово есть в словаре? Гайд изучили, риски осознали, юриста с маркетологом помирили. Остался один вопрос: а как быть с теми самыми «дитейлсами», «фейсами» и прочими «фабриксами», которые уже въелись в лексику бренда? Листать словари каждый раз - занятие для терпеливых. Мы сделали инструмент для прагматичных: https://zarlaw.ru/word-search/ Автоматизированная проверка слов по нормативным словарям Вводите слово - сервис ищет его в нормативных источниках. ✔️Нашли? Значит, можно использовать без риска. ✖️Не нашли? Значит, лучше перевести или заменить.

Если вы пропустили открытый урок программы "Юрист IT компании" - мы делимся видео. Тема урока - Open Source. https://www.youtube.com/watch?v=nXejnm6vpVQ

Рубрика: «Как у них устроено» Давайте как юристы разберём технологические сервисы и посмотрим, как у них устроена юридическая архитектура бизнеса. Начнём с сервиса приема платежей https://unitpay.ru/ По описанию функционала сервис предлагает: • прием платежей из России и из-за рубежа • альтернативу онлайн-кассам — Unit.Чеки • собственное anti-fraud решение (3DS native) • защиту данных по стандарту PCI DSS • более 40 модулей для CMS и CRM • вывод средств на расчетный счет на следующий день. Когда юрист видит формулировку «прием платежей», возникает логичный вопрос: а нужна ли здесь банковская лицензия? Что показывает анализ документов сервиса Если открыть пользовательское соглашение и документы сервиса, можно увидеть важную деталь. В модели используются платежные партнеры. В документах указано:

«Платежные партнеры – финансовые организации, имеющие право на осуществление переводов денежных средств и связанных с ними операций».

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

Система Unitpay — совокупность программных средств, веб-форм, программно-аппаратных решений и объектов интеллектуальной собственности

То есть юридически это: IT-продукт + договорная модель с финансовыми организациями. Функция сервиса — предоставить удобный интерфейс и технологическую инфраструктуру для обработки платежей. Как обычно работает такая схема На практике используется следующая архитектура: 1️⃣ пользователь оплачивает товар или услугу 2️⃣ деньги поступают на счет платежного партнера (банка) 3️⃣ банк распределяет средства 4️⃣ получатель получает платеж 5️⃣ сервис получает комиссию. Иногда используются так называемые транзитные счета, через которые банк распределяет поступившие средства. Какие юридические особенности есть у таких проектов Такие сервисы почти всегда имеют несколько зон риска. 1. Работа с персональными данными Платежные сервисы обрабатывают большой объем данных: ФИО телефоны email иногда платежные реквизиты. Это требует: правильной архитектуры обработки ПДн договоров с банками и партнерами соблюдения стандартов безопасности. 2. Передача данных третьим лицам В модели почти всегда участвуют: банки платежные системы получатели платежей. Это означает массовую передачу персональных данных третьим лицам, которая должна быть правильно оформлена юридически. 3. Отсутствие банковской лицензии Важный момент: сам сервис обычно не является финансовой организацией. Он выступает как: технологическая платформа агрегатор платежей IT-решение. А вот лицензированную деятельность выполняют банки-партнеры. 4. Интеллектуальная собственность Основной актив таких проектов — это: программное обеспечение база данных интерфейсы API. Поэтому критически важно правильно оформить исключительные права на программный продукт.

Рубрика: «Как у них устроено» Давайте как юристы разберём технологические сервисы и посмотрим, как у них устроена юридическая архитектура бизнеса. Начнём с сервиса приема платежей https://unitpay.ru/ По описанию функционала сервис предлагает: • прием платежей из России и из-за рубежа • альтернативу онлайн-кассам — Unit.Чеки • собственное anti-fraud решение (3DS native) • защиту данных по стандарту PCI DSS • более 40 модулей для CMS и CRM • вывод средств на расчетный счет на следующий день. Когда юрист видит формулировку «прием платежей», возникает логичный вопрос: а нужна ли здесь банковская лицензия? Что показывает анализ документов сервиса Если открыть пользовательское соглашение и документы сервиса, можно увидеть важную деталь. В модели используются платежные партнеры. В документах указано:

«Платежные партнеры – финансовые организации, имеющие право на осуществление переводов денежных средств и связанных с ними операций».

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

Система Unitpay — совокупность программных средств, веб-форм, программно-аппаратных решений и объектов интеллектуальной собственности

То есть юридически это: IT-продукт + договорная модель с финансовыми организациями. Функция сервиса — предоставить удобный интерфейс и технологическую инфраструктуру для обработки платежей. Как обычно работает такая схема На практике используется следующая архитектура: 1️⃣ пользователь оплачивает товар или услугу 2️⃣ деньги поступают на счет платежного партнера (банка) 3️⃣ банк распределяет средства 4️⃣ получатель получает платеж 5️⃣ сервис получает комиссию. Иногда используются так называемые транзитные счета, через которые банк распределяет поступившие средства. Какие юридические особенности есть у таких проектов Такие сервисы почти всегда имеют несколько зон риска. 1. Работа с персональными данными Платежные сервисы обрабатывают большой объем данных: ФИО телефоны email иногда платежные реквизиты. Это требует: правильной архитектуры обработки ПДн договоров с банками и партнерами соблюдения стандартов безопасности. 2. Передача данных третьим лицам В модели почти всегда участвуют: банки платежные системы получатели платежей. Это означает массовую передачу персональных данных третьим лицам, которая должна быть правильно оформлена юридически. 3. Отсутствие банковской лицензии Важный момент: сам сервис обычно не является финансовой организацией. Он выступает как: технологическая платформа агрегатор платежей IT-решение. А вот лицензированную деятельность выполняют банки-партнеры. 4. Интеллектуальная собственность Основной актив таких проектов — это: программное обеспечение база данных интерфейсы API. Поэтому критически важно правильно оформить исключительные права на программный продукт.