Snowflake Ventures выделяет Dust и Gray Swan как недостающий слой корпоративного AI

Не новый раунд, а инвестиционная карта рынка

Snowflake Ventures опубликовала собственную схему следующего этапа корпоративного AI и поставила в центр две уже входящие в её портфель компании — Dust и Gray Swan. В тексте нет объявления о новой сумме инвестиций, оценке или закрытии раунда. Поэтому точнее говорить не о свежей сделке, а о публичном объяснении того, куда Snowflake считает важным направлять капитал: в инфраструктуру между фундаментальной моделью и реальным бизнес-процессом.

Тезис Snowflake предельно практичен. По версии компании, корпоративные AI-программы часто застревают не из-за слабости модели, а из-за пробелов в управлении, безопасности и организации рабочего процесса. Для перехода к промышленному использованию агентам нужны доверенный источник корпоративных данных, контроль доступа с учётом личности, политики и ограничения, которые действуют не только в презентации, но и во время выполнения задачи.

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

Dust: общий контекст вместо одиночного чат-бота

Dust строит платформу для совместной работы людей и агентов. Snowflake описывает её как общий фундамент из корпоративных знаний, поиска, подключений через Model Context Protocol и повторно используемых управляемых агентов и навыков. Dust, в свою очередь, говорит о сведении контекста из Slack, CRM, документов и других систем, а также о правах на данные, инструменты, системы и агентов.

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

Snowflake отдельно отмечает растущую интеграцию с Dust: клиенты могут связывать Cortex Agents и агентов Dust с доверенными корпоративными данными. Для Snowflake это также платформенная стратегия. Чем больше рабочих процессов опирается на данные и политики внутри её среды, тем важнее становится слой данных независимо от того, какая модель используется для конкретной задачи.

Gray Swan: защита должна работать во время выполнения

Вторая компания, Gray Swan, представлена как слой runtime-защиты для AI-приложений. Её собственная публичная формулировка — безопасность корпоративных приложений на базе AI; Snowflake связывает продукт с проверкой и защитой систем, которые уже взаимодействуют с рабочими данными и инструментами.

Такая защита нужна потому, что предварительная оценка модели не охватывает всё, что произойдёт после запуска. Агент ежедневно получает новые документы, сообщения и результаты инструментов. Часть содержимого может быть ошибочной или враждебной. Статический тест отвечает, как система вела себя на подготовленном наборе сценариев; runtime-контроль должен замечать нарушение политики в конкретной рабочей сессии и останавливать опасную последовательность действий.

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

Что следует проверять покупателю

Компаниям стоит оценивать агентскую платформу не только по демонстрации, но и по проверяемым границам. Полезный тест начинается с матрицы: какой сотрудник, агент и инструмент видят конкретный источник; какие действия только читают данные; какие создают необратимый эффект; где требуется человеческое подтверждение. Затем нужно убедиться, что отказ действительно обеспечивается системой доступа, а не только инструкцией языковой модели.

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

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

Публикация Snowflake убедительна именно как карта инфраструктурного спроса, а не как сообщение о раунде. Dust закрывает вопрос общего контекста и управляемых рабочих процессов, Gray Swan — вопрос наблюдения и защиты в момент выполнения. Их совместное появление в тезисе Snowflake показывает: рынок корпоративного AI смещается от выбора самой впечатляющей модели к доказательству того, что система может безопасно выполнять повторяемую работу.