Как Papaya Global построила compliance-агента на Claude, Lovable и Supabase без инженеров
Payroll compliance — это бизнес, где один неверный ответ может стоить $250,000. Papaya Global ведёт такие процессы в 160 странах и всё время проигрывала тихую войну. В 2 часа ночи, когда у клиента возникает реальный вопрос, например можно ли уволить сотрудника в Германии, он не открывает базу знаний Papaya. Он открывает ChatGPT. Тот отвечает за секунды, звучит абсолютно уверенно и иногда полностью ошибается.
Именно эту проблему на SaaStr AI Annual 2026 пришли решить вице-президент по работе с клиентами Papaya Sivanne Fishel и руководитель продуктового дизайна Hagit Ben-Tzur. Их сессия называлась «Ваш AI-агент приведёт вас в суд. Вот как мы исправили свой», и это наглядный разбор того, что нужно, чтобы запустить агента в домене, где ошибка дорого стоит.
Начать стоит с того, что многие основатели упускают. Конкурентом Papaya никогда не был другой payroll-вендор. Конкурентом был бесплатный чат-бот, уже открытый у клиента в другой вкладке и уже заслуживший доверие, чтобы его спросить. Любая B2B-компания, которая продаёт в регулируемый рабочий процесс, теперь в такой же позиции. Ваши клиенты прогоняют вашу предметную область через общую модель, построите вы что-то или нет. Вопрос только в том, сможете ли вы быть надёжнее этой модели в 2 часа ночи, на том самом вопросе, за который потом прилетает ответственность.
И главный вывод всего проекта обычно понимают наоборот. У Papaya рабочий агент появился за четыре недели. А чтобы клиенты начали доверять ему настолько, чтобы перестать открывать ChatGPT, понадобилось четыре месяца. Построить было легче всего.
Тест, с которого всё началось
Ben-Tzur начала с простого. Она взяла реальный бразильский трудовой контракт, CLT-контракт, и отправила его в Claude. Потом тот же контракт с тем же вопросом отправила в ChatGPT.
Оба выглядели уверенно. Оба дали совершенно разные ответы. Когда она сверила их с реальным законом, ни один не оказался полностью правильным.
В этом и ловушка, в которую попадает каждый основатель вертикального AI: предположить, что модель плюс ваши данные — это уже продукт. Бразильский контракт доказал обратное. Общая модель не знает, чего не знает о вашей области, и будет говорить неправильную вещь с полной уверенностью. Проблема была не в том, какую модель она выбрала. Проблема была в том, что ни одну из моделей никто не научил думать о compliance. Поэтому она перестала спрашивать, какой AI лучше, и начала спрашивать, почему они ошибаются.
Превращать каждую ошибку в правило
Каждый раз, когда она находила ошибку, она писала правило. Правило четыре: не угадывать юрисдикцию. Правило восемь: не звучать уверенно, если ты не уверен. Правило восемнадцать: не указывать на проблему без ссылки на правильный закон. По одному, неделями, пока не набралось 22 правила.
Фактически она строила библиотеку правил на основе eval-подхода, и именно эту библиотеку конкуренты не могут быстро скопировать. Каждое правило — это воплощённое в коде институциональное знание, тот самый суждение, которое держит в голове опытный compliance-юрист, а модель к нему доступа не имеет. Библиотека накапливается. Каждая новая ошибка, которую Papaya ловит, навсегда делает продукт лучше, а у конкурента, который стартует сегодня, нет ни одного из этих правил. Вот как на практике выглядит «предметная экспертиза как moat». Это не слайд. Это 22 конкретные корректировки, каждая из которых заработана конкретной ошибкой модели.
Разница проявилась сразу, как только она прогнала тот же бразильский контракт через все три варианта:
Один и тот же документ, один и тот же вопрос. Разрыв между общими моделями и доменным агентом был не в интеллекте. Он был в том, что нужно искать и что игнорировать.
Одной модели было недостаточно, поэтому они построили вторую для проверки первой
Даже с 22 правилами агент всё равно ошибался. Реже, но достаточно часто, чтобы это имело значение, когда неправильный ответ несёт шестизначную ответственность. Правила исправляют то, что модель знает. Они не исправляют то, как модель ведёт себя, а самое опасное поведение в compliance — это уверенная ошибка.
Поэтому Papaya построила вторую AI-систему, единственная задача которой — проверять первую. В итоге получился трёхэтапный pipeline, который повторяет то, как реально работает юридическая фирма:
Аналитик. Применяет все 22 compliance-правила — по юрисдикции и по фактам, так, как черновик пишет младший юрист.
Ревьюер. Отдельный AI со своим набором проверок, который ловит излишнюю уверенность, ложную неопределённость и смешение юрисдикций, как старший проверяет работу младшего.
Финализатор. Объединяет исправления, структурирует результат и отправляет его, как подписывает партнёр.
Такую архитектуру стоит назвать, потому что она обобщается: генерация, adversarial review, затем синтез. Одна модель, оценивающая собственную работу, унаследует собственные слепые зоны. Вторая модель с другой задачей ловит метаошибки, которых первая в себе не видит.
Формулировка Ben-Tzur для всей системы была такой: правила сделали её точной, слой валидации сделал её надёжной, а UX — хорошей. Три разные задачи, и модель касается только первой.
Построили без инженеров и без UX-дизайнеров
Ben-Tzur собрала Papaya 1 без инженеров и без UX-дизайнеров. Для всех, кто занимается vibe coding в продакшене, это именно тот фрагмент, который стоит изучить.
На первом этапе она проводила дизайн-исследование в Claude, затем перешла в Claude Code, потом гоняла итерации между Claude Code, MCP от Figma и дизайн-системой Papaya. Когда всё стало выглядеть правильно, она подключила Lovable для живого прототипа и деплоя, а Supabase взял на себя аутентификацию, базу данных и edge functions. На втором этапе дизайн-инструменты Claude полностью заменили Figma, и цикл сократился до связки Claude design, Claude Code и Lovable.
Стратегический вывод важнее списка инструментов. Когда стоимость сборки падает почти до нуля, сама сборка перестаёт быть дифференциатором. Всё, что делает продукт защищаемым, смещается в то, что инструменты дать не могут: методология, предметное знание и доверие. Она сказала это прямо: настоящая работа была в compliance-методологии, а не в коде. Компания из payroll-compliance подтвердила тезис о vibe coding на главной сцене, и это были не продавцы dev tools, пытающиеся что-то продать.
Что реально делает Papaya 1
Продукт отражает ту же дисциплину. Онбординг занимает два клика: выбрать роль, выбрать страны интереса, никаких форм и пустых анкет. Главная страница — тоже не пустое окно чата, и это осознанное решение ради доверия. Пустое окно провоцирует расплывчатый, плохо сформулированный вопрос, который и создаёт уверенно неверный ответ. Вместо этого система открывается с готовыми сценариями и подсказками, собранными под конкретного пользователя, так что HR-лид, сфокусированный на Германии, видит один продукт, а другой пользователь — другой. Портфель, страны, уведомления — всё адаптировано. Каждый пользователь видит свою Papaya 1.
Загрузите контракт, и система прогонит его через три этапа, возвращая чистое разделение: в демонстрации с бразильским контрактом одна проблема была отмечена, а 13 пунктов подтверждены как соответствующие требованиям и готовы к передаче юридической команде. Попросите сравнить правила probation в Германии и Бразилии, и те же три агента покажут сравнение бок о бок, чтобы помочь принять решение, а не просто выдадут стену текста.
Не запускать на всех и прямо говорить, что это guidance
На этапе go-to-market Fishel была прямолинейна. Papaya не выкатила Papaya 1 сразу всем клиентам. Они выбрали небольшой пул — пять-десять клиентов, которым доверяют, тех, кто уже приходит с compliance-вопросами и ведёт себя как партнёры. Эти клиенты задают правильные вопросы и дают честную обратную связь вместо вежливых комментариев, а продукт улучшается на реальных вопросах, а не на внутренних тестах. Каждый ответ явно помечен как guidance, а не legal advice.
Её совет тем, кто внедряет доменный агент: не запускайте продукт на всех клиентов в один день. Самый трудный вопрос — не работает ли агент. Он работает. Он может работать через день или через четыре недели. Самый трудный вопрос — достаточно ли вы ему доверяете, чтобы поставить на него имя своей компании. На это уходит гораздо больше времени, чем на сборку.
Как Papaya измеряет доверие
Papaya отслеживает три сигнала, чтобы понять, действительно ли растёт доверие, и каждый из них говорит о чём-то, чего не покажет survey удовлетворённости:
Возвращаются ли пользователи? Если они приходят на следующий день или на следующей неделе с новым вопросом, значит предыдущий ответ заслужил второй. Повторное использование — первое доказательство, что агент заменяет привычку открывать ChatGPT в 2 часа ночи.
Задают ли они более сложные вопросы? Более высокие по ставке вопросы со временем означают, что доверие растёт, и одновременно это roadmap. Там, где клиенты начинают «давить», Papaya понимает, куда углублять продукт дальше.
Используют ли они меньше внешних консультантов? Это самый важный показатель. Если клиенты всё ещё пересылают ответы агента своей внутренней юридической команде, доверие ещё не сформировалось и Papaya ещё не снижает их внешние расходы. Меньше внешних консультантов — это жёсткое доказательство ROI, а не ощущение.
Когда все три сигнала движутся в нужную сторону, масштабируются. Пока нет — удерживаются.
Сначала ограждения, потом функции
Самая важная защита Papaya — механическая, а не строка в prompt. Они сделали kill switch. Если точность в какой-либо отдельной стране падает ниже порога, эту страну отключают, пока проблему не исправят. Вместо латания по ходу — выключают систему.
Вывод, который из этого сделала Fishel: сначала строить ограждения, потом функции. В высокорисковом домене проблема не в отсутствии фичи. Проблема — в уверенно неверном ответе, который отправляют клиенту, а тот на него опирается. Kill switch нужен потому, что в какой-то момент система ошибётся, и единственный вопрос — узнаете ли вы об этом раньше клиента или позже.
Что можно скопировать, а что нельзя
AI — это двигатель. Предметное знание — это топливо. Двигатель можно скопировать. Топливо — нельзя.
Что можно взять из playbook Papaya
Если вы строите доменного агента в 2026 году, вот порядок работы, который следует из их сессии:
Считайте, что ваш настоящий конкурент — это общая модель, которой клиент уже доверяет. Стройте продукт так, чтобы он был надёжнее ChatGPT в одном вопросе, за который наступает ответственность, а не просто богаче по функциям, чем предыдущий вендор.
Превращайте каждую ошибку в правило. Ваш eval suite — это ваш moat. Конкурент может скопировать ваш интерфейс за выходные, но не может скопировать 22 корректировки, которые вы заработали за месяцы.
Добавьте вторую модель для проверки первой. Генерация, adversarial review, синтез. Модель, оценивающая собственную работу, сохраняет собственные слепые зоны.
Сначала сделайте kill switch, потом функции. Заранее решите, какой порог точности отключает рынок, и отключайте.
Запускайтесь на пяти-десяти клиентах, которые скажут правду. Реальные вопросы лучше внутреннего тестирования, а честные партнёры лучше вежливых.
Измеряйте доверие, а не удовлетворённость. Повторное использование, более сложные вопросы и меньшая зависимость от внешних консультантов — вот сигналы, которые говорят, когда можно масштабироваться.
Рабочий агент у Papaya появился за четыре недели. Доверие к нему заняло четыре месяца. Планируйте именно четыре месяца, потому что это та часть, которая и выигрывает сделку.
Материал — перевод статьи с английского.