Предупреждение Сатьи Наделлы: не позволяйте одному ИИ-поставщику стать «мозгом» вашей компании

Введение

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

В интервью программе CNN «Fareed Zakaria GPS» 26 июля 2026 года Наделла заявил, что компании должны сохранять право собственности на данные, подсказки, метаданные, контекст, память и оркестровочный слой, создаваемые в ходе использования ИИ сотрудниками.

Его опасения прямолинейны.

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

Со временем эти взаимодействия формируют цифровую запись операционных знаний компании.

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

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

Напротив, он выступает за разделение.

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

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

Ставить все на одну ИИ-модель — значит передавать собственные возможности на аутсорсинг

На первый взгляд, использование одного поставщика ИИ кажется эффективным.

У сотрудников один интерфейс. Закупки проще. Группе безопасности нужно утвердить только одну платформу. Разработчикам нужно построить только один набор интеграций. Организация может стандартизировать подсказки, агентов и внутренние рабочие процессы на едином технологическом стеке.

Проблемы проявляются постепенно.

Корпоративные ИИ-системы давно перестали быть просто текстовым полем, подключенным к API модели.

По мере углубления внедрения система накапливает:

• Внутреннюю документацию
• Библиотеку подсказок
• Историю диалогов
• Пользовательские предпочтения
• Долговременную память агентов
• Результаты оценки
• Разрешения на инструменты
• Правила рабочих процессов
• Индексы для поиска
• Записи ручных исправлений
• Историю вызовов инструментов
• Бизнес-специфические инструкции
• Шаблоны утверждений
• Внутреннюю терминологию
• Примеры успешных и неудачных работ

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

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

Использование ИИ создает новый тип институциональной памяти

Традиционные организационные знания разбросаны по

множеству мест.

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

Они существуют в решениях, которые сотрудники принимают снова и снова:

• Какой запрос клиента заслуживает эскалации?
• Какая продажа действительно квалифицирована?
• Какие инженерные компромиссы допустимы?
• Как компания реагирует на необычные запросы на возврат?
• Какой язык приемлем на регулируемых рынках?
• Какие дефекты продукта требуют немедленного отката?
• Что замечает опытный менеджер, но упускает младший сотрудник?

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

Пользователи задают вопросы.

ИИ извлекает информацию.

Сотрудники исправляют ответы.

Система вызывает инструменты.

Пользователь отклоняет один результат и выбирает другой.

Рабочие процессы обновляются.

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

Ключевой вопрос: кто владеет этим набором данных и может его повторно использовать.

Привязка к поставщику выходит далеко за рамки совместимости API

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

Если поставщик A становится слишком дорогим, замените его конечной точкой API поставщика B.

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

Современные агентные системы включают множество других уровней.

Уровень	Пример
Базовая модель	OpenAI, Anthropic, Microsoft Managed, модели с открытым весом
Системные подсказки	Корпоративные правила и инструкции по задачам
Контекст	Соответствующие бизнес-документы и извлеченная информация
Память	Постоянная история пользователя, команды, проекта или клиента
Фреймворк	Агентные циклы для планирования, вызова инструментов, повторных попыток и оценки
Инструменты	CRM, базы данных, репозитории кода, ERP, электронная почта, внутренние API
Метаданные	Подсказки, выбор модели, выходные данные, задержка, стоимость, исправления
Оценка	Тесты для определения надежности рабочих процессов
Политики	Разрешения, правила безопасности, требования соответствия
Наблюдаемость	Логи, трассировки, показатели использования и записи событий

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

Это создает фактическую зависимость.

Первоначальный поставщик может:

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

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

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

Реальный риск — потерять способность объяснять, как выполняется работа

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

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

Сотрудники неоднократно исправляли систему.

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

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

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

У компании могут остаться исходные документы.

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

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

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

Самые умные модели можно арендовать, «мозг» компании должен оставаться внутри

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

В интервью CNN он особо выступил за отделение управляющего каркаса от модели и отделение контекста и памяти от модели.

![На изображении показан генеральный директор Microsoft Наделла в интервью CNN. Он в темном костюме стоит перед книжным шкафом, на котором расположены книги, шляпа, рамка для фото и другие предметы. Внизу кадра показаны субтитры на китайском и английском языках: «frontier models but for example by keeping the harness separate 比如，可以采用前沿模型，但同时将各部件保持分开处理.» Это тесно связано с контекстом, в котором упоминается, что Наделла в интервью предложил разделить модели и принадлежащие предприятию уровни, сохраняя компоненты раздельными, чтобы сформировать различные архитектуры, позволяющие предприятиям сохранять контроль над данными и т.д., подчеркивая контроль предприятий над ИИ-системами.](https://we0-cms.oss-cn-beijing.aliyuncs.

com/cms-assets/image/2026/07/21391647-8a61-4954-ae92-4d7a55f1d5bd-4c4dbfd1-8681-4d4b-b867-90886af544b4.png)

Это формирует иную архитектуру.

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

Предприятие сохраняет контроль над:

• Своими данными
• Своими промптами
• Своей памятью
• Состоянием своих рабочих процессов
• Своими оценочными данными
• Своим инструментальным слоем
• Своими метаданными
• Своими правами доступа
• Своими бизнес-правилами
• Своим аудиторским следом

Модель получает только контекст, необходимый для текущей задачи.

Метаданные, о которых говорит Наделла

В корпоративных ИИ-системах метаданные могут включать:

• Какой вопрос задал сотрудник
• Какая модель обработала запрос
• Какие документы были извлечены
• Какие инструменты были вызваны
• Какие параметры инструментов использовались
• Какой результат сгенерировала модель
• Принял ли пользователь результат или отклонил его
• Как сотрудник отредактировал выходные данные
• Сколько времени заняла задача
• Какова стоимость задачи
• Был ли рабочий процесс успешным
• Какие проверки безопасности или политик были запущены

Такие записи могут стать чрезвычайно ценными.

Они могут использоваться для:

• Оценки модели
• Выявления типичных сбоев
• Улучшения промптов
• Обучения классификаторов
• Настройки правил маршрутизации
• Построения внутренних наборов данных
• Создания доменно-специфичных моделей
• Улучшения агентных рабочих процессов
• Аудита важных решений

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

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

Сохранение управляющего фреймворка независимым

Управляющий фреймворк — это программный слой вокруг ИИ-модели, который преобразует сырые ответы модели в агентные рабочие процессы.

Он может обрабатывать:

1. Построение промптов
2. Извлечение контекста
3. Планирование
4. Выбор инструментов
5. Выполнение инструментов
6. Чтение и запись памяти
7. Механизмы повторных попыток
8. Валидацию выходных данных
9. Процессы утверждения
10. Логирование
11. Маршрутизацию моделей
12. Генерацию финального ответа

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

Например:

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

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

Многомодельная архитектура становится реальной корпоративной практикой

Это уже не просто концептуальный дизайн.
Microsoft сама теперь предоставляет инфраструктуру для маршрутизации между несколькими ИИ-моделями.
Маршрутизатор моделей в Microsoft Foundry анализирует промпты и направляет их к подходящим базовым моделям на основе качества, стоимости, задержки и сконфигурированного подмножества моделей.
ИИ-шлюз в Azure API Management предоставляет несколько поставщиков моделей через единую корпоративную границу. В документации Microsoft описана поддержка серверных частей, включая Microsoft Foundry, Azure OpenAI, AWS Bedrock, Google Vertex, OpenAI, Anthropic и пользовательские конечные точки моделей.

Шлюзовая архитектура позволяет централизованно управлять:

• Аутентификацией
• Выбором модели
• Учетными данными поставщиков
• Лимитами токенов
• Ограничениями скорости
• Логированием
• Мониторингом
• Политиками безопасности контента
• Сетевыми политиками
• Отслеживанием затрат

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

Практичная корпоративная ИИ-архитектура

Вендор-нейтральный корпоративный ИИ-стек можно представить как несколько независимых слоев:

Сотрудник/Приложение
          |
          v
Корпоративный агент/Фреймворк
          |
          +------ Корпоративная память
          |
          +------ Извлечение/Контекст
          |
          +------ Инструменты/MCP/Внутренние API
          |
          +------ Оценка/Политики
          |
          +------ Наблюдаемость/Метаданные
          |
          v
ИИ-шлюз/Маршрутизатор моделей
     /       |        \
    v        v         v
 Модель А  Модель Б  Внутренняя модель

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

Первый слой: Корпоративные данные

Храните авторитетную бизнес-информацию в системах, контролируемых организацией.
Примеры включают:

• Хранилища данных
• Репозитории документов
• CRM-системы
• Базы данных продуктов
• Системы управления исходным кодом
• Внутренние базы знаний

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

Второй слой: Контекст и извлечение

Стройте извлечение как независимый сервис.

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

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

Третий слой: Память

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

Возможные типы памяти включают:

• Память пользователя
• Память проекта
• Память клиента
• Память агента
• Организационная память

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

Четвертый слой: Агентный фреймворк

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

Фреймворк должен определять:

• Какие инструменты существуют
• Кто может их использовать
• Какие действия требуют утверждения
• Как работают механизмы повторных попыток
• Какие состояния нужно сохранять
• Когда можно переключать модели
• Что считается успехом

Это превращает агента из специфической функции поставщика в корпоративный рабочий процесс.

Пятый слой: ИИ-шлюз или маршрутизатор

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

Маршрутизатор может выбирать модель на основе:

• Типа задачи
• Требований к качеству
• Стоимости
• Задержки
• Местоположения данных
• Длины контекста
• Требований безопасности
• Доступности поставщика

Шлюз также может обеспечивать отказоустойчивость.

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

Шестой слой: Метаданные и оценка

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

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

Для соответствующих рабочих процессов полезные записи могут включать:

• Версию модели
• Версию шаблона промпта
• Извлеченные источники
• Использование инструментов
• Задержку
• Использование токенов
• Обратную связь от пользователя
• Человеческие исправления
• Оценочные баллы
• Конечный результат

Эти данные позволяют ИИ-системам со временем становиться лучше, не привязывая это улучшение к конкретному поставщику.

Почему это важно, даже если одна модель сейчас явно лучшая

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

Сильнейшая модель сегодня может не быть таковой через шесть месяцев.

Рынок ИИ меняется быстро, поскольку улучшения могут исходить от:

• Нового претрейнинга
• Лучших способностей к рассуждению
• Снижения стоимости вывода
• Новых технологий контекстного окна
• Новых мультимодальных возможностей
• Улучшенного кодирования
• Лучшего использования инструментов
• Более быстрого обслуживания
• Публикации открытых весов
• Специализированных доменных моделей

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

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

Он одет в чёрный костюм, носит очки, улыбается и активно жестикулирует. На заднем плане — книжный шкаф с книгами, шляпой, фоторамками и другими предметами. В нижней части экрана — двуязычные субтитры на китайском и английском. Английский текст: «at the same time anyone model can go away and you can», китайский: «В то же время любая модель может устареть, а вы можете продолжать использовать свою собственную модель». Это изображение тесно связано с контекстом, в котором обсуждается, что компаниям следует избегать чрезмерной зависимости от одного поставщика ИИ, и подчёркивается необходимость взаимозаменяемости моделей для адаптации к изменениям, таким как устаревание модели.

Это не означает, что компании должны постоянно менять модели.

Частая смена сама по себе может вызвать проблемы:

• Несогласованность выходных данных

• Новые

• Оценка работы

• Проверка безопасности

• Несовместимость промптов

• Разное поведение инструментов

• Новые типы сбоев

Цель — возможность выбора, а не постоянная замена.

Компания должна иметь возможность вносить изменения, когда для этого есть веские основания.

Программа токенов YC показывает, почему стартапы опасаются зависимости от платформы

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

В мае 2026 года генеральный директор OpenAI Сэм Альтман предложил каждому стартапу из текущего набора Y Combinator токены OpenAI на сумму 2 миллиона долларов в обмен на долю в компании.

По сообщению TechCrunch, инвестиции будут оформлены в виде SAFE без верхнего предела и конвертированы при следующем раунде финансирования с оценкой.

Это привлекательно для ИИ-стартапов.

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

Но это также вызывает очевидные вопросы о стратегической зависимости.

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

Это опасение не означает, что OpenAI действительно скопирует чей-то продукт.

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

Предложение OpenAI не зависит от стандартной сделки YC

Стандартные инвестиции самого Y Combinator остаются независимыми.

В настоящее время YC описывает свою стандартную сделку как инвестиции в 500 000 долларов, включающие:

• 125 000 долларов за фиксированные 7% акций
• 375 000 долларов через SAFE без верхнего предела с условием наибольшего благоприятствования

Сообщённая TechCrunch договорённость с OpenAI является дополнительным предложением, а не заменой стандартного финансирования YC.

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

Главное — приведёт ли принятие этого предложения к изменениям в структуре стартапа, которые усложнят его самостоятельную работу в будущем.

Корпоративные знания об ИИ становятся новым стратегическим активом

Раньше преимущества компании часто заключались в talent и процессах.

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

Системы ИИ начинают кодифицировать часть накопленного опыта в машиночитаемые артефакты.

К таким артефактам относятся:

• Библиотеки промптов
• Инструкции для агентов
• Контекстные хранилища
• Наборы для оценки
• Данные обратной связи от людей
• Траектории использования инструментов
• Журналы решений
• Память агентов
• Данные для тонкой настройки
• Определения рабочих процессов

Это не значит, что ИИ уже владеет всем интеллектом организации.

Значительная часть опыта по-прежнему сосредоточена в людях, культуре, межличностных отношениях и неявных суждениях.

Но доля машиночитаемой части растёт.

Это делает вопросы собственности и переносимости более важными.

Модели всё чаще становятся товарным слоем

Дорого и технически сложно.

Для большинства компаний обучение модели с нуля экономически бессмысленно.

Реальное изменение в том, что у компаний появилось больше вариантов.

Например, Microsoft Foundry предоставляет доступ к моделям от Microsoft, OpenAI, Meta, DeepSeek и других поставщиков. Корпоративные шлюзы также могут направлять запросы к моделям, размещённым на других облачных платформах или предоставленным напрямую третьими сторонами.

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

Устойчивая ценность компании находится на следующих уровнях:

• Собственные данные
• Знания о рабочих процессах
• Внутренняя обратная связь
• Системы оценки
• Бизнес-правила
• Системы памяти
• Контекст клиентов
• Организационные решения

Именно эти уровни позволяют универсальным моделям проявлять уникальные ИИ-способности компании.

Тест на миграцию, который должна пройти каждая компания

Практический способ измерить степень блокировки ИИ — задать простой вопрос:

Если бы наш основной поставщик моделей завтра исчез, что бы мы потеряли?

Ответ должен быть задокументирован.

1. Доступ к модели

Может ли приложение указывать на другую конечную точку модели?
Если да, сколько кода нужно изменить?

2. Промпты

Хранятся ли системные промпты и инструкции агентов в собственном репозитории компании?
Можно ли их экспортировать и версионировать?

3. Контекст

Контролирует ли компания исходные документы и индексы поиска?
Потребует ли смена модели восстановления уровня знаний?

4. Система памяти

Можно ли экспортировать долговременную память?
Понимает ли организация её архитектуру?
Совместима ли эта память с другими агентными системами?

5. Интеграция инструментов

Построены ли интеграции инструментов на основе переносимых API или стандартов, таких как MCP?
Или критические рабочие процессы существуют только в проприетарном агентном продукте конкретного поставщика?

6. Метаданные

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

7. Система оценки

Можно ли протестировать те же критерии приемки с другой моделью?
Без воспроизводимого набора для оценки смена модели превращается в субъективную попытку миграции.

8. Идентификация и права доступа

Применяются ли бизнес-правила доступа собственной системой компании?
Миграция модели не должна требовать перестройки модели авторизации компании.

9. Соответствие требованиям

Может ли компания объяснить, куда направляются данные, какие модели их обрабатывают и что сохраняется?
Гибкость работы с несколькими моделями ценна только при сохранении целостности системы управления.

10. Операционное аварийное переключение

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

Несколько моделей не означают отправку каждого промпта повсюду

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

Например:

Нагрузка	Возможная стратегия маршрутизации
Низкорисковая классификация	Небольшая дешёвая размещённая модель
Сложное кодирование	Мощная модель для кодирования
Анализ длинных документов	Модель с длинным контекстом
Чувствительные внутренние данные	Частная или самостоятельно размещённая модель
Высокорисковые решения	Аудируемая корпоративная модель

Поддержка решений | Утверждённая модель + человеческая проверка
| Сбой поставщика | Предварительно утверждённая резервная модель |

Компаниям всё равно необходима политика управления данными, определяющая, какие модели могут обрабатывать какую информацию.

Выбор модели должен оставаться гибким.

Обработка данных должна быть строгой.

Архитектура сама по себе предполагает компромиссы

Предложение Наделлы звучит заманчиво, но разделение каждого уровня увеличивает объём инженерных работ.

Система с несколькими моделями может потребовать:

• Тестирования совместимости
• Нормализации промптов
• Адаптеров для конкретных поставщиков
• Инфраструктуры оценки
• Отслеживания затрат
• Стратегии маршрутизации
• Унифицированной наблюдаемости
• Проверок безопасности от нескольких поставщиков
• Контроля за размещением данных
• Логики отката для конкретных моделей

Небольшие компании могут разумно начать с одного поставщика.

Ключ в том, чтобы избежать ненужной блокировки.

Стартапам не нужно строить сложную внутреннюю ИИ-платформу до достижения product-market fit.

Они всё ещё могут:

• Хранить промпты в собственном репозитории кода
• Держать исходные данные вне модели поставщика
• Поддерживать переносимые шаблоны памяти
• Абстрагировать вызовы моделей за единым внутренним интерфейсом
• Записывать версии моделей
• Сохранять наборы данных для оценки

Эти относительно простые решения могут значительно облегчить будущую миграцию.

Стратегический вопрос в том, кому принадлежит цикл обучения

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

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

Компания ставит задачу.

Модель предлагает ответ.

Сотрудники исправляют ошибки.

Вызываются инструменты.

Измеряются результаты.

Рождается лучший рабочий процесс.

Если у организации есть этот цикл, накопленные знания могут переходить от одной модели к следующей.

Если цикл полностью принадлежит поставщику, компания может заметить улучшение AI-систем, но её собственная переносимость не возрастёт.

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

Это рекомендация о том, где должен храниться корпоративный интеллект.

Модель можно арендовать.

Но организация должна сохранить контекст, в котором модель действует.

Часто задаваемые вопросы

Как Сатья Наделла относится к зависимости от единственной AI-модели?

В интервью Фариду Закарии 26 июля 2026 года Наделла заявил, что компании не должны позволять одному поставщику AI контролировать их данные, метаданные, контекст, память и фреймворк агентов. Он предупредил, что, потеряв контроль над этими уровнями, компания рискует передать часть своего мыслительного процесса на аутсорсинг.

Считает ли Наделла, что компании должны строить собственные базовые модели?

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

Что такое фреймворк AI-агентов?

Фреймворк — это программный слой вокруг модели, управляющий промптами, инструментами, контекстом, памятью, планированием, повторными попытками, правами доступа, оценкой и выполнением. Его отделение от единственного поставщика модели способствует переносимости бизнес-процессов.

Что такое AI-шлюз?

AI-шлюз — это контролируемый слой между корпоративными приложениями и поставщиками моделей. Он централизует аутентификацию, маршрутизацию, ограничение скорости, мониторинг, политики, выбор модели и учётные данные поставщиков.

Почему компаниям следует сохранять AI-метаданные?

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

Может ли многомодельная архитектура устранить блокировку поставщика?

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

Что OpenAI предложила стартапам Y Combinator?

Согласно сообщению TechCrunch в мае 2026 года, OpenAI предоставила каждой компании в текущем наборе YC токены на сумму 2 миллиона долларов в обмен на долю через безасортиментный SAFE. Эта сделка независима от стандартного инвестиционного соглашения YC на 500 тысяч долларов.

Должны ли небольшие стартапы немедленно строить многомодельную платформу?

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

Связанные инструменты

• Microsoft Foundry: платформа Microsoft для обнаружения, оценки, развёртывания и эксплуатации множества AI-моделей.
• Microsoft Foundry Model Router: промежуточный слой маршрутизации для выбора подходящих моделей по качеству, стоимости и конфигурации.
• Azure API Management AI Gateway: управляемый шлюз для доступа к нескольким AI-моделям и инструментам MCP.
• Model Context Protocol: открытый протокол для подключения AI-приложений к инструментам и источникам данных через стандартизированный интерфейс.
• OpenTelemetry: фреймворк с открытым исходным кодом для сбора трассировок, метрик и логов в инфраструктуре AI-приложений.
• Y Combinator SAFE: официальный ресурс YC по структурам финансирования простых соглашений о будущем капитале.

Связанные ссылки

• Интервью Fareed Zakaria GPS с Сатьей Наделлой: 26 июля 2026 года Наделла обсуждает риски и выгоды корпоративного AI.
• TechCrunch: Сатья Наделла о зависимости от одного AI: сообщение о рекомендации Наделлы отделить корпоративный контекст, память и контроль от базовых моделей.
• Microsoft Foundry Model Router: официальная документация многомодельной системы маршрутизации Microsoft.
• [Обзор Azure AI Gateway](https://learn.microsoft. Обзор AI Gateway в Azure API Management: официальная документация по управлению несколькими AI-моделями и инструментами через единую корпоративную конечную точку.
• Унифицированный API моделей в Azure API Management: официальная документация Microsoft о представлении нескольких бэкендов моделей за единым клиентским API.
• TechCrunch: OpenAI предлагает стартапам YC токены на 2 млн долларов: сообщение о предложении OpenAI компаниям набора YC 2026 года "токены в обмен на долю".
• Стандартные инвестиционные условия Y Combinator: официальное описание YC стандартной инвестиционной структуры на 500 тысяч долларов.

Заключение

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

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

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

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