Как убедиться, что модель рабочая до старта

Модель работы подрядчика — это решение для AEO и GEO-продвижения, которое клиент может проверить до начала работ на согласованном наборе запросов, метрик и материалов.

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

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

Что должно входить в предложение подрядчика:

• методика отбора запросов по брендовым, категорийным и сравнительным намерениям пользователей;
• список ИИ-платформ для мониторинга;
• baseline и порядок хранения исходных ответов;
• план действий: аудит, технические задачи, контент, работа с сущностями и источниками;
• образец отчёта с первичными данными;
• границы ответственности и сроки повторной проверки.

Диагностика и сопровождение — не одно и то же. Диагностика даёт снимок проблемы, а исполнение под ключ включает устранение пробелов и повторные замеры. От модели работы зависит, кто закрывает найденные пробелы: команда клиента или подрядчик.

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

Проверка подрядчика состоит из пяти шагов.

1. Запросите у подрядчика методику, пример отчёта, обезличенный кейс и перечень работ первых 30 дней.
2. Утвердите набор промптов и таблицу оценки до публикации отчёта.
3. Проведите совместный прогон части запросов в целевых ИИ-платформах. Сохраните полные ответы с датой.
4. Зафиксируйте baseline, ответственных, сроки и формат повторного замера.
5. Проверьте, объясняет ли подрядчик расхождения между ручным результатом и отчётом инструмента.

Заказчик и подрядчик не включают название бренда в тестовый промпт. Иначе видимость растёт искусственно: ИИ повторяет название из вопроса, а не выбирает компанию сам. Эта мелочь способна испортить весь baseline.

Заказчик оценивает результат проверки по воспроизводимости, прозрачности и связи данных с действиями подрядчика. Оценка «выглядит убедительно» здесь бесполезна. Её нельзя перепроверить.

Инструмент признают работающим, когда его отчёт полностью совпадает с результатами ручной проверки по тем же промптам. Для контрольной выборки подходят 10—20 реальных промптов. Если ручная проверка полностью совпала с инструментом, его можно использовать для регулярного мониторинга. Если совпали 8 из 10 ответов, не принимайте агрегированный показатель без разбора расхождений. Подрядчик обязан показать, откуда они взялись.

Сырые ответы позволяют проверить контекст упоминания, URL и формулировку ответа ИИ, чего не показывает агрегированная панель с показателями. Они раскрывают контекст: бренд рекомендован, просто упомянут или стоит рядом с конкурентом. Видимость фиксирует присутствие. Цитирование — ссылку на конкретный URL. Похожи только на первый взгляд.

Единичный скриншот не доказывает результат. Один ответ ИИ меняется из-за сессии, режима ИИ-модели или источников, найденных в конкретный момент. Поэтому случайная удача не равна устойчивой видимости. Один скриншот может показать ответ, полученный при конкретных настройках сессии и наборе источников; без повторного прогона он не подтверждает устойчивый результат.

Другая ошибка — выдавать рост упоминаний за бизнес-результат. Упоминание влияет на узнаваемость, но не доказывает лиды или сделки. Подрядчик должен отдельно показывать:

• промпты;
• цитирования;
• трафик;
• следующие действия.

Иначе между диаграммой и подписью мелким шрифтом пропадает причинная связь.

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

White label подтверждён, когда конечный клиент видит бренд агентства или компании-заказчика во всём сценарии: в кабинете, ссылке, уведомлениях и отчётах. Логотип на одном экране ничего не подтверждает.

Партнёрская программа работает иначе. Агентство получает комиссию за приведённого клиента, а сам клиент видит платформу. Настоящий white label даёт отдельный мультибрендовый кабинет и право подключать клиента под своим именем.

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

• минимальный объём;
• окно уведомления;
• срок экспорта данных;
• условия возврата.

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

Отчёт под брендом клиента — это брендированный отчёт, в котором видны статус упоминания, цитирование, URL-источник и динамика по каждому проверяемому вопросу.

Попросите подрядчика собрать тестовый отчёт на вашем наборе запросов. Если доступ предусмотрен, откройте отчёт как клиент в PDF, по ссылке и в личном кабинете. Проверяйте прежде всего состав данных, потому что только первичные ответы, даты, URL и статусы позволяют перепроверить выводы отчёта.

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

Заказчик до подписания договора уточняет покрытие российских ИИ-сервисов, порядок работы с данными и условия договора. Подрядчик может уверенно показывать зарубежные платформы, но не мониторить Яндекс Нейро, Алису или GigaChat. От состава площадок зависит, отражает ли отчёт поведение русскоязычной аудитории.

Передача персональных данных клиентов в публичные облачные ИИ требует проверки на соответствие 152-ФЗ. Например, если менеджер вставляет в публичный чат-бот заявку с именем, телефоном и историей заказа, сначала проверьте основание передачи и условия обработки. Не отправляйте такие данные в сервис, если договор и правила доступа не определены.

В договоре разделите:

• роли сторон по обработке данных;
• SLA;
• порядок экспорта;
• уведомления об изменении продукта.

Здесь лучше быть занудным заранее, чем спорить после утечки или закрытия доступа.

Результат проверки — это материалы, по которым руководитель выбирает запуск, доработку условий или отказ. Не оставляйте решение только в переписке после демо, потому что через месяц участники могут не вспомнить, какие данные и условия показывал подрядчик.

До старта сохраните:

• утверждённый список промптов и карту оценки;
• baseline с датами, ответами и скриншотами;
• пример брендированного отчёта;
• описание white label и права на сублицензию;
• перечень работ, KPI, сроки и ответственных;
• протокол разногласий, если часть проверки не пройдена.

Цифры baseline стоит включить в приложение к договору. В приложение внесите дату замера, промпт, платформу, полный ответ и статус упоминания. Не ограничивайтесь формулировкой «видимость 20 %» без списка запросов и исходных ответов. Тогда через несколько месяцев спор идёт не об общем впечатлении, а о сравнении одинаковых условий.