Умный кредитный кабинет — выжимка Q&A с экспертами Альфа-Банка¶

Трек: «Умный кредитный кабинет» для предпринимателей (малый и микробизнес, ММБ), Альфа-Банк / «Альфа Будущее». Источник: запись Q&A-вебинара с экспертами (автотранскрипция, поэтому имена и отдельные термины могут быть искажены).

Главное в одной строке: нужен работающий, самостоятельно запускаемый end-to-end прототип кредитного конвейера (клиент + банк) на синтетических данных и моках. Лучше меньше фич, но всё работает и всё обосновано и задокументировано. ИИ не обязателен и не даёт преимущества сам по себе.

1. Эксперты¶

Кто	Зона
Тимур Балбаев	Руководитель технологического развития департамента кредитного и гарантийного бизнеса, общий ведущий
Евгений Окунцев, Николай	Backend (Java)
Ольга Урсул	Системный и бизнес-анализ, документация, модели
Данила Звягин	AI / LLM, frontend
Александр Кузьмичев	Тестирование, качество
Антон, Денис Мишенков	Архитектура, интеграции, инфраструктура
Алексей Григорьев	IT-лидер стрима (платформа кредитования), критерии приёмки, орг. вопросы
Наталья Глазкова-Иванова	HR-бренд IT ММБ

Организационные вопросы (команды, состав и т.п.) — в Telegram-чат для тех. и орг. вопросов, не экспертам. Неотвеченные вопросы из Zoom-чата организаторы обещали собрать и ответить в Telegram. Также рекомендуют подписаться на Telegram-канал «Альфа Будущее».

2. Пять опорных частей задачи¶

Исследование предметной области. Продуктовое мышление: какую проблему решает каждая фича и почему. Подготовленный и обоснованный бэклог — большой плюс. «Кушайте слона по кусочкам».
Модель кредитного процесса. Изучить реальные этапы конвейера и спроектировать свою модель. В тексте задания много намёков — каждый абзац несёт смысл, непонятное стоит загуглить.
Личный кабинет клиента.
Функционал для банка (сотрудник банка). Заявка не должна «улетать в пустоту» — нужно показать, что с ней происходит на стороне банка.
Всё объединено в работающую логику. Картинки и записанные видео — не то. Нужен прототип, который эксперт сможет сам запустить и проверить.

Каждый буллет критериев в задании оставлен не случайно (лишние убрали). Регулярно сверяйтесь с исходным заданием.

3. Границы решения¶

Скоуп: от подачи заявки до принятия решения и выдачи кредита. Сопровождение после выдачи — не требуется (можно сверху, но рискованно: «сделать слишком много» часто хуже).
Этапы (подача заявки, проверка данных, подбор продукта, решение, выдача) гуглятся. Набор и глубину определяете сами, но каждое решение (добавить, упростить, опустить) должно быть обосновано. При этом пропуск того, что явно заявлено в задании, — минус.
Регистрация не нужна. Клиент — уже действующий клиент банка (ИП / юрлицо), обратился за кредитом. Авторизация — на ваше усмотрение.
Сегмент: действующие ИП и юрлица. Физлица, только планирующие открыть бизнес, не рассматриваются. Делить MVP по сегментам не обязательно.
Нужны обе стороны: клиентский интерфейс и функционал сотрудника банка (полный цикл).
Никаких интеграций с реальными банковскими системами. Все внешние системы — моки, стабы, симуляторы. Итог: автономный и воспроизводимый прототип.
Финал сценария: эксперты советуют «сделать счастливого клиента в конце» — смоделировать событие одобрения и выдачи (например, мок зачисления на счёт). Реальные проводки не нужны.
Подписание договора обязательно должно быть в процессе как шаг; можно упростить (простая ЭП / код подтверждения в интерфейсе без SMS, УКЭП «как будто есть») — это типовое допустимое упрощение.

4. Упрощения и моки¶

Допустимы и ожидаемы, но их нужно явно обозначать и обосновывать («я знаю, что здесь должно быть X, в прототипе это мок»).
Можно урезать внешние API (например, госсистемы) до нужного подмножества полей.
Не злоупотреблять: упрощения уместны в ключевых местах, но не половина решения.
Упрощённая часть = скорее 0 баллов за детальную реализацию этой части. Оценка сравнительная между командами.
Совет эксперта: выделить ~5 базовых шагов конвейера, сделать их полностью, остальное — упрощённо. Если время осталось — доводить куски без упрощений.
Добавить этап сверху в упрощённом виде с обоснованием, что он нужен, — нормально, может быть плюсом.

5. Данные и документы¶

Обязательного перечня полей нет. Что используете — обосновано; что умышленно не используете — тоже по какой-то причине.
Все данные синтетические, генерируете сами; формат и содержимое — ваши.
Загрузка и автообработка документов (выписки, финотчётность) — необязательно, бонус. Можно анкета, можно документы, можно упростить.
Использование распознанных данных (реквизиты, суммы) для прогноза кассового разрыва и рекомендаций — можно, если объясните зачем и где это место в процессе.
Хранение: данные синтетические, но учёт законодательных требований — «маленький спойлер», что это может оцениваться.

6. Кредитные продукты и рекомендации¶

Продукты — свои, условные (в реальности базовых продуктов немного, «по пальцам двух рук», отличаются параметрами). Под конкретные продукты Альфа-Банка не подстраиваться, интеграции с банком нет.
Условия должны быть реалистичными: учитывать текущую ключевую ставку ЦБ и рыночные ставки. «Всем по 0,5% годовых» — оторвано от реальности.
Параметры подбора (обороты, выручка, кредитная история и т.д.) — выбираете сами; найти действительно важные — часть задачи.
Объяснимость: система должна выдавать ожидаемые и объяснимые результаты для заданных входов. Необъяснимое поведение = баг. Банк должен понимать, почему предложен продукт. Показывать ли обоснование клиенту и в каком объёме — UX-решение команды.
Контрпредложение (например, меньшая сумма) — решайте сами, входит ли в ваш MVP (подсказка: перечитать задание).
Где участие сотрудника, а где автомат — решайте сами; обоснованная автоматизация — плюс. 100% автоматизация не требуется.

7. ИИ, LLM и ML¶

Вопрос	Ответ
Обязательны LLM / ML / ML-скоринг / AI-ассистент?	Нет. Это «вау-фича», не даёт преимущества сверх любой другой классно сделанной фичи. Трек про ММБ, не про ИИ.
Какие модели можно?	Только с открытыми весами. Требование касается всего: LLM, OCR, эмбеддинги, классификаторы.
Закрытые сервисы (Yandex OCR и т.п.)?	Нельзя.
Как указать модели?	LLM — ссылкой на Hugging Face. OCR и подобное — положить в репозиторий.
Можно ходить к open-weights модели через сторонний API?	Да, для разработки и демо провайдер не ограничен.
Обязательное требование к интеграции LLM	OpenAI-compatible и конфигурируемо: эксперты подставят свой base URL, API-ключ и имя модели.
Размер модели	Желательно не более 120B параметров.
Время ответа	Жёсткого лимита нет; думайте об UX и потоке заявок, выбирайте модель оптимально.
Несколько моделей под разные задачи	Можно.
ML-модель скоринга без реальных данных	Достаточно заглушки, легко заменяемой на модель банка, + обоснование, почему здесь ML. Обучать новое не требуется.
AI-ассистент	Не обязателен. Может просто отвечать на запросы; проактивность — по желанию.
Оценка ассистента	По вашей документации: эксперты поймут замысел и проверят на своих синтетических данных.
Кодекс этики ЦБ по ИИ	Не требуется. Если учитываете — опишите в аннотации.

8. Технические требования¶

Docker: всё решение должно легко подниматься у проверяющего (разные ОС, без «приседаний»). LLM можно запускать отдельно (например, через Ollama и т.п.), паковать модель в Docker не обязательно.
Запуск без вас по инструкции. Эксперты сами разворачивают решение. Проверка: отдайте инструкцию другу — запустится ли?
Свой сервер / VPS для демо — можно, но обязателен рабочий локальный запуск. Ссылка на демо при неработающем локальном запуске не спасёт.
Ресурсы: ориентир — решение в простое укладывается примерно в 12 ГБ RAM; CPU не важен. Клиентская часть — веб, условный рабочий ноутбук на Windows с 8 ГБ. Про GPU ответа пока нет — обещали позже.
SLA не оценивается напрямую, но описание SLA по этапам и способов его обеспечения — большой плюс.

9. Интерфейс и дизайн¶

Жёстких требований и референсов нет — простор для творчества. Цель — сделать лучше топовых банков.
Десктоп достаточно, если работает «как швейцарские часы». Адаптив под мобильные — небольшой плюс.
Дизайн-система Альфа-Банка публична, ссылку давали в чате вебинара — пользоваться можно, но не обязательно. Свой стиль в цветах банка тоже приветствуется (зелёный — будет странно).
Логотипы Альфы — можно, но не нужно.
Разные интерфейсы для ИП / юрлиц — не обязательно; если нашли обоснованную специфику (анкеты, шаги) — отражайте.
Один веб-интерфейс с ролями или несколько — решайте и обосновывайте сами.

10. Документация (важно!)¶

Эксперты несколько раз повторили: документируйте. Без описания замысла оценка становится субъективной и может быть неверной.

Документация нужна и в репозитории, и отдельным документом / аннотацией.
Разделите артефакты:
аналитика: модель кредитного процесса, требования, модель данных, модели обмена данными, API, обоснование решений;
инфраструктура и разработка: архитектура, хранение, запуск.
Описывайте требования к решению — эксперты будут сверять работу с ними.
Продуктовые практики (CJM, Jobs To Be Done, пользовательские проверки) — плюс, если реально использовались, а не написаны постфактум «для галочки».
Файл с источниками и инструментами — по желанию.
Учитывайте обе стороны: выгода клиента и выгода банка. Если сотрудник тратит 2 часа на простое действие — это плохо для всех.

11. Как будут проверять¶

Эксперты сами запускают решение по инструкции (первый фильтр — запустилось ли).
Проверяют сквозной сценарий: от потребности клиента до получения денег, плюс процесс на стороне банка. Процесс не должен обрываться — идеальный кусок при нерабочем старте или финале = минус.
Сверяют с вашими требованиями и документацией.
Позже — защита и демонстрация (финал, судя по всему, офлайн в Москве; интернет ожидается).

Шкала оценки во многом сравнительная между командами.

12. Советы экспертов¶

Не переусложняйте. Двигайтесь от простого к сложному.
Лучше меньше фич, но всё работает.
Задавайте себе вопросы: зачем это нужно? в каком виде? что для этого нужно?
Ставьте себя на место клиента и сотрудника банка.
Обосновывайте каждое решение — и включения, и упрощения.
Возвращайтесь к заданию и проверяйте, всё ли учтено.