Та же AI-модель, но другой продукт:где заканчивается велнесс и начинается MedTech.

Если продукт неверно определит фазу сна, это неудобство. Если же он пропустит риск апноэ или аритмии, человек может не обратиться к врачу. Поэтому во втором случае к модели предъявляются совершенно иные требования. «Средняя точность» алгоритма вообще перестает играть ключевую роль.

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

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

Кроме того, изменения функциональности меняют сам процесс разработки. Вступают в силу требования по управлению рисками, формализованному жизненному циклу программного обеспечения, системе менеджмента качества. Каждое требование должно быть прослеживаемым: от него должна вестись цепочка к конкретному коду и тестам.

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

«Заявления» (claims) — это не только то, что указано в описании функциональности продукта для регулятора. Это также ваш сайт, описание в сторах, реклама и даже экраны с результатами. Регуляторы рассматривают все это в совокупности.

Несколько показательных примеров:

(И в каком порядке):

1. 01

   Начинайте с исследований, а не с продукта.

   Здесь нельзя экономить усилия. Изучите нормативно-правовую базу в каждом регионе, где планируете работать в будущем, поскольку правила сильно различаются. Например, в США действует FDA и существуют свои критерии разграничения wellness-продуктов и медицинских изделий. В Европе применяется регламент MDR, который предъявляет более строгие требования к классификации программного обеспечения. В Германии существует система DiGA, предусматривающая возмещение расходов через государственные системы медицинского страхования.

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

   Пара консультаций на раннем этапе обойдется в сущие копейки по сравнению с затратами на исправление ошибок в будущем.

2. 02

   Определитесь с направлением.

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

3. 03

   С самого начала внимательно относитесь к формулировкам.

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

4. 04

   Собирайте данные с прицелом на будущее.

   Это подразумевает получение согласия на использование данных в исследовательских целях, отслеживание происхождения данных, а также ведение версий наборов данных и моделей. Если заложить эти механизмы на раннем этапе, затраты будут минимальными, тогда как восстановить их впоследствии практически невозможно.

5. 05

   Выделяйте будущую медицинскую составляющую в архитектуре.

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

6. 06

   Учитесь вести документацию без излишней бюрократии.

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

• Данные, полученные без надлежащего согласия или не имеющие клинической маркировки.
• Архитектуру, из которой невозможно выделить регулируемую часть.
• Безопасность и соответствие нормативным требованиям (HIPAA, GDPR, аудиты, соглашения об обработке данных), хотя клиника или страховая компания спросят об этом раньше, чем о самом AI.  Вопросы доверия к работе с данными находятся под пристальным вниманием: в июле 2026 года Федеральная торговая комиссия США (FTC) подала иск против сервиса телемедицины Hims & Hers, обвинив его в передаче рекламным платформам медицинской информации пользователей, несмотря на обещания обеспечить конфиденциальность.
• Интеграции: врачи не станут работать в отдельном приложении, поэтому продукт должен вписываться в их системы и рабочий процесс.
• Доказательная база: метрики вовлеченности должны уступить место исследованиям клинических результатов и экономического эффекта.

Отдельно хочу остановиться на бизнес-модели, поскольку, по нашему опыту, это один из самых проблемных аспектов. Продукты в сфере HealthTech/MedTech часто создают люди с научным или медицинским бэкграундом. Они блестяще знают свою предметную область, но имеют меньше опыта в работе с долгими циклами B2B-продаж, переговорах с плательщиками и построении модели возмещения расходов. На рынке немало примеров компаний, которые прошли регуляторный процесс, но так и не смогли выжить.

Данные, исследования, архитектура продукта, процессы — здесь невозможно поставить приоритет, что важнее. Ведь данные определяют дизайн исследования, исследование зависит от архитектуры, а документация описывает процессы. Если одно звено оказывается слабым, приходится перестраивать всю цепь. Если все-таки расставлять приоритеты, то выстроить их можно так:

• Клинические исследования — самая затратная статья расходов (и по деньгам, и по времени). Набор пациентов, работа с клиническими центрами, этическими комитетами занимает месяцы, а иногда и годы. Этот процесс невозможно ускорить, просто наняв больше инженеров.
• Retrofitting — то есть приведение продукта в соответствие с требованиями «задним числом», самый недооцененный аспект. Если продукт создавался без соблюдения формальных процессов, приходится восстанавливать прослеживаемость, заново валидировать модули, переделывать документацию. Мы не раз наблюдали у клиентов ситуации, когда переписывание регулируемой части с нуля обходилось дешевле, чем попытки «документировать то, что уже есть».
• Intended use — то есть неверный выбор назначения продукта, самая опасная стратегическая ошибка. Слишком широкое определение ведет к повышению класса риска, дорогостоящим исследованиям и долгому пути согласования. Слишком узкое — не обеспечивает продаж. Эта ошибка обходится дороже всего, так как все остальное строится вокруг нее: дизайн исследования, архитектура, документация.

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