Телеграм канал «Клуб CDO»

To whom it may consern.

Финтех — это всегда баланс технологий и доверия. Поэтому внедрение ИИ в банки и финансовые проекты — одна из самых острых тем. Кто проверяет ИИ-помощников и алгоритмы, которые получают доступ к самым чувствительным данным?

Мы спросили об этом Максима Григорьева, генерального директора Ассоциации ФинТех. В первой части интервью — о том, как банки выстраивают систему ответственности и где проходит та самая красная линия, за которую ИИ пускать нельзя.

➡️ Клиенты не доверяют ИИ ключевые решения, несмотря на весь потенциал технологии. В чем причины и можно ли преодолеть этот барьер?

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

Накопился и прикладной опыт. В финансовом секторе мы протестировали 12 реальных сценариев с ИИ-агентами. Это важный шаг к пониманию, где технология полезна, а где нужен дополнительный контроль.

Недоверие направлено не на ИИ как таковой, а на его «черный ящик» — непрозрачность решений и «серую зону» ответственности. Клиенту важно знать, кто отвечает за результат и как его можно оспорить.

Преодолеть этот барьер помогает развитие объяснимого ИИ, гибридные контуры «ИИ + человек» с правом последнего слова, а также песочницы и рабочие группы по этике, где формируются общие правила игры.

Только сочетание технологий и прозрачных процессов ведет к осознанному доверию.

➡️ Если ИИ-агент действует автономно, кто несет ответственность за этичность его решений?

Алгоритм — это инструмент, а не субъект принятия решений. Задача банка — выстроить процессы так, чтобы использование ИИ было управляемым и прозрачным.

Юридическая и операционная ответственность всегда остается за финансовой организацией.

Этичность закладывается еще на этапе проектирования, но проверяется и в эксплуатации. В отрасли уже складывается типовой процесс аудита:
1️⃣ Дизайн-ревью, где фиксируются цели модели.
2️⃣ Аудит данных на предмет смещений
3️⃣ Валидация модели с помощью стресс-тестов.

После запуска действует пост-контроль: мониторинг «дрейфа» модели и анализ жалоб.

Для чувствительных кейсов создаются этические комитеты. Даже при 100% автоскоринге сохраняются гарантии: канал оспаривания и эскалация сложных случаев на человека.

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

➡️ Генеративный ИИ склонен «галлюцинировать» — можно ли внедрять его в финтех? Как решить эту проблему, если тотальная проверка человеком убивает выгоду?

Технологию внедряют не в критичных процессах выдачи денег, а там, где ИИ ускоряет эксперта, не принимая необратимых решений. Это:
⚪️ассистенты операторов,
⚪️аналитика,
⚪️комплаенс.

Риски «галлюцинаций» минимизируются технически:
▶️Подход RAG с опорой только на верифицированные данные
▶️Двухконтурные проверки «ИИ — правила — человек»,
▶️Жесткое ограничение домена знаний модели и метрики достоверности: если система не уверена, она просто передает задачу специалисту.

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

И да, 100% ручная проверка действительно вредна — мы переходим к модели выборочного контроля, пропорционального уровню риска.

В следующий раз поговорим о безопасности в ИИ-разработке и о том, где проходит грань автономности ИИ.

#голос_AI
Подписывайтесь на AI Inside в Max | ВКонтакте

Нет более ценного приобретения, чем утраченные иллюзии (c) ada

Похоже, OpenAI готовит не очередную версию, а полноценный перезапуск архитектуры.

Что известно из утечек:

• Новая база GPT-5.5 - это не тюнинг старого, а полностью новый фундамент после ~2 лет разработки.

• Мышление стало “человечнее” Модели меньше «тупят по шаблону» и лучше понимают намерение без лишних объяснений.

• Омнимодальность из коробки Текст, изображения, возможно аудио и видео — всё в одной системе без костылей.

Фокус смещается: от ответов → к выполнению задач и автономной работе (все пилят агентов).

• Длинные горизонты мышления Сложные задачи, многошаговые процессы, долгий контекст - это ключевая ставка.

То, что раньше требовало сложных промптов - теперь работает «из коробки».

Ценовая война на подходе На фоне слухов о дорогих конкурентах OpenAI может демпинговать ради захвата рынка.

Релиз уже близко.

В AI-аренах уже мелькают первые генерации - похоже, тесты идут полным ходом.

https://x.com/pankajkumar_dev/status/2040670839624908816

Дайджест статей

📰 The Missing Context Layer for AI Agents Over Business Data
🔗 https://medium.com/wrenai/the-missing-context-layer-for-ai-agents-over-business-data-03849b72f73d
💡 Вывод: Авторы Wren Engine переосмыслили семантический слой как «контекстный движок» для AI-агентов над бизнес-данными — аргумент в пользу того, что проблема NL→SQL не в модели, а в отсутствии правильного контекстного слоя между агентом и данными. (по метаданным — paywall)

📰 SQL Is Quietly Taking Over Data Engineering — Again
🔗 https://medium.com/towards-data-engineering/sql-is-quietly-taking-over-data-engineering-again-1dec44ca2c7d
💡 Вывод: SQL возвращается как де-факто стандарт современной data engineering через dbt, DuckDB, MotherDuck и SQL-first платформы — Python-пайплайны уступают место SQL там, где раньше его считали недостаточным. (по метаданным — paywall)

📰 Data Gravity и отравление выборки
🔗 https://habr.com/ru/companies/otus/articles/1012868/
💡 Вывод: Три системные угрозы ML-проектов — инерция данных (Data Gravity), намеренное и случайное отравление выборки (Data Poisoning по OWASP ML02:2023) и эффект матроса (ложные корреляции) — не решаются ростом объёма данных; решаются они версионированием, статистическим мониторингом и отношением к данным как к инженерному артефакту, а не бесплатному ресурсу.

📰 Лучшие YouTube-каналы по Data и Product Analytics
🔗 https://habr.com/ru/articles/1018610/
💡 Вывод: Подборка каналов (Alex The Analyst, Luke Barousse, Amplitude, Reforge и др.) — материал уровня «начинающий аналитик ищет что посмотреть», для CDO-аудитории ценности почти нет.

📰 Data as Code на практике: ArchDB
🔗 https://habr.com/ru/articles/1018586/
💡 Вывод: ArchDB — open-source DSL для декларативного описания схем БД с модульностью, множественным наследованием шаблонов и контролем версий; практически применим для команд, у которых схема базы живёт в Confluence и устаревает быстрее, чем обновляется — переход с DBML потребует минимальных правок.

📰 BI-аналитика или Excel: где вести аналитику компаниям?
🔗 https://habr.com/ru/articles/1018058/
💡 Вывод: По данным «КОРУС Консалтинг», 43% компаний до сих пор строят аналитику в Excel — статья описывает типичный путь к BI через боль с актуальностью данных, ошибками формул и временны́м долгом на сбор отчётности; реальный кейс — сокращение времени на аналитику с 15–20 до 2–3 часов в неделю через Yandex DataLens с окупаемостью за 4 месяца.

📰 OLAP-кубы в финансах: превращаем бюджетирование в управляемую систему
🔗 https://habr.com/ru/articles/1017470/
💡 Вывод: Статья чётко артикулирует разницу между «личной автоматизацией» (Power Pivot) и корпоративной аналитической инфраструктурой (OLAP): четыре сценария — многоверсионное планирование, консолидация ЦФО, двунаправленное планирование и скользящие прогнозы — реализуемы только на OLAP-платформе, а не в Excel, и именно это меняет роль финансиста с «составителя отчётов» на аналитика.

📰 Как стать аналитиком данных и сколько можно зарабатывать
🔗 https://habr.com/ru/companies/habr_career/articles/1017412/
💡 Вывод: Медианная зарплата дата-аналитика в России — 171 тыс. руб., сеньор получает 283 тыс., лид — 380 тыс.; рынок перегрет кандидатами с сертификатами без практики — по словам руководителя аналитиков Яндекса, рабочий путь в профессию: применять анализ данных там, где уже работаешь, не ждать «правильного» первого места.

📰 ML/AI в системе мониторинга: прогнозирование и предотвращение инцидентов
🔗 https://habr.com/ru/companies/sberbank/articles/1015336/
💡 Вывод: Сбер описывает production-реализацию ML predict-модели с горизонтом 15 минут на инфраструктурных, прикладных и бизнес-метриках — 80% точности достаточно для практического применения, модель обучается на ноутбуке при наличии 5 недель исторических данных, но требует переобучения минимум раз в квартал при изменении инфраструктуры или бизнес-паттернов.

📰 Reference Data Management по-русски: НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/

💡 Вывод: В российской практике НСИ исторически стало означать RDM + часть MDM + элементы DQ в одном флаконе — это создаёт ошибочные ожидания от систем и приводит к выбору «универсального» решения, которое делает всё, но плохо; правильный подход — разделить задачи и подбирать инструмент под каждую.

На прошлой неделе послушал доклад Анны Байдиной из Revolut - технического лидера их voice team. Тема: dialogue management в голосовых агентах. Казалось бы, нишевая история. На практике - хороший срез того, где реально ломается большинство голосовых продуктов.

Первый инсайт, который стоит зафиксировать: голос и текст - разные домены не по UX, а по физике. В текстовом чате лишние 3–4 секунды на ответ - нормально. В голосе те же 3–4 секунды - руинированная сессия и желание попросить живого оператора. Revolut ориентируется на P50 latency < 2 секунд. Это не KPI, это порог между "работает" и "не работает".

Второй момент: большинство команд, которые строят голосовых агентов, думают что задача - это STT + LLM + TTS. Сложили три модели — готово. Но есть четвёртый слой, без которого первые три не имеют смысла. Это dialogue management.

Что это такое? Это слой управления разговором, который решает один вопрос: сейчас говорить или слушать? Если STT — это уши, LLM — мозг, TTS — рот, то dialogue manager — это личность агента. Он определяет, перебивает ли агент пользователя, отвечает ли на правильный вопрос, или зависает в паузе и теряет нить.

Конкретный пример из доклада: пользователь говорит "я хочу купить... [пауза] ...пиво на 150 человек". Без dialogue management агент слышит паузу после "купить", решает что фраза закончена, отвечает на неполный запрос. С dialogue management - понимает, что пауза внутри фразы, ждёт конца, отвечает по существу.

Технически это решается через turn-taking - механизм определения конца реплики пользователя. Простое решение: VAD (Voice Activity Detector) + таймер. Молчание 700 мс — конец хода. Проблема: 700 мс из бюджета в 2 секунды — это огромная цена. Плюс ложные срабатывания на паузы внутри фраз.

Более сильное решение — аудионативные модели типа SmartTurn. Они используют те же сигналы, которые использует человек в живом разговоре: падение питча, снижение энергии, замедление ритма речи. Transformer-архитектура (encoder от Whisper) + классификатор. Быстрее и точнее VAD-based подхода. Revolut использует его в продакшене как основной механизм, с VAD-based fallback на 2 секунды.

Ещё одна деталь, которую легко пропустить: Revolut не смог просто переиспользовать свой существующий чатбот LLM внутри голосового агента. Архитектурно они сделали отдельный LLM + два вызова к chatbot API для получения ответов — именно чтобы вписаться в латентный бюджет. То есть задача оказалась не "взять готовый AI и добавить голос", а переосмыслить всю цепочку под жёсткое latency constraint.

Это честная инженерная история: не про то какая модель умнее, а про то как архитектура определяет что вообще возможно.


https://www.youtube.com/watch?v=onIFwG-5tuE