Пилот LLM для финтеха за 14 дней: план без лишнего

Почему пилот тормозит до старта

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

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

Чаще всего пилот тормозят четыре вещи:

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

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

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

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

Как выбрать функцию, которую реально проверить

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

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

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

Хороший кандидат на пилот выглядит просто:

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

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

Успех тоже лучше зафиксировать до запуска. Не "стало удобнее", а конкретно: сократили среднее время обработки с 6 минут до 4, модель верно заполняет обязательные поля в 92% случаев, доля опасных ошибок не выше 1%, оператор принимает черновик без серьезной правки в трети обращений.

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

Типовой сценарий для финтеха

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

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

Обычно хватает 4-6 категорий, чтобы пилот стал полезным уже в первую неделю:

• блокировка карты или счета
• статус перевода или платежа
• лимиты и комиссии
• запрос документов или выписки
• подозрение на мошенничество

Пример простой. Клиент пишет: "Перевод ушел, получатель денег не видит". Модель относит обращение к категории "статус перевода", помечает его как обычное или срочное по правилам команды и готовит черновик: что проверить, какой срок обработки назвать, когда передать кейс во вторую линию. Сотрудник открывает тикет, быстро правит текст и отправляет ответ.

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

Что команда решает в первый день

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

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

Один короткий документ

В тот же день стоит собрать рабочий документ на 1-2 страницы. Не презентацию на 20 слайдов, а лист, который можно открыть за минуту и сразу понять, что именно проверяют. В нем достаточно четырех вещей: какую бизнес-задачу пилот решает, что входит в объем и что точно не входит, кто принимает решение через 14 дней и по каким метрикам команда скажет "да", "нет" или "нужно доработать".

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

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

Стоп-условия до старта

До начала работ команда заранее договаривается, когда она останавливает пилот. Это снимает половину споров на второй неделе.

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

План работ на 14 дней

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

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

• Дни 1-2. Выбирают один сценарий, пишут критерии успеха и назначают владельца.
• Дни 3-5. Собирают небольшую, но живую выборку, часто 100-300 кейсов, и вручную размечают ожидаемый результат.
• Дни 6-8. Делают несколько версий промпта, собирают простой тестовый контур и подключают базовую интеграцию без лишней автоматики.
• Дни 9-11. Прогоняют поток на реальных кейсах в теневом режиме, где сотрудник видит ответ модели, но не зависит от него.
• Дни 12-14. Считают метрики, разбирают сбои по типам риска и готовят решение по следующему шагу.

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

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

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

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

Данные и доступы без лишнего риска

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

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

То же относится к логам. Не храните полный prompt и полный ответ "на всякий случай", если вам нужен только итоговый класс, оценка уверенности и несколько технических меток. Лишние поля в логах потом долго объяснять ИБ и комплаенсу.

На пилоте стоит сразу ввести четыре ограничения:

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

Это не бюрократия. Если аналитик вручную проверяет 200 ответов модели, журнал доступа потом показывает, кто именно работал с выборкой и не утекли ли данные в соседний чат, ноутбук или личную таблицу.

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

Как считать результат и риск

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

Если пилот проверяет разбор обращений, возвратов или KYC-заметок, возьмите 50-100 реальных кейсов из обычного потока. Для каждого кейса запишите время работы человека до пилота, а потом время с моделью. Считать нужно по одному и тому же сценарию, иначе цифры быстро поплывут. Если аналитик раньше тратил 12 минут на кейс, а с пилотом тратит 7, экономия видна сразу.

Одной скорости мало. Ошибки лучше делить по цене:

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

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

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

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

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

Где пилот ломается чаще всего

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

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

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

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

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

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

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

Что показать комитету

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

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

Обычно хватает пяти вещей:

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

Для финтеха особенно плохо работают формулировки вроде "качество стало лучше". Комитет обычно спрашивает другое: сколько случаев проверили, сколько ошибок нашли вручную, какой тип ошибки самый дорогой и можно ли держать данные внутри России. Если в архитектуре есть внешний или проксирующий API, это тоже надо назвать прямо: где хранятся логи, как маскируются PII, есть ли журнал по каждому запросу и кто отвечает за 152-ФЗ.

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

Что делать после пилота

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

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

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

Отдельно нужно быстро решить операционные вопросы:

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

Если команде нужен единый шлюз, совместимый с OpenAI, с логами и биллингом внутри РФ, можно посмотреть на RU LLM. В таком контуре обычно достаточно сменить base_url и оставить текущие SDK, код и промпты без изменений.

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