# Как стартапу доверить прототип B2B-партнёру: 6 правил, которые защищают и отношения, и IP

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

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

## Почему «просто дать попользоваться» не работает

Без документа, фиксирующего условия, у вас нет ни одного рычага. Партнёр может показать ваше решение своим коллегам, подрядчикам, конкурентам. Может использовать часть логики в собственном продукте. А вы будете спорить о том, что «мы же просто обсуждали». В B2B-сегменте, где цикл сделки долгий и вовлечены десятки людей, такие ситуации случаются регулярно — не из злобы, а из-за размытых границ.

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

## Правило 1: определите, что именно передаёте

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

Запишите это в спецификации к договору: что именно передаётся, в каком объёме, для каких задач. Формулировка «прототип системы» без деталей — это приглашение к спорам через полгода.

## Правило 2: зафиксируйте цель передачи и границы использования

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

Это не «параграфы из страха». Это стандартная практика. Крупные компании сами просят такие условия — их юридические службы проверяют каждый входящий документ. Если вы приходите с уже готовой структурой, это экономит время обеих сторон и показывает зрелость команды.

## Правило 3: разделите IP до передачи, а не после

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

Определите это заранее: базовая IP остаётся за стартапом; улучшения, сделанные силами партнёра, принадлежат партнёру; совместно созданные элементы — совместная собственность с правом лицензирования. Пропишите механизм: как фиксируется факт доработки, кто принимает решение о совместном использовании.

Этот пункт не должен пугать партнёра. Наоборот: если вы не хотите делиться IP, зачем вам пилот на его площадке? Честная формулировка «мы защищаем и вашу, и нашу собственность» звучит убедительнее, чем молчание по теме.

## Правило 4: ограничьте доступ внутри компании партнёра

Даже если договор подписан, в реальности прототип может оказаться у пяти человек. Попросите партнёра назвать ответственного за приёмку и перечень лиц, которые будут иметь доступ. Это не паранойя — это минимальная гигиена. Для чувствительных решений можно предложить: доступ только на площадке партнёра, без выноса; или совместные сессии, где ваша команда присутствует при тестировании.

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

## Правило 5: зафиксируйте метрики и критерии успеха до начала пилота

Если вы передаёте прототип для оценки, у вас должны быть чёткие критерии, по которым партнёр скажет «да, это работает» или «нет, не подходит». Без этого пилот превращается в бесконечное «мы ещё подумаем», а ваш прототип — в экспонат на полке.

Сформулируйте вместе с партнёром: какие показатели измеряются, в каком объёме, за какой период. Зафиксируйте в протоколе или приложении к договору. Это защищает и вас (вы не зависите от субъективного впечатления), и партнёра (у него есть объективная основа для решения).

## Правило 6: предусмотрите выход — что происходит, если пилот не удался

Самый недооценённый пункт. Что происходит с прототипом, если решение не принято? Возвращение в течение N дней? Удаление данных? Запрет на использование накопленной информации?

И что происходит, если пилот успешен? Автоматически ли начинается коммерческая фаза? Какие условия лицензирования или поставки обсуждаются заранее? Чем конкретнее эти сценарии, тем меньше эмоционального давления в момент принятия решения.

## Что это даёт на практике

Команда, которая приходит к партнёру с готовой структурой передачи — ограниченный образец, чёткие границы, разделённое IP, метрики успеха — вызывает доверие быстрее, чем команда, которая «просто даст посмотреть». Партнёр видит, что вы думаете о его рисках так же, как о своих. А это именно то качество, которое отличает проект, готовый к масштабированию, от идеи, которая остаётся идеей.

Стартап-студия ГГНТУ сопровождает проекты на всех этих этапах: от структурирования IP до подготовки документов для пилота и защиты перед инвестиционным комитетом. Если вы находитесь в точке «прототип готов, партнёр есть, а договор нет» — это как раз тот момент, когда правильная структура экономит месяцы споров.

Подписывайтесь на канал →