Реальная ценность, а не дань моде: как внедрить AI в финтех с пользой для бизнеса

На сегодняшний день уже 78% компаний по всему миру используют AI в своих продуктах. В сфере финтеха тоже заметен рост: по прогнозам экспертов, к концу 2025 года объем рынка AI в fintech достигнет 17,1 млрд долларов.

При этом в погоне за трендом компании стараются внедрить ИИ без оглядки на пользу для клиентов. В результате только 22% пилотных проектов переходят к реальному внедрению, а существенную пользу получает совсем небольшая доля бизнесов, около 4%. Большая часть проблем возникает не из-за недостатков технологии, а из-за неправильного выбора подхода.

Привет, Хабр! Меня зовут Саша Бондаренко, я CPTO в Garage Eight. Повсеместный хайп вокруг AI уже никого не удивляет, но реальная польза для бизнеса становится всё более важным вопросом. В этой ситуации особенно важно различать AI Feature и AI Native не как модные термины, а как стратегические подходы с разной экономикой и разным влиянием на продукт.

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

Что такое AI Feature и AI Native

AI Feature — добавление AI без изменения сути. Это внедрение AI без кардинального изменения продукта — например, добавление чат-бота в службу поддержки или AI-ассистента в приложение банка. В этом случае пользовательский путь не меняется и AI решает локальную задачу. Вот несколько примеров:

• Revolut — финтех-сервис внедрил AI-анализ транзакций: AI ищет забытые подписки, анализирует регулярные платежи, предлагает отменить. Это не изменило ядро продукта и не стало новой категорией. В этом случае AI Feature решает конкретную узкую задачу.

• Robinhood — инвестиционный сервис добавил подбор новостей и объяснение терминов с помощью AI. LLM рекомендует релевантные новости для конкретных ценных бумаг и объясняет сложные термины простым языком. Это встроенный помощник, но не пересборка trading experience, так что это снова AI Feature.

• PayPal — финтех-сервис добавил AI-поддержку в диспутах между продавцами и покупателями. Ассистент помогает составить описание спора и подсказывает, какие документы нужны, — это локальный AI-ускоритель. PayPal не делал AI Native решение, не пересобирал процесс.

Использовать AI Feature нужно очень осознанно, потому что часто это превращается в AI ради AI. Например, за последние годы многие финтех-сервисы и CRM внедрили AI-ассистентов, которыми никто не пользуется, а AI-рекомендации в ecommerce оказались хуже естественных.

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

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

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

• Cursor — сервис для генерации кода на основе промптов. Он не добавил дополнение к привычному VS Code, а принципиально переопределил код-редактор и его возможности.

• Perplexity — умная поисковая система, которая стала новым видом поиска, а не дополнила Google.

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

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

В чём разница подходов

Сравним оба метода с точки зрения глубины изменений.

Как определить, что вам нужен AI: практические инструменты

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

7 вопросов для оценки AI-идей

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

• Меняется ли суть задачи пользователя? (Да = AI Native)

• Можем ли мы убрать более трех шагов из текущего пути? (Да = AI Native)

• Можем ли создать новую категорию продукта? (Да = AI Native)

• Готовы ли пользователи к кардинальным изменениям? (Нет = AI Feature)

• Есть ли у нас данные для обучения AI? (Нет = начать с AI Feature)

• Критична ли скорость выхода на рынок? (Да = AI Feature)

• Есть ли ресурсы на полную перестройку? (Нет = AI Feature)

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

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

Карта пользовательского пути до и после AI

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

Разберем поэтапно, как составить карту пользовательского пути для AI-проектов.

Таким образом, примерный шаблон AI CJM before-after будет выглядеть так:

Приведу кейс, как внедрение AI Native может повлиять на продукт.

До AI: пользователь ищет юридический документ, открывает 3–5 файлов, читает текст, ищет нужные блоки и делает выводы о рисках.

После AI: ассистент сам находит документы, показывает саммари по нужным блокам и выделяет риски и рассчитанные рекомендации.

В результате время пользователя в сервисе снижается с двенадцати минут до двух, а adoption возрастает с 12 до 67%. Подробнее об этом кейсе расскажу в следующих блоках.

Фреймворк AI Value Hypothesis

AI Value Hypothesis (AVH) предлагает до технической разработки сформулировать гипотезу о том, какую ценность принесет AI-инициатива. Сам фреймворк еще не закрепился на рынке, но уже обретает конкретные формы — узнать больше о нем можно в статьях PwC The path to generative AI value: Setting the flywheel in motion или Mindfuel AI Without a Value Hypothesis is Just an Experiment.

Фреймворк предлагает прописать все детали инициативы и зафиксировать метрики успеха и провала. Для этого продумайте несколько аспектов:

• Пользователь: кто наша целевая аудитория, какие у нее предпочтения, боли и интересы.

• Задача: какую проблему хочет решить пользователь с помощью нашего сервиса.

• Текущий путь: сколько шагов совершает пользователь сейчас до целевого действия.

• AI-путь: как изменится количество шагов и время пользователя в приложении после внедрения AI.

• Гипотеза ценности: во сколько раз функциональность для пользователя станет проще, понятнее или удобнее.

• Метрика успеха: что будем считать хорошим результатом и как количественно и качественно его измерим.

• Критерий провала: при каких обстоятельствах остановим внедрение.

Примеры метрик успеха для двух подходов:

Критерии провала могут быть такими:

• adoption < 10%;

• нет delta-value;

• AI увеличивает steps/time.

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

Minimum Viable AI Opportunity для быстрого тестирования

MVA — это MVP с AI. Подход тот же, что у классической первой версии продукта: создание простого прототипа для первых тестов, проверка гипотез и принятие решения о работе над полноценным сервисом.

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

1. Выберите один сценарий использования AI, который хотите протестировать.

2. Создайте самый простой прототип решения. Это может быть даже no-code-вариант, который позволит проверить гипотезу.

3. Протестируйте прототип на 10–15 пользователях. Задайте им вопросы о клиентском опыте, впечатлениях, недостатках и возможных улучшениях. Соберите количественные данные о том, как изменилось время решения задачи до и после внедрения AI.

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

5. Агрегируйте все данные и примите решение о дальнейшей работе над продуктом. Если пользователи высказываются позитивно, готовы платить, а бизнес-модель позволяет инвестировать в разработку — стоит попробовать.

При этом правильный MVA отличается от классического MVP:
он фокусируется не только на пользовательской ценности, но и на валидации AI-компонента и его поведения в реальных условиях:

MVA:

• включает обязательное измерение delta-value (время, количество шагов, качество результата);

• измеряет AI-специфичные метрики, критичные для принятия решения о масштабировании: model performance (accuracy, precision, recall, F1), inference latency (время ответа модели), cost per prediction, human-in-the-loop rate и скорость деградации модели (drift detection);

• содержит fallback-сценарий на случай ошибок AI;

• фокусируется на одном самом болезненном шаге пользовательского пути;

• допускает no-code / low-code интеграции;

• не требует изменений в архитектуре;

• запускается менее чем за две недели.

Для запуска MVA можно использовать разные типы прототипов:

• no-code прототип в Notion / Tally;

• mock-backend + LLM-подсказки;

• интерцептор данных, подменяющий один шаг процесса;

• тестирование в WhatsApp / Telegram вместо полноценного UI;

• Wizard of Oz, где человек временно исполняет роль AI-ассистента.

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

После тестов MVA важно проанализировать, чтобы ответить на несколько вопросов. Стало ли проще? Что бы вы убрали из текущего процесса? Где AI ошибся? Доверяете ли вы результату? Хотели бы использовать это ежедневно? Заплатили бы вы за это (если B2C/B2B)?

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

Частые ошибки при внедрении AI

Даже глубокая аналитика и применения инструментов не всегда спасают от типовых ошибок. Из основных я бы выделил такие:

• Начинать с модели, а не с задачи. Чтобы избежать, используйте AI Value Hypothesis и CJM Before/After.

• Думать, что AI Feature — дешевый win. На самом деле AI Feature может ухудшить UX, увеличить когнитивную нагрузку и привести к потере доверия пользователей.

• Не учитывать explainability. Для финтех-продуктов особенно критично, чтобы AI объяснял конкретный выбор и действия.

• Не предусмотреть fallback. Приводит к отказам, падению CR, фрустрации.

• Пытаться заменить все ручные процессы сразу. Правильнее будет автоматизировать 20% самого болезненного сценария.

• Не определять метрики провала (kill criteria). Очень важно зафиксировать, когда стоит остановиться.

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

• Ожидать, что AI-фичи появятся быстро, потому что модель уже есть. Для реализации фичи нужно правильно оценивать интеграцию в существующую архитектуру, учитывать требования к тестированию, нагрузке и безопасности и закладывать время на юридические проверки. Реалистично считать delivery MVA в 2–4 раза дольше обычных фич.

• Создавать AI-фичи, не консультируясь с юристами. Часто происходит, что команды уже после разработки AI понимают, что юридически функциональность неприемлема или требует серьезного пересмотра. Например, не хватает политики обработки данных, на которых работает AI, или не выполняются требования к прозрачности алгоритма. В таком случае реальные риски могут варьироваться от блокировки фичи до штрафов и запретов со стороны регуляторов, а также потери доверия клиентов. Чтобы избежать этой ошибки, создайте AI governance framework, согласуйте до этапа разработки всё с ИБ и юристами и используйте privacy-by-design.

• Не мониторить data drift и model drift. После деплоя AI-модели её качество почти гарантированно деградирует: меняется поведение пользователей, появляются новые типы транзакций, сдвигается контекст принятия решений. Без системного мониторинга data drift (изменение распределения входных данных) и model drift (падение предсказательной способности) модель может незаметно потерять 30–35% точности за 6 месяцев, продолжая «выглядеть рабочей». Чтобы избежать этого, настройте continuous monitoring drift-метрик (PSI, KL-divergence, embedding drift), внедрите automated retraining pipelines при превышении порогов и используйте observability-платформы для отслеживания performance моделей в реальном времени.

• Игнорировать data bias и algorithmic bias. Модель, обученная на исторических данных, почти всегда наследует прошлые искажения и дискриминационные паттерны — а иногда и усиливает их. Data bias возникает из-за нерепрезентативных или искажённых данных, algorithmic bias — из-за самого механизма обучения, даже на формально «чистых» данных. В финтехе это приводит к системным отказам для отдельных групп пользователей, репутационным рискам и вниманию регуляторов. Чтобы минимизировать риск, проводите data audit на репрезентативность, тестируйте модели с помощью fairness-метрик (equalized odds, demographic parity), расширяйте признаки альтернативными данными и внедряйте fairness constraints или техники debiasing (re-weighting, adversarial debiasing) ещё на этапе обучения. История уже показала, что игнорирование bias обходится дорого — от кейса Amazon Recruiting AI до скандала с Apple Card и выводов британского регулятора FCA в 2024 году.

• Измерять впечатления, а не delta value. Регулярно AI оценивают не по бизнес-эффекту, а по мнению, которое сформировалось у аудитории. Проблема в том, что «вау-эффект», заметный на старте, очень быстро пропадает и за это время можно ошибочно проинвестировать в фичи, которые не влияют на бизнес-метрики. Измеряйте вместо впечатления delta value*.

Value Delta = (T_before – T_after) × Freq × Cost_per_minute

Эта формула показывает, какую ценность дает AI-внедрение благодаря экономии времени пользователя или сотрудника. Используется как в B2C, так и в B2B, а в финтехе особенно хорошо ложится на процессы саппорта, операций, трейдинга, KYC и других повторяющихся сценариев.

• T_before (Time Before) — время выполнения задачи до внедрения AI. Считаем, сколько минут или секунд пользователь или сотрудник тратил на сценарий раньше.

• T_after (Time After) — время выполнения той же задачи после внедрения AI.

• Freq (Frequency) — частота выполнения сценария за единицу времени. Сколько раз пользователи или сотрудники совершают этот процесс за день, неделю или месяц.

• Cost_per_minute — стоимость одной минуты выполнения сценария. Выражается:

  • в деньгах: зарплата сотрудников, стоимость ошибки;

  • влиянии на выручку: например, каждая минута задержки снижает CR;

  • пользовательской ценности скорости.

Чтобы избежать ошибки, используйте формулу, а также фиксируйте гипотезы ценности фичи до разработки, сравнивайте качество относительно baseline, а не красоту и прекращайте эксперименты, если value delta ниже порога.

Реальные кейсы использования AI-подходов

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

Кейс 1. Внутренний ассистент для работы с документами

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

Так происходило по совокупности причин:

1. Ручной поиск оставался быстрее, чем помощь AI. Сотрудники знали, в какой папке находится документ или по каким ключевым словам его можно найти. Поиск руками занимал примерно 20–40 секунд, в то время как обращение к ассистенту, включая формулировку запроса, уточнения и ожидания ответа, требовало около 1,5–2 минут.

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

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

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

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

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

• «Слишком много данных, не хочу ошибиться».

• «Хочу, чтобы приложение само подсказывало».

• «Почему нельзя заполнить за меня то, что я уже вводил раньше?»

• «Мне сложно понять, что именно выбрать в пункте X».

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

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

Мы хотели протестировать безопасный AI Feature сценарий. Заполнение форм не критичный риск, не высокочастотный сценарий и не затрагивает ядро продукта. Именно поэтому это был хороший кейс для первой волны AI-итераций. В то время на рынке рос тренд на smart forms — интеллектуальные формы, которые анализируют контекст пользователя, предзаполняют и адаптируют поля на основе ML. Мы анализировали конкурентов и видели, как банки, страховые компании и финансовые сервисы начали тестировать полуавтоматическое заполнение анкет. Мы не хотели быть догоняющими, поэтому рассматривали этот сценарий как возможность закрыть очевидный pain point и протестировать новый подход.

В результате внедрения smart forms ассистентом стали пользоваться уже 67% специалистов, а скорость принятия решений выросла в 2,3 раза.

Если коротко описывать этот кейс, получилось так:

• Ошибка: мы ожидали, что пользователи будут вручную запрашивать документы через чат.

• Инсайт: 83% сотрудников не могли точно сформулировать, что ищут, им были нужны подсказки.

• Что изменили: добавили проактивный анализ задач и автопоиск.

• Почему стало AI Native: AI перестал быть инструментом, стал частью decision-making-процесса.

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

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

Мини-дерево решений

1. Определите ключевой сценарий (core/non-core).
2. Оцените глубину изменения пользовательского пути.
3. Оцените доступность данных.
4. Проверьте риски: legal, security, explainability.
5. Выберите подход:
> если изменяется суть задачи — Native;
> если это ускорение/упрощение — Feature.
6. Прогоните через AI Value Hypothesis.
7. Определите эксперимент (MVA) и метрики успеха.

И пусть ваши проекты с AI будут полезными для бизнеса и эффективными! Если у вас есть вопросы о подходах или инструментах, задавайте их в комментариях.