Генеральный директор Microsoft Сатья Наделла предупреждает компании, стремящиеся стандартизировать все свои бизнес-процессы на единой платфо...
Генеральный директор Microsoft Сатья Наделла предупреждает компании, спешащие стандартизировать все бизнес-процессы на единой ИИ-платформе: самый большой риск может заключаться не в качестве модели или цене токенов, а в потере контроля над знаниями, составляющими ценность самой компании.
В интервью программе CNN «Fareed Zakaria GPS» 26 июля 2026 года Наделла заявил, что компании должны сохранять право собственности на данные, подсказки, метаданные, контекст, память и оркестровочный слой, создаваемые в ходе использования ИИ сотрудниками.
Его опасения прямолинейны.
Чем глубже компания интегрирует ИИ в повседневную работу, тем больше информации о реальном функционировании организации она предоставляет системе: как команды обслуживают клиентов, как руководители принимают взвешенные решения, как инженеры отлаживают продукты, как аналитики оценивают риски, как сотрудники исправляют несовершенные выходные данные модели.
Со временем эти взаимодействия формируют цифровую запись операционных знаний компании.
Если эта запись существует только в проприетарном продукте одного поставщика моделей, то смена поставщика в будущем может потребовать восстановления гораздо большего, чем просто интеграция чат-бота.
Решение, предложенное Наделлой, не заключается в том, чтобы каждая компания обучала собственные передовые фундаментальные модели.
Напротив, он выступает за разделение.
Модели должны быть заменяемыми. Контекст, память, метаданные, агентные фреймворки, рабочие процессы и накопленные знания компании всегда должны оставаться под ее контролем.
Такая архитектура позволяет организации использовать самые мощные модели для конкретных задач, не позволяя ни одному поставщику стать единственным хранилищем ее институционального интеллекта.
На первый взгляд, использование одного поставщика ИИ кажется эффективным.
У сотрудников один интерфейс. Закупки проще. Группе безопасности нужно утвердить только одну платформу. Разработчикам нужно построить только один набор интеграций. Организация может стандартизировать подсказки, агентов и внутренние рабочие процессы на едином технологическом стеке.
Проблемы проявляются постепенно.
Корпоративные ИИ-системы давно перестали быть просто текстовым полем, подключенным к API модели.
По мере углубления внедрения система накапливает:
Каждый из этих элементов по отдельности может не выглядеть как стратегический актив.
Но вместе они могут составить подробную карту того, как компания мыслит.
Традиционные организационные знания разбросаны по
множеству мест.
Часть из них зафиксирована в политиках, руководствах, базах данных и вики-страницах, но значительная часть не документируется.
Они существуют в решениях, которые сотрудники принимают снова и снова:
Когда системы искусственного интеллекта участвуют в этих решениях, история взаимодействий начинает захватывать часть этих неявных знаний.
Пользователи задают вопросы.
ИИ извлекает информацию.
Сотрудники исправляют ответы.
Система вызывает инструменты.
Пользователь отклоняет один результат и выбирает другой.
Рабочие процессы обновляются.
После тысяч взаимодействий компания, осознанно или нет, создала ценный набор данных для обучения и оценки.
Ключевой вопрос: кто владеет этим набором данных и может его повторно использовать.
Компании часто рассматривают привязку к ИИ как проблему API.
Если поставщик A становится слишком дорогим, замените его конечной точкой API поставщика B.
Этот подход работает только в том случае, если сама модель является единственной зависимостью.
Современные агентные системы включают множество других уровней.
| Уровень | Пример |
|---|---|
| Базовая модель | OpenAI, Anthropic, Microsoft Managed, модели с открытым весом |
| Системные подсказки | Корпоративные правила и инструкции по задачам |
| Контекст | Соответствующие бизнес-документы и извлеченная информация |
| Память | Постоянная история пользователя, команды, проекта или клиента |
| Фреймворк | Агентные циклы для планирования, вызова инструментов, повторных попыток и оценки |
| Инструменты | CRM, базы данных, репозитории кода, ERP, электронная почта, внутренние API |
| Метаданные | Подсказки, выбор модели, выходные данные, задержка, стоимость, исправления |
| Оценка | Тесты для определения надежности рабочих процессов |
| Политики | Разрешения, правила безопасности, требования соответствия |
| Наблюдаемость | Логи, трассировки, показатели использования и записи событий |
Если все эти уровни встроены в проприетарный продукт одного поставщика, замена базовой модели может потребовать перепроектирования всего технологического стека.
Это создает фактическую зависимость.
Первоначальный поставщик может:
Компании с модульной архитектурой могут реагировать, заменяя модель.
А для тех, чья память, фреймворк, контекст и логика рабочего процесса объединены в едином сервисе, вариантов выбора может быть гораздо меньше.
Самая глубокая форма привязки возникает, когда организация перестает вести собственную запись рассуждений и обратной связи, связанных с работой, выполняемой с помощью ИИ.
Представьте процесс поддержки клиентов, который улучшался в ходе тысяч взаимодействий с ИИ в течение двух лет.
Сотрудники неоднократно исправляли систему.
Эти исправления научили рабочий процесс, когда следует возмещать средства, когда эскалировать, какой тон использовать.
Как используются инструменты, какие существуют исключения и какие внутренние команды следует привлекать.
Если все эти результаты обучения существуют только в проприетарном агентном сервисе, миграция может означать потерю исторических данных, сделавших рабочий процесс эффективным.
У компании могут остаться исходные документы.
Но у нее может уже не быть полной операционной памяти, возникшей в результате их использования.
Именно эту озабоченность подразумевает предупреждение Наделлы — компании могут в конечном итоге передать часть своего мыслительного процесса на аутсорсинг.
Это звучит драматично, но архитектурная проблема сама по себе очень конкретна: предприятиям необходим достаточный контроль над знаниями, созданными с помощью ИИ, чтобы иметь возможность реконструировать, аудировать, переносить и улучшать свои собственные рабочие процессы.
Решение, предложенное Наделлой, заключается в отделении базовых моделей от периферийных уровней, принадлежащих предприятию.
В интервью CNN он особо выступил за отделение управляющего каркаса от модели и отделение контекста и памяти от модели.
Это формирует иную архитектуру.
Компании больше не рассматривают одного поставщика ИИ как полноценную интеллектуальную платформу, а воспринимают базовые модели как взаимозаменяемые механизмы рассуждений.
Предприятие сохраняет контроль над:
Модель получает только контекст, необходимый для текущей задачи.
В корпоративных ИИ-системах метаданные могут включать:
Такие записи могут стать чрезвычайно ценными.
Они могут использоваться для:
Ключевая идея Наделлы в том, что этот цикл обучения всегда должен принадлежать предприятию.
Если организация сохраняет свою историю взаимодействий, она может постоянно улучшаться, даже если базовая модель изменится.
Управляющий фреймворк — это программный слой вокруг ИИ-модели, который преобразует сырые ответы модели в агентные рабочие процессы.
Он может обрабатывать:
Если фреймворк тесно связан с моделью одного поставщика, смена модели может потребовать замены всей агентной системы.
Если фреймворк не зависит от поставщика, тот же рабочий процесс может вызывать разные модели.
Например:
Бизнес-процесс остается стабильным, а механизм рассуждений гибко переключается.
Это уже не просто концептуальный дизайн.
Microsoft сама теперь предоставляет инфраструктуру для маршрутизации между несколькими ИИ-моделями.
Маршрутизатор моделей в Microsoft Foundry анализирует промпты и направляет их к подходящим базовым моделям на основе качества, стоимости, задержки и сконфигурированного подмножества моделей.
ИИ-шлюз в Azure API Management предоставляет несколько поставщиков моделей через единую корпоративную границу. В документации Microsoft описана поддержка серверных частей, включая Microsoft Foundry, Azure OpenAI, AWS Bedrock, Google Vertex, OpenAI, Anthropic и пользовательские конечные точки моделей.
Шлюзовая архитектура позволяет централизованно управлять:
Приложения теперь вызывают корпоративный шлюз, а не встраивают одного поставщика напрямую во всю кодовую базу.
Это не устраняет проблему блокировки полностью. Сам шлюз может стать инфраструктурой, которую нужно будет мигрировать и администрировать.
Но это поднимает выбор модели на уровень, контролируемый предприятием.
Вендор-нейтральный корпоративный ИИ-стек можно представить как несколько независимых слоев:
Сотрудник/Приложение
|
v
Корпоративный агент/Фреймворк
|
+------ Корпоративная память
|
+------ Извлечение/Контекст
|
+------ Инструменты/MCP/Внутренние API
|
+------ Оценка/Политики
|
+------ Наблюдаемость/Метаданные
|
v
ИИ-шлюз/Маршрутизатор моделей
/ | \
v v v
Модель А Модель Б Внутренняя модель
Ключевая граница проходит между корпоративными знаниями и рассуждениями модели.
Память компании, промпты, рабочие процессы, инструменты и оценочные данные находятся над слоем модели.
Модель можно заменить, не отбрасывая организованное состояние, построенное вокруг нее.
Храните авторитетную бизнес-информацию в системах, контролируемых организацией.
Примеры включают:
Модель должна извлекать необходимое содержимое, а не быть единственной постоянной копией информации.
Стройте извлечение как независимый сервис.
Это позволяет организации менять модели встраивания, реранкеры или генеративные модели, не перестраивая исходную базу знаний.
Слой извлечения должен сохранять источники информации, чтобы пользователи знали, какие внутренние материалы повлияли на ответ.
Когда память имеет стратегическое значение, храните долгосрочную память отдельно от родной истории чата поставщика модели.
Возможные типы памяти включают:
Для каждого типа должны быть четкие правила хранения, прав доступа, экспорта и удаления.
Поместите бизнес-логику в систему, которую предприятие может проверять и версионировать.
Фреймворк должен определять:
Это превращает агента из специфической функции поставщика в корпоративный рабочий процесс.
Когда важна многомодельная гибкость, разместите слой маршрутизации между приложением и моделями.
Маршрутизатор может выбирать модель на основе:
Шлюз также может обеспечивать отказоустойчивость.
Если одна конечная точка модели недоступна, рабочий процесс может продолжиться с использованием другой подходящей модели.
Храните достаточно метаданных взаимодействий, чтобы понять, работает ли система правильно.
Не сохраняйте все данные без разбора. Требования конфиденциальности, безопасности и регулирования по-прежнему действуют.
Для соответствующих рабочих процессов полезные записи могут включать:
Эти данные позволяют ИИ-системам со временем становиться лучше, не привязывая это улучшение к конкретному поставщику.
Опишите идею одной фразой, и We0 AI создаст сайт-витрину, страницы и CMS, а после запуска поможет привлечь клиентов и трафик.
Одна полная генерация проекта для бесплатной регистрации
Лучше всего попробовать один полный поток генерации и быстро увидеть первый черновик проекта.
Корпоративная архитектура строится с прицелом на более длительную перспективу, чем рейтинги бенчмарков.
Сильнейшая модель сегодня может не быть таковой через шесть месяцев.
Рынок ИИ меняется быстро, поскольку улучшения могут исходить от:
Компания, способная менять модели, не меняя свою операционную систему, выиграет от такой конкуренции.
А компания, глубоко привязанная к одному проприетарному стеку, может не выиграть.
Он одет в чёрный костюм, носит очки, улыбается и активно жестикулирует. На заднем плане — книжный шкаф с книгами, шляпой, фоторамками и другими предметами. В нижней части экрана — двуязычные субтитры на китайском и английском. Английский текст: «at the same time anyone model can go away and you can», китайский: «В то же время любая модель может устареть, а вы можете продолжать использовать свою собственную модель». Это изображение тесно связано с контекстом, в котором обсуждается, что компаниям следует избегать чрезмерной зависимости от одного поставщика ИИ, и подчёркивается необходимость взаимозаменяемости моделей для адаптации к изменениям, таким как устаревание модели.
Это не означает, что компании должны постоянно менять модели.
Частая смена сама по себе может вызвать проблемы:
Несогласованность выходных данных
Новые
Оценка работы
Проверка безопасности
Несовместимость промптов
Разное поведение инструментов
Новые типы сбоев
Цель — возможность выбора, а не постоянная замена.
Компания должна иметь возможность вносить изменения, когда для этого есть веские основания.
Исходная статья связывает предупреждение Наделлы с более ранними обсуждениями в стартап-сообществе.
В мае 2026 года генеральный директор OpenAI Сэм Альтман предложил каждому стартапу из текущего набора Y Combinator токены OpenAI на сумму 2 миллиона долларов в обмен на долю в компании.
По сообщению TechCrunch, инвестиции будут оформлены в виде SAFE без верхнего предела и конвертированы при следующем раунде финансирования с оценкой.
Это привлекательно для ИИ-стартапов.
Затраты на инференс модели могут быть одними из крупнейших расходов компании на раннем этапе. Получение значительного объёма токенов позволяет команде создавать и тестировать продукты, не тратя эквивалентные суммы наличных.
Но это также вызывает очевидные вопросы о стратегической зависимости.
Инвестор Джейсон Калаканис публично предупредил основателей, что провайдер платформы может узнать, что разрабатывает стартап, и впоследствии составить ему конкуренцию.
Это опасение не означает, что OpenAI действительно скопирует чей-то продукт.
Это классический аргумент о риске платформы: чем более центральным становится инфраструктурный провайдер для бизнеса, тем важнее понимать, к каким данным он имеет доступ и насколько высока стоимость перехода.
Стандартные инвестиции самого Y Combinator остаются независимыми.
В настоящее время YC описывает свою стандартную сделку как инвестиции в 500 000 долларов, включающие:
Сообщённая TechCrunch договорённость с OpenAI является дополнительным предложением, а не заменой стандартного финансирования YC.
Таким образом, для основателей стратегический вопрос заключается не только в ценности бесплатного или субсидированного инференса.
Главное — приведёт ли принятие этого предложения к изменениям в структуре стартапа, которые усложнят его самостоятельную работу в будущем.
Раньше преимущества компании часто заключались в talent и процессах.
Опытные сотрудники знали, как решать нестандартные проблемы. Менеджеры понимали, какие исключения критически важны. Продавцы знали, какие сигналы указывают на реальное намерение купить. Инженеры помнили причины, стоящие за, казалось бы, странными архитектурными решениями многолетней давности.
Системы ИИ начинают кодифицировать часть накопленного опыта в машиночитаемые артефакты.
К таким артефактам относятся:
Это не значит, что ИИ уже владеет всем интеллектом организации.
Значительная часть опыта по-прежнему сосредоточена в людях, культуре, межличностных отношениях и неявных суждениях.
Но доля машиночитаемой части растёт.
Это делает вопросы собственности и переносимости более важными.
Дорого и технически сложно.
Для большинства компаний обучение модели с нуля экономически бессмысленно.
Реальное изменение в том, что у компаний появилось больше вариантов.
Например, Microsoft Foundry предоставляет доступ к моделям от Microsoft, OpenAI, Meta, DeepSeek и других поставщиков. Корпоративные шлюзы также могут направлять запросы к моделям, размещённым на других облачных платформах или предоставленным напрямую третьими сторонами.
Таким образом, модель можно рассматривать как специализированный инфраструктурный компонент.
Устойчивая ценность компании находится на следующих уровнях:
Именно эти уровни позволяют универсальным моделям проявлять уникальные ИИ-способности компании.
Практический способ измерить степень блокировки ИИ — задать простой вопрос:
Если бы наш основной поставщик моделей завтра исчез, что бы мы потеряли?
Ответ должен быть задокументирован.
Может ли приложение указывать на другую конечную точку модели?
Если да, сколько кода нужно изменить?
Хранятся ли системные промпты и инструкции агентов в собственном репозитории компании?
Можно ли их экспортировать и версионировать?
Контролирует ли компания исходные документы и индексы поиска?
Потребует ли смена модели восстановления уровня знаний?
Можно ли экспортировать долговременную память?
Понимает ли организация её архитектуру?
Совместима ли эта память с другими агентными системами?
Построены ли интеграции инструментов на основе переносимых API или стандартов, таких как MCP?
Или критические рабочие процессы существуют только в проприетарном агентном продукте конкретного поставщика?
Сохраняет ли компания собственные журналы взаимодействий и результаты оценки моделей?
Можно ли сравнить производительность двух поставщиков по историческим задачам?
Можно ли протестировать те же критерии приемки с другой моделью?
Без воспроизводимого набора для оценки смена модели превращается в субъективную попытку миграции.
Применяются ли бизнес-правила доступа собственной системой компании?
Миграция модели не должна требовать перестройки модели авторизации компании.
Может ли компания объяснить, куда направляются данные, какие модели их обрабатывают и что сохраняется?
Гибкость работы с несколькими моделями ценна только при сохранении целостности системы управления.
Что происходит, когда основной поставщик недоступен?
Могут ли критические рабочие процессы корректно деградировать?
Один тест на миграцию часто выявляет зависимости, отсутствующие на архитектурных схемах.
Избегание блокировки поставщика не означает одновременную отправку данных нескольким поставщикам моделей.
Это создаёт ненужные риски для конфиденциальности и безопасности.
Контролируемая стратегия использования нескольких моделей должна применять правила маршрутизации.
Например:
| Нагрузка | Возможная стратегия маршрутизации |
|---|---|
| Низкорисковая классификация | Небольшая дешёвая размещённая модель |
| Сложное кодирование | Мощная модель для кодирования |
| Анализ длинных документов | Модель с длинным контекстом |
| Чувствительные внутренние данные | Частная или самостоятельно размещённая модель |
| Высокорисковые решения | Аудируемая корпоративная модель |
Поддержка решений | Утверждённая модель + человеческая проверка
| Сбой поставщика | Предварительно утверждённая резервная модель |
Компаниям всё равно необходима политика управления данными, определяющая, какие модели могут обрабатывать какую информацию.
Выбор модели должен оставаться гибким.
Обработка данных должна быть строгой.
Предложение Наделлы звучит заманчиво, но разделение каждого уровня увеличивает объём инженерных работ.
Система с несколькими моделями может потребовать:
Небольшие компании могут разумно начать с одного поставщика.
Ключ в том, чтобы избежать ненужной блокировки.
Стартапам не нужно строить сложную внутреннюю ИИ-платформу до достижения product-market fit.
Они всё ещё могут:
Эти относительно простые решения могут значительно облегчить будущую миграцию.
Самая ценная часть корпоративного ИИ может заключаться не в самой модели.
А в цикле обратной связи, который возникает при использовании модели сотрудниками.
Компания ставит задачу.
Модель предлагает ответ.
Сотрудники исправляют ошибки.
Вызываются инструменты.
Измеряются результаты.
Рождается лучший рабочий процесс.
Если у организации есть этот цикл, накопленные знания могут переходить от одной модели к следующей.
Если цикл полностью принадлежит поставщику, компания может заметить улучшение AI-систем, но её собственная переносимость не возрастёт.
Именно поэтому предупреждение Наделлы имеет более глубокий смысл, чем просто совет использовать нескольких поставщиков.
Это рекомендация о том, где должен храниться корпоративный интеллект.
Модель можно арендовать.
Но организация должна сохранить контекст, в котором модель действует.
В интервью Фариду Закарии 26 июля 2026 года Наделла заявил, что компании не должны позволять одному поставщику AI контролировать их данные, метаданные, контекст, память и фреймворк агентов. Он предупредил, что, потеряв контроль над этими уровнями, компания рискует передать часть своего мыслительного процесса на аутсорсинг.
Не обязательно. Его предложение заключается в отделении собственного контекста, памяти, метаданных и оркестрационного слоя от модели, чтобы компания могла использовать несколько передовых или открытых моделей, сохраняя при этом свои знания.
Фреймворк — это программный слой вокруг модели, управляющий промптами, инструментами, контекстом, памятью, планированием, повторными попытками, правами доступа, оценкой и выполнением. Его отделение от единственного поставщика модели способствует переносимости бизнес-процессов.
AI-шлюз — это контролируемый слой между корпоративными приложениями и поставщиками моделей. Он централизует аутентификацию, маршрутизацию, ограничение скорости, мониторинг, политики, выбор модели и учётные данные поставщиков.
AI-метаданные раскрывают используемые промпты, извлечённую информацию, вызванные инструменты, способы корректировки вывода пользователем и успешность задач. Эти исторические данные можно использовать для оценки, оптимизации рабочих процессов, маршрутизации моделей или будущего внутреннего обучения.
Нет. Она снижает зависимость на уровне модели, но шлюз, векторная база данных, система памяти, фреймворк агентов или облачная платформа могут создать новые формы блокировки. Переносимость требует комплексного подхода ко всему технологическому стеку.
Согласно сообщению TechCrunch в мае 2026 года, OpenAI предоставила каждой компании в текущем наборе YC токены на сумму 2 миллиона долларов в обмен на долю через безасортиментный SAFE. Эта сделка независима от стандартного инвестиционного соглашения YC на 500 тысяч долларов.
Обычно нет. Ранние команды могут начать с одного поставщика, сохраняя при этом абстракцию вызова модели, управление версиями промптов, автономный контроль данных и переносимость оценки. Эти решения позволяют сохранить гибкость для будущих изменений без излишней инфраструктуры.
Предостережение Сатьи Наделлы не сводится к простой рекомендации подписаться на несколько AI-моделей. Его более глубокий смысл заключается в том, что компаниям следует избегать хранения накопленного контекста, памяти, метаданных, логики агентов и операционных знаний в системах, которые невозможно независимо сохранить или перенести.
Модульная архитектура позволяет сохранить независимость уровня знаний компании от уровня моделей. Компания может выбирать модели в зависимости от потребностей в кодировании, обработке длинного контекста, низкозатратных задачах, конфиденциальных нагрузках или аварийном переключении, не перестраивая полную AI-систему.
Такая гибкость создаёт инженерную сложность, но даже небольшие команды могут сохранить будущую свободу выбора, с самого начала контролируя свои данные, промпты, архитектуру памяти, критерии оценки и интерфейсы моделей.
Передовые модели можно арендовать, а учебный цикл, объясняющий, как работает ваша компания, должен навсегда остаться вашим.
Начните с одной фразы и получите полноценный сайт за считанные минуты.
