Документирование приёма в фоне: ИИ-скрайб

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

Амбиентный ИИ-скрайб слушает телемедицинскую консультацию и готовит черновик протокола: структурированный документ с жалобами, анамнезом, диагнозом и рекомендациями, который иначе врач набирал бы сам, когда пациент уже отключился. Скрайб – цепочка из трёх шагов (распознавание речи, разделение говорящих, клиническое резюме), и в 2026 году это самая зрелая ИИ-функция в российской медицине: ИИ-помощник, заполняющий протокол приёма, доступен более чем 3 000 специалистов московских поликлиник, а «Яндекс Мед» пилотирует транскрибацию приёма для клиник. Но и требований комплаенса у этой функции больше всего. Аудио приёма – сведения о здоровье и врачебная тайна, поэтому поставщик модели работает по поручению оператора, данные обрабатываются только в России (зарубежные ИИ-API не подходят), обучать на них свои модели поставщику нельзя, а черновик проверяет и подписывает врач. В статье – как скрайб устроен от начала до конца, где медданные пересекают границу контура, где проходит линия медизделия и как выбрать между собственной сборкой и готовым решением.

Зачем это читать

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

Что такое амбиентный скрайб

Представьте, что загруженная клиника посадила в кабинет помощника, который тихо оформляет приём, пока врач занимается пациентом. Амбиентный ИИ-скрайб – программная версия такого помощника: он незаметно присутствует в видеозвонке, слушает весь разговор и к концу консультации выдаёт черновик протокола. «Амбиентный» (от англ. ambient – «фоновый») значит, что он работает в фоне, на материале обычного разговора: врачу не нужно диктовать или прерываться, чтобы печатать.

Протокол – вполне конкретный структурированный документ. В российской практике протокол приёма обычно делят на жалобы, анамнез, данные осмотра, диагноз и рекомендации; в международной литературе похожую структуру называют SOAP (жалобы, объективные данные, оценка, план). Задача скрайба – разложить свободный разговор по этим разделам: выделить симптомы, анамнез, препараты, план наблюдения и отбросить разговоры не по делу. Московский ИИ-помощник, например, заносит в протокол жалобы, анамнез, диагнозы и рекомендации.

Одно различие стоит зафиксировать сразу, потому что от него зависит всё регулирование. Скрайб – инструмент документирования: он записывает и упорядочивает сказанное. Решений он не принимает: не говорит врачу, что с пациентом и что назначить. Граница между документированием и решением совпадает с границей между обычным продуктом и медицинским изделием, и мы к ней ещё вернёмся. Пока достаточно простой формулы: скрайб записывает приём, а каждое клиническое решение принимает врач.

Как это работает: цепочка из трёх шагов

Технически скрайб – цепочка из трёх моделей машинного обучения. На каждом шаге аудио или текст передаётся модели, а значит, на каждом шаге перемещаются медданные.

Нажмите, чтобы увеличить

Шаг 1 – распознавание речи (из аудио в текст). Первая модель – система автоматического распознавания речи (ASR). Она получает аудио консультации и по ходу разговора выдаёт транскрипт. Распознавать речь на приёме сложнее, чем диктовку в телефоне: названия препаратов, анатомические термины, акценты, перебивания, шум на кухне, где сидит пациент. Модели общего назначения хорошо справляются с бытовой речью и ошибаются на медицинской лексике, поэтому для скрайба нужны либо модели, дообученные на медицинской речи, либо слой коррекции терминов по словарю. Для русского языка это российские сервисы распознавания (SaluteSpeech, Yandex SpeechKit, в том числе on-prem SpeechKit Hybrid) или открытые модели вроде Whisper, развёрнутые в вашем контуре. Как устроен потоковый ASR изнутри, разобрано в инженерном разделе, в статье потоковый ASR; здесь речь о клинике и комплаенсе.

Шаг 2 – разделение говорящих (кто что сказал). Сырой транскрипт – просто слова, а для протокола важно, что «кашель уже три дня» сказал пациент, а «начнём с ингалятора» – врач. Определение, кому принадлежит каждая фраза, называют диаризацией (diarization). В телемед-звонке это проще, чем в кабинете: у пациента и врача обычно отдельные аудиоканалы, и система опирается на это, чтобы надёжно размечать реплики. Ошибка на этом шаге не косметическая: если протокол приписал симптом пациента врачу или назначение врача пациенту, это уже клиническая ошибка.

Шаг 3 – клиническое резюме (сборка протокола). Третья модель – большая языковая модель (LLM – на таких моделях работают современные чат-ассистенты; в России это, например, GigaChat или Alice AI, а для закрытого контура – открытые модели на своих серверах). Она получает транскрипт с метками говорящих и собирает из него структурированный протокол: симптомы – в жалобы, план – в рекомендации, посторонние разговоры отбрасывает. Это самый мощный и самый опасный шаг: языковая модель умеет гладко написать то, чего на приёме не говорили. Этот риск разобран ниже.

Итого три шага и три модели: на входе аудио, на выходе структурированный протокол. Всё остальное – интерфейс, связь с медицинской информационной системой (МИС), экран проверки – строится вокруг этого ядра.

Почему это самая окупаемая ИИ-функция телемедицины

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

Посчитаем – это и есть бизнес-обоснование. Допустим, врач проводит 16 телемедконсультаций в день и тратит в среднем 6 минут на ручное оформление каждой:

Ручное оформление:
   16 консультаций × 6 минут  = 96 минут в день на печать протоколов

Со скрайбом (черновик пишется автоматически, врач проверяет):
   16 консультаций × 2 минуты = 32 минуты в день на проверку и подпись

Время, возвращённое врачу:
   96 − 32 = 64 минуты в день ≈ больше часа

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

Выгода не ограничивается временем врача: полный и единообразный протокол удобнее следующему врачу, который примет пациента, и нужен для расчётов по ОМС и ДМС. Но обосновывает проект прежде всего экономия времени.

Картина комплаенса: куда уходят медданные

Теперь сложная часть – из-за неё эта статья ближе к блоку о защите данных, чем к блоку об ИИ. Аудио медицинской консультации – сведения о состоянии здоровья конкретного человека, то есть специальная категория персональных данных (ст. 10 152-ФЗ), и одновременно врачебная тайна (ст. 13 323-ФЗ): ею защищён уже сам факт обращения. Дальше будем называть всё это медданными. По записи, где пациент описывает свои симптомы, его легко опознать, и чувствительнее данных не бывает, а скрайб по своей природе отправляет это аудио модели. Поэтому центральный вопрос карты ИИ здесь встаёт в полную силу: покидают ли медданные ваш защищённый контур, и если да – кто их принимает, что он подписал и где стоят его серверы?

Нажмите, чтобы увеличить

Договор: поручение, врачебная тайна и запрет обучения

Если скрайб встроен в платформу клиники, оператор персональных данных – клиника, а вы и поставщик модели обрабатываете данные по её поручению (ст. 6 ч. 3 152-ФЗ). Поручение подписывают до того, как подрядчик получит доступ к данным; в нём – перечень данных и действий, цели, конфиденциальность, требования к защите по ст. 19, обязанность сообщать оператору об инцидентах. Отдельное согласие пациента обработчику не нужно (ч. 4), но перед пациентом отвечает оператор, а обработчик отвечает перед оператором (ч. 5). К поручению добавляется обязательство не разглашать врачебную тайну – для каждого, кто может увидеть транскрипт. Цепочка поручений должна прослеживаться от клиники до последнего звена: вас, облака, поставщика распознавания, поставщика языковой модели. Как её выстроить – в статье о поручении обработки и договорах с подрядчиками.

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

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

Где стоит модель: только в России

С 1 июля 2025 года 152-ФЗ прямо запрещает хранить персональные данные граждан РФ в базах данных за рубежом (ст. 18 ч. 5), а отправка данных зарубежному провайдеру – трансграничная передача с предварительным уведомлением Роскомнадзора (ст. 12). Для аудио приёма – спецкатегории под врачебной тайной – этот путь на практике закрыт, а крупнейшие зарубежные провайдеры моделей к тому же официально недоступны российским пользователям. Поэтому скрайб в России собирают из компонентов двух типов: облачных API российских провайдеров (SaluteSpeech и GigaChat у Сбера, SpeechKit и Alice AI в Yandex AI Studio; условия обработки ПДн и договор уточняйте у провайдера) или моделей on-prem – в аттестованном российском облаке (Yandex Cloud, Cloud.ru, Selectel, MWS) либо в серверной клиники. Подробнее – в статье о локализации данных и о том, где хранятся медданные.

Минимизация, информирование пациента и хранение

На устройство скрайба влияют ещё три правила. Во-первых, принцип 152-ФЗ: объём и содержание данных соответствуют целям, лишнее не обрабатывают и не хранят дольше, чем нужно (ст. 5). Это повод решить, нужно ли хранить сырое аудио после того, как протокол подписан. Во-вторых, пациент должен понимать, как обрабатывается консультация: порядок телемедицины требует раскрывать на сайте или в приложении оператора информационной системы и место хранения материалов (приказ Минздрава 193н, п. 37). В-третьих, если аудио- или видеозапись консультации сделана, её нужно хранить: такие «сопутствующие материалы» хранятся один год (193н, п. 49–51), хотя отдельной обязанности вести запись нет. Если ваша архитектура сохраняет аудио даже временно – например, для пакетной обработки, – уточните у юриста, не становится ли этот файл записью консультации со сроком хранения. Механика согласия, записи и хранения – в статье согласие пациента, запись и хранение данных.

На сохранённые аудио и транскрипты распространяются все правила для медданных: шифрование, разграничение доступа и журнал, где видно, кто что открывал (регистрация событий безопасности входит в меры по приказу ФСТЭК № 21; для электронных медицинских документов журналирование доступа отдельно требует приказ Минздрава 209н). Подробнее – в статье о журналах аудита и контроле доступа. Самая дешёвая с точки зрения комплаенса архитектура скрайба – та, что хранит меньше всего: обработать поток, дать врачу подписать протокол и не оставлять лишних копий.

Линия медизделия: скрайб остаётся документированием, пока не начинает решать

Вторая линия, от которой зависит, можно ли запускать ИИ-функцию, – регуляторная. По 323-ФЗ медицинские изделия – это в том числе изделия, «включая специальное программное обеспечение», предназначенные производителем для профилактики, диагностики, лечения заболеваний и мониторинга состояния организма (ст. 38 ч. 1). В обращении в России могут находиться только зарегистрированные медизделия (ст. 38 ч. 4); регистрирует их Росздравнадзор по правилам ПП 1684 (с 01.03.2025), а ПО с искусственным интеллектом всегда относится к классу риска 3, самому высокому (приказ Минздрава 4н от 06.06.2012, п. 15.1.1).

Скрайб в чистом виде остаётся по безопасную сторону этой линии: он документирует сказанное врачом и ничего не решает. Так устроены и обе российские разработки, упомянутые в статье: итоговое решение остаётся за врачом.

Проблема в том, что скрайбы редко остаются в чистом виде. Как только скрайб начинает подсказывать – предлагать по разговору диагноз и код по МКБ-10, отмечать «пропущенное» обследование, рекомендовать лечение, – он превращается из инструмента документирования в систему поддержки принятия врачебных решений (СППВР). А СППВР на основе ИИ порядок телемедицины допускает, только если они зарегистрированы как медизделия (193н, п. 15–17). Этот путь проходим: на август 2026 года, по данным Росздравнадзора, зарегистрировано 59 отечественных медизделий с ИИ. Для ПО в правилах регистрации есть и послабления: разрешение на клинические испытания ПО-медизделия не требуется (ПП 1684, п. 31 «в»), а изменения в зарегистрированное ИИ-ПО вносят по отдельной процедуре (п. 112–136). Но регистрация всё равно остаётся отдельным проектом со своими сроками. Чтобы скрайб оставался безопасным, проектируйте функции-подсказки отдельными модулями с собственным регуляторным решением, а не добавляйте их в протокол «тихими» улучшениями. Подробнее – в статье о слое комплаенса и безопасности клинического ИИ.

Точность, галлюцинации и подпись врача

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

Первый – галлюцинация: модель выдумывает осмотр, которого не было, или симптом, о котором пациент не говорил, просто потому, что такое обычно встречается в похожих протоколах. В российской телемедицине у этого риска есть особенность: в консультации «врач – пациент» без очного приёма диагноз не ставят (193н, п. 40), поэтому скрайб, «по привычке» дописавший диагноз, создаёт документ, которого быть не должно. Второй – пропуск: модель упускает важное, например аллергию или изменение дозы. Третий – путаница говорящих из-за ошибки диаризации. Исследования клинических ИИ-скрайбов оценивают долю галлюцинаций в непроверенных черновиках в единицы процентов. Кажется, это немного, пока не умножишь на тысячи приёмов в день и не вспомнишь, что одна выдуманная аллергия способна навредить.

Поэтому весь дизайн строится вокруг проверки врачом. Ни один результат скрайба не становится медицинским документом, пока врач его не прочитал, не исправил и не подписал. Документирование телемедицинской консультации ведётся с усиленной квалифицированной электронной подписью (УКЭП) медработника (ч. 7 ст. 36.2 323-ФЗ), а электронные медицинские документы по приказу Минздрава 209н подписываются только УКЭП и при исправлении сохраняют все версии. Подписывая протокол, врач удостоверяет его содержание, кто бы ни набирал текст, поэтому продукт должен сделать проверку действительно возможной: быстро показать черновик, упростить правки и никогда не сохранять протокол автоматически. Московский помощник устроен именно так: в конце консультации врач проверяет готовый протокол, при необходимости правит и подписывает.

Нажмите, чтобы увеличить

В спецификацию продукта стоит внести две детали. Первая – достаточное время на проверку: если расписание оставляет врачу секунды до следующего пациента, проверка превращается в штамповку, и подпись под непрочитанным протоколом ничего не защищает. Стройте расписание и интерфейс так, чтобы на проверку было время. Вторая – строгий статус черновика: пока врач не проверил и не подписал документ, он явно помечен как черновик и исключён из медицинской документации, чтобы его нельзя было принять за готовый протокол. Как подписанный протокол попадает в МИС – в следующем разделе.

Запись в МИС: как протокол попадает в документацию

Протокол, который остаётся только в инструменте скрайба, – лишь половина функции. Польза появляется, когда подписанный документ попадает в медицинскую информационную систему клиники – основную систему, в которой работают врачи, – а оттуда в государственный контур. Этот шаг называют обратной записью (write-back).

Путей обычно два, и часто нужны оба. Первый – API конкретной МИС (Медиалог, 1С:Медицина, ЕЦП.МИС и другие): у каждой свой способ принять документ, а у государственных систем – свои регламенты подключения. Второй – стандарты обмена: подписанный протокол оформляют как структурированный электронный медицинский документ (СЭМД – XML на базе HL7 CDA R2), сведения о нём передают в РЭМД ЕГИСЗ в течение одного рабочего дня, а протокол телемедконсультации – ещё и в подсистему ФЭР. Там, где интеграция идёт через HL7 FHIR (например, через N3.Health), протокол удобно передавать ресурсом DocumentReference. Правило то же, что и при проверке: интеграция передаёт документ в статусе черновика, а окончательным его делает подпись врача, то есть действие человека, а не ИИ. Подробно – в статьях HL7 FHIR, СЭМД и реальность интеграции с МИС и интеграция с МИС: Медиалог, 1С:Медицина, ЕЦП.МИС, ЕМИАС.

Ещё один стратегический момент. В Москве ИИ-помощник работает в городском контуре (данные, по сообщению властей, передаются по защищённым каналам ЕМИАС), а «Яндекс Мед» предлагает транскрибацию приёма клиникам напрямую. Для телемед-продукта это значит, что место, где будет жить протокол, может меняться: стройте интеграцию так, чтобы протокол корректно сохранялся, где бы врач его ни заканчивал – в вашем приложении или в МИС, – и учитывайте, что владельцы МИС и крупные платформы теперь для вас одновременно конкуренты и партнёры.

Своё или покупное: варианты и путь сборки

Почти каждая команда приходит к одной развилке: взять готовое решение или собрать цепочку самим. Для большинства телемед-продуктов в 2026 году ответ такой: модели брать готовые, процесс строить самим. Тяжёлую часть машинного обучения отдайте зрелым российским моделям распознавания и языковым моделям (в облаке по поручению или on-prem), а то, что специфично для продукта, – экран проверки, запись в МИС, информирование пациента – делайте сами. Варианты сведены в таблицу; для медданных важнее всего последняя колонка.

Нажмите, чтобы увеличить

Читайте таблицу с последней колонки. Зарубежных облачных API в ней нет вовсе: для аудио приёма они не проходят ни по локализации, ни по правилам трансграничной передачи. У готового сервиса нужно выяснить, кто оператор и где обрабатываются данные; для своей сборки в облаке нужны поручения с каждым провайдером в цепочке (медданные получают и распознавание, и языковая модель). On-prem даёт больше всего контроля, и его проще всего обосновать перед службой безопасности клиники, но он требует GPU, MLOps и собственной оценки качества; выбирайте его, когда скрайб – ядро продукта, а не дополнительная функция. На российском рынке есть и специализированные решения голосового заполнения медицинских протоколов (например, Voice2Med от ЦРТ); их актуальный статус и возможности уточняйте у разработчика. Инженерная сторона собственной сборки разобрана в инженерном плейбуке ИИ-скрайба для телемедицины и в дизайне системы intake и скрайба; экономика решения – в статье своя разработка или покупка ИИ-функций.

Частая дорогая ошибка

Самая частая ошибка – не техническая. Врач или разработчик, тестируя функцию, вставляет реальный транскрипт консультации в публичный чат-бот, чтобы «причесать протокол». Одна такая вставка – это передача медданных третьему лицу без поручения и разглашение врачебной тайны; если сервис зарубежный, к этому добавляются трансграничная передача и хранение за рубежом, а на потребительских условиях данные могут ещё и попасть в обучение модели. Нарушение есть, даже если никаких последствий не наступило.

Решение скучное и без исключений: каждый инструмент, который может получить доступ к транскрипту, внесён в утверждённый список и работает в России по поручению или в вашем контуре, а публичные чат-боты на рабочих устройствах заблокированы. Сделайте правильный путь самым простым прямо в продукте, например кнопкой «собрать протокол», которая отправляет транскрипт утверждённой модели, иначе победит удобный обходной путь. Вторая по частоте ошибка – обход проверки врачом: черновик сохраняется автоматически или врач подписывает пачку протоколов, не читая. Обе ошибки – просчёты дизайна, и обе можно предотвратить в самом продукте.

Где здесь Фора Софт

Мы строим телемедицинские и видеоплатформы реального времени, к которым подключается амбиентный скрайб, и начинаем с комплаенса: сначала путь медданных, потом функции. Когда клиент хочет скрайб, мы выстраиваем путь аудио консультации так, чтобы модели работали в России – у провайдера по поручению с запретом обучения или on-prem в контуре клиники, не выводим функцию за пределы документирования, встраиваем цикл «проверь – исправь – подпиши УКЭП» в сам продукт и передаём подписанный протокол в МИС и РЭМД. Модели машинного обучения становятся всё доступнее, и главная инженерная работа – правильно расположить их относительно границы медданных, линии медизделия и подписи врача. От этого зависят и успех запуска, и спокойствие врачей, которые работают с продуктом.

Главное

• Амбиентный скрайб слушает консультацию и готовит черновик протокола; подписывает его УКЭП врач.
• Внутри – три модели: распознавание речи, разделение говорящих и клиническое резюме.
• Это самая окупаемая ИИ-функция телемедицины; в Москве такой помощник доступен более чем 3 000 специалистов.
• Аудио приёма – спецкатегория ПДн и врачебная тайна: поручение, обработка только в России, запрет обучения на данных пациентов.
• Скрайб в чистом виде – инструмент документирования; подсказки диагноза и лечения превращают его в СППВР, то есть медизделие класса 3.
• Из-за галлюцинаций и пропусков проверка врачом обязательна, и на неё нужно закладывать реальное время.

Что читать дальше

• Транскрипция и субтитры консультаций в реальном времени
• Резюме визита и памятка для пациента после приёма
• Слой комплаенса и безопасности клинического ИИ