Долю модели нужно включать в отчет для совета

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

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

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

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

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

Доля модели измеряет присутствие в ответах, а не узнаваемость

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

Простая невзвешенная формула для бренда b выглядит так:

mention_share(b) = answers_that_mention(b) / all_eligible_answers

Если в ответе названы три конкурента, каждый может получить одно упоминание. Поэтому сумма долей компаний может превышать 100 процентов. Если совет ожидает диаграмму, похожую на рыночные доли и всегда дающую 100 процентов, используйте нормализованную конкурентную долю:

normalized_share(b) = mentions_of(b) / mentions_of_all_tracked_brands

Такая нормализация отвечает на более узкий вопрос: какую часть отслеживаемого внимания конкурентов получил каждый бренд? Она скрывает ответы, где не упомянут ни один отслеживаемый бренд. Показывайте отдельно долю «ни один бренд не упомянут», иначе отчет выдаст слабое присутствие категории за хорошее.

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

Четыре различия помогают говорить точно. Присутствие означает, что бренд появился в ответе. Заметность показывает, где и насколько выразительно он представлен. Предпочтение означает, что ответ рекомендует бренд для задачи пользователя. Цитирование означает, что система приводит бренд или его материал как подтверждение. Сначала показывайте эти показатели отдельно и только потом думайте о составной оценке.

Управляемый набор вопросов - главный измерительный актив

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

Отталкивайтесь от клиента и ситуации покупки, а не от желаемого упоминания бренда. Вопрос «Какие инструменты заменят ручную сверку в конце месяца для финансовой команды из 50 человек?» полезен. Вопрос «Почему Acme - лучший инструмент для сверки?» измеряет послушность ответчика. Вопросы должны звучать так, как их сформулировал бы покупатель в отсутствие компании.

Присвойте каждому вопросу постоянный идентификатор и добавьте немного метаданных:

• Этап пути покупателя и бизнес-проблема
• Клиентский сегмент и география
• Коммерческая важность в виде явно заданного веса
• Ожидаемый тип ответа, например объяснение, сравнение или короткий список
• Дата включения и причина любого последующего изменения

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

При ежеквартальном пересмотре можно добавлять и убирать вопросы, но сохраняйте предыдущую версию и показывайте эффект замены. Один раз запустите старый и новый наборы параллельно. Такое перекрытие покажет совету, чем вызван скачок: рынком или измерительным инструментом. Незаметная замена слабых промптов равна переносу плана продаж после закрытия квартала.

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

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

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

Для сопоставимых тестов нужен письменный регламент запуска

Сравнивать ChatGPT, Perplexity и Gemini можно лишь после точного определения запуска для каждого сервиса. Записывайте поверхность продукта, видимую пользователю метку модели или режима, состояние учетной записи, режим просмотра или исследования, локаль, настройку местоположения при ее наличии, дату и признак новой беседы. Не объединяйте ответы потребительского чата, API и исследовательского режима под одним названием платформы.

Минимальный регламент прост:

1. Для каждого промпта начинайте новую беседу, чтобы предыдущие ответы не повлияли на следующий.
2. Во всех трех сервисах используйте одинаковый текст промпта, язык, сведения о покупателе и запрошенный формат ответа.
3. Сохраняйте полный ответ, видимые цитаты, время запуска и доступные проверяющему настройки.
4. Повторяйте промпт по расписанию, а не до тех пор, пока не появится привлекательный ответ.
5. Сохраняйте отказы, ошибки и пустые ответы вместо их незаметной замены.

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

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

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

Оценивайте присутствие, заметность, предпочтение и цитирование отдельно

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

Я использую простую шкалу заметности, которую может воспроизвести второй проверяющий:

0 = absent
1 = incidental mention or undifferentiated long list
2 = substantive description or direct comparison
3 = top recommendation tied to the buyer's stated need

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

Не ставьте непрозрачную взвешенную оценку во главе отчета. Формула с 40 процентами упоминаний, 30 процентами позиции, 20 процентами тональности и 10 процентами цитат выражает предпочтения руководства, а не закон природы. Она может помочь рабочей команде расставить приоритеты, но совету нужно видеть компоненты и веса. Меняйте вес только для будущих периодов, а один раз покажите прежний расчет для сохранения непрерывности.

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

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

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

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

Воспроизводимая таблица лучше непонятной панели

Первую рабочую систему можно построить в таблице, которая хранит исходные подтверждения и прозрачно считает сводные показатели. Одна строка должна соответствовать одной паре «ответ и бренд», а не одному промпту. Такая форма обрабатывает ответы с несколькими конкурентами без списка в одной ячейке.

Практичный заголовок CSV выглядит так:

run_id,run_date,platform,surface,question_id,segment,question_weight,brand,mentioned,prominence,recommended,cited,accuracy_issue,reviewer
2026Q1-0042,2026-02-12,ExampleAI,consumer_chat,Q017,midmarket,2,Acme,1,2,0,1,0,RS

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

Рассчитайте взвешенную долю упоминаний, не скрывая знаменатель:

weighted_mentions = sum(question_weight where mentioned = 1)
eligible_weight = sum(question_weight for eligible answers)
weighted_mention_rate = weighted_mentions / eligible_weight

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

Для нормализованной конкурентной доли рассчитайте взвешенные упоминания каждого отслеживаемого бренда, затем разделите значение бренда на общую сумму. Для доли предпочтения повторите расчет с recommended = 1. Нельзя сравнивать свой взвешенный показатель с невзвешенным показателем конкурента или смешивать знаменатель на уровне ответов со знаменателем на уровне упоминаний. Многие неожиданные скачки панели на деле оказываются ошибкой знаменателя, к которой придумали стратегическую историю.

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

Контроль выборки делает динамику правдоподобной

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

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

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

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

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

В AI Risk Management Framework от NIST измерение входит в более широкий цикл вместе с контекстом, управлением и действиями. Здесь это верный подход. Технически воспроизводимый подсчет все равно бесполезен для стратегии, если выборка исключает реальных покупателей или в компании никто не отвечает за неточные ответы.

Конкурентный анализ требует доказательств, а не турнирной таблицы

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

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

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

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

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

Отчет для совета должен связывать видимость с решениями

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

Таблица показателей должна содержать:

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

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

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

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

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

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

Анализ сценариев делает ограничения понятными. Покажите, как меняется главный показатель без весов вопросов, после удаления спорных оценок или исключения одной платформы. Устойчивый вывод должен пережить разумный выбор параметров. Если при одном правдоподобном знаменателе рейтинг переворачивается, назовите результат неопределенным и соберите дополнительные данные. Совет нормально воспринимает неопределенность, когда руководство описывает ее прямо. Проблемы начинаются, когда скрытые допущения всплывают после принятого обязательства.

Если руководство не может договориться о вопросах, сегментах или правилах решений, разногласие раскрывает полезную стратегическую проблему. Когда оно указывает на более широкий сбой в ответственности за ИИ или стоимости разработки, oleg.is предлагает пятидневный Team & AI Audit, посвященный экономии команды и трансформации с ИИ. Отделяйте эту операционную работу от рыночной метрики и сохраняйте за руководителем ответственность за определение и последующие действия.

Относитесь к метрике как к рабочему сигналу

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

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

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

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

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