Itaú — один из крупнейших банков Латинской Америки — запустил генеративный ИИ сразу на двух уровнях: для клиентов через интерфейс ia.i и для сотрудников через платформу управления IARA. Это не пилот на тысяче пользователей, а промышленное внедрение в одном из самых зарегулированных секторов Бразилии. Разбираем, как устроена архитектура и что из этого применимо в вашем продукте.
Зачем вообще читать про банковский ИИ, если ты не банк
Финтех — это предельный случай продуктовых ограничений: персональные данные, финансовый регулятор, нулевая терпимость к галлюцинациям модели в ответе про остаток на счёте. Если паттерн работает здесь, он сработает в медицине, юридических сервисах, корпоративных инструментах.
Для разработчика и продуктолога кейс Itaú — это шпаргалка по трём вопросам: как разделить клиентский и внутренний контур ИИ, как выстроить governance (управление рисками модели) без бюрократического паралича и как масштабировать LLM-фичи на всю базу, а не держать их в вечном бета-режиме.
Два контура: клиент и сотрудник — разные задачи, разная архитектура
Itaú разделил внедрение на два независимых слоя.
ia.i — conversational interface (разговорный интерфейс) для клиентов. Пользователь задаёт вопросы о продуктах, операциях, условиях — и получает ответ на естественном языке вместо навигации по меню. Ключевое требование: ответ должен быть верифицируемым, потому что любая ошибка — это потенциальная жалоба регулятору.
IARA — внутренняя governance-платформа для сотрудников и команд, которые разрабатывают ИИ-продукты внутри банка. Это не чат-бот, а инфраструктурный слой: контроль доступа к моделям, логирование, аудит решений, управление промптами и версиями.
Разделение принципиально. Клиентский контур оптимизирован под UX и точность ответа. Внутренний — под скорость разработки и соответствие политикам. Смешивать их в одну систему — типичная ошибка при первом внедрении LLM в регулируемой среде.
Как выглядит AI First как стратегия, а не как слоган
«AI First» у Itaú — это не маркетинг, а принцип приоритизации: новые продуктовые решения сначала проверяются на возможность реализации через ИИ, и только потом рассматриваются классические подходы. На практике это означает несколько вещей.
Во-первых, ИИ-компетенции распределены по командам, а не сосредоточены в одном «центре ИИ». Каждая продуктовая команда имеет доступ к инструментам через IARA и несёт ответственность за качество своих моделей.
Во-вторых, governance встроен в процесс разработки, а не добавляется постфактум. Это снимает классический конфликт между скоростью и compliance: команда не может задеплоить модель в прод, не пройдя через чеклист платформы.
В-третьих, стратегия распространяется на всю клиентскую базу сразу, а не на отдельный сегмент. Это требует горизонтальной масштабируемости с первого дня — нельзя сначала «попробовать на молодых пользователях», а потом разобраться с остальными.
Что внутри IARA: governance без бюрократии
IARA решает проблему, с которой сталкивается любая компания, масштабирующая LLM: как дать командам свободу экспериментировать и одновременно не потерять контроль над тем, что модели говорят клиентам или обрабатывают внутри.
Платформа закрывает несколько задач одновременно:
| Задача | Что делает IARA |
|---|---|
| Контроль доступа | Разграничение, какие команды работают с какими моделями |
| Аудит | Логирование запросов и ответов для регуляторной отчётности |
| Управление промптами | Версионирование и согласование системных промптов |
| Оценка качества | Метрики точности и безопасности ответов до выхода в прод |
Для продуктолога важный вывод: governance нужно проектировать как продукт для внутренних пользователей (разработчиков), а не как набор запретов сверху. Иначе команды будут его обходить.
Пошаговая логика внедрения: что можно повторить
Из кейса Itaú вычленяется воспроизводимая последовательность шагов.
Шаг 1. Определить контуры. Клиентский и внутренний ИИ — разные продукты с разными требованиями к точности, латентности и аудиту. Проектируйте их отдельно с самого начала.
Шаг 2. Начать с governance, а не с фич. Прежде чем запускать ia.i для клиентов, Itaú выстроил IARA для команд. Это контринтуитивно, но именно это позволило масштабировать без остановок на «а как нам теперь это контролировать».
Шаг 3. Встроить оценку качества в пайплайн. Не «проверим перед релизом», а автоматические метрики на каждом этапе: точность, безопасность, соответствие политикам. В регулируемой среде это обязательно, в нерегулируемой — просто хорошая практика.
Шаг 4. Распределить ответственность по командам. Центральная платформа задаёт правила, продуктовые команды отвечают за результат своих моделей. Это снимает узкое горлышко «одной ИИ-команды на всю компанию».
Шаг 5. Масштабировать горизонтально с первого дня. Архитектура ia.i рассчитана на всю клиентскую базу, а не на MVP-сегмент. Это дороже на старте, но дешевле при росте.
Где это ломается
Самая частая точка отказа при копировании этого подхода — попытка запустить клиентский интерфейс до того, как готова внутренняя платформа. Команды начинают с ia.i-аналога, быстро получают проблемы с качеством ответов, и тратят следующие полгода на ретрофит governance поверх уже работающей системы.
Вторая проблема — governance как отдел, а не как платформа. Если IARA — это комитет людей, которые согласовывают промпты вручную, скорость разработки падает до нуля. Автоматизация проверок обязательна.
Третья — недооценка языковой специфики. Itaú работает с бразильским португальским, включая финансовый жаргон и региональные особенности. Для российского рынка аналогичная проблема: базовая модель требует дообучения или тщательного промпт-инжиниринга под локальный контекст.
Что попробовать дальше
Если вы строите LLM-продукт в регулируемой среде, следующие шаги после изучения кейса Itaú:
- Посмотреть на open-source governance-инструменты: MLflow для версионирования моделей, Langfuse для трейсинга LLM-запросов.
- Спроектировать внутренний «чеклист выхода в прод» для LLM-фич — аналог IARA в минимальной форме.
- Протестировать разделение клиентского и внутреннего контуров на уровне системных промптов, прежде чем строить отдельную инфраструктуру.
FAQ
Что такое ia.i в контексте Itaú?
ia.i — это conversational interface (разговорный интерфейс) банка Itaú для клиентов. Он позволяет задавать вопросы о банковских продуктах и операциях на естественном языке вместо навигации по стандартным меню.
Что делает платформа IARA?
IARA — внутренняя governance-платформа Itaú для команд, разрабатывающих ИИ-продукты. Она управляет доступом к моделям, ведёт аудит-логи, контролирует версии промптов и оценивает качество ответов до выхода в продакшн.
Почему governance нужно строить до запуска клиентского интерфейса?
Без governance-платформы команды не могут контролировать качество и безопасность ответов модели в масштабе. В регулируемых секторах (банки, медицина) ретрофит контроля поверх работающей системы значительно дороже и рискованнее, чем проектирование с нуля.
Применим ли подход Itaú для небанковских продуктов?
Да. Разделение клиентского и внутреннего контуров, встроенная оценка качества и распределённая ответственность команд — универсальные паттерны для любого LLM-продукта с требованиями к точности и безопасности.
Какие инструменты можно использовать вместо IARA?
Для небольших команд подойдут open-source альтернативы: Langfuse для трейсинга и мониторинга LLM-запросов, MLflow для версионирования моделей и промптов, LangSmith для оценки качества ответов.
