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

🚀 Открываем приём заявок на Лето с AIRI 2026!

Юбилейная Летняя школа по искусственному интеллекту пройдёт в Первом университетском лицее имени Н.И. Лобачевского при МГУ в городе Усть-Лабинск, Краснодарский край. Даты проведения — с 21 июля по 4 августа.

На школе вы сможете лично пообщаться с известными учёными в области ИИ и найти единомышленников, зарядиться вдохновением и получить новые знания для будущих исследований. В программе — лекции, семинары, постерная сессия, работа над проектами и, конечно, внеучебные активности.

Подать заявку на участие можно по ссылке до 24 мая включительно.

Обучение, питание и проживание обеспечивают организаторы — на вас только транспортные расходы.

Подавайте заявки и делитесь постом с друзьями и коллегами!

ИИ-риск это не отдельная категория в risk register. Это сквозной слой через всю компанию. APRA (Австралийский регулятор) в конце 2025 они провели deep-dive по крупнейшим игрокам, в апреле 2026 опубликовали выводы. Главный - ИИ внедряется быстрее, чем созревает управление им. Советы директоров с энтузиазмом одобряют слайды от вендоров, но не имеют ни грамотности, ни инструментов задать правильный вопрос. Кибербезопасность не успевает за новой поверхностью атак: prompt injection, утечки через интеграции, манипуляция автономными агентами, identity-management, не рассчитанный на нечеловеческих акторов.

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

Минимум, который APRA ожидает выстроить:

• Нормативные рамки: политики, стандарты, руководящие принципы и линии отчётности
• Ответственность за весь жизненный цикл ИИ — от проектирования до вывода из эксплуатации
• Инвентарь моделей и use-cases
• Человек в петле для высокорисковых решений
• Обучение сотрудников

Главный месседж APRA - перестаньте относиться к ИИ как к очередной технологии. Это другой класс систем: вероятностный, обучающийся, деградирующий со временем, с нечеловеческой агентностью. Sample-based аудит здесь не работает. Нужен непрерывный мониторинг и интегрированная гарантия по нескольким доменам сразу.

В общем следует ожидать больше регулирования и надзора.

https://www.apra.gov.au/apra-letter-to-industry-on-artificial-intelligence-ai

Anthropic научил агентов «спать»

https://zenvanriel.com/ai-engineer-blog/claude-code-autodream-memory-consolidation-guide/

В новую эпоху GenAI и LLM данные стали еще более ценным и важным ресурсом от которого зависит качество работы агентов.

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

Раньше между сырой таблицей и бизнес-решением всегда стоял аналитик. Он знал, что в этой таблице выручка считается без возвратов, а в той - с возвратами. Помнил, что финансовый квартал кончается 28-го, а не 30-го. Умел сказать «это число выглядит странно, давайте перепроверим». Его экспертиза компенсировала кривизну данных.

LLM-агент таким фильтром не является и не будет. Он не сомневается, не спрашивает коллегу, не перепроверяет. Берёт первую правдоподобную таблицу с похожим названием, пишет правдоподобный SQL, возвращает уверенный ответ. С отличным форматированием и без единого вопроса.

В этом разборе Modern Data 101 хорошо показаны пять точек отказа на тривиальном вопросе «какой был рост выручки в прошлом квартале»: определение выручки, определение квартала, выбор источника среди трёх таблиц с одинаковым именем, актуальность данных, аудируемость ответа. Аналитик прошёл бы через эту же мину и заметил все пять. Агент проедет, не моргнув.

Автор статьи, конечно, ведёт к своему продукту - он сооснователь компании, делающей платформу для тех самых дата-продуктов, которые он рекомендует строить. Понятный интерес. Но диагноз эпохи от этого интереса не зависит: проблема enterprise AI - это не проблема моделей. Модели за прошлый год выросли драматически, и проблема не ушла. Слой компенсации между данными и решением исчез, а слой источника никто не починил. Раньше можно было держать данные в относительно сыром состоянии, потому что между ними и реальностью была человеческая экспертиза. Теперь так нельзя.

Хороший повод вернуться к скучным разговорам про data quality, контракты, lineage и семантический слой. Не потому что это модно, а потому что без этого автоматизация превращается в автоматизацию ошибок.

https://moderndata101.substack.com/p/data-products-the-essential-context

📰 AI in Manufacturing 2026: Solutions, Benefits, Challenges *(по метаданным)*
🔗 https://dzone.com/articles/ai-in-manufacturing-2026-solutions-benefits-challe
💡 Обзорная статья DZone по AI-сценариям в производстве на 2026 год.
Вывод: Публичные кейсы AI в производстве упираются в одно: сенсорные данные есть, контекст процесса нет, ROI считается на пилоте, на проде не подтверждается. Для CDO/CTO вопрос не "что внедрить", а как закрыть data foundation — без него любой AI-проект превращается в дорогой PoC.

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


📰 Почему Big Data стек небезопасен по своей природе
🔗 https://habr.com/ru/articles/1030842/
💡 Разбор доклада Sheila A. Berta (Black Hat 2021): основные уязвимости Big Data-инфраструктур живут не внутри компонентов, а на стыках. HDFS, Spark, ZooKeeper, ClickHouse — каждый строился под "доверенную среду", и атака превращается в навигацию: ZooKeeper отдаёт карту кластера, Spark/YARN дают исполнение кода, дальше — данные.
Вывод: Attack surface растёт быстрее архитектуры; безопасность отдельных сервисов не работает без единой модели доверия между слоями и регулярной чистки "цифрового мусора" (старые пайплайны, реплики, забытые доступы) — иначе в какой-то момент данных становится больше, чем контроля.

📰 Почему 70% BI-систем не окупаются: 5 фатальных ошибок
🔗 https://habr.com/ru/articles/1027986/
💡 Пять типичных провалов: ожидание "магической кнопки", культ красивых графиков, отсутствие data quality, слепое исполнение запросов вместо диалога с заказчиком, отсутствие версионирования дашбордов.
Вывод: BI — зеркало бизнеса, а не его хирург; окупаемость появляется только при чистых данных, простых дашбордах под конкретный бизнес-вопрос и регламенте на каждый отчёт (владелец, версии, аудит). Без этого получаешь 200 дашбордов "Отчёт_новый_финальный_v15" с расхождениями 20% по одному и тому же KPI.

📰 Управление данными в ERP-проектах на основе DAMA-DMBoK
🔗 https://habr.com/ru/articles/1028864/
💡 Обзор: 11 областей знаний DAMA-DMBoK (от моделирования и качества до руководства и метаданных) ложатся на пирамиду Питера Айкена и фазы ERP-внедрения. Управление данными — отдельный бизнес-процесс уровня закупок и финансов, не разовая активность.
Вывод: DMBoK — рабочая карта для ERP-проектов, но порядок применения важнее охвата: фундамент (моделирование, хранение, качество) → метаданные и архитектура → governance. Попытка начать с governance без чистого слоя 1–2 даёт красивые регламенты на грязных данных.

📰 A "meshy" approach to Data: Enabling 100+ teams to build Data Models (Monzo)
🔗 https://monzo.com/blog/a-meshy-approach-to-data
💡 Monzo перестроил dbt-warehouse (12 000+ моделей, 100+ команд) на трёх принципах: opinionated стандарты, формализованные interfaces между командами, автоматизация в CI вместо ручного gatekeeping. Слои landing → normalised → logical → presentation, межкомандный обмен — только через явно объявленные контракты. Первые результаты — ~40% снижение стоимости warehouse и ~25% ускорение поставки данных в ряде доменов.
Вывод: При масштабе data mesh централизованное владение не работает, но и анархия тоже — выход в том, чтобы перенести "правильность" в инструменты (model-gen из YAML, CI-проверки на unique key, freshness, инкрементальность). Это самый трезвый кейс по data mesh за последний год: не манифест, а архитектура.

📰 DuckLake 1.0: Data Lake Format with SQL Catalog Metadata
🔗 https://www.infoq.com/news/2026/05/ducklake-sql-catalog/
💡 DuckDB Labs выпустили production-ready формат лейкхауса, хранящий метаданные таблиц в SQL-базе, а не россыпью файлов в object storage (как Iceberg/Delta/Hudi). Главные фичи — data inlining (мелкие insert/update/delete пишутся прямо в каталог, без small files), сортировка, bucket-партиционирование, deletion vectors совместимые с Iceberg.
Вывод: Серьёзный challenger Iceberg для команд, которым критичны быстрые мелкие записи и простая операционка; компромисс — SQL-каталог это и сила (скорость), и новая точка отказа (ещё одна БД в архитектуре). Для on-prem и средних объёмов "лейкхаус из коробки" может оказаться дешевле и быстрее всей экосистемы вокруг Iceberg.

вот так надо делать release notes 🙂 это просто красиво 🙂

https://www.youtube.com/watch?v=6dIwFoQ0eVg