Представьте: ваш продукт работает без сбоев уже полгода. Пользователи довольны, метрики растут.
А потом один клиент сталкивается с редким случаем, который никто не продумал. И уже маячит штраф вместо роста. Впереди сорванная сделка и иск.
Это не выдумка: одна компания уже заплатила реальными деньгами за похожую невнимательность.
Вот так чаще всего и подводит IT-продукт: сценарий, о котором никто не подумал. Баг в коде тут почти ни при чём.
На сайте это называется форматом Audit & Second Opinion. Аудит юридической архитектуры помогает найти такой сценарий заранее, до того как он случится.
Кому и когда он нужен
Он подходит для уже работающих продуктов.
Если юридической логики в продукте пока просто нет, сначала её нужно построить. Для этого есть отдельный формат, Core Architecture & Triage Logic, подробнее в гиде для инвестора.
Но вот в чём загвоздка: заранее это не всегда понятно даже вам самим. Иногда только аудит честно покажет, с чем вы на самом деле имеете дело.
Он нужен, когда логика уже есть: продукт работает или почти готов к запуску, но её никто не проверял со стороны.
Обычно за этим стоит одна из трёх историй:
- Свои правила. Разработчики написали их сами, юриста никто не звал: программисты выбирали то, что проще закодировать, а закон никто не учитывал.
- Логика в наследство. Сменился технический директор (CTO), пришёл фаундер после слияния, обновилась команда: логику писали другие люди, и сейчас никто не скажет, насколько ей можно доверять.
- Сделка на носу. Инвестор или партнёр хочет знать, как продукт работает на самом деле, за пределами презентации: это и есть due diligence.
Что реально происходит в рамках аудита
Мы делаем экспресс-разбор существующей логики и ищем два типа проблем:
- Где автоматика может выдать пользователю юридически необоснованный или опасный ответ.
- Моменты, когда она должна была остановиться и передать решение человеку, но вместо этого продолжила действовать сама.
Представьте техосмотр подержанной машины: специалист проверяет всё, но разбирает и меняет только то, что вызывает сомнения, например, тормоза, ремни или подвеску, если они изношены.
Двигатель и остальные исправные узлы при этом никто не трогает.
С продуктом происходит то же самое: мы находим конкретные места, где он может дать сбой в первой же нештатной ситуации.
На выходе вы получаете отчёт с конкретными точками риска: что именно может пойти не так, в каком сценарии и как это исправить.
Гипотетический пример: где чаще всего находят проблему
Вот как это работает на практике. Сценарий вымышленный, но собран из типичных паттернов.
Сервис проверяет контрагентов и месяцами исправно выдаёт заключения.
При аудите выясняется: для одного типа документов, например, выписок из зарубежных реестров, логики попросту нет.
Алгоритм в этом случае возвращает наиболее вероятный ответ вместо проверенного и никак не помечает его как менее надёжный.
Как это видит фаундер: «Ну, мелкий баг, поправим». И отчасти он прав: обычное тестирование качества продукта (QA) действительно имеет шанс его поймать.
А вот как это видит инвестор: клиент увидел «проверка пройдена», подписал сделку и положился на этот ответ как на факт.
Если контрагент окажется недобросовестным, у клиента есть все основания требовать возмещения именно от сервиса: он дал уверенный ответ, хотя должен был честно сказать «не знаю».
В этом и вся разница между багом и юридическим риском. У бага простое объяснение: ошибка в коде.
А у юридического риска причина другая: никто в компании заранее не решил, что систему в таких случаях нужно останавливать и передавать решение человеку.
Пока такой документ не попадался, риск как будто не существует.
Но аудит для того и нужен: искать именно такие предсказуемые слепые зоны, где отсутствие правила однажды обернётся не только технической, но и юридической проблемой.
Чем это отличается от разработки логики с нуля
Core Architecture & Triage Logic с нуля строит для нового продукта правила, которых ему пока недостаёт: деревья решений, стоп-сигналы, критерии эскалации.
Аудит решает обратную задачу: разбирает то, что уже написано, но никогда не проверялось системно.
Иногда выясняется, что логики местами вообще нет. Это серьёзнее отдельных недочётов: перед вами полное отсутствие правил.
И это нормально: аудит для того и нужен, чтобы это вскрыть.
Дальше в дело вступает Core Architecture (тот самый формат Core Architecture & Triage Logic) вместо повторной проверки.
Чек-лист: 3 признака, что аудит нужен прямо сейчас
- Продукт уже принимает решения без участия человека, а логику никто ни разу формально не проверял. Жалобы отсутствуют? Это скорее везение, чем доказательство надёжности.
- Логику писала предыдущая команда, и никто из нынешней не может объяснить её целиком. Если на вопрос «что делает система в пограничном случае X» вам отвечают «наверное, что-то разумное», аудит нужен уже сейчас.
- На носу сделка, раунд инвестиций или крупный клиент, а под рукой нет ничего, кроме презентации от собственной команды.
Часто задаваемые вопросы
Чем аудит отличается от обычного код-ревью? Код-ревью проверяет, работает ли код так, как задумано.
Аудит юридической архитектуры проверяет другое: правильно ли задумано то, что код реализует.
Он смотрит, нарушает ли сама логика закон или права пользователя, даже если технически всё работает без ошибок.
Что если аудит покажет, что всё в порядке? Это тоже результат: время потрачено с пользой.
Вы получаете независимое подтверждение, что продукт выдерживает проверку. Это весомый аргумент и на переговорах с инвестором, и для собственного спокойствия.
Нужен ли аудит, если продукт ещё не запущен? Если вы точно знаете, что логики ещё нет, начните с Core Architecture & Triage Logic, а к аудиту вернётесь позже.
Не уверены, есть ли логика вообще? Тогда начните именно с аудита: экспресс-проверка быстро покажет, с чем вы на самом деле имеете дело.
Сколько это займёт? Из четырёх форматов юридической архитектуры это самый быстрый.
Причина простая: аудит работает с готовой логикой, а не строит её с нуля.
Один непроверенный сценарий может стоить сорванной сделки, штрафа или доверия инвестора. Посмотрите, как устроен аудит, формат Audit & Second Opinion среди остальных вариантов работы.