Как компании монетизируют данные через API?

Они превращают их в сервис: не просто передают файлы или выгрузки, а дают клиентам удобный, контролируемый доступ к данным. Клиенты сами подключаются к API и забирают нужные данные в нужном объеме, платя за запросы или подписку.

С помощью API компания превращает данные в продукт с интерфейсом. Набор данных стоит денег, но работающий на этом наборе DaaS создает добавленную стоимость и за него вам заплатят заметно больше.

Откуда дополнительная ценность?

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

2. Сделайте за клиента обработку, фильтрацию, агрегацию и тогда сможете брать за данные больше. Сильно больше.

3. Можно упаковать одни и те же данные в разные API и продавать их разным сегментам по разной цене. Сырые аналитикам, агрегированные SMB-клиентам, скоринг банкам.

4. Можно создавать наборы API под конкретные ниши: например, API для финтеха, API для ритейла и так далее. Появляется возможность партнериться и получать процент от использования.

5. С API видно, какие данные востребованы, когда пики спроса, кто потребляет больше всего и как меняется поведение. Это позволяет адаптировать продукт, улучшать структуру, выявлять новые точки роста.

Получается, что API создает уровни ценности, даже если изначально у вас только один набор данных.

Какие данные подходят для такой модели?

Продажа данных по API не дает обойти законы вроде GDPR или HIPAA, но есть способы легально продавать производные от персональных данных. Например: «оценка кредитного риска по сегментам», «популярность товаров по регионам», «обобщенные демографические профили».

Reddit продает доступ к пользовательскому контенту для обучения ИИ, но через API, который отдает посты без привязки к конкретным людям.

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

Experian продает через API кредитные скоринги и риск-профили, выдавая только баллы и рекомендации без личных данных клиентов.

Продажа данных по API выгодна продавцам, чьи данные регулярно обновляются, а вот данные, не требующие постоянного доступа, лучше продавать сразу пакетами.

#деньги

Если ваш сайт посещают ИИ-боты, вы можете на этом заработать

Сегодня боты вроде OpenAI, Anthropic, Perplexity и других массово собирают данные для обучения моделей и формирования ответов, но:

- Не возвращают пользователей на сайты.

- Не платят владельцам контента.

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

Cloudflare предложила решение: монетизировать доступ ИИ-ботов к контенту сайтов.

Владелец сайта через панель Cloudflare выставляет цену за один запрос. Бот перед отправкой запроса указывает, готов ли платить, и подтверждает свою личность с помощью подписи. Если бот согласен заплатить, сервер возвращает данные и списывает платеж. Cloudflare собирает платежи и перечисляет их владельцу сайта.

Технология уже поддержана крупными игроками вроде Condé Nast, Associated Press и Reddit, а Cloudflare запустила решение в режиме закрытой беты. По сути, это первый шаг к полноценному рынку данных для ИИ, основанному на прозрачности и стандартных интернет-технологиях.

Reddit, кстати, показал пример: он уже продает свои данные Google, но параллельно судится с Anthropic за нелицензионное использование своих данных.

#ии #деньги

Можно продавать данные, чтобы покупатели получали из них инсайты, а можно сразу продавать инсайты

Разбираемся, как это так.

Model Context Protocols — способ превращать данные в готовые контекстные ответы прямо внутри бизнес-процессов.

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

Звучит невероятно, но это уже нон-фикшн. MCP меняет подход к монетизации: продавать можно не данные, а сразу действия на их основе, подсказки и решения.

В чем цимес?

Купили вы данные. Вот они лежат у вас мертвым грузом. Пару раз в неделю ими пользуется три сотрудника. Только один из этих трех умеет извлекать из данных инсайты, которые помогают больше заработать в моменте. Печально.

MCP решает проблему системно: подход избавляет покупателя от необходимости разбираться в данных и искать моменты, когда их применить.

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

Многие данные раньше вообще не удавалось монетизировать — слишком специфичные, сложные или кусочные. MCP делает их коммерчески пригодными: включает в сценарии, где они внезапно становятся ценными, потому что закрывают конкретные вопросы в конкретное время.

Как это реализуется технически?

1. Триггер

На стороне покупателя происходит событие (например, нажата кнопка «Подобрать ассортимент» или «Выбрать блюдо дня»), MCP фиксирует его и определяет нужные данные и инструменты.

2. Оркестрация

MCP запускает сценарий: собирает данные из источников, применяет к ним модели, бизнес-правила и экспертизу владельца.

3. Формирование и доставка ответа

MCP объединяет данные, интерпретирует по заданным правилам и возвращает готовый, понятный результат прямо в интерфейс пользователя (CRM, сайт, приложение) за доли секунд, скрывая всю кухню.

4. Монетизация

Каждый вызов MCP учитывается, и можно выставлять счет за готовые ответы, а не за общий доступ к сырым данным.

Пример

Когда кассир на экране выбирает опцию «Выбрать блюдо дня», MCP в фоне собирает необходимые данные: продажи за прошлую неделю, запасы на складе, погоду на завтра и отзывы клиентов.

Затем применяет бизнес-правила (например, не предлагать блюда, ингредиентов для которых мало на складе, и учитывать сезонность и популярность) и формирует готовое предложение: «Сегодня рекомендуем продвигать комбо с курицей и лимонадом — спрос высок, маржа максимальная».

Все это происходит за секунды, за кулисами, через облачный сервис, и кассир видит готовый совет прямо в своем интерфейсе, не зная и не думая о том, откуда и как пришли данные.

В таком подходе данные — не новая нефть, а сразу бензин. Причем сразу в баке, а не на заправке.

#деньги

Если друг оказался вдруг и не друг, и не враг, а дипфейк

Контур.Толк представили инструмент, который выявляет дипфейки прямо во время видеозвонков. Сервис уже работает в формате «один на один» и скоро будет доступен для конференций.

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

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

Инструмент уже тестируется крупнейшим российским банком.

Вы тоже можете подключить детектор дипфейков по запросу. Для этого нужно обратиться в службу поддержки Толка.

#ии #безопасность

OpenAI и AFT обучат 400 000 американских учителей работе с ИИ

OpenAI совместно с Американской федерацией учителей (AFT) запускают National Academy for AI Instruction — пятилетнюю программу, которая поможет 400 000 педагогам в США освоить ИИ и научиться применять его в школах. Это около 10% всех учителей страны.

OpenAI выделит на проект $10 млн, из которых $8 млн — прямое финансирование, а $2 млн — техническая поддержка, доступ к вычислительным мощностям и консультации.

В программе бесплатные курсы, мастер-классы и практика. В Нью-Йорке откроется флагманский кампус, а к 2030 году академия развернет сеть центров по всей стране.

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

#ии

Если вы тоже захотели себе решение на базе MCP

В Anthropic говорят о важности интеграции контекста в ИИ-решения:

Самые продвинутые модели все равно ограничены своей изоляцией от данных — они заперты в информационных силосах и легаси-системах.

Крупные игроки ИИ-индустрии и опенсорс-сообщества начали активно поддерживать MCP, видя в нем потенциально революционный инструмент для построения агентных систем на базе LLM.

В Microsoft опубликовали бесплатный курс по MCP для начинающих. С актуальным переводом на русский язык и примерами использования разных языков программирования.

В Google опубликовали бета-версию MCP Toolbox — опенсорсного инструмента, который помогает разработчикам быстрее, удобнее и безопаснее создавать приложения для работы с базами данных.

MCP Toolbox экономит время. Под капотом: запросы на естественном языке, автоматизация управления базами данных, контекстно-зависимый код, а также автоматизация настройки подключений, управления схемами и обработки ошибок миграции.

Забирайте, пользуйтесь, делитесь.

#ии #опенсорс

Как данные помогают бизнесу получать кредиты без твердого залога

В 40% случаев банки отказывают малому и среднему бизнесу по двум причинам: отсутствие залога и недоверие к отчетности.

В мае этого года Тун Юй из Имперского колледжа Лондона объяснил, как доступ к живым данным помогает малому бизнесу получать кредиты, снижает риски для банков и сокращает время одобрения заявок.

Open Banking — система, которая позволяет клиентам банков безопасно делиться своими финансовыми данными с другими банками, финтех‑компаниями и сервисами.

В чем идея?

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

Open Banking передает данные прямо c банковских счетов.

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

Как это работает?

На техническом уровне Open Banking — это API.

1. Компания дает согласие кредитору на доступ к данным.

2. Кредитор подключается через API к банку компании.

3. Кредитор получает данные в стандартизированном виде: история поступлений, платежей, задолженности, остатки.

4. Система анализирует данные и оценивает риск.

5. Если риск приемлемый, бизнес получает кредит, обеспеченный текущими активами.

Какой от этого всего эффект?

Система заработала в 2018 году.

В Великобритании 18% малого бизнеса использует Open Banking. Всего у системы 13 млн пользователей, включая физлиц.

Компании, использующие Open Banking, на 4 процентных пункта чаще получают кредит под текущие активы.

Банки сократили время рассмотрения заявок от малого и среднего бизнеса с нескольких недель до нескольких минут.

Модели скоринга с использованием Open Banking снизили кредитные потери на 20-40 % по сравнению с традиционными методами.

#деньги #исследования

В Slack без остановки сыпятся алерты, тесты уже месяц висят красными и непонятно, кто за что отвечает и что на самом деле важно

Нередко из-за хаоса в тестах дела у дата-команды идут даже хуже, чем во времена, когда они эти тесты еще не написали.

Штука в том, что данные — это сложно. Они не статичны и иногда меняются назад во времени. Источники данных — тоже сложные системы. Ну а люди вообще коллекционируют несовершенства.

Миккель Денгсё и Петр Янда вместе с дата-отделами сотен стартапов и компаний из Fortune 500 составили «Гайд по созданию высококачественных дата‑продуктов» для тех, кто устал от хаоса и хочет навести порядок в тестах, управлении качеством и инцидентами.

Если сжать его в 69 раз, то гайд объясняет, как:

1. Определить, какие данные действительно являются продуктами

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

Категории были большими и размытыми: «Маркетинг», «Продажи», «Продукт». Когда где‑то ломались данные, алерты сообщали, что сломался, допустим, «Маркетинг», но никто толком не понимал:

Что именно сломалось?
Насколько это критично?
Кто за это отвечает?
На какие бизнес‑процессы это влияет?

Проблемы диагностировали медленно, а решали с большим трудом.

Методично выделяя из больших продуктов вроде «Маркетинга» продукты поменьше, например, «Атрибуция маркетинга», в Aiven стали быстрее находить ошибки и понимать, кто за них отвечает.

2. Назначить ответственных и расставить приоритеты, чтобы сбои не были сиротами

Если попробовать присвоить максимальный приоритет вообще всему, то ни у чего вообще приоритета не прибавится. Так было в Lunar, где каждая команда считала свои данные самыми важными. Это мешало работе.

Каждая команда была права: ее данные — самые важные, но только для нее самой. Важность элементов системы не могут оценивать эти же элементы.

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

3. Выстроить тесты, которые ловят ошибки, а не шумят

В Google и Monzo на первых порах придавали огромное значение проверкам всех таблиц и столбцов. В результате получали сотни алертов, большинство из которых не имело вообще никакого значения.

Помогла смена стратегии: тестировать стали в первую очередь источники данных, которые влияют на все остальное. Шум стих, система стала надежнее.

Мораль: устранять ошибки в производных — вычерпывать воду, а исправить ошибки в источнике данных — залатать течь.

4. Не терять и быстро устранять инциденты

Пользователи Shalion следят за данными на дашбордах в реальном времени. Малейшая ошибка в данных сразу бьет по доверию клиентов сервису.

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

Угроза клиентскому доверию стала источником этого доверия. Снимаем шляпу.

5. Измерять качество данных не ради отчета, а ради пользы для бизнеса.

Метрики нужно поделить на «какая доля данных под контролем» и «какая доля проходит проверки». Сперва проверяйте, проверяете ли вы какие-то данные, а уже потом проверяйте эти данные.

Иначе появятся слепые пятна:

Если все данные, которые вы проверили, в порядке, это значит, что вы не проверили все те, которые не в порядке (если они есть, а они наверняка есть).

* * *

Гайд не привязывается к инструментам, а учит принципам. Подходит командам из 5 человек и большим отделам. Полезен, независимо от масштаба компании и зрелости дата-культуры.

Сохраните себе, расскажите коллегам.

Путь в тысячу ли начинается с найма Chief Data Officer. Или нет?

Николай Валиотти на «Сабстаке» рассказывает, что если вы хотите стать data driven, то первым делом нанимать CDO или Head of Data на фултайм — фатальная ошибка.

Разбираемся, почему так.

Многие нанимают дорогого CDO на ранней стадии, а спустя полгода все еще видят хаос: данные в Excel, KPI непонятны, отчеты на решения не влияют.

Почему?

Потому что высокие затраты стратегию не компенсируют готовность компании эту стратегию проводить в жизнь. Это как пытаться откупиться от ребенка подарками — ему на самом деле нужно ваше внимание, а не деньги.

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

В реальности проблемы компаний чаще всего не стратегические, а чисто организационные:

- Каждый департамент считает по‑своему.

- Никто не понимает, какие метрики на самом деле отражают успех.

- Отчеты формируются вручную.

- На подготовку слайдов у аналитиков уходят часы.

- К моменту обсуждения данные уже устаревают.

Смена стратегии тут не поможет.

Как быть?

Вместо того, чтобы на раннем этапе пытаться проработать стратегию работы с данными на 3 года вперед, нужно сфокусироваться на результате, который можно получить на следующей неделе.

Решение:

Привлечь Fractional Head of Data — временного управляющего, который не будет строить многолетних планов, а прямо сегодня наведет порядок и выстроит базовую работу с данными.

Это быстрее, дешевле и эффективнее.

Fractional Head of Data может быстро привести к маленьким победам, которые сформируют у команды веру в данные, как в источник правильных решений.

По сути, fractional‑подход позволяет получить одновременно архитектора и исполнителя, который быстро строит работающую систему, а не предлагает лишь ее чертеж в виде стратегии на 3 года.

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

Вывод:

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

#деньги #статьи

Теперь официально: вместо «уверенных пользователей ПК» работодатели ищут «уверенных пользователей ИИ»

В Сбере намерены нанимать на все ключевые позиции только кандидатов с навыками работы с искусственным интеллектом. Все уже трудоустроенные сотрудники тоже в обязательном порядке учатся работать с ИИ.

К специалистам первой линии ключевое требование — умение применять ИИ для эффективного решения повседневных задач. Каких — не уточняют. Это базовые навыки работы с нейросетями — о них спрашивают на собеседовании.

Специалистам аналитических и айти-направлений нужны более глубокие знания и интеграция ИИ в профессиональную деятельность. Для проверки на собеседованиях будут практические задания. Какие — не говорят. Также будут тестировать способность переписывать тексты и проверять факты при помощи нейросетей.

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

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

— Нас всех заменит ИИ?
— Нет, вас всех заменят люди, которые владеют ИИ.

#ии #исследования

Контекст важнее промпта

Тренер ставит новичку задачу: прыгнуть в длину на 8 метров. У того не получается. Тогда тренер в подробностях объясняет технику: как разбегаться, в какой момент отталкиваться, как группироваться и все такое. У того опять не получается.

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

В работе с LLM бывает так же: можно написать предельно точный и учитывающий все тонкости промпт, но если модели не хватает контекста, задачу она не решит.

И это работа для контекст-инженера.

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

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

Представьте, что ИИ просят назначить встречу на основе письма: «Привет, ты завтра свободен для быстрой встречи?»

Если у агента нет контекста, он видит только этот текст и отвечает формально и бесполезно: «Спасибо за сообщение. Завтра мне подходит. В какое время?»

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

Теперь сравните с агентом, у которого есть контекст:

- Он видит ваш календарь и знает, что вы заняты весь день.

- Считывает стиль общения из предыдущих писем.

- Знает, кто вам пишет.

- Имеет доступ к инструментам и может отправить приглашение на встречу.

В этом случае ответ будет таким: «Привет! Завтра я весь день занят, но в четверг утром свободен. Отправил приглашение — дай знать, если все окей».

Магия не в более умной модели или более хитром алгоритме. Она в предоставлении правильного контекста для задачи. Поэтому контекстная инженерия будет важна. Неудачи агентов — это не только неудачи модели, это неудачи контекста.

Сегодня в работе с ИИ куда важнее не то, что и как мы спрашиваем у модели, а что она уже знает и умеет в этот момент.

#ии

Качественные данные ≠ готовые для ИИ данные

В 2016 году аналитики IBM посчитали, что из-за некачественных данных экономика США теряет $3 трлн ежегодно. До 80% проектов по внедрению ИИ проваливаются из-за некачественных данных.

И сегодня все бьются над качеством данных. Но штука в том, что мы уже не в 2016 году, и сегодня этого недостаточно.

Ваши данные должны быть не только качественными в традиционном смысле, а готовыми к использованию в ИИ.

Самим качеством, кстати, можно пожертвовать.

В статья на Financial Times Маккензи Хоу из Atheni выдала такой пассаж:

Ждать идеальных данных — все равно что ждать, когда освободятся дороги, чтобы научиться водить.

Однако выводы в статье не такие однозначные:

Не стоит по полной вкладываться в ИИ, если ваши данные не готовы. Но и откладывать внедрение ИИ, сетуя на плохие данные, не стоит.

В чем разница между качественными данными и готовыми для ИИ данными?

Качественные данные — это про корректность. Готовые к ИИ данные — это еще и про релевантность, доступность и управляемость.

ИИ требует, чтобы данные не только были чистыми, но и легко встраивались в процессы.

Качественные данные — это данные, которые:

- Точные, полные, актуальные.

- Не содержат дубликатов и ошибок.

- Согласованы по форматам и источникам.

Такие данные подходят для отчетности, BI и аналитики.

Готовые для ИИ данные — понятие шире.

Помимо качества, готовые для ИИ данные должны:

- Быть релевантны конкретной задаче ИИ (подобраны под конкретный use case).

- Быть доступны в нужной форме и скорости (API, потоки, батчи).

- Быть интероперабельными и описанными (метаданные, словари).

- Учитывать правовые, этические и безопасностные требования.

- Постоянно обновляться и отслеживаться для предотвращения дрейфа данных.

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

Как подготовить данные для ИИ?

В Gartner сделали неплохой гайд по подготовке данные для ИИ.

1. Увязка данных с задачей ИИ

Подготовка начинается с увязки бизнес‑задачи с нужными источниками и атрибутами, включая поиск недостающих данных.

Для прогноза коррозии на буровых к датчикам добавляют десятилетние ряды погоды, химсостав воды и историю ремонтов.

2. Управление и соблюдение норм

Данные очищаются от персональной информации, снабжаются правилами использования и частотой обновления под конкретный сценарий.

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

3. Метаданные и контекст

Создается слой активных метаданных, который хранит происхождение, смысл и условия применения данных и управляет их выбором.

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

4. Автоматизация потоков

Разнородные данные очищаются, нормализуются и объединяются в сквозные конвейеры, дающие модели стабильный поток.

В агротехе данные с дронов и сенсоров приводят к общей сетке координат и времени, чтобы ИИ корректно интерпретировал их.

5. Валидация и контроль

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

В кредитном скоринге система замечает изменение поведения заемщиков и автоматически перестраивает данные и модель, чтобы сохранять точность прогноза.

Чистота — это прошлый век?

Чистить данные, конечно, нужно, но если раньше почистить их было достаточно, то теперь этого мало. ИИ требует данных, которые живут вместе с процессами компании, а не лежат чистенькие в хранилищах.

#ии

Парадокс Эрроу, и как он мешает торговать данными

Сперва разберемся, в чем суть парадокса.

На рынках данных возникает фундаментальная дилемма:

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

Выходит, что определить ценность данных до покупки нельзя, а раскрывать их заранее — опасно. Это создает замкнутый круг, описанный Кеннетом Эрроу еще в 1962 году для информационных товаров.

Очевидно, это сильно тормозит потенциально огромный рынок дата-маркетплейсов.

Какие есть решения?

1. Определение ценности без раскрытия данных

Представьте маркетплейс, где вы ищете данные для улучшения прогноза спроса. Файлы вам не дают, но показывают: если добавить этот набор в вашу модель, точность вырастет на 8 %.

Вы видите, какие признаки сработали и чем набор полезен именно для вашей задачи, при этом сами данные остаются закрыты. Это делают алгоритмы на стороне продавца — они выдают не сырой файл, а доказательство ценности. В итоге вы покупаете не вслепую, а понимая, что получите.

Такой подход уже тестируют, например, в прототипе DQSM, который встраивают прямо в маркетплейсы данных.

2. Временный доступ и нейрализатор из «Людей в черном»

Вы приходите на тот же маркетплейс и говорите агенту‑помощнику: «Посмотри вот эти три набора данных и скажи, какой из них реально подходит для нашей задачи».

Агент получает временный доступ, открывает данные, делает серию проверок и даже пробует построить несколько моделей. После этого он говорит: «Первый набор — слабый, второй ничего не добавляет, а третий дает хорошую прибавку, его стоит купить».

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

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

3. Data clean rooms

В этом подходе данные вообще не покидают контур владельца.

Вы формулируете вопрос или задачу: «постройте мне модель прогноза», «посчитайте пересечение наших клиентов», а расчет делается на стороне продавца. Вам возвращают не файлы, а результат — модель, набор коэффициентов или готовый отчет.

Именно так работают рекламные clean rooms Google и Meta: бренды видят аналитику по аудиториям, но не получают доступ к исходным данным пользователей.

Какие еще есть перспективы?

Помимо описанных подходов, исследователи обсуждают гибридные механизмы:

Объединение временного доступа с юридическими гарантиями через смарт‑контракты, а также создание стандартов описания наборов данных, которые позволят оценивать их ценность еще на уровне метаданных.

Правда со вторым вариантом беда — если сейчас мы не доверяем продавцу, боясь, что данные нам не подойдут, с чего бы нам вдруг доверять какому-то стандарту?

#деньги

Как начать думать про данные по-новому

В 2007 году консорциум The Green Grid для оценки энергоэффективности дата‑центров ввел новую метрику — PUE (Power Usage Effectiveness).

PUE = (общая энергия, потребляемая дата-центром) ÷ (энергия, идущая на айти-оборудование).

Внедрение PUE изменило индустрию: компании начали конкурировать за снижение PUE, повышая эффективность и снижая стоимость владения.

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

Знакомьтесь, DUE (Data Usage Effectiveness).

DUE = (объем данных, который используется для аналитики и принятия решений) ÷ (общий объем данных, который хранится в компании).

Если DUE = 0.25, это значит, что 75% данных организации лежат мертвым грузом.

Если PUE изменил то, как дата-центры думают об энергии, DUE может изменить то, как компании думают о своих данных.

DUE может стать цифровым показателем зрелости компании. Показатель можно будет указывать в отчетах об устойчивом развитии, а аналитики смогут сравнивать компании по эффективности работы с данными.

Повторяйте за большими ребятами, не стесняйтесь

Microsoft в отчетах по Sustainability и Responsible AI говорит о Data Value Ratio — проценте данных, которые активно используются в аналитике и ИИ‑моделях.

Splunk и Gartner истошно публикуют показатели dark data — по сути, это обратная метрика DUE: чем больше dark data, тем ниже эффективность использования.

Облачные провайдеры (AWS, Google Cloud, Azure) вводят KPI вроде Data Utilization и Active Data Sets, которые фактически оценивают DUE на уровне облачных клиентов.

Финансовые компании (JP Morgan, Capital One) используют метрику Share of actively governed data assets для оценки зрелости управления данными.

Это выгодно

McKinsey в исследовании The Missing Data Link показали простую вещь: ценность дает не количество данных, а умение работать с тем, что уже накоплено.

Когда компании превращают хаотичные массивы в понятные дата-продукты и повышают свой DUE, новые решения и инсайты появляются до 90% быстрее, а затраты на хранение и обработку падают на треть.

Оркам из «Варкрафта» нужно больше золота, а вам не нужно больше данных, вам нужен высокий DUE.

#деньги

Боится ли Америка Китая

Почти одновременно США и Китай опубликовали планы по развитию искусственного интеллекта. Нам кажется интересным не просто сравнить их между собой, но и сопоставить с трендами рынка, которые описаны на 340 страницах исследования Bond Capital, вышедшего в мае.

Поехали.

Битва при данных

И США, и Китай исходят из того, что вычислительные мощности можно нарастить за пару лет, а вот большие и качественные датасеты — нет.

США делают ставку на закрытую модель: строят собственные национальные наборы и минимизируют зависимость от внешних источников. Китай напротив — предлагает создать международные платформы и хранилища, где данные циркулируют по общим правилам.

Подход Китая, кстати, выливается в то, что у них пока лучше всех получаются маркетплейсы данных.

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

По мере роста ценности наборов данных борьба развернется не за алгоритмы, а за контроль над потоками данных и условиями их обмена.

Пока вы 7 раз отмеряли, кто-то уже отрезал

ИИ развивается быстрее, чем когда‑то интернет. Количество пользователей и разработчиков растет лавинообразно, а время между поколениями моделей сокращается.

План США буквально заточен под скорость: он убирает регуляторные барьеры, упрощает строительство дата‑центров и ориентируется на то, чтобы новые версии моделей выходили максимально быстро.

Логика проста: чем выше темп, тем быстрее собирается обратная связь и данные, которые нужны для следующего поколения моделей.

Китайский план тоже говорит о развитии инфраструктуры, но делает упор на долгосрочность и глобальную координацию. В нем меньше про скорость, больше про системность и совместимость.

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

Экология, или как США и Китай поменялись местами

Глобальное потепление, альтернативная энергетика и вся зеленая повестка — это часть западного дискурса. Китай же напротив — крупнейший в мире импортер угля, что плохо рифмуется с заботой об экологии.

В плане США по развитию ИИ в разделе про инфраструктуру делается акцент на упрощении разрешений для дата‑центров, а скорость строительства инфраструктуры ставится выше климатической повестки:

Мы продолжим отвергать радикальные климатические догмы и бюрократические препоны, как это делала Администрация с первого дня работы. Проще говоря, нам нужно строить, строить и еще раз строить!

В Китайском же плане наоборот — неожиданно много внимания к экологии:

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

Да, это только риторика. Не утверждаем, что Китай будет спасать планету, а США начнут сжигать больше угля, чем в Поднебесной. Однако это показательная риторика — кажется, США чувствуют уязвимость и нехило боятся отстать от Китая.

#ии #исследования

MCP и безопасность: три главные угрозы, о которых нужно знать

Мы уже рассказывали про MCP. Это передовой способ превращать данные в полезные инсайты для бизнеса.

Тогда мы опустили вероятные проблемы, связанные с его внедрением, ибо гипотез было много, но в бою они проверены не были.

Однако теперь подвезли хорошую статью на эту тему. Разбираемся.

Видится, что MCP меняет саму природу безопасности:

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

1. Удаленное выполнение команд (RCE / OS injection)

Некорректная обработка запросов в MCP позволяет выполнять системные команды на машине разработчика. В связке с LLM это опасно: модель может сгенерировать и сама выполнить разрушительную команду.

Backslash показали, как сервер передает текст напрямую в subprocess, и одна строка превращается в полный контроль над системой. Защита требует не только фильтрации ввода, но и изоляции среды, где работает агент.

2. Подмена и отравление инструментов (Tool Poisoning / Shadowing)

В MCP инструмент — это сервис или модуль, который агент вызывает для задач вроде доступа к CRM, расчетов или подготовки отчетов. Агент доверяет инструменту полностью и не проверяет его работу.

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

Защита — проверка подлинности и контроль изменений инструментов.

3. Prompt injection и отравление контекста

MCP превращает данные в живой контекст для модели: документы, базы, API подключаются автоматически. Если источник данных заражен скрытыми инструкциями, агент воспримет их как часть задания и выполнит.

Так атака приходит не через код, а через данные: невинный отчет может содержать команду передать пароли или изменить расчет, и LLM выполнит это, считая, что действует корректно.

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

Выводы

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

Следующий шаг — научиться строить такие системы так же осознанно, как мы строим надежные API и корпоративные сети: MCP — не просто технология, а новая дисциплина безопасности.

#ии #безопасность #статьи #исследования

Вы еще не научились продавать данные? В Маккинзи говорят, что уже поздно

Сырые данные обесцениваются. Ключевая модель — встроенный интеллект, который работает в моменте. И если раньше звучал вопрос «Что мы можем продать?», то теперь — «Что мы можем автоматизировать?»

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

Разбираемся, так ли это, и что с этим делать.

Монетизация данных больше не про данные

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

Генеративный ИИ позволяет продавать не данные, а поведение. Это видно по спросу на MCP-решения.

ИИ связывает источники, учитывает контекст и выдает не ответ, а действие. В этом новая форма дата-продукта: не API, не дашборд, а агент, встроенный в задачу. Сегодня HR-система не показывает бенчмарки — она предлагает зарплату, объясняет расчет и формирует оффер.

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

Старая модель продажи данных умирает

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

Маккинзи фиксируют: data-as-a-product уходит в прошлое. Продавать датасеты и агрегированные выгрузки больше невыгодно. К 2026 году 75% компаний будут использовать синтетические данные. Заказчики не хотят доступ — им нужен результат.

Стройте сервисы, которые не показывают данные, а решают задачи. Переходите к intelligence-as-a-service: продавайте поведение, встраивайте агентов в процессы клиента, берите деньги за эффект, а не за API.

Помните, что данные — новая нефть? Ну так и поймите правильно: нефть — это топливо, а продуктом становится действие.

Большие данные больше не конкурентное преимущество

У всех терабайты информации. Но данные стали взаимозаменяемыми: их можно купить, сгенерировать или синтезировать. Уникальность быстро теряется. Ценность смещается от владения к действию.

Преимущество теперь в том, как быстро данные превращаются в решение. Не в дашборде, а в том, что система делает на его основе. Те, кто встроил ИИ в таргетинг, ценообразование и обслуживание, выигрывают за счет реакции, а не доступа.

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

Побеждают не те, у кого больше, а те, у кого работает.

#ии #исследования