Архитектура AI-пилота: сначала исправьте системы, потом улучшайте промпты

Почему пилот буксует еще до того, как дело доходит до промптов

Слабый промпт может навредить AI-пилоту. Но беспорядочный процесс навредит еще сильнее.

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

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

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

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

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

Как выглядят беспорядочные системы в повседневной работе

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

Один запрос может попасть в четыре места еще до обеда. Сначала его прислали по почте, потом обсудили в чате, затем добавили строку в таблицу и позже создали заметку в CRM. В каждом инструменте лежит своя версия, поэтому команда постоянно задает один и тот же вопрос: какая из них правильная?

Вот тут и становится важен дизайн пилота. Если AI читает CRM, а самая свежая деталь лежит в чате, он даст аккуратный ответ на основе старой информации. Промпт может быть нормальным. Проблема в системе.

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

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

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

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

Где автоматизация ломается из-за отсутствующих статусов

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

Проблемы начинаются, когда эти метки размыты или неполные. Если один человек ставит запросу «готово», другой — «решено», а третий оставляет его «в работе», система перестает рассказывать понятную историю. Тогда AI вынужден гадать, задача уже завершена, ждет проверки или требует последующего контакта.

Обычно такое угадывание заканчивается ошибкой.

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

Плохие метки заводят в тупик

Расплывчатые статусы обычно создают две проблемы. Либо AI отправляет неправильный результат, либо автоматизация останавливается, потому что ни одно правило не подходит к текущей записи.

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

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

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

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

Как слабая модель данных рождает плохой результат

Слабая модель данных сначала путает людей, а потом уже AI. Если команда сама не понимает, что означает запись, модель тоже не сможет последовательно это вывести.

Часто хаос сначала выглядит мелким. Один клиент значится как «Acme Ltd» в CRM, «ACME» в биллинге и «Acme Logistics» в тикетах поддержки. Сотрудник может знать, что это одна и та же компания. AI-инструмент не знает этого, если у систем нет общего понятного ID.

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

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

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

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

Обычно проблемные места просты:

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

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

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

Простой пример из пилота

Небольшая софтверная компания попробовала AI-помощника для follow-up после демо-звонков. Задача казалась простой. По одной записи клиента приходили заметки со звонка, вопрос по цене и просьба перенести следующую встречу.

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

Потом все застопорилось.

У записи клиента не было четкого статуса. Этот клиент все еще новый лид, уже в тестовом периоде или уже платит по ручному счету? В CRM стояло «демо проведено». В общей таблице — «триал отправлен». В старой переписке в почте их уже называли клиентом. AI мог написать письмо, но не мог выбрать следующий шаг, потому что система не говорила, на какой стадии клиент на самом деле находится.

Вторая проблема появилась быстро. У записи не был назначен владелец. Продажи думали, что ответить по части настройки должна поддержка. Поддержка думала, что с ценой должны разобраться продажи. У AI не было правила, кто одобряет или отправляет финальное сообщение, поэтому черновик просто лежал без движения, пока кто-то его не заметил.

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

Три небольших пробела остановили весь процесс:

• статус клиента был неясен
• у следующего шага не было владельца
• одна и та же учетная запись существовала в нескольких местах

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

Сначала исправьте основу

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

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

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

После этого определите статусы. Пусть их будет немного, и пусть они будут строгими: новый, на проверке, одобрено, заблокировано, готово. У каждого статуса должно быть четкое значение, и у каждого перехода должно быть правило. Если задача может прыгнуть из «новой» сразу в «готово» или неделями висеть в «в работе», AI не сможет действовать уверенно, потому что у самой системы нет понятной логики.

Дальше очистите поля, которые управляют процессом. Уберите дублирующиеся колонки. Разделите смешанные поля вроде «статус/заметки» на отдельные части. Приведите к единому виду даты, ID, владельцев и приоритеты. Если модель данных для автоматизации грязная, AI начнет гадать, а догадки быстро становятся дорогими.

И только потом тестируйте AI. Дайте ему одну узкую задачу, например классифицировать входящие запросы, написать первый ответ, кратко передать задачу или отметить недостающую информацию. Измеряйте один важный результат, например сокращение времени на сортировку с 12 минут до 4 или снижение числа переделок из-за плохих передач.

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

Ошибки, которые команды допускают в начале

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

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

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

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

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

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

Быстрая проверка перед расширением пилота

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

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

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

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

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

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

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

Именно такую проверку часто проводит внешний технический советник, прежде чем команда добавит больше агентов или инструментов. Олег Сотников из oleg.is работает с основателями и небольшими командами над AI-first операциями и услугами Fractional CTO, и такая ранняя очистка процессов обычно и становится источником настоящего роста.

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

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

Выберите один процесс, который случается часто и создает команде реальную работу. Лучший первый кандидат — это то, что повторяется регулярно, имеет одного понятного владельца и дает измеримый результат. Если задача появляется два раза в месяц, пока оставьте ее в покое. Если она ложится на чей-то стол 30 раз в неделю, начните с нее.

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

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

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

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

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