Сегодня у нас произошёл эпизод, который очень хорошо показывает разницу между красивой генерацией и управляемой AI-системой. MediaMashin подготовила статическую статью от первого лица. Текст выглядел правдоподобно, но начинался с истории о том, что я якобы владелец сети небольших кофеен. Никакой сети кофеен у меня в этом контексте нет — модель просто достроила удобную биографию под сюжет.
Самое неприятное здесь не то, что AI ошибся. Ошибки моделей давно не новость. Интереснее другое: текст был настолько гладким, что его легко было принять за нормальный авторский материал, если проверять только стиль, структуру и наличие ключевых слов.
Мы не стали «чуть поправлять» выдуманный кейс
Первое решение было простым: статью удалили целиком. Не потому, что нельзя было заменить «кофейни» на нейтральный бизнес. После такого сбоя я уже не хочу предполагать, какая ещё часть истории тихо придумана: разговоры, последовательность действий, результат или мотивы героя.
Одновременно мы удалили старую STATIC-карту, которая сама подталкивала генератор к искусственным OWNER/TEAM/CLIENT историям. Она создавала лишнее давление: каждой теме требовался сюжет, даже если реального опыта под него не было.
Мы разделили реальный опыт и мысленный эксперимент
При этом я не хочу превращать статьи в сухие инструкции. Личная подача работает именно потому, что читатель видит ход мысли. Решение оказалось в другой формуле.
Если событие реально произошло — пишем «мы сделали», «я увидел», «у нас сломалось» и сохраняем доказательства. Если я наткнулся на чужой вопрос — можно честно написать «увидел и задумался». Если хочется проверить гипотезу — «подумал, что будет, если…». Можно поставить ChatGPT условие и разобрать сценарий вместе. Но гипотетическая часть должна оставаться гипотетической до конца.
Это даёт почти ту же драматургию, но без подмены фактов. История строится вокруг настоящего наблюдения или настоящего вопроса, а не вокруг выдуманного прошлого автора.
Почему это важно не только для контента
В бизнес-системах та же проблема опаснее. Модель может уверенно сказать не только «вы владелец кофеен», но и «публикация размещена», «клиенту отправлено письмо», «заказ изменён». Поэтому мы применяем один принцип и к текстам, и к действиям: утверждение должно быть связано с проверяемым состоянием.
Для статьи это источник, журнал разработки или сохранённая метрика. Для внешнего действия — read-back, URL, изменённое поле или ответ API. Если доказательства нет, система не должна повышать уверенность красивой формулировкой.
После сегодняшнего случая STATIC вообще перестала генерироваться внутри MediaMashin. Темы, ключи, master и платформенные версии готовлю я как редактор. Машина получила более узкую роль: очередь, публикация, проверка и метрики. Иногда хороший AI-продукт становится лучше именно после того, как у AI забирают лишнюю свободу.
Почему обычные проверки качества здесь не спасают
До этого сбоя у нас уже были проверки структуры, объёма, ссылок, повторов и других формальных признаков. Все они отвечают на вопрос «хорошо ли написан текст». Но выдуманная биография может быть написана очень хорошо. Более того, чем лучше модель связывает детали в цельный рассказ, тем убедительнее становится ложная предпосылка.
Поэтому фактологический контроль нельзя заменять стилистическим. Если статья говорит «я сделал», система должна знать, на каком реальном событии основано это утверждение. Если описывается клиентский кейс, нужен подтверждённый кейс, а не правдоподобная конструкция. Если это мысленный эксперимент, язык должен прямо сохранять условность: «представим», «проверим сценарий», «что будет, если».
У нас появился отдельный контракт правды
После эпизода мы формализовали границу. Реальное наблюдение можно писать от первого лица только тогда, когда оно действительно относится к нашей работе и его можно восстановить по контексту проекта. Чужой вопрос или рыночный сигнал можно использовать как повод для рассуждения, не присваивая себе чужой опыт. Моделируемый сценарий остаётся моделируемым от начала до конца.
Отдельно запретили подменять доказательство красивой конкретикой. Нельзя придумывать клиента, отрасль, цитату, выручку, срок внедрения или измеренный результат ради убедительности. Такие детали работают как доказательство, поэтому требования к ним должны быть строже, а не мягче.
STATIC мы сделали намеренно скучнее для машины
Раньше статический контур мог получить тему и сам достроить историю. Теперь конечная карта тем, поисковые ключи, master-текст и нативные версии для площадок готовятся редакционно заранее. MediaMashin хранит проверенный пакет, выпускает его по графику, публикует и собирает подтверждение результата. Если пакет изменился, меняется digest и он снова должен пройти аудит.
Это важная архитектурная деталь. Мы не пытаемся заставить модель «быть честнее» одной дополнительной фразой в prompt. Мы меняем саму систему так, чтобы этап, где особенно опасна выдумка, не зависел от свободной runtime-генерации.
Тот же принцип нужен для действий AI
Контент оказался хорошим полигоном для более общего правила. AI может ошибиться не только в прошлом автора, но и в состоянии внешней системы. Если после команды он пишет «готово», этого недостаточно. Нужно прочитать результат обратно: существует ли публикация, изменилось ли поле, появился ли нужный объект, вернул ли API подтверждаемый идентификатор.
Именно поэтому в управляемом AI-контуре важны не уверенность формулировки и не «умность» модели, а цепочка доказательств. Чем существеннее действие, тем меньше должно оставаться мест, где система просто верит собственному тексту.
Что я вынес из этого сбоя
Ошибка была полезна только потому, что мы не стали её маскировать. Удаление уже подготовленных материалов стоило времени, но попытка оставить их после косметической правки сохранила бы неправильный принцип. Теперь у STATIC более узкий, проверяемый процесс, а у редактора — явная ответственность за фактическую основу.
Для бизнеса вывод тот же. При внедрении AI нужно заранее решить, какие утверждения считаются фактами, откуда они берутся и какое доказательство требуется после внешнего действия. Это скучнее демонстрации, зато именно так AI перестаёт быть генератором правдоподобия и становится частью управляемой системы.
Проверка должна блокировать пакет до публикации, а не после жалобы
Из этого случая следует ещё одно техническое правило: аудит должен быть исполняемым ограничением. Недостаточно написать в инструкции «не выдумывать факты», если система всё равно может пометить пакет как готовый и отправить его дальше. Поэтому критичные требования должны проверяться до материализации статьи и ещё раз перед внешней публикацией.
Именно такая двойная проверка сейчас нужна STATIC: редакционный digest связывает master и платформенные версии, а deterministic gate проверяет обязательные форматы и ключевые ограничения. Если пакет изменён или не соответствует контракту, он останавливается независимо от того, насколько убедительно выглядит текст.
Если вы подключаете AI к реальным бизнес-процессам, я бы начинал не с вопроса «что он умеет», а с вопроса «какие утверждения и действия мы можем доказать». Именно вокруг этого мы строим управляемый AI-контур: обсудить задачу