Тая ж AI-мадэль, але іншы прадукт:дзе заканчваецца велнес і пачынаецца MedTech.

Калі прадукт няправільна вызначыць фазу сну, гэта нязручнасць. Калі ж ён прапусціць рызыку апноэ або арытміі, чалавек можа не звярнуцца да лекара. Таму ў другім выпадку да мадэлі прад'яўляюцца зусім іншыя патрабаванні. «Сярэдняя дакладнасць» алгарытму ўвогуле перастае адыгрываць ключавую ролю.

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

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

Акрамя таго, змены функцыянальнасці змяняюць сам працэс распрацоўкі. Уступаюць у сілу патрабаванні да кіравання рызыкамі, фармалізаванага жыццёвага цыклу праграмнага забеспячэння і сістэмы менеджменту якасці. Кожнае патрабаванне павінна быць прасочвальным: ад яго павінен ісці ланцужок да канкрэтнага кода і тэстаў.

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

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

Некалькі паказальных прыкладаў:

(І ў якім парадку):

1. 01

   Пачынайце з даследаванняў, а не з прадукту.

   Тут нельга эканоміць намаганні. Вывучыце нарматыўна-прававую базу ў кожным рэгіёне, дзе плануеце працаваць у будучыні, бо правілы моцна адрозніваюцца. Напрыклад, у ЗША дзейнічае FDA і існуюць свае крытэрыі размежавання вэлнэс-прадуктаў і медыцынскіх вырабаў. У Еўропе прымяняецца рэгламент 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 — гэта значыць няправільны выбар прызначэння прадукту — самая небяспечная стратэгічная памылка. Занадта шырокае вызначэнне вядзе да павышэння класа рызыкі, дарагіх даследаванняў і доўгага шляху ўзгаднення. Занадта вузкае — не забяспечвае продажаў. Гэтая памылка каштуе даражэй за ўсё, бо ўсё астатняе будуецца вакол яе: дызайн даследавання, архітэктура, дакументацыя.

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