Главное не в AI-агенте#
Cloudflare построила новый внутренний стек данных вокруг идеи, что «как сделано» не менее важно, чем «что сделано». Town Lake дает сотрудникам единый SQL-слой поверх разрозненных операционных данных, а Skipper добавляет к нему интерфейс на естественном языке.
Важная часть здесь не в том, что Cloudflare добавила AI-агента. Важная часть — слой под ним. Cloudflare пишет, что сначала ей пришлось сделать данные находимыми, доступными по правам, проверяемыми, аудируемыми и пригодными для запросов между системами. Только после этого агенту на обычном английском можно было доверять ответы на внутренние вопросы.
Это практичный урок для security operations и оценки privacy-рисков. AI-интерфейс поверх хаотичных данных не исправляет хаос. Он может просто ускорить его.
Что именно изменила Cloudflare#
Cloudflare описала два внутренних инструмента: Town Lake, единую платформу аналитики данных, и Skipper, AI-агента для работы с данными поверх этой платформы.
Исходная проблема — расползание данных. По словам Cloudflare, операционные данные жили в production-базах, кластерах ClickHouse, потоках Kafka, бакетах Google Cloud, наборах BigQuery и длинном хвосте пайплайнов. Даже простой бизнесовый или операционный вопрос мог требовать знания нужной системы, нужных учетных данных, нужного языка запросов и понимания, откуда пришел ответ: из сэмплированных данных, свежих данных или устаревших данных.
Эта разница критична. Cloudflare приводит пример с дашбордами и биллингом. Downsampling может быть разумным, если дашборд должен быстро загрузиться. Но это плохой дефолт, когда считается использование для счета. Та же логика работает в расследованиях: сэмплированные данные помогают на этапе разведки, но опасны, если кто-то воспринимает их как полное доказательство.
Town Lake — попытка Cloudflare накрыть весь этот ландшафт одной поверхностью для запросов. Компания пишет, что использует Apache Trino: один SQL-запрос может объединять данные из разных систем, например Postgres, ClickHouse и таблиц Iceberg на R2, без предварительной материализации всего в еще одну систему.
Для более «холодных» и «теплых» данных Cloudflare описывает Apache Iceberg на R2. Iceberg дает таблицеподобное поведение поверх объектного хранилища: эволюцию схемы, time travel, эволюцию партиций и compaction по мере старения данных. В описании Cloudflare свежие данные об использовании можно хранить в более детальном разрешении, а старые — уплотнять до более грубых интервалов, сохраняя возможность запросов.
Cloudflare также называет DataHub как слой метаданных. Там живут описания таблиц и колонок, владельцы, lineage и термины глоссария. Это не декоративный каталог. Для такой системы метаданные — часть control plane. Если пользователи не понимают, что означает таблица, кто ей владеет и чем она наполняется, единый слой запросов все равно может выдавать уверенные, но неверные ответы.
Skipper расположен поверх Town Lake. Заявленная цель Cloudflare — дать авторизованным сотрудникам возможность задавать вопросы обычным английским и получать корректные, аудируемые ответы без знания SQL. Примеры в источнике идут от вопросов по выручке и биллингу до security-запросов, например событий Bot Management scoring из конкретного ASN.
Почему это важно для security operations и privacy-рисков#
Пост Cloudflare хорошо показывает паттерн, с которым сталкиваются многие крупные организации: чем больше телеметрии производит компания, тем сложнее безопасно ее использовать.
Cloudflare пишет, что обрабатывает более миллиарда событий каждую секунду и работает более чем в 330 городах в 120+ странах. На таком масштабе операционная проблема — не только хранение. Нужно понимать, каким данным можно доверять для какого решения.
Security operations зависят от этой границы. Аналитику, который смотрит abuse-паттерны, bot-сигналы, метаданные аккаунтов или контекст поддержки, нужен не просто доступ к «данным». Ему нужны свежесть, lineage, retention, статус сэмплирования и границы прав. Иначе результат запроса превращается в ложный якорь.
Privacy-риск движется в ту же сторону. Единая аналитическая платформа может сократить хаотичный обмен учетными данными и доступы «по знакомству». Но она же концентрирует чувствительную видимость в одном мощном интерфейсе. Ответ Cloudflare, согласно посту, — встроить governance: автоматическое обнаружение personally identifiable information, чувствительные таблицы с закрытым доступом по умолчанию, аудируемый доступ и временные grants.
Именно эти контроли отделяют «внутреннего AI-помощника» от «быстрого пути к избыточному раскрытию». Skipper безопасен лишь настолько, насколько безопасны модель авторизации и метаданные под ним. Если агент может ответить на вопрос, платформа все равно должна доказать, что пользователь имел право его задать, источник данных подходил для ответа, а сам ответ можно отследить.
Здесь сходятся безопасность open source и безопасность внутренних платформ. Apache Trino, Apache Iceberg и DataHub — не магические щиты. Это компоненты в модели доверия. Их ценность зависит от того, как вокруг них реализованы правила доступа, владение таблицами, lineage и операционные проверки.
Что проверить перед копированием такой модели#
Полезный вопрос — не «нужно ли каждой компании строить то же самое?». Большинству не стоит копировать архитектуру Cloudflare один к одному. Полезнее спросить, что должно быть правдой, прежде чем единый слой данных или AI-агент для данных станет достаточно безопасным, чтобы на него опираться.
Начать стоит с классов данных. Какие вопросы требуют несэмплированных данных? Где допустимы approximate или downsampled данные? Биллинг, incident response, проверка fraud, юридические и compliance-задачи обычно требуют более строгого обращения, чем исследовательские дашборды.
Затем проверьте identity и access. Единый интерфейс резко повышает цену слабых permissions. Система должна понимать, кто спрашивает, к какой группе относится этот человек, какая задача оправдывает доступ и когда этот доступ истекает. Постоянный широкий доступ — типичный failure mode.
Следом идет качество метаданных. Если владельцы таблиц, описания, lineage и retention-правила отсутствуют или устарели, слой на естественном языке не закроет этот разрыв. Он может его спрятать. Пользователь задаст простой вопрос и получит гладкий ответ, построенный на неверно понятых данных.
Для AI-агентов auditability — жесткое требование. Платформа должна сохранять, что спросили, какие источники использовались, какой запрос был выполнен, какие permissions проверялись и какой ответ вернулся. Без этой цепочки сложно отлаживать плохие ответы или расследовать неправомерный доступ.
Практические операционные проверки:
- Определите, какие datasets сэмплируются, задерживаются, уплотняются или считаются approximate.
- Пометьте чувствительные таблицы и колонки до того, как открывать их через широкие инструменты запросов.
- Требуйте ownership и lineage для критичных datasets.
- Используйте time-bounded grants для исключительных доступов.
- Логируйте prompts агента, сгенерированные запросы, исходные таблицы и возвращенные outputs.
- Проверяйте, отказывает ли агент на вопросы, на которые пользователь не смог бы ответить через прямой SQL.
Это тот же урок, что и в недавней работе по supply chain: артефакты помогают только тогда, когда становятся частью операционной практики. См. также заметку GigaTap об апрельском сигнале OpenSSF: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational
Чего не стоит преувеличивать#
Пост Cloudflare — рассказ об архитектуре, а не независимый security audit. Он объясняет, что компания построила и зачем, но не доказывает, что каждое permission-правило, каждый PII-детектор, каждая запись метаданных и каждый AI-ответ в production корректны.
Не стоит читать этот пост как доказательство, что аналитика на естественном языке автоматически безопасна на большом масштабе. Источник поддерживает более узкий вывод: Cloudflare понимала, что AI-агенту для данных нужна управляемая платформа под ним, и спроектировала Town Lake вокруг единого доступа, метаданных, lineage и auditability.
Это все равно важный сигнал. Многие организации пытаются добавить AI на уровне интерфейса, оставляя качество данных и контроль доступа «чьей-то чужой проблемой». Разбор Cloudflare показывает обратный порядок: сначала привести слой данных в связное состояние, потом давать большему числу людей возможность задавать вопросы.
Компромисс никуда не исчезает. Централизация снижает хаос, но создает ценный control plane. Если сервис доступа, каталог метаданных или policy-слой агента ломается, blast radius будет больше, чем у отдельного дашборда или учетных данных к базе.
Тем, кто оценивает похожие системы, важнее смотреть не на демо агента, а на операционные проверки. Спрашивайте не только «что запустили», но и «как это построено». В ответе должны быть data lineage, срок действия permissions, обработка sensitive data, статус сэмплирования и audit trails. Если эти части описаны туманно, AI-слой — не инновация. Это множитель риска.