Microsoft Copilot / Azure AI architecture
Как выбрать облачный, локальный или гибридный ИИ: данные, безопасность, размещение, качество, TCO, команда и измеримый пилот для бизнеса в Казахстане.
Tugelbay Konabayev, Marketing Specialist · 2 сентября 2026 г.
Эти блоки отвечают на практические вопросы без скрытого текста и без неподтвержденных обещаний по срокам, стоимости или результату.
Если компания уже работает в Microsoft 365 и сценарий связан с письмами, встречами и документами, обычно разумно сначала проверить Microsoft 365 Copilot или ограниченного агента Copilot Studio. Собственную облачную или локальную систему стоит рассматривать, когда нужны отдельное приложение, особая модель, изоляция, offline-режим или нестандартная интеграция.
Нет. Локальное размещение меняет границу контроля, но не создаёт безопасность автоматически. Нужны identity, сегментация сети, управление секретами, обновления, журналирование, резервное копирование, контроль моделей и runtime, мониторинг и incident response. Плохо управляемый local-контур может быть рискованнее зрелого облачного сервиса.
Единого ответа для всех сервисов нет. Microsoft публикует отдельные условия для Microsoft 365 Copilot и моделей, продаваемых через Azure/Microsoft Foundry. Проверять нужно конкретный сервис, модель, тип deployment, tenant, регион, Product Terms и Data Protection Addendum на дату решения.
Гибрид уместен, когда часть данных или действий должна оставаться в контролируемом локальном контуре, а для остальных задач полезны облачные модели, масштабирование и managed-эксплуатация. Гибрид имеет смысл только с явной маршрутизацией данных, owner, журналированием и правилами отказа, а не как неопределённое сочетание двух сред.
Нет. Residency — один из критериев рядом с категорией данных, договорными условиями, доступом администраторов, резервными копиями, логами, моделью угроз, качеством, latency и поддержкой. Для персональных данных Казахстана финальное решение должен подтвердить legal/compliance owner по фактическому потоку данных.
Нужно измерять оба слоя. Хорошая модель бесполезна, если данные недоступны, ответы нельзя проверить или сервис нестабилен. Надёжная инфраструктура также не спасает слабое качество. Пилот должен одновременно проверять точность, groundedness, latency, безопасность, эксплуатацию, adoption и стоимость единицы полезного результата.
Когда основной сценарий живёт в Microsoft 365, пользовательские permissions уже управляются, а бизнесу нужны готовые рабочие функции без создания отдельного приложения. Собственная система оправдана, если требуются особая логика, интерфейс, модель, изолированный контур или интеграции, которые нельзя разумно закрыть готовым продуктом.
Универсального срока нет. Пилот должен охватить достаточно повторов реального процесса, чтобы увидеть качество, редкие ошибки, нагрузку и поддержку. Вместо обещания календарного срока зафиксируйте число реальных задач, контрольный набор, пользователей, пиковую нагрузку и критерии остановки.
Для типовой работы с письмами, встречами и документами сначала проверяйте Microsoft 365 Copilot. Для отдельного AI-приложения — Azure AI / Microsoft Foundry. Local/self-hosted LLM оправдана при доказанном требовании к изоляции, offline или особой среде выполнения. Гибрид выбирайте, когда поток данных можно явно разделить. Решение принимают по пилоту, а не по ярлыку архитектуры.
Вопрос «облако или локально?» слишком широкий. Компания выбирает не место для абстрактной модели, а контур для конкретного процесса: какие данные входят, что модель с ними делает, кто получает ответ, какие действия разрешены, как проверяется результат и кто отвечает за систему после запуска.
Один бизнес может одновременно использовать три маршрута. Microsoft 365 Copilot помогает сотрудникам в рабочем контексте Microsoft 365. Агент в Copilot Studio отвечает по утверждённой базе знаний и запускает ограниченные действия. Отдельное приложение в Azure AI / Microsoft Foundry решает кастомную задачу. Локальная модель обрабатывает изолированный набор данных без передачи исходного содержимого во внешний inference. Это не противоречие, если у каждого маршрута есть owner и граница данных.
Начните с пяти вопросов:
Если команда не может ответить на эти вопросы, выбор архитектуры преждевременен. «Local» не исправит неизвестный процесс, а «cloud» не создаст владельца данных.
| Критерий | Облачный AI | Local / self-hosted LLM | Гибридный AI |
|---|---|---|---|
| Граница данных | Данные обрабатываются по условиям конкретного managed-сервиса, tenant, региона и deployment. | Inference можно держать в контролируемой среде; полный путь всё равно включает storage, логи, backup и админ-доступ. | Категории данных и операции делятся по явной политике между локальной и облачной средой. |
| Governance | Можно использовать tenant controls, identity, data policies, audit и service controls, если они настроены. | Все политики, роли, журналы и lifecycle модели проектирует и поддерживает ваша команда. | Нужны controls в обеих средах плюс контроль маршрутизации между ними. |
| Качество и выбор моделей | Быстрый доступ к managed-моделям и обновлениям; поведение может меняться вместе с сервисом. | Можно закрепить модель и runtime, но качество ограничено выбранным артефактом, данными и доступным железом. | Задачи можно маршрутизировать по качеству, чувствительности и стоимости, но тестовая матрица сложнее. |
| Latency и нагрузка | Зависит от региона, сети, квот, модели и нагрузки сервиса; проще масштабировать при корректных лимитах. | Latency предсказуема только после теста на целевом железе; capacity нужно покупать и резервировать. | Можно держать быстрые или критичные операции локально, но сетевой hop и policy gateway добавляют задержку. |
| Offline-режим | Не подходит для полной сетевой изоляции. | Возможен, если весь runtime, retrieval, identity и observability действительно автономны. | Нужен заранее определённый degraded mode: что продолжает работать при потере облака. |
| Инфраструктура | Провайдер управляет базовой платформой, а клиент — конфигурацией, доступом, данными и использованием. | Нужны compute, storage, сеть, резерв, обновления, мониторинг и физическая эксплуатация. | Нужны обе основы и надёжный integration/security слой между ними. |
| TCO | Потребление и лицензии заметны быстрее, но рост, storage, network, monitoring и support нужно считать отдельно. | Нет честной оценки без оборудования, резерва, энергии, площадки, инженеров, обновлений и простоя. | Может оптимизировать отдельные потоки, но почти всегда увеличивает архитектурную и операционную сложность. |
| Срок до пилота | Обычно меньше подготовительной инфраструктуры, но readiness данных и security остаются обязательными. | До бизнес-теста нужно собрать и защитить рабочий runtime, поэтому подготовка часто шире. | Пилот требует заранее реализовать хотя бы одну реальную политику разделения data-flow. |
| Поддержка | Есть service support, но клиент всё равно владеет use case, данными, prompt/retrieval и пользовательским процессом. | Проблемы модели, runtime, drivers и железа сходятся у внутреннего owner или подрядчика. | Нужно заранее разделить ответственность и диагностику между двумя контурами. |
Таблица не выдаёт победителя, потому что его нет без конкретного сценария. Она показывает цену контроля: чем больше компонентов компания забирает к себе, тем больше решений и on-call остаётся у неё.
Microsoft 365 Copilot уместен, когда задача уже живёт в Word, Excel, PowerPoint, Outlook, Teams, SharePoint и других сервисах Microsoft 365. По текущему Microsoft Learn, возможности различаются по лицензии и конфигурации, а доступ к организационному контексту ограничивается правами пользователя.
Это сокращает объём разработки, но не отменяет readiness. Если в SharePoint слишком широкие permissions, есть ownerless sites или устаревшие guest-доступы, AI делает старую проблему заметнее. Перед пилотом используйте чеклист Copilot readiness и отдельно определите сайты, пользователей и сценарии, входящие в scope.
Microsoft публикует Enterprise Data Protection и privacy commitments для подписанных корпоративных сценариев. Это основание для проверки, а не универсальное обещание. На архитектурной сессии нужно заново открыть актуальные Product Terms, Data Protection Addendum, tenant settings и описание конкретного Copilot experience.
Copilot Studio подходит, когда нужен агент с инструкциями, источниками знаний, authentication, каналами и действиями. Он может быть ближе к бизнес-процессу, чем универсальный помощник: например, отвечать по утверждённой базе или инициировать workflow.
Преимущество low-code не означает отсутствие архитектуры. Нужно выбрать environment, identity, connectors, data policies, lifecycle, monitoring и владельца публикации. Географическая residency также проверяется по текущей документации Copilot Studio и фактическим функциям агента. Подробнее о границах продукта — в гайде по Copilot Studio.
Microsoft Foundry — текущее название Azure-платформы для создания, оценки, развёртывания и governance кастомных AI-приложений и агентов. Этот маршрут нужен, если компания создаёт отдельный пользовательский интерфейс, собственную orchestration-логику, API, retrieval, оценку моделей или интеграции, которые не помещаются в готовый рабочий продукт.
Здесь больше свободы и больше ответственности. Команда выбирает модель и deployment, проектирует network access, identity, storage, secrets, evaluation, safety controls, telemetry и support. Доступность моделей зависит от региона и cloud, поэтому архитектуру нельзя фиксировать по старому скриншоту или общему списку «Azure AI». Проверяйте текущую доступность перед пилотом и перед production.
Для инфраструктурного и residency-контекста используйте Azure service route и гайд по Azure migration, data residency и FinOps.
Local/self-hosted LLM — это модель и inference runtime (среда выполнения модели), которыми организация управляет в собственном или выделенном контролируемом контуре. Это может быть сервер в ЦОД, workstation для ограниченного пилота или изолированный cluster. Важен не маркетинговый ярлык, а фактическая граница: где лежит model artifact, куда попадают prompts, retrieval data, cache, логи и ответы, кто имеет admin access и откуда приходят обновления.
Local имеет смысл, когда требование нельзя закрыть настройкой managed-сервиса: полноценный offline, строгая изоляция, закреплённая версия модели, специфический runtime, предсказуемая локальная latency или обработка данных, которые после customer-specific review нельзя передавать внешнему inference.
Но local не означает «данные никуда не уходят» без проверки. Telemetry runtime, package repositories, remote administration, резервные копии, мониторинг, внешняя база векторного поиска или интеграционный API могут пересечь границу. Для честного threat model нарисуйте весь поток, включая эксплуатационные сервисы.
Производительность local LLM тоже нельзя переносить с одного теста на другой. Нужны точные модель, версия артефакта и квантование, runtime, параметры запуска, context, workload и железо. Воспроизводимый benchmark локальной модели на конкретной конфигурации здесь служит только образцом методики описания теста: это не рекомендуемый стек, не прогноз вашей скорости и не расчёт ROI.
Перед выбором local зафиксируйте:
Гибрид — не компромисс «немного cloud, немного local». Это архитектура с проверяемым правилом, какое действие выполняется в каком контуре.
Практические паттерны:
Для каждого паттерна нужна deny-by-default логика: какие данные нельзя отправлять, что происходит при неизвестной классификации, где журналируется решение, кто может изменить policy и как остановить маршрут. Если ответ звучит «система сама поймёт», гибридный контроль пока не спроектирован.
Официальные источники Adilet устанавливают требования Казахстана к сбору, обработке, защите и хранению персональных данных. Их применимость к конкретному AI data-flow нельзя определить по одной формулировке или по месту inference: нужно установить категории данных, роль базы, операции, копии, логи, резерв, участников обработки и правовые основания. Поэтому из закона нельзя автоматически вывести ни «весь AI должен быть локальным», ни «конкретный cloud deployment допустим».
Этот гайд не является юридической консультацией. Для каждого пилота legal/compliance owner вместе с security и data owner должен проверить:
Data residency не равна data security. Данные могут находиться в требуемой географии и оставаться слишком широко доступными. И наоборот, сильное шифрование не отменяет требований к месту хранения, если они применимы. Поэтому residency, security и legal approval — три отдельных gates.
Сравнение «API стоит за запрос, а local уже куплен» почти всегда неполно. Нужна одна единица сравнения: например, стоимость принятого экспертом ответа, обработанного документа с требуемым качеством или успешно завершённого процесса.
Для облачного маршрута учитывайте:
Для local добавьте:
Для hybrid считайте оба контура плюс routing, интеграцию, двойную observability и диагностику. Гибрид может быть правильным по риску, но его нельзя заранее объявлять самым дешёвым.
Не начинайте с local/self-hosted, если:
Local — обоснованная архитектура, а не символ независимости. Если главная причина звучит «не хотим зависеть от облака», перечислите, какие зависимости исчезают и какие появляются: hardware, model license, runtime, drivers, supply chain и инженеры.
Облачный маршрут нужно остановить или переработать, если:
Сначала проверьте, нельзя ли сузить проблему: минимизировать данные, разделить процесс, использовать approved knowledge, ограничить actions или добавить human approval. Если нельзя — local или hybrid становится предметом пилота, а не автоматическим ответом.
| Сценарий | Стартовый маршрут | Почему | Что может изменить решение |
|---|---|---|---|
| Подготовка писем, встреч и документов сотрудниками | Microsoft 365 Copilot | Рабочий контекст уже находится в Microsoft 365; меньше отдельной разработки. | Oversharing, неподготовленные permissions, отсутствие принятого use case или запрет на часть данных. |
| FAQ или внутренний агент по утверждённой базе | Copilot Studio | Нужны управляемые знания, инструкции, authentication, channels и actions. | Нестандартный интерфейс, pro-code orchestration, строгая изоляция или сложный runtime. |
| Кастомный AI-продукт или отраслевое приложение | Azure AI / Microsoft Foundry | Нужны модельный выбор, API, evaluation, deployment и собственная логика приложения. | Offline, запрещённый data-flow, фиксированная модель или доказанный local TCO. |
| Изолированная обработка чувствительных документов | Local pilot | Основное требование — контролируемая граница и отсутствие внешнего inference. | Недостаточное качество, отсутствие команды, скрытые внешние зависимости или разрешённая минимизация данных. |
| Часть данных нельзя передавать, но нужен сильный managed-model | Hybrid pilot | Data-flow можно разделить через classification, минимизацию и policy routing. | Невозможность надёжно классифицировать данные или слишком высокая сложность эксплуатации. |
| Работа при потере внешней связи | Local или hybrid fallback | Offline — end-to-end требование к runtime и зависимостям. | Достаточный резервный канал, некритичность простоя или невозможность поддерживать local capacity. |
| Первое знакомство бизнеса с AI без выбранного процесса | Не выбирать платформу | Сначала нужны use case, owner, data scope и измеримый baseline. | Появление повторяемой задачи и ответственного бизнес-владельца. |
Не сравнивайте готовый cloud product с сырой local demo. Для каждого варианта зафиксируйте одинаковый scope, данные, model/version, retrieval, instructions, tools, hardware/region и load profile. Если один вариант получает больше контекста или ручной настройки, это должно быть видно в выводах.
Начните с синтетического или обезличенного набора, затем допускайте реальные данные только после проверки архитектуры. Решение должно назвать разрешённые категории, запрещённые категории и approver. Фраза «не вводите ничего конфиденциального» без технических и организационных controls недостаточна.
Пилот успешен не тогда, когда модель однажды дала красивый ответ. Заранее установите пороги по пяти группам.
После пилота решение может быть scale, revise, change architecture или stop. Остановка — нормальный результат, если качество, риск или TCO не проходят порог. Намного дешевле получить этот вывод на ограниченном scope, чем после закупки capacity или широкого rollout.
Соберите короткий decision record:
Не нужно навсегда выбирать «облачную стратегию» или «локальную стратегию». Нужен обратимый выбор для одного класса задач. Модели, сервисы и регуляторный контекст меняются; хороший decision record позволяет пересмотреть архитектуру без переписывания истории.
Проверено 2 сентября 2026 года. Названия продуктов, функции, модели, регионы и договорные условия могут измениться; перед решением откройте актуальные версии источников.
Материал не даёт юридической консультации, не подтверждает соответствие конкретной архитектуры требованиям Казахстана, не обещает безопасность, ROI, срок или стоимость и не приписывает Promise Group услуги по внедрению сторонних local/self-hosted LLM. Все выводы нужно проверять на фактическом data-flow, договорных условиях и результатах пилота конкретной компании.
Не обязательно. Microsoft 365 Copilot работает в контексте Microsoft 365 и разрешений пользователя, но решение о составе доступных данных принимается через tenant, permissions, sharing и governance. Не нужно включать в пилот всё: выбирайте утверждённый набор сайтов, документов и пользователей.
Не обязательно. Сам inference может работать локально, но обновления, лицензирование, observability, внешние API, поиск, интеграции или получение моделей могут зависеть от сети. Offline-режим нужно проверять как end-to-end требование, а не как свойство одного model file.
Нет. Гибрид определяется не процентом ресурсов, а разделением ответственности и потоков. Например, чувствительные записи остаются локально, а обезличенный контекст обрабатывается в облаке; либо локальный фильтр маршрутизирует задачи между двумя средами по политике.
Нет. Для cloud учитываются потребление, storage, network, monitoring, support и рост нагрузки. Для local — оборудование, резерв мощности, электричество, площадка, внедрение, обновления, on-call, безопасность и простой. Сравнивайте стоимость принятого бизнес-результата при одинаковом качестве и риске.
Не подменяйте решение обещанием шифрования. Уточните запрещённые категории и операции, затем рассмотрите локальную обработку, минимизацию, маскирование, токенизацию, обезличивание или гибридную маршрутизацию. Финальную схему должен утвердить legal/security owner на реальном data-flow.
Нужен назначенный эксплуатационный owner и доступные компетенции по моделям, runtime, инфраструктуре, security, мониторингу и обновлениям. Это может быть не отдельный отдел, но обязанности и on-call нельзя оставлять неявными.
Используйте одинаковый закрытый набор реальных задач, единую рубрику, экспертную проверку и порог критических ошибок. Отдельно фиксируйте модель, версию, артефакт, квантование, runtime, параметры, retrieval и железо: без этого сравнение невоспроизводимо.
Не автоматически. Сначала разберите ошибки и security findings, подтвердите owner, capacity, поддержку, budget guardrails, обучение пользователей и процедуру rollback. Пилот доказывает пригодность в ограниченном scope, а не универсальную готовность всей организации.
Google Preferred Sources
Добавьте Promise Group в предпочтительные источники, чтобы чаще находить наши свежие гайды и новости о Microsoft-технологиях.
Зафиксируйте сценарий, категории данных, ограничения, контрольный набор и критерии успеха. Это позволит проверить Microsoft cloud route и понять, нужен ли отдельный архитектурный review; материал не обещает внедрение сторонней self-hosted LLM.