Код, который нельзя потрогать

Сделки с технологическими и ИИ-компаниями сохраняют привычную форму, но их экономическое содержание стало принципиально иным: стоимость теперь сосредоточена в интеллектуальной собственности, данных и команде, а не в основных средствах. Это меняет и структуру сделки, и выбор арбитражной площадки. Какие вопросы необходимо снять до подписания и почему российское право уже перестало быть «бедным родственником» английского, “Ъ” рассказал партнер, глава практики сопровождения сделок и проектов «Дякин, Горцунян и партнеры» Сурен Горцунян.

Когда в середине 1990-х я пришел на рынок слияний и поглощений, реальный «объект» сделки нередко можно было в буквальном смысле обойти пешком. Цеха, склады, станки и краны солидно именовались в документах «основными средствами», юристы ездили на выездные проверки, сверяя документы с реальностью, и у значительной части того, что приобретал покупатель, имелись адрес и инвентарный номер.

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

И, казалось бы, сделка M&A в технологиях (а тем более в сфере искусственного интеллекта) внешне остается знакомой, но экономическая реальность у нее уже совершенно другая. Потенциальные риски и юридические задачи выглядят не так, как прежде, и главной задачей юриста становится не столько проверить, что актив существует, сколько понять, кому он принадлежит, на каких условиях им можно распоряжаться и сохранится ли его ценность после смены владельца.

Первый вопрос любой технологической сделки звучит обманчиво просто: принадлежит ли продавцу то, что он продает?

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

Российское право дает вполне понятный каркас: программы для ЭВМ охраняются авторским правом, базы данных могут пользоваться несколькими режимами правовой охраны, техническое решение можно запатентовать и так далее. Исключительное право на служебное произведение по общему правилу принадлежит работодателю, если оно действительно создавалось в пределах трудовых обязанностей работника и соответствует поставленной и оплаченной работодателем задаче. И вот здесь начинается практика.

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

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

При IP due diligence проверяется многое: цепочка прав на существенные элементы продукта, лицензии на стороннее программное обеспечение, использование open source и «цепочки» титула, отношения с работниками и исполнителями. В сделках с ИИ к этому добавляется новый вопрос: а на чем, собственно, была построена и обучена модель, какова политика ее использования, в том числе в отношении прав на результаты, и право какой юрисдикции применимо? Поэтому IP due diligence — своего рода позвоночник технологической сделки.

Применительно к ИИ принято говорить, что данные — это новая нефть. Однако с точки зрения M&A сравнение не вполне точное: нефть после покупки месторождения обычно не предъявляет покупателю претензий.

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

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

Если модель обучалась на чужих текстах, изображениях, музыке или программном коде, возникает другой вопрос: имела ли компания право использовать соответствующий массив данных именно таким образом? В России этот вопрос пока не урегулирован законодательством или устоявшейся судебной практикой (за исключением разработчиков суверенных и национальных больших фундаментальных моделей ИИ, которым разрешено использовать чужие произведения для сбора датасетов и обучения нейросетей, полученных при соблюдении определенных условий). В других юрисдикциях этот вопрос уже стал предметом крупных споров между правообладателями, авторскими обществами и разработчиками ИИ.

Для покупателя проблема носит отнюдь не академический характер. Представим, что после сделки выясняется: часть критически важного обучающего массива использовалась без необходимых прав. Нужно ли переобучать модель? Насколько удаление материалов и переобучение модели ухудшит ее качество? Сколько времени и денег потребуется? В каком размере и кому выплачивать компенсацию? Иногда юридический дефект датасета способен превратиться непосредственно в дефект самого продукта. Именно поэтому data due diligence постепенно становится самостоятельной дисциплиной наряду с IP due diligence.

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

Люди, регулярно уходящие в собственные проекты,— это третья особенность технологических сделок. Если продукт держится на пяти инженерах, а ключевую архитектуру понимают двое, покупка 100% акций еще не означает приобретения 100% бизнеса — через полгода покупатель может обнаружить у себя юридическую оболочку компании, права на код вчерашней версии продукта и команду, половина которой уже работает у конкурента.

Отсюда особая роль retention-механизмов, опционных программ, отложенной части цены и earn-out. Но и здесь российская специфика требует аккуратности: привычные английскому праву обязательства non-compete, как правило, переносятся в российские соглашения со своими особенностями. Иногда экономически эффективнее оказывается не запрещать человеку уходить, а создать для него достаточную мотивацию остаться: потенциально это усложнение условий сделки, новые договорные механизмы, опционные договоренности и прочее.

Еще 20 лет назад при структурировании крупной российской M&A-сделки вопрос о применимом праве часто решался автоматически: к сделке свыше нескольких десятков миллионов долларов применялось английское право, а российское оставалось для корпоративных документов и регистрационных действий.

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

Для технологического M&A особенно интересна комбинация опциона и earn-out. Представим, что инвестор покупает 70% ИИ-компании, а основатель сохраняет 30% и продолжает руководить бизнесом. Стороны могут заранее договориться, при каких условиях оставшаяся доля будет продана через несколько лет и как будет определяться ее цена — например, исходя из выручки, EBITDA или иных согласованных показателей, и для технологической компании это зачастую разумнее, чем сегодня бесконечно спорить об оценке.

Наконец, технологический M&A все реже остается исключительно частным делом продавца и покупателя. В России сделки с иностранным элементом могут подпадать под требования законодательства о стратегических инвестициях, если деятельность компании относится к установленным законом стратегическим видам. Дополнительный контур регулирования сформировали специальные экономические меры и разрешительный порядок для ряда сделок с участием лиц из определенных иностранных юрисдикций.

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

Любой хороший M&A-договор пишется с надеждой, что раздел о разрешении споров никогда не понадобится — и все же именно в момент сделки стороны выбирают поле, на котором однажды могут встретиться уже не как партнеры.

Для сделок между российскими сторонами естественным выбором стали российские арбитражные учреждения, прежде всего РАЦ и МКАС. Российское законодательство устанавливает специальные требования к арбитражу корпоративных споров, и это необходимо учитывать при подготовке оговорки. А вот в международных сделках география заметно изменилась: если раньше в российских M&A-проектах почти рефлекторно писали LCIA или SCC, то сегодня стороны все чаще смотрят на Гонконг, Сингапур и Дубай. HKIAC, SIAC и DIAC предлагают развитую арбитражную инфраструктуру и воспринимаются многими участниками как удобные нейтральные площадки. Но одной красивой арбитражной оговорки недостаточно — важно еще и заранее продумать, где находятся активы контрагента, где придется исполнять решение, как на процедуру повлияют санкционные ограничения и специальные нормы российского процессуального законодательства, включая статьи 248.1 и 248.2 АПК РФ.