Технический аудит при покупке ИТ-бизнеса

Материал подготовлен по мотивам интервью Анатолия Земцова (DFCenter), данного им Анастасии Нерчинской в рамках проводимого под ее авторством исследования «Tech M&A 2026: Инвестиционный ландшафт, тренды, взгляд индустрии».

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

В рамках исследования мы попросили Анатолия Земцова, управляющего партнера DFCenter, рассказать о том, каких рисков позволяет избежать технический due diligencе, чем его выводы могут помочь в работе над сделкой и что инвесторы хотят узнать об активе в первую очередь. Интервью провела Анастасия Нерчинская, автор исследования.

Анастасия Нерчинская, автор исследования: Коллеги по рынку Tech M&A отмечают, что в 2025 г. запросы на проведение технической экспертизы ПО перед сделкой стали глубже и прицельнее, чем 2−3 года назад. Анатолий, если говорить про 2025 г., — с какими задачами чаще всего потенциальные покупатели ИТ-бизнесов обращались за технической экспертизой программных продуктов? Какие области проверки ПО можно назвать приоритетными по итогам 2025 г.

Анатолий Земцов, управляющий партнер DFCenter: Основная цель таких обращений — получение независимого мнения относительно того, полностью ли и верно ли продавец ИТ-продукта или получатель инвестиций описывает свой продукт / актив в презентациях, технической документации и прочих подобных документах. И дело даже не в недоверии одной стороны или умысле другой. Очень часто, особенно для растущих ИТ-компаний, маркетинговые материалы несколько обгоняют реальное положение вещей в разработке. При этом сам производственный цикл разработки ПО обгоняет уже процесс создания технической документации к этому ПО.

Также покупателю все чаще важно понимание «из чего сделан» продукт / актив. Поэтому клиентам интересны как общие вопросы (например, способен ли софт решать описанные в презентации задачи описанными способами?), так и достаточно прикладные (например, используется ли в продукте open source, и если да, то под какими лицензиями? Имеются ли в продукте фрагменты кода, потенциально сгенерированного ИИ-инструментами?).

Также могу отметить рост в 2024—2025 гг. дополнительного интереса к, во-первых, вопросу о наличии в софте элементов, запрещенных для использования в отечественном программном обеспечении (Реестр РПО), что особенно важно для крупных компаний, работающих по 223-ФЗ.

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

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

А.З.: Подобный аудит стоит проводить во всех случаях, когда риск несостоятельности, технической или финансовой, такого актива является значимым для приобретателя. Причем не только при приобретении ИТ-компании целиком вместе с таким активом, но и при приобретении самого такого ИТ-продукта (для крупных сделок, конечно же) или при оценке и приемке результата, созданного по заказу (имеются в виду договоры на разработку ПО).

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

Часть таких задач покупатели, особенно «стратеги», возлагают на свои внутренние подразделения. В ряде случаев это вполне оправдано. Однако есть и прецеденты конфликта интересов и более лояльного, чем необходимо, отношения к подобным проверкам.

А.Н.: В сделках M&A часто времени на техническую экспертизу совсем мало, а для принятия инвестиционных решений нужно понимать ситуацию крупным планом и видеть потенциальные red flags. Расскажите, пожалуйста, существует ли некий базовый sanitycheck или «программа-минимум» технической экспертизы ИТ-активов и какие области проверки она включает?

А.З.: «Программой-минимум», в случае закрытия именно IP-рисков, можно назвать анализ кода для ответа на вопросы о наличии open source (в разрезе связанных с ним лицензионных исков), а также аудит процесса разработки (история создания, авторы, вовлеченность в разработку и т. д.).

Далее добавляются вопросы о соответствии функционала ПО представленной документации, вопросы о качестве реализации, реальных возможностях софта. А при дальнейшем погружении могут разрешаться уже достаточно «кастомизированные» вопросы и задачи, например о возможных уязвимостях (тематика, пограничная с ИБ), потенциале к масштабированию и так далее.

Как я говорил ранее, подобный аудит стоит проводить во всех случаях, когда риск несостоятельности, технической или финансовой, такого актива является значимым для конкретного приобретателя.

А.Н.: Существует ли специфика технической экспертизы в зависимости от сегмента ИТ-решений? Например, есть ли различия или дополнительные акценты при проверке ИИ-систем, финтех-сервисов, компаний из B2B Software (провайдеры ПО) или решений в сфере кибербезопасности?

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

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

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

А.Н.: Любому ИТ-эксперту хорошо известно, что вопросы титула на ПО, а также связанных с ним рисков и их митигации напрямую зависят от точности определения круга авторов ПО. Это — краеугольный камень состоятельности приобретаемого ИТ-актива и фундамент его оценки, поскольку от корректности установления авторства зависит наличие у таргета прав на ключевые активы, которые невозможно быстро заменить на другие. Анатолий, было бы интересно узнать, какие подходы и практики Вы обычно используете в рамках процедуры установления круга авторов ПО (сверка логов в репозиториях, поиск"цифровых следов" в кодовой базе, другие приемы)?

А.З.: На практике наши специалисты используют комбинацию нескольких подходов, поскольку опора только на один источник информации может не дать гарантированно достоверный результат. В первую очередь анализируются логи и метаданные в системах контроля версий (Git, SVN и т. п.): история коммитов, авторы, временные интервалы, структура веток, характер правок. Это позволяет восстановить хронологию разработки и выявить ключевых участников.

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

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

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

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

А.Н.: Есть вопрос, который вызывает неоднозначные оценки и дискуссии, но при этом затрагивает качество юридической проверки титула на ПО, в связи с чем заслуживает внимания. Существует мнение, что при анализе юридической чистоты прав на ПО достаточно убедиться в наличии свидетельства государственной регистрации на ПО или во включении его в иные публичные реестры, чтобы «получить» так называемую презумпцию авторства. К примеру, с моей точки зрения, такой подход не является хорошей практикой и сам по себе уязвим и рискован. Было бы интересно узнать Вашу позицию по этому вопросу? Может ли такой подход быть оправдан в каких-либо случаях?

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

ФИПС не проверяет «реальность» и тем более работоспособность кода, это не является его задачей. В связи с чем свидетельство о государственной регистрации программы подтверждает только тот факт, что некое лицо в некую дату уже имело в своем распоряжении некий (предположительно) программный код. Но нет никаких гарантий, что эти «идентифицирующие программу для ЭВМ материалы в форме распечатки исходного текста» являются осмысленным, работоспособным, законченным и, что немаловажно, авторским кодом;

ФИПС не проверяет код на предмет наличия в нем объектов, правами на которые обладают третьи лица (open source, ИИ-сгенерированный код, элементы явно проприетарного кода).

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

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

Анатолий, по Вашему мнению, могут ли результаты технического аудита ПО «помочь» юристам установить правовой режим или вид ПО — например, понять, что вот здесь — производное ПО, а здесь — составное? Если в Вашей практике были интересные примеры такого рода задач, пожалуйста, расскажите о них.

А.З.: Да, ответ на эти вопросы будет получен. История развития ПО, преемственность его версий и степень их «родства» — это распространенные вариации вопроса «является ли ПрЭВМ-1 воспроизведением / модификацией ПрЭВМ 2», часто встречающегося не только в рамках аудитов, но и в рамках судебных экспертиз в IP-спорах.

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

В большинстве случаев эти компании начинают задумываться о проведении внутреннего расследования по факту потенциальной утечки разработок или даже уже находятся в стадии судебного разбирательства по этому поводу. Однако, если к вопросу о сходстве добавить вопрос о возможных причинах такого сходства (о чем часто забывают), то почти всегда выясняется, что причина сходства — две команды разработки независимо друг от друга использовали одни и те же open source-элементы. Это особенно актуально именно для компаний, работающих в одной сфере — потому что в этой сфере именно эти конкретные open source-решения стали в какой-то момент общеупотребимыми.

В нашей практике был случай, когда мы показали заказчику, что элементы «его» кода есть не только в коде его конкурента (как он и подозревал), но и в коде еще двенадцати программных продуктов компаний, работающих в аналогичном сегменте бизнеса. Только в других странах, от ЮАР до Новой Зеландии и никак не связанных с Россией.

А.Н.: И еще один вопрос, связанный с юридическими, а сегодня и регуляторными, ИТ-рисками. Известно, что при разработке ПО широко используются различные open source-решения. В зависимости от масштаба проекта их число может исчисляться несколькими десятками, а то и сотнями, что делает невозможной полноценную юридическую проверку каждого из них. Поделитесь, пожалуйста, мнением, всегда ли при покупке ИТ-компании, следует проверять наличие в кодовой базе сторонних компонентов — таких как open source или фрагментов ПО, созданных с помощью инструментов ИИ, например, посредством технологии вайбкодинга? На чем следует фокусироваться при такой поверке?

А.З.: Обязательно. Причины следующие:
Использование open source подразумевает необходимость соблюдения определенных лицензионных требований. Да, в России в настоящее время маловероятен сценарий, когда зарубежные правообладатели смогут предъявить какие-либо претензии к российскому разработчику, но они не нулевые (кейс Bytes&Rights vs РедСофт). Также эти риски могут стать реальными и при выходе ИТ-компании на рынки в зарубежных странах, где правообладатели более активны.

Определенная часть open source сейчас находится в «черном списке» Минцифры — его нельзя использовать при создании отечественных ИТ-продуктов и включить в реестр российского ПО. А также — это ограничение для участия в закупках по 223-ФЗ и для использования государственными заказчиками. То есть если такие продажи планируется сделать важной часть коммерциализации — этот риск весьма существенен.

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

Использование некоторых ИИ-инструментов для написания кода потенциально ведет к рискам «принудительных лицензий» на такой код. Подобные положения содержатся, например, в правилах GigaChat. А в правилах большинства зарубежных сервисов говорится о праве на использование такого кода в рамках обучения, анализа и т. п. целей. Некоторые участники ИТ-рынка расценивают риск анализа их кода как значительный.

Также не будем забывать и про риски информационной безопасности такого кода. Мы не утверждаем, что open source или код, сгенерированный ИИ, обязательно имеет проблемы в плане безопасности, но независимая оценка тут также важна.

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

Анализ сделок Tech M&A всегда требует пристального фокуса на трех плоскостях: оценке, юридических аспектах и технической составляющей. На эти процессы нельзя смотреть «по отдельности» без учета предпосылок и выводов каждого из них. В современном Tech M&A технологическая и юридическая экспертиза давно перестали существовать параллельно.
Несмотря на то что первая разрешает вопросы факта, а вторая — вопросы права, сегодня они настолько тесно связаны, что образуют практически единый контур. Выводы технической экспертизы напрямую влияют на обоснование юридических ИТ-рисков, в первую очередь от них зависит ответ на главный вопрос — у кого права на ключевое ПО? А выявленные юридические риски требуют подтверждения или верификации со стороны технических экспертов. Сюда можно смело добавить и вопросы оценки, — известно, например, что титульные риски на ПО не закладываются в ставку дисконтирования, хотя наличие прав на ПО является главной предпосылкой создания основной стоимости такой компании.