[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:ru":3,"public-menus:all":38,"post:what-is-an-ai-platform-architect-models-data-runtime-security-and-operations:ru":205,"related:post:what-is-an-ai-platform-architect-models-data-runtime-security-and-operations:ru:1":2451},{"statusCode":4,"data":5,"message":37},200,{"tenantId":6,"lang":7,"defaultLang":8,"siteUrl":9,"contactEmail":10,"brandName":11,"logoUrl":12,"siteName":11,"siteDescription":13,"ogImage":10,"robotsIndex":14,"socialLinks":10,"reservedSlugs":10,"seoPolicy":15},"stajic","ru","de","https:\u002F\u002Fstajic.de",null,"Stajic Platform","\u002FLogo_Planet.svg","Stajic Portal",true,{"branding":16,"relatedContent":17,"crossDomainLinks":18},{"logoUrl":12},{"enabled":14},[19,22,25,28,31,34],{"url":20,"label":21,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Ffigure.rocks","figure.rocks",{"url":23,"label":24,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Floving.rocks","loving.rocks",{"url":26,"label":27,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.com","bazify.com",{"url":29,"label":30,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.de","bazify.de",{"url":32,"label":33,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.at","bazify.at",{"url":35,"label":36,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.ba","bazify.ba","Portal settings resolved",[39,45],{"id":40,"name":41,"location":42,"isActive":14,"isDefault":43,"items":44},1,"main-navigation","header",false,[],{"id":46,"name":47,"location":48,"isActive":14,"isDefault":14,"items":49},4,"main-menu","sidebar",[50,66,79,93,103,118,133],{"id":51,"title":52,"url":60,"target":61,"icon":62,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":64,"portfolioId":10,"children":65},"item-18",{"de":53,"en":54,"es":55,"fr":56,"it":54,"ru":57,"sr":58,"zh":59},"Startseite","Home","Inicio","Accueil","Главная","Почетна","首页","\u002Ffull-stack-web-developer-munich-performance-seo-and-maintainable-builds","_self","i-lucide-home","page",111,[],{"id":67,"title":68,"url":75,"target":61,"icon":76,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":77,"portfolioId":10,"children":78},"item-22",{"de":69,"en":69,"es":70,"fr":69,"it":71,"ru":72,"sr":73,"zh":74},"Vision","Visión","Visione","Видение","Визија","想象","\u002Fueber-uns-webdesign-muenchen-webaplikation","i-lucide-eye",113,[],{"id":80,"title":81,"url":89,"target":61,"icon":90,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":91,"portfolioId":10,"children":92},"item-19",{"de":82,"en":83,"es":84,"fr":83,"it":85,"ru":86,"sr":87,"zh":88},"Leistungen","Services","Servicios","Servizi","Услуги","Услуге","服务","\u002Fservices-dienstleistungen-muenchen","i-lucide-wrench",116,[],{"id":94,"title":95,"url":99,"target":61,"icon":100,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":101,"portfolioId":10,"children":102},"item-23",{"de":96,"en":96,"es":96,"fr":96,"it":96,"ru":97,"sr":97,"zh":98},"Blog","Блог","博客","\u002Fblog","i-lucide-book-open",112,[],{"id":104,"title":105,"url":114,"target":61,"icon":115,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":116,"portfolioId":10,"children":117},"item-32",{"de":106,"en":107,"es":108,"fr":109,"it":110,"ru":111,"sr":112,"zh":113},"Neue Technologien","New Technologies","Nuevas tecnologías","Nouvelles technologies","Nuove tecnologie","Новые технологии","Нове технологије","新技术！","\u002Fneue-webtechnologien","i-lucide-sparkles",122,[],{"id":119,"title":120,"url":129,"target":61,"icon":130,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":131,"portfolioId":10,"children":132},"item-20",{"de":121,"en":122,"es":123,"fr":124,"it":125,"ru":126,"sr":127,"zh":128},"Kontakt","Contact us!","Contacto","Contact","Contatto","Контакт","Контактирајте нас","联系我们！","\u002Fcontact","i-lucide-mail",115,[],{"id":134,"title":135,"url":144,"target":61,"icon":145,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":147},"item-21",{"de":136,"en":137,"es":138,"fr":139,"it":140,"ru":141,"sr":142,"zh":143},"Unsere Arbeit","Our Work","Nuestro trabajo","Nos réalisations","I nostri lavori","Наши работы","Наши радови","文件夹","\u002Fportfolio","i-lucide-briefcase",114,[148,161,175,181,193],{"id":149,"title":150,"url":144,"target":61,"icon":159,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":160},"item-24",{"de":151,"en":152,"es":153,"fr":154,"it":155,"ru":156,"sr":157,"zh":158},"Alle Projekte","All Projects","Todos los proyectos","Tous les projets","Tutti i progetti","Все проекты","Сви пројекти","所有项目","i-lucide-grid-3x3",[],{"id":162,"title":163,"url":171,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":174},"item-29",{"de":164,"en":165,"es":166,"fr":167,"it":168,"ru":169,"sr":170,"zh":143},"Local Roots, Global Reach","Local Roots - Global Reach","Empresa local ","Entreprise locale","Azienda locale","Местная компания","Локално предузеће глобално тржиште","\u002Fportfolio\u002Flocal-roots-global-reach-communication-media-systems-for-modern-business","i-lucide-folder","custom",[],{"id":176,"title":177,"url":179,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":180},"item-28",{"de":178,"en":178,"es":178,"fr":178,"it":178,"ru":178,"sr":178,"zh":178},"Solr Suggester","\u002Fportfolio\u002Fsolr-fuzzy-suggester-und-solr-infix-suggester-abfrage-ueber-ajax-und-filterung",[],{"id":182,"title":183,"url":191,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":192},"item-27",{"de":184,"en":185,"es":186,"fr":187,"it":188,"ru":189,"sr":190,"zh":185},"Firmenwebseite SEO","Company Website SEO","Sitio web corporativo SEO","Site web d’entreprise SEO","Sito web aziendale SEO","Корпоративный сайт SEO","Пословна веб-страница SEO","\u002Fportfolio\u002Fseo-sem-branding-mobile-webseite-muenchen",[],{"id":194,"title":195,"url":203,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":204},"item-31",{"de":196,"en":197,"es":198,"fr":199,"it":200,"ru":201,"sr":202,"zh":197},"Digitalisierungsportal","Digitalization Portal","Portal de digitalización","Portail de numérisation","Portale di digitalizzazione","Портал цифровизации","Портал за дигитализацију","\u002Fportfolio\u002Fdigitalisierungsportal-archiv-museum-bibliothek-ead-lido-mets-mods",[],{"statusCode":4,"data":206,"message":2450},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":1203,"featuredImage":1204,"featuredImageAlt":1205,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":1206,"publishedAt":1207,"createdAt":1208,"updatedAt":1209,"seoLocalePaths":1210,"categories":1219,"author":1232,"translations":1237},"484","Что такое архитектор AI-платформы? Модели, данные, среда выполнения, безопасность и операции","what-is-an-ai-platform-architect-models-data-runtime-security-and-operations","\u003Cp>\u003Cstrong>Архитектор AI-платформы\u003C\u002Fstrong> проектирует переиспользуемую основу для ИИ, через которую множество приложений, команд или контекстов арендаторов получают доступ к моделям, данным и поиску, средам выполнения агентов и инструментов, идентификации и разрешениям, оценке, наблюдаемости, квотам, секретам и возможностям развёртывания. Эта роль шире, чем инфраструктура, но уже, чем владение каждым продуктом с поддержкой ИИ: её центральная ответственность — решать, \u003Cstrong>что должно быть общим, как общие возможности управляются и изолируются, и что должно оставаться специфичным для конкретного решения\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--info my-6 rounded-xl border p-5 border-blue-300 bg-blue-50 dark:border-blue-900 dark:bg-blue-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Прямой ответ\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>Архитектор AI-платформы проектирует общую техническую и операционную основу для ИИ-систем.\u003C\u002Fstrong> Вместо проектирования одного ассистента или одного рабочего процесса эта роль определяет переиспользуемые контракты и границы для доступа к моделям и провайдерам, шлюзов и маршрутизации, сервисов поиска, сред выполнения агентов, доступа к инструментам, идентификации и изоляции арендаторов, секретов, оценки, телеметрии, развёртывания и управления жизненным циклом.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Примечание о терминологии\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>Архитектор AI-платформы — это практическое обозначение роли, а не универсально стандартизированное название должности.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 определяет концепции для описаний архитектуры, а не эту роль. Разные организации могут распределять эти обязанности между архитекторами платформ, архитекторами решений, корпоративными архитекторами, архитекторами безопасности, специалистами по MLOps\u002FLLMOps и командами платформенной инженерии. В этой статье термин используется для обозначения архитектурной ответственности за переиспользуемый слой AI-платформы.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Примечание об актуальности источников — 8 октября 2026 г.\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Изложенные здесь устойчивые архитектурные принципы не зависят от поставщика. Актуальные рекомендации Microsoft, AWS и NIST используются как внешние свидетельства реализации и управления. NIST сообщает, что AI RMF 1.0 пересматривается; функции платформ поставщиков, продукты-шлюзы, среды выполнения агентов и возможности моделей развиваются быстрее, чем архитектурные принципы, поэтому зависящие от версии решения по реализации необходимо перепроверять перед развёртыванием.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Содержание\">\u003Cstrong class=\"editorjs-toc__title\">Содержание\u003C\u002Fstrong>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-0\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-6\" class=\"editorjs-toc__link\">Что на самом деле проектирует архитектор AI-платформы?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">Простейший пример\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-15\" class=\"editorjs-toc__link\">Где заканчивается простой пример\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-18\" class=\"editorjs-toc__link\">Самое важное решение платформы: общее или специфичное для решения\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-21\" class=\"editorjs-toc__link\">Карта архитектурной ответственности\u003C\u002Fa>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-1\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-22\" class=\"editorjs-toc__link\">1. Доступ к моделям и провайдерам\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-26\" class=\"editorjs-toc__link\">2. Шлюз, маршрутизация, квоты и контроль затрат\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-30\" class=\"editorjs-toc__link\">3. Общие данные, извлечение и сервисы обоснования\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-34\" class=\"editorjs-toc__link\">4. Среда выполнения агентов и инструментов\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-38\" class=\"editorjs-toc__link\">5. Идентификация, изоляция арендаторов и авторизация\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-42\" class=\"editorjs-toc__link\">6. Секреты, учётные данные и границы доверия\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-45\" class=\"editorjs-toc__link\">7. Оценка, наблюдаемость и возможность аудита\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-49\" class=\"editorjs-toc__link\">8. Среда выполнения, развёртывание и локальность\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-52\" class=\"editorjs-toc__link\">9. Жизненный цикл платформы, совместимость и подключение\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-55\" class=\"editorjs-toc__link\">Практическая модель control-plane \u002F execution-plane \u002F solution-plane\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-59\" class=\"editorjs-toc__link\">Что должен создавать архитектор AI-платформы?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-61\" class=\"editorjs-toc__link\">Работа — это в основном компромиссы, а не максимальная централизация\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-63\" class=\"editorjs-toc__link\">Чем это отличается от смежных ролей?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-66\" class=\"editorjs-toc__link\">Доказательства реализации: как эти границы платформы проявляются в моей собственной работе\u003C\u002Fa>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-1\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-68\" class=\"editorjs-toc__link\">Aaasaasa AI Client: разделение провайдера, среды выполнения и разрешений\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-73\" class=\"editorjs-toc__link\">Aaasaasa AI CMS: авторизация в рамках тенанта как граница платформы\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-77\" class=\"editorjs-toc__link\">Source of Truth Research Engine: общая механика поиска без общей истины\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-82\" class=\"editorjs-toc__link\">Как современные архитектурные руководства поддерживают этот охват платформы\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-88\" class=\"editorjs-toc__link\">Распространённые заблуждения\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-90\" class=\"editorjs-toc__link\">Режимы отказа, которые должен предотвращать AI Platform Architect\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-92\" class=\"editorjs-toc__link\">Практическая последовательность решений по архитектуре платформы\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-94\" class=\"editorjs-toc__link\">Краевые случаи и ограничения роли\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-100\" class=\"editorjs-toc__link\">Что могло бы изменить этот ответ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-103\" class=\"editorjs-toc__link\">Контрольный список архитектора ИИ-платформы\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-105\" class=\"editorjs-toc__link\">Заключение\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-109\" class=\"editorjs-toc__link\">Связанные канонические знания\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-114\" class=\"editorjs-toc__link\">Часто задаваемые вопросы\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-116\" class=\"editorjs-toc__link\">Глоссарий\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-118\" class=\"editorjs-toc__link\">Первичные источники и актуальные рекомендации по архитектуре\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-6\">Что на самом деле проектирует архитектор AI-платформы?\u003C\u002Fh2>\n\u003Cp>Объектом работы является \u003Cstrong>платформа\u003C\u002Fstrong>: набор общих возможностей, который сокращает повторяющуюся работу по интеграции, сохраняя при этом явные границы безопасности, данных и эксплуатации. Платформа может предоставлять множеству потребляющих решений доступ к моделям, адаптеры провайдеров, примитивы поиска, выполнение агентов, брокеры инструментов, применение политик, оценку, телеметрию и сервисы развёртывания.\u003C\u002Fp>\n\u003Cp>Платформа ценна не просто потому, что её компоненты централизованы. Она ценна, когда потребители получают стабильные возможности с чёткими контрактами, ответственностью, изоляцией, наблюдаемостью и правилами жизненного цикла. Поэтому ключевой архитектурный вопрос не «Какую модель должны использовать все?», а \u003Cstrong>«Какие обязанности можно безопасно стандартизировать и переиспользовать, не стирая требования каждого решения?»\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Архитектура решения и архитектура платформы решают разные задачи по охвату\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Архитектор AI-решения\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Архитектор AI-платформы\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Основной охват\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">One concrete AI-enabled product, workflow or application.\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Reusable AI capabilities consumed by multiple solutions, teams or tenant contexts.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Главный вопрос\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">How should this solution meet its business, data, security, quality and operational requirements?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Which shared capabilities and controls should solutions consume, and where must solution-specific ownership remain?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Ответственность за данные\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Defines which domain data is authoritative and how the solution may use it.\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Provides storage, retrieval, provenance or access primitives without automatically becoming the authority for every domain.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Оценка\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Defines task-specific quality and acceptance criteria.\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Provides reusable evaluation, telemetry and release mechanisms; it cannot define every domain's success threshold.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Жизненный цикл\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Owns the lifecycle of the specific workload.\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Owns shared capability versions, compatibility, onboarding, quotas, policy and operational contracts.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-10\">Простейший пример\u003C\u002Fh2>\n\u003Cp>Представьте, что в организации есть пять продуктов с поддержкой ИИ: внутренний ассистент по документам, копилот службы поддержки клиентов, агент для разработки программного обеспечения, рабочий процесс проверки договоров и ассистент поиска по товарам. Каждый продукт мог бы независимо интегрировать API моделей, хранить учётные данные, реализовывать повторные попытки, собирать метрики токенов, создавать код поиска и строить собственные разрешения для инструментов.\u003C\u002Fp>\n\u003Cp>Такое дублирование дорого и опасно, когда каждая команда изобретает свою модель безопасности и эксплуатации. Общая платформа вместо этого может предлагать одобренные подключения к провайдерам, обнаружение моделей, квоты, учётные данные, доступ с учётом арендатора, общую телеметрию, переиспользуемые сервисы поиска и контракт среды выполнения агентов и инструментов.\u003C\u002Fp>\n\u003Cp>Но платформа должна остановиться на правильной границе. Решение для проверки договоров может требовать полномочий по юридическим документам и правил цитирования, которых нет у программного агента. Ассистенту поиска по товарам могут понадобиться специфичные для торговли правила актуальности и авторизации. \u003Cstrong>Переиспользуемая инфраструктура не делает всю предметную истину переиспользуемой.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Общий путь AI-запроса\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Потребитель идентифицирует себя\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Вызывающее приложение, пользователь, сервис, команда или арендатор входят через аутентифицированную идентичность и явную область действия.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Применяется политика платформы\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Уровни шлюза и политик определяют разрешённых провайдеров, модели, квоты, пути данных, инструменты и режимы выполнения.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Выполняется общая возможность\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Запрос может использовать вывод модели, поиск, среду выполнения агента, доступ к инструментам или другой переиспользуемый сервис платформы.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Контекст, специфичный для решения, остаётся авторитетным\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Потребляющее решение предоставляет предметные правила, намерение пользователя, полномочия по данным, ограничения конкретной задачи и логику приёмки.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Собираются телеметрия и свидетельства\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Платформа фиксирует идентичность, маршрут, модель и провайдера, задержку, стоимость, ошибки, активность инструментов и другие разрешённые сигналы наблюдаемости.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Результат возвращается по контракту решения\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Решение остаётся ответственным за то, приемлем ли вывод для его пользователя и предметной области.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-15\">Где заканчивается простой пример\u003C\u002Fh2>\n\u003Cp>Централизация не является автоматически архитектурой. Единая точка входа перед несколькими API моделей полезна, но сама по себе она не создаёт AI-платформу. Производственной платформе также нужны границы идентичности, контракты возможностей, обработка работоспособности и жизненного цикла провайдеров, квоты, ответственность за секреты, наблюдаемость, правила совместимости, средства безопасности, дисциплина выпуска и чёткая эксплуатационная ответственность.\u003C\u002Fp>\n\u003Cp>Противоположная ошибка также распространена: поместить каждый промпт, векторный индекс, бизнес-правило, агента и рабочий процесс приложения в один «AI-бэкенд». Это создаёт монолит, общий статус которого случаен, а не архитектурен. \u003Cstrong>Платформа должна стандартизировать сквозные возможности, а не поглощать предметную ответственность только потому, что задействован ИИ.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch2 id=\"section-18\">Самое важное решение платформы: общее или специфичное для решения\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Область возможностей\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Хороший кандидат для общей ответственности платформы\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Обычно остаётся специфичным для решения\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Доступ к моделям\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Одобренные подключения к провайдерам, адаптеры, учётные данные, проверка работоспособности, примитивы маршрутизации, квоты\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Приёмка моделей для конкретных задач, поведение промптов, порог качества\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Извлечение данных\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Примитивы загрузки, извлечение, индексирование, API поиска, контракты происхождения, хуки авторизации\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Авторитетный корпус, правила актуальности, доменные метаданные, достаточность доказательств\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Агенты и инструменты\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Жизненный цикл среды выполнения, реестр\u002Fброкер инструментов, обеспечение разрешений, трассировка, отмена\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Бизнес-процесс, семантика разрешённых действий, политика эскалации, успех задачи\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Безопасность\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Интеграция удостоверений, хранение секретов, обеспечение политик, контракты аудита, механизмы изоляции арендаторов\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Классификация данных, правила бизнес-авторизации, принятие рисков для конкретной области\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Оценка\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Стенд, механика версионирования наборов данных, телеметрия, рабочий процесс экспериментов\u002Fрелизов\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Эталонные данные, доменный тестовый набор, порог приёмки, результат для пользователя\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Операции\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Шаблон развёртывания, работоспособность, метрики, интеграция с инцидентами, управление мощностями\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">SLO решения, если они различаются, влияние на непрерывность бизнеса, runbook'и для конкретных нагрузок\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Caside class=\"editorjs-callout editorjs-callout--success my-6 rounded-xl border p-5 border-emerald-300 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Принцип платформы\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>Совместно используйте механику и средства контроля там, где повторное использование реально; оставляйте полномочия и приёмку там, где ими владеет домен.\u003C\u002Fstrong> Это предотвращает две противоположные ошибки: дублирование инфраструктуры повсюду и центральная платформа, которая ложно становится владельцем данных, политик и качества каждого приложения.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-21\">Карта архитектурной ответственности\u003C\u002Fh2>\n\u003Ch3 id=\"section-22\">1. Доступ к моделям и провайдерам\u003C\u002Fh3>\n\u003Cp>Архитектор платформы определяет, как потребители обнаруживают и вызывают модели, не заставляя каждое приложение жёстко кодировать одного провайдера. Это включает адаптеры провайдеров, идентификаторы моделей, метаданные возможностей, аутентификацию, проверки работоспособности, конфигурацию конечных точек, нормализацию запросов и поведение совместимости.\u003C\u002Fp>\n\u003Cp>Абстракция провайдера должна оставаться честной. Разные провайдеры предоставляют разные ограничения контекста, семантику инструментов, поведение структурированного вывода, мультимодальные возможности, средства безопасности, кэширование, ценообразование и режимы отказа. Хорошая абстракция создаёт стабильный контракт платформы, сохраняя доступ к возможностям, которые нельзя осмысленно свести к общему знаменателю.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Не путайте абстракцию с притворством, что провайдеры идентичны\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">API по наименьшему общему знаменателю может упростить миграцию, но также может стереть возможности, которые важны. Архитектура должна определять, какие функции переносимы, какие специфичны для провайдера и как потребители узнают об этом различии.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch3 id=\"section-26\">2. Шлюз, маршрутизация, квоты и контроль затрат\u003C\u002Fh3>\n\u003Cp>Общий AI-шлюз может централизовать аутентификацию, маршрутизацию, ограничение скорости, повторные попытки, лимиты токенов, атрибуцию использования и обеспечение политик. Текущее руководство Microsoft по AI Gateway явно рассматривает лимиты токенов в минуту, квоты и изоляцию нескольких проектов как задачи платформы; AWS аналогично предоставляет квоты на аккаунт и модель и централизованные средства контроля.\u003C\u002Fp>\n\u003Cp>Таким образом, шлюз — это больше, чем обратный прокси, когда он несёт специфичную для ИИ политику и операционную семантику. Но он не должен молча принимать бизнес-решения. Политика маршрутизации может предпочитать работоспособную локальную модель, более дешёвого провайдера или регионально совместимую конечную точку; однако приемлемость этого маршрута для конкретной задачи всё ещё остаётся контрактом между платформой и решением.\u003C\u002Fp>\n\u003Cp>Маршрутизация также требует семантики отказов. Если предпочтительная модель недоступна, платформа должна знать, разрешён ли резервный вариант, требует ли облачный маршрут явного согласия, допустима ли модель с меньшими возможностями и как это решение отображается в наблюдаемости.\u003C\u002Fp>\n\u003Ch3 id=\"section-30\">3. Общие данные, извлечение и сервисы обоснования\u003C\u002Fh3>\n\u003Cp>Сервисы извлечения данных — сильные кандидаты для платформы, потому что разбор, разбиение на фрагменты, индексирование, лексический поиск, семантический поиск, фильтрация метаданных, происхождение и механика цитирования переиспользуемы. Однако платформа не должна путать общий движок извлечения с общим источником истины.\u003C\u002Fp>\n\u003Cp>Решение всё ещё владеет такими вопросами: какой корпус является авторитетным? Какая версия действительна? Может ли этот пользователь видеть этот документ? Насколько свежими должны быть данные? Что считается достаточным доказательством? Можно ли сгенерировать ответ, если извлечение не удалось? Это требования домена и решения, даже когда платформа предоставляет механизм извлечения.\u003C\u002Fp>\n\u003Cp>Эта граница особенно важна в мультитенантных системах. Технически общий индекс или векторный сервис не оправдывает кросс-тенантную видимость. Контекст авторизации должен сохраняться через извлечение, а не добавляться только после того, как результаты поиска уже пересекли границу.\u003C\u002Fp>\n\u003Ch3 id=\"section-34\">4. Среда выполнения агентов и инструментов\u003C\u002Fh3>\n\u003Cp>Агентные системы добавляют переиспользуемые задачи среды выполнения: жизненный цикл потока\u002Fсессии, циклы планирования, регистрация инструментов, вызов инструментов, отмена, тайм-ауты, одобрения человеком, интерфейсы памяти\u002Fсостояния, протоколы удалённых агентов и корреляция трассировок. Платформа может предоставить эти механизмы, чтобы каждый продукт не пересобирал их заново.\u003C\u002Fp>\n\u003Cp>Платформа также должна отделять разрешения инструментов от возможностей модели. То, что модель способна сгенерировать команду оболочки, не означает, что среда выполнения должна разрешать выполнение оболочки. Граница разрешений принадлежит архитектуре приложения\u002Fсреды выполнения и должна обеспечиваться независимо от модели.\u003C\u002Fp>\n\u003Cp>Текущие рекомендации AWS по агентному ИИ подчеркивают ограниченных агентов, явные полномочия, сквозную трассировку, версионированные артефакты поведения и человеческий надзор, соразмерный последствиям. Это вопросы, обеспечивающие работу платформы, но потребляющее решение всё ещё определяет, какие действия являются законными для его домена.\u003C\u002Fp>\n\u003Ch3 id=\"section-38\">5. Идентификация, изоляция арендаторов и авторизация\u003C\u002Fh3>\n\u003Cp>Платформы ИИ часто находятся перед высокоценными моделями, проприетарными данными и инструментами, способными выполнять действия. Поэтому аутентификация — это только начало. Архитектура должна передавать контекст пользователя, сервиса, приложения и арендатора через каждую привилегированную операцию, где это необходимо.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>RBAC и изоляция арендаторов решают разные задачи.\u003C\u002Fstrong> RBAC отвечает на вопрос, что может делать идентичность; изоляция арендаторов отвечает на вопрос, с ресурсами какого арендатора эта идентичность может действовать. Платформа, которая проверяет роли, но теряет контекст арендатора, всё ещё может раскрыть не те данные.\u003C\u002Fp>\n\u003Cp>Текущие рекомендации Microsoft по рабочим нагрузкам ИИ явно рекомендуют сегментацию идентичности и доступ к контенту с учётом авторизации. Рекомендации AWS по многопользовательской платформе генеративного ИИ аналогично рассматривают логическую изоляцию, централизованное управление и возможность аудита как вопросы платформы.\u003C\u002Fp>\n\u003Ch3 id=\"section-42\">6. Секреты, учётные данные и границы доверия\u003C\u002Fh3>\n\u003Cp>Платформа должна определить, кто владеет ключами провайдера, удалёнными bearer-токенами, материалами для подписи и учётными данными инструментов, где они хранятся, какой процесс может к ним получить доступ, как они ротируются и могут ли они когда-либо попасть в браузер или недоверенный рендерер.\u003C\u002Fp>\n\u003Cp>Это архитектурная граница, а не деталь реализации. Если каждое потребляющее приложение копирует учётные данные провайдера в свою собственную конфигурацию, организация дублирует как операционную нагрузку, так и радиус поражения. Централизация может снизить этот риск только в том случае, если сама платформа имеет более узкие, поддающиеся аудиту пути доступа.\u003C\u002Fp>\n\u003Ch3 id=\"section-45\">7. Оценка, наблюдаемость и возможность аудита\u003C\u002Fh3>\n\u003Cp>Многоразовая платформа может предоставлять средства оценки, идентификаторы трассировки, метаданные модели\u002Fпровайдера, метрики токенов и стоимости, задержку, частоту ошибок, связь версий промпта\u002Fмодели, трассировки агентов\u002Fинструментов и контролируемое логирование. AWS и Microsoft рассматривают наблюдаемость и оценку как ключевые производственные вопросы для рабочих нагрузок ИИ.\u003C\u002Fp>\n\u003Cp>Оценка платформы и оценка решения должны оставаться раздельными. Платформа может проверить, что конечная точка работоспособна, версия модели проходит общий набор регрессионных тестов и трассировки полны. Она не может решить, что юридический ответ, медицинский рабочий процесс или рекомендация продукта приемлемы без предметно-специфической эталонной истины и критериев приёмки.\u003C\u002Fp>\n\u003Cp>Логирование также создаёт границу конфиденциальности. Журналы промптов и ответов могут содержать конфиденциальные или проприетарные данные. Поэтому архитектор платформы должен решить, что логируется, редактируется, сэмплируется, сохраняется и доступно, а не предполагать, что больше телеметрии всегда безопаснее.\u003C\u002Fp>\n\u003Ch3 id=\"section-49\">8. Среда выполнения, развёртывание и локальность\u003C\u002Fh3>\n\u003Cp>Архитектор платформы решает, как общие возможности ИИ развёртываются и становятся доступными: управляемые облачные сервисы, самостоятельно размещённые конечные точки, локальный вывод, гибридная маршрутизация, контейнеризированные сервисы, настольные среды выполнения, частные сети или изолированные среды. Важное различие — между \u003Cstrong>тем, где выполняется процесс управления\u002Fсреды выполнения\u003C\u002Fstrong>, и \u003Cstrong>тем, где фактически происходят вывод и обработка данных\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>Локальный клиент всё ещё может вызывать облачную модель. Облачная плоскость управления может маршрутизировать к локальной модели. Удалённый агент может выполнять инструменты внутри сети клиента. Поэтому архитектурные диаграммы должны показывать границы доверия и потоков данных, а не использовать «локальный» и «облачный» как расплывчатые ярлыки.\u003C\u002Fp>\n\u003Ch3 id=\"section-52\">9. Жизненный цикл платформы, совместимость и подключение\u003C\u002Fh3>\n\u003Cp>Многоразовая возможность становится платформой только тогда, когда потребители могут полагаться на неё с течением времени. Для этого требуются версионированные контракты, правила миграции, политика совместимости, вывод из эксплуатации, тестирование релизов, откат, ответственность за инциденты, планирование мощности, документация и путь для подключения новых команд или приложений.\u003C\u002Fp>\n\u003Cp>Быстро развивающиеся экосистемы ИИ делают это особенно важным. Имена моделей, SDK, версии протоколов, API провайдеров и возможности безопасности меняются независимо. Платформа должна поглощать часть этой волатильности, не скрывая изменения, которые существенно влияют на поведение решения.\u003C\u002Fp>\n\u003Ch2 id=\"section-55\">Практическая модель control-plane \u002F execution-plane \u002F solution-plane\u003C\u002Fh2>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Предлагаемая архитектурная модель\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Приведённая ниже трёхуровневая модель — это практический способ рассуждать об ответственности; это не стандарт ISO, NIST, Microsoft или AWS. Её цель — сделать границы ответственности явными.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Уровень\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Типичные обязанности\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Не должен неявно владеть\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Control plane платформы\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Реестр провайдеров, политика моделей, квоты, конфигурация тенантов, идентичности, секреты, правила маршрутизации, версии возможностей, конфигурация развёртывания\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Бизнес-логика приложения или доменная истина\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Execution\u002Fdata plane платформы\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Запросы на инференс, операции поиска, выполнение агентов\u002Fинструментов, извлечение, индексация, отправка телеметрии, применение политик\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Кросс-тенантный доступ только потому, что инфраструктура общая\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Solution plane\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Пользовательский рабочий процесс, промпты\u002Fинструкции, выбор авторитетного корпуса, доменная авторизация, бизнес-правила, оценка и приёмка задач\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Низкоуровневая интеграция с провайдерами, которой явно владеет платформа\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Это разделение помогает диагностировать дрейф платформы. Если приложение должно знать все учётные данные и эндпоинты конкретного провайдера, контракт платформы слишком тонкий. Если платформа решает, какая запись клиента юридически авторитетна или приемлем ли доменный ответ, платформа перешла в зону ответственности решения.\u003C\u002Fp>\n\u003Ch2 id=\"section-59\">Что должен создавать архитектор AI-платформы?\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Архитектурный артефакт\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Назначение\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Карта возможностей платформы\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Определяет, что предоставляет платформа, кто это потребляет и какие возможности остаются вне области охвата.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Контракт провайдера\u002Fмодели\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Определяет провайдеров, модели, возможности, границы абстракции, метаданные маршрутизации и семантику отката.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Модель идентичности и тенантности\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Определяет идентичность пользователя\u002Fсервиса\u002Fприложения, контекст тенанта, точки подключения RBAC\u002FABAC и изоляцию ресурсов.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Политика шлюза и квот\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Определяет ограничения скорости, бюджеты токенов\u002Fстоимости, управление маршрутизацией, повторные попытки и поведение при нагрузке.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Контракт поиска\u002Fданных\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Определяет приём данных, происхождение, поиск, метаданные, распространение авторизации и то, где остаётся доменная авторитетность.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Контракт агента\u002Fинструмента\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Определяет жизненный цикл среды выполнения, регистрацию инструментов, разрешения, согласования, отмену и поведение трассировки.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Модель секретов и границ доверия\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Определяет владение учётными данными, хранение, границы процессов, ротацию и пути конфиденциальных данных.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Контракт оценки и телеметрии\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Определяет общие метрики, трассировки, связи с наборами данных\u002Fверсиями, политику логирования и точки расширения решения.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Политика жизненного цикла и совместимости\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Определяет версии, миграции, вывод из эксплуатации, релизы, откат, ответственность за инциденты и адаптацию.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-61\">Работа — это в основном компромиссы, а не максимальная централизация\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Типичные компромиссы платформы\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Давление A\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Давление B\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Абстракция провайдера\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Stable portable platform API\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Access to provider-specific capabilities and fast innovation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Повторное использование\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Shared services reduce duplication\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Isolation and domain autonomy prevent unsafe coupling\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Управление\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Central policy and auditability\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Team speed and local experimentation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Наблюдаемость\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Rich traces for debugging and evaluation\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Privacy, data minimization and logging cost\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Доступность\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Fallback and multi-provider resilience\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Predictable quality, compliance and data-location guarantees\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Область охвата платформы\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">More reusable capabilities\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Smaller blast radius and less platform lock-in\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-63\">Чем это отличается от смежных ролей?\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Роль\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Основная архитектурная область\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Архитектор AI-решений\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Конкретное AI-решение и его сквозные требования, границы, компромиссы и приёмка в продакшене.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Архитектор AI-платформы\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Переиспользуемые AI-возможности и операционные\u002Fбезопасностные контракты, потребляемые несколькими решениями или командами.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Корпоративный архитектор\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Общеорганизационный портфель бизнес\u002Fтехнологий, согласование возможностей и управления на более широком уровне.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Архитектор или специалист MLOps \u002F LLMOps\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Жизненный цикл моделей и AI, развёртывание, эксперименты, наблюдаемость, релизы и операционные практики; может сильно пересекаться, но не владеет автоматически всей общей платформой приложений.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Платформенный инженер \u002F SRE\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Реализует и эксплуатирует инфраструктуру платформы, надёжность, автоматизацию и опыт разработчиков; архитектурная ответственность может быть разделена с архитектором платформы.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">AI \u002F программный инженер\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Реализует модели, интеграции, сервисы, агентов, поиск и продуктовую функциональность в рамках согласованной архитектуры.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Эти границы организационные, а не универсальные. В небольшой команде один человек может нести несколько обязанностей. В регулируемом предприятии они могут быть разделены между группами архитектуры, безопасности, платформы, данных и эксплуатации. Полезное различие — это \u003Cstrong>область архитектурной ответственности\u003C\u002Fstrong>, а не должность, напечатанная на организационной схеме.\u003C\u002Fp>\n\u003Ch2 id=\"section-66\">Доказательства реализации: как эти границы платформы проявляются в моей собственной работе\u003C\u002Fh2>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Доказательства оригинальной реализации\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Следующие разделы описывают конкретные паттерны из моих собственных проектов. Они являются доказательством того, что эти архитектурные границы были реализованы или явно спроектированы в реальном коде и проектных системах. Они \u003Cstrong>не\u003C\u002Fstrong> являются утверждением, что проекты вместе уже constitute коммерчески развёрнутую корпоративную AI-платформу.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch3 id=\"section-68\">Aaasaasa AI Client: разделение провайдера, среды выполнения и разрешений\u003C\u002Fh3>\n\u003Cp>Aaasaasa AI Client — это локальное настольное AI-рабочее пространство, созданное с использованием Nuxt 4, Electron и TypeScript. Его AI Hub намеренно разделяет \u003Cstrong>агента\u002Fклиента, провайдера, модель, расположение соединения\u002Fсреды выполнения, разрешения и веб-клиент\u003C\u002Fstrong>, вместо того чтобы рассматривать их как одно значение конфигурации.\u003C\u002Fp>\n\u003Cp>Реализация включает прямые адаптеры провайдеров, интеграцию среды выполнения агента Codex, локальные пути Ollama\u002FLM Studio, сервисы, совместимые с OpenAI, централизованные разрешения рабочего пространства, хранение учётных данных в главном процессе, DuckDB, поддержку Qdrant\u002Fвекторов, извлечение PDF\u002Fчитаемости и аутентифицированный доступ к каталогам на основе MCP.\u003C\u002Fp>\n\u003Cp>Два урока платформы особенно актуальны. Во-первых, локальная среда выполнения — это не то же самое, что локальный инференс: локальный процесс Codex всё ещё может использовать облачную модель. Во-вторых, автоматическая маршрутизация не выполняет неявный откат с локального на платный облачный инференс. Это делает политику маршрутизации и локальность среды выполнения явными, а не выведенными из меток интерфейса.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Реализованная граница\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Значение для архитектуры платформы\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Агент vs провайдер vs модель\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Разные обязанности могут развиваться независимо, вместо того чтобы быть скрытыми за одним селектором «AI».\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Разрешения отдельно от модели\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Полномочия файловой системы\u002Fинструментов принадлежат политике среды выполнения, а не возможностям модели.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Секреты в главном процессе\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Владение учётными данными следует за границей привилегированного процесса, а не за рендерером\u002Fинтерфейсом.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Состояние провайдера и обнаружение моделей\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Маршрутизация и доступность — это вопросы среды выполнения\u002Fплатформы.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Никакого неявного облачного отката\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Семантика стоимости, локальности и передачи данных остаётся явными политическими решениями.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch3 id=\"section-73\">Aaasaasa AI CMS: авторизация в рамках тенанта как граница платформы\u003C\u002Fh3>\n\u003Cp>Кодовая база Aaasaasa AI CMS представляет отдельный пример реализации: RBAC в рамках тенанта реализуется через роли, разрешения и назначения ролей пользователям, привязанные к идентификатору тенанта. Системные разрешения группируются по возможностям, а поиск и обновление ролей остаются в рамках тенанта.\u003C\u002Fp>\n\u003Cp>Это само по себе не является доказательством полноценной AI-платформы, но напрямую относится к одной из самых сложных границ общей платформы: переиспользуемый сервис должен сохранять \u003Cstrong>кто что может делать\u003C\u002Fstrong> и \u003Cstrong>для какого тенанта\u003C\u002Fstrong>. Добавление AI-инференса или поиска поверх прикладной платформы не отменяет этого требования.\u003C\u002Fp>\n\u003Cp>Архитектурное следствие состоит в том, что шлюзы моделей, сервисы поиска и агенты должны использовать уже установленный контекст идентичности\u002Fтенанта, а не изобретать параллельную вселенную авторизации только для AI.\u003C\u002Fp>\n\u003Ch3 id=\"section-77\">Source of Truth Research Engine: общая механика поиска без общей истины\u003C\u002Fh3>\n\u003Cp>Source of Truth Research Engine представляет третий пример реализации. Различные режимы исследования используют общее ядро доказательств: источники, артефакты, происхождение, утверждения, связи, противоречия, эталонную модель и журнал аудита. Система также обеспечивает локальный лексический поиск, опциональный семантический поиск, извлечение, снимки состояния и происхождение на основе SHA-256.\u003C\u002Fp>\n\u003Cp>Проект явно рассматривает поиск и семантическое сходство как сигналы для обнаружения, а не как доказательства. Результат должен быть прослежен до конкретного источника и локатора, прежде чем он сможет подтвердить утверждение. Именно это различие необходимо AI-платформе: \u003Cstrong>переиспользуемая механика поиска может быть общей, тогда как авторитет доказательств остаётся под управлением потребляющей методологии и предметной области.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Движок также демонстрирует, почему одна общая платформа не требует одной общей интерпретации. Исторический, научно-технический, рыночно-аналитический и мониторинговый режимы могут переиспользовать базовую инфраструктуру доказательств, сохраняя методологию, специфичную для каждого режима.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--success my-6 rounded-xl border p-5 border-emerald-300 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Что эти реализации демонстрируют вместе\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Во всех этих проектах переиспользуемый паттерн — это не «один бэкенд для всего». Это \u003Cstrong>разделение ответственности плюс явные контракты\u003C\u002Fstrong>: разделение провайдера\u002Fмодели\u002Fсреды выполнения, авторизация с учётом тенанта, границы учётных данных, переиспользуемые примитивы данных\u002Fпоиска, происхождение и предметно-специфичный авторитет. Будущая интегрированная платформа нуждалась бы в стабильных контрактах между этими возможностями, а не в прямой связанности между кодовыми базами.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-82\">Как современные архитектурные руководства поддерживают этот охват платформы\u003C\u002Fh2>\n\u003Cp>ISO\u002FIEC\u002FIEEE 42010:2022 предоставляет общую дисциплину для описаний архитектуры программного обеспечения, систем, предприятий и связанных сущностей. Он не определяет роль AI Platform Architect, но усиливает необходимость выражать архитектурные concerns, взаимосвязи и точки зрения, а не сводить архитектуру к списку технологий.\u003C\u002Fp>\n\u003Cp>NIST AI RMF 1.0 и Generative AI Profile формируют управление рисками AI на протяжении жизненного цикла, а не только на этапе выбора модели. Управление, картирование, измерение и менеджмент поэтому совместимы с архитектурой платформы, которая несёт общие средства контроля и доказательства для множества потребляющих рабочих нагрузок.\u003C\u002Fp>\n\u003Cp>Текущее руководство Microsoft по рабочим нагрузкам AI рассматривает проектирование приложений, данные, безопасность, эксплуатацию, тестирование\u002Fоценку и GenAIOps как связанные архитектурные области. Его текущее руководство по AI Gateway также показывает практические платформенные concerns, такие как централизованный доступ к моделям, лимиты токенов для конкретных проектов, квоты и изоляцию между командами.\u003C\u002Fp>\n\u003Cp>Текущий AWS Generative AI Lens и сценарий мультитенантной платформы аналогично разделяют базовые платформенные средства контроля и ответственность потребляющего приложения. AWS явно отмечает, что центральная платформа может обеспечивать общие guardrails и аудируемость, тогда как качество данных и наблюдаемость, специфичная для рабочей нагрузки, всё ещё остаются ответственностью потребляющих приложений или производителей данных.\u003C\u002Fp>\n\u003Cp>Продукты вендоров различаются, но кросс-источниковый паттерн стабилен: производственные AI-платформы должны координировать идентичность, доступ к данным, модели, политику, оценку, наблюдаемость, ёмкость, стоимость и жизненный цикл. Кластер GPU или эндпоинт модели покрывает лишь часть этой ответственности.\u003C\u002Fp>\n\u003Ch2 id=\"section-88\">Распространённые заблуждения\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Заблуждение\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Почему это неверно\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«AI-платформа — это кластер GPU».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Вычисления — это лишь один субстрат. Платформе также нужны контракты для идентичности, доступа к моделям, данных, политики, оценки, наблюдаемости и жизненного цикла.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«AI-шлюз — это просто обратный прокси».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Он также может нести маршрутизацию моделей, квоты токенов, атрибуцию затрат, применение политик, идентичность и телеметрию, специфичную для AI.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Общий означает глобально общий».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Сервис может быть физически общим, но логически сегментированным по тенанту, приложению, региону, классификации или уровню риска.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Одна центральная векторная база данных становится истиной компании».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Векторное хранилище или сервис поиска — это инфраструктура. Предметный авторитет, актуальность, происхождение и доступ остаются отдельными concerns.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Оценка платформы заменяет оценку решения».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Общая регрессия и телеметрия не могут определить, приемлем ли ответ или действие, специфичные для предметной области.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Абстракция провайдера должна скрывать все различия».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Некоторые различия являются существенными возможностями, семантикой безопасности или режимами отказа и должны оставаться видимыми.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«RBAC решает мультитенантность».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">RBAC управляет действиями; изоляция тенантов управляет границами ресурсов. Может потребоваться и то, и другое.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«AI Platform Architect — это просто другое название для MLOps».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">MLOps\u002FLLMOps — это крупная пересекающаяся дисциплина, но общие границы приложения\u002Fсреды выполнения, идентичности, шлюза, поиска и инструментов могут выходить за пределы операций жизненного цикла модели.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-90\">Режимы отказа, которые должен предотвращать AI Platform Architect\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Режим отказа\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Архитектурное последствие\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Каждая команда хранит собственные ключи провайдера\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Дублирование обработки секретов, несогласованная ротация и больший радиус поражения.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Абстракция провайдера скрывает требуемые возможности\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Потребители не могут использовать нужные им функции или незаметно получают поведение, отличное от ожидаемого.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Общий поиск игнорирует контекст арендатора\u002Fпользователя\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Утечка данных за границы может произойти до того, как приложение получит возможность отфильтровать результаты.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Резервный вариант незаметно меняет провайдера или локальность\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Стоимость, соответствие требованиям, местоположение данных и качество вывода могут измениться без ведома вызывающей стороны.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Инструменты агента предоставляются по выбору модели\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Мощная модель получает избыточные привилегии, поскольку полномочия времени выполнения не обеспечиваются независимо.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Все запросы\u002Fответы журналируются по умолчанию\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Наблюдаемость может создать новое хранилище конфиденциальных данных и проблему соответствия.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Платформа владеет одной общей оценкой качества\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Доменные сбои остаются скрытыми за метриками работоспособности платформы.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Нет контракта версий для возможностей платформы\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Изменения модели\u002Fпровайдера\u002Fсреды выполнения непредсказуемо ломают потребителей.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Всё, связанное с ИИ, централизовано\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Платформа становится узким местом и монолитом вместо слоя многократно используемых возможностей.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-92\">Практическая последовательность решений по архитектуре платформы\u003C\u002Fh2>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">От потребности платформы к эксплуатируемой общей возможности\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Определите реальных потребителей\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Перечислите решения, команды, арендаторов и рабочие нагрузки, которые будут использовать платформу; избегайте создания платформы для гипотетического повторного использования.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Определите общую границу\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Отделите сквозные механизмы от специфичных для решения доменных полномочий, рабочего процесса и приёмки.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Сначала определите идентичность и изоляцию\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Установите пользователей, сервисы, приложения, арендаторов, регионы и классификации данных до того, как делиться возможностями поиска или инструментов.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Определите контракты возможностей\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Задайте API модели\u002Fпровайдера, поиска, агента\u002Fинструмента, шлюза и телеметрии с явным владением и версионированием.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Выберите стратегию провайдера и среды выполнения\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Выберите управляемое, самостоятельно размещённое, локальное или гибридное выполнение и задокументируйте семантику резервирования, локальности и возможностей.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Спроектируйте границы данных и поиска\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Определите происхождение, распространение авторизации, владение корпусом, индексацию и ответственность за доказательства.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">7. Добавьте квоты, секреты и политику\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Контролируйте стоимость, ёмкость, учётные данные, разрешения инструментов, средства безопасности и радиус поражения.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">8. Создайте контракты оценки и наблюдаемости\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Предоставьте метрики платформы и трассировку, оставив доменную эталонную истину и приёмку решению.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">9\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">9. Определите жизненный цикл и операции\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Версионируйте возможности, тестируйте обновления, документируйте вывод из эксплуатации, откат, инциденты, ёмкость и подключение потребителей.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">10\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">10. Проверьте с более чем одним потребителем\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Заявление о платформе становится убедительным, когда общая возможность действительно обслуживает различные рабочие нагрузки, не вынуждая их использовать одну доменную модель.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-94\">Краевые случаи и ограничения роли\u003C\u002Fh2>\n\u003Cp>Небольшой организации с одним ИИ-приложением может не требоваться отдельная ИИ-платформа или архитектор платформы. Преждевременное создание платформы может породить больше абстракции, чем ценности. Правильной архитектурой может быть одно хорошо спроектированное решение с несколькими многократно используемыми модулями.\u003C\u002Fp>\n\u003Cp>Изолированное или суверенное развёртывание существенно меняет модель провайдера, обновлений и наблюдаемости. Размещение моделей, распространение артефактов, интеграция идентичности и экспорт телеметрии могут потребовать локальных эквивалентов.\u003C\u002Fp>\n\u003Cp>Сильно регулируемые рабочие нагрузки или нагрузки с высокими последствиями могут требовать более сильной физической или организационной изоляции вместо логически общей платформы. Повторное использование никогда не является достаточной причиной ослаблять требуемую границу безопасности.\u003C\u002Fp>\n\u003Cp>Управляемые облачные ИИ-сервисы могут снять бремя реализации, но не снимают архитектурную ответственность. Организация по-прежнему решает вопросы идентичности, доступа к данным, журналирования, хранения, квот, допустимости моделей, резервирования, оценки и приёмки решений.\u003C\u002Fp>\n\u003Cp>Граница платформы также может различаться по модальности. Текстовый вывод, мультимодальная генерация, речь, использование компьютера и автономные агенты могут иметь разные требования к задержке, данным, разрешениям и наблюдаемости, даже если они используют общую инфраструктуру провайдера и идентичности.\u003C\u002Fp>\n\u003Ch2 id=\"section-100\">Что могло бы изменить этот ответ?\u003C\u002Fh2>\n\u003Cp>Основное определение изменилось бы при изменении организационного охвата. Если архитектор отвечает за одну рабочую нагрузку, роль становится ближе к архитектору ИИ-решений. Если ответственность расширяется до стратегии возможностей, инвестиций, стандартов и целевых портфелей на уровне всей организации, она смещается к корпоративной ИИ-архитектуре.\u003C\u002Fp>\n\u003Cp>Руководство по реализации меняется всякий раз, когда меняются провайдеры, продукты-шлюзы, протоколы агентов, регуляторные обязательства, возможности моделей или ограничения развёртывания. Именно поэтому архитектура платформы должна выражать стабильные обязанности и контракты отдельно от текущих механизмов поставщиков.\u003C\u002Fp>\n\u003Ch2 id=\"section-103\">Контрольный список архитектора ИИ-платформы\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Вопрос\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Ожидаемый ответ\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Кто является фактическими потребителями платформы?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Названные решения, команды или контексты арендаторов с различными, но пересекающимися потребностями.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Что действительно является общим?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Явный список возможностей, а не расплывчатый «ИИ-бэкенд».\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Что должно оставаться специфичным для решения?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Доменные полномочия, бизнес-процесс, приёмка задач и другие вопросы, принадлежащие рабочей нагрузке.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как представлены модели\u002Fпровайдеры?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Версионированные контракты провайдера\u002Fмодели с возможностями и явной семантикой резервирования.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как распространяется идентичность?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Контекст пользователя\u002Fсервиса\u002Fприложения\u002Fарендатора сохраняется на каждом привилегированном пути запроса.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как обеспечивается изоляция арендаторов?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ограничение области ресурсов отделено от проверок разрешений ролей.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как обрабатываются секреты?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Привилегированное хранение, ротация, ограниченное раскрытие и поддающееся аудиту владение.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как поиск сохраняет полномочия?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Общие механизмы с авторизацией, происхождением и правилами доказательств, принадлежащими домену.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как ограничиваются инструменты и агенты?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Разрешения времени выполнения, ограниченные контракты инструментов, одобрения, отмена и прослеживаемость.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как контролируются стоимость и ёмкость?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Квоты, контроль токенов\u002Fскорости, атрибуция использования и поведение при перегрузке.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как измеряется качество?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Регрессия\u002Fоценка платформы плюс специфичная для решения эталонная истина и приёмка.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как внедряются изменения?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Версионирование, совместимость, миграция, вывод из эксплуатации, откат и ответственность за инциденты.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-105\">Заключение\u003C\u002Fh2>\n\u003Cp>Архитектор ИИ-платформы отвечает за многократно используемую архитектуру \u003Cstrong>между возможностями ИИ и решениями, которые их потребляют\u003C\u002Fstrong>. Роль определяет, как модели, провайдеры, поиск, агенты, инструменты, идентичность, арендаторы, секреты, оценка, наблюдаемость, квоты и операции времени выполнения становятся надёжными сервисами платформы, а не повторяющимися разовыми интеграциями.\u003C\u002Fp>\n\u003Cp>Сложная часть — не максимизация повторного использования. Это выбор правильной границы. Сильная платформа стандартизирует механизмы, политику и операции там, где несколько потребителей действительно получают выгоду, сохраняя при этом специфичные для решения полномочия над данными, бизнес-логику, требования безопасности и критерии приёмки.\u003C\u002Fp>\n\u003Cp>Это различие также объясняет связь с архитектурой ИИ-решений: \u003Cstrong>архитектор решений делает одну систему с поддержкой ИИ пригодной для её цели; архитектор платформы делает общие возможности ИИ безопасными, многократно используемыми, эксплуатируемыми и развиваемыми across many such systems.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch2 id=\"section-109\">Связанные канонические знания\u003C\u002Fh2>\n\u003Cp>Эта статья следует за каноническими основами по компонентам генеративного ИИ, ADR против NFR и архитектуре ИИ-решений. Эти концепции являются предварительными условиями, поскольку платформа существует для предоставления переиспользуемых системных возможностей и для кодирования архитектурных решений в соответствии с явными требованиями к качеству и эксплуатации.\u003C\u002Fp>\n\u003Cp>Генерация с дополнением из поиска — это один из примеров возможности, которая может предоставляться через платформу, но платформа не должна сводить инфраструктуру поиска, предметные знания и достоверность ответов в одно понятие.\u003C\u002Fp>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fru\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Что такое RAG? Самое простое объяснение того, как это работает\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Каноническое введение в генерацию с дополнением из поиска и границу между генерацией модели и извлечением внешних знаний.\u003C\u002Fp>\u003C\u002Fa>\n\u003Cp>Агентные протоколы, изоляция тенантов, управление ИИ, маршрутизация моделей, контекстная инженерия и MLOps\u002FLLMOps — это нижестоящие или смежные узлы знаний. О них становится легче рассуждать, когда граница платформы явно определена.\u003C\u002Fp>\n\u003Ch2 id=\"section-114\">Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Csection class=\"editorjs-faq my-6 rounded-xl border border-gray-200 p-5 dark:border-gray-700\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">FAQ архитектора ИИ-платформы\u003C\u002Fh3>\u003Cdiv id=\"faq-1\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Архитектор ИИ-платформы — это то же самое, что архитектор ИИ-решений?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Нет. Архитектор решений фокусируется на одном конкретном решении с поддержкой ИИ. Архитектор платформы фокусируется на переиспользуемых возможностях ИИ, средствах контроля и эксплуатационных контрактах, которые могут поддерживать множество решений.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq-2\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Должна ли ИИ-платформа размещать собственные модели?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Нет. Платформа может использовать управляемые облачные модели, самостоятельно размещённые модели, локальный инференс или гибридную стратегию. Архитектура должна делать явными последствия для провайдера, локальности, идентичности, маршрутизации, данных и эксплуатации.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq-3\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Достаточно ли ИИ-шлюза, чтобы считаться ИИ-платформой?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Обычно нет. Шлюз может быть важным компонентом платформы, но полноценной платформе также нужны контракты для идентичности, секретов, данных\u002Fпоиска, оценки, наблюдаемости, жизненного цикла и эксплуатационной ответственности.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq-4\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Следует ли централизовать поиск?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Механику поиска часто можно сделать общей, но предметная авторитетность, авторизация, актуальность, достаточность доказательств и владение корпусом должны оставаться явными. Общая инфраструктура не подразумевает общую истину.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq-5\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Заменяет ли оценка платформы оценку приложения?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Нет. Оценка платформы может проверять общие возможности и регрессии. Каждому решению всё ещё нужны эталонные данные для конкретной задачи, критерии приёмки и предметные пороги качества.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq-6\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Мультитенантность — это просто RBAC?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Нет. RBAC определяет, что может делать идентичность. Изоляция тенантов определяет, с ресурсами какого тенанта идентичность может действовать. Платформе часто нужно и то, и другое.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-116\">Глоссарий\u003C\u002Fh2>\n\u003Csection class=\"editorjs-glossary my-6 rounded-xl border border-gray-200 dark:border-gray-700 p-5\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Ключевые термины архитектуры ИИ-платформы\u003C\u002Fh3>\u003Cdl>\u003Cdiv id=\"ai-platform\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">ИИ-платформа\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Переиспользуемый набор связанных с ИИ технических и эксплуатационных возможностей, потребляемых множеством приложений, команд или тенантных контекстов.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"ai-gateway\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">ИИ-шлюз\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Слой шлюза для ИИ-эндпоинтов, который может добавлять аутентификацию, маршрутизацию, квоты, политику, повторные попытки, атрибуцию затрат и специфичную для ИИ телеметрию помимо базового проксирования.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"provider-adapter\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Адаптер провайдера\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Компонент, который отображает контракт платформы на API, возможности, состояние работоспособности и семантику отказов провайдера модели.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"tenant-isolation\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Изоляция тенантов\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Граница, которая предотвращает доступ одного тенантного контекста к ресурсам другого тенанта независимо от разрешений роли.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"capability-contract\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Контракт возможности\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Версионированный интерфейс и поведенческое соглашение, описывающее, что предоставляет общий сервис платформы и что потребитель должен предоставить или взять на себя.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"grounding-service\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Сервис привязки к источникам \u002F поиска\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Общая механика для поиска и предоставления внешней информации ИИ-нагрузке; она не определяет автоматически, какая информация является авторитетной для предметной области.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"evaluation-harness\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Стенд оценки\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Переиспользуемая инфраструктура для запуска тестов, наборов данных, версий моделей\u002Fпромптов и метрик; предметная приёмка остаётся специфичной для решения.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"control-plane\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Плоскость управления\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Слой конфигурации и управления, который управляет возможностями платформы, идентичностями, политиками, квотами, версиями и состоянием развёртывания.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-118\">Первичные источники и актуальные рекомендации по архитектуре\u003C\u002Fh2>\n\u003Cp>Приведённые ниже источники подтверждают общие утверждения об архитектуре и производственной платформе. Разделы Aaasaasa AI Client, Aaasaasa AI CMS и Source of Truth Research Engine являются явно оригинальными доказательствами реализации. Внешние ссылки на текущее состояние были проверены 8 октября 2026 года.\u003C\u002Fp>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC\u002FIEEE 42010:2022 — Описание архитектуры\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Действующий опубликованный международный стандарт для концепций и связей описания архитектуры.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">NIST AI Risk Management Framework\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Ресурсы и текущий статус NIST AI RMF; AI RMF 1.0 находится на стадии пересмотра по состоянию на октябрь 2026 года.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fartificial-intelligence-risk-management-framework-generative-artificial-intelligence\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">NIST AI 600-1 — Профиль генеративного ИИ\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Профиль генеративного ИИ для применения соображений управления рисками ИИ на протяжении жизненного цикла ИИ.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fget-started\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Microsoft Azure Well-Architected — ИИ-нагрузки\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальные рекомендации по архитектуре, охватывающие приложение ИИ, данные, операции, оценку, ответственный ИИ и вопросы жизненного цикла.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fdesign-principles\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Microsoft — Принципы проектирования для ИИ-нагрузок\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальные рекомендации по сегментации идентичностей, границам безопасности, телеметрии, производительности, данным и компромиссам платформы.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fai-foundry\u002Fconfiguration\u002Fenable-ai-api-management-gateway-portal?view=foundry\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Microsoft Foundry — Архитектура ИИ-шлюза\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальные рекомендации по ИИ-шлюзу для общего доступа к проектам, сдерживания токенов, квот и управления.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Farchitecture\u002Fai-ml\u002Fguide\u002Fazure-openai-gateway-guide\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Azure Architecture Center — Доступ к моделям через шлюз\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Рекомендации по архитектуре для централизованного доступа к моделям, маршрутизации, ограничения скорости, отработки отказов и обязанностей клиента\u002Fплатформы.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fgenerative-ai-lens\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">AWS Well-Architected — линза генеративного ИИ\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальные рекомендации по производственной архитектуре для рабочих нагрузок генеративного ИИ в области безопасности, надежности, эксплуатации, производительности и затрат.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fgenerative-ai-lens\u002Fmulti-tenant-generative-ai-platform-scenario.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">AWS — сценарий мультитенантной платформы генеративного ИИ\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальный пример, разделяющий централизованное управление платформой и аудируемость от качества данных потребляющих приложений и обязанностей, специфичных для рабочей нагрузки.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fagentic-ai-lens\u002Fdesign-principles.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">AWS Well-Architected — принципы проектирования агентного ИИ\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальные рекомендации по ограничению полномочий агентов, прослеживаемости, версионированию поведения, явным контрактам и человеческому надзору.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonCloudWatch\u002Flatest\u002Fmonitoring\u002FGenAI-observability.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">AWS CloudWatch — наблюдаемость генеративного ИИ\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальные возможности наблюдаемости и производственные метрики для моделей, агентов, баз знаний, инструментов и анализа затрат\u002Fзадержек\u002Fошибок.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1202},1791477659873,[214,219,226,232,237,244,248,252,256,300,304,308,312,316,341,345,349,353,357,388,394,398,402,406,410,416,420,424,428,432,436,440,444,448,452,456,460,464,468,472,476,480,484,488,492,496,500,504,508,512,516,520,524,528,532,536,541,561,565,569,603,607,655,659,683,687,691,696,700,704,708,712,734,738,742,746,750,754,758,762,766,771,775,779,783,787,791,795,799,830,834,868,872,907,911,915,919,923,927,931,935,939,943,947,990,994,998,1002,1006,1010,1014,1018,1028,1032,1036,1065,1069,1106,1110,1114,1122,1130,1138,1146,1154,1162,1170,1178,1186,1194],{"id":215,"data":216,"type":218},"intro",{"text":217},"\u003Cstrong>Архитектор AI-платформы\u003C\u002Fstrong> проектирует переиспользуемую основу для ИИ, через которую множество приложений, команд или контекстов арендаторов получают доступ к моделям, данным и поиску, средам выполнения агентов и инструментов, идентификации и разрешениям, оценке, наблюдаемости, квотам, секретам и возможностям развёртывания. Эта роль шире, чем инфраструктура, но уже, чем владение каждым продуктом с поддержкой ИИ: её центральная ответственность — решать, \u003Cstrong>что должно быть общим, как общие возможности управляются и изолируются, и что должно оставаться специфичным для конкретного решения\u003C\u002Fstrong>.","paragraph",{"id":220,"data":221,"type":225},"direct",{"body":222,"title":223,"variant":224},"\u003Cstrong>Архитектор AI-платформы проектирует общую техническую и операционную основу для ИИ-систем.\u003C\u002Fstrong> Вместо проектирования одного ассистента или одного рабочего процесса эта роль определяет переиспользуемые контракты и границы для доступа к моделям и провайдерам, шлюзов и маршрутизации, сервисов поиска, сред выполнения агентов, доступа к инструментам, идентификации и изоляции арендаторов, секретов, оценки, телеметрии, развёртывания и управления жизненным циклом.","Прямой ответ","info","callout",{"id":227,"data":228,"type":225},"term-note",{"body":229,"title":230,"variant":231},"\u003Cstrong>Архитектор AI-платформы — это практическое обозначение роли, а не универсально стандартизированное название должности.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 определяет концепции для описаний архитектуры, а не эту роль. Разные организации могут распределять эти обязанности между архитекторами платформ, архитекторами решений, корпоративными архитекторами, архитекторами безопасности, специалистами по MLOps\u002FLLMOps и командами платформенной инженерии. В этой статье термин используется для обозначения архитектурной ответственности за переиспользуемый слой AI-платформы.","Примечание о терминологии","note",{"id":233,"data":234,"type":225},"version-note",{"body":235,"title":236,"variant":231},"Изложенные здесь устойчивые архитектурные принципы не зависят от поставщика. Актуальные рекомендации Microsoft, AWS и NIST используются как внешние свидетельства реализации и управления. NIST сообщает, что AI RMF 1.0 пересматривается; функции платформ поставщиков, продукты-шлюзы, среды выполнения агентов и возможности моделей развиваются быстрее, чем архитектурные принципы, поэтому зависящие от версии решения по реализации необходимо перепроверять перед развёртыванием.","Примечание об актуальности источников — 8 октября 2026 г.",{"id":238,"data":239,"type":243},"toc",{"title":240,"maxLevel":241,"minLevel":242},"Содержание",3,2,"tableOfContents",{"id":245,"data":246,"type":42},"h-meaning",{"text":247,"level":242},"Что на самом деле проектирует архитектор AI-платформы?",{"id":249,"data":250,"type":218},"p-meaning-1",{"text":251},"Объектом работы является \u003Cstrong>платформа\u003C\u002Fstrong>: набор общих возможностей, который сокращает повторяющуюся работу по интеграции, сохраняя при этом явные границы безопасности, данных и эксплуатации. Платформа может предоставлять множеству потребляющих решений доступ к моделям, адаптеры провайдеров, примитивы поиска, выполнение агентов, брокеры инструментов, применение политик, оценку, телеметрию и сервисы развёртывания.",{"id":253,"data":254,"type":218},"p-meaning-2",{"text":255},"Платформа ценна не просто потому, что её компоненты централизованы. Она ценна, когда потребители получают стабильные возможности с чёткими контрактами, ответственностью, изоляцией, наблюдаемостью и правилами жизненного цикла. Поэтому ключевой архитектурный вопрос не «Какую модель должны использовать все?», а \u003Cstrong>«Какие обязанности можно безопасно стандартизировать и переиспользовать, не стирая требования каждого решения?»\u003C\u002Fstrong>.",{"id":257,"data":258,"type":299},"solution-vs-platform",{"rows":259,"title":290,"layout":291,"columns":292},[260,266,272,278,284],{"id":261,"label":262,"values":263},"c1","Основной охват",{"platform":264,"solution":265},"Reusable AI capabilities consumed by multiple solutions, teams or tenant contexts.","One concrete AI-enabled product, workflow or application.",{"id":267,"label":268,"values":269},"c2","Главный вопрос",{"platform":270,"solution":271},"Which shared capabilities and controls should solutions consume, and where must solution-specific ownership remain?","How should this solution meet its business, data, security, quality and operational requirements?",{"id":273,"label":274,"values":275},"c3","Ответственность за данные",{"platform":276,"solution":277},"Provides storage, retrieval, provenance or access primitives without automatically becoming the authority for every domain.","Defines which domain data is authoritative and how the solution may use it.",{"id":279,"label":280,"values":281},"c4","Оценка",{"platform":282,"solution":283},"Provides reusable evaluation, telemetry and release mechanisms; it cannot define every domain's success threshold.","Defines task-specific quality and acceptance criteria.",{"id":285,"label":286,"values":287},"c5","Жизненный цикл",{"platform":288,"solution":289},"Owns shared capability versions, compatibility, onboarding, quotas, policy and operational contracts.","Owns the lifecycle of the specific workload.","Архитектура решения и архитектура платформы решают разные задачи по охвату","table",[293,296],{"id":294,"label":295},"solution","Архитектор AI-решения",{"id":297,"label":298},"platform","Архитектор AI-платформы","comparison",{"id":301,"data":302,"type":42},"h-simple",{"text":303,"level":242},"Простейший пример",{"id":305,"data":306,"type":218},"p-simple-1",{"text":307},"Представьте, что в организации есть пять продуктов с поддержкой ИИ: внутренний ассистент по документам, копилот службы поддержки клиентов, агент для разработки программного обеспечения, рабочий процесс проверки договоров и ассистент поиска по товарам. Каждый продукт мог бы независимо интегрировать API моделей, хранить учётные данные, реализовывать повторные попытки, собирать метрики токенов, создавать код поиска и строить собственные разрешения для инструментов.",{"id":309,"data":310,"type":218},"p-simple-2",{"text":311},"Такое дублирование дорого и опасно, когда каждая команда изобретает свою модель безопасности и эксплуатации. Общая платформа вместо этого может предлагать одобренные подключения к провайдерам, обнаружение моделей, квоты, учётные данные, доступ с учётом арендатора, общую телеметрию, переиспользуемые сервисы поиска и контракт среды выполнения агентов и инструментов.",{"id":313,"data":314,"type":218},"p-simple-3",{"text":315},"Но платформа должна остановиться на правильной границе. Решение для проверки договоров может требовать полномочий по юридическим документам и правил цитирования, которых нет у программного агента. Ассистенту поиска по товарам могут понадобиться специфичные для торговли правила актуальности и авторизации. \u003Cstrong>Переиспользуемая инфраструктура не делает всю предметную истину переиспользуемой.\u003C\u002Fstrong>",{"id":317,"data":318,"type":340},"simple-flow",{"steps":319,"title":338,"orientation":339},[320,323,326,329,332,335],{"label":321,"description":322},"1. Потребитель идентифицирует себя","Вызывающее приложение, пользователь, сервис, команда или арендатор входят через аутентифицированную идентичность и явную область действия.",{"label":324,"description":325},"2. Применяется политика платформы","Уровни шлюза и политик определяют разрешённых провайдеров, модели, квоты, пути данных, инструменты и режимы выполнения.",{"label":327,"description":328},"3. Выполняется общая возможность","Запрос может использовать вывод модели, поиск, среду выполнения агента, доступ к инструментам или другой переиспользуемый сервис платформы.",{"label":330,"description":331},"4. Контекст, специфичный для решения, остаётся авторитетным","Потребляющее решение предоставляет предметные правила, намерение пользователя, полномочия по данным, ограничения конкретной задачи и логику приёмки.",{"label":333,"description":334},"5. Собираются телеметрия и свидетельства","Платформа фиксирует идентичность, маршрут, модель и провайдера, задержку, стоимость, ошибки, активность инструментов и другие разрешённые сигналы наблюдаемости.",{"label":336,"description":337},"6. Результат возвращается по контракту решения","Решение остаётся ответственным за то, приемлем ли вывод для его пользователя и предметной области.","Общий путь AI-запроса","auto","processFlow",{"id":342,"data":343,"type":42},"h-stops",{"text":344,"level":242},"Где заканчивается простой пример",{"id":346,"data":347,"type":218},"p-stops-1",{"text":348},"Централизация не является автоматически архитектурой. Единая точка входа перед несколькими API моделей полезна, но сама по себе она не создаёт AI-платформу. Производственной платформе также нужны границы идентичности, контракты возможностей, обработка работоспособности и жизненного цикла провайдеров, квоты, ответственность за секреты, наблюдаемость, правила совместимости, средства безопасности, дисциплина выпуска и чёткая эксплуатационная ответственность.",{"id":350,"data":351,"type":218},"p-stops-2",{"text":352},"Противоположная ошибка также распространена: поместить каждый промпт, векторный индекс, бизнес-правило, агента и рабочий процесс приложения в один «AI-бэкенд». Это создаёт монолит, общий статус которого случаен, а не архитектурен. \u003Cstrong>Платформа должна стандартизировать сквозные возможности, а не поглощать предметную ответственность только потому, что задействован ИИ.\u003C\u002Fstrong>",{"id":354,"data":355,"type":42},"h-boundary",{"text":356,"level":242},"Самое важное решение платформы: общее или специфичное для решения",{"id":358,"data":359,"type":291},"shared-boundary-table",{"content":360,"stretched":43,"withHeadings":14},[361,365,369,373,377,381,384],[362,363,364],"Область возможностей","Хороший кандидат для общей ответственности платформы","Обычно остаётся специфичным для решения",[366,367,368],"Доступ к моделям","Одобренные подключения к провайдерам, адаптеры, учётные данные, проверка работоспособности, примитивы маршрутизации, квоты","Приёмка моделей для конкретных задач, поведение промптов, порог качества",[370,371,372],"Извлечение данных","Примитивы загрузки, извлечение, индексирование, API поиска, контракты происхождения, хуки авторизации","Авторитетный корпус, правила актуальности, доменные метаданные, достаточность доказательств",[374,375,376],"Агенты и инструменты","Жизненный цикл среды выполнения, реестр\u002Fброкер инструментов, обеспечение разрешений, трассировка, отмена","Бизнес-процесс, семантика разрешённых действий, политика эскалации, успех задачи",[378,379,380],"Безопасность","Интеграция удостоверений, хранение секретов, обеспечение политик, контракты аудита, механизмы изоляции арендаторов","Классификация данных, правила бизнес-авторизации, принятие рисков для конкретной области",[280,382,383],"Стенд, механика версионирования наборов данных, телеметрия, рабочий процесс экспериментов\u002Fрелизов","Эталонные данные, доменный тестовый набор, порог приёмки, результат для пользователя",[385,386,387],"Операции","Шаблон развёртывания, работоспособность, метрики, интеграция с инцидентами, управление мощностями","SLO решения, если они различаются, влияние на непрерывность бизнеса, runbook'и для конкретных нагрузок",{"id":389,"data":390,"type":225},"boundary-principle",{"body":391,"title":392,"variant":393},"\u003Cstrong>Совместно используйте механику и средства контроля там, где повторное использование реально; оставляйте полномочия и приёмку там, где ими владеет домен.\u003C\u002Fstrong> Это предотвращает две противоположные ошибки: дублирование инфраструктуры повсюду и центральная платформа, которая ложно становится владельцем данных, политик и качества каждого приложения.","Принцип платформы","success",{"id":395,"data":396,"type":42},"h-responsibility-map",{"text":397,"level":242},"Карта архитектурной ответственности",{"id":399,"data":400,"type":42},"h-provider",{"text":401,"level":241},"1. Доступ к моделям и провайдерам",{"id":403,"data":404,"type":218},"p-provider-1",{"text":405},"Архитектор платформы определяет, как потребители обнаруживают и вызывают модели, не заставляя каждое приложение жёстко кодировать одного провайдера. Это включает адаптеры провайдеров, идентификаторы моделей, метаданные возможностей, аутентификацию, проверки работоспособности, конфигурацию конечных точек, нормализацию запросов и поведение совместимости.",{"id":407,"data":408,"type":218},"p-provider-2",{"text":409},"Абстракция провайдера должна оставаться честной. Разные провайдеры предоставляют разные ограничения контекста, семантику инструментов, поведение структурированного вывода, мультимодальные возможности, средства безопасности, кэширование, ценообразование и режимы отказа. Хорошая абстракция создаёт стабильный контракт платформы, сохраняя доступ к возможностям, которые нельзя осмысленно свести к общему знаменателю.",{"id":411,"data":412,"type":225},"provider-warning",{"body":413,"title":414,"variant":415},"API по наименьшему общему знаменателю может упростить миграцию, но также может стереть возможности, которые важны. Архитектура должна определять, какие функции переносимы, какие специфичны для провайдера и как потребители узнают об этом различии.","Не путайте абстракцию с притворством, что провайдеры идентичны","warning",{"id":417,"data":418,"type":42},"h-gateway",{"text":419,"level":241},"2. Шлюз, маршрутизация, квоты и контроль затрат",{"id":421,"data":422,"type":218},"p-gateway-1",{"text":423},"Общий AI-шлюз может централизовать аутентификацию, маршрутизацию, ограничение скорости, повторные попытки, лимиты токенов, атрибуцию использования и обеспечение политик. Текущее руководство Microsoft по AI Gateway явно рассматривает лимиты токенов в минуту, квоты и изоляцию нескольких проектов как задачи платформы; AWS аналогично предоставляет квоты на аккаунт и модель и централизованные средства контроля.",{"id":425,"data":426,"type":218},"p-gateway-2",{"text":427},"Таким образом, шлюз — это больше, чем обратный прокси, когда он несёт специфичную для ИИ политику и операционную семантику. Но он не должен молча принимать бизнес-решения. Политика маршрутизации может предпочитать работоспособную локальную модель, более дешёвого провайдера или регионально совместимую конечную точку; однако приемлемость этого маршрута для конкретной задачи всё ещё остаётся контрактом между платформой и решением.",{"id":429,"data":430,"type":218},"p-gateway-3",{"text":431},"Маршрутизация также требует семантики отказов. Если предпочтительная модель недоступна, платформа должна знать, разрешён ли резервный вариант, требует ли облачный маршрут явного согласия, допустима ли модель с меньшими возможностями и как это решение отображается в наблюдаемости.",{"id":433,"data":434,"type":42},"h-data",{"text":435,"level":241},"3. Общие данные, извлечение и сервисы обоснования",{"id":437,"data":438,"type":218},"p-data-1",{"text":439},"Сервисы извлечения данных — сильные кандидаты для платформы, потому что разбор, разбиение на фрагменты, индексирование, лексический поиск, семантический поиск, фильтрация метаданных, происхождение и механика цитирования переиспользуемы. Однако платформа не должна путать общий движок извлечения с общим источником истины.",{"id":441,"data":442,"type":218},"p-data-2",{"text":443},"Решение всё ещё владеет такими вопросами: какой корпус является авторитетным? Какая версия действительна? Может ли этот пользователь видеть этот документ? Насколько свежими должны быть данные? Что считается достаточным доказательством? Можно ли сгенерировать ответ, если извлечение не удалось? Это требования домена и решения, даже когда платформа предоставляет механизм извлечения.",{"id":445,"data":446,"type":218},"p-data-3",{"text":447},"Эта граница особенно важна в мультитенантных системах. Технически общий индекс или векторный сервис не оправдывает кросс-тенантную видимость. Контекст авторизации должен сохраняться через извлечение, а не добавляться только после того, как результаты поиска уже пересекли границу.",{"id":449,"data":450,"type":42},"h-agent-runtime",{"text":451,"level":241},"4. Среда выполнения агентов и инструментов",{"id":453,"data":454,"type":218},"p-agent-1",{"text":455},"Агентные системы добавляют переиспользуемые задачи среды выполнения: жизненный цикл потока\u002Fсессии, циклы планирования, регистрация инструментов, вызов инструментов, отмена, тайм-ауты, одобрения человеком, интерфейсы памяти\u002Fсостояния, протоколы удалённых агентов и корреляция трассировок. Платформа может предоставить эти механизмы, чтобы каждый продукт не пересобирал их заново.",{"id":457,"data":458,"type":218},"p-agent-2",{"text":459},"Платформа также должна отделять разрешения инструментов от возможностей модели. То, что модель способна сгенерировать команду оболочки, не означает, что среда выполнения должна разрешать выполнение оболочки. Граница разрешений принадлежит архитектуре приложения\u002Fсреды выполнения и должна обеспечиваться независимо от модели.",{"id":461,"data":462,"type":218},"p-agent-3",{"text":463},"Текущие рекомендации AWS по агентному ИИ подчеркивают ограниченных агентов, явные полномочия, сквозную трассировку, версионированные артефакты поведения и человеческий надзор, соразмерный последствиям. Это вопросы, обеспечивающие работу платформы, но потребляющее решение всё ещё определяет, какие действия являются законными для его домена.",{"id":465,"data":466,"type":42},"h-identity",{"text":467,"level":241},"5. Идентификация, изоляция арендаторов и авторизация",{"id":469,"data":470,"type":218},"p-identity-1",{"text":471},"Платформы ИИ часто находятся перед высокоценными моделями, проприетарными данными и инструментами, способными выполнять действия. Поэтому аутентификация — это только начало. Архитектура должна передавать контекст пользователя, сервиса, приложения и арендатора через каждую привилегированную операцию, где это необходимо.",{"id":473,"data":474,"type":218},"p-identity-2",{"text":475},"\u003Cstrong>RBAC и изоляция арендаторов решают разные задачи.\u003C\u002Fstrong> RBAC отвечает на вопрос, что может делать идентичность; изоляция арендаторов отвечает на вопрос, с ресурсами какого арендатора эта идентичность может действовать. Платформа, которая проверяет роли, но теряет контекст арендатора, всё ещё может раскрыть не те данные.",{"id":477,"data":478,"type":218},"p-identity-3",{"text":479},"Текущие рекомендации Microsoft по рабочим нагрузкам ИИ явно рекомендуют сегментацию идентичности и доступ к контенту с учётом авторизации. Рекомендации AWS по многопользовательской платформе генеративного ИИ аналогично рассматривают логическую изоляцию, централизованное управление и возможность аудита как вопросы платформы.",{"id":481,"data":482,"type":42},"h-secrets",{"text":483,"level":241},"6. Секреты, учётные данные и границы доверия",{"id":485,"data":486,"type":218},"p-secrets-1",{"text":487},"Платформа должна определить, кто владеет ключами провайдера, удалёнными bearer-токенами, материалами для подписи и учётными данными инструментов, где они хранятся, какой процесс может к ним получить доступ, как они ротируются и могут ли они когда-либо попасть в браузер или недоверенный рендерер.",{"id":489,"data":490,"type":218},"p-secrets-2",{"text":491},"Это архитектурная граница, а не деталь реализации. Если каждое потребляющее приложение копирует учётные данные провайдера в свою собственную конфигурацию, организация дублирует как операционную нагрузку, так и радиус поражения. Централизация может снизить этот риск только в том случае, если сама платформа имеет более узкие, поддающиеся аудиту пути доступа.",{"id":493,"data":494,"type":42},"h-eval",{"text":495,"level":241},"7. Оценка, наблюдаемость и возможность аудита",{"id":497,"data":498,"type":218},"p-eval-1",{"text":499},"Многоразовая платформа может предоставлять средства оценки, идентификаторы трассировки, метаданные модели\u002Fпровайдера, метрики токенов и стоимости, задержку, частоту ошибок, связь версий промпта\u002Fмодели, трассировки агентов\u002Fинструментов и контролируемое логирование. AWS и Microsoft рассматривают наблюдаемость и оценку как ключевые производственные вопросы для рабочих нагрузок ИИ.",{"id":501,"data":502,"type":218},"p-eval-2",{"text":503},"Оценка платформы и оценка решения должны оставаться раздельными. Платформа может проверить, что конечная точка работоспособна, версия модели проходит общий набор регрессионных тестов и трассировки полны. Она не может решить, что юридический ответ, медицинский рабочий процесс или рекомендация продукта приемлемы без предметно-специфической эталонной истины и критериев приёмки.",{"id":505,"data":506,"type":218},"p-eval-3",{"text":507},"Логирование также создаёт границу конфиденциальности. Журналы промптов и ответов могут содержать конфиденциальные или проприетарные данные. Поэтому архитектор платформы должен решить, что логируется, редактируется, сэмплируется, сохраняется и доступно, а не предполагать, что больше телеметрии всегда безопаснее.",{"id":509,"data":510,"type":42},"h-runtime",{"text":511,"level":241},"8. Среда выполнения, развёртывание и локальность",{"id":513,"data":514,"type":218},"p-runtime-1",{"text":515},"Архитектор платформы решает, как общие возможности ИИ развёртываются и становятся доступными: управляемые облачные сервисы, самостоятельно размещённые конечные точки, локальный вывод, гибридная маршрутизация, контейнеризированные сервисы, настольные среды выполнения, частные сети или изолированные среды. Важное различие — между \u003Cstrong>тем, где выполняется процесс управления\u002Fсреды выполнения\u003C\u002Fstrong>, и \u003Cstrong>тем, где фактически происходят вывод и обработка данных\u003C\u002Fstrong>.",{"id":517,"data":518,"type":218},"p-runtime-2",{"text":519},"Локальный клиент всё ещё может вызывать облачную модель. Облачная плоскость управления может маршрутизировать к локальной модели. Удалённый агент может выполнять инструменты внутри сети клиента. Поэтому архитектурные диаграммы должны показывать границы доверия и потоков данных, а не использовать «локальный» и «облачный» как расплывчатые ярлыки.",{"id":521,"data":522,"type":42},"h-lifecycle",{"text":523,"level":241},"9. Жизненный цикл платформы, совместимость и подключение",{"id":525,"data":526,"type":218},"p-lifecycle-1",{"text":527},"Многоразовая возможность становится платформой только тогда, когда потребители могут полагаться на неё с течением времени. Для этого требуются версионированные контракты, правила миграции, политика совместимости, вывод из эксплуатации, тестирование релизов, откат, ответственность за инциденты, планирование мощности, документация и путь для подключения новых команд или приложений.",{"id":529,"data":530,"type":218},"p-lifecycle-2",{"text":531},"Быстро развивающиеся экосистемы ИИ делают это особенно важным. Имена моделей, SDK, версии протоколов, API провайдеров и возможности безопасности меняются независимо. Платформа должна поглощать часть этой волатильности, не скрывая изменения, которые существенно влияют на поведение решения.",{"id":533,"data":534,"type":42},"h-control-plane",{"text":535,"level":242},"Практическая модель control-plane \u002F execution-plane \u002F solution-plane",{"id":537,"data":538,"type":225},"model-note",{"body":539,"title":540,"variant":231},"Приведённая ниже трёхуровневая модель — это практический способ рассуждать об ответственности; это не стандарт ISO, NIST, Microsoft или AWS. Её цель — сделать границы ответственности явными.","Предлагаемая архитектурная модель",{"id":542,"data":543,"type":291},"planes-table",{"content":544,"stretched":43,"withHeadings":14},[545,549,553,557],[546,547,548],"Уровень","Типичные обязанности","Не должен неявно владеть",[550,551,552],"Control plane платформы","Реестр провайдеров, политика моделей, квоты, конфигурация тенантов, идентичности, секреты, правила маршрутизации, версии возможностей, конфигурация развёртывания","Бизнес-логика приложения или доменная истина",[554,555,556],"Execution\u002Fdata plane платформы","Запросы на инференс, операции поиска, выполнение агентов\u002Fинструментов, извлечение, индексация, отправка телеметрии, применение политик","Кросс-тенантный доступ только потому, что инфраструктура общая",[558,559,560],"Solution plane","Пользовательский рабочий процесс, промпты\u002Fинструкции, выбор авторитетного корпуса, доменная авторизация, бизнес-правила, оценка и приёмка задач","Низкоуровневая интеграция с провайдерами, которой явно владеет платформа",{"id":562,"data":563,"type":218},"p-control-plane-1",{"text":564},"Это разделение помогает диагностировать дрейф платформы. Если приложение должно знать все учётные данные и эндпоинты конкретного провайдера, контракт платформы слишком тонкий. Если платформа решает, какая запись клиента юридически авторитетна или приемлем ли доменный ответ, платформа перешла в зону ответственности решения.",{"id":566,"data":567,"type":42},"h-artifacts",{"text":568,"level":242},"Что должен создавать архитектор AI-платформы?",{"id":570,"data":571,"type":291},"artifacts-table",{"content":572,"stretched":43,"withHeadings":14},[573,576,579,582,585,588,591,594,597,600],[574,575],"Архитектурный артефакт","Назначение",[577,578],"Карта возможностей платформы","Определяет, что предоставляет платформа, кто это потребляет и какие возможности остаются вне области охвата.",[580,581],"Контракт провайдера\u002Fмодели","Определяет провайдеров, модели, возможности, границы абстракции, метаданные маршрутизации и семантику отката.",[583,584],"Модель идентичности и тенантности","Определяет идентичность пользователя\u002Fсервиса\u002Fприложения, контекст тенанта, точки подключения RBAC\u002FABAC и изоляцию ресурсов.",[586,587],"Политика шлюза и квот","Определяет ограничения скорости, бюджеты токенов\u002Fстоимости, управление маршрутизацией, повторные попытки и поведение при нагрузке.",[589,590],"Контракт поиска\u002Fданных","Определяет приём данных, происхождение, поиск, метаданные, распространение авторизации и то, где остаётся доменная авторитетность.",[592,593],"Контракт агента\u002Fинструмента","Определяет жизненный цикл среды выполнения, регистрацию инструментов, разрешения, согласования, отмену и поведение трассировки.",[595,596],"Модель секретов и границ доверия","Определяет владение учётными данными, хранение, границы процессов, ротацию и пути конфиденциальных данных.",[598,599],"Контракт оценки и телеметрии","Определяет общие метрики, трассировки, связи с наборами данных\u002Fверсиями, политику логирования и точки расширения решения.",[601,602],"Политика жизненного цикла и совместимости","Определяет версии, миграции, вывод из эксплуатации, релизы, откат, ответственность за инциденты и адаптацию.",{"id":604,"data":605,"type":42},"h-tradeoffs",{"text":606,"level":242},"Работа — это в основном компромиссы, а не максимальная централизация",{"id":608,"data":609,"type":299},"tradeoff-comparison",{"rows":610,"title":647,"layout":291,"columns":648},[611,617,623,629,635,641],{"id":612,"label":613,"values":614},"t1","Абстракция провайдера",{"pressureA":615,"pressureB":616},"Stable portable platform API","Access to provider-specific capabilities and fast innovation",{"id":618,"label":619,"values":620},"t2","Повторное использование",{"pressureA":621,"pressureB":622},"Shared services reduce duplication","Isolation and domain autonomy prevent unsafe coupling",{"id":624,"label":625,"values":626},"t3","Управление",{"pressureA":627,"pressureB":628},"Central policy and auditability","Team speed and local experimentation",{"id":630,"label":631,"values":632},"t4","Наблюдаемость",{"pressureA":633,"pressureB":634},"Rich traces for debugging and evaluation","Privacy, data minimization and logging cost",{"id":636,"label":637,"values":638},"t5","Доступность",{"pressureA":639,"pressureB":640},"Fallback and multi-provider resilience","Predictable quality, compliance and data-location guarantees",{"id":642,"label":643,"values":644},"t6","Область охвата платформы",{"pressureA":645,"pressureB":646},"More reusable capabilities","Smaller blast radius and less platform lock-in","Типичные компромиссы платформы",[649,652],{"id":650,"label":651},"pressureA","Давление A",{"id":653,"label":654},"pressureB","Давление B",{"id":656,"data":657,"type":42},"h-adjacent",{"text":658,"level":242},"Чем это отличается от смежных ролей?",{"id":660,"data":661,"type":291},"roles-table",{"content":662,"stretched":43,"withHeadings":14},[663,666,669,671,674,677,680],[664,665],"Роль","Основная архитектурная область",[667,668],"Архитектор AI-решений","Конкретное AI-решение и его сквозные требования, границы, компромиссы и приёмка в продакшене.",[298,670],"Переиспользуемые AI-возможности и операционные\u002Fбезопасностные контракты, потребляемые несколькими решениями или командами.",[672,673],"Корпоративный архитектор","Общеорганизационный портфель бизнес\u002Fтехнологий, согласование возможностей и управления на более широком уровне.",[675,676],"Архитектор или специалист MLOps \u002F LLMOps","Жизненный цикл моделей и AI, развёртывание, эксперименты, наблюдаемость, релизы и операционные практики; может сильно пересекаться, но не владеет автоматически всей общей платформой приложений.",[678,679],"Платформенный инженер \u002F SRE","Реализует и эксплуатирует инфраструктуру платформы, надёжность, автоматизацию и опыт разработчиков; архитектурная ответственность может быть разделена с архитектором платформы.",[681,682],"AI \u002F программный инженер","Реализует модели, интеграции, сервисы, агентов, поиск и продуктовую функциональность в рамках согласованной архитектуры.",{"id":684,"data":685,"type":218},"p-adjacent-1",{"text":686},"Эти границы организационные, а не универсальные. В небольшой команде один человек может нести несколько обязанностей. В регулируемом предприятии они могут быть разделены между группами архитектуры, безопасности, платформы, данных и эксплуатации. Полезное различие — это \u003Cstrong>область архитектурной ответственности\u003C\u002Fstrong>, а не должность, напечатанная на организационной схеме.",{"id":688,"data":689,"type":42},"h-evidence",{"text":690,"level":242},"Доказательства реализации: как эти границы платформы проявляются в моей собственной работе",{"id":692,"data":693,"type":225},"evidence-note",{"body":694,"title":695,"variant":231},"Следующие разделы описывают конкретные паттерны из моих собственных проектов. Они являются доказательством того, что эти архитектурные границы были реализованы или явно спроектированы в реальном коде и проектных системах. Они \u003Cstrong>не\u003C\u002Fstrong> являются утверждением, что проекты вместе уже constitute коммерчески развёрнутую корпоративную AI-платформу.","Доказательства оригинальной реализации",{"id":697,"data":698,"type":42},"h-ai-client",{"text":699,"level":241},"Aaasaasa AI Client: разделение провайдера, среды выполнения и разрешений",{"id":701,"data":702,"type":218},"p-ai-client-1",{"text":703},"Aaasaasa AI Client — это локальное настольное AI-рабочее пространство, созданное с использованием Nuxt 4, Electron и TypeScript. Его AI Hub намеренно разделяет \u003Cstrong>агента\u002Fклиента, провайдера, модель, расположение соединения\u002Fсреды выполнения, разрешения и веб-клиент\u003C\u002Fstrong>, вместо того чтобы рассматривать их как одно значение конфигурации.",{"id":705,"data":706,"type":218},"p-ai-client-2",{"text":707},"Реализация включает прямые адаптеры провайдеров, интеграцию среды выполнения агента Codex, локальные пути Ollama\u002FLM Studio, сервисы, совместимые с OpenAI, централизованные разрешения рабочего пространства, хранение учётных данных в главном процессе, DuckDB, поддержку Qdrant\u002Fвекторов, извлечение PDF\u002Fчитаемости и аутентифицированный доступ к каталогам на основе MCP.",{"id":709,"data":710,"type":218},"p-ai-client-3",{"text":711},"Два урока платформы особенно актуальны. Во-первых, локальная среда выполнения — это не то же самое, что локальный инференс: локальный процесс Codex всё ещё может использовать облачную модель. Во-вторых, автоматическая маршрутизация не выполняет неявный откат с локального на платный облачный инференс. Это делает политику маршрутизации и локальность среды выполнения явными, а не выведенными из меток интерфейса.",{"id":713,"data":714,"type":291},"ai-client-evidence-table",{"content":715,"stretched":43,"withHeadings":14},[716,719,722,725,728,731],[717,718],"Реализованная граница","Значение для архитектуры платформы",[720,721],"Агент vs провайдер vs модель","Разные обязанности могут развиваться независимо, вместо того чтобы быть скрытыми за одним селектором «AI».",[723,724],"Разрешения отдельно от модели","Полномочия файловой системы\u002Fинструментов принадлежат политике среды выполнения, а не возможностям модели.",[726,727],"Секреты в главном процессе","Владение учётными данными следует за границей привилегированного процесса, а не за рендерером\u002Fинтерфейсом.",[729,730],"Состояние провайдера и обнаружение моделей","Маршрутизация и доступность — это вопросы среды выполнения\u002Fплатформы.",[732,733],"Никакого неявного облачного отката","Семантика стоимости, локальности и передачи данных остаётся явными политическими решениями.",{"id":735,"data":736,"type":42},"h-cms",{"text":737,"level":241},"Aaasaasa AI CMS: авторизация в рамках тенанта как граница платформы",{"id":739,"data":740,"type":218},"p-cms-1",{"text":741},"Кодовая база Aaasaasa AI CMS представляет отдельный пример реализации: RBAC в рамках тенанта реализуется через роли, разрешения и назначения ролей пользователям, привязанные к идентификатору тенанта. Системные разрешения группируются по возможностям, а поиск и обновление ролей остаются в рамках тенанта.",{"id":743,"data":744,"type":218},"p-cms-2",{"text":745},"Это само по себе не является доказательством полноценной AI-платформы, но напрямую относится к одной из самых сложных границ общей платформы: переиспользуемый сервис должен сохранять \u003Cstrong>кто что может делать\u003C\u002Fstrong> и \u003Cstrong>для какого тенанта\u003C\u002Fstrong>. Добавление AI-инференса или поиска поверх прикладной платформы не отменяет этого требования.",{"id":747,"data":748,"type":218},"p-cms-3",{"text":749},"Архитектурное следствие состоит в том, что шлюзы моделей, сервисы поиска и агенты должны использовать уже установленный контекст идентичности\u002Fтенанта, а не изобретать параллельную вселенную авторизации только для AI.",{"id":751,"data":752,"type":42},"h-sot",{"text":753,"level":241},"Source of Truth Research Engine: общая механика поиска без общей истины",{"id":755,"data":756,"type":218},"p-sot-1",{"text":757},"Source of Truth Research Engine представляет третий пример реализации. Различные режимы исследования используют общее ядро доказательств: источники, артефакты, происхождение, утверждения, связи, противоречия, эталонную модель и журнал аудита. Система также обеспечивает локальный лексический поиск, опциональный семантический поиск, извлечение, снимки состояния и происхождение на основе SHA-256.",{"id":759,"data":760,"type":218},"p-sot-2",{"text":761},"Проект явно рассматривает поиск и семантическое сходство как сигналы для обнаружения, а не как доказательства. Результат должен быть прослежен до конкретного источника и локатора, прежде чем он сможет подтвердить утверждение. Именно это различие необходимо AI-платформе: \u003Cstrong>переиспользуемая механика поиска может быть общей, тогда как авторитет доказательств остаётся под управлением потребляющей методологии и предметной области.\u003C\u002Fstrong>",{"id":763,"data":764,"type":218},"p-sot-3",{"text":765},"Движок также демонстрирует, почему одна общая платформа не требует одной общей интерпретации. Исторический, научно-технический, рыночно-аналитический и мониторинговый режимы могут переиспользовать базовую инфраструктуру доказательств, сохраняя методологию, специфичную для каждого режима.",{"id":767,"data":768,"type":225},"evidence-synthesis",{"body":769,"title":770,"variant":393},"Во всех этих проектах переиспользуемый паттерн — это не «один бэкенд для всего». Это \u003Cstrong>разделение ответственности плюс явные контракты\u003C\u002Fstrong>: разделение провайдера\u002Fмодели\u002Fсреды выполнения, авторизация с учётом тенанта, границы учётных данных, переиспользуемые примитивы данных\u002Fпоиска, происхождение и предметно-специфичный авторитет. Будущая интегрированная платформа нуждалась бы в стабильных контрактах между этими возможностями, а не в прямой связанности между кодовыми базами.","Что эти реализации демонстрируют вместе",{"id":772,"data":773,"type":42},"h-frameworks",{"text":774,"level":242},"Как современные архитектурные руководства поддерживают этот охват платформы",{"id":776,"data":777,"type":218},"p-frameworks-1",{"text":778},"ISO\u002FIEC\u002FIEEE 42010:2022 предоставляет общую дисциплину для описаний архитектуры программного обеспечения, систем, предприятий и связанных сущностей. Он не определяет роль AI Platform Architect, но усиливает необходимость выражать архитектурные concerns, взаимосвязи и точки зрения, а не сводить архитектуру к списку технологий.",{"id":780,"data":781,"type":218},"p-frameworks-2",{"text":782},"NIST AI RMF 1.0 и Generative AI Profile формируют управление рисками AI на протяжении жизненного цикла, а не только на этапе выбора модели. Управление, картирование, измерение и менеджмент поэтому совместимы с архитектурой платформы, которая несёт общие средства контроля и доказательства для множества потребляющих рабочих нагрузок.",{"id":784,"data":785,"type":218},"p-frameworks-3",{"text":786},"Текущее руководство Microsoft по рабочим нагрузкам AI рассматривает проектирование приложений, данные, безопасность, эксплуатацию, тестирование\u002Fоценку и GenAIOps как связанные архитектурные области. Его текущее руководство по AI Gateway также показывает практические платформенные concerns, такие как централизованный доступ к моделям, лимиты токенов для конкретных проектов, квоты и изоляцию между командами.",{"id":788,"data":789,"type":218},"p-frameworks-4",{"text":790},"Текущий AWS Generative AI Lens и сценарий мультитенантной платформы аналогично разделяют базовые платформенные средства контроля и ответственность потребляющего приложения. AWS явно отмечает, что центральная платформа может обеспечивать общие guardrails и аудируемость, тогда как качество данных и наблюдаемость, специфичная для рабочей нагрузки, всё ещё остаются ответственностью потребляющих приложений или производителей данных.",{"id":792,"data":793,"type":218},"p-frameworks-5",{"text":794},"Продукты вендоров различаются, но кросс-источниковый паттерн стабилен: производственные AI-платформы должны координировать идентичность, доступ к данным, модели, политику, оценку, наблюдаемость, ёмкость, стоимость и жизненный цикл. Кластер GPU или эндпоинт модели покрывает лишь часть этой ответственности.",{"id":796,"data":797,"type":42},"h-misconceptions",{"text":798,"level":242},"Распространённые заблуждения",{"id":800,"data":801,"type":291},"misconceptions-table",{"content":802,"stretched":43,"withHeadings":14},[803,806,809,812,815,818,821,824,827],[804,805],"Заблуждение","Почему это неверно",[807,808],"«AI-платформа — это кластер GPU».","Вычисления — это лишь один субстрат. Платформе также нужны контракты для идентичности, доступа к моделям, данных, политики, оценки, наблюдаемости и жизненного цикла.",[810,811],"«AI-шлюз — это просто обратный прокси».","Он также может нести маршрутизацию моделей, квоты токенов, атрибуцию затрат, применение политик, идентичность и телеметрию, специфичную для AI.",[813,814],"«Общий означает глобально общий».","Сервис может быть физически общим, но логически сегментированным по тенанту, приложению, региону, классификации или уровню риска.",[816,817],"«Одна центральная векторная база данных становится истиной компании».","Векторное хранилище или сервис поиска — это инфраструктура. Предметный авторитет, актуальность, происхождение и доступ остаются отдельными concerns.",[819,820],"«Оценка платформы заменяет оценку решения».","Общая регрессия и телеметрия не могут определить, приемлем ли ответ или действие, специфичные для предметной области.",[822,823],"«Абстракция провайдера должна скрывать все различия».","Некоторые различия являются существенными возможностями, семантикой безопасности или режимами отказа и должны оставаться видимыми.",[825,826],"«RBAC решает мультитенантность».","RBAC управляет действиями; изоляция тенантов управляет границами ресурсов. Может потребоваться и то, и другое.",[828,829],"«AI Platform Architect — это просто другое название для MLOps».","MLOps\u002FLLMOps — это крупная пересекающаяся дисциплина, но общие границы приложения\u002Fсреды выполнения, идентичности, шлюза, поиска и инструментов могут выходить за пределы операций жизненного цикла модели.",{"id":831,"data":832,"type":42},"h-failure",{"text":833,"level":242},"Режимы отказа, которые должен предотвращать AI Platform Architect",{"id":835,"data":836,"type":291},"failures-table",{"content":837,"stretched":43,"withHeadings":14},[838,841,844,847,850,853,856,859,862,865],[839,840],"Режим отказа","Архитектурное последствие",[842,843],"Каждая команда хранит собственные ключи провайдера","Дублирование обработки секретов, несогласованная ротация и больший радиус поражения.",[845,846],"Абстракция провайдера скрывает требуемые возможности","Потребители не могут использовать нужные им функции или незаметно получают поведение, отличное от ожидаемого.",[848,849],"Общий поиск игнорирует контекст арендатора\u002Fпользователя","Утечка данных за границы может произойти до того, как приложение получит возможность отфильтровать результаты.",[851,852],"Резервный вариант незаметно меняет провайдера или локальность","Стоимость, соответствие требованиям, местоположение данных и качество вывода могут измениться без ведома вызывающей стороны.",[854,855],"Инструменты агента предоставляются по выбору модели","Мощная модель получает избыточные привилегии, поскольку полномочия времени выполнения не обеспечиваются независимо.",[857,858],"Все запросы\u002Fответы журналируются по умолчанию","Наблюдаемость может создать новое хранилище конфиденциальных данных и проблему соответствия.",[860,861],"Платформа владеет одной общей оценкой качества","Доменные сбои остаются скрытыми за метриками работоспособности платформы.",[863,864],"Нет контракта версий для возможностей платформы","Изменения модели\u002Fпровайдера\u002Fсреды выполнения непредсказуемо ломают потребителей.",[866,867],"Всё, связанное с ИИ, централизовано","Платформа становится узким местом и монолитом вместо слоя многократно используемых возможностей.",{"id":869,"data":870,"type":42},"h-decision",{"text":871,"level":242},"Практическая последовательность решений по архитектуре платформы",{"id":873,"data":874,"type":340},"decision-flow",{"steps":875,"title":906,"orientation":339},[876,879,882,885,888,891,894,897,900,903],{"label":877,"description":878},"1. Определите реальных потребителей","Перечислите решения, команды, арендаторов и рабочие нагрузки, которые будут использовать платформу; избегайте создания платформы для гипотетического повторного использования.",{"label":880,"description":881},"2. Определите общую границу","Отделите сквозные механизмы от специфичных для решения доменных полномочий, рабочего процесса и приёмки.",{"label":883,"description":884},"3. Сначала определите идентичность и изоляцию","Установите пользователей, сервисы, приложения, арендаторов, регионы и классификации данных до того, как делиться возможностями поиска или инструментов.",{"label":886,"description":887},"4. Определите контракты возможностей","Задайте API модели\u002Fпровайдера, поиска, агента\u002Fинструмента, шлюза и телеметрии с явным владением и версионированием.",{"label":889,"description":890},"5. Выберите стратегию провайдера и среды выполнения","Выберите управляемое, самостоятельно размещённое, локальное или гибридное выполнение и задокументируйте семантику резервирования, локальности и возможностей.",{"label":892,"description":893},"6. Спроектируйте границы данных и поиска","Определите происхождение, распространение авторизации, владение корпусом, индексацию и ответственность за доказательства.",{"label":895,"description":896},"7. Добавьте квоты, секреты и политику","Контролируйте стоимость, ёмкость, учётные данные, разрешения инструментов, средства безопасности и радиус поражения.",{"label":898,"description":899},"8. Создайте контракты оценки и наблюдаемости","Предоставьте метрики платформы и трассировку, оставив доменную эталонную истину и приёмку решению.",{"label":901,"description":902},"9. Определите жизненный цикл и операции","Версионируйте возможности, тестируйте обновления, документируйте вывод из эксплуатации, откат, инциденты, ёмкость и подключение потребителей.",{"label":904,"description":905},"10. Проверьте с более чем одним потребителем","Заявление о платформе становится убедительным, когда общая возможность действительно обслуживает различные рабочие нагрузки, не вынуждая их использовать одну доменную модель.","От потребности платформы к эксплуатируемой общей возможности",{"id":908,"data":909,"type":42},"h-edge",{"text":910,"level":242},"Краевые случаи и ограничения роли",{"id":912,"data":913,"type":218},"p-edge-1",{"text":914},"Небольшой организации с одним ИИ-приложением может не требоваться отдельная ИИ-платформа или архитектор платформы. Преждевременное создание платформы может породить больше абстракции, чем ценности. Правильной архитектурой может быть одно хорошо спроектированное решение с несколькими многократно используемыми модулями.",{"id":916,"data":917,"type":218},"p-edge-2",{"text":918},"Изолированное или суверенное развёртывание существенно меняет модель провайдера, обновлений и наблюдаемости. Размещение моделей, распространение артефактов, интеграция идентичности и экспорт телеметрии могут потребовать локальных эквивалентов.",{"id":920,"data":921,"type":218},"p-edge-3",{"text":922},"Сильно регулируемые рабочие нагрузки или нагрузки с высокими последствиями могут требовать более сильной физической или организационной изоляции вместо логически общей платформы. Повторное использование никогда не является достаточной причиной ослаблять требуемую границу безопасности.",{"id":924,"data":925,"type":218},"p-edge-4",{"text":926},"Управляемые облачные ИИ-сервисы могут снять бремя реализации, но не снимают архитектурную ответственность. Организация по-прежнему решает вопросы идентичности, доступа к данным, журналирования, хранения, квот, допустимости моделей, резервирования, оценки и приёмки решений.",{"id":928,"data":929,"type":218},"p-edge-5",{"text":930},"Граница платформы также может различаться по модальности. Текстовый вывод, мультимодальная генерация, речь, использование компьютера и автономные агенты могут иметь разные требования к задержке, данным, разрешениям и наблюдаемости, даже если они используют общую инфраструктуру провайдера и идентичности.",{"id":932,"data":933,"type":42},"h-change",{"text":934,"level":242},"Что могло бы изменить этот ответ?",{"id":936,"data":937,"type":218},"p-change-1",{"text":938},"Основное определение изменилось бы при изменении организационного охвата. Если архитектор отвечает за одну рабочую нагрузку, роль становится ближе к архитектору ИИ-решений. Если ответственность расширяется до стратегии возможностей, инвестиций, стандартов и целевых портфелей на уровне всей организации, она смещается к корпоративной ИИ-архитектуре.",{"id":940,"data":941,"type":218},"p-change-2",{"text":942},"Руководство по реализации меняется всякий раз, когда меняются провайдеры, продукты-шлюзы, протоколы агентов, регуляторные обязательства, возможности моделей или ограничения развёртывания. Именно поэтому архитектура платформы должна выражать стабильные обязанности и контракты отдельно от текущих механизмов поставщиков.",{"id":944,"data":945,"type":42},"h-checklist",{"text":946,"level":242},"Контрольный список архитектора ИИ-платформы",{"id":948,"data":949,"type":291},"checklist-table",{"content":950,"stretched":43,"withHeadings":14},[951,954,957,960,963,966,969,972,975,978,981,984,987],[952,953],"Вопрос","Ожидаемый ответ",[955,956],"Кто является фактическими потребителями платформы?","Названные решения, команды или контексты арендаторов с различными, но пересекающимися потребностями.",[958,959],"Что действительно является общим?","Явный список возможностей, а не расплывчатый «ИИ-бэкенд».",[961,962],"Что должно оставаться специфичным для решения?","Доменные полномочия, бизнес-процесс, приёмка задач и другие вопросы, принадлежащие рабочей нагрузке.",[964,965],"Как представлены модели\u002Fпровайдеры?","Версионированные контракты провайдера\u002Fмодели с возможностями и явной семантикой резервирования.",[967,968],"Как распространяется идентичность?","Контекст пользователя\u002Fсервиса\u002Fприложения\u002Fарендатора сохраняется на каждом привилегированном пути запроса.",[970,971],"Как обеспечивается изоляция арендаторов?","Ограничение области ресурсов отделено от проверок разрешений ролей.",[973,974],"Как обрабатываются секреты?","Привилегированное хранение, ротация, ограниченное раскрытие и поддающееся аудиту владение.",[976,977],"Как поиск сохраняет полномочия?","Общие механизмы с авторизацией, происхождением и правилами доказательств, принадлежащими домену.",[979,980],"Как ограничиваются инструменты и агенты?","Разрешения времени выполнения, ограниченные контракты инструментов, одобрения, отмена и прослеживаемость.",[982,983],"Как контролируются стоимость и ёмкость?","Квоты, контроль токенов\u002Fскорости, атрибуция использования и поведение при перегрузке.",[985,986],"Как измеряется качество?","Регрессия\u002Fоценка платформы плюс специфичная для решения эталонная истина и приёмка.",[988,989],"Как внедряются изменения?","Версионирование, совместимость, миграция, вывод из эксплуатации, откат и ответственность за инциденты.",{"id":991,"data":992,"type":42},"h-conclusion",{"text":993,"level":242},"Заключение",{"id":995,"data":996,"type":218},"p-conclusion-1",{"text":997},"Архитектор ИИ-платформы отвечает за многократно используемую архитектуру \u003Cstrong>между возможностями ИИ и решениями, которые их потребляют\u003C\u002Fstrong>. Роль определяет, как модели, провайдеры, поиск, агенты, инструменты, идентичность, арендаторы, секреты, оценка, наблюдаемость, квоты и операции времени выполнения становятся надёжными сервисами платформы, а не повторяющимися разовыми интеграциями.",{"id":999,"data":1000,"type":218},"p-conclusion-2",{"text":1001},"Сложная часть — не максимизация повторного использования. Это выбор правильной границы. Сильная платформа стандартизирует механизмы, политику и операции там, где несколько потребителей действительно получают выгоду, сохраняя при этом специфичные для решения полномочия над данными, бизнес-логику, требования безопасности и критерии приёмки.",{"id":1003,"data":1004,"type":218},"p-conclusion-3",{"text":1005},"Это различие также объясняет связь с архитектурой ИИ-решений: \u003Cstrong>архитектор решений делает одну систему с поддержкой ИИ пригодной для её цели; архитектор платформы делает общие возможности ИИ безопасными, многократно используемыми, эксплуатируемыми и развиваемыми across many such systems.\u003C\u002Fstrong>",{"id":1007,"data":1008,"type":42},"h-related",{"text":1009,"level":242},"Связанные канонические знания",{"id":1011,"data":1012,"type":218},"p-related-1",{"text":1013},"Эта статья следует за каноническими основами по компонентам генеративного ИИ, ADR против NFR и архитектуре ИИ-решений. Эти концепции являются предварительными условиями, поскольку платформа существует для предоставления переиспользуемых системных возможностей и для кодирования архитектурных решений в соответствии с явными требованиями к качеству и эксплуатации.",{"id":1015,"data":1016,"type":218},"p-related-2",{"text":1017},"Генерация с дополнением из поиска — это один из примеров возможности, которая может предоставляться через платформу, но платформа не должна сводить инфраструктуру поиска, предметные знания и достоверность ответов в одно понятие.",{"id":1019,"data":1020,"type":1027},"related-rag",{"link":1021,"meta":1022},"https:\u002F\u002Fstajic.de\u002Fru\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works",{"image":1023,"title":1025,"description":1026},{"url":1024},"","Что такое RAG? Самое простое объяснение того, как это работает","Каноническое введение в генерацию с дополнением из поиска и границу между генерацией модели и извлечением внешних знаний.","linkTool",{"id":1029,"data":1030,"type":218},"p-related-3",{"text":1031},"Агентные протоколы, изоляция тенантов, управление ИИ, маршрутизация моделей, контекстная инженерия и MLOps\u002FLLMOps — это нижестоящие или смежные узлы знаний. О них становится легче рассуждать, когда граница платформы явно определена.",{"id":1033,"data":1034,"type":42},"h-faq",{"text":1035,"level":242},"Часто задаваемые вопросы",{"id":1037,"data":1038,"type":1037},"faq",{"items":1039,"title":1064},[1040,1044,1048,1052,1056,1060],{"id":1041,"answer":1042,"question":1043},"faq-1","Нет. Архитектор решений фокусируется на одном конкретном решении с поддержкой ИИ. Архитектор платформы фокусируется на переиспользуемых возможностях ИИ, средствах контроля и эксплуатационных контрактах, которые могут поддерживать множество решений.","Архитектор ИИ-платформы — это то же самое, что архитектор ИИ-решений?",{"id":1045,"answer":1046,"question":1047},"faq-2","Нет. Платформа может использовать управляемые облачные модели, самостоятельно размещённые модели, локальный инференс или гибридную стратегию. Архитектура должна делать явными последствия для провайдера, локальности, идентичности, маршрутизации, данных и эксплуатации.","Должна ли ИИ-платформа размещать собственные модели?",{"id":1049,"answer":1050,"question":1051},"faq-3","Обычно нет. Шлюз может быть важным компонентом платформы, но полноценной платформе также нужны контракты для идентичности, секретов, данных\u002Fпоиска, оценки, наблюдаемости, жизненного цикла и эксплуатационной ответственности.","Достаточно ли ИИ-шлюза, чтобы считаться ИИ-платформой?",{"id":1053,"answer":1054,"question":1055},"faq-4","Механику поиска часто можно сделать общей, но предметная авторитетность, авторизация, актуальность, достаточность доказательств и владение корпусом должны оставаться явными. Общая инфраструктура не подразумевает общую истину.","Следует ли централизовать поиск?",{"id":1057,"answer":1058,"question":1059},"faq-5","Нет. Оценка платформы может проверять общие возможности и регрессии. Каждому решению всё ещё нужны эталонные данные для конкретной задачи, критерии приёмки и предметные пороги качества.","Заменяет ли оценка платформы оценку приложения?",{"id":1061,"answer":1062,"question":1063},"faq-6","Нет. RBAC определяет, что может делать идентичность. Изоляция тенантов определяет, с ресурсами какого тенанта идентичность может действовать. Платформе часто нужно и то, и другое.","Мультитенантность — это просто RBAC?","FAQ архитектора ИИ-платформы",{"id":1066,"data":1067,"type":42},"h-glossary",{"text":1068,"level":242},"Глоссарий",{"id":1070,"data":1071,"type":1070},"glossary",{"title":1072,"entries":1073},"Ключевые термины архитектуры ИИ-платформы",[1074,1078,1082,1086,1090,1094,1098,1102],{"term":1075,"anchor":1076,"definition":1077},"ИИ-платформа","ai-platform","Переиспользуемый набор связанных с ИИ технических и эксплуатационных возможностей, потребляемых множеством приложений, команд или тенантных контекстов.",{"term":1079,"anchor":1080,"definition":1081},"ИИ-шлюз","ai-gateway","Слой шлюза для ИИ-эндпоинтов, который может добавлять аутентификацию, маршрутизацию, квоты, политику, повторные попытки, атрибуцию затрат и специфичную для ИИ телеметрию помимо базового проксирования.",{"term":1083,"anchor":1084,"definition":1085},"Адаптер провайдера","provider-adapter","Компонент, который отображает контракт платформы на API, возможности, состояние работоспособности и семантику отказов провайдера модели.",{"term":1087,"anchor":1088,"definition":1089},"Изоляция тенантов","tenant-isolation","Граница, которая предотвращает доступ одного тенантного контекста к ресурсам другого тенанта независимо от разрешений роли.",{"term":1091,"anchor":1092,"definition":1093},"Контракт возможности","capability-contract","Версионированный интерфейс и поведенческое соглашение, описывающее, что предоставляет общий сервис платформы и что потребитель должен предоставить или взять на себя.",{"term":1095,"anchor":1096,"definition":1097},"Сервис привязки к источникам \u002F поиска","grounding-service","Общая механика для поиска и предоставления внешней информации ИИ-нагрузке; она не определяет автоматически, какая информация является авторитетной для предметной области.",{"term":1099,"anchor":1100,"definition":1101},"Стенд оценки","evaluation-harness","Переиспользуемая инфраструктура для запуска тестов, наборов данных, версий моделей\u002Fпромптов и метрик; предметная приёмка остаётся специфичной для решения.",{"term":1103,"anchor":1104,"definition":1105},"Плоскость управления","control-plane","Слой конфигурации и управления, который управляет возможностями платформы, идентичностями, политиками, квотами, версиями и состоянием развёртывания.",{"id":1107,"data":1108,"type":42},"h-sources",{"text":1109,"level":242},"Первичные источники и актуальные рекомендации по архитектуре",{"id":1111,"data":1112,"type":218},"p-sources-note",{"text":1113},"Приведённые ниже источники подтверждают общие утверждения об архитектуре и производственной платформе. Разделы Aaasaasa AI Client, Aaasaasa AI CMS и Source of Truth Research Engine являются явно оригинальными доказательствами реализации. Внешние ссылки на текущее состояние были проверены 8 октября 2026 года.",{"id":1115,"data":1116,"type":1027},"src-iso-42010",{"link":1117,"meta":1118},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html",{"image":1119,"title":1120,"description":1121},{"url":1024},"ISO\u002FIEC\u002FIEEE 42010:2022 — Описание архитектуры","Действующий опубликованный международный стандарт для концепций и связей описания архитектуры.",{"id":1123,"data":1124,"type":1027},"src-nist-rmf",{"link":1125,"meta":1126},"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework",{"image":1127,"title":1128,"description":1129},{"url":1024},"NIST AI Risk Management Framework","Ресурсы и текущий статус NIST AI RMF; AI RMF 1.0 находится на стадии пересмотра по состоянию на октябрь 2026 года.",{"id":1131,"data":1132,"type":1027},"src-nist-gai",{"link":1133,"meta":1134},"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fartificial-intelligence-risk-management-framework-generative-artificial-intelligence",{"image":1135,"title":1136,"description":1137},{"url":1024},"NIST AI 600-1 — Профиль генеративного ИИ","Профиль генеративного ИИ для применения соображений управления рисками ИИ на протяжении жизненного цикла ИИ.",{"id":1139,"data":1140,"type":1027},"src-ms-ai",{"link":1141,"meta":1142},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fget-started",{"image":1143,"title":1144,"description":1145},{"url":1024},"Microsoft Azure Well-Architected — ИИ-нагрузки","Актуальные рекомендации по архитектуре, охватывающие приложение ИИ, данные, операции, оценку, ответственный ИИ и вопросы жизненного цикла.",{"id":1147,"data":1148,"type":1027},"src-ms-principles",{"link":1149,"meta":1150},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fdesign-principles",{"image":1151,"title":1152,"description":1153},{"url":1024},"Microsoft — Принципы проектирования для ИИ-нагрузок","Актуальные рекомендации по сегментации идентичностей, границам безопасности, телеметрии, производительности, данным и компромиссам платформы.",{"id":1155,"data":1156,"type":1027},"src-ms-gateway",{"link":1157,"meta":1158},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fai-foundry\u002Fconfiguration\u002Fenable-ai-api-management-gateway-portal?view=foundry",{"image":1159,"title":1160,"description":1161},{"url":1024},"Microsoft Foundry — Архитектура ИИ-шлюза","Актуальные рекомендации по ИИ-шлюзу для общего доступа к проектам, сдерживания токенов, квот и управления.",{"id":1163,"data":1164,"type":1027},"src-ms-gateway-guide",{"link":1165,"meta":1166},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Farchitecture\u002Fai-ml\u002Fguide\u002Fazure-openai-gateway-guide",{"image":1167,"title":1168,"description":1169},{"url":1024},"Azure Architecture Center — Доступ к моделям через шлюз","Рекомендации по архитектуре для централизованного доступа к моделям, маршрутизации, ограничения скорости, отработки отказов и обязанностей клиента\u002Fплатформы.",{"id":1171,"data":1172,"type":1027},"src-aws-genai",{"link":1173,"meta":1174},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fgenerative-ai-lens\u002F",{"image":1175,"title":1176,"description":1177},{"url":1024},"AWS Well-Architected — линза генеративного ИИ","Актуальные рекомендации по производственной архитектуре для рабочих нагрузок генеративного ИИ в области безопасности, надежности, эксплуатации, производительности и затрат.",{"id":1179,"data":1180,"type":1027},"src-aws-multitenant",{"link":1181,"meta":1182},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fgenerative-ai-lens\u002Fmulti-tenant-generative-ai-platform-scenario.html",{"image":1183,"title":1184,"description":1185},{"url":1024},"AWS — сценарий мультитенантной платформы генеративного ИИ","Актуальный пример, разделяющий централизованное управление платформой и аудируемость от качества данных потребляющих приложений и обязанностей, специфичных для рабочей нагрузки.",{"id":1187,"data":1188,"type":1027},"src-aws-agentic",{"link":1189,"meta":1190},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fagentic-ai-lens\u002Fdesign-principles.html",{"image":1191,"title":1192,"description":1193},{"url":1024},"AWS Well-Architected — принципы проектирования агентного ИИ","Актуальные рекомендации по ограничению полномочий агентов, прослеживаемости, версионированию поведения, явным контрактам и человеческому надзору.",{"id":1195,"data":1196,"type":1027},"src-aws-observability",{"link":1197,"meta":1198},"https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonCloudWatch\u002Flatest\u002Fmonitoring\u002FGenAI-observability.html",{"image":1199,"title":1200,"description":1201},{"url":1024},"AWS CloudWatch — наблюдаемость генеративного ИИ","Актуальные возможности наблюдаемости и производственные метрики для моделей, агентов, баз знаний, инструментов и анализа затрат\u002Fзадержек\u002Fошибок.","2.31","Архитектор платформы ИИ проектирует многоразовые основы ИИ для моделей, провайдеров, поиска, агентов, идентификации, безопасности, оценки, наблюдаемости и операций.","\u002Fuploads\u002F2026\u002F10\u002Fwhat-is-an-ai-platform-architect-models-data-runtime-security-and-operations-1791477229171-ou3zcc.webp","what-is-an-ai-platform-architect-models-data-runtime-security-and-operations-1791477229171-ou3zcc","PUBLISHED","2026-10-08T12:32:00.000Z","2026-10-08T16:32:14.856Z","2026-10-08T16:47:57.364Z",{"en":1211,"de":1212,"sr":1213,"es":1214,"fr":1215,"it":1216,"ru":1217,"zh":1218},"\u002Fblog\u002Fwhat-is-an-ai-platform-architect-models-data-runtime-security-and-operations","\u002Fde\u002Fblog\u002Fwhat-is-an-ai-platform-architect-models-data-runtime-security-and-operations","\u002Fsr\u002Fblog\u002Fwhat-is-an-ai-platform-architect-models-data-runtime-security-and-operations","\u002Fes\u002Fblog\u002Fwhat-is-an-ai-platform-architect-models-data-runtime-security-and-operations","\u002Ffr\u002Fblog\u002Fwhat-is-an-ai-platform-architect-models-data-runtime-security-and-operations","\u002Fit\u002Fblog\u002Fwhat-is-an-ai-platform-architect-models-data-runtime-security-and-operations","\u002Fru\u002Fblog\u002Fwhat-is-an-ai-platform-architect-models-data-runtime-security-and-operations","\u002Fzh\u002Fblog\u002Fwhat-is-an-ai-platform-architect-models-data-runtime-security-and-operations",[1220,1224,1228],{"id":1221,"name":1222,"slug":1223},84,"Политики и границы данных","policy-and-data",{"id":1225,"name":1226,"slug":1227},57,"Границы данных","data-boundaries",{"id":1229,"name":1230,"slug":1231},80,"Доступ и идентичность","access-and-identity",{"id":1233,"login":1234,"email":1235,"displayName":1236},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1238,2025],{"lang":1239,"title":1240,"content":1241,"contentJson":1242,"excerpt":2024},"en","What Is an AI Platform Architect? Models, Data, Runtime, Security and Operations","{\"time\":1791476955677,\"blocks\":[{\"id\":\"intro\",\"data\":{\"text\":\"An \u003Cstrong>AI Platform Architect\u003C\u002Fstrong> designs the reusable AI foundation through which multiple applications, teams, or tenant contexts access models, data and retrieval, agent and tool runtimes, identity and permissions, evaluation, observability, quotas, secrets, and deployment capabilities. The role is broader than infrastructure but narrower than owning every AI-enabled product: its central responsibility is deciding \u003Cstrong>what should be shared, how shared capabilities are governed and isolated, and what must remain solution-specific\u003C\u002Fstrong>.\"},\"type\":\"paragraph\"},{\"id\":\"direct\",\"data\":{\"body\":\"\u003Cstrong>An AI Platform Architect designs the shared technical and operational substrate for AI systems.\u003C\u002Fstrong> Instead of architecting one assistant or one workflow, the role defines reusable contracts and boundaries for model\u002Fprovider access, gateways and routing, retrieval services, agent runtimes, tool access, identity and tenant isolation, secrets, evaluation, telemetry, deployment and lifecycle management.\",\"title\":\"Direct answer\",\"variant\":\"info\"},\"type\":\"callout\"},{\"id\":\"term-note\",\"data\":{\"body\":\"\u003Cstrong>AI Platform Architect is a practical role label, not a universally standardized job title.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 defines concepts for architecture descriptions, not this role. Different organizations may split these responsibilities among platform architects, solution architects, enterprise architects, security architects, MLOps\u002FLLMOps specialists and platform engineering teams. This article uses the term for the architecture responsibility over a reusable AI platform layer.\",\"title\":\"Terminology note\",\"variant\":\"note\"},\"type\":\"callout\"},{\"id\":\"version-note\",\"data\":{\"body\":\"The stable architectural principles here are vendor-neutral. Current Microsoft, AWS and NIST guidance is used as external implementation and governance evidence. NIST states that AI RMF 1.0 is being revised; vendor platform features, gateway products, agent runtimes and model capabilities evolve faster than the architectural principles, so version-sensitive implementation choices must be rechecked before deployment.\",\"title\":\"Current-source note — 8 October 2026\",\"variant\":\"note\"},\"type\":\"callout\"},{\"id\":\"toc\",\"data\":{\"title\":\"Contents\",\"maxLevel\":3,\"minLevel\":2},\"type\":\"tableOfContents\"},{\"id\":\"h-meaning\",\"data\":{\"text\":\"What does an AI Platform Architect actually architect?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-meaning-1\",\"data\":{\"text\":\"The object of the work is the \u003Cstrong>platform\u003C\u002Fstrong>: a set of shared capabilities that reduces repeated integration work while preserving explicit security, data and operational boundaries. A platform can expose model access, provider adapters, retrieval primitives, agent execution, tool brokers, policy enforcement, evaluation, telemetry and deployment services to many consuming solutions.\"},\"type\":\"paragraph\"},{\"id\":\"p-meaning-2\",\"data\":{\"text\":\"The platform is not valuable merely because components are centralized. It is valuable when consumers receive stable capabilities with clear contracts, ownership, isolation, observability and lifecycle rules. The key architectural question is therefore not “Which model should everyone use?” but \u003Cstrong>“Which responsibilities can be safely standardized and reused without erasing the requirements of each solution?”\u003C\u002Fstrong>.\"},\"type\":\"paragraph\"},{\"id\":\"solution-vs-platform\",\"data\":{\"rows\":[{\"id\":\"c1\",\"label\":\"Primary scope\",\"values\":{\"platform\":\"Reusable AI capabilities consumed by multiple solutions, teams or tenant contexts.\",\"solution\":\"One concrete AI-enabled product, workflow or application.\"}},{\"id\":\"c2\",\"label\":\"Main question\",\"values\":{\"platform\":\"Which shared capabilities and controls should solutions consume, and where must solution-specific ownership remain?\",\"solution\":\"How should this solution meet its business, data, security, quality and operational requirements?\"}},{\"id\":\"c3\",\"label\":\"Data authority\",\"values\":{\"platform\":\"Provides storage, retrieval, provenance or access primitives without automatically becoming the authority for every domain.\",\"solution\":\"Defines which domain data is authoritative and how the solution may use it.\"}},{\"id\":\"c4\",\"label\":\"Evaluation\",\"values\":{\"platform\":\"Provides reusable evaluation, telemetry and release mechanisms; it cannot define every domain's success threshold.\",\"solution\":\"Defines task-specific quality and acceptance criteria.\"}},{\"id\":\"c5\",\"label\":\"Lifecycle\",\"values\":{\"platform\":\"Owns shared capability versions, compatibility, onboarding, quotas, policy and operational contracts.\",\"solution\":\"Owns the lifecycle of the specific workload.\"}}],\"title\":\"Solution architecture and platform architecture solve different scope problems\",\"layout\":\"table\",\"columns\":[{\"id\":\"solution\",\"label\":\"AI Solution Architect\"},{\"id\":\"platform\",\"label\":\"AI Platform Architect\"}]},\"type\":\"comparison\"},{\"id\":\"h-simple\",\"data\":{\"text\":\"The simplest example\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-simple-1\",\"data\":{\"text\":\"Imagine an organization has five AI-enabled products: an internal document assistant, a customer-support copilot, a software-engineering agent, a contract review workflow and a product-search assistant. Each product could independently integrate model APIs, keep credentials, implement retries, collect token metrics, create retrieval code and build its own tool permissions.\"},\"type\":\"paragraph\"},{\"id\":\"p-simple-2\",\"data\":{\"text\":\"That duplication is expensive and dangerous when every team invents a different security and operational model. A shared platform can instead offer approved provider connections, model discovery, quotas, credentials, tenant-aware access, common telemetry, reusable retrieval services and an agent\u002Ftool runtime contract.\"},\"type\":\"paragraph\"},{\"id\":\"p-simple-3\",\"data\":{\"text\":\"But the platform must stop at the correct boundary. The contract-review solution may require legal-document authority and citation rules that the software agent does not. The product-search assistant may need commerce-specific freshness and authorization rules. \u003Cstrong>Reusable infrastructure does not make all domain truth reusable.\u003C\u002Fstrong>\"},\"type\":\"paragraph\"},{\"id\":\"simple-flow\",\"data\":{\"steps\":[{\"label\":\"1. Consumer identifies itself\",\"description\":\"The calling application, user, service, team or tenant enters through an authenticated identity and explicit scope.\"},{\"label\":\"2. Platform policy applies\",\"description\":\"Gateway and policy layers determine allowed providers, models, quotas, data paths, tools and execution modes.\"},{\"label\":\"3. Shared capability executes\",\"description\":\"The request may use inference, retrieval, agent runtime, tool access or another reusable platform service.\"},{\"label\":\"4. Solution-specific context remains authoritative\",\"description\":\"The consuming solution supplies domain rules, user intent, data authority, task-specific constraints and acceptance logic.\"},{\"label\":\"5. Telemetry and evidence are captured\",\"description\":\"The platform records identity, route, model\u002Fprovider, latency, cost, errors, tool activity and other permitted observability signals.\"},{\"label\":\"6. Result returns under the solution contract\",\"description\":\"The solution remains responsible for whether the output is acceptable for its user and domain.\"}],\"title\":\"A shared AI request path\",\"orientation\":\"auto\"},\"type\":\"processFlow\"},{\"id\":\"h-stops\",\"data\":{\"text\":\"Where the simple example stops\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-stops-1\",\"data\":{\"text\":\"Centralization is not automatically architecture. A single endpoint in front of several model APIs is useful, but it does not by itself create an AI platform. A production platform also needs identity boundaries, capability contracts, provider health and lifecycle handling, quotas, secret ownership, observability, compatibility rules, security controls, release discipline and clear operational responsibility.\"},\"type\":\"paragraph\"},{\"id\":\"p-stops-2\",\"data\":{\"text\":\"The opposite failure is also common: putting every prompt, vector index, business rule, agent and application workflow into one “AI backend.” That creates a monolith whose shared status is accidental rather than architectural. \u003Cstrong>A platform should standardize cross-cutting capabilities, not absorb domain ownership merely because AI is involved.\u003C\u002Fstrong>\"},\"type\":\"paragraph\"},{\"id\":\"h-boundary\",\"data\":{\"text\":\"The most important platform decision: shared versus solution-specific\",\"level\":2},\"type\":\"header\"},{\"id\":\"shared-boundary-table\",\"data\":{\"content\":[[\"Capability area\",\"Good candidate for shared platform ownership\",\"Usually remains solution-specific\"],[\"Model access\",\"Approved provider connections, adapters, credentials, health, routing primitives, quotas\",\"Task-specific model acceptance, prompt behavior, quality threshold\"],[\"Retrieval\",\"Ingestion primitives, extraction, indexing, search APIs, provenance contracts, authorization hooks\",\"Authoritative corpus, freshness rules, domain metadata, evidence sufficiency\"],[\"Agents and tools\",\"Runtime lifecycle, tool registry\u002Fbroker, permission enforcement, tracing, cancellation\",\"Business workflow, allowed action semantics, escalation policy, task success\"],[\"Security\",\"Identity integration, secret storage, policy enforcement, audit contracts, tenant isolation mechanisms\",\"Data classification, business authorization rules, domain-specific risk acceptance\"],[\"Evaluation\",\"Harness, dataset\u002Fversion mechanics, telemetry, experiment\u002Frelease workflow\",\"Ground truth, domain test set, acceptance threshold, user outcome\"],[\"Operations\",\"Deployment pattern, health, metrics, incident integration, capacity controls\",\"Solution SLOs where they differ, business continuity impact, workload-specific runbooks\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"boundary-principle\",\"data\":{\"body\":\"\u003Cstrong>Share mechanics and controls where reuse is real; keep authority and acceptance where the domain owns them.\u003C\u002Fstrong> This prevents two opposite errors: duplicated infrastructure everywhere, and a central platform that falsely becomes the owner of every application's data, policy and quality.\",\"title\":\"Platform principle\",\"variant\":\"success\"},\"type\":\"callout\"},{\"id\":\"h-responsibility-map\",\"data\":{\"text\":\"Architecture responsibility map\",\"level\":2},\"type\":\"header\"},{\"id\":\"h-provider\",\"data\":{\"text\":\"1. Model and provider access\",\"level\":3},\"type\":\"header\"},{\"id\":\"p-provider-1\",\"data\":{\"text\":\"A platform architect defines how consumers discover and invoke models without forcing every application to hard-code one provider. This includes provider adapters, model identifiers, capability metadata, authentication, health checks, endpoint configuration, request normalization and compatibility behavior.\"},\"type\":\"paragraph\"},{\"id\":\"p-provider-2\",\"data\":{\"text\":\"Provider abstraction must remain honest. Different providers expose different context limits, tool semantics, structured-output behavior, multimodal capabilities, safety controls, caching, pricing and failure modes. A good abstraction creates a stable platform contract while preserving access to capabilities that cannot be meaningfully flattened.\"},\"type\":\"paragraph\"},{\"id\":\"provider-warning\",\"data\":{\"body\":\"A lowest-common-denominator API can make migration easier but can also erase capabilities that matter. The architecture should define which features are portable, which are provider-specific and how consumers discover that difference.\",\"title\":\"Do not confuse abstraction with pretending providers are identical\",\"variant\":\"warning\"},\"type\":\"callout\"},{\"id\":\"h-gateway\",\"data\":{\"text\":\"2. Gateway, routing, quotas and cost controls\",\"level\":3},\"type\":\"header\"},{\"id\":\"p-gateway-1\",\"data\":{\"text\":\"A shared AI gateway can centralize authentication, routing, throttling, retries, token limits, usage attribution and policy enforcement. Microsoft’s current AI Gateway guidance explicitly treats token-per-minute limits, quotas and multi-project containment as platform concerns; AWS likewise exposes account and model quotas and centralized controls.\"},\"type\":\"paragraph\"},{\"id\":\"p-gateway-2\",\"data\":{\"text\":\"The gateway is therefore more than a reverse proxy when it carries AI-specific policy and operational semantics. But it should not silently make business decisions. A routing policy may prefer a healthy local model, a lower-cost provider or a regionally compliant endpoint; whether that route is acceptable for a particular task is still a contract between platform and solution.\"},\"type\":\"paragraph\"},{\"id\":\"p-gateway-3\",\"data\":{\"text\":\"Routing also needs failure semantics. If the preferred model is unavailable, the platform must know whether fallback is permitted, whether a cloud route requires explicit consent, whether a lower-capability model is valid and how the decision is surfaced to observability.\"},\"type\":\"paragraph\"},{\"id\":\"h-data\",\"data\":{\"text\":\"3. Shared data, retrieval and grounding services\",\"level\":3},\"type\":\"header\"},{\"id\":\"p-data-1\",\"data\":{\"text\":\"Retrieval services are strong platform candidates because parsing, chunking, indexing, lexical search, semantic search, metadata filtering, provenance and citation mechanics are reusable. However, the platform must not confuse a shared retrieval engine with a shared source of truth.\"},\"type\":\"paragraph\"},{\"id\":\"p-data-2\",\"data\":{\"text\":\"A solution still owns questions such as: Which corpus is authoritative? Which version is valid? Can this user see this document? How fresh must the data be? What counts as sufficient evidence? Can an answer be generated when retrieval fails? Those are domain and solution requirements even when the platform supplies the retrieval machinery.\"},\"type\":\"paragraph\"},{\"id\":\"p-data-3\",\"data\":{\"text\":\"This boundary is especially important in multi-tenant systems. A technically shared index or vector service does not justify cross-tenant visibility. Authorization context must be preserved through retrieval, not added only after search results have already crossed the boundary.\"},\"type\":\"paragraph\"},{\"id\":\"h-agent-runtime\",\"data\":{\"text\":\"4. Agent and tool runtime\",\"level\":3},\"type\":\"header\"},{\"id\":\"p-agent-1\",\"data\":{\"text\":\"Agentic systems add reusable runtime concerns: thread\u002Fsession lifecycle, planning loops, tool registration, tool invocation, cancellation, timeouts, human approvals, memory\u002Fstate interfaces, remote-agent protocols and trace correlation. A platform can provide these mechanics so each product does not rebuild them.\"},\"type\":\"paragraph\"},{\"id\":\"p-agent-2\",\"data\":{\"text\":\"The platform must also keep tool permission separate from model capability. A model being capable of generating a shell command does not mean the runtime should allow shell execution. The permission boundary belongs to the application\u002Fruntime architecture and must be enforceable independently of the model.\"},\"type\":\"paragraph\"},{\"id\":\"p-agent-3\",\"data\":{\"text\":\"Current AWS Agentic AI guidance emphasizes bounded agents, explicit authority, end-to-end tracing, versioned behavioral artifacts and human oversight proportionate to consequence. Those are platform-enabling concerns, but the consuming solution still defines what actions are legitimate for its domain.\"},\"type\":\"paragraph\"},{\"id\":\"h-identity\",\"data\":{\"text\":\"5. Identity, tenant isolation and authorization\",\"level\":3},\"type\":\"header\"},{\"id\":\"p-identity-1\",\"data\":{\"text\":\"AI platforms often sit in front of high-value models, proprietary data and action-capable tools. Authentication is therefore only the beginning. The architecture must carry user, service, application and tenant context through every privileged operation that needs it.\"},\"type\":\"paragraph\"},{\"id\":\"p-identity-2\",\"data\":{\"text\":\"\u003Cstrong>RBAC and tenant isolation solve different problems.\u003C\u002Fstrong> RBAC answers what an identity may do; tenant isolation answers which tenant’s resources that identity may act on. A platform that checks roles but loses tenant context can still expose the wrong data.\"},\"type\":\"paragraph\"},{\"id\":\"p-identity-3\",\"data\":{\"text\":\"Microsoft’s current AI workload guidance explicitly recommends identity segmentation and authorization-aware access to content. AWS’s multi-tenant generative AI platform guidance similarly treats logical isolation, centralized controls and auditability as platform concerns.\"},\"type\":\"paragraph\"},{\"id\":\"h-secrets\",\"data\":{\"text\":\"6. Secrets, credentials and trust boundaries\",\"level\":3},\"type\":\"header\"},{\"id\":\"p-secrets-1\",\"data\":{\"text\":\"A platform should define who owns provider keys, remote bearer tokens, signing material and tool credentials, where they are stored, which process can access them, how they are rotated and whether they can ever reach a browser or untrusted renderer.\"},\"type\":\"paragraph\"},{\"id\":\"p-secrets-2\",\"data\":{\"text\":\"This is an architectural boundary, not an implementation detail. If every consuming application copies provider credentials into its own configuration, the organization has duplicated both operational burden and blast radius. Centralization can reduce that risk only if the platform itself has narrower, auditable access paths.\"},\"type\":\"paragraph\"},{\"id\":\"h-eval\",\"data\":{\"text\":\"7. Evaluation, observability and auditability\",\"level\":3},\"type\":\"header\"},{\"id\":\"p-eval-1\",\"data\":{\"text\":\"A reusable platform can provide evaluation harnesses, trace IDs, model\u002Fprovider metadata, token and cost metrics, latency, error rates, prompt\u002Fmodel version linkage, agent\u002Ftool traces and controlled logging. AWS and Microsoft both treat observability and evaluation as core production concerns for AI workloads.\"},\"type\":\"paragraph\"},{\"id\":\"p-eval-2\",\"data\":{\"text\":\"Platform evaluation and solution evaluation must remain separate. A platform can verify that an endpoint is healthy, a model version passes a general regression suite and traces are complete. It cannot decide that a legal answer, medical workflow or product recommendation is acceptable without domain-specific ground truth and acceptance criteria.\"},\"type\":\"paragraph\"},{\"id\":\"p-eval-3\",\"data\":{\"text\":\"Logging also creates a privacy boundary. Prompt and response logs may contain sensitive or proprietary data. The platform architect must therefore decide what is logged, redacted, sampled, retained and accessible rather than assuming that more telemetry is always safer.\"},\"type\":\"paragraph\"},{\"id\":\"h-runtime\",\"data\":{\"text\":\"8. Runtime, deployment and locality\",\"level\":3},\"type\":\"header\"},{\"id\":\"p-runtime-1\",\"data\":{\"text\":\"A platform architect decides how shared AI capabilities are deployed and reached: managed cloud services, self-hosted endpoints, local inference, hybrid routing, containerized services, desktop runtimes, private networking or air-gapped environments. The important distinction is between \u003Cstrong>where the control\u002Fruntime process runs\u003C\u002Fstrong> and \u003Cstrong>where inference and data processing actually occur\u003C\u002Fstrong>.\"},\"type\":\"paragraph\"},{\"id\":\"p-runtime-2\",\"data\":{\"text\":\"A local client may still call a cloud model. A cloud control plane may route to an on-premises model. A remote agent may execute tools inside a customer network. Architectural diagrams must therefore show trust and data-flow boundaries rather than using “local” and “cloud” as vague labels.\"},\"type\":\"paragraph\"},{\"id\":\"h-lifecycle\",\"data\":{\"text\":\"9. Platform lifecycle, compatibility and onboarding\",\"level\":3},\"type\":\"header\"},{\"id\":\"p-lifecycle-1\",\"data\":{\"text\":\"Reusable capability becomes a platform only when consumers can depend on it over time. That requires versioned contracts, migration rules, compatibility policy, deprecation, release testing, rollback, incident ownership, capacity planning, documentation and a path for onboarding new teams or applications.\"},\"type\":\"paragraph\"},{\"id\":\"p-lifecycle-2\",\"data\":{\"text\":\"Fast-moving AI ecosystems make this particularly important. Model names, SDKs, protocol versions, provider APIs and safety capabilities change independently. A platform must absorb some of that volatility without hiding changes that materially affect a solution’s behavior.\"},\"type\":\"paragraph\"},{\"id\":\"h-control-plane\",\"data\":{\"text\":\"A practical control-plane \u002F execution-plane \u002F solution-plane model\",\"level\":2},\"type\":\"header\"},{\"id\":\"model-note\",\"data\":{\"body\":\"The three-plane model below is a practical way to reason about responsibilities; it is not an ISO, NIST, Microsoft or AWS standard. Its purpose is to make ownership boundaries explicit.\",\"title\":\"Proposed architecture model\",\"variant\":\"note\"},\"type\":\"callout\"},{\"id\":\"planes-table\",\"data\":{\"content\":[[\"Plane\",\"Typical responsibilities\",\"Should not silently own\"],[\"Platform control plane\",\"Provider registry, model policy, quotas, tenant configuration, identities, secrets, routing rules, capability versions, deployment configuration\",\"Application business logic or domain truth\"],[\"Platform execution\u002Fdata plane\",\"Inference requests, retrieval operations, agent\u002Ftool execution, extraction, indexing, telemetry emission, policy enforcement\",\"Cross-tenant access merely because infrastructure is shared\"],[\"Solution plane\",\"User workflow, prompts\u002Finstructions, authoritative corpus selection, domain authorization, business rules, task evaluation and acceptance\",\"Low-level provider integration that the platform explicitly owns\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"p-control-plane-1\",\"data\":{\"text\":\"This separation helps diagnose platform drift. If an application must know every provider-specific credential and endpoint, the platform contract is too thin. If the platform decides which customer record is legally authoritative or whether a domain answer is acceptable, the platform has crossed into solution ownership.\"},\"type\":\"paragraph\"},{\"id\":\"h-artifacts\",\"data\":{\"text\":\"What should an AI Platform Architect produce?\",\"level\":2},\"type\":\"header\"},{\"id\":\"artifacts-table\",\"data\":{\"content\":[[\"Architecture artifact\",\"Purpose\"],[\"Platform capability map\",\"Defines what the platform provides, who consumes it and which capabilities remain outside scope.\"],[\"Provider\u002Fmodel contract\",\"Defines providers, models, capabilities, abstraction boundaries, route metadata and fallback semantics.\"],[\"Identity and tenancy model\",\"Defines user\u002Fservice\u002Fapplication identity, tenant context, RBAC\u002FABAC hooks and resource isolation.\"],[\"Gateway and quota policy\",\"Defines rate limits, token\u002Fcost budgets, routing controls, retries and capacity behavior.\"],[\"Retrieval\u002Fdata contract\",\"Defines ingestion, provenance, search, metadata, authorization propagation and where domain authority remains.\"],[\"Agent\u002Ftool contract\",\"Defines runtime lifecycle, tool registration, permissions, approvals, cancellation and trace behavior.\"],[\"Secret and trust-boundary model\",\"Defines credential ownership, storage, process boundaries, rotation and sensitive data paths.\"],[\"Evaluation and telemetry contract\",\"Defines common metrics, traces, datasets\u002Fversion links, logging policy and solution extension points.\"],[\"Lifecycle and compatibility policy\",\"Defines versions, migrations, deprecation, releases, rollback, incident ownership and onboarding.\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"h-tradeoffs\",\"data\":{\"text\":\"The work is mostly trade-offs, not maximum centralization\",\"level\":2},\"type\":\"header\"},{\"id\":\"tradeoff-comparison\",\"data\":{\"rows\":[{\"id\":\"t1\",\"label\":\"Provider abstraction\",\"values\":{\"pressureA\":\"Stable portable platform API\",\"pressureB\":\"Access to provider-specific capabilities and fast innovation\"}},{\"id\":\"t2\",\"label\":\"Reuse\",\"values\":{\"pressureA\":\"Shared services reduce duplication\",\"pressureB\":\"Isolation and domain autonomy prevent unsafe coupling\"}},{\"id\":\"t3\",\"label\":\"Governance\",\"values\":{\"pressureA\":\"Central policy and auditability\",\"pressureB\":\"Team speed and local experimentation\"}},{\"id\":\"t4\",\"label\":\"Observability\",\"values\":{\"pressureA\":\"Rich traces for debugging and evaluation\",\"pressureB\":\"Privacy, data minimization and logging cost\"}},{\"id\":\"t5\",\"label\":\"Availability\",\"values\":{\"pressureA\":\"Fallback and multi-provider resilience\",\"pressureB\":\"Predictable quality, compliance and data-location guarantees\"}},{\"id\":\"t6\",\"label\":\"Platform scope\",\"values\":{\"pressureA\":\"More reusable capabilities\",\"pressureB\":\"Smaller blast radius and less platform lock-in\"}}],\"title\":\"Common platform trade-offs\",\"layout\":\"table\",\"columns\":[{\"id\":\"pressureA\",\"label\":\"Pressure A\"},{\"id\":\"pressureB\",\"label\":\"Pressure B\"}]},\"type\":\"comparison\"},{\"id\":\"h-adjacent\",\"data\":{\"text\":\"How is this different from adjacent roles?\",\"level\":2},\"type\":\"header\"},{\"id\":\"roles-table\",\"data\":{\"content\":[[\"Role\",\"Primary architectural scope\"],[\"AI Solution Architect\",\"A concrete AI-enabled solution and its end-to-end requirements, boundaries, trade-offs and production acceptance.\"],[\"AI Platform Architect\",\"Reusable AI capabilities and operational\u002Fsecurity contracts consumed across multiple solutions or teams.\"],[\"Enterprise Architect\",\"Organization-wide business\u002Ftechnology portfolio, capability and governance alignment at a broader level.\"],[\"MLOps \u002F LLMOps Architect or specialist\",\"Model and AI lifecycle, deployment, experiments, observability, release and operational practices; may overlap strongly but does not automatically own the whole shared application platform.\"],[\"Platform Engineer \u002F SRE\",\"Implements and operates platform infrastructure, reliability, automation and developer experience; architecture responsibility may be shared with the platform architect.\"],[\"AI \u002F Software Engineer\",\"Implements models, integrations, services, agents, retrieval and product functionality inside the agreed architecture.\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"p-adjacent-1\",\"data\":{\"text\":\"These boundaries are organizational, not universal. In a small team one person may hold several responsibilities. In a regulated enterprise they may be split across architecture, security, platform, data and operations groups. The useful distinction is the \u003Cstrong>scope of architectural responsibility\u003C\u002Fstrong>, not the job title printed on an org chart.\"},\"type\":\"paragraph\"},{\"id\":\"h-evidence\",\"data\":{\"text\":\"Implementation evidence: how these platform boundaries appear in my own work\",\"level\":2},\"type\":\"header\"},{\"id\":\"evidence-note\",\"data\":{\"body\":\"The following sections describe concrete patterns from my own projects. They are evidence that these architectural boundaries have been implemented or explicitly designed in real code and project systems. They are \u003Cstrong>not\u003C\u002Fstrong> claims that the projects together already constitute a commercially deployed enterprise AI platform.\",\"title\":\"Original implementation evidence\",\"variant\":\"note\"},\"type\":\"callout\"},{\"id\":\"h-ai-client\",\"data\":{\"text\":\"Aaasaasa AI Client: provider, runtime and permission separation\",\"level\":3},\"type\":\"header\"},{\"id\":\"p-ai-client-1\",\"data\":{\"text\":\"Aaasaasa AI Client is a local-first desktop AI workspace built with Nuxt 4, Electron and TypeScript. Its AI Hub deliberately separates \u003Cstrong>agent\u002Fclient, provider, model, connection\u002Fruntime location, permissions and web client\u003C\u002Fstrong> instead of treating them as one configuration value.\"},\"type\":\"paragraph\"},{\"id\":\"p-ai-client-2\",\"data\":{\"text\":\"The implementation includes direct provider adapters, Codex agent runtime integration, local Ollama\u002FLM Studio paths, OpenAI-compatible services, centralized workspace permissions, main-process credential storage, DuckDB, Qdrant\u002Fvector support, PDF\u002Freadability extraction and authenticated MCP-based directory access.\"},\"type\":\"paragraph\"},{\"id\":\"p-ai-client-3\",\"data\":{\"text\":\"Two platform lessons are especially relevant. First, a local runtime is not the same as local inference: a local Codex process can still use a cloud model. Second, automatic routing does not silently fall back from local to paid cloud inference. That makes routing policy and runtime locality explicit rather than inferred from UI labels.\"},\"type\":\"paragraph\"},{\"id\":\"ai-client-evidence-table\",\"data\":{\"content\":[[\"Implemented boundary\",\"Platform-architecture meaning\"],[\"Agent vs provider vs model\",\"Different responsibilities can evolve independently instead of being hidden behind one “AI” selector.\"],[\"Permissions separate from model\",\"Filesystem\u002Ftool authority belongs to the runtime policy, not model capability.\"],[\"Main-process secrets\",\"Credential ownership follows the privileged process boundary rather than the renderer\u002FUI.\"],[\"Provider health and model discovery\",\"Routing and availability are runtime\u002Fplatform concerns.\"],[\"No silent cloud fallback\",\"Cost, locality and data-transfer semantics remain explicit policy decisions.\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"h-cms\",\"data\":{\"text\":\"Aaasaasa AI CMS: tenant-scoped authorization as a platform boundary\",\"level\":3},\"type\":\"header\"},{\"id\":\"p-cms-1\",\"data\":{\"text\":\"The Aaasaasa AI CMS codebase provides a separate implementation example: tenant-scoped RBAC is represented through roles, permissions and user-role assignments bound to a tenant identifier. System permissions are grouped by capability, and role lookup and updates remain tenant-scoped.\"},\"type\":\"paragraph\"},{\"id\":\"p-cms-2\",\"data\":{\"text\":\"This is not itself proof of a complete AI platform, but it is directly relevant to one of the hardest shared-platform boundaries: a reusable service must preserve \u003Cstrong>who may do what\u003C\u002Fstrong> and \u003Cstrong>for which tenant\u003C\u002Fstrong>. Adding AI inference or retrieval on top of an application platform does not remove that requirement.\"},\"type\":\"paragraph\"},{\"id\":\"p-cms-3\",\"data\":{\"text\":\"The architectural implication is that model gateways, retrieval services and agents should consume established identity\u002Ftenant context rather than inventing a parallel AI-only authorization universe.\"},\"type\":\"paragraph\"},{\"id\":\"h-sot\",\"data\":{\"text\":\"Source of Truth Research Engine: shared retrieval mechanics without shared truth\",\"level\":3},\"type\":\"header\"},{\"id\":\"p-sot-1\",\"data\":{\"text\":\"The Source of Truth Research Engine provides a third implementation example. Different research modes share a common evidence core: Sources, Artifacts, provenance, Claims, Relations, Contradictions, a Reference Model and audit trail. The system also provides local lexical retrieval, optional semantic retrieval, extraction, snapshots and SHA-256-based provenance.\"},\"type\":\"paragraph\"},{\"id\":\"p-sot-2\",\"data\":{\"text\":\"The project explicitly treats search and semantic similarity as discovery signals rather than evidence. A result must be traced back to a concrete source and locator before it can support a claim. This is precisely the distinction an AI platform needs: \u003Cstrong>reusable retrieval machinery can be shared while evidence authority remains governed by the consuming methodology and domain.\u003C\u002Fstrong>\"},\"type\":\"paragraph\"},{\"id\":\"p-sot-3\",\"data\":{\"text\":\"The engine also demonstrates why one shared platform does not require one shared interpretation. Historical, scientific\u002Ftechnical, market-intelligence and monitoring modes can reuse core evidence infrastructure while retaining mode-specific methodology.\"},\"type\":\"paragraph\"},{\"id\":\"evidence-synthesis\",\"data\":{\"body\":\"Across these projects, the reusable pattern is not “one backend for everything.” It is \u003Cstrong>separation of concerns plus explicit contracts\u003C\u002Fstrong>: provider\u002Fmodel\u002Fruntime separation, tenant-aware authorization, credential boundaries, reusable data\u002Fretrieval primitives, provenance, and domain-specific authority. A future integrated platform would need stable contracts between those capabilities rather than direct coupling between codebases.\",\"title\":\"What these implementations demonstrate together\",\"variant\":\"success\"},\"type\":\"callout\"},{\"id\":\"h-frameworks\",\"data\":{\"text\":\"How current architecture guidance supports this platform scope\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-frameworks-1\",\"data\":{\"text\":\"ISO\u002FIEC\u002FIEEE 42010:2022 provides a general discipline for architecture descriptions across software, systems, enterprises and related entities. It does not define an AI Platform Architect, but it reinforces the need to express architectural concerns, relationships and viewpoints rather than reducing architecture to a technology list.\"},\"type\":\"paragraph\"},{\"id\":\"p-frameworks-2\",\"data\":{\"text\":\"NIST AI RMF 1.0 and the Generative AI Profile frame AI risk management across the lifecycle rather than only at model selection time. Governance, mapping, measurement and management are therefore compatible with a platform architecture that carries shared controls and evidence across many consuming workloads.\"},\"type\":\"paragraph\"},{\"id\":\"p-frameworks-3\",\"data\":{\"text\":\"Microsoft’s current AI workload guidance treats application design, data, security, operations, testing\u002Fevaluation and GenAIOps as connected architectural areas. Its current AI Gateway guidance also shows practical platform concerns such as centralized model access, project-specific token limits, quotas and multi-team containment.\"},\"type\":\"paragraph\"},{\"id\":\"p-frameworks-4\",\"data\":{\"text\":\"AWS’s current Generative AI Lens and multi-tenant platform scenario similarly separate foundational platform controls from consuming-application ownership. AWS explicitly notes that a central platform can enforce shared guardrails and auditability while data quality and workload-specific observability still remain responsibilities of consuming applications or data producers.\"},\"type\":\"paragraph\"},{\"id\":\"p-frameworks-5\",\"data\":{\"text\":\"The vendor products differ, but the cross-source pattern is stable: production AI platforms must coordinate identity, data access, models, policy, evaluation, observability, capacity, cost and lifecycle. A GPU cluster or model endpoint covers only part of that responsibility.\"},\"type\":\"paragraph\"},{\"id\":\"h-misconceptions\",\"data\":{\"text\":\"Common misconceptions\",\"level\":2},\"type\":\"header\"},{\"id\":\"misconceptions-table\",\"data\":{\"content\":[[\"Misconception\",\"Why it is wrong\"],[\"“An AI platform is the GPU cluster.”\",\"Compute is one substrate. A platform also needs contracts for identity, model access, data, policy, evaluation, observability and lifecycle.\"],[\"“An AI gateway is just a reverse proxy.”\",\"It may also carry model routing, token quotas, cost attribution, policy enforcement, identity and AI-specific telemetry.\"],[\"“Shared means globally shared.”\",\"A service may be physically shared while logically segmented by tenant, application, region, classification or risk level.\"],[\"“One central vector database becomes the company truth.”\",\"A vector store or retrieval service is infrastructure. Domain authority, freshness, provenance and access remain separate concerns.\"],[\"“Platform evaluation replaces solution evaluation.”\",\"General regression and telemetry cannot define whether a domain-specific answer or action is acceptable.\"],[\"“Provider abstraction should hide every difference.”\",\"Some differences are material capabilities, security semantics or failure modes and must remain visible.\"],[\"“RBAC solves multi-tenancy.”\",\"RBAC controls actions; tenant isolation controls resource boundaries. Both can be required.\"],[\"“AI Platform Architect is just another name for MLOps.”\",\"MLOps\u002FLLMOps is a major overlapping discipline, but shared application\u002Fruntime, identity, gateway, retrieval and tool boundaries can extend beyond model lifecycle operations.\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"h-failure\",\"data\":{\"text\":\"Failure modes an AI Platform Architect should prevent\",\"level\":2},\"type\":\"header\"},{\"id\":\"failures-table\",\"data\":{\"content\":[[\"Failure mode\",\"Architectural consequence\"],[\"Every team stores its own provider keys\",\"Duplicated secret handling, inconsistent rotation and larger blast radius.\"],[\"Provider abstraction hides required capabilities\",\"Consumers cannot use features they need or silently receive behavior different from assumptions.\"],[\"Shared retrieval ignores tenant\u002Fuser context\",\"Cross-boundary data leakage can occur before the application gets a chance to filter results.\"],[\"Fallback silently changes provider or locality\",\"Cost, compliance, data location and output quality can change without the caller knowing.\"],[\"Agent tools are granted by model choice\",\"A capable model becomes over-privileged because runtime authority is not independently enforced.\"],[\"All prompts\u002Fresponses are logged by default\",\"Observability can create a new sensitive-data repository and compliance problem.\"],[\"Platform owns one generic quality score\",\"Domain failures remain hidden behind platform health metrics.\"],[\"No version contract for platform capabilities\",\"Model\u002Fprovider\u002Fruntime changes break consumers unpredictably.\"],[\"Everything AI-related is centralized\",\"The platform becomes a bottleneck and monolith instead of a reusable capability layer.\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"h-decision\",\"data\":{\"text\":\"A practical platform-architecture decision sequence\",\"level\":2},\"type\":\"header\"},{\"id\":\"decision-flow\",\"data\":{\"steps\":[{\"label\":\"1. Identify real consumers\",\"description\":\"List solutions, teams, tenants and workloads that would consume the platform; avoid building a platform for hypothetical reuse.\"},{\"label\":\"2. Define the shared boundary\",\"description\":\"Separate cross-cutting mechanics from solution-specific domain authority, workflow and acceptance.\"},{\"label\":\"3. Define identity and isolation first\",\"description\":\"Establish users, services, applications, tenants, regions and data classifications before sharing retrieval or tool capabilities.\"},{\"label\":\"4. Define capability contracts\",\"description\":\"Specify model\u002Fprovider, retrieval, agent\u002Ftool, gateway and telemetry APIs with explicit ownership and versioning.\"},{\"label\":\"5. Decide provider and runtime strategy\",\"description\":\"Choose managed, self-hosted, local or hybrid execution and document fallback, locality and capability semantics.\"},{\"label\":\"6. Design data and retrieval boundaries\",\"description\":\"Define provenance, authorization propagation, corpus ownership, indexing and evidence responsibilities.\"},{\"label\":\"7. Add quotas, secrets and policy\",\"description\":\"Control cost, capacity, credentials, tool permissions, safety controls and blast radius.\"},{\"label\":\"8. Build evaluation and observability contracts\",\"description\":\"Provide platform metrics and tracing while leaving domain ground truth and acceptance to the solution.\"},{\"label\":\"9. Define lifecycle and operations\",\"description\":\"Version capabilities, test upgrades, document deprecation, rollback, incidents, capacity and consumer onboarding.\"},{\"label\":\"10. Validate with more than one consumer\",\"description\":\"A platform claim becomes credible when the shared capability actually serves distinct workloads without forcing them into the same domain model.\"}],\"title\":\"From platform need to operable shared capability\",\"orientation\":\"auto\"},\"type\":\"processFlow\"},{\"id\":\"h-edge\",\"data\":{\"text\":\"Edge cases and limits of the role\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-edge-1\",\"data\":{\"text\":\"A small organization with one AI application may not need a distinct AI platform or platform architect. Premature platforming can create more abstraction than value. The correct architecture may be one well-designed solution with a few reusable modules.\"},\"type\":\"paragraph\"},{\"id\":\"p-edge-2\",\"data\":{\"text\":\"An air-gapped or sovereign deployment changes the provider, update and observability model substantially. Model hosting, artifact distribution, identity integration and telemetry export may all need local equivalents.\"},\"type\":\"paragraph\"},{\"id\":\"p-edge-3\",\"data\":{\"text\":\"Highly regulated or high-consequence workloads may require stronger physical or organizational isolation instead of a logically shared platform. Reuse is never a sufficient reason to weaken a required security boundary.\"},\"type\":\"paragraph\"},{\"id\":\"p-edge-4\",\"data\":{\"text\":\"Managed cloud AI services can remove implementation burden but do not remove architectural accountability. The organization still decides identity, data access, logging, retention, quotas, model eligibility, fallback, evaluation and solution acceptance.\"},\"type\":\"paragraph\"},{\"id\":\"p-edge-5\",\"data\":{\"text\":\"The platform boundary may also differ by modality. Text inference, multimodal generation, speech, computer use and autonomous agents can have different latency, data, permission and observability requirements even when they share provider and identity infrastructure.\"},\"type\":\"paragraph\"},{\"id\":\"h-change\",\"data\":{\"text\":\"What would change this answer?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-change-1\",\"data\":{\"text\":\"The core definition would change if the organizational scope changes. If the architect owns one workload, the role becomes closer to AI Solution Architect. If the responsibility expands to organization-wide capability strategy, investment, standards and target-state portfolios, it moves toward Enterprise AI Architecture.\"},\"type\":\"paragraph\"},{\"id\":\"p-change-2\",\"data\":{\"text\":\"Implementation guidance changes whenever providers, gateway products, agent protocols, regulatory obligations, model capabilities or deployment constraints change. That is why platform architecture should express stable responsibilities and contracts separately from current vendor mechanisms.\"},\"type\":\"paragraph\"},{\"id\":\"h-checklist\",\"data\":{\"text\":\"AI Platform Architect checklist\",\"level\":2},\"type\":\"header\"},{\"id\":\"checklist-table\",\"data\":{\"content\":[[\"Question\",\"Expected answer\"],[\"Who are the actual platform consumers?\",\"Named solutions, teams or tenant contexts with distinct but overlapping needs.\"],[\"What is genuinely shared?\",\"Explicit capability list, not a vague “AI backend.”\"],[\"What must remain solution-specific?\",\"Domain authority, business workflow, task acceptance and other workload-owned concerns.\"],[\"How are models\u002Fproviders represented?\",\"Versioned provider\u002Fmodel contracts with capabilities and explicit fallback semantics.\"],[\"How is identity propagated?\",\"User\u002Fservice\u002Fapplication\u002Ftenant context survives every privileged request path.\"],[\"How is tenant isolation enforced?\",\"Resource scoping is separate from role permission checks.\"],[\"How are secrets handled?\",\"Privileged storage, rotation, limited exposure and auditable ownership.\"],[\"How does retrieval preserve authority?\",\"Shared mechanics with authorization, provenance and domain-owned evidence rules.\"],[\"How are tools and agents constrained?\",\"Runtime permissions, bounded tool contracts, approvals, cancellation and traceability.\"],[\"How are cost and capacity controlled?\",\"Quotas, token\u002Frate controls, usage attribution and overload behavior.\"],[\"How is quality measured?\",\"Platform regression\u002Fevaluation plus solution-specific ground truth and acceptance.\"],[\"How are changes rolled out?\",\"Versioning, compatibility, migration, deprecation, rollback and incident ownership.\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"h-conclusion\",\"data\":{\"text\":\"Conclusion\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-conclusion-1\",\"data\":{\"text\":\"An AI Platform Architect is responsible for the reusable architecture \u003Cstrong>between AI capabilities and the solutions that consume them\u003C\u002Fstrong>. The role defines how models, providers, retrieval, agents, tools, identity, tenants, secrets, evaluation, observability, quotas and runtime operations become dependable platform services rather than repeated one-off integrations.\"},\"type\":\"paragraph\"},{\"id\":\"p-conclusion-2\",\"data\":{\"text\":\"The difficult part is not maximizing reuse. It is choosing the correct boundary. A strong platform standardizes mechanics, policy and operations where multiple consumers genuinely benefit, while preserving solution-specific data authority, business logic, security requirements and acceptance criteria.\"},\"type\":\"paragraph\"},{\"id\":\"p-conclusion-3\",\"data\":{\"text\":\"That distinction also explains the relationship with AI Solution Architecture: \u003Cstrong>the solution architect makes one AI-enabled system fit its purpose; the platform architect makes shared AI capabilities safe, reusable, operable and evolvable across many such systems.\u003C\u002Fstrong>\"},\"type\":\"paragraph\"},{\"id\":\"h-related\",\"data\":{\"text\":\"Related canonical knowledge\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-related-1\",\"data\":{\"text\":\"This article sits after the canonical foundations on generative AI components, ADR versus NFR, and AI Solution Architecture. Those concepts are prerequisites because a platform exists to provide reusable system capabilities and to encode architectural decisions against explicit quality and operational requirements.\"},\"type\":\"paragraph\"},{\"id\":\"p-related-2\",\"data\":{\"text\":\"Retrieval-Augmented Generation is one example of a capability that may be offered through a platform, but the platform should not collapse retrieval infrastructure, domain knowledge and answer validity into one concept.\"},\"type\":\"paragraph\"},{\"id\":\"related-rag\",\"data\":{\"link\":\"https:\u002F\u002Fstajic.de\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"What Is RAG? The Simplest Explanation of How It Works\",\"description\":\"Canonical introduction to retrieval-augmented generation and the boundary between model generation and external knowledge retrieval.\"}},\"type\":\"linkTool\"},{\"id\":\"p-related-3\",\"data\":{\"text\":\"Agent protocols, tenant isolation, AI governance, model routing, Context Engineering and MLOps\u002FLLMOps are downstream or adjacent knowledge nodes. They become easier to reason about once the platform boundary is explicit.\"},\"type\":\"paragraph\"},{\"id\":\"h-faq\",\"data\":{\"text\":\"Frequently asked questions\",\"level\":2},\"type\":\"header\"},{\"id\":\"faq\",\"data\":{\"items\":[{\"id\":\"faq-1\",\"answer\":\"No. The solution architect focuses on one concrete AI-enabled solution. The platform architect focuses on reusable AI capabilities, controls and operational contracts that can support multiple solutions.\",\"question\":\"Is an AI Platform Architect the same as an AI Solution Architect?\"},{\"id\":\"faq-2\",\"answer\":\"No. A platform can use managed cloud models, self-hosted models, local inference or a hybrid strategy. The architecture must make provider, locality, identity, routing, data and operational consequences explicit.\",\"question\":\"Does an AI platform need to host its own models?\"},{\"id\":\"faq-3\",\"answer\":\"Usually not. A gateway can be an important platform component, but a complete platform also needs contracts for identity, secrets, data\u002Fretrieval, evaluation, observability, lifecycle and operational ownership.\",\"question\":\"Is an AI gateway enough to be an AI platform?\"},{\"id\":\"faq-4\",\"answer\":\"Retrieval mechanics can often be shared, but domain authority, authorization, freshness, evidence sufficiency and corpus ownership should remain explicit. Shared infrastructure does not imply shared truth.\",\"question\":\"Should retrieval be centralized?\"},{\"id\":\"faq-5\",\"answer\":\"No. Platform evaluation can test shared capabilities and regressions. Each solution still needs task-specific ground truth, acceptance criteria and domain quality thresholds.\",\"question\":\"Does platform evaluation replace application evaluation?\"},{\"id\":\"faq-6\",\"answer\":\"No. RBAC determines what an identity may do. Tenant isolation determines which tenant's resources the identity may act on. A platform often needs both.\",\"question\":\"Is multi-tenancy just RBAC?\"}],\"title\":\"AI Platform Architect FAQ\"},\"type\":\"faq\"},{\"id\":\"h-glossary\",\"data\":{\"text\":\"Glossary\",\"level\":2},\"type\":\"header\"},{\"id\":\"glossary\",\"data\":{\"title\":\"Key AI platform architecture terms\",\"entries\":[{\"term\":\"AI platform\",\"anchor\":\"ai-platform\",\"definition\":\"A reusable set of AI-related technical and operational capabilities consumed by multiple applications, teams or tenant contexts.\"},{\"term\":\"AI gateway\",\"anchor\":\"ai-gateway\",\"definition\":\"A gateway layer for AI endpoints that may add authentication, routing, quotas, policy, retries, cost attribution and AI-specific telemetry beyond basic proxying.\"},{\"term\":\"Provider adapter\",\"anchor\":\"provider-adapter\",\"definition\":\"A component that maps a platform contract to a model provider's API, capabilities, health and failure semantics.\"},{\"term\":\"Tenant isolation\",\"anchor\":\"tenant-isolation\",\"definition\":\"The boundary that prevents one tenant context from accessing another tenant's resources, independent of role permissions.\"},{\"term\":\"Capability contract\",\"anchor\":\"capability-contract\",\"definition\":\"A versioned interface and behavioral agreement describing what a shared platform service provides and what the consumer must supply or own.\"},{\"term\":\"Grounding \u002F retrieval service\",\"anchor\":\"grounding-service\",\"definition\":\"Shared mechanics for finding and supplying external information to an AI workload; it does not automatically define which information is authoritative for a domain.\"},{\"term\":\"Evaluation harness\",\"anchor\":\"evaluation-harness\",\"definition\":\"Reusable infrastructure for running tests, datasets, model\u002Fprompt versions and metrics; domain acceptance remains solution-specific.\"},{\"term\":\"Control plane\",\"anchor\":\"control-plane\",\"definition\":\"The configuration and governance layer that manages platform capabilities, identities, policies, quotas, versions and deployment state.\"}]},\"type\":\"glossary\"},{\"id\":\"h-sources\",\"data\":{\"text\":\"Primary sources and current architecture guidance\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-sources-note\",\"data\":{\"text\":\"The sources below support the general architecture and production-platform claims. The Aaasaasa AI Client, Aaasaasa AI CMS and Source of Truth Research Engine sections are explicitly original implementation evidence. Current-state external references were checked on 8 October 2026.\"},\"type\":\"paragraph\"},{\"id\":\"src-iso-42010\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description\",\"description\":\"Current published international standard for architecture-description concepts and relationships.\"}},\"type\":\"linkTool\"},{\"id\":\"src-nist-rmf\",\"data\":{\"link\":\"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"NIST AI Risk Management Framework\",\"description\":\"NIST's AI RMF resources and current status; AI RMF 1.0 is under revision as of October 2026.\"}},\"type\":\"linkTool\"},{\"id\":\"src-nist-gai\",\"data\":{\"link\":\"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fartificial-intelligence-risk-management-framework-generative-artificial-intelligence\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"NIST AI 600-1 — Generative AI Profile\",\"description\":\"Generative AI profile for applying AI risk-management considerations across the AI lifecycle.\"}},\"type\":\"linkTool\"},{\"id\":\"src-ms-ai\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fget-started\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Microsoft Azure Well-Architected — AI Workloads\",\"description\":\"Current architectural guidance covering AI application, data, operations, evaluation, responsible AI and lifecycle concerns.\"}},\"type\":\"linkTool\"},{\"id\":\"src-ms-principles\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fdesign-principles\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Microsoft — Design Principles for AI Workloads\",\"description\":\"Current guidance on identity segmentation, security boundaries, telemetry, performance, data and platform trade-offs.\"}},\"type\":\"linkTool\"},{\"id\":\"src-ms-gateway\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fai-foundry\u002Fconfiguration\u002Fenable-ai-api-management-gateway-portal?view=foundry\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Microsoft Foundry — AI Gateway Architecture\",\"description\":\"Current AI Gateway guidance for shared project access, token containment, quotas and governance.\"}},\"type\":\"linkTool\"},{\"id\":\"src-ms-gateway-guide\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Farchitecture\u002Fai-ml\u002Fguide\u002Fazure-openai-gateway-guide\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Azure Architecture Center — Access Models Through a Gateway\",\"description\":\"Architecture guidance for centralized model access, routing, throttling, failover and client\u002Fplatform responsibilities.\"}},\"type\":\"linkTool\"},{\"id\":\"src-aws-genai\",\"data\":{\"link\":\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fgenerative-ai-lens\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"AWS Well-Architected — Generative AI Lens\",\"description\":\"Current production architecture guidance for generative AI workloads across security, reliability, operations, performance and cost.\"}},\"type\":\"linkTool\"},{\"id\":\"src-aws-multitenant\",\"data\":{\"link\":\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fgenerative-ai-lens\u002Fmulti-tenant-generative-ai-platform-scenario.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"AWS — Multi-tenant Generative AI Platform Scenario\",\"description\":\"Current example separating central platform controls and auditability from consuming-application data quality and workload-specific responsibilities.\"}},\"type\":\"linkTool\"},{\"id\":\"src-aws-agentic\",\"data\":{\"link\":\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fagentic-ai-lens\u002Fdesign-principles.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"AWS Well-Architected — Agentic AI Design Principles\",\"description\":\"Current guidance on bounded agent authority, traceability, versioned behavior, explicit contracts and human oversight.\"}},\"type\":\"linkTool\"},{\"id\":\"src-aws-observability\",\"data\":{\"link\":\"https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonCloudWatch\u002Flatest\u002Fmonitoring\u002FGenAI-observability.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"AWS CloudWatch — Generative AI Observability\",\"description\":\"Current observability capabilities and production metrics for models, agents, knowledge bases, tools and cost\u002Flatency\u002Ferror analysis.\"}},\"type\":\"linkTool\"}],\"version\":\"2.31.0\"}",{"time":1243,"blocks":1244,"version":2023},1791476955677,[1245,1248,1252,1256,1260,1263,1266,1269,1272,1296,1299,1302,1305,1308,1330,1333,1336,1339,1342,1372,1376,1379,1382,1385,1388,1392,1395,1398,1401,1404,1407,1410,1413,1416,1419,1422,1425,1428,1431,1434,1437,1440,1443,1446,1449,1452,1455,1458,1461,1464,1467,1470,1473,1476,1479,1482,1486,1504,1507,1510,1543,1546,1573,1576,1598,1601,1604,1608,1611,1614,1617,1620,1641,1644,1647,1650,1653,1656,1659,1662,1665,1669,1672,1675,1678,1681,1684,1687,1690,1720,1723,1756,1759,1793,1796,1799,1802,1805,1808,1811,1814,1817,1820,1823,1865,1868,1871,1874,1877,1880,1883,1886,1893,1896,1899,1921,1924,1952,1955,1958,1964,1969,1975,1981,1987,1993,1999,2005,2011,2017],{"id":215,"data":1246,"type":218},{"text":1247},"An \u003Cstrong>AI Platform Architect\u003C\u002Fstrong> designs the reusable AI foundation through which multiple applications, teams, or tenant contexts access models, data and retrieval, agent and tool runtimes, identity and permissions, evaluation, observability, quotas, secrets, and deployment capabilities. The role is broader than infrastructure but narrower than owning every AI-enabled product: its central responsibility is deciding \u003Cstrong>what should be shared, how shared capabilities are governed and isolated, and what must remain solution-specific\u003C\u002Fstrong>.",{"id":220,"data":1249,"type":225},{"body":1250,"title":1251,"variant":224},"\u003Cstrong>An AI Platform Architect designs the shared technical and operational substrate for AI systems.\u003C\u002Fstrong> Instead of architecting one assistant or one workflow, the role defines reusable contracts and boundaries for model\u002Fprovider access, gateways and routing, retrieval services, agent runtimes, tool access, identity and tenant isolation, secrets, evaluation, telemetry, deployment and lifecycle management.","Direct answer",{"id":227,"data":1253,"type":225},{"body":1254,"title":1255,"variant":231},"\u003Cstrong>AI Platform Architect is a practical role label, not a universally standardized job title.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 defines concepts for architecture descriptions, not this role. Different organizations may split these responsibilities among platform architects, solution architects, enterprise architects, security architects, MLOps\u002FLLMOps specialists and platform engineering teams. This article uses the term for the architecture responsibility over a reusable AI platform layer.","Terminology note",{"id":233,"data":1257,"type":225},{"body":1258,"title":1259,"variant":231},"The stable architectural principles here are vendor-neutral. Current Microsoft, AWS and NIST guidance is used as external implementation and governance evidence. NIST states that AI RMF 1.0 is being revised; vendor platform features, gateway products, agent runtimes and model capabilities evolve faster than the architectural principles, so version-sensitive implementation choices must be rechecked before deployment.","Current-source note — 8 October 2026",{"id":238,"data":1261,"type":243},{"title":1262,"maxLevel":241,"minLevel":242},"Contents",{"id":245,"data":1264,"type":42},{"text":1265,"level":242},"What does an AI Platform Architect actually architect?",{"id":249,"data":1267,"type":218},{"text":1268},"The object of the work is the \u003Cstrong>platform\u003C\u002Fstrong>: a set of shared capabilities that reduces repeated integration work while preserving explicit security, data and operational boundaries. A platform can expose model access, provider adapters, retrieval primitives, agent execution, tool brokers, policy enforcement, evaluation, telemetry and deployment services to many consuming solutions.",{"id":253,"data":1270,"type":218},{"text":1271},"The platform is not valuable merely because components are centralized. It is valuable when consumers receive stable capabilities with clear contracts, ownership, isolation, observability and lifecycle rules. The key architectural question is therefore not “Which model should everyone use?” but \u003Cstrong>“Which responsibilities can be safely standardized and reused without erasing the requirements of each solution?”\u003C\u002Fstrong>.",{"id":257,"data":1273,"type":299},{"rows":1274,"title":1290,"layout":291,"columns":1291},[1275,1278,1281,1284,1287],{"id":261,"label":1276,"values":1277},"Primary scope",{"platform":264,"solution":265},{"id":267,"label":1279,"values":1280},"Main question",{"platform":270,"solution":271},{"id":273,"label":1282,"values":1283},"Data authority",{"platform":276,"solution":277},{"id":279,"label":1285,"values":1286},"Evaluation",{"platform":282,"solution":283},{"id":285,"label":1288,"values":1289},"Lifecycle",{"platform":288,"solution":289},"Solution architecture and platform architecture solve different scope problems",[1292,1294],{"id":294,"label":1293},"AI Solution Architect",{"id":297,"label":1295},"AI Platform Architect",{"id":301,"data":1297,"type":42},{"text":1298,"level":242},"The simplest example",{"id":305,"data":1300,"type":218},{"text":1301},"Imagine an organization has five AI-enabled products: an internal document assistant, a customer-support copilot, a software-engineering agent, a contract review workflow and a product-search assistant. Each product could independently integrate model APIs, keep credentials, implement retries, collect token metrics, create retrieval code and build its own tool permissions.",{"id":309,"data":1303,"type":218},{"text":1304},"That duplication is expensive and dangerous when every team invents a different security and operational model. A shared platform can instead offer approved provider connections, model discovery, quotas, credentials, tenant-aware access, common telemetry, reusable retrieval services and an agent\u002Ftool runtime contract.",{"id":313,"data":1306,"type":218},{"text":1307},"But the platform must stop at the correct boundary. The contract-review solution may require legal-document authority and citation rules that the software agent does not. The product-search assistant may need commerce-specific freshness and authorization rules. \u003Cstrong>Reusable infrastructure does not make all domain truth reusable.\u003C\u002Fstrong>",{"id":317,"data":1309,"type":340},{"steps":1310,"title":1329,"orientation":339},[1311,1314,1317,1320,1323,1326],{"label":1312,"description":1313},"1. Consumer identifies itself","The calling application, user, service, team or tenant enters through an authenticated identity and explicit scope.",{"label":1315,"description":1316},"2. Platform policy applies","Gateway and policy layers determine allowed providers, models, quotas, data paths, tools and execution modes.",{"label":1318,"description":1319},"3. Shared capability executes","The request may use inference, retrieval, agent runtime, tool access or another reusable platform service.",{"label":1321,"description":1322},"4. Solution-specific context remains authoritative","The consuming solution supplies domain rules, user intent, data authority, task-specific constraints and acceptance logic.",{"label":1324,"description":1325},"5. Telemetry and evidence are captured","The platform records identity, route, model\u002Fprovider, latency, cost, errors, tool activity and other permitted observability signals.",{"label":1327,"description":1328},"6. Result returns under the solution contract","The solution remains responsible for whether the output is acceptable for its user and domain.","A shared AI request path",{"id":342,"data":1331,"type":42},{"text":1332,"level":242},"Where the simple example stops",{"id":346,"data":1334,"type":218},{"text":1335},"Centralization is not automatically architecture. A single endpoint in front of several model APIs is useful, but it does not by itself create an AI platform. A production platform also needs identity boundaries, capability contracts, provider health and lifecycle handling, quotas, secret ownership, observability, compatibility rules, security controls, release discipline and clear operational responsibility.",{"id":350,"data":1337,"type":218},{"text":1338},"The opposite failure is also common: putting every prompt, vector index, business rule, agent and application workflow into one “AI backend.” That creates a monolith whose shared status is accidental rather than architectural. \u003Cstrong>A platform should standardize cross-cutting capabilities, not absorb domain ownership merely because AI is involved.\u003C\u002Fstrong>",{"id":354,"data":1340,"type":42},{"text":1341,"level":242},"The most important platform decision: shared versus solution-specific",{"id":358,"data":1343,"type":291},{"content":1344,"stretched":43,"withHeadings":14},[1345,1349,1353,1357,1361,1365,1368],[1346,1347,1348],"Capability area","Good candidate for shared platform ownership","Usually remains solution-specific",[1350,1351,1352],"Model access","Approved provider connections, adapters, credentials, health, routing primitives, quotas","Task-specific model acceptance, prompt behavior, quality threshold",[1354,1355,1356],"Retrieval","Ingestion primitives, extraction, indexing, search APIs, provenance contracts, authorization hooks","Authoritative corpus, freshness rules, domain metadata, evidence sufficiency",[1358,1359,1360],"Agents and tools","Runtime lifecycle, tool registry\u002Fbroker, permission enforcement, tracing, cancellation","Business workflow, allowed action semantics, escalation policy, task success",[1362,1363,1364],"Security","Identity integration, secret storage, policy enforcement, audit contracts, tenant isolation mechanisms","Data classification, business authorization rules, domain-specific risk acceptance",[1285,1366,1367],"Harness, dataset\u002Fversion mechanics, telemetry, experiment\u002Frelease workflow","Ground truth, domain test set, acceptance threshold, user outcome",[1369,1370,1371],"Operations","Deployment pattern, health, metrics, incident integration, capacity controls","Solution SLOs where they differ, business continuity impact, workload-specific runbooks",{"id":389,"data":1373,"type":225},{"body":1374,"title":1375,"variant":393},"\u003Cstrong>Share mechanics and controls where reuse is real; keep authority and acceptance where the domain owns them.\u003C\u002Fstrong> This prevents two opposite errors: duplicated infrastructure everywhere, and a central platform that falsely becomes the owner of every application's data, policy and quality.","Platform principle",{"id":395,"data":1377,"type":42},{"text":1378,"level":242},"Architecture responsibility map",{"id":399,"data":1380,"type":42},{"text":1381,"level":241},"1. Model and provider access",{"id":403,"data":1383,"type":218},{"text":1384},"A platform architect defines how consumers discover and invoke models without forcing every application to hard-code one provider. This includes provider adapters, model identifiers, capability metadata, authentication, health checks, endpoint configuration, request normalization and compatibility behavior.",{"id":407,"data":1386,"type":218},{"text":1387},"Provider abstraction must remain honest. Different providers expose different context limits, tool semantics, structured-output behavior, multimodal capabilities, safety controls, caching, pricing and failure modes. A good abstraction creates a stable platform contract while preserving access to capabilities that cannot be meaningfully flattened.",{"id":411,"data":1389,"type":225},{"body":1390,"title":1391,"variant":415},"A lowest-common-denominator API can make migration easier but can also erase capabilities that matter. The architecture should define which features are portable, which are provider-specific and how consumers discover that difference.","Do not confuse abstraction with pretending providers are identical",{"id":417,"data":1393,"type":42},{"text":1394,"level":241},"2. Gateway, routing, quotas and cost controls",{"id":421,"data":1396,"type":218},{"text":1397},"A shared AI gateway can centralize authentication, routing, throttling, retries, token limits, usage attribution and policy enforcement. Microsoft’s current AI Gateway guidance explicitly treats token-per-minute limits, quotas and multi-project containment as platform concerns; AWS likewise exposes account and model quotas and centralized controls.",{"id":425,"data":1399,"type":218},{"text":1400},"The gateway is therefore more than a reverse proxy when it carries AI-specific policy and operational semantics. But it should not silently make business decisions. A routing policy may prefer a healthy local model, a lower-cost provider or a regionally compliant endpoint; whether that route is acceptable for a particular task is still a contract between platform and solution.",{"id":429,"data":1402,"type":218},{"text":1403},"Routing also needs failure semantics. If the preferred model is unavailable, the platform must know whether fallback is permitted, whether a cloud route requires explicit consent, whether a lower-capability model is valid and how the decision is surfaced to observability.",{"id":433,"data":1405,"type":42},{"text":1406,"level":241},"3. Shared data, retrieval and grounding services",{"id":437,"data":1408,"type":218},{"text":1409},"Retrieval services are strong platform candidates because parsing, chunking, indexing, lexical search, semantic search, metadata filtering, provenance and citation mechanics are reusable. However, the platform must not confuse a shared retrieval engine with a shared source of truth.",{"id":441,"data":1411,"type":218},{"text":1412},"A solution still owns questions such as: Which corpus is authoritative? Which version is valid? Can this user see this document? How fresh must the data be? What counts as sufficient evidence? Can an answer be generated when retrieval fails? Those are domain and solution requirements even when the platform supplies the retrieval machinery.",{"id":445,"data":1414,"type":218},{"text":1415},"This boundary is especially important in multi-tenant systems. A technically shared index or vector service does not justify cross-tenant visibility. Authorization context must be preserved through retrieval, not added only after search results have already crossed the boundary.",{"id":449,"data":1417,"type":42},{"text":1418,"level":241},"4. Agent and tool runtime",{"id":453,"data":1420,"type":218},{"text":1421},"Agentic systems add reusable runtime concerns: thread\u002Fsession lifecycle, planning loops, tool registration, tool invocation, cancellation, timeouts, human approvals, memory\u002Fstate interfaces, remote-agent protocols and trace correlation. A platform can provide these mechanics so each product does not rebuild them.",{"id":457,"data":1423,"type":218},{"text":1424},"The platform must also keep tool permission separate from model capability. A model being capable of generating a shell command does not mean the runtime should allow shell execution. The permission boundary belongs to the application\u002Fruntime architecture and must be enforceable independently of the model.",{"id":461,"data":1426,"type":218},{"text":1427},"Current AWS Agentic AI guidance emphasizes bounded agents, explicit authority, end-to-end tracing, versioned behavioral artifacts and human oversight proportionate to consequence. Those are platform-enabling concerns, but the consuming solution still defines what actions are legitimate for its domain.",{"id":465,"data":1429,"type":42},{"text":1430,"level":241},"5. Identity, tenant isolation and authorization",{"id":469,"data":1432,"type":218},{"text":1433},"AI platforms often sit in front of high-value models, proprietary data and action-capable tools. Authentication is therefore only the beginning. The architecture must carry user, service, application and tenant context through every privileged operation that needs it.",{"id":473,"data":1435,"type":218},{"text":1436},"\u003Cstrong>RBAC and tenant isolation solve different problems.\u003C\u002Fstrong> RBAC answers what an identity may do; tenant isolation answers which tenant’s resources that identity may act on. A platform that checks roles but loses tenant context can still expose the wrong data.",{"id":477,"data":1438,"type":218},{"text":1439},"Microsoft’s current AI workload guidance explicitly recommends identity segmentation and authorization-aware access to content. AWS’s multi-tenant generative AI platform guidance similarly treats logical isolation, centralized controls and auditability as platform concerns.",{"id":481,"data":1441,"type":42},{"text":1442,"level":241},"6. Secrets, credentials and trust boundaries",{"id":485,"data":1444,"type":218},{"text":1445},"A platform should define who owns provider keys, remote bearer tokens, signing material and tool credentials, where they are stored, which process can access them, how they are rotated and whether they can ever reach a browser or untrusted renderer.",{"id":489,"data":1447,"type":218},{"text":1448},"This is an architectural boundary, not an implementation detail. If every consuming application copies provider credentials into its own configuration, the organization has duplicated both operational burden and blast radius. Centralization can reduce that risk only if the platform itself has narrower, auditable access paths.",{"id":493,"data":1450,"type":42},{"text":1451,"level":241},"7. Evaluation, observability and auditability",{"id":497,"data":1453,"type":218},{"text":1454},"A reusable platform can provide evaluation harnesses, trace IDs, model\u002Fprovider metadata, token and cost metrics, latency, error rates, prompt\u002Fmodel version linkage, agent\u002Ftool traces and controlled logging. AWS and Microsoft both treat observability and evaluation as core production concerns for AI workloads.",{"id":501,"data":1456,"type":218},{"text":1457},"Platform evaluation and solution evaluation must remain separate. A platform can verify that an endpoint is healthy, a model version passes a general regression suite and traces are complete. It cannot decide that a legal answer, medical workflow or product recommendation is acceptable without domain-specific ground truth and acceptance criteria.",{"id":505,"data":1459,"type":218},{"text":1460},"Logging also creates a privacy boundary. Prompt and response logs may contain sensitive or proprietary data. The platform architect must therefore decide what is logged, redacted, sampled, retained and accessible rather than assuming that more telemetry is always safer.",{"id":509,"data":1462,"type":42},{"text":1463,"level":241},"8. Runtime, deployment and locality",{"id":513,"data":1465,"type":218},{"text":1466},"A platform architect decides how shared AI capabilities are deployed and reached: managed cloud services, self-hosted endpoints, local inference, hybrid routing, containerized services, desktop runtimes, private networking or air-gapped environments. The important distinction is between \u003Cstrong>where the control\u002Fruntime process runs\u003C\u002Fstrong> and \u003Cstrong>where inference and data processing actually occur\u003C\u002Fstrong>.",{"id":517,"data":1468,"type":218},{"text":1469},"A local client may still call a cloud model. A cloud control plane may route to an on-premises model. A remote agent may execute tools inside a customer network. Architectural diagrams must therefore show trust and data-flow boundaries rather than using “local” and “cloud” as vague labels.",{"id":521,"data":1471,"type":42},{"text":1472,"level":241},"9. Platform lifecycle, compatibility and onboarding",{"id":525,"data":1474,"type":218},{"text":1475},"Reusable capability becomes a platform only when consumers can depend on it over time. That requires versioned contracts, migration rules, compatibility policy, deprecation, release testing, rollback, incident ownership, capacity planning, documentation and a path for onboarding new teams or applications.",{"id":529,"data":1477,"type":218},{"text":1478},"Fast-moving AI ecosystems make this particularly important. Model names, SDKs, protocol versions, provider APIs and safety capabilities change independently. A platform must absorb some of that volatility without hiding changes that materially affect a solution’s behavior.",{"id":533,"data":1480,"type":42},{"text":1481,"level":242},"A practical control-plane \u002F execution-plane \u002F solution-plane model",{"id":537,"data":1483,"type":225},{"body":1484,"title":1485,"variant":231},"The three-plane model below is a practical way to reason about responsibilities; it is not an ISO, NIST, Microsoft or AWS standard. Its purpose is to make ownership boundaries explicit.","Proposed architecture model",{"id":542,"data":1487,"type":291},{"content":1488,"stretched":43,"withHeadings":14},[1489,1493,1497,1501],[1490,1491,1492],"Plane","Typical responsibilities","Should not silently own",[1494,1495,1496],"Platform control plane","Provider registry, model policy, quotas, tenant configuration, identities, secrets, routing rules, capability versions, deployment configuration","Application business logic or domain truth",[1498,1499,1500],"Platform execution\u002Fdata plane","Inference requests, retrieval operations, agent\u002Ftool execution, extraction, indexing, telemetry emission, policy enforcement","Cross-tenant access merely because infrastructure is shared",[558,1502,1503],"User workflow, prompts\u002Finstructions, authoritative corpus selection, domain authorization, business rules, task evaluation and acceptance","Low-level provider integration that the platform explicitly owns",{"id":562,"data":1505,"type":218},{"text":1506},"This separation helps diagnose platform drift. If an application must know every provider-specific credential and endpoint, the platform contract is too thin. If the platform decides which customer record is legally authoritative or whether a domain answer is acceptable, the platform has crossed into solution ownership.",{"id":566,"data":1508,"type":42},{"text":1509,"level":242},"What should an AI Platform Architect produce?",{"id":570,"data":1511,"type":291},{"content":1512,"stretched":43,"withHeadings":14},[1513,1516,1519,1522,1525,1528,1531,1534,1537,1540],[1514,1515],"Architecture artifact","Purpose",[1517,1518],"Platform capability map","Defines what the platform provides, who consumes it and which capabilities remain outside scope.",[1520,1521],"Provider\u002Fmodel contract","Defines providers, models, capabilities, abstraction boundaries, route metadata and fallback semantics.",[1523,1524],"Identity and tenancy model","Defines user\u002Fservice\u002Fapplication identity, tenant context, RBAC\u002FABAC hooks and resource isolation.",[1526,1527],"Gateway and quota policy","Defines rate limits, token\u002Fcost budgets, routing controls, retries and capacity behavior.",[1529,1530],"Retrieval\u002Fdata contract","Defines ingestion, provenance, search, metadata, authorization propagation and where domain authority remains.",[1532,1533],"Agent\u002Ftool contract","Defines runtime lifecycle, tool registration, permissions, approvals, cancellation and trace behavior.",[1535,1536],"Secret and trust-boundary model","Defines credential ownership, storage, process boundaries, rotation and sensitive data paths.",[1538,1539],"Evaluation and telemetry contract","Defines common metrics, traces, datasets\u002Fversion links, logging policy and solution extension points.",[1541,1542],"Lifecycle and compatibility policy","Defines versions, migrations, deprecation, releases, rollback, incident ownership and onboarding.",{"id":604,"data":1544,"type":42},{"text":1545,"level":242},"The work is mostly trade-offs, not maximum centralization",{"id":608,"data":1547,"type":299},{"rows":1548,"title":1567,"layout":291,"columns":1568},[1549,1552,1555,1558,1561,1564],{"id":612,"label":1550,"values":1551},"Provider abstraction",{"pressureA":615,"pressureB":616},{"id":618,"label":1553,"values":1554},"Reuse",{"pressureA":621,"pressureB":622},{"id":624,"label":1556,"values":1557},"Governance",{"pressureA":627,"pressureB":628},{"id":630,"label":1559,"values":1560},"Observability",{"pressureA":633,"pressureB":634},{"id":636,"label":1562,"values":1563},"Availability",{"pressureA":639,"pressureB":640},{"id":642,"label":1565,"values":1566},"Platform scope",{"pressureA":645,"pressureB":646},"Common platform trade-offs",[1569,1571],{"id":650,"label":1570},"Pressure A",{"id":653,"label":1572},"Pressure B",{"id":656,"data":1574,"type":42},{"text":1575,"level":242},"How is this different from adjacent roles?",{"id":660,"data":1577,"type":291},{"content":1578,"stretched":43,"withHeadings":14},[1579,1582,1584,1586,1589,1592,1595],[1580,1581],"Role","Primary architectural scope",[1293,1583],"A concrete AI-enabled solution and its end-to-end requirements, boundaries, trade-offs and production acceptance.",[1295,1585],"Reusable AI capabilities and operational\u002Fsecurity contracts consumed across multiple solutions or teams.",[1587,1588],"Enterprise Architect","Organization-wide business\u002Ftechnology portfolio, capability and governance alignment at a broader level.",[1590,1591],"MLOps \u002F LLMOps Architect or specialist","Model and AI lifecycle, deployment, experiments, observability, release and operational practices; may overlap strongly but does not automatically own the whole shared application platform.",[1593,1594],"Platform Engineer \u002F SRE","Implements and operates platform infrastructure, reliability, automation and developer experience; architecture responsibility may be shared with the platform architect.",[1596,1597],"AI \u002F Software Engineer","Implements models, integrations, services, agents, retrieval and product functionality inside the agreed architecture.",{"id":684,"data":1599,"type":218},{"text":1600},"These boundaries are organizational, not universal. In a small team one person may hold several responsibilities. In a regulated enterprise they may be split across architecture, security, platform, data and operations groups. The useful distinction is the \u003Cstrong>scope of architectural responsibility\u003C\u002Fstrong>, not the job title printed on an org chart.",{"id":688,"data":1602,"type":42},{"text":1603,"level":242},"Implementation evidence: how these platform boundaries appear in my own work",{"id":692,"data":1605,"type":225},{"body":1606,"title":1607,"variant":231},"The following sections describe concrete patterns from my own projects. They are evidence that these architectural boundaries have been implemented or explicitly designed in real code and project systems. They are \u003Cstrong>not\u003C\u002Fstrong> claims that the projects together already constitute a commercially deployed enterprise AI platform.","Original implementation evidence",{"id":697,"data":1609,"type":42},{"text":1610,"level":241},"Aaasaasa AI Client: provider, runtime and permission separation",{"id":701,"data":1612,"type":218},{"text":1613},"Aaasaasa AI Client is a local-first desktop AI workspace built with Nuxt 4, Electron and TypeScript. Its AI Hub deliberately separates \u003Cstrong>agent\u002Fclient, provider, model, connection\u002Fruntime location, permissions and web client\u003C\u002Fstrong> instead of treating them as one configuration value.",{"id":705,"data":1615,"type":218},{"text":1616},"The implementation includes direct provider adapters, Codex agent runtime integration, local Ollama\u002FLM Studio paths, OpenAI-compatible services, centralized workspace permissions, main-process credential storage, DuckDB, Qdrant\u002Fvector support, PDF\u002Freadability extraction and authenticated MCP-based directory access.",{"id":709,"data":1618,"type":218},{"text":1619},"Two platform lessons are especially relevant. First, a local runtime is not the same as local inference: a local Codex process can still use a cloud model. Second, automatic routing does not silently fall back from local to paid cloud inference. That makes routing policy and runtime locality explicit rather than inferred from UI labels.",{"id":713,"data":1621,"type":291},{"content":1622,"stretched":43,"withHeadings":14},[1623,1626,1629,1632,1635,1638],[1624,1625],"Implemented boundary","Platform-architecture meaning",[1627,1628],"Agent vs provider vs model","Different responsibilities can evolve independently instead of being hidden behind one “AI” selector.",[1630,1631],"Permissions separate from model","Filesystem\u002Ftool authority belongs to the runtime policy, not model capability.",[1633,1634],"Main-process secrets","Credential ownership follows the privileged process boundary rather than the renderer\u002FUI.",[1636,1637],"Provider health and model discovery","Routing and availability are runtime\u002Fplatform concerns.",[1639,1640],"No silent cloud fallback","Cost, locality and data-transfer semantics remain explicit policy decisions.",{"id":735,"data":1642,"type":42},{"text":1643,"level":241},"Aaasaasa AI CMS: tenant-scoped authorization as a platform boundary",{"id":739,"data":1645,"type":218},{"text":1646},"The Aaasaasa AI CMS codebase provides a separate implementation example: tenant-scoped RBAC is represented through roles, permissions and user-role assignments bound to a tenant identifier. System permissions are grouped by capability, and role lookup and updates remain tenant-scoped.",{"id":743,"data":1648,"type":218},{"text":1649},"This is not itself proof of a complete AI platform, but it is directly relevant to one of the hardest shared-platform boundaries: a reusable service must preserve \u003Cstrong>who may do what\u003C\u002Fstrong> and \u003Cstrong>for which tenant\u003C\u002Fstrong>. Adding AI inference or retrieval on top of an application platform does not remove that requirement.",{"id":747,"data":1651,"type":218},{"text":1652},"The architectural implication is that model gateways, retrieval services and agents should consume established identity\u002Ftenant context rather than inventing a parallel AI-only authorization universe.",{"id":751,"data":1654,"type":42},{"text":1655,"level":241},"Source of Truth Research Engine: shared retrieval mechanics without shared truth",{"id":755,"data":1657,"type":218},{"text":1658},"The Source of Truth Research Engine provides a third implementation example. Different research modes share a common evidence core: Sources, Artifacts, provenance, Claims, Relations, Contradictions, a Reference Model and audit trail. The system also provides local lexical retrieval, optional semantic retrieval, extraction, snapshots and SHA-256-based provenance.",{"id":759,"data":1660,"type":218},{"text":1661},"The project explicitly treats search and semantic similarity as discovery signals rather than evidence. A result must be traced back to a concrete source and locator before it can support a claim. This is precisely the distinction an AI platform needs: \u003Cstrong>reusable retrieval machinery can be shared while evidence authority remains governed by the consuming methodology and domain.\u003C\u002Fstrong>",{"id":763,"data":1663,"type":218},{"text":1664},"The engine also demonstrates why one shared platform does not require one shared interpretation. Historical, scientific\u002Ftechnical, market-intelligence and monitoring modes can reuse core evidence infrastructure while retaining mode-specific methodology.",{"id":767,"data":1666,"type":225},{"body":1667,"title":1668,"variant":393},"Across these projects, the reusable pattern is not “one backend for everything.” It is \u003Cstrong>separation of concerns plus explicit contracts\u003C\u002Fstrong>: provider\u002Fmodel\u002Fruntime separation, tenant-aware authorization, credential boundaries, reusable data\u002Fretrieval primitives, provenance, and domain-specific authority. A future integrated platform would need stable contracts between those capabilities rather than direct coupling between codebases.","What these implementations demonstrate together",{"id":772,"data":1670,"type":42},{"text":1671,"level":242},"How current architecture guidance supports this platform scope",{"id":776,"data":1673,"type":218},{"text":1674},"ISO\u002FIEC\u002FIEEE 42010:2022 provides a general discipline for architecture descriptions across software, systems, enterprises and related entities. It does not define an AI Platform Architect, but it reinforces the need to express architectural concerns, relationships and viewpoints rather than reducing architecture to a technology list.",{"id":780,"data":1676,"type":218},{"text":1677},"NIST AI RMF 1.0 and the Generative AI Profile frame AI risk management across the lifecycle rather than only at model selection time. Governance, mapping, measurement and management are therefore compatible with a platform architecture that carries shared controls and evidence across many consuming workloads.",{"id":784,"data":1679,"type":218},{"text":1680},"Microsoft’s current AI workload guidance treats application design, data, security, operations, testing\u002Fevaluation and GenAIOps as connected architectural areas. Its current AI Gateway guidance also shows practical platform concerns such as centralized model access, project-specific token limits, quotas and multi-team containment.",{"id":788,"data":1682,"type":218},{"text":1683},"AWS’s current Generative AI Lens and multi-tenant platform scenario similarly separate foundational platform controls from consuming-application ownership. AWS explicitly notes that a central platform can enforce shared guardrails and auditability while data quality and workload-specific observability still remain responsibilities of consuming applications or data producers.",{"id":792,"data":1685,"type":218},{"text":1686},"The vendor products differ, but the cross-source pattern is stable: production AI platforms must coordinate identity, data access, models, policy, evaluation, observability, capacity, cost and lifecycle. A GPU cluster or model endpoint covers only part of that responsibility.",{"id":796,"data":1688,"type":42},{"text":1689,"level":242},"Common misconceptions",{"id":800,"data":1691,"type":291},{"content":1692,"stretched":43,"withHeadings":14},[1693,1696,1699,1702,1705,1708,1711,1714,1717],[1694,1695],"Misconception","Why it is wrong",[1697,1698],"“An AI platform is the GPU cluster.”","Compute is one substrate. A platform also needs contracts for identity, model access, data, policy, evaluation, observability and lifecycle.",[1700,1701],"“An AI gateway is just a reverse proxy.”","It may also carry model routing, token quotas, cost attribution, policy enforcement, identity and AI-specific telemetry.",[1703,1704],"“Shared means globally shared.”","A service may be physically shared while logically segmented by tenant, application, region, classification or risk level.",[1706,1707],"“One central vector database becomes the company truth.”","A vector store or retrieval service is infrastructure. Domain authority, freshness, provenance and access remain separate concerns.",[1709,1710],"“Platform evaluation replaces solution evaluation.”","General regression and telemetry cannot define whether a domain-specific answer or action is acceptable.",[1712,1713],"“Provider abstraction should hide every difference.”","Some differences are material capabilities, security semantics or failure modes and must remain visible.",[1715,1716],"“RBAC solves multi-tenancy.”","RBAC controls actions; tenant isolation controls resource boundaries. Both can be required.",[1718,1719],"“AI Platform Architect is just another name for MLOps.”","MLOps\u002FLLMOps is a major overlapping discipline, but shared application\u002Fruntime, identity, gateway, retrieval and tool boundaries can extend beyond model lifecycle operations.",{"id":831,"data":1721,"type":42},{"text":1722,"level":242},"Failure modes an AI Platform Architect should prevent",{"id":835,"data":1724,"type":291},{"content":1725,"stretched":43,"withHeadings":14},[1726,1729,1732,1735,1738,1741,1744,1747,1750,1753],[1727,1728],"Failure mode","Architectural consequence",[1730,1731],"Every team stores its own provider keys","Duplicated secret handling, inconsistent rotation and larger blast radius.",[1733,1734],"Provider abstraction hides required capabilities","Consumers cannot use features they need or silently receive behavior different from assumptions.",[1736,1737],"Shared retrieval ignores tenant\u002Fuser context","Cross-boundary data leakage can occur before the application gets a chance to filter results.",[1739,1740],"Fallback silently changes provider or locality","Cost, compliance, data location and output quality can change without the caller knowing.",[1742,1743],"Agent tools are granted by model choice","A capable model becomes over-privileged because runtime authority is not independently enforced.",[1745,1746],"All prompts\u002Fresponses are logged by default","Observability can create a new sensitive-data repository and compliance problem.",[1748,1749],"Platform owns one generic quality score","Domain failures remain hidden behind platform health metrics.",[1751,1752],"No version contract for platform capabilities","Model\u002Fprovider\u002Fruntime changes break consumers unpredictably.",[1754,1755],"Everything AI-related is centralized","The platform becomes a bottleneck and monolith instead of a reusable capability layer.",{"id":869,"data":1757,"type":42},{"text":1758,"level":242},"A practical platform-architecture decision sequence",{"id":873,"data":1760,"type":340},{"steps":1761,"title":1792,"orientation":339},[1762,1765,1768,1771,1774,1777,1780,1783,1786,1789],{"label":1763,"description":1764},"1. Identify real consumers","List solutions, teams, tenants and workloads that would consume the platform; avoid building a platform for hypothetical reuse.",{"label":1766,"description":1767},"2. Define the shared boundary","Separate cross-cutting mechanics from solution-specific domain authority, workflow and acceptance.",{"label":1769,"description":1770},"3. Define identity and isolation first","Establish users, services, applications, tenants, regions and data classifications before sharing retrieval or tool capabilities.",{"label":1772,"description":1773},"4. Define capability contracts","Specify model\u002Fprovider, retrieval, agent\u002Ftool, gateway and telemetry APIs with explicit ownership and versioning.",{"label":1775,"description":1776},"5. Decide provider and runtime strategy","Choose managed, self-hosted, local or hybrid execution and document fallback, locality and capability semantics.",{"label":1778,"description":1779},"6. Design data and retrieval boundaries","Define provenance, authorization propagation, corpus ownership, indexing and evidence responsibilities.",{"label":1781,"description":1782},"7. Add quotas, secrets and policy","Control cost, capacity, credentials, tool permissions, safety controls and blast radius.",{"label":1784,"description":1785},"8. Build evaluation and observability contracts","Provide platform metrics and tracing while leaving domain ground truth and acceptance to the solution.",{"label":1787,"description":1788},"9. Define lifecycle and operations","Version capabilities, test upgrades, document deprecation, rollback, incidents, capacity and consumer onboarding.",{"label":1790,"description":1791},"10. Validate with more than one consumer","A platform claim becomes credible when the shared capability actually serves distinct workloads without forcing them into the same domain model.","From platform need to operable shared capability",{"id":908,"data":1794,"type":42},{"text":1795,"level":242},"Edge cases and limits of the role",{"id":912,"data":1797,"type":218},{"text":1798},"A small organization with one AI application may not need a distinct AI platform or platform architect. Premature platforming can create more abstraction than value. The correct architecture may be one well-designed solution with a few reusable modules.",{"id":916,"data":1800,"type":218},{"text":1801},"An air-gapped or sovereign deployment changes the provider, update and observability model substantially. Model hosting, artifact distribution, identity integration and telemetry export may all need local equivalents.",{"id":920,"data":1803,"type":218},{"text":1804},"Highly regulated or high-consequence workloads may require stronger physical or organizational isolation instead of a logically shared platform. Reuse is never a sufficient reason to weaken a required security boundary.",{"id":924,"data":1806,"type":218},{"text":1807},"Managed cloud AI services can remove implementation burden but do not remove architectural accountability. The organization still decides identity, data access, logging, retention, quotas, model eligibility, fallback, evaluation and solution acceptance.",{"id":928,"data":1809,"type":218},{"text":1810},"The platform boundary may also differ by modality. Text inference, multimodal generation, speech, computer use and autonomous agents can have different latency, data, permission and observability requirements even when they share provider and identity infrastructure.",{"id":932,"data":1812,"type":42},{"text":1813,"level":242},"What would change this answer?",{"id":936,"data":1815,"type":218},{"text":1816},"The core definition would change if the organizational scope changes. If the architect owns one workload, the role becomes closer to AI Solution Architect. If the responsibility expands to organization-wide capability strategy, investment, standards and target-state portfolios, it moves toward Enterprise AI Architecture.",{"id":940,"data":1818,"type":218},{"text":1819},"Implementation guidance changes whenever providers, gateway products, agent protocols, regulatory obligations, model capabilities or deployment constraints change. That is why platform architecture should express stable responsibilities and contracts separately from current vendor mechanisms.",{"id":944,"data":1821,"type":42},{"text":1822,"level":242},"AI Platform Architect checklist",{"id":948,"data":1824,"type":291},{"content":1825,"stretched":43,"withHeadings":14},[1826,1829,1832,1835,1838,1841,1844,1847,1850,1853,1856,1859,1862],[1827,1828],"Question","Expected answer",[1830,1831],"Who are the actual platform consumers?","Named solutions, teams or tenant contexts with distinct but overlapping needs.",[1833,1834],"What is genuinely shared?","Explicit capability list, not a vague “AI backend.”",[1836,1837],"What must remain solution-specific?","Domain authority, business workflow, task acceptance and other workload-owned concerns.",[1839,1840],"How are models\u002Fproviders represented?","Versioned provider\u002Fmodel contracts with capabilities and explicit fallback semantics.",[1842,1843],"How is identity propagated?","User\u002Fservice\u002Fapplication\u002Ftenant context survives every privileged request path.",[1845,1846],"How is tenant isolation enforced?","Resource scoping is separate from role permission checks.",[1848,1849],"How are secrets handled?","Privileged storage, rotation, limited exposure and auditable ownership.",[1851,1852],"How does retrieval preserve authority?","Shared mechanics with authorization, provenance and domain-owned evidence rules.",[1854,1855],"How are tools and agents constrained?","Runtime permissions, bounded tool contracts, approvals, cancellation and traceability.",[1857,1858],"How are cost and capacity controlled?","Quotas, token\u002Frate controls, usage attribution and overload behavior.",[1860,1861],"How is quality measured?","Platform regression\u002Fevaluation plus solution-specific ground truth and acceptance.",[1863,1864],"How are changes rolled out?","Versioning, compatibility, migration, deprecation, rollback and incident ownership.",{"id":991,"data":1866,"type":42},{"text":1867,"level":242},"Conclusion",{"id":995,"data":1869,"type":218},{"text":1870},"An AI Platform Architect is responsible for the reusable architecture \u003Cstrong>between AI capabilities and the solutions that consume them\u003C\u002Fstrong>. The role defines how models, providers, retrieval, agents, tools, identity, tenants, secrets, evaluation, observability, quotas and runtime operations become dependable platform services rather than repeated one-off integrations.",{"id":999,"data":1872,"type":218},{"text":1873},"The difficult part is not maximizing reuse. It is choosing the correct boundary. A strong platform standardizes mechanics, policy and operations where multiple consumers genuinely benefit, while preserving solution-specific data authority, business logic, security requirements and acceptance criteria.",{"id":1003,"data":1875,"type":218},{"text":1876},"That distinction also explains the relationship with AI Solution Architecture: \u003Cstrong>the solution architect makes one AI-enabled system fit its purpose; the platform architect makes shared AI capabilities safe, reusable, operable and evolvable across many such systems.\u003C\u002Fstrong>",{"id":1007,"data":1878,"type":42},{"text":1879,"level":242},"Related canonical knowledge",{"id":1011,"data":1881,"type":218},{"text":1882},"This article sits after the canonical foundations on generative AI components, ADR versus NFR, and AI Solution Architecture. Those concepts are prerequisites because a platform exists to provide reusable system capabilities and to encode architectural decisions against explicit quality and operational requirements.",{"id":1015,"data":1884,"type":218},{"text":1885},"Retrieval-Augmented Generation is one example of a capability that may be offered through a platform, but the platform should not collapse retrieval infrastructure, domain knowledge and answer validity into one concept.",{"id":1019,"data":1887,"type":1027},{"link":1888,"meta":1889},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works",{"image":1890,"title":1891,"description":1892},{"url":1024},"What Is RAG? The Simplest Explanation of How It Works","Canonical introduction to retrieval-augmented generation and the boundary between model generation and external knowledge retrieval.",{"id":1029,"data":1894,"type":218},{"text":1895},"Agent protocols, tenant isolation, AI governance, model routing, Context Engineering and MLOps\u002FLLMOps are downstream or adjacent knowledge nodes. They become easier to reason about once the platform boundary is explicit.",{"id":1033,"data":1897,"type":42},{"text":1898,"level":242},"Frequently asked questions",{"id":1037,"data":1900,"type":1037},{"items":1901,"title":1920},[1902,1905,1908,1911,1914,1917],{"id":1041,"answer":1903,"question":1904},"No. The solution architect focuses on one concrete AI-enabled solution. The platform architect focuses on reusable AI capabilities, controls and operational contracts that can support multiple solutions.","Is an AI Platform Architect the same as an AI Solution Architect?",{"id":1045,"answer":1906,"question":1907},"No. A platform can use managed cloud models, self-hosted models, local inference or a hybrid strategy. The architecture must make provider, locality, identity, routing, data and operational consequences explicit.","Does an AI platform need to host its own models?",{"id":1049,"answer":1909,"question":1910},"Usually not. A gateway can be an important platform component, but a complete platform also needs contracts for identity, secrets, data\u002Fretrieval, evaluation, observability, lifecycle and operational ownership.","Is an AI gateway enough to be an AI platform?",{"id":1053,"answer":1912,"question":1913},"Retrieval mechanics can often be shared, but domain authority, authorization, freshness, evidence sufficiency and corpus ownership should remain explicit. Shared infrastructure does not imply shared truth.","Should retrieval be centralized?",{"id":1057,"answer":1915,"question":1916},"No. Platform evaluation can test shared capabilities and regressions. Each solution still needs task-specific ground truth, acceptance criteria and domain quality thresholds.","Does platform evaluation replace application evaluation?",{"id":1061,"answer":1918,"question":1919},"No. RBAC determines what an identity may do. Tenant isolation determines which tenant's resources the identity may act on. A platform often needs both.","Is multi-tenancy just RBAC?","AI Platform Architect FAQ",{"id":1066,"data":1922,"type":42},{"text":1923,"level":242},"Glossary",{"id":1070,"data":1925,"type":1070},{"title":1926,"entries":1927},"Key AI platform architecture terms",[1928,1931,1934,1937,1940,1943,1946,1949],{"term":1929,"anchor":1076,"definition":1930},"AI platform","A reusable set of AI-related technical and operational capabilities consumed by multiple applications, teams or tenant contexts.",{"term":1932,"anchor":1080,"definition":1933},"AI gateway","A gateway layer for AI endpoints that may add authentication, routing, quotas, policy, retries, cost attribution and AI-specific telemetry beyond basic proxying.",{"term":1935,"anchor":1084,"definition":1936},"Provider adapter","A component that maps a platform contract to a model provider's API, capabilities, health and failure semantics.",{"term":1938,"anchor":1088,"definition":1939},"Tenant isolation","The boundary that prevents one tenant context from accessing another tenant's resources, independent of role permissions.",{"term":1941,"anchor":1092,"definition":1942},"Capability contract","A versioned interface and behavioral agreement describing what a shared platform service provides and what the consumer must supply or own.",{"term":1944,"anchor":1096,"definition":1945},"Grounding \u002F retrieval service","Shared mechanics for finding and supplying external information to an AI workload; it does not automatically define which information is authoritative for a domain.",{"term":1947,"anchor":1100,"definition":1948},"Evaluation harness","Reusable infrastructure for running tests, datasets, model\u002Fprompt versions and metrics; domain acceptance remains solution-specific.",{"term":1950,"anchor":1104,"definition":1951},"Control plane","The configuration and governance layer that manages platform capabilities, identities, policies, quotas, versions and deployment state.",{"id":1107,"data":1953,"type":42},{"text":1954,"level":242},"Primary sources and current architecture guidance",{"id":1111,"data":1956,"type":218},{"text":1957},"The sources below support the general architecture and production-platform claims. The Aaasaasa AI Client, Aaasaasa AI CMS and Source of Truth Research Engine sections are explicitly original implementation evidence. Current-state external references were checked on 8 October 2026.",{"id":1115,"data":1959,"type":1027},{"link":1117,"meta":1960},{"image":1961,"title":1962,"description":1963},{"url":1024},"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description","Current published international standard for architecture-description concepts and relationships.",{"id":1123,"data":1965,"type":1027},{"link":1125,"meta":1966},{"image":1967,"title":1128,"description":1968},{"url":1024},"NIST's AI RMF resources and current status; AI RMF 1.0 is under revision as of October 2026.",{"id":1131,"data":1970,"type":1027},{"link":1133,"meta":1971},{"image":1972,"title":1973,"description":1974},{"url":1024},"NIST AI 600-1 — Generative AI Profile","Generative AI profile for applying AI risk-management considerations across the AI lifecycle.",{"id":1139,"data":1976,"type":1027},{"link":1141,"meta":1977},{"image":1978,"title":1979,"description":1980},{"url":1024},"Microsoft Azure Well-Architected — AI Workloads","Current architectural guidance covering AI application, data, operations, evaluation, responsible AI and lifecycle concerns.",{"id":1147,"data":1982,"type":1027},{"link":1149,"meta":1983},{"image":1984,"title":1985,"description":1986},{"url":1024},"Microsoft — Design Principles for AI Workloads","Current guidance on identity segmentation, security boundaries, telemetry, performance, data and platform trade-offs.",{"id":1155,"data":1988,"type":1027},{"link":1157,"meta":1989},{"image":1990,"title":1991,"description":1992},{"url":1024},"Microsoft Foundry — AI Gateway Architecture","Current AI Gateway guidance for shared project access, token containment, quotas and governance.",{"id":1163,"data":1994,"type":1027},{"link":1165,"meta":1995},{"image":1996,"title":1997,"description":1998},{"url":1024},"Azure Architecture Center — Access Models Through a Gateway","Architecture guidance for centralized model access, routing, throttling, failover and client\u002Fplatform responsibilities.",{"id":1171,"data":2000,"type":1027},{"link":1173,"meta":2001},{"image":2002,"title":2003,"description":2004},{"url":1024},"AWS Well-Architected — Generative AI Lens","Current production architecture guidance for generative AI workloads across security, reliability, operations, performance and cost.",{"id":1179,"data":2006,"type":1027},{"link":1181,"meta":2007},{"image":2008,"title":2009,"description":2010},{"url":1024},"AWS — Multi-tenant Generative AI Platform Scenario","Current example separating central platform controls and auditability from consuming-application data quality and workload-specific responsibilities.",{"id":1187,"data":2012,"type":1027},{"link":1189,"meta":2013},{"image":2014,"title":2015,"description":2016},{"url":1024},"AWS Well-Architected — Agentic AI Design Principles","Current guidance on bounded agent authority, traceability, versioned behavior, explicit contracts and human oversight.",{"id":1195,"data":2018,"type":1027},{"link":1197,"meta":2019},{"image":2020,"title":2021,"description":2022},{"url":1024},"AWS CloudWatch — Generative AI Observability","Current observability capabilities and production metrics for models, agents, knowledge bases, tools and cost\u002Flatency\u002Ferror analysis.","2.31.0","An AI Platform Architect designs reusable AI foundations across models, providers, retrieval, agents, identity, security, evaluation, observability and operations.",{"lang":7,"title":208,"content":210,"contentJson":2026,"excerpt":1203},{"time":212,"blocks":2027,"version":1202},[2028,2030,2032,2034,2036,2038,2040,2042,2044,2060,2062,2064,2066,2068,2077,2079,2081,2083,2085,2095,2097,2099,2101,2103,2105,2107,2109,2111,2113,2115,2117,2119,2121,2123,2125,2127,2129,2131,2133,2135,2137,2139,2141,2143,2145,2147,2149,2151,2153,2155,2157,2159,2161,2163,2165,2167,2169,2176,2178,2180,2193,2195,2213,2215,2225,2227,2229,2231,2233,2235,2237,2239,2248,2250,2252,2254,2256,2258,2260,2262,2264,2266,2268,2270,2272,2274,2276,2278,2280,2292,2294,2307,2309,2322,2324,2326,2328,2330,2332,2334,2336,2338,2340,2342,2358,2360,2362,2364,2366,2368,2370,2372,2376,2378,2380,2389,2391,2402,2404,2406,2410,2414,2418,2422,2426,2430,2434,2438,2442,2446],{"id":215,"data":2029,"type":218},{"text":217},{"id":220,"data":2031,"type":225},{"body":222,"title":223,"variant":224},{"id":227,"data":2033,"type":225},{"body":229,"title":230,"variant":231},{"id":233,"data":2035,"type":225},{"body":235,"title":236,"variant":231},{"id":238,"data":2037,"type":243},{"title":240,"maxLevel":241,"minLevel":242},{"id":245,"data":2039,"type":42},{"text":247,"level":242},{"id":249,"data":2041,"type":218},{"text":251},{"id":253,"data":2043,"type":218},{"text":255},{"id":257,"data":2045,"type":299},{"rows":2046,"title":290,"layout":291,"columns":2057},[2047,2049,2051,2053,2055],{"id":261,"label":262,"values":2048},{"platform":264,"solution":265},{"id":267,"label":268,"values":2050},{"platform":270,"solution":271},{"id":273,"label":274,"values":2052},{"platform":276,"solution":277},{"id":279,"label":280,"values":2054},{"platform":282,"solution":283},{"id":285,"label":286,"values":2056},{"platform":288,"solution":289},[2058,2059],{"id":294,"label":295},{"id":297,"label":298},{"id":301,"data":2061,"type":42},{"text":303,"level":242},{"id":305,"data":2063,"type":218},{"text":307},{"id":309,"data":2065,"type":218},{"text":311},{"id":313,"data":2067,"type":218},{"text":315},{"id":317,"data":2069,"type":340},{"steps":2070,"title":338,"orientation":339},[2071,2072,2073,2074,2075,2076],{"label":321,"description":322},{"label":324,"description":325},{"label":327,"description":328},{"label":330,"description":331},{"label":333,"description":334},{"label":336,"description":337},{"id":342,"data":2078,"type":42},{"text":344,"level":242},{"id":346,"data":2080,"type":218},{"text":348},{"id":350,"data":2082,"type":218},{"text":352},{"id":354,"data":2084,"type":42},{"text":356,"level":242},{"id":358,"data":2086,"type":291},{"content":2087,"stretched":43,"withHeadings":14},[2088,2089,2090,2091,2092,2093,2094],[362,363,364],[366,367,368],[370,371,372],[374,375,376],[378,379,380],[280,382,383],[385,386,387],{"id":389,"data":2096,"type":225},{"body":391,"title":392,"variant":393},{"id":395,"data":2098,"type":42},{"text":397,"level":242},{"id":399,"data":2100,"type":42},{"text":401,"level":241},{"id":403,"data":2102,"type":218},{"text":405},{"id":407,"data":2104,"type":218},{"text":409},{"id":411,"data":2106,"type":225},{"body":413,"title":414,"variant":415},{"id":417,"data":2108,"type":42},{"text":419,"level":241},{"id":421,"data":2110,"type":218},{"text":423},{"id":425,"data":2112,"type":218},{"text":427},{"id":429,"data":2114,"type":218},{"text":431},{"id":433,"data":2116,"type":42},{"text":435,"level":241},{"id":437,"data":2118,"type":218},{"text":439},{"id":441,"data":2120,"type":218},{"text":443},{"id":445,"data":2122,"type":218},{"text":447},{"id":449,"data":2124,"type":42},{"text":451,"level":241},{"id":453,"data":2126,"type":218},{"text":455},{"id":457,"data":2128,"type":218},{"text":459},{"id":461,"data":2130,"type":218},{"text":463},{"id":465,"data":2132,"type":42},{"text":467,"level":241},{"id":469,"data":2134,"type":218},{"text":471},{"id":473,"data":2136,"type":218},{"text":475},{"id":477,"data":2138,"type":218},{"text":479},{"id":481,"data":2140,"type":42},{"text":483,"level":241},{"id":485,"data":2142,"type":218},{"text":487},{"id":489,"data":2144,"type":218},{"text":491},{"id":493,"data":2146,"type":42},{"text":495,"level":241},{"id":497,"data":2148,"type":218},{"text":499},{"id":501,"data":2150,"type":218},{"text":503},{"id":505,"data":2152,"type":218},{"text":507},{"id":509,"data":2154,"type":42},{"text":511,"level":241},{"id":513,"data":2156,"type":218},{"text":515},{"id":517,"data":2158,"type":218},{"text":519},{"id":521,"data":2160,"type":42},{"text":523,"level":241},{"id":525,"data":2162,"type":218},{"text":527},{"id":529,"data":2164,"type":218},{"text":531},{"id":533,"data":2166,"type":42},{"text":535,"level":242},{"id":537,"data":2168,"type":225},{"body":539,"title":540,"variant":231},{"id":542,"data":2170,"type":291},{"content":2171,"stretched":43,"withHeadings":14},[2172,2173,2174,2175],[546,547,548],[550,551,552],[554,555,556],[558,559,560],{"id":562,"data":2177,"type":218},{"text":564},{"id":566,"data":2179,"type":42},{"text":568,"level":242},{"id":570,"data":2181,"type":291},{"content":2182,"stretched":43,"withHeadings":14},[2183,2184,2185,2186,2187,2188,2189,2190,2191,2192],[574,575],[577,578],[580,581],[583,584],[586,587],[589,590],[592,593],[595,596],[598,599],[601,602],{"id":604,"data":2194,"type":42},{"text":606,"level":242},{"id":608,"data":2196,"type":299},{"rows":2197,"title":647,"layout":291,"columns":2210},[2198,2200,2202,2204,2206,2208],{"id":612,"label":613,"values":2199},{"pressureA":615,"pressureB":616},{"id":618,"label":619,"values":2201},{"pressureA":621,"pressureB":622},{"id":624,"label":625,"values":2203},{"pressureA":627,"pressureB":628},{"id":630,"label":631,"values":2205},{"pressureA":633,"pressureB":634},{"id":636,"label":637,"values":2207},{"pressureA":639,"pressureB":640},{"id":642,"label":643,"values":2209},{"pressureA":645,"pressureB":646},[2211,2212],{"id":650,"label":651},{"id":653,"label":654},{"id":656,"data":2214,"type":42},{"text":658,"level":242},{"id":660,"data":2216,"type":291},{"content":2217,"stretched":43,"withHeadings":14},[2218,2219,2220,2221,2222,2223,2224],[664,665],[667,668],[298,670],[672,673],[675,676],[678,679],[681,682],{"id":684,"data":2226,"type":218},{"text":686},{"id":688,"data":2228,"type":42},{"text":690,"level":242},{"id":692,"data":2230,"type":225},{"body":694,"title":695,"variant":231},{"id":697,"data":2232,"type":42},{"text":699,"level":241},{"id":701,"data":2234,"type":218},{"text":703},{"id":705,"data":2236,"type":218},{"text":707},{"id":709,"data":2238,"type":218},{"text":711},{"id":713,"data":2240,"type":291},{"content":2241,"stretched":43,"withHeadings":14},[2242,2243,2244,2245,2246,2247],[717,718],[720,721],[723,724],[726,727],[729,730],[732,733],{"id":735,"data":2249,"type":42},{"text":737,"level":241},{"id":739,"data":2251,"type":218},{"text":741},{"id":743,"data":2253,"type":218},{"text":745},{"id":747,"data":2255,"type":218},{"text":749},{"id":751,"data":2257,"type":42},{"text":753,"level":241},{"id":755,"data":2259,"type":218},{"text":757},{"id":759,"data":2261,"type":218},{"text":761},{"id":763,"data":2263,"type":218},{"text":765},{"id":767,"data":2265,"type":225},{"body":769,"title":770,"variant":393},{"id":772,"data":2267,"type":42},{"text":774,"level":242},{"id":776,"data":2269,"type":218},{"text":778},{"id":780,"data":2271,"type":218},{"text":782},{"id":784,"data":2273,"type":218},{"text":786},{"id":788,"data":2275,"type":218},{"text":790},{"id":792,"data":2277,"type":218},{"text":794},{"id":796,"data":2279,"type":42},{"text":798,"level":242},{"id":800,"data":2281,"type":291},{"content":2282,"stretched":43,"withHeadings":14},[2283,2284,2285,2286,2287,2288,2289,2290,2291],[804,805],[807,808],[810,811],[813,814],[816,817],[819,820],[822,823],[825,826],[828,829],{"id":831,"data":2293,"type":42},{"text":833,"level":242},{"id":835,"data":2295,"type":291},{"content":2296,"stretched":43,"withHeadings":14},[2297,2298,2299,2300,2301,2302,2303,2304,2305,2306],[839,840],[842,843],[845,846],[848,849],[851,852],[854,855],[857,858],[860,861],[863,864],[866,867],{"id":869,"data":2308,"type":42},{"text":871,"level":242},{"id":873,"data":2310,"type":340},{"steps":2311,"title":906,"orientation":339},[2312,2313,2314,2315,2316,2317,2318,2319,2320,2321],{"label":877,"description":878},{"label":880,"description":881},{"label":883,"description":884},{"label":886,"description":887},{"label":889,"description":890},{"label":892,"description":893},{"label":895,"description":896},{"label":898,"description":899},{"label":901,"description":902},{"label":904,"description":905},{"id":908,"data":2323,"type":42},{"text":910,"level":242},{"id":912,"data":2325,"type":218},{"text":914},{"id":916,"data":2327,"type":218},{"text":918},{"id":920,"data":2329,"type":218},{"text":922},{"id":924,"data":2331,"type":218},{"text":926},{"id":928,"data":2333,"type":218},{"text":930},{"id":932,"data":2335,"type":42},{"text":934,"level":242},{"id":936,"data":2337,"type":218},{"text":938},{"id":940,"data":2339,"type":218},{"text":942},{"id":944,"data":2341,"type":42},{"text":946,"level":242},{"id":948,"data":2343,"type":291},{"content":2344,"stretched":43,"withHeadings":14},[2345,2346,2347,2348,2349,2350,2351,2352,2353,2354,2355,2356,2357],[952,953],[955,956],[958,959],[961,962],[964,965],[967,968],[970,971],[973,974],[976,977],[979,980],[982,983],[985,986],[988,989],{"id":991,"data":2359,"type":42},{"text":993,"level":242},{"id":995,"data":2361,"type":218},{"text":997},{"id":999,"data":2363,"type":218},{"text":1001},{"id":1003,"data":2365,"type":218},{"text":1005},{"id":1007,"data":2367,"type":42},{"text":1009,"level":242},{"id":1011,"data":2369,"type":218},{"text":1013},{"id":1015,"data":2371,"type":218},{"text":1017},{"id":1019,"data":2373,"type":1027},{"link":1021,"meta":2374},{"image":2375,"title":1025,"description":1026},{"url":1024},{"id":1029,"data":2377,"type":218},{"text":1031},{"id":1033,"data":2379,"type":42},{"text":1035,"level":242},{"id":1037,"data":2381,"type":1037},{"items":2382,"title":1064},[2383,2384,2385,2386,2387,2388],{"id":1041,"answer":1042,"question":1043},{"id":1045,"answer":1046,"question":1047},{"id":1049,"answer":1050,"question":1051},{"id":1053,"answer":1054,"question":1055},{"id":1057,"answer":1058,"question":1059},{"id":1061,"answer":1062,"question":1063},{"id":1066,"data":2390,"type":42},{"text":1068,"level":242},{"id":1070,"data":2392,"type":1070},{"title":1072,"entries":2393},[2394,2395,2396,2397,2398,2399,2400,2401],{"term":1075,"anchor":1076,"definition":1077},{"term":1079,"anchor":1080,"definition":1081},{"term":1083,"anchor":1084,"definition":1085},{"term":1087,"anchor":1088,"definition":1089},{"term":1091,"anchor":1092,"definition":1093},{"term":1095,"anchor":1096,"definition":1097},{"term":1099,"anchor":1100,"definition":1101},{"term":1103,"anchor":1104,"definition":1105},{"id":1107,"data":2403,"type":42},{"text":1109,"level":242},{"id":1111,"data":2405,"type":218},{"text":1113},{"id":1115,"data":2407,"type":1027},{"link":1117,"meta":2408},{"image":2409,"title":1120,"description":1121},{"url":1024},{"id":1123,"data":2411,"type":1027},{"link":1125,"meta":2412},{"image":2413,"title":1128,"description":1129},{"url":1024},{"id":1131,"data":2415,"type":1027},{"link":1133,"meta":2416},{"image":2417,"title":1136,"description":1137},{"url":1024},{"id":1139,"data":2419,"type":1027},{"link":1141,"meta":2420},{"image":2421,"title":1144,"description":1145},{"url":1024},{"id":1147,"data":2423,"type":1027},{"link":1149,"meta":2424},{"image":2425,"title":1152,"description":1153},{"url":1024},{"id":1155,"data":2427,"type":1027},{"link":1157,"meta":2428},{"image":2429,"title":1160,"description":1161},{"url":1024},{"id":1163,"data":2431,"type":1027},{"link":1165,"meta":2432},{"image":2433,"title":1168,"description":1169},{"url":1024},{"id":1171,"data":2435,"type":1027},{"link":1173,"meta":2436},{"image":2437,"title":1176,"description":1177},{"url":1024},{"id":1179,"data":2439,"type":1027},{"link":1181,"meta":2440},{"image":2441,"title":1184,"description":1185},{"url":1024},{"id":1187,"data":2443,"type":1027},{"link":1189,"meta":2444},{"image":2445,"title":1192,"description":1193},{"url":1024},{"id":1195,"data":2447,"type":1027},{"link":1197,"meta":2448},{"image":2449,"title":1200,"description":1201},{"url":1024},"Post erfolgreich abgerufen",{"items":2452,"source":2537,"manualIds":2538,"manualMatchedIds":2539},[2453,2460,2467,2474,2481,2488,2495,2502,2509,2516,2523,2530],{"id":2454,"slug":2455,"title":2456,"excerpt":2457,"featuredImage":2458,"publishedAt":2459},"479","where-does-an-llm-get-its-data-rag-data-sources-in-python","Откуда LLM берёт данные? Источники данных RAG в Python","LLM не знает магическим образом о ваших файлах, базах данных или API. Это практическое продолжение серии о RAG показывает на простом Python, как внешние данные становятся извлекаемыми доказательствами: от текстовых файлов и SQL до полнотекстового поиска, эмбеддингов, сборки контекста и финального вызова LLM.","\u002Fuploads\u002F2026\u002F09\u002Fwhere-does-an-llm-get-its-data-rag-data-sources-in-python-1790517200521-nfsi5i.webp","2026-09-27T05:51:00.000Z",{"id":2461,"slug":2462,"title":2463,"excerpt":2464,"featuredImage":2465,"publishedAt":2466},"492","mcp-explained-what-it-connects-what-it-does-not-do-and-where-it-fits","MCP: объяснение — что он подключает, чего не делает и где ему место","Протокол контекста модели соединяет приложения ИИ с внешними инструментами, ресурсами и подсказками через стандартную границу клиент-сервер. Узнайте, что делает MCP, чего он не делает и где он вписывается в архитектуру агента.","\u002Fuploads\u002F2026\u002F10\u002Fmcp-explained-what-it-connects-what-it-does-not-do-and-where-it-fits-1791486640275-7ub1cq.webp","2026-10-08T15:09:00.000Z",{"id":2468,"slug":2469,"title":2470,"excerpt":2471,"featuredImage":2472,"publishedAt":2473},"485","enterprise-ai-architecture-what-changes-when-ai-enters-a-company","Архитектура ИИ на предприятии: что меняется, когда ИИ приходит в компанию","Архитектура ИИ для предприятий объясняет, как ИИ меняет корпоративные системы в таких областях, как полномочия на данные, идентификация, разрешения, поставщики, риски, управление, оценка, соответствие требованиям и операции.","\u002Fuploads\u002F2026\u002F10\u002Fenterprise-ai-architecture-what-changes-when-ai-enters-a-company-1791478161363-czrwaq.webp","2026-10-08T10:48:00.000Z",{"id":2475,"slug":2476,"title":2477,"excerpt":2478,"featuredImage":2479,"publishedAt":2480},"487","vector-databases-embeddings-and-reranking-three-different-parts-of-retrieval","Векторные базы данных, эмбеддинги и переранжирование: три разные части поиска","Эмбеддинги представляют смысл, векторные базы данных извлекают кандидатов, а реранкеры уточняют результаты. Узнайте, чем отличаются эти три слоя поиска и как они работают вместе в RAG.","\u002Fuploads\u002F2026\u002F10\u002Fvector-databases-embeddings-and-reranking-three-different-parts-of-retrieval-1791480129884-9dtasz.webp","2026-10-08T11:21:00.000Z",{"id":2482,"slug":2483,"title":2484,"excerpt":2485,"featuredImage":2486,"publishedAt":2487},"490","rbac-vs-tenant-isolation-two-different-security-boundaries","RBAC против изоляции арендаторов: две разные границы безопасности","RBAC определяет, что пользователь может делать; изоляция тенантов определяет, к ресурсам какого тенанта это действие может получить доступ. Узнайте, почему безопасность многотенантного SaaS требует обеих границ.","\u002Fuploads\u002F2026\u002F10\u002Frbac-vs-tenant-isolation-two-different-security-boundaries-1791485111528-qqtzby.webp","2026-10-08T14:43:00.000Z",{"id":2489,"slug":2490,"title":2491,"excerpt":2492,"featuredImage":2493,"publishedAt":2494},"471","how-to-know-whether-an-ai-agent-actually-used-the-right-evidence","Как узнать, действительно ли ИИ-агент использовал правильные доказательства","ИИ-агент может ссылаться на источники и при этом использовать неверные доказательства. В этой статье представлен практический метод проверки обоснованности утверждений, авторитетности источников, применимости, происхождения и того, действительно ли доказательства повлияли на ответ.","\u002Fuploads\u002F2026\u002F09\u002Fhow-to-know-whether-an-ai-agent-actually-used-the-right-evidence-1790351317188-o5z9ve.webp","2026-09-25T11:47:00.000Z",{"id":2496,"slug":2497,"title":2498,"excerpt":2499,"featuredImage":2500,"publishedAt":2501},"483","what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","Что такое архитектор ИИ-решений? Границы системы, обязанности и компромиссы","Архитектор решений ИИ превращает бизнес-требования в готовую к производству систему ИИ, охватывающую данные, модели, инструменты, безопасность, среду выполнения, оценку и операции.","\u002Fuploads\u002F2026\u002F10\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs-1791476643267-1st5xz.webp","2026-10-08T12:23:00.000Z",{"id":2503,"slug":2504,"title":2505,"excerpt":2506,"featuredImage":2507,"publishedAt":2508},"467","the-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers","Граница достоверности ответа: недостающий слой между релевантностью и надёжными ответами ИИ","Источник может быть релевантным, авторитетным и при этом неверным для задаваемого вопроса. Недостающий слой — применимость: условия, при которых ответ остаётся в силе, и изменения, вынуждающие пересмотреть его. В этой статье вводится понятие «Граница действительности ответа» как паттерн проектирования источников для людей, ИИ-поиска и RAG-систем.","\u002Fuploads\u002F2026\u002F09\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers-1790272901306-1g5jly.webp","2026-09-24T11:59:00.000Z",{"id":2510,"slug":2511,"title":2512,"excerpt":2513,"featuredImage":2514,"publishedAt":2515},"495","sovereign-ai-control-of-models-data-infrastructure-and-dependencies","Суверенный ИИ: контроль над моделями, данными, инфраструктурой и зависимостями","Суверенный ИИ — это эффективный контроль над моделями, данными, инфраструктурой, программным обеспечением, операциями и стратегическими зависимостями, а не просто место размещения модели ИИ.","\u002Fuploads\u002F2026\u002F10\u002Fsovereign-ai-control-of-models-data-infrastructure-and-dependencies-1791488833132-niy85x.webp","2026-10-08T15:45:00.000Z",{"id":2517,"slug":2518,"title":2519,"excerpt":2520,"featuredImage":2521,"publishedAt":2522},"486","source-of-truth-in-ai-systems-where-reliable-knowledge-actually-comes-from","Источник истины в системах ИИ: откуда на самом деле берутся надёжные знания","Источник истины определяет, какой источник является авторитетным для конкретного факта или состояния. Узнайте, чем он отличается от RAG, происхождения данных, памяти, контекста, векторных баз данных и систем учёта.","\u002Fuploads\u002F2026\u002F10\u002Fsource-of-truth-in-ai-systems-where-reliable-knowledge-actually-comes-from-1791479103235-6bq9em.webp","2026-10-08T13:02:00.000Z",{"id":2524,"slug":2525,"title":2526,"excerpt":2527,"featuredImage":2528,"publishedAt":2529},"489","agentic-ai-explained-when-an-ai-system-can-plan-use-tools-and-act","Агентный ИИ: когда система ИИ может планировать, использовать инструменты и действовать","Агентный ИИ использует модели внутри многошаговых циклов выполнения, где они могут выбирать инструменты, наблюдать результаты, обновлять состояние и адаптировать своё следующее действие в рамках явных границ времени выполнения и разрешений.","\u002Fuploads\u002F2026\u002F10\u002Fagentic-ai-explained-when-an-ai-system-can-plan-use-tools-and-act-1791481499084-wnji2a.webp","2026-10-08T11:43:00.000Z",{"id":2531,"slug":2532,"title":2533,"excerpt":2534,"featuredImage":2535,"publishedAt":2536},"480","when-should-an-ai-stop-trusting-its-own-knowledge-the-retrieval-trigger","Когда ИИ должен перестать доверять собственным знаниям? — Триггер извлечения","Модель ИИ не нуждается в поиске для каждого вопроса. Важная проблема — знать, когда её внутренних знаний уже недостаточно. Триггер поиска — это практическая граница принятия решений, которая определяет, когда система ИИ должна перестать полагаться исключительно на знания модели и получить внешние доказательства перед ответом.","\u002Fuploads\u002F2026\u002F09\u002Fwhen-should-an-ai-stop-trusting-its-own-knowledge-the-retrieval-trigger-1790574991244-f4rpyg.webp","2026-09-28T01:49:00.000Z","fallback",[],[]]