Перед сделкой инвестор обычно проверяет две вещи: финансы и технологию.
Юристы смотрят учредительные документы, налоговую историю, интеллектуальную собственность.
Но у продукта, который сам принимает решения (одобряет заявку, проверяет контрагента, рассчитывает выплату), есть третий слой.
Про него часто забывают: это юридическая логика самого алгоритма.
Три слоя due diligence, и почему один из них пропускают
Due diligence стартапа (проверка бизнеса перед сделкой) обычно строится вокруг трёх вопросов.
- В порядке ли финансы?
- Насколько чисто оформлено владение бизнесом?
- Технология делает то, что обещано?
Финансовый и юридический слои закрывают бухгалтеры и юристы.
За технический слой обычно отвечает ИТ-директор инвестора (CTO) или приглашённый разработчик.
А вопрос «правильно ли задумана сама логика, которую реализует код» остаётся без ответа.
У бухгалтера в фокусе цифры: баланс, налоги, расходы.
Разработчик смотрит на код: работает ли он технически без ошибок.
Законность самой логики при этом выпадает из вида.
У юриста без отдельной специализации в поле зрения договоры и внутренняя документация.
Кто именно принимает решения внутри самого алгоритма, остаётся загадкой.
Сразу оговорюсь: в регулируемых нишах вроде банкинга, страхования и медицины профильные комплаенс-юристы уже запрашивают описание алгоритмов как часть отраслевого due diligence.
Для них это привычная практика.
Сложность в другом: такая проверка обычно проходит разово, на словах, без единого документа, к которому можно вернуться на следующем раунде или после смены команды.
Слепая зона возникает из-за отсутствия системы: за пределами этих узких ниш такие проверки идут бессистемно, время от времени.
Кое-где их просто нет.
Что упускают при проверке
Формальности вроде лицензий и отказов от ответственности в пользовательском соглашении тоже важны.
Это территория обычного юриста.
Дальше речь о конкретных решениях внутри кода:
- В каких случаях алгоритм одобряет заявку сам?
- Когда он обязан остановиться и передать решение человеку?
- Где проходит эта черта, и кто её придумал?
Чаще всего эту границу определяет случайный выбор программиста: как было проще закодировать, так и получилось.
Продукт при этом может месяцами работать без единой жалобы.
А потом один редкий случай оборачивается штрафом, судом или испорченной репутацией.
Причём уже после того, как инвестор вложил деньги.
Один частый пример такой границы: как продукт различает техническую ошибку внешнего сервиса и настоящий юридический отказ. Разбор на конкретном примере →
А как быть с нейросетью?
Хороший вопрос.
У кода правила видны: «если — то».
У нейросети такого нет: она обучена на примерах и сама находит закономерности внутри данных.
Аудит не разбирает веса модели.
Это миллионы чисел, которые невозможно прочитать по-человечески, и для проверки они не нужны.
Он проверяет всё, что построено вокруг неё:
- Есть ли порог уверенности, после которого система обязана остановиться и передать решение человеку?
- Ведётся ли запись каждого решения, чтобы его можно было проверить позже?
- Что происходит, если уверенность модели в собственном ответе падает?
Именно этот контур вокруг неё определяет, где заканчивается автоматика и начинается ответственность человека.
Одно важно сделать сразу, другое может подождать
Здесь есть честная граница.
Речь о регулируемых нишах: кредитование и скоринг, страхование, медицина, подбор персонала (HR-tech), автоматизация комплаенса (RegTech) и другие сферы, где решения затрагивают права людей.
Тут цена ошибки выходит далеко за рамки одного штрафа.
На кону может быть лицензия, репутация и личная ответственность руководителей.
А в обычном потребительском продукте на самой ранней стадии (в MVP) всё иначе.
Тут алгоритм пока принимает только простые решения без юридических последствий, и глубокий аудит логики может спокойно подождать до следующего раунда.
Это нормально, но к теме стоит вернуться позже.
Как эту часть due diligence закрывают на практике
На сайте для этого слоя есть отдельный формат: Audit & Second Opinion.
Это экспресс-разбор именно юридической логики.
Специалист ищет два типа мест:
- где алгоритм может дать пользователю опасный или юридически необоснованный ответ;
- когда он должен был остановиться, но вместо этого продолжил работать.
На выходе вы получаете отчёт с конкретными точками риска:
- что может пойти не так;
- в каком сценарии;
- как это исправить.
Аудит подсвечивает системные логические разрывы и юридические риски в заданных сценариях и помогает устранить их до сделки.
Но у него есть границы: он не заменяет операционный комплаенс и не страхует от любого будущего иска.
У некоторых стартапов юридической логики пока попросту нет, и тогда вопрос смещается на этап её создания.
Для этого есть другой формат: Core Architecture & Triage Logic.
Чек-лист: что спросить у стартапа перед due diligence
- Кто принимал решения в спорных местах логики? Ответ «разработчики решали по ходу дела» звучит тревожно: юридический слой логики появился сам собой, без осознанного решения.
- Есть ли документ, описывающий, где алгоритм обязан остановиться? Имеется в виду простое описание словами: в каких случаях система передаёт решение человеку.
- Проверял ли эту логику кто-то, кроме самой команды? Внутренняя уверенность команды в своём продукте не заменяет независимую проверку.
Документа может не быть, и это нормально: у многих быстрорастущих компаний его тоже нет.
Это повод спросить, как команда планирует его создать.
Due diligence внутри компании
Due diligence нужен инвестору перед вложением.
Он точно так же нужен человеку, который принимает компанию изнутри — например, новому генеральному или коммерческому директору, вступающему в должность в уже работающей компании.
Принцип тот же: проверка перед тем, как взять на себя ответственность.
Меняется только направление: вместо чужого стартапа перед сделкой это теперь собственная новая зона ответственности внутри компании.
Чек-листы для этой ситуации:
Часто задаваемые вопросы
Чем due diligence юридической логики отличается от обычной юридической проверки? Обычная юридическая проверка при due diligence касается договоров, корпоративной структуры, интеллектуальной собственности.
Проверка юридической логики смотрит на другое: что делает сам алгоритм и нарушает ли это закон или права пользователя.
Кто обычно инициирует такую проверку: инвестор или сам фаундер? Обе стороны.
Инвестор хочет понять реальные риски до вложения.
Фаундеру важно прийти на переговоры с готовым независимым подтверждением вместо обещаний.
А если проще заложить бюджет на будущие штрафы, чем тратить время на проверку логики? Для нерегулируемого потребительского продукта на самой ранней стадии в этом есть логика: цена ошибки там действительно ограничена и предсказуема.
Для регулируемой ниши это рискованная ставка.
Штраф обычно составляет только часть цены: сверху добавляются отзыв лицензии, предписания регулятора и репутационные потери, которые в бюджет заранее не заложишь.
Сколько занимает такая проверка? Из четырёх форматов юридической архитектуры формат Audit & Second Opinion самый быстрый: он работает с уже существующей логикой, а не создаёт её заново.
Хотите понять, что на самом деле проверяют в юридической логике вашего продукта перед сделкой?
Посмотрите, как устроен аудит: формат Audit & Second Opinion среди остальных вариантов работы.