О чем материал:
В IT-индустрии классический Due Diligence часто сводится к проверке свидетельств о регистрации программ для ЭВМ, актов приема-передачи и типовых договоров. Однако по своей сути IT-бизнес — это код, архитектура и ноу-хау. Опора исключительно на документы заставляет инвесторов пропускать критические риски: например, скрытое использование Open Source или технологический долг, который потребует полной переработки продукта сразу после сделки.
Специально для блога MDS управляющий партнер DFCenter, эксперт в области Digital Forensics и E-Discovery, автор ТГ-канала «Арбитражная форензика» Анатолий Земцов рассказал, на какие неочевидные детали стоит обращать внимание при проверке технологических активов.
Зарубежное ПО: иллюзии и реальные операционные риски
Один из мифов — поиск «серых схем» использования ушедших вендоров. Российский инвестор с российским капиталом, который планирует приобрести стартап/компанию с продуктом для российского рынка, как критический риск скорее будет оценивать не степень легальности использования продуктов зарубежных вендоров, а сам факт такого использования.
Главный критический риск здесь — не судебные претензии от иностранных правообладателей (что в текущих реалиях маловероятно), а сам факт технологической зависимости. Использование такого ПО сегодня — это либо архаика, поддерживаемая неимоверными усилиями отдельных специалистов там, где пока невозможно импортозамещение, либо инфраструктурные решения, которые не работают с КИИ и госзаказом (44-ФЗ).
Хеджирование таких рисков для инвестора заключается в жесткой оценке: либо отказ от сделки, если архитектура не встраивается в бизнес-модель, либо закладывание сроков и бюджетов на миграцию на отечественные аналоги.
Исключение составляет сценарий, когда инвестор покупает IT-компанию «вместе с продуктом» для закрытия собственных инфраструктурных нужд, которые исторически завязаны на SAP или Oracle. В этом случае технологические риски простоя для покупателя существенно выше гипотетических репутационных или юридических рисков. Здесь работает простая финансовая модель: сопоставление стоимости простоя и стоимости миграции.
Совершенно иная процедура применяется, если инвестор вкладывается в компанию, работающую на зарубежных рынках. Там вендоры представлены легально, и аудиторы проводят классическую проверку: сопоставляют данные лицензионных договоров с аналитикой реального использования (число пользователей, серверов, ядер процессоров, виртуальных машин).
Релокация команды и права на код
Наличие у компании исключительных прав на технологию (РИД) определяется не физическим местонахождением внешнего исполнителя (по договору подряда / авторского заказа), а тем, в каком праве и насколько хорошо составлены документы.
Если разработчик — гражданин РФ, и компания-заказчик зарегистрирована в России, их отношения регулируются российским правом. Место фактического пребывания программиста (ВНЖ, виза цифрового кочевника, туристическая поездка) на владение кодом не влияет. Риск потери прав здесь ровно такой же, как и у любых других компаний — отсутствие юридически правильно оформленных отношений в части создания РИД. Экстерриториальный элемент тут влияет несущественно.
Риски могут возникнуть, если подрядчик/работник — иностранный гражданин. Причем риски не только в части прав на код, но и во множестве других сфер.
Так что первый объект проверки — что технология принадлежит компании — это анализ документов по взаимоотношениям с разработчиками. Если в документах существенные пробелы либо документов просто нет — это потенциальный блок для сделки. Если же документы есть — их соответствие реальности проверяется уже аудитом кода в рамках Tech DD, где проводится выявление авторов конкретных коммитов, участков кода и т. д.
Как выявить наличие технологического долга
Главные признаки технологического долга:
- рост периода выпуска изменений/обновлений,
- увеличение числа сбоев и срочных исправлений,
- большая часть команды занята поддержкой старой системы, а не развитием продукта (новыми функциями).
Желательно также обратить внимание на наличие и процент «устаревших» технологий, критические уязвимости, зависимость от отдельных сотрудников и сложность внесения изменений.
Если техдолг регулярно сдвигает сроки апдейта продукта и/или требует значительной части ресурсов команды, он уже влияет на стоимость бизнеса.
Использование зарубежных AI-ассистентов в корпоративной практике
Проверки на «IP-загрязнение» кода нейросетями и контроль за использованием локальных LLM-моделей уже стали частью аудита компании. Анализируется, какие ИИ-сервисы используют сотрудники, какие данные или исходный код туда передают, где эти данные обрабатываются и сохраняются, а также может ли сервис использовать эти данные для обучения.
В подавляющем большинстве случаев выявляются риски нарушения 152-ФЗ и 98-ФЗ. Критичность этих рисков для сделки оценивается в каждом конкретном случае покупателем отдельно.
Использование локальных моделей эти риски полностью не снимает.