Бизнес‑правила перед ИИ: что сначала вынести в код

Почему правила не работают, если они живут в подсказках

Подсказка может звучать ясно и при этом давать разные ответы. Попросите ассистента ИИ: "Утвердить скидку, если сделка выглядит разумной и укладывается в политику", — и вы, вероятно, получите непоследовательные результаты. Один ответ даёт согласие на 12%. Другой просит ревью менеджера. Третий отклоняет запрос, потому что маржа кажется слишком низкой.

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

Люди тоже по-разному читают расплывчатые правила. Один менеджер понимает "разумно" как до 10%. Другой допускает 15% для долгосрочного клиента. Юридический отдел заботится о лимитах, о которых отдел продаж ничего не говорит. Все предполагают, что у ИИ есть одна книга правил, но на практике руководство разбросано по памяти, чатам и старым документам.

Подсказки также устаревают. Кто-то обновил политику на встрече, кто-то добавил исключение по почте, и никто не переписал подсказку так же. Вскоре ИИ следует неясной смеси старых правил и новых привычек. У кода свои недостатки, но по крайней мере он даёт команде одно место для проверки.

Когда люди не могут предсказать результат, доверие быстро падает. Менеджеры по продажам продолжают переформулировать подсказки, пока не получат нужный ответ. Саппорт отправляет рутинные случаи человеку, потому что ИИ кажется случайным. Финансы и юристы не могут объяснить, почему один случай прошёл, а другой — нет. Обычно клиенты первыми замечают эту неконсистентность.

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

Что стоит помещать в код первым делом

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

Обычно это включает прайс-листы, пределы скидок, обработку налогов, сроки возврата, контрактные лимиты, проверки по регионам и любые правила, связанные с деньгами, географией, риском или соответствием. Это — практическая суть понятия "бизнес-правила перед ИИ".

Ценообразование обычно первое место, где команды обжигаются. Модель может описать предложение, но не должна решать, получит ли клиент 5% или 25% скидки. Храните правила ценообразования в коде: таблицы цен, диапазоны скидок, логика наборов и пути исключений. Тогда ИИ сможет объяснить расчёт простыми словами, не меняя саму математику.

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

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

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

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

Правила, которым нужны жёсткие лимиты

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

Ценообразование — почти наверху списка. Ассистент продаж может составить черновой расчёт, но он не должен придумывать скидку или искажать формулу. Система должна рассчитывать прайс-лист, применять допустимые диапазоны скидок и отклонять всё вне политики. Если представитель может дать 5% без одобрения и 10% с разрешением менеджера, софт должен это точно знать.

Пороги утверждения требуют той же точности. Часто пишут подсказки вроде "попросить утверждение, когда сумма высокая", что звучит нормально, пока никто не договорится, что значит "высокая". Жёсткие лимиты решают эту проблему. Руководитель может утверждать до $2,000, глава отдела до $10,000, а всё выше — передаётся в финансы. ИИ может направить запрос или объяснить результат, но само правило должно быть фиксированным.

Юридическое ревью тоже нуждается в чётких триггерах. Пункты про автопродление, лимиты ответственности, сроки платежа, правила обработки данных и нестандартные пункты об оговорках должны отправлять документ в юридическую очередь. ИИ может пометить условие, суммировать риск и составить черновик ответа. Он не должен решать, что риск "наверное, приемлем".

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

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

Как отличить правило от суждения

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

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

При обзоре рабочего процесса задайте простые вопросы:

• Должен ли одинаковый вход всегда давать одинаковый ответ?
• Стоит ли ошибка денег, нарушит ли контракт или пересечёт юридический лимит?
• Нужен ли аудиторский след, который показывает, почему система разрешила или заблокировала действие?
• Зависит ли задача больше от тона, формулировки или контекста, чем от простого теста "пройдёт/нет"?

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

А теперь посмотрите на письмо, которое объясняет решение клиенту. Это задача с суждением. Сообщение может требовать эмпатии, более мягкого тона или короткой версии для занятого покупателя. Здесь ИИ полезен, потому что формулировка важнее строгой последовательности.

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

Хорошее разделение простое: код решает, что разрешено. ИИ помогает с объяснением, составлением черновиков, резюмированием и крайними случаями, где человек всё ещё принимает окончательное решение.

Как вынести правила из подсказок

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

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

Затем перепишите каждый выбор в простой if–then форме. Делайте это скучно и точно:

• Если скидка выше 12%, требуется одобрение менеджера.
• Если клиент в заблокированной стране, не генерировать контракт.
• Если срок действия котировки меньше 7 дней, требуется обновление.

Дальше процесс довольно прост: выпишите все точки принятия решений. Превратите каждое решение в короткое правило. Храните стабильные правила в коде, а для значений, которые меняются чаще — таблицу правил (discount caps, approval thresholds, country restrictions). Выполняйте эти проверки до любого шага с участием ИИ.

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

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

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

Пример: подтверждение скидки для отдела продаж

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

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

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

Правила могут выглядеть так: стандартным сделкам автоматически можно давать до 10%, существующим клиентам при годовой предоплате — до 15%, а всё, что понижает маржу ниже фиксированного пола, требует ревью менеджера. Если клиент в регулируемом сегменте или контракт содержит нестандартные условия, система может также требовать проверки юриста или финансов.

Теперь маршрутизация предсказуема. Небольшой продление на 12% с хорошей маржой может пройти автоматически, если политика это позволяет. Большая новая сделка на 22% уходит к менеджеру по продажам. Сделка с тонкой маржой и нестандартными условиями идёт к менеджеру и в финансы. Никто не должен гадать.

После того как код принял решение, автоматизация потока утверждений становится легче. ИИ может составить записку для утверждения, суммировать причину и подставить цифры из карточки сделки. Он может написать: "Запрошенная скидка превышает лимит автоодобрения, потому что прогнозируемая маржа падает ниже 18%. Требуется проверка менеджера." Это экономит время, не меняя исхода.

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

Ошибки, которые подрывают доверие

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

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

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

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

Пару типичных ошибок встречаются часто:

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

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

Правки подсказок создают ту же кашу. Тихая смена формулировки во вторник может привести к плохим утверждениям в среду. К пятнице никто не помнит, что изменилось.

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

Проверки перед запуском

Перед включением автоматизации сначала проверьте простые случаи. Если два человека дают один и тот же вход, они должны получить один и тот же ответ. Если нет — какое‑то правило всё ещё в подсказке, а не в коде.

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

Короткий чек‑лист:

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

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

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

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

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

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

Практичный план на неделю достаточен:

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

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

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

Если грань между правилом и суждением всё ещё кажется размыта, внешний обзор может сэкономить много переделок. Oleg Sotnikov фокусируется на таком AI‑первом инжиниринге и работе в роли Fractional CTO, и oleg.is — полезная ссылка, если вы решаете, где софт должен обеспечивать политику, а где ИИ должен помогать.

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