Коротко: один специалист учит ИИ хорошо формулировать ответы, другой решает, на какие вопросы ему вообще можно отвечать самому. Это разные задачи, и путают их постоянно.
Каждый второй разговор с основателем компании (фаундером) начинается одинаково: «У нас уже есть промпт-инженер, зачем нам ещё и архитектор?» Вопрос закономерный: со стороны обе роли выглядят как настройка ИИ под задачу продукта. На практике это разные профессии, которые решают непохожие задачи, и одна не заменяет другую.
Что делает промпт-инженер
Промпт-инженер берёт готовую языковую модель и настраивает её под конкретную задачу: пишет и уточняет текстовые инструкции для модели (промпты), тестирует разные формулировки, добивается стабильного и предсказуемого ответа. Это тонкая и важная работа: от качества промпта напрямую зависит, насколько точно и удобно продукт отвечает пользователю.
Что делает юридический архитектор
Промпт-инженер работает с формой: как модель формулирует ответ, какую роль и тон принимает, звучит ли она убедительно. Юридический архитектор работает на другом уровне: с тем, что системе вообще дозволено делать, и с границей ответственности: какие решения продукт вправе доверить алгоритму, а какие обязан передавать живому специалисту.
Задача архитектора: заложить логику так, чтобы сам сценарий действий алгоритма не создавал повод для претензии регулятора или клиента. Промпт-инженер отвечает за другое: чтобы ответ модели не «поплыл».
Это логика допустимых решений для модели: именно правовая и рисковая часть логики продукта, а не весь продукт целиком. Сюда входят:
- схемы принятия решений (деревья решений);
- список стоп-сигналов (матрица Red Flags);
- критерии, когда передавать решение человеку (критерии эскалации).
Всё это задаёт промпт-инженеру рамки, внутри которых он может действовать. Остальные продуктовые решения (что показывать пользователю, как выглядит интерфейс) по-прежнему принимает менеджер продукта (продакт-менеджер).
Житейский пример: ресторан. Официант может виртуозно расписать блюдо и убедить гостя его заказать, но не он решает, что вообще можно подавать: соблюдены ли санитарные нормы, указаны ли аллергены, годен ли продукт.
Эти границы задаёт кто-то другой, ещё до того, как официант подойдёт к столику.
Промпт-инженер — это официант. Юридический архитектор — тот, кто решает, что в принципе можно подавать на стол.
Где проходит граница: пример
Тот же принцип виден на более техническом примере: автоматическом оформлении нового клиента в онлайн-банке. Заявку обрабатывает автоматика, без участия человека, и здесь важно точно развести роли:
- Архитектор закладывает жёсткое правило: если клиент оказывается публичным должностным лицом (у таких клиентов повышенный риск коррупционных схем, поэтому банк обязан проверять их строже), автоматика не одобряет заявку сама и передаёт её на усиленную проверку специалисту по контролю за соблюдением требований (комплаенс-офицеру); если клиент найден в списке по борьбе с отмыванием денег, операция блокируется полностью.
- Разработчик привязывает это правило к программному интерфейсу для проверки данных по официальным реестрам. Проверка статуса публичного должностного лица и списков по борьбе с отмыванием денег в финтехе всегда идёт через точный, заранее предсказуемый запрос к реестру, в обход языковой модели.
- Промпт-инженер подключается на следующем шаге, там, где нужен только текст: формулирует, как вежливо и юридически корректно попросить у клиента дополнительные документы, не раскрывая, что именно вызвало вопрос, или как кратко резюмировать досье клиента для комплаенс-офицера.
Без правила, которое задаёт архитектор, промпт-инженеру попросту не с чем работать: решение о том, кого передавать человеку, принимается раньше и без участия языковой модели.
Почему нужны обе роли
Это не конкуренция за бюджет и не выбор «или-или», а последовательная работа.
Юридический архитектор проектирует логику один раз, на старте, и актуализирует её при изменении законодательства: для этого на странице услуги есть формат регулярного сопровождения (Legal Maintenance). Промпт-инженер настраивает модель под эту логику и донастраивает её по мере роста продукта.
Нанять только промпт-инженера — значит доверить решение о границах ответственности человеку, который не обязан в них разбираться. Нанять только архитектора — значит получить правильную логику, которую пока некому стабильно передать модели.
Житейский пример: в том же ресторане у двух официантов могут быть абсолютно одинаковые правила: что можно подавать, а что нет. Но один гасит недовольство гостя парой фраз и получает чаевые, а другой из-за неловкой формулировки превращает мелкую придирку в скандал и жалобу. Правильные границы не спасают от неудачной подачи: это разные, одинаково нужные навыки.
Часто задаваемые вопросы
Может ли промпт-инженер сам определить эти правила? Иногда пытается, и это частый источник проблем. Промпт-инженер обычно не юрист и не обязан разбираться, какие законодательные требования и риски стоят за конкретным сценарием.
Хорошо написанный промпт поверх отсутствующей правовой логики не спасает: модель не понимает, когда нужно остановиться и передать случай человеку, но отвечает при этом так же уверенно, будто у неё есть точный ответ.
У нас есть штатный юрист, разве не он должен формулировать эти правила? Штатный юрист хорошо знает право, но обычно мыслит нормами закона и судебными спорами. Структуры данных (деревья решений и редкие пороговые ситуации) для него непривычная система координат.
Собрать набор тестовых примеров, на которых потом проверяют, что код ведёт себя правильно (калибровочный датасет), — отдельный навык на стыке права и системного проектирования, которого юридическое образование само по себе не даёт.
Юридический архитектор переводит экспертизу юриста в формат, который сразу можно передать разработчику и промпт-инженеру.
С чего начать, если у нас уже есть и разработчик, и промпт-инженер, но нет юридической логики? С формата проектирования логики с нуля (Core Architecture & Triage Logic).
На выходе вы получаете полный комплект технического задания для разработчиков:
- деревья решений;
- список стоп-сигналов;
- критерии, когда передавать решение человеку.
Всё это оформлено в виде готовых структурированных файлов-описаний (JSON-схем) и технических спецификаций, которые команда сразу переносит в промпты и в код.
Уже используете промпт-инженера, но чувствуете, что логике продукта не хватает рамок? Посмотрите, как устроена юридическая архитектура: форматы работы и что именно я передаю команде. А если у вас уже есть команда, которая строит платформу, эту разницу мы разбираем отдельно: чем архитектор отличается от разработчика.