Резюме исследования
Технологическая компания внешне воспринимается как бизнес без тяжёлых материальных активов.
Нет завода.
Нет склада сырья.
Нет производственной линии.
Основную стоимость создают:
программное обеспечение
алгоритмы
данные
команда разработчиков
клиентская база
цифровая платформа
бренд
облачная инфраструктура
интеграции
технологические знания.
Эта нематериальность создаёт иллюзию мобильности и юридической простоты.
Кажется, что продукт можно быстро разработать, перенести в облако, масштабировать на другие регионы, привлечь инвестиции и продать без сложного правового оформления.
Но именно технологический бизнес особенно уязвим к разрыву между экономической и юридической реальностью.
Компания считает, что владеет программой.
Но ключевой модуль написал внешний разработчик, а договор не предусматривал передачу исключительного права.
Основатели считают алгоритм собственностью стартапа.
Но первая версия создавалась до регистрации общества на личных компьютерах участников.
Инвестор покупает долю в компании.
Но домен, репозиторий, товарный знак и облачная учётная запись зарегистрированы на одного из основателей.
Сервис обучает модель на клиентских данных.
Но согласия, договоры и заявленные цели обработки не охватывают такое использование.
Компания внедряет искусственный интеллект в принятие решений.
Но никто не определил, кто проверяет результат, кто вправе его отменить и кто отвечает за причинённый ущерб.
Сотрудник увольняется и уносит исходный код, архитектурные схемы, клиентские контакты и промпты.
Компания называет это кражей коммерческой тайны.
Но режим коммерческой тайны формально не вводился, перечень защищаемых сведений отсутствует, доступ не разграничен, а документы не имеют соответствующей маркировки.
Кибератака останавливает сервис.
Руководство пытается восстановить работу, перезапускает системы и удаляет заражённые файлы.
Одновременно уничтожаются цифровые следы, необходимые для расследования, уведомления регуляторов и предъявления требований подрядчику.
Поэтому цифровой бизнес существует сразу в нескольких слоях:
как программный код
как объект интеллектуальных прав
как информационная система
как оператор персональных данных
как договорная инфраструктура
как набор облачных сервисов и лицензий
как корпоративный актив
как потенциальный объект кибератаки
как система принятия решений, способных причинять вред клиентам и контрагентам.
Для Краснодарского края эта тема перестала быть периферийной.
По данным региональных органов, в крае работает более двух тысяч организаций сферы информационных технологий и связи, в которых заняты свыше 18,5 тысячи человек. За пять лет выручка региональных ИТ-компаний выросла почти в четыре раза. Регион также сохраняет специальные меры поддержки аккредитованных ИТ-компаний и развивает кадровую и образовательную инфраструктуру цифровой отрасли.
Рост создаёт новые объекты стоимости.
Но он одновременно увеличивает цену ошибки.
Утечка данных теперь способна повлечь многомиллионные и оборотные штрафы.
С 1 октября 2026 года начинает действовать специальный закон о платформенной экономике.
26 июля 2026 года опубликован первый федеральный закон, непосредственно регулирующий разработку и применение больших фундаментальных моделей искусственного интеллекта.
В 2026 году уточнена уголовная ответственность за неправомерное воздействие на критическую информационную инфраструктуру.
Главный вывод настоящего исследования:
I. Технологическая компания — это не только разработчик программного обеспечения
1. Цифровой бизнес включает разные экономические модели
К технологическим компаниям Краснодарского края могут относиться:
разработчики программного обеспечения
сервисы автоматизации бизнеса
медицинские информационные системы
финансово-технологические проекты
агротехнологические компании
образовательные платформы
маркетплейсы
сервисы бронирования
логистические платформы
операторы мобильных приложений
разработчики решений искусственного интеллекта
интеграторы
облачные сервисы
кибербезопасностные компании
цифровые агентства
разработчики оборудования с программным ядром.
Юридическая модель зависит не от того, называет ли компания себя стартапом или ИТ-компанией.
Она зависит от того:
что именно компания создаёт
кому предоставляет продукт
какие данные получает
какие решения принимает система
на чьей инфраструктуре работает
какие последствия способен вызвать цифровой сбой.
2. Один продукт состоит из нескольких самостоятельных активов
Программный продукт может включать:
исходный код
объектный код
архитектуру
интерфейс
дизайн
документацию
базу данных
обучающую выборку
модель машинного обучения
товарный знак
домен
мобильное приложение
пользовательские материалы
аналитические отчёты
ноу-хау
доступы к облачной инфраструктуре.
Права на эти элементы могут принадлежать разным лицам.
Поэтому утверждение:
не имеет достаточной юридической определённости.
Необходимо установить принадлежность каждого критического компонента.
II. Четыре реальности цифрового продукта
3. Техническая реальность
Кто написал код.
Какие библиотеки использованы.
Где находится репозиторий.
Как устроена инфраструктура.
Какие данные обрабатываются.
Кто имеет административный доступ.
4. Договорная реальность
Что обещано клиенту.
Какие функции входят в лицензию.
Какие показатели доступности установлены.
Кто отвечает за интеграции.
Какие ограничения использования предусмотрены.
5. Правовая реальность
Кому принадлежат исключительные права.
Законно ли используются данные и сторонние компоненты.
Введён ли режим коммерческой тайны.
Соблюдаются ли требования к персональным данным и информационной безопасности.
6. Инвестиционная реальность
Какой актив оценивает инвестор.
Можно ли передать продукт другому юридическому лицу.
Не зависит ли работа компании от одного сотрудника или аккаунта.
Сохранятся ли права после увольнения основателя.
Наиболее высокий риск возникает, когда эти четыре реальности не совпадают.
III. Исходный код сам по себе не доказывает право собственности
7. Автором программы является физическое лицо
Программный код создают конкретные разработчики.
Компания получает исключительное право не потому, что оплатила зарплату, арендовала офис или зарегистрировала домен.
Необходимо юридическое основание:
служебное произведение
договор создания программы по заказу
договор отчуждения исключительного права
лицензионный договор
иная предусмотренная законом конструкция.
Гражданский кодекс отдельно регулирует служебные произведения, программы, созданные по заказу, и произведения, возникшие при выполнении договора, который прямо не предусматривал их создание. Последствия в этих случаях различаются.
8. Оплата разработки не всегда означает получение исключительного права
Если предметом договора было именно создание программы, исключительное право по общему правилу принадлежит заказчику, если стороны не установили иное.
Но если программа возникла при выполнении договора, который прямо не предусматривал её создание, исключительное право по общему правилу может остаться у исполнителя.
Одно различие в формулировке предмета договора способно определить владельца цифрового продукта.
IV. Служебный код: трудового договора недостаточно
9. Разработка должна входить в трудовые обязанности или служебное задание
Чтобы программа считалась служебным произведением, необходимо связать её создание с трудовой функцией работника.
Практически важны:
трудовой договор
должностная инструкция
служебное задание
техническое задание
история задач
репозиторий
акт передачи результата
переписка
сведения об использовании продукта компанией.
Должность «программист» помогает, но не заменяет доказательство того, что спорный модуль создавался в рамках трудовых обязанностей.
10. Разработчик может писать код вне рабочего времени
Сам по себе факт работы вечером или на личном компьютере не означает, что код принадлежит работнику.
Но компания должна доказать связь разработки с трудовой функцией, корпоративной задачей и ресурсами работодателя.
Особенно опасны ситуации, когда:
задачи ставились устно
репозиторий находился в личном аккаунте
разработка началась до трудоустройства
часть кода использовалась в личном проекте сотрудника
передача результата не оформлялась.
11. Неиспользование служебного произведения тоже создаёт риск
Гражданский кодекс устанавливает последствия, если работодатель в течение предусмотренного срока не начинает использование служебного произведения, не передаёт право другому лицу и не сообщает автору о сохранении результата в тайне.
Поэтому архив исходного кода, о котором компания забыла, не всегда остаётся бесспорным активом работодателя.
V. Основатель написал первую версию до создания компании
12. Регистрация общества не переносит права автоматически
Типичная история стартапа:
два основателя придумали продукт
один написал прототип
второй нашёл клиентов
затем зарегистрировано ООО
работа продолжилась уже внутри компании.
Но права на первоначальный код могут остаться у физического лица.
Использование продукта обществом не всегда означает отчуждение исключительного права.
13. Необходимо оформить вклад цифрового актива в бизнес
Возможные конструкции:
отчуждение исключительного права компании
предоставление исключительной лицензии
внесение права в уставный капитал
передача комплекса результатов по отдельным договорам.
Нужно одновременно решить:
кто является автором
какие версии кода передаются
включаются ли документация и базы данных
может ли основатель использовать прежние наработки в других проектах
какое вознаграждение предусмотрено.
VI. Репозиторий не равен интеллектуальному праву
14. Контроль над Git-системой — технический, но не всегда юридический контроль
Компания может иметь доступ к исходному коду, который юридически ей не принадлежит.
И наоборот:
компания может обладать исключительным правом, но потерять доступ к репозиторию, если аккаунт зарегистрирован на сотрудника или подрядчика.
Поэтому необходимо разделять:
право на код
физическое хранение
административный доступ
историю изменений
право выпускать новые версии.
15. Критические аккаунты должны принадлежать организации
Это относится к:
репозиториям
облачным платформам
магазинам мобильных приложений
доменному регистратору
системам аналитики
сертификатам электронной подписи
платёжным кабинетам
системам рассылок
учётным записям разработчиков.
Если инфраструктура находится на личной почте основателя, инвестор приобретает не самостоятельный бизнес, а зависимость от конкретного человека.
VII. Внешний разработчик способен сохранить контроль над всем продуктом
16. Договор должен передавать не только конечный результат
Необходимо урегулировать:
исключительное право
исходный код
документацию
архитектурные схемы
доступы
средства сборки
тесты
историю изменений
сторонние компоненты
право модификации
обязанность содействовать миграции.
Фраза «исполнитель передаёт программу» не всегда отвечает на эти вопросы.
17. Акт без передачи исходного кода создаёт зависимость
Компания может получить работающий сервис, но не иметь возможности:
исправить ошибку
сменить подрядчика
провести аудит
перенести продукт
доказать состав разработки
выявить сторонние компоненты.
Такая система способна приносить выручку, но её стоимость для инвестора существенно ниже.
VIII. Открытый код не означает отсутствие обязательств
18. Open source — это лицензионная модель
Сторонние библиотеки могут разрешать использование:
без раскрытия собственного кода
при сохранении уведомлений об авторстве
при предоставлении текста лицензии
при раскрытии производных компонентов
на иных специальных условиях.
Поэтому юридическая проверка продукта должна включать реестр зависимостей и условий их использования.
19. Разработчик не должен самостоятельно определять лицензионную политику компании
Одна библиотека может быть технически удобной, но несовместимой с коммерческой моделью продукта.
Особенно важно проверить:
распространяется ли приложение клиентам
предоставляется ли только облачный доступ
модифицировался ли открытый компонент
встраивается ли он в основное приложение
какие уведомления необходимо разместить.
20. Реестр компонентов становится частью инвестиционного досье
Компания должна знать:
название компонента
версию
источник
лицензию
место использования
наличие модификаций
известные уязвимости
ответственного за обновление.
Без такого реестра невозможно надёжно оценить ни интеллектуальные, ни киберриски продукта.
IX. Регистрация программы помогает, но не создаёт право из ничего
21. Государственная регистрация программы для ЭВМ добровольна
Роспатент вносит программу или базу данных в соответствующий реестр и выдаёт свидетельство.
Регистрация способна усилить доказательственную позицию, зафиксировать заявленного правообладателя и идентифицировать депонированный результат.
Но она не заменяет договоры с авторами и не устраняет спор о первоначальном происхождении права.
22. Зарегистрировать следует правильную версию и правильного правообладателя
Нужно проверить:
кто указан автором
кто указан правообладателем
какая версия депонируется
не содержит ли материал чужой код
совпадает ли регистрация с корпоративной структурой
оформлены ли последующие переходы права.
Свидетельство с ошибочным правообладателем способно усложнить, а не упростить инвестиционную сделку.
X. База данных и данные — разные активы
23. Право на структуру базы не означает право свободно использовать её содержимое
Компания может обладать исключительным правом на базу данных как результат организации и систематизации материалов.
Но содержащиеся в ней сведения могут одновременно охраняться как:
персональные данные
коммерческая тайна
банковская тайна
медицинская тайна
авторские материалы
информация контрагента.
Поэтому формула:
не даёт автоматического права использовать сведения для любой новой цели.
24. Обучающая выборка должна иметь карту происхождения
Для каждой категории данных необходимо установить:
источник
правовое основание получения
цель первоначального сбора
допустимость обучения модели
срок хранения
необходимость обезличивания
право передавать данные разработчику или облачному провайдеру
возможность повторного использования.
Иначе модель становится технически работающим продуктом с недоказанным происхождением основного ресурса.
XI. Закон об искусственном интеллекте 2026 года: что он действительно регулирует
25. Федеральный закон № 243-ФЗ не является универсальным кодексом ИИ
Закон от 26 июля 2026 года регулирует специальный контур разработки, внедрения и применения больших фундаментальных моделей искусственного интеллекта.
Он не превращает каждый алгоритм, рекомендательную систему, чат-бот или автоматический скоринг в регулируемую большую фундаментальную модель.
Поэтому технологической компании сначала необходимо определить собственную роль:
разработчик большой фундаментальной модели
лицо, предоставляющее доступ к ней
разработчик прикладного продукта поверх сторонней модели
пользователь модели внутри собственного процесса
обычная компания, использующая алгоритмическую автоматизацию.
26. Основные специальные обязанности заработают с 1 марта 2027 года
Для разработчиков суверенных и национальных больших фундаментальных моделей предусмотрены:
организационные и технические меры безопасности
правила эксплуатации, ограничений, обновления и вывода модели из эксплуатации
техническая документация с описанием ключевых параметров и ограничений.
Эти обязанности вступят в силу с 1 марта 2027 года.
27. К августу 2026 года подготовку уже нельзя откладывать
Разработчикам и крупным пользователям следует формировать:
паспорт модели
карту данных
описание ограничений
правила обновления
процедуру тестирования
управление уязвимостями
порядок прекращения эксплуатации
журнал существенных изменений
распределение ответственности.
Такая работа нужна не только ради будущего закона.
Она создаёт доказательства добросовестной разработки уже сегодня.
XII. Суверенная и национальная модель — специальные статусы
28. Закон устанавливает требования к разработчику и инфраструктуре
Для соответствующих статусов имеют значение:
российское юридическое лицо-разработчик
контроль над характеристиками модели
воспроизводимость цикла разработки
расположение обработки запросов и хранения данных в российских центрах обработки данных
иные установленные законом условия.
Для национальной модели допускается использование определённых открытых компонентов при соблюдении предусмотренных требований.
29. Российская регистрация компании сама по себе недостаточна
Закон связывает статус российского юридического лица для этих целей также с контролем над компанией.
Поэтому иностранная инвестиция, корпоративная реструктуризация или опцион способны повлиять на возможность получения специального статуса модели.
XIII. Маркировка ИИ-контента
30. Закон создаёт механизм информационного предупреждения
Для аудио- и визуальных материалов, созданных с применением больших фундаментальных моделей, пользователю должна обеспечиваться возможность разместить предупреждение о применении ИИ.
Крупные интернет-площадки с установленной законом аудиторией также должны обеспечивать соответствующую техническую возможность пользователям.
Специальные положения вступят в силу с 1 марта 2027 года.
31. Возможность маркировки и обязанность маркировать — не одно и то же
Закон не следует читать как безусловное требование ставить единый знак на каждый материал, созданный любым ИИ-инструментом.
Необходимо учитывать:
вид модели
формат материала
роль компании
условия платформы
договор с поставщиком модели
будущие подзаконные правила
иные требования к рекламе, выборам, персональным данным и защите потребителей.
XIV. Права на результаты, созданные с помощью ИИ
32. Новый закон не установил простую формулу «всё принадлежит пользователю»
Лицо, предоставляющее возможность применения большой фундаментальной модели, должно уведомлять пользователя:
о принадлежности прав на полученные результаты
об условиях доступа, использования и сохранения результатов.
Следовательно, правообладатель и пользователь должны заранее видеть договорный режим результата.
Сам закон не устраняет необходимость анализа авторского вклада человека, условий сервиса и прав на использованные материалы.
33. Коммерческое использование результата нужно проверять отдельно
Необходимо установить:
разрешает ли поставщик модели коммерческое использование
предоставляется ли исключительное право
может ли тот же результат быть создан для другого пользователя
содержит ли результат элементы чужих произведений
допускается ли регистрация товарного знака
кто отвечает по претензии правообладателя
сохраняет ли провайдер запросы и результаты.
XV. Обучение модели и интеллектуальные права
34. Закон 2026 года создаёт специальную конструкцию для определённых моделей
Статья 10 предусматривает, что компьютерный анализ закономерностей, классификация и краткосрочная запись произведений для обучения суверенных или национальных больших фундаментальных моделей при установленных условиях не считаются нарушением авторских и смежных прав.
Среди условий названы правомерное получение экземпляра либо доступность объекта без технических ограничений.
35. Это исключение нельзя автоматически распространить на любой стартап
Специальное правило связано с суверенными и национальными большими фундаментальными моделями.
Обычный разработчик прикладной модели не должен считать весь доступный интернет свободной обучающей выборкой.
Для него сохраняются вопросы:
авторских прав
условий сайтов
договорных ограничений
персональных данных
коммерческой тайны
конфиденциальности.
XVI. Искусственный интеллект не становится самостоятельным ответственным лицом
36. Ответственность остаётся в человеческой и корпоративной системе
Если алгоритм:
отказал клиенту
ошибочно списал деньги
предложил опасную рекомендацию
раскрыл конфиденциальные данные
заблокировал пользователя
создал недостоверный документ,
вопрос будет поставлен не к «ИИ вообще».
Будет исследоваться:
кто разработал систему
кто выбрал модель
кто определил правила
кто внедрил
кто проверял
кто мог отменить решение
кто взаимодействовал с клиентом
кто получил экономическую выгоду.
37. Человеческий контроль должен быть реальным
Формальная кнопка ручной проверки не решает проблему, если сотрудник:
не понимает модель
не видит исходные данные
не имеет времени на проверку
не вправе отменить результат
автоматически подтверждает рекомендации.
Нужно определить решения, которые нельзя исполнять без содержательной проверки человеком.
XVII. Компания должна вести реестр алгоритмических решений
38. Собственник должен знать, где именно используется ИИ
Не только в основном продукте.
Также:
в подборе сотрудников
оценке клиентов
рекламе
ценообразовании
модерации
подготовке договоров
службе поддержки
информационной безопасности
контроле работников
финансовом планировании.
Теневой ИИ, который сотрудники используют без согласования, способен создать такой же риск, как официальная система.
39. Для каждого применения нужен владелец риска
Следует определить:
цель
поставщика
данные
ограничения
критичность ошибки
проверяющего человека
порядок обжалования
журналирование
срок хранения результата
действия при сбое.
XVIII. Персональные данные — основной регуляторный контур цифрового бизнеса
40. Технологическая компания часто является оператором данных раньше первой продажи
Она обрабатывает сведения:
сотрудников
соискателей
пользователей
клиентов
контрагентов
посетителей сайта
участников рассылки
пользователей приложения
лиц, чьи данные загрузил корпоративный клиент.
По общему правилу оператор должен уведомить Роскомнадзор до начала обработки, а при изменении заявленных сведений — направлять обновления в установленный срок.
41. Пользовательское соглашение не заменяет все правовые основания
В зависимости от операции обработка может основываться на:
договоре
законе
согласии
исполнении обязанностей работодателя
защите прав
иных предусмотренных основаниях.
Один универсальный флажок:
не делает законной обработку для неограниченного набора будущих целей.
XIX. Цель обработки определяет границу использования данных
42. Данные, полученные для сервиса, нельзя автоматически превращать в обучающую выборку
Клиент передаёт сведения, чтобы:
получить услугу
хранить документы
вести учёт
обработать заявку
использовать CRM.
Если компания затем использует сведения для обучения собственной модели, анализа поведения или продажи аналитики, необходимо проверить совместимость цели и существующее правовое основание.
43. Обезличивание должно быть фактическим
Удаление имени не всегда делает массив обезличенным.
Человека могут позволить определить:
телефон
электронная почта
идентификатор устройства
геолокация
редкое сочетание признаков
история операций
связь с другой базой.
Поэтому необходимо оценивать реальную возможность повторной идентификации.
XX. Поручение обработки подрядчику
44. Облачный сервис не принимает автоматически весь регуляторный риск
Компания может поручить обработку:
хостинг-провайдеру
CRM
сервису аналитики
call-центру
рассылочной платформе
разработчику
службе поддержки.
Но договор должен определять:
перечень данных
операции
цели
конфиденциальность
безопасность
действия при инциденте
возврат или уничтожение данных
возможность субподряда.
45. Срок уведомления подрядчика должен быть короче срока оператора
При инциденте оператор обязан направить первое уведомление Роскомнадзору в течение 24 часов, а результаты внутреннего расследования — в течение 72 часов.
Если облачный подрядчик имеет право уведомлять клиента через три дня, оператор объективно не сможет выполнить собственную обязанность.
XXI. Утечка данных стала риском капитала
46. Штраф зависит от масштаба и категории данных
С 30 мая 2025 года действуют специальные составы за утечки.
Для крупных массивов установлены штрафы до 15 млн рублей.
За неправомерную передачу специальных категорий персональных данных предусмотрены отдельные повышенные санкции.
Повторное нарушение способно привести к оборотному штрафу от 1% до 3% выручки, но не менее установленного минимального размера и не более 500 млн рублей.
47. Кибербезопасность стала вопросом совета директоров и инвестора
Собственник должен знать:
какой массив является наиболее опасным
сколько лиц затронет единый инцидент
можно ли сегментировать данные
какие резервные копии существуют
кто обнаружит выгрузку
кто уведомит руководство
можно ли доказать принятые меры защиты.
XXII. Локализация и зарубежные сервисы
48. Место нахождения интерфейса не показывает место хранения данных
Российский сайт способен использовать:
иностранную CRM
зарубежную аналитику
облачную телефонию
систему поддержки
репозиторий
сервис электронных писем
модель искусственного интеллекта.
Необходимо установить фактическую архитектуру обработки и местонахождение баз данных.
49. Техническая интеграция может быть трансграничной передачей
Если данные становятся доступными иностранной компании или направляются на иностранную инфраструктуру, нужно отдельно оценить:
правовое основание
уведомление Роскомнадзора
страну получателя
содержание договора
меры защиты
возможность прекратить передачу
локализацию первичного сбора.
XXIII. Коммерческая тайна не возникает от слова «конфиденциально»
50. Необходимо установить режим
Закон требует определить перечень защищаемой информации, ограничить доступ, учитывать лиц, получивших сведения, урегулировать отношения с работниками и контрагентами и маркировать материальные носители.
Режим считается установленным после принятия предусмотренных мер.
51. В технологической компании к тайне могут относиться:
исходный код
архитектура
модели данных
промпты
обучающие выборки
параметры алгоритмов
дорожная карта продукта
уязвимости
коммерческие условия
клиентская база
аналитика
методики внедрения
планы инвестиций.
Но не все сведения можно объявить коммерческой тайной.
Закон устанавливает категории информации, в отношении которых такой режим недопустим.
XXIV. Ноу-хау требует реальной закрытости
52. Секрет производства существует, пока сохраняется конфиденциальность
Гражданский кодекс связывает ноу-хау с коммерческой ценностью вследствие неизвестности третьим лицам, отсутствием свободного доступа и принятием разумных мер конфиденциальности.
Если алгоритм подробно опубликован:
в статье
презентации
открытом репозитории
патентной заявке
рекламном материале,
защищать ту же информацию как секрет производства становится сложнее.
53. Патент и коммерческая тайна требуют стратегического выбора
Патентование предполагает раскрытие существа решения.
Коммерческая тайна предполагает сохранение закрытости.
Для каждого технологического решения необходимо определить:
можно ли обнаружить нарушение извне
как быстро технология устареет
можно ли сохранить её в секрете
нужна ли защита для инвестора
на каких рынках планируется работа.
XXV. Увольнение разработчика — операция информационной безопасности
54. Недостаточно заблокировать корпоративную почту
Нужно проверить доступ к:
репозиториям
облачным системам
VPN
клиентским кабинетам
ключам API
магазинам приложений
системам аналитики
резервным копиям
мессенджерам
паролям подрядчиков.
Также необходимо сохранить журналы действий и корпоративные устройства.
55. Нельзя удалять учётную запись до сохранения доказательств
В ней могут находиться:
история разработки
служебные задания
переписка
сведения о передаче кода
факты выгрузки
контакты клиентов
подтверждение авторства и служебного характера результата.
XXVI. Уходящий сотрудник и статья 183 УК РФ
56. Не всякая выгрузка кода автоматически является разглашением коммерческой тайны
Для уголовно-правовой оценки имеют значение:
статус информации
наличие режима
способ получения
обязанность сохранять конфиденциальность
факт использования или передачи
ущерб
мотив
последствия.
Статья 183 УК РФ предусматривает ответственность за незаконные получение, разглашение и использование коммерческой тайны, включая квалифицированные составы при крупном ущербе, корыстной заинтересованности и тяжких последствиях.
57. Слабый режим тайны ухудшает положение компании
Если любой сотрудник имел доступ ко всему репозиторию, файлы не маркировались, перечень тайны отсутствовал, а тот же код направлялся подрядчикам без NDA, компании будет сложнее доказать охраняемый статус сведений.
XXVII. Инвестиции: инвестор покупает не идею
58. Он покупает контролируемый набор прав и денежных потоков
Инвестор проверяет:
структуру капитала
права на продукт
договоры с командой
данные
лицензии
клиентов
инфраструктуру
регуляторные риски
споры
зависимость от основателей.
Красивый интерфейс не компенсирует отсутствие прав на базовый код.
59. Основательская договорённость должна быть формализована до конфликта
Необходимо определить:
доли
роли
финансирование
принятие решений
права на код
право на бренд
последствия ухода
запрет конкуренции в допустимых пределах
порядок продажи компании
тупиковые ситуации
опционы.
XXVIII. Опцион сотруднику не равен обещанию доли
60. Фраза «после запуска дадим 5%» создаёт конфликт, но не всегда корпоративное право
Нужно определить:
какой инструмент используется
когда возникает право
каковы условия вестинга
что происходит при увольнении
размывается ли доля
какие корпоративные одобрения необходимы
какова налоговая модель.
XXIX. Инвестор не должен получать больше прав на продукт, чем компания имеет сама
61. Заверения о правах должны быть проверяемыми
Инвестиционные документы часто содержат утверждения:
компания владеет всем программным обеспечением
нарушений прав третьих лиц нет
все сотрудники передали результаты
данные обрабатываются законно
споров нет.
Если это не соответствует действительности, основатели могут получить персональные требования инвестора.
XXX. Корпоративная реструктуризация цифрового бизнеса
62. Перенос операционной деятельности не переносит активы автоматически
При создании новой компании необходимо отдельно передать:
исключительные права
лицензии
домены
товарные знаки
договоры
персональные данные
облачные аккаунты
репозитории
базы данных.
Налоговый или инвестиционный мотив реструктуризации не исправляет отсутствие необходимых договоров.
XXXI. Государственная аккредитация ИТ-компании
63. Статус требует постоянного соответствия
В 2026 году аккредитованные компании подтверждали соответствие установленным требованиям, включая сведения о профильной деятельности, уровне выплат работникам и — для правообладателей программного обеспечения — данные о продукте в реестре российского ПО и выручке от его реализации.
Региональные ИТ-компании также используют связанные с аккредитацией меры поддержки.
64. Аккредитация не подтверждает права на программный продукт
Она не заменяет:
договоры с авторами
регистрацию переходов прав
лицензионный аудит
режим коммерческой тайны
проверку персональных данных.
XXXII. Реестр российского программного обеспечения
65. Включение продукта имеет самостоятельную коммерческую ценность
Оно может быть важно для:
государственных закупок
импортозамещения
аккредитационных процедур
доверия крупных заказчиков
получения поддержки.
Но необходимо подтвердить:
принадлежность прав
структуру продукта
контроль над развитием
зависимость от иностранных компонентов
соответствие установленным критериям.
XXXIII. Платформенный бизнес: 1 октября 2026 года — новая граница
66. Закон № 289-ФЗ начинает действовать с 1 октября 2026 года
Он регулирует отношения между операторами посреднических цифровых платформ, партнёрами, пользователями и иными участниками продажи товаров, выполнения работ и оказания услуг через платформы.
Закон предусматривает специальный реестр, требования к договорам, информации, партнёрам, спорам и платформенной инфраструктуре.
67. Не каждый сайт или приложение становится посреднической платформой
Специальный режим не применяется автоматически к ресурсу, через который владелец продаёт только собственные товары или услуги, а также к ряду прямо исключённых сервисов.
Нужно анализировать фактическую модель:
соединяет ли ресурс независимых продавцов и покупателей
кто заключает основной договор
кто принимает оплату
кто устанавливает правила
кто управляет рейтингом и доступом
кто рассматривает спор.
XXXIV. Алгоритм платформы становится экономическим регулятором
68. Ранжирование определяет доступ партнёра к клиенту
Алгоритм может:
понижать карточку
увеличивать комиссию
блокировать продавца
ограничивать заказ
изменять территорию показа
перераспределять спрос.
Поэтому компании необходимо заранее определить:
правила алгоритмического воздействия
основания ограничений
уведомление партнёра
процедуру оспаривания
сохранение истории решений.
69. Одностороннее изменение правил не должно быть неожиданным
Платформа контролирует интерфейс и текст договора.
Но это не означает неограниченную возможность:
немедленно повысить комиссию
задним числом изменить расчёт
удержать средства
заблокировать аккаунт
навязать дополнительную услугу.
С 1 октября 2026 года договорная и операционная модель должна быть проверена на соответствие специальному закону о платформенной экономике.
XXXV. Пользовательское соглашение — не лицензия на произвол
70. Условия должны соответствовать реальному продукту
Необходимо согласовать:
функциональность
порядок регистрации
стоимость
автопродление
ограничения
ответственность
блокировку
удаление данных
порядок предъявления претензий
юрисдикцию
правила использования контента.
Если интерфейс, реклама и договор противоречат друг другу, потребитель или корпоративный клиент будет ссылаться на наиболее выгодную ему версию.
XXXVI. SLA и доступность сервиса
71. Обещание «99,9%» должно быть технически и юридически определено
Нужно установить:
период измерения
плановые работы
исключения
точку измерения
влияние внешних провайдеров
размер компенсации
порядок уведомления
предельную ответственность.
72. Облачный провайдер может обещать меньше, чем компания обещает клиенту
Если инфраструктура гарантирует один уровень доступности, а SaaS-компания продаёт более высокий, разницу она принимает на себя.
То же относится к:
резервированию
восстановлению
сохранности данных
технической поддержке
срокам реакции.
XXXVII. Киберинцидент — не только работа технического отдела
73. Один инцидент создаёт несколько параллельных задач
Необходимо:
остановить развитие атаки
сохранить работу критических функций
зафиксировать доказательства
определить затронутые данные
уведомить регуляторов и клиентов, когда это требуется
проверить договоры
взаимодействовать со страховщиком
управлять публичной коммуникацией
готовить требования к подрядчику.
74. Самая опасная команда — «быстро всё удалить»
Удаление вредоносного файла или перезапуск сервера может уничтожить:
журналы
временные файлы
следы доступа
идентификаторы
время событий
данные об объёме выгрузки.
Сначала требуется контролируемая фиксация, если это не препятствует предотвращению дальнейшего вреда.
XXXVIII. План реагирования должен существовать до атаки
75. В документе необходимо определить:
кто объявляет инцидент
кто отключает систему
кто сохраняет журналы
кто взаимодействует с Роскомнадзором
кто работает с ФСБ, если применим режим КИИ
кто уведомляет клиентов
кто принимает решение о публичном заявлении
кто привлекает внешних экспертов
кто разрешает восстановление.
XXXIX. Критическая информационная инфраструктура
76. Не каждая технологическая компания является субъектом КИИ
Необходимо оценить:
сферу деятельности
принадлежащие или используемые информационные системы
автоматизированные системы управления
сети
роль компании в соответствующей отрасли
результаты категорирования.
Ошибка возможна в обе стороны:
компания формально объявляет всё КИИ
компания вообще не проводит анализ, хотя обслуживает критический процесс.
77. Субъекты КИИ обязаны незамедлительно сообщать о компьютерных атаках и инцидентах
Закон предусматривает информирование уполномоченного органа, содействие расследованию и реагирование.
С конца 2025 года действует обновлённый порядок информирования ФСБ и взаимодействия с государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак.
XL. Уголовный риск КИИ
78. В апреле 2026 года статья 274.1 УК РФ уточнена
Ответственность охватывает, в частности:
неправомерный доступ
использование вредоносных программ
нарушение правил эксплуатации и доступа к системам КИИ при наступлении предусмотренных последствий.
Введено специальное основание освобождения лица, нарушившего правила эксплуатации, если оно активно содействовало раскрытию и расследованию, приняло меры по сохранению следов воздействия и в его действиях нет иного состава преступления.
79. Сохранение следов стало не только технической, но и уголовно-правовой задачей
Сотрудник, который обнаружил инцидент, не должен скрывать его из опасения наказания.
Система должна мотивировать:
своевременное сообщение
изоляцию
сохранение журналов
документирование действий
содействие расследованию.
XLI. Обычная информационная система тоже создаёт уголовный риск
80. Отсутствие статуса КИИ не означает отсутствие ответственности
Уголовный кодекс предусматривает отдельные составы за:
неправомерный доступ к компьютерной информации
создание и использование вредоносных программ
нарушение правил эксплуатации информационных систем
разглашение коммерческой тайны
неправомерный оборот персональных данных в предусмотренных случаях.
Поэтому юридическая квалификация начинается с механизма события, а не с общего слова «хакерская атака».
XLII. Подрядчик по информационной безопасности
81. Сертификат подрядчика не гарантирует защищённость компании
Договор должен определять:
контур проверки
доступ
методику
допустимые действия
конфиденциальность
формат отчёта
критичность уязвимостей
срок устранения
повторное тестирование
ответственность
сохранение доказательств.
82. Тестирование без письменного разрешения способно выглядеть как неправомерный доступ
Нужно документально установить:
какие системы разрешено проверять
в какое время
какими методами
можно ли использовать эксплуатацию уязвимости
как поступать с найденными данными
кому немедленно сообщать о критическом дефекте.
XLIII. Внешний разработчик и киберинцидент
83. Уязвимость может быть создана подрядчиком, но ущерб несёт оператор сервиса
Необходимо установить:
обязанность безопасной разработки
стандарты кодирования
проверку зависимостей
срок исправления
обновления
поддерживаемые версии
ответственность за известную уязвимость
участие в расследовании
лимит ответственности.
XLIV. Цифровое решение может причинить реальный физический вред
84. Особенно чувствительны системы:
медицинские
транспортные
промышленные
финансовые
инфраструктурные
управляющие оборудованием
обрабатывающие критические обращения граждан.
Ошибка программы в таких сферах оценивается не только как программный дефект.
Будет исследоваться влияние на физический процесс и действия людей.
XLV. Ответственность за цифровое решение
85. Необходимо разделять роли
Разработчик создал программу.
Интегратор настроил.
Заказчик предоставил данные.
Оператор определил правила.
Сотрудник подтвердил результат.
Пользователь нарушил инструкцию.
Поставщик модели выдал рекомендацию.
Без договорного и технического разделения ролей каждая сторона будет пытаться переложить ответственность на другую.
86. Договор не может отменить ответственность перед третьим лицом
Ограничение ответственности между поставщиком и заказчиком регулирует их внутренние отношения.
Но потерпевший, потребитель или регулятор может предъявить требования к лицу, непосредственно нарушившему обязанность.
После этого возникает регрессный спор между участниками цифровой цепочки.
XLVI. Логи — цифровая медицинская карта технологического бизнеса
87. Без журналирования невозможно восстановить решение
Необходимо фиксировать:
вход пользователя
версию программы
версию модели
исходные данные
изменение настроек
административное действие
выданный результат
подтверждение человеком
передачу во внешнюю систему
ошибку
отказ.
88. Логи сами могут содержать персональные данные и тайну
Поэтому нужно определить:
срок хранения
доступ
защиту
неизменность
архивирование
использование при расследовании
удаление.
XLVII. Резервная копия не равна готовности к восстановлению
89. Копию необходимо регулярно проверять
Собственник должен знать:
что копируется
как часто
где хранится
изолирована ли копия от основной сети
кто имеет доступ
сколько времени займёт восстановление
проверялось ли оно фактически.
90. Резервная копия заражённой системы может сохранить заражение
Поэтому необходимы:
история версий
контроль целостности
изолированные копии
порядок выбора точки восстановления
проверка до возврата в эксплуатацию.
XLVIII. Зависимость от одного облачного поставщика
91. Облачная инфраструктура снижает расходы, но создаёт концентрацию
Нужно проверить:
можно ли выгрузить данные
в каком формате
сколько займёт миграция
кто владеет резервной копией
что происходит при санкции или прекращении обслуживания
где находятся данные
какие субподрядчики используются
кто отвечает за ключи шифрования.
XLIX. Продажа технологической компании
92. Покупатель проверяет не количество строк кода
Его интересуют:
принадлежность прав
повторяемая выручка
удержание клиентов
архитектура
масштабируемость
зависимости
безопасность
команда
регуляторные риски
технический долг
способность передать контроль.
93. Технический долг способен стать юридическим
Устаревшая библиотека.
Неподдерживаемая версия.
Отсутствие документации.
Общий пароль.
Код бывшего подрядчика.
Иностранный сервис без договорной защиты.
Каждый элемент способен уменьшить цену сделки или привести к специальным гарантиям продавца.
L. Семь кризисных сценариев цифрового бизнеса
94. Сценарий № 1. Ключевой разработчик заявил права на продукт
Необходимо:
зафиксировать текущий код
сохранить историю репозитория
поднять трудовые и договорные документы
установить даты создания
разделить служебные и личные компоненты
не блокировать автора до сохранения доказательств
оценить возможность продолжения разработки.
95. Сценарий № 2. Инвестор обнаружил, что код принадлежит подрядчику
Нужно:
определить критический объём
проверить условия договора
установить авторов
получить отчуждение или необходимую лицензию
проверить вознаграждение
обновить регистрационные сведения
раскрыть инвестору реальный статус риска.
96. Сценарий № 3. Произошла утечка пользовательской базы
Необходимо:
локализовать событие
сохранить доказательства
установить время выявления
определить категории и объём данных
направить уведомления
проверить действия подрядчиков
зафиксировать меры защиты
подготовить коммуникацию пользователям.
97. Сценарий № 4. ИИ принял ошибочное решение
Нужно установить:
какая модель использована
какая версия
какие данные поступили
какие ограничения были известны
кто подтвердил результат
можно ли было отменить решение
как аналогичные случаи будут выявлены
нужно ли приостановить функцию.
98. Сценарий № 5. Сотрудник скачал код перед увольнением
Необходимо:
сохранить журналы
зафиксировать объём
отозвать доступ
проверить режим коммерческой тайны
определить служебный характер кода
направить юридически точные требования
не преувеличивать охраняемый статус сведений.
99. Сценарий № 6. Платформа заблокировала тысячи партнёров из-за ошибки алгоритма
Нужно:
остановить автоматическое решение
сохранить версию алгоритма
определить затронутых лиц
восстановить доступ
пересчитать удержания
организовать обжалование
проверить договор и будущие требования закона о платформенной экономике.
100. Сценарий № 7. Возбуждено уголовное дело после киберинцидента
Необходимо разделить:
атаку
уязвимость
правила эксплуатации
действия сотрудника
статус КИИ
причинную связь
сохранение следов
своевременность сообщения
последствия.
Общая версия компании не всегда защищает конкретного администратора или руководителя информационной безопасности.
LI. Красные флаги собственника технологической компании
101. Системный риск уже повышен, если:
первый код написан до создания общества и не передан компании
репозиторий зарегистрирован на личную почту
договоры с разработчиками не регулируют исключительные права
не ведётся реестр открытых компонентов
компания не знает, какие данные использовались для обучения модели
все сотрудники используют внешние ИИ-сервисы без правил
клиентские данные передаются в иностранные сервисы без карты обработки
уведомление Роскомнадзора не соответствует реальной архитектуре
режим коммерческой тайны существует только в NDA
увольнение сотрудника не сопровождается аудитом доступа
основной облачный аккаунт принадлежит подрядчику
резервные копии никогда не восстанавливались
план реагирования на инцидент отсутствует
логи можно удалить обычному администратору
решение алгоритма невозможно объяснить и отменить
компания обещает клиенту более высокий SLA, чем получает от инфраструктуры
инвестору заявлены права, которые документально не подтверждены
собственник узнаёт об утечке из сообщения клиента или публикации в интернете.
LII. Что должен видеть собственник цифрового бизнеса
102. Карта интеллектуальных прав
Код.
Дизайн.
База данных.
Алгоритмы.
Товарные знаки.
Домены.
Документация.
103. Карта разработчиков
Основатели.
Сотрудники.
Самозанятые.
Индивидуальные предприниматели.
Студии.
Субподрядчики.
104. Карта данных
Источник.
Цель.
Категория.
Местонахождение.
Доступ.
Передача.
Срок хранения.
105. Карта искусственного интеллекта
Модель.
Поставщик.
Данные.
Решения.
Ограничения.
Человеческий контроль.
106. Карта инфраструктуры
Облако.
Репозиторий.
Домены.
Ключи.
Резервные копии.
Критические зависимости.
107. Карта платформы
Партнёры.
Пользователи.
Комиссии.
Алгоритмы.
Блокировки.
Споры.
108. Карта киберриска
Атака.
Утечка.
Отказ.
Вымогатель.
Инсайдер.
КИИ.
Уведомления.
109. Карта персональной ответственности
Генеральный директор.
Технический директор.
Руководитель разработки.
Директор по данным.
Руководитель информационной безопасности.
Администратор.
Владелец продукта.
LIII. Пятнадцать вопросов собственнику
110. Первый вопрос
Можем ли мы за один день доказать права компании на каждый критический модуль продукта?
111. Второй
Какие компоненты созданы до регистрации общества?
112. Третий
Какие части продукта принадлежат подрядчикам или используются по ограниченной лицензии?
113. Четвёртый
Кто контролирует репозиторий, домены, облако и магазины приложений?
114. Пятый
Какие пользовательские данные используются для обучения и улучшения продукта?
115. Шестой
Соответствует ли уведомление Роскомнадзора реальной обработке?
116. Седьмой
Какие сведения компания действительно способна защищать как коммерческую тайну?
117. Восьмой
Где сотрудники используют внешние ИИ-инструменты без официального согласования?
118. Девятый
Какие решения алгоритм принимает без содержательной проверки человеком?
119. Десятый
Готова ли платформа к требованиям закона, вступающего в силу 1 октября 2026 года?
120. Одиннадцатый
Сколько времени потребуется, чтобы определить объём утечки?
121. Двенадцатый
Можно ли восстановить систему из резервной копии сегодня?
122. Тринадцатый
Сохранятся ли доказательства после действий технической команды при атаке?
123. Четырнадцатый
Какие заверения инвестору не подтверждены документами?
124. Пятнадцатый
Если завтра уйдёт технический директор, сможет ли компания продолжить работу без его личных аккаунтов и знаний?
LIV. Модель Аналитического центра ADVOLAW
125. Первый уровень — права
Код.
Дизайн.
Базы.
Бренд.
Ноу-хау.
126. Второй уровень — люди
Основатели.
Работники.
Подрядчики.
Авторы.
Администраторы.
127. Третий уровень — данные
Получение.
Основание.
Использование.
Локализация.
Защита.
128. Четвёртый уровень — алгоритм
Модель.
Обучение.
Ограничения.
Контроль.
Результат.
129. Пятый уровень — инфраструктура
Облако.
Репозиторий.
Интеграции.
Логи.
Резервирование.
130. Шестой уровень — рынок
Клиенты.
Партнёры.
Платформа.
Лицензии.
Инвестиции.
131. Седьмой уровень — кризис
Утечка.
Сбой.
Претензия автора.
Блокировка.
Кибератака.
Проверка.
Уголовное дело.
LV. Итоговый вывод исследования
Технологический бизнес создаёт стоимость за счёт возможности почти безграничного копирования и масштабирования цифрового продукта.
Одну программу можно одновременно предоставить тысячам клиентов.
Один алгоритм может принимать миллионы решений.
Одна база способна использоваться во множестве продуктов.
Одна модель может стать основой целой экосистемы.
Но масштабирование работает в обе стороны.
Если права на код не оформлены, спор распространяется на весь продукт.
Если алгоритм содержит системную ошибку, она воспроизводится в каждом решении.
Если один компонент уязвим, атака затрагивает тысячи пользователей.
Если незаконно сформирована обучающая выборка, проблема находится внутри каждой версии модели.
Если платформа использует непрозрачное правило блокировки, оно способно одновременно нарушить права тысяч партнёров.
Поэтому цифровая компания не может строить юридическую защиту вокруг утверждения:
Облако не отвечает на вопрос, кому принадлежат права.
Репозиторий не заменяет договор с автором.
Согласие пользователя не разрешает любую обработку.
NDA не создаёт автоматически режим коммерческой тайны.
Внешняя модель ИИ не принимает на себя ответственность за решение компании.
Сертификат безопасности не гарантирует правильное реагирование на инцидент.
Инвестор не приобретает идею — он приобретает контролируемый актив.
В 2026 году цифровой бизнес входит в новый этап регулирования.
Федеральный закон № 243-ФЗ создаёт специальный режим для больших фундаментальных моделей искусственного интеллекта, а ключевые обязанности начнут действовать с 1 марта 2027 года.
С 1 октября 2026 года начинает действовать закон о платформенной экономике, который формализует отношения операторов, партнёров и пользователей цифровых платформ.
Ответственность за утечки персональных данных уже способна достигать сотен миллионов рублей при повторных нарушениях.
В 2026 году уточнён и уголовный контур критической информационной инфраструктуры, включая значение сохранения следов компьютерного воздействия.
Но основной риск технологической компании остаётся не в появлении нового закона.
Он возникает из-за отсутствия контроля над собственным цифровым активом.
Главный актив — система, в которой компания может доказать:
кто создал продукт
кому принадлежат права
какие компоненты использованы
откуда получены данные
как работает алгоритм
кто контролирует решение
где находится инфраструктура
как восстанавливается работа
кто отвечает при ошибке.
Устойчивая модель строится не вокруг утверждения:
Она строится вокруг другого принципа:
Именно такая система превращает код, данные и технологии в полноценный инвестиционный и коммерческий актив.
Материал представляет собой отраслевое исследование. Он не заменяет юридический и технический анализ конкретной программы, модели искусственного интеллекта, базы данных, договора с разработчиком, обработки персональных данных, цифровой платформы, инвестиционной сделки, киберинцидента или уголовного производства.
