ИИ в прямом эфире – инженерный плейбук

Автор: Николай СапуновОбновлено: август 202629 мин чтения
Содержание статьи +

Кратко (TL;DR)

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

Под каждой функцией лежит второе решение – где физически работает ИИ: внутри здания или в ПТС (передвижной телестанции) на несжатой сети SMPTE ST 2110, в облаке как часть удалённого производства (REMI) или на двух уровнях одновременно. От этого выбора зависят задержки, стоимость трафика и сценарии отказоустойчивости.

Этот плейбук даёт продукту и инженеру единую карту: каталог функций, бюджет задержки, который ограничивает всё остальное, три возможных места размещения ИИ, юридическую границу между показом реального изображения и синтетическим контентом согласно статье 50 EU AI Act, правила доступности и громкости, действующие независимо от ИИ, а также маршруты «купить или построить» для каждой группы.

Почему это важно

Прямой эфир – это место, где у ИИ меньше всего права на ошибку, но и наибольшая выгода. Аудитория одного финала или блока экстренных новостей легко перекрывает месячный охват по поисковым запросам: контент скоропортящийся – пропущенный гол не переснимешь, – а весь конвейер работает против времени, измеряемого миллисекундами на кадр. При этом экономика жёсткая: классическое выездное производство требует ПТС, бригады и операторов, и именно поэтому, по оценкам, 99% спортивных событий в мире никогда не транслировались вообще. ИИ меняет этот расчёт с обеих сторон – он превращает школьный матч с одной камерой в нечто похожее на полноценную трансляцию и позволяет крупному вещателю мгновенно получать хайлайты, субтитры на сорока языках и переведённый комментарий, которые ни одна бригада не способна выдать в реальном времени. Этот плейбук написан так, чтобы продакт мог спланировать функцию и оценить её риски без диплома по телевизионной инженерии, а инженер – увидеть, где именно каждая модель подключается к живому сигналу, сколько задержки она может добавить и где может сломаться. Более глубокие уроки этого раздела – инструкции по ключевым компонентам: streaming ASR, перевод в реальном времени, генеративное видео, модерация; а это – вертикальная карта, которая подсказывает, какой компонент открыть и что позволят живые часы.

Что на самом деле значит «ИИ в прямом эфире»

Если убрать выставочный блеск, ИИ в прямом эфире – это программное обеспечение, которое анализирует живой сигнал, обрабатывает его или дополняет и выдаёт результат достаточно быстро, чтобы тот успел попасть в эфир. Каталог обширный, но его можно разделить на три группы – и это важно, потому что живые часы, оборудование и законодательство относятся к ним по-разному.

Полезно ознакомиться со всем каталогом до того, как обсуждать отдельную функцию.

Рисунок 1. Каталог ИИ-функций в прямом эфире, сгруппированный по работе, которую выполняет ИИ. Каждая группа отвечает перед своим хозяином: часами, законом о доступности и законом о раскрытии синтетического контента.

Первая группа – снимать и режиссировать эфир. Камера или банк камер запускает детекцию объектов и трекинг – технологию, которая находит мяч, игрока или ведущего в кадре и следует за ними, – и на её основе создаются авто-трекинговые PTZ-камеры (от pan-tilt-zoom – поворот-наклон-зум), которые кадрируют действие без оператора. К ним относятся автоматическое переключение между камерами, как это сделал бы режиссёр, графика в реальном времени и AR-виртуальные студии, которые накладывают табло и 3D-объекты на живую картинку, а также автоматический мгновенный повтор. Это группа, которая гонится за временем сильнее всех, потому что всё, что она делает, должно уместиться в тот промежуток, за который один кадр проходит через конвейер.

Вторая группа – сделать эфир понятным и охватить всех, кому он нужен. Здесь ИИ не смотрит, а слушает: автоматическое распознавание речи (ASR) превращает комментарии в живые субтитры, машинный перевод – в текст на других языках, а синтез речи – обратно в озвучку. Всё это работает в реальном времени. Аудиоописание – голосовое описание происходящего на экране для незрячих – развивается в том же направлении. Эта группа может казаться опциональной, но на деле часто таковой не является: во многих странах субтитрирование прямого эфира – это не любезность, а требование закона.

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

Единственное ограничение, которое правит всем: живые часы

Прежде чем переходить к топологии и закону, стоит чётко объяснить, почему живой ИИ сложнее, чем тот же ИИ, работающий с записанным файлом: причина – в одном ключевом свойстве, вокруг которого построена вся отрасль. Прямой эфир не может ждать. Конвейер видео по запросу может использовать модель, которая тратит три секунды на кадр, и просто воспроизводить её медленнее реального времени – никто не заметит. У прямого эфира такой возможности нет. Шоу идёт сейчас, кадр уходит сейчас, и что бы ни собирался добавить ИИ, он должен сделать это до того, как кадр уйдёт.

У часов две стрелки, и инженеры следят за обеими. Первая – задержка glass-to-glass – это суммарная задержка от момента, когда свет попадает на объектив («стекло»), до появления изображения на экране зрителя («стекло»). Вторая – бюджет на кадр – это время, которое у вас есть на обработку одного кадра до прихода следующего.

Поставим цифры на бюджет кадра, потому что он беспощаден. Вещательное видео идёт с фиксированной частотой кадров – обычно 50 или 59,94 кадра в секунду. При 50 кадрах в секунду время между двумя кадрами:

1 секунда ÷ 50 кадров = 0,02 секунды = 20 миллисекунд на кадр

То есть у ИИ-функции, которая должна обрабатывать каждый кадр в такт с изображением – например, авто-трекинговый кроп или графика в реальном времени, привязанная к движущемуся игроку, – есть всего около 20 миллисекунд, чтобы проанализировать кадр и выдать результат. При частоте 59,94 кадра в секунду этот интервал сокращается до примерно 16,7 миллисекунды. Это меньше, чем время одного кругового рейса до типичного облачного региона. Именно поэтому наиболее требовательные real-time-решения на основе ИИ в эфире работают на графическом процессоре (GPU), расположенном рядом с видеоисточником, а не в удалённом дата-центре. И именно поэтому специализированные решения вроде NVIDIA Holoscan Sensor Bridge заявляют задержку glass-to-glass всего 17 миллисекунд – они передают данные с сенсора напрямую в память GPU, минуя дополнительные этапы.

Но не каждая функция обязана находиться в одном кадре, и именно это различие – самый полезный инструмент планирования во всей статье. Функции распределяются по лестнице задержек.

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

На верхней ступени – real-time в кадре (≈ 20 мс или меньше) – находится всё, что должно быть визуально привязано к движущейся картинке: авто-трекинговые кропы, AR-графика, прикреплённая к игроку, ИИ-кеинг, заменяющий зелёный фон кадр за кадром. Это должно работать на железе рядом с сигналом.

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

На третьей ступени – вещание и low-latency-стриминг (задержка около 2–6 секунд) – сосредоточены задачи кодирования и доставки: живые энкодеры, Low-Latency HLS и Low-Latency DASH (форматы, сокращающие разрыв с классическим телевидением почти до нуля – задержка составляет всего около пяти секунд по сравнению с эфиром), а также вставка рекламы по меткам SCTE-35.

Нижняя ступень – та, с которой все стремятся слезть: legacy-стриминг (OTT), где наивная сегментная доставка оставляла зрителей онлайн на 30–45 секунд позади прямого эфира – достаточно, чтобы услышать радость соседей после гола, ещё не увидев его. Поставить ИИ-функцию на неправильную ступень – самая частая ошибка при планировании в этой области: модель, которой нужно 200 миллисекунд, не справится с отрисовкой графики в реальном времени, но отлично подойдёт для генерации хайлайтов. Полный разбор бюджета задержки под этой лестницей – в уроке про бюджет задержки sub-100ms; компромиссы при развёртывании – в уроке про задержку и топологию развёртывания.

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

Где ИИ работает на самом деле

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

Первое место – локально или в ПТС – ИИ работает на оборудовании внутри объекта или в передвижной телестанции, припаркованной у стадиона, в той же сети, что и камеры. Современные вещательные объекты всё чаще передают этот сигнал не по классическому кабелю SDI, а по SMPTE ST 2110 – набору стандартов, которые отправляют несжатые видео, аудио и метаданные отдельными, но синхронизированными потоками по управляемой IP-сети с общими точными часами. Запуск ИИ здесь обеспечивает минимальную задержку – модель находится в микросекундах от несжатого сигнала – и максимальный контроль, поэтому in-frame-функции (авто-трекинг, AR, кеинг) почти всегда реализуются локально. Цена – капитальные затраты: настоящие GPU, настоящая инженерия и IP-инфраструктура, которую нужно построить и поддерживать.

Второе место – облако, в том, что вещатели называют удалённым производством или REMI (от remote integration). Вместо отправки полной бригады и ПТС площадка передаёт сжатые видеосигналы с камер через публичный интернет в облако или центральный центр обработки, где выполняются переключение, наложение графики, работа с ИИ и финальная упаковка – после чего готовая программа возвращается обратно. Сигналы передаются по протоколам, специально разработанным для таких задач – SRT и RIST, которые обеспечивают восстановление ошибок поверх обычного интернета, позволяя контрибуционному сигналу надёжно проходить через публичную сеть. Привлекательность решения – в операционной и экономической эффективности: не нужны ПТС, ёмкость масштабируется «ползунком», а облачные GPU доступны по требованию. Однако цена – это задержка и зависимость от канала: каждый переход до облака и обратно добавляет латентность, а нестабильный аплинк на площадке становится единственной точкой отказа.

Третий паттерн – гибрид, и к 2026 году он станет стандартом по умолчанию. Работа, требующая низкой задержки и не терпящая ожидания, выполняется на edge – в ПТС или локально; более ресурсоёмкие или гибкие задачи – например, мгновенные хайлайты, перевод или аналитика архивного уровня – обрабатываются в облаке. При этом локальная и облачная части взаимодействуют через стандартизированный транспорт. Опросы отрасли это подтверждают: большинство вещателей используют гибридную инфраструктуру, сочетающую SDI, IP и облако, а не строят всю станцию на одном технологическом решении. Программно-определяемые платформы вещания, такие как NVIDIA Holoscan for Media, созданы именно для оркестрации мультивендорного ИИ-инференса на несжатых живых сигналах с минимальной задержкой, стирая границу между «локально» и «облако» и превращая их в единую программируемую систему.

Рисунок 3. Три места, где может работать ИИ. Локально и ПТС выигрывают по задержке и контролю; облачный REMI – по стоимости и эластичности; большинство реальных производств их комбинируют.

Клей интероперабельности здесь так же важен, как ONVIF в видеонаблюдении. На ST 2110 производством управляет NMOS – набор открытых спецификаций от Advanced Media Workflow Association, предназначенных для обнаружения устройств, их регистрации и соединения потоков, – так что ИИ-процессор от одного вендора может найти и подключиться к нужному сигналу в мультивендорной сети без кастомной обвязки. Когда функции нужно вынести за пределы здания, NDI (легко сжимаемый IP-видеоформат, примерно 100 мегабит в секунду на поток) доставляет их по объекту или кампусу, а SRT или RIST – через открытый интернет. Выбор транспортного протокола – часть решения о том, где будет работать ИИ.

Реальность трафика, которая формирует выбор

Решение «где работает ИИ» – не эстетическое, а отчасти арифметическое, и именно эта арифметика делает несжатый локальный ИИ дорогим, а облачный REMI – привлекательным. Несжатый сигнал 1080p по стандарту SMPTE ST 2110 составляет примерно 3 гигабита в секунду на одну камеру. Поэтому скромное живое производство с восемью камерами требует порядка:

8 камер × ~3 Гбит/с = ~24 Гбит/с несжатого видео в производственной сети

Вот почему станции на ST 2110 строятся на 25- и 100-гигабитных коммутаторах – и почему запуск ИИ на этих сигналах требует железа, способного их принять. Отправьте те же восемь несжатых сигналов в облако – и вам понадобится аплинк в 24 гигабита с площадки, которого фактически нет ни у одной площадки. Поэтому REMI сначала сжимает: контрибуционный SRT-сигнал камеры 1080p занимает уже около 10–50 мегабит в секунду, превращая те 24 Гбит/с в несколько сотен мегабит, которые публичный интернет реально способен передать:

8 камер × ~25 Мбит/с SRT-контрибуции ≈ 200 Мбит/с аплинка — реально по интернету

Компромисс отражён в этих двух числах. Локально сигналы остаются несжатыми и чистыми для ИИ, но требуют мощной локальной сети и локальных GPU. Облачный REMI легко помещается в обычный интернет-канал, но платит артефактами сжатия, задержкой кодирования и декодирования, а также зависимостью от стабильности канала. Бесплатного обеда не бывает: есть бюджет, и лестница задержек показывает, на какой его стороне оказывается каждая функция.

Граница, которая решает всё: реальная картинка против синтетического контента

В разделе про задержку ограничивающим фактором было время; в разделе про топологию – трафик; в законе ключевым вопросом становится показывает ли ИИ зрителю то, что произошло, или то, что он сгенерировал, и следующее правило теперь сформулировано явно. Использование ИИ для поиска, субтитрирования, перевода или перекадрирования реальной картинки – это обычное производство. А использование ИИ для генерации или изменения того, что видит и слышит зритель – синтетический ведущий, клонированный голос, изменённый кадр – относится к другой категории, регулируемой в рамках EU AI Act обязанностью прозрачности. Поскольку EU AI Act (Регламент (ЕС) 2024/1689) применяется ко всем системам, чей вывод используется в ЕС, он задаёт правила почти для любого вещателя, имеющего аудиторию в Европе.

Релевантное правило – статья 50, положения которой о прозрачности вступают в силу 2 августа 2026 года и предусматривают классификацию контента прямого эфира по трём категориям.

Рисунок 4. Граница прозрачности для живого ИИ. Вспомогательный ИИ поверх реальной картинки находится в лёгкой верхней полосе; синтетический или изменённый контент, показанный зрителю, требует раскрытия по статье 50; ИИ-написанный новостной текст подпадает под оговорку только в случае, если за него несёт ответственность человек.

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

Средний уровень – синтетический или изменённый контент, показанный зрителю. Как только в эфире появляется голос комментатора, клонированный с помощью ИИ, синтетический ведущий, аватар на основе искусственного интеллекта или изображение, цифрово изменённое так, что оно не соответствует реальности, применяется статья 50(4): деплойер обязан раскрыть, что контент сгенерирован или изменён искусственно, ясно и различимо – не позднее первого момента, когда зритель его видит. Регуляторы прямо указали, что в случае эфира это означает постоянное раскрытие – ведь зритель может подключиться в любой момент, – а не одноразовую плашку на секунду в начале часа. Контент, который очевидно является художественным, творческим или сатирическим, освобождается от полной обязанности раскрытия (достаточно указать наличие синтетического контента, не нарушая целостность произведения), но полностью свободных от раскрытия случаев вещания не существует.

Нижний уровень – ИИ-сгенерированный текст, который информирует общество. В статье 50(4) для него предусмотрено отдельное положение: ИИ-сгенерированный или ИИ-изменённый текст, «опубликованный с целью информирования общества по вопросам общественного интереса» – например, ИИ-написанный новостной выпуск, бегущая строка или сводка – должен быть раскрыт, если только контент не прошёл человеческую проверку и за него не несёт редакционной ответственности человек или организация. Это оговорка для редакций, и это самое важное положение статьи для любого вещателя, автоматизирующего выпуск новостей: если человек-редактор несёт ответственность за ИИ-черновик эфирного текста – обязанность раскрытия снимается; если же выпускаются непроверенные машинно-написанные новости – она остаётся. Более широкая инженерия раскрытия и происхождения, включая стандарт C2PA (content credentials) для подтверждения источника медиафрагмента, рассмотрена в уроке про качество, C2PA и раскрытие EU AI Act; генеративные модели, создающие этот синтетический контент, разобраны в уроке про ландшафт генеративного видео и уроке про ИИ-аватары и lip-sync.

Та же логика работает и за пределами Европы, даже при иных правовых рамках: если зрителям показывают синтетического ведущего, не предупредив об этом, их вводят в заблуждение – а это влечёт последствия, репутационные и всё чаще юридические, – чего не происходит при субтитровании реального эфира. EU AI Act просто делает эту границу чёткой и обязательной. Полная регуляторная картина – в уроке про регуляторный инжиниринг EU AI Act.

Корзина доступности: где ИИ отрабатывает своё, а правила кусаются

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

Аргумент в пользу AT здесь сильный и актуальный. Реальное субтитрирование сегодня достигает точности 98–99,5% на чистом эфирном звуке – достаточно высокого уровня, чтобы вещатели и платформы внедряли его для прямых трансляций спортивных событий, – а платформы генерируют синхронные субтитры на 40+ языках в режиме реального времени. Перевод и дубляж в реальном времени также преодолели этот порог: системы, разработанные для эфира, теперь обеспечивают многоязычный живой дубляж с задержкой менее секунды – настолько точно, что европейский футбольный матч 2026 года стал первым, в котором использовался живой ИИ-дубляж комментатора. Экономический эффект очевиден. Человек-оператор реального времени (стенографист, выполняющий CART – communication access real-time translation) – это редкий, дорогой и дефицитный специалист. Возьмём, к примеру, канал с 18 часами эфира в сутки:

18 часов/день × 365 дней = 6 570 часов живого эфира в год
Человек-субтитровщик ~$150/час:  6 570 × $150  ≈ $985 000/год
AI-субтитрирование по низкой ставке: иллюстративно 1–2% от этого

Числа носят иллюстративный характер и зависят от вендора и языка, но именно форма объясняет, почему субтитрирование с помощью ИИ распространилось так быстро: оно делает субтитрирование каждого часа каждого канала доступным там, где человеческое субтитрирование требовало выбора, какой эфир покрыть.

Чего ИИ не делает – так это не отменяет правил. В США Федеральная комиссия по связи (FCC) требует закрытых субтитров для телевещания в соответствии с 47 CFR § 79.1, устанавливая стандарты качества по точности, синхронности, полноте и размещению на экране. При этом чётко признаётся: живой и почти живой эфир сложнее записанного – это не освобождение от требований, а более низкая планка. Срок соблюдения требований – 2026 год – дополнительно обязывает делать настройки отображения субтитров легко доступными для зрителя.

Таким образом, инженерная цель – не «достаточно хорошо, чтобы выглядеть умно на демонстрации», а «достаточно хорошо, чтобы соответствовать стандартам регулятора в реальном времени на живом эфире каждый час». Именно эта планка объясняет, почему человеческий контроль и специализированные словари вещателя (имена команд, игроков, локальная терминология) по-прежнему остаются необходимыми, даже если точность ИИ достигает 99%.

Инструкции по компонентам: урок про streaming ASR, урок про живые субтитры с fan-out, урок про перевод речи в реальном времени и урок про ИИ-дубляж и конвейеры субтитров.

«Частая ошибка: поставить облачную модель на in-frame-работу. Команда демонстрирует красивую ИИ-графику или автоматический кроп на записанном клипе в облаке – выглядит отлично, и планирует использовать это для управления живой картинкой в эфире. Но в прямом эфире всё рушится: круговой путь до облака и обратно занимает десятки или даже сотни миллисекунд, а при частоте 50 кадров в секунду у каждого кадра всего 20 миллисекунд. Графика приходит с опозданием на один, два, три кадра – и заметно отстаёт от действия. Та же модель отлично работает на более низком уровне, например, генерируя хайлайт или нижнюю панель, которым не нужно синхронизироваться с движением.»

Решение – заранее оценить задержку каждой функции до выбора места её размещения: in-frame-обработка должна выполняться на GPU рядом с видеосигналом в ПТС или локально; только почти real-time и более медленные задачи могут отправляться в облако. Проектировать архитектуру вокруг демо, а не вокруг временных ограничений, – самая дорогая ошибка в живом ИИ.

Корзина пересборки: мгновенная ценность с человеком на спуске

Третья группа – мгновенные хайлайты, модерация, комплаенс и синтез – это зона, где живой AT мгновенно превращает эфир в множество продуктов, а принцип «второго дубля нет» требует максимальной дисциплины.

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

Модерация и комплаенс – это оборонительная часть системы. Каждый активный канал уже отстаёт от реальности на несколько секунд – эфирная задержка, изначально введённая, чтобы человек успел «запикать» мат. Теперь искусственный интеллект работает в той же задержке, чтобы быстрее и стабильнее, чем оператор за стеной мониторов, выявлять нецензурную лексику, откровенные сцены, нарушения бренд-безопасности и запрещённый контент, а также автоматически фиксировать каждый выпуск для комплаенс-отчётности, которую требуют регуляторы. Технические аспекты real-time-модерации описаны в уроке про модерацию контента. Управление громкостью – тоже часть комплаенс-контроля: в США CALM Act обязывает рекламу соответствовать средней громкости основного эфира, и автоматическая регулировка громкости эту задачу решает.

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

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

Три способа добавить ИИ в прямой эфир

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

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

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

Третий маршрут – и единственный, дающий полный контроль над задержкой и данными, – строить на открытых моделях на edge: запускать открытые детекторы, трекеры и речевые модели на собственных GPU рядом с сигналом в ПТС или локально. Он требует наибольших инженерных усилий – обычно месяцы разработки, – но позволяет разместить in-frame-функции в рамках вашего 20-миллисекундного бюджета, хранить сигналы и любой чувствительный контент на собственном оборудовании и избавиться от поштучной оплаты вендоров. Этот путь подходит вещателю, для которого задержка, независимость или безопасность контента имеют первостепенное значение. Адаптация моделей под real-time-ограничения на локальном железе – отдельное ремесло, подробно рассмотренное в уроке про дистилляцию и квантизацию для edge.

КритерийВстроить вендораСобрать CV + речь стекСтроить на открытых моделях на edge
Время до запускаДни-неделиНедели-месяцыМесяцы
Контроль задержкиБюджет вендораВаш, в рамках инфрыПолный – in-frame на вашем GPU
Кто владеет моделямиВендорТюните чужие моделиВы, от и до
Куда уходит сигналЧасто облако вендораВаш выборОстаётся на вашем железе
Комплаенс-позицияУнаследована, проверьтеВаш дизайнВаш дизайн
Когда лучшеНужна полировка быстроНужен контроль потокаЗадержка или данные – это суть

Таблица 1. Три маршрута к ИИ в прямом эфире – и чем каждый из них жертвует. Большинство вещателей внедряют слои доступности и хайлайтов, собирают производственную логику и реализуют только те in-frame-функции, которые не могут быть вынесены за пределы железа.

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

Гейт, через который проходит каждое развёртывание: доступность, громкость, раскрытие

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

Доступность – в приоритете, потому что она обязательна независимо от использования ИИ. Если вы вещаете на регулируемом рынке, скорее всего, вам необходимо обеспечивать субтитры в прямом эфире в соответствии с установленными стандартами – например, в США это требования FCC 47 CFR § 79.1. Кроме того, может потребоваться аудиоописание и доступное управление субтитрами. Искусственный интеллект – это инструмент, позволяющий выполнить эти обязательства эффективно и в больших масштабах, но не повод их игнорировать или ослаблять. Организуйте человеческий контроль и создайте специализированные словари для каждого вещателя вокруг модели субтитрирования, чтобы она соответствовала требованиям регулятора по точности при обработке живого звука – и каждый час.

Громкость и вещательный комплаенс идут вторыми. CALM Act и его международные аналоги требуют стабильной громкости, особенно на стыке программы и рекламы; автоматическое управление громкостью – это основа. Тот же уровень комплаенса ведёт логирование выпуска – что вышло в эфир, с какими субтитрами, с какими флагами модерации, – потому что запрос «покажите мне запись» давно стал рутинным для регуляторов и правообладателей.

Раскрытие синтетического контента идёт третьим, и оно новое. С 2 августа 2026 года статья 50 EU AI Act обязывает ИИ-системы, генерирующие синтетические аудио, изображения или видео, маркировать свой вывод как машиночитаемо ИИ-генерируемый, а операторам – раскрывать дипфейки и изменённый контент зрителю чётко и непрерывно. ИИ-генерируемый эфирный текст, предназначенный для информирования общества, должен быть раскрыт, если за него не несёт редакционной ответственности человек. Внедряйте раскрытие с самого начала – постоянный экранный маркер для синтетических сегментов, машиночитаемую информацию о происхождении через C2PA и редакционный процесс, фиксирующий человеческое одобрение, – а не добавляйте его позже, когда потребует регулятор.

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

Плейбук: от «запустить ИИ в эфир» до полноценной функции

Соберите всё вместе – и добавление ИИ в прямой эфир сводится к четырём вопросам, заданным по порядку.

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

Во-первых, поставьте функцию на лестницу задержки: ей нужно привязываться к картинке (in-frame, ≈ 20 мс), она может ехать в естественной задержке производства (почти real-time, секунды) или это работа по кодированию и доставке (несколько секунд)? Эта ступень – самый важный факт о функции. Во-вторых, разместите ИИ там, где ступень позволяет: in-frame-работа на GPU рядом с сигналом в ПТС или локально по SMPTE ST 2110; эластичная или тяжёлая работа в облаке через REMI по SRT или RIST; гибрид как дефолт, и ждите, что будете смешивать. В-третьих, проектируйте под «второго дубля нет»: пусть функция откатывается к безопасному дефолту, когда уверенность падает, и держите человека-режиссёра или редактора на всём, что доходит до эфира, – никогда не давайте ИИ-флагу в одиночку запускать необратимое эфирное действие. В-четвёртых, и без исключений, комплаенс-гейт: соблюдите правила качества субтитров на живом звуке, управляйте громкостью и логируйте выпуск, а для любого ИИ-сгенерированного или изменённого контента заложите раскрытие по статье 50 и происхождение C2PA – сохраняя оговорку для новостного текста только там, где редакционную ответственность несёт человек.

Это весь плейбук. Более глубокие уроки раздела – инструкции для каждой команды: streaming ASR и перевод в реальном времени для группы доступности, трекинг множества объектов для группы авто-производства, модерация контента для группы комплаенса, ландшафт генеративного видео и ИИ-аватары для группы синтеза, к которой нужно подходить с наибольшей дисциплиной раскрытия, и плейбук по OTT-платформам для доставки стриминга, которая всё это обеспечивает.

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

Мы разрабатываем стриминговые, WebRTC- и OTT-платформы, через которые транслируется прямой эфир, поэтому регулярно применяем этот плейбук с клиентами. Когда клиенту важно быстро выйти на рынок, мы интегрируем специализированные ИИ-движки – для субтитров, перевода, хайлайтов и графики – в стриминговый воркфлоу и сразу внедряем решения по доступности, громкости и раскрытию. Если ключевыми становятся задержка или контроль над контентом, мы строим собственные конвейеры: запускаем детекцию, трекинг и речевые модели как можно ближе к сигналу, чтобы in-frame-обработка оставалась в рамках бюджета кадра, и проектируем аккуратную деградацию и паттерн «человек в контроле» с самого первого спринта. Когда клиент затрагивает тему синтетического ведущего или ИИ-клона голоса, мы рассматриваем это как продукт, связанный с раскрытием, с встроенной прозрачностью по статье 50 и стандарту C2PA. Эти четыре вопроса плейбука – те же, что мы обсуждаем на скоупинг-звонках, когда вещательный клиент спрашивает, где место ИИ в его живом эфире.

Ключевые выводы

  • ИИ в прямом эфире используется для создания эфира, расширения охвата и его переработки.
  • Живые часы управляют всем: у in-frame-функций задержка около 20 мс при 50 fps, и второго дубля нет.
  • Уровень функции на лестнице задержки определяет, где ИИ может физически работать.
  • In-frame-ИИ запускайте на GPU рядом с сигналом; в облако отправляйте только почти real-time-задачи.
  • ИИ-субтитры обеспечивают точность около 98–99,5%, но всё равно должны соответствовать планке качества регулятора.
  • Синтетических ведущих, клонирование голосов и изменённую картинку необходимо раскрывать в соответствии со статьёй 50 EU AI Act с августа 2026 года.

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

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.