80% руководителей, опрошенных Cisco, считают агентный ИИ вопросом конкурентного выживания, но 65% компаний все еще работают на переходной или устаревшей инфраструктуре. Как пишет VentureBeat в партнерском материале Tata Communications, именно этот разрыв и делает сети для ИИ новым узким местом корпоративных проектов: модели уже ушли в прод, а сетевой слой под ними остался из эпохи предсказуемых ERP и веб-приложений. Для русскоязычных команд вывод неприятный, но полезный: без нормальной связности даже дорогой ИИ-стек быстро превращается в дорогую задержку.
Поводом для дискуссии стала довольно простая мысль: ИИ меняет не только вычисления, но и сам характер трафика. Постоянный inference, обмен сообщениями между агентами и потоковые данные в реальном времени создают непредсказуемую, круглосуточную нагрузку, под которую классические корпоративные сети просто не проектировались. Если прежние бизнес-приложения могли пережить задержку в 100-500 миллисекунд, то для критичных ИИ-сценариев, по оценке Tata Communications, планка сместилась ниже 10 миллисекунд. Это уже не косметический апгрейд канала, а смена инженерной модели: проектировать теперь нужно не просто пропускную способность, а гарантированную реакцию сети под конкретную нагрузку.
Отсюда и главный практический эффект: сеть перестает быть фоном и становится прямым фактором надежности и стоимости ИИ-сервиса. Модель для антифрода, оптимизации поставок или скоринга в реальном времени бесполезна в тот момент, когда данные к ней приехали с опозданием из-за перегруженного канала. Капил, вице-президент Tata Communications по глобальным сетевым сервисам, прямо говорит, что каждая миллисекунда такой задержки может иметь операционную или финансовую цену. Отдельная проблема в том, что многие компании по привычке считают публичный интернет нормальной заменой глобальной корпоративной сети. Пока трафик живет в одной стране, это иногда выглядит терпимо. Как только появляются международные маршруты, облачные платформы и несколько площадок обработки, отсутствие сквозного контроля быстро вылезает в продакшене.
Ситуацию усложняет сама архитектура современных ИИ-систем. Они все реже живут в одном ЦОДе и все чаще размазаны между облаком, on-prem, edge-узлами, SaaS-сервисами и устройствами. На этом фоне узким местом становится не только север-юг трафик, но и интенсивный east-west обмен между GPU и внутренними сервисами. Параллельно растет и поверхность атаки: пользователи, партнеры, приложения и данные оказываются распределены по множеству сред, а, по оценке Капила, боты с ИИ уже формируют около 37% онлайн-трафика. Многие предприятия отвечали на это привычным способом, навешивая новые инструменты поверх старых. Результат предсказуем: фрагментация, разные политики безопасности и почти нулевая общая видимость. Tata, разумеется, продвигает здесь SASE как способ собрать сеть и безопасность в одну облачную архитектуру, но сама постановка проблемы вполне узнаваема и без маркетинговой обвязки.
На этом фоне сети для ИИ начинают вести себя скорее как программная платформа, чем как набор железок с ручной конфигурацией. В материале VentureBeat ключевой тезис звучит так: сетевой слой должен стать наблюдаемым, управляемым через API и способным сам перенаправлять нагрузку по наиболее эффективному и безопасному пути. Для инфраструктурных команд это означает сдвиг от ручного тушения аварий к описанию правил, политик и ожидаемых бизнес-результатов. Вместо расплывчатого требования вроде «хотим высокую производительность» появляется почти контрактная формулировка: задержка для конкретной ИИ-нагрузки не должна превышать 10 миллисекунд в 99,999% времени. В качестве иллюстрации Tata приводит свою платформу IZO Data Centre Dynamic Connectivity, которая, по заявлению компании, умеет за секунды перестраивать маршруты при сбоях и снижать операционные расходы до 30%. Еще один пример из того же ряда — совместный проект Tata и AWS по строительству крупной AI-ready сети между площадками в Мумбаи, Хайдарабаде и Ченнаи.
Для разработчиков, платформенных инженеров и CIO из этого следует довольно приземленный список действий. Если компания всерьез запускает агентные системы, генеративные сервисы или real-time inference, сетевые вопросы надо вытаскивать в проект на раннем этапе, а не оставлять «на потом» после выбора модели и GPU. Придется считать путь данных между источником, хранилищем, моделью и пользователем, отдельно смотреть на всплески нагрузки и отдельно — на внутренний east-west трафик. Придется резервировать емкость для критичных сценариев, а не отправлять их в общую очередь с остальным корпоративным трафиком. И, вероятно, придется признать неприятное: сети для ИИ уже нельзя оценивать по старой логике среднего потребления и абстрактной доступности. Здесь важнее предсказуемость, масштабирование по требованию и понятные SLA, иначе бизнес либо упрется в деградацию сервиса, либо начнет без разбора перепокупать каналы «на всякий случай».
Следующий большой спор вокруг enterprise-ИИ, похоже, будет не о том, какую модель выбрать, а о том, кто в компании отвечает за путь данных от источника до GPU и обратно. Пока сеть считается второстепенной статьей расходов, компании будут продолжать покупать ускорители и лицензии, а терять деньги на миллисекундах и слепых зонах; исходный материал с цитатами и цифрами доступен в .