Искусственный интеллект быстро выявляет слабые места в корпоративных облачных стратегиях. Во многих крупных компаниях ситуация развивается по похожему сценарию: руководство утверждает амбициозную AI-дорожную карту, расходы на облако растут на 40, 50 или даже 70%, но реальные AI-нагрузки, которые хорошо выглядели в презентации для совета директоров, начинают буксовать в продакшене. Они выходят за рамки бюджета, не выдерживают нагрузки или не доходят до конечных пользователей в рабочем виде.
Проблема не в самих AI-моделях. Модели работают. Проблема в том, что многие организации строили свои AI-амбиции на облачных стратегиях, созданных для другой эпохи: для SaaS-приложений, предсказуемого трафика и линейных моделей затрат. AI-нагрузки ломают все эти предположения одновременно.
Почему AI ломает традиционные облачные подходы
На протяжении десятилетия стратегия cloud-first хорошо служила крупным компаниям. Облако давало гибкость, снижало капитальные затраты и упрощало доступ к вычислительным ресурсам.
Но традиционные корпоративные нагрузки были относительно предсказуемыми: веб-приложения, ERP-системы, базы данных, аналитические пайплайны. Они масштабировались постепенно, а расходы можно было заранее смоделировать в финансовой таблице.
Генеративный AI и агентные AI-системы меняют эту картину.
Когда компании переводят AI в продакшен, появляются новые типы нагрузок:
- инференс в реальном времени;
- retrieval-пайплайны;
- векторный поиск;
- real-time decisioning;
- цепочки вызовов инструментов агентными системами.
В результате облачная модель начинает ломаться сразу по нескольким направлениям.
Пять главных проблем AI-нагрузок в облаке
AI-нагрузки создают для инфраструктуры принципиально новые требования:
- тренировочные кластеры требуют гораздо более высокой плотности энергопотребления, чем стандартные вычисления;
- инференс нуждается в задержках на уровне миллисекунд, а география сети может этому мешать;
- векторные базы данных создают неожиданные скачки затрат;
- агентные нагрузки могут запускать сотни связанных вызовов инструментов;
- правила суверенитета данных ограничивают места, где эти нагрузки вообще можно запускать.
На уровне платформы облако может выглядеть подходящим решением. Но на уровне конкретной AI-нагрузки оно часто оказывается неэффективным или слишком дорогим.
Почему расходы на AI оказываются неожиданными
Первый сюрприз для руководителей — стоимость. Причем эти расходы часто скрыты.
AI-затраты могут отображаться в биллинге как обычные строки: compute, storage, instances. Они редко прямо помечаются как «AI», поэтому финансовым и IT-командам сложно быстро понять, где именно возникает перерасход.
Основные источники лишних затрат обычно находятся в трех слоях.
1. Стоимость LLM API
При stateless-вызовах система может каждый раз повторно отправлять полную историю диалога. Даже внедрение с несколькими сотнями пользователей способно быстро превысить изначальный токен-бюджет.
2. Простаивающие GPU
Команды часто резервируют мощности под пиковую нагрузку, но фактическая загрузка GPU остается на уровне 10–20%. В результате прогнозы по стоимости AI-инфраструктуры часто оказываются заниженными.
3. Векторные базы данных и retrieval-слой
Самый недооцененный источник затрат — хранение, ввод-вывод, объем запросов и обновление embedding-данных. Эти расходы могут не выглядеть как AI-расходы до момента получения счета.
Риски, которые часто недооценивают: устойчивость и контроль
В разговорах об AI-инфраструктуре обычно доминируют стоимость и задержка. Но есть еще два критически важных параметра:
- устойчивость — сможет ли AI-зависимая система пережить сбой, корректно деградировать и предсказуемо восстановиться;
- контроль — кто может наблюдать, остановить, проверить и аудировать работу системы.
AI приносит новые типы отказов, с которыми традиционная архитектура раньше не сталкивалась:
- единые точки отказа GPU в критичных инференс-сценариях;
- агентные пайплайны, которые могут остановиться на середине процесса без rollback;
- деградация моделей из-за drift или throttling, которую сложно заметить сразу.
Часто компании проектируют устойчивость для традиционных приложений, а затем запускают поверх них AI, не проверяя, сохраняются ли прежние гарантии.
Четыре вопроса перед запуском AI в продакшен
Перед запуском AI-системы необходимо заранее ответить на несколько вопросов:
- Что произойдет при сбое сети?
- Что произойдет при деградации модели?
- Что произойдет, если агент выполнит процесс только наполовину?
- Кто имеет право остановить систему и провести аудит?
Если эти вопросы не заданы заранее, компания рискует столкнуться с дорогой переделкой уже после первого инцидента.
Что показали облачные провайдеры весной 2026 года
Крупные cloud-провайдеры активно развивают инфраструктуру для AI. Их недавние анонсы показывают важный сдвиг: речь уже идет не только о том, где запускаются нагрузки, а о том, как управлять агентами, их правами, действиями и безопасностью.
Microsoft представила модель Agent Computer с контейнерами исполнения и машинной идентичностью для агентов.
AWS развивает Amazon Bedrock AgentCore, включая runtime, память, идентификацию и аудит.
Google продвигает agent gateway и суверенные механизмы контроля для cross-cloud-трафика.
Общий тренд очевиден: агентный AI становится не только технологической возможностью, но и экономической, операционной и управленческой проблемой.
От выбора платформы — к решению о размещении нагрузки
Одна из главных ошибок компаний — отсутствие прозрачного процесса принятия решений о том, где должна работать конкретная AI-нагрузка.
Во многих организациях такие решения принимаются неформально: платформенные команды выбирают инфраструктуру под давлением сроков, а затем повторяют этот подход для десятков и сотен use case.
В результате нагрузки по умолчанию накапливаются в публичном облаке — не потому, что это лучший выбор, а потому что другого процесса нет. После этого появляются перерасходы на 30–50%.
Проблема часто не в том, что публичное облако было неправильным вариантом. Проблема в том, что осознанного выбора вообще не было.
Шесть критериев для размещения AI-нагрузок
Каждая AI-нагрузка должна оцениваться до запуска по шести параметрам.
1. Задержка
Нужно определить, какой режим требуется:
- real-time до 10 мс — edge или on-prem;
- interactive от 50 до 500 мс — облако;
- batch — отложенная обработка.
2. Стоимость и TCO
Важно учитывать не только compute, но и:
- токены;
- загрузку GPU;
- запросы к векторным базам;
- egress;
- стоимость одной операции или одного сценария.
3. Устойчивость
Нужно заранее определить:
- архитектуру failover;
- поведение в degraded mode;
- SLA восстановления;
- rollback-политику.
4. Контроль
Ключевые вопросы:
- есть ли наблюдаемость;
- сохраняются ли audit trails;
- кто имеет право остановить систему;
- можно ли откатить действия.
5. Чувствительность данных
Нужно учитывать:
- требования суверенитета;
- правила приватности;
- compliance;
- защиту интеллектуальной собственности.
6. Интеграция
Важно оценивать:
- зависимости от legacy-систем;
- сложность пайплайнов;
- ограничения по резидентности данных;
- близость к источникам данных.
Примеры размещения разных AI-нагрузок
Разные сценарии требуют разной инфраструктуры.
Клиентский чат-бот
Задержка 200–500 мс, средняя предсказуемость затрат, низкий риск по данным. Подходит публичное облако с reserved instances.
Fraud detection в реальном времени
Задержка менее 10 мс, высокая чувствительность данных. Лучше подходит on-prem или суверенное частное облако.
Клиническая поддержка принятия решений
Задержка 100–300 мс, критичные данные. Возможный вариант — суверенное облако или выделенный VPC.
Прогнозирование спроса
Batch-нагрузка, высокая предсказуемость затрат, низкие риски по данным. Подходят spot instances или запланированные облачные вычисления.
Computer vision на производственной линии
Задержка менее 5 мс, средняя чувствительность данных. Рациональный путь — edge-узлы.
Внутренний knowledge assistant
Задержка 1–3 секунды, переменная стоимость токенов, высокий риск по интеллектуальной собственности. Возможный вариант — private cloud с on-prem retrieval.
Почему repatriation становится нормой
Возврат AI-нагрузок из публичного облака в частные или локальные среды становится все более распространенным.
Причины обычно повторяются:
- требования к суверенитету данных;
- перерасходы;
- задержки;
- необходимость real-time-производительности;
- сложность контроля;
- риски зависимости от облачного провайдера.
Для многих компаний вопрос уже не в том, использовать ли публичное облако вообще. Вопрос в том, какие конкретно нагрузки должны оставаться в облаке, а какие лучше перенести ближе к данным, пользователям или производственным системам.
Агентный AI требует новой дисциплины
Агентные системы делают инфраструктурную дисциплину еще более важной.
Обычный чат-бот — это один тип governance. Но автономный агент, который утверждает закупки, онбордит клиентов или вызывает десятки инструментов, требует совершенно другого уровня контроля.
Один агент может связывать 20–100 вызовов, каждый из которых имеет собственную стоимость, задержку и вероятность отказа.
Поэтому для агентных систем нужны:
- отдельные правила наблюдаемости;
- идентичность агента;
- ограничения полномочий;
- audit trail;
- rollback;
- право остановки;
- сценарии частичного отказа.
Платформы уже начали предоставлять технические механизмы. Но во многих компаниях пока нет политики, которая объясняет, как этими механизмами пользоваться.
Что делают лидеры
Компании, которые получают от AI устойчивую ценность, отличаются не только моделями и не размером облачных контрактов.
Их главное отличие — дисциплина в принятии инфраструктурных решений.
Они делают пять вещей:
- классифицируют каждый AI use case на входе по ключевым параметрам еще до выделения инфраструктуры;
- разделяют бюджеты на эксперименты, продакшен-инференс и обучение моделей;
- считают unit economics: стоимость одного инференса, одного запроса, одного agent run;
- заранее определяют триггеры для repatriation;
- прописывают resilience contract, правила наблюдаемости и rollback до масштабирования.
План действий для CIO на 90 дней
Для CIO практический план может выглядеть так.
1. Провести аудит всех AI-нагрузок
Нужно оценить каждую AI-нагрузку в продакшене по следующим критериям:
- задержка;
- стоимость;
- суверенитет данных;
- объем;
- устойчивость;
- контроль;
- интеграция.
2. Разделить AI-инфраструктурные бюджеты
Эксперименты, обучение моделей и production inference должны учитываться отдельно. Иначе управлять расходами будет практически невозможно.
3. Определить unit economics
Стоимость одного запроса, одного инференса или одного запуска агента должна стать инженерным KPI, а не неожиданностью в конце месяца.
4. Установить триггеры repatriation
Нужно заранее определить условия, при которых нагрузку стоит пересмотреть и, возможно, перенести из публичного облака в private cloud, on-prem или edge.
5. Прописать rollback и observability до масштабирования
Особенно для агентных систем необходимо заранее определить:
- как отслеживаются действия;
- кто может остановить процесс;
- как выполняется откат;
- что происходит при частичном сбое.
Главный вывод
Организации, которые реально продвигаются в AI, отличаются не самыми сложными моделями и не самыми крупными облачными контрактами.
Их отличает способность последовательно отвечать на вопрос: что, где, почему и на каких условиях должно работать.
Это уже не просто IT-функция. Это стратегическая компетенция, которая требует участия CIO, согласования с CFO и ответственности на уровне руководства.
Облачные провайдеры уже предоставили инфраструктуру для запуска и управления AI на разных уровнях архитектуры. Теперь главный дефицит — не в технологиях, а в операционной модели.
Компании, которые создадут эту модель сейчас, получат прочную основу для AI в масштабе. Остальные будут накапливать дорогой backlog исправлений.