Самый безопасный AI для банка — тот, которому не отдали данные
Когда обсуждают AI в банках, разговор обычно быстро сводится к выбору модели.
GPT? Gemini? Claude? Своя?
Мне кажется, это уже не самый интересный вопрос.
Гораздо важнее другой: Где вообще должна выполняться каждая AI-задача?
Новые Android-инструменты постепенно позволяют выбирать между локальной моделью на устройстве и облаком.
И вот здесь архитектура становится интересной.
Представим запрос клиента: Найди тот платеж за гостиницу в Турции. Кажется, около 80 тысяч.
Совсем необязательно отправлять историю операций в LLM.
На телефоне можно разобрать запрос: страна = Турция категория = гостиница сумма = 70–90 тыс.
А поиск выполнить обычным банковским API.
Получается:
User ↓ On-device LLM ↓ Structured query ↓ Bank API
Историю платежей модель вообще не увидела.
И это хороший принцип.
Я бы разделял AI-задачи примерно так:
PII extraction → ONLY ON DEVICE
Классификация транзакций → PREFER ON DEVICE
Поиск по истории → PREFER ON DEVICE
FAQ → CLOUD
Сложный reasoning / RAG → BANK AI CLOUD
То есть вместо одной большой LLM появляется AI Router:
On-device <- AI Router -> Bank
И внезапно качество AI-архитектуры определяется не только тем, что модель умеет.
Но и тем, какие данные мы сумели ей не показать.
Для банков это особенно важно. Потому что самый дешевый способ защитить чувствительные данные — не отправлять их туда, где они вообще не нужны.
Мы долго жили с принципом: API-first.
Возможно, следующим архитектурным принципом станет: Local-first AI.
· 18.08
Лучше если при local ai нет из местной сети совсем выхода наружу, а то это бесполезно. Примером может служит десятки взломов через митоз и прочие модели её уровня.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён