[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:ru":3,"public-menus:all":38,"post:what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs:ru":205,"related:post:what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs:ru:1":2136},{"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":2135},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":1072,"featuredImage":1073,"featuredImageAlt":1074,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":1075,"publishedAt":1076,"createdAt":1077,"updatedAt":1078,"seoLocalePaths":1079,"categories":1088,"author":1105,"translations":1110},"483","Что такое архитектор ИИ-решений? Границы системы, обязанности и компромиссы","what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u003Cp>\u003Cstrong>Архитектор AI-решений\u003C\u002Fstrong> переводит бизнес- или продуктовую потребность в архитектуру конкретного AI-решения. Роль определяет границы системы и значимые решения по логике приложения, авторитетным данным, поиску и контексту, моделям и провайдерам, инструментам или агентам, идентичности и разрешениям, безопасности, среде выполнения и развёртыванию, наблюдаемости, оценке, стоимости и операционному поведению. Это не просто выбор модели или промпт-инжиниринг: архитектурная ответственность состоит в том, чтобы всё решение было реализуемым, управляемым, тестируемым и эксплуатируемым.\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-решений проектирует полное AI-решение, а не только 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 стандартизирует понятия для описаний архитектуры; он не определяет эту должностную роль. Организации могут распределять обязанности между несколькими людьми. В этой статье термин означает архитектурную ответственность за одно конкретное 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\">Изложенные здесь архитектурные принципы намеренно не привязаны к вендорам, тогда как актуальные рекомендации вендоров используются как свидетельства реализации. NIST AI RMF 1.0 в настоящее время пересматривается; NIST AI 600-1 остаётся опубликованным профилем генеративного ИИ. Упоминаемые ниже рекомендации Microsoft и AWS отражают текущие производственные вопросы, такие как идентичность, границы данных, абстракция моделей, безопасность, наблюдаемость, оценка, надёжность и стоимость.\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-14\" class=\"editorjs-toc__link\">Где заканчивается простой пример\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-17\" class=\"editorjs-toc__link\">Карта архитектурной ответственности\u003C\u002Fa>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-1\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-20\" class=\"editorjs-toc__link\">1. Превратите потребность продукта в архитектурные требования\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-23\" class=\"editorjs-toc__link\">2. Проектируйте авторитетные данные, извлечение и контекст\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-26\" class=\"editorjs-toc__link\">3. Рассматривайте модели и провайдеров как зависимости, а не как всю систему\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-29\" class=\"editorjs-toc__link\">4. Проектируйте инструменты, действия и границы агентов\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-32\" class=\"editorjs-toc__link\">5. Сделайте границы доверия и разрешения явными\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-35\" class=\"editorjs-toc__link\">6. Решите, где система фактически работает\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-38\" class=\"editorjs-toc__link\">7. Определите оценку, наблюдаемость и операционную приёмку\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-41\" class=\"editorjs-toc__link\">Что должна создавать эта роль?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-44\" class=\"editorjs-toc__link\">Работа — это в основном компромиссы, а не выбор «лучших практик»\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-47\" class=\"editorjs-toc__link\">Чем это отличается от смежных ролей?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-51\" class=\"editorjs-toc__link\">Доказательства реализации: как эти границы проявляются в моей собственной работе\u003C\u002Fa>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-1\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-53\" class=\"editorjs-toc__link\">SenseFlow: потребность → требования → архитектура → валидация\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-57\" class=\"editorjs-toc__link\">Aaasaasa AI Client: разделяйте концепции до их интеграции\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\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-65\" class=\"editorjs-toc__link\">Распространённые заблуждения\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-67\" class=\"editorjs-toc__link\">Режимы отказа, которые архитектор AI-решений должен предотвращать\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-69\" class=\"editorjs-toc__link\">Практическая последовательность решений\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-71\" class=\"editorjs-toc__link\">Краевые случаи и ограничения роли\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-75\" class=\"editorjs-toc__link\">Что могло бы изменить этот ответ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-78\" class=\"editorjs-toc__link\">Чек-лист AI Solution Architect\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-80\" class=\"editorjs-toc__link\">Заключение\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-85\" 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>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-6\">Что на самом деле проектирует архитектор AI-решений?\u003C\u002Fh2>\n\u003Cp>Объектом работы является \u003Cstrong>решение\u003C\u002Fstrong>: полная социотехническая система, которая превращает потребность в полезное, контролируемое поведение. Модель может быть центральной для этой системы, но она всё равно остаётся лишь одной зависимостью. Одна и та же модель может участвовать в безопасном внутреннем поисковом ассистенте, в небезопасном агенте с избыточными привилегиями, в клиентской функции с низкой задержкой или в дорогостоящем прототипе, который невозможно экономически эффективно эксплуатировать. Архитектура определяет эти различия.\u003C\u002Fp>\n\u003Cp>Полезная граница, таким образом, такова: \u003Cstrong>бизнес-результат → требования → обязанности системы → архитектурные решения → реализация → проверка → эксплуатация\u003C\u002Fstrong>. Архитектор AI-решений работает по всей этой цепочке, взаимодействуя с продуктом, инженерией, данными, безопасностью, инфраструктурой, управлением и предметными специалистами.\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\">Вопрос, ориентированный на модель\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\">Вопрос архитектуры решения\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\">Which model can generate or reason well enough?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Which combination of model, data, application logic, retrieval, tools and controls produces the required behavior?\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\">What context can fit in the prompt?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">What is authoritative, who may access it, how is it retrieved, versioned, filtered and cited?\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\">Does the provider offer security features?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">What are the trust boundaries, identities, permissions, secrets, data flows and failure containment mechanisms?\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\">What is the token latency?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">How is the complete workload deployed, observed, evaluated, recovered, versioned and cost-controlled?\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\">Can we switch models?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Which dependencies are abstracted, what changes require an ADR, and how do we validate that a replacement still meets requirements?\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-10\">Простейший пример\u003C\u002Fh2>\n\u003Cp>Представьте, что компания хочет создать внутреннего ассистента, который отвечает на вопросы техников по руководствам по обслуживанию и рабочим процедурам. Видимая функция звучит просто: введите вопрос и получите ответ с источниками.\u003C\u002Fp>\n\u003Cp>Архитектурный вопрос гораздо шире. Какие документы являются авторитетными? Как аутентифицируются пользователи? Должен ли поиск учитывать разрешения отдела или площадки? Разрешено ли ответу использовать только найденные доказательства? Какая модель допустима для данной классификации данных? Может ли облачный провайдер получать содержимое? Что происходит, когда поиск ничего не находит? Как формируются ссылки на источники? Как оценивается качество ответа? Какие задержка и стоимость приемлемы? Кто может видеть логи и что в них можно хранить?\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\">Превратите архитектуру в код приложения, API, политики, инфраструктуру, рабочие процессы и операционные средства контроля.\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>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-14\">Где заканчивается простой пример\u003C\u002Fh2>\n\u003Cp>Прототип часто может пропустить ту архитектуру, без которой не обойтись в продакшене. Разработчик может жёстко задать одного провайдера, использовать общий API-ключ, поместить все документы в один индекс, выполнять поиск без фильтрации по контексту пользователя, логировать промпты дословно и оценивать качество вручную. Это может продемонстрировать осуществимость, но не создаёт производственную архитектуру.\u003C\u002Fp>\n\u003Cp>Продакшен вводит ограничения, которые взаимодействуют: изоляция арендаторов или пользователей, конфиденциальность, резидентность данных, пропускная способность, задержка, стоимость, квоты провайдеров, поведение при отказах, аудируемость, изменения версий моделей, качество поиска, разрешения инструментов, реагирование на инциденты и жизненный цикл развёртывания. Задача архитектора — не максимизировать каждое качество сразу, а сделать компромиссы явными и спроектировать решение, удовлетворяющее фактическому набору приоритетов.\u003C\u002Fp>\n\u003Ch2 id=\"section-17\">Карта архитектурной ответственности\u003C\u002Fh2>\n\u003Cp>Точное распределение зависит от организации, но приведённая ниже карта отражает повторяющиеся обязанности архитектуры AI на уровне решения. Архитектор может лично не реализовывать каждый слой; ответственность состоит в том, чтобы слои согласованно сочетались, а критические решения оставались прослеживаемыми.\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\">Вопросы, которые должен решить архитектор AI-решения\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\">Какие ограничения по качеству, безопасности, доступности, задержке, стоимости, размещению данных и соответствию применимы?\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\">Где заканчивается детерминированная логика приложения и начинается поведение AI? Как координируются рабочие процессы?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Модель компонентов, API, границы оркестрации, пути отказов\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\">Решение о модели\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>\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\">Модель угроз\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>\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подсказок\u002Fконфигурации\u002Fданных?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Операционная модель, управление жизненным циклом, ADR, инструкции, правила изменений\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch3 id=\"section-20\">1. Превратите потребность продукта в архитектурные требования\u003C\u002Fh3>\n\u003Cp>AI-архитектура начинается до выбора модели. Сначала архитектор определяет, чего должно достичь решение и при каких ограничениях. Это включает функциональное поведение, но также нефункциональные требования и политики, которые сужают пространство проектирования: безопасность, надежность, задержка, конфиденциальность, размещение данных, сопровождаемость, стоимость и операционная поддержка.\u003C\u002Fp>\n\u003Cp>Здесь важно различие из A02: требование вроде «неавторизованные пользователи не должны извлекать документы с ограниченным доступом» не является архитектурным решением. Это движущий фактор. Решения о распространении идентификаторов, секционировании индекса, фильтрации метаданных, границах API и обеспечении авторизации — это архитектурные ответы, которые позже должны быть проверены.\u003C\u002Fp>\n\u003Ch3 id=\"section-23\">2. Проектируйте авторитетные данные, извлечение и контекст\u003C\u002Fh3>\n\u003Cp>AI-системы часто терпят неудачу на границе между поведением модели и корпоративной истиной. Архитектор должен определить, какие источники являются авторитетными, что означают свежесть и происхождение данных, как контроль доступа достигает извлечения и как извлеченные доказательства становятся контекстом модели. Векторная база данных, модель эмбеддингов или библиотека RAG сами по себе не являются архитектурой.\u003C\u002Fp>\n\u003Cp>Текущие рекомендации Microsoft по AI-нагрузкам явно устанавливают такое же разделение: код приложения не должен обходить границы доступа к данным; контекст пользователя или арендатора должен распространяться на извлечение и фильтрацию; данные для обоснования должны быть спроектированы для поиска, одновременно соответствуя требованиям безопасности и соответствия.\u003C\u002Fp>\n\u003Ch3 id=\"section-26\">3. Рассматривайте модели и провайдеров как зависимости, а не как всю систему\u003C\u002Fh3>\n\u003Cp>Выбор модели важен, но он должен определяться требуемыми возможностями и ограничениями. Архитектор учитывает качество рассуждений или генерации, модальность, ограничения контекста, задержку, обработку данных, место развертывания, доступность провайдера, стоимость, наблюдаемость и риск замены.\u003C\u002Fp>\n\u003Cp>Абстракция провайдера не является автоматически «лучшей архитектурой». Она добавляет инженерные затраты и может скрывать возможности, специфичные для провайдера. Она оправдана, когда переносимость, резервирование, разделение политик или маршрутизация между несколькими провайдерами являются явным требованием. В противном случае прямая интеграция может быть лучшим решением. Смысл в том, чтобы сделать компромисс осознанным.\u003C\u002Fp>\n\u003Ch3 id=\"section-29\">4. Проектируйте инструменты, действия и границы агентов\u003C\u002Fh3>\n\u003Cp>Когда AI-система может вызывать инструменты, изменять данные, отправлять сообщения, выполнять код или управлять бизнес-системами, архитектурный риск меняется. Доступ к инструментам требует собственной модели идентификации и авторизации. Способность модели запросить действие не равна разрешению на его выполнение.\u003C\u002Fp>\n\u003Cp>Для агентных нагрузок текущие рекомендации AWS подчеркивают дополнительные измерения, такие как идентификаторы агентов, доступ к инструментам, оркестрация, человеческий надзор, трассировка, обработка сбоев и стоимость итеративных циклов рассуждения. Это вопросы решения, даже когда фреймворк скрывает часть механики реализации.\u003C\u002Fp>\n\u003Ch3 id=\"section-32\">5. Сделайте границы доверия и разрешения явными\u003C\u002Fh3>\n\u003Cp>Производственное AI-решение имеет несколько границ доверия: браузер или клиент, серверная часть приложения, AI-оркестрация, службы извлечения\u002Fданных, провайдеры моделей, API инструментов, локальные среды выполнения и внешние системы. Каждая граница должна отвечать: кто вызывает, от чьего имени, с какими учетными данными, для какого ресурса, с каким журналом аудита и с каким ограничением последствий сбоя?\u003C\u002Fp>\n\u003Cp>Безопасность нельзя откладывать на «ограждение» вокруг модели. Рекомендации Microsoft по AI-нагрузкам явно размещают безопасность на всех архитектурных уровнях и требуют управления идентификацией\u002Fдоступом, защиты данных, контроля содержимого и безопасности жизненного цикла. NIST также рассматривает управление и управление рисками как непрерывные на протяжении жизненного цикла AI.\u003C\u002Fp>\n\u003Ch3 id=\"section-35\">6. Решите, где система фактически работает\u003C\u002Fh3>\n\u003Cp>«Локальный AI», «облачный AI» и «гибридный AI» являются архитектурными утверждениями только тогда, когда пути выполнения и данных точны. Локальный процесс на рабочем столе все еще может вызывать облачную модель. Приложение, размещенное в облаке, может извлекать данные из локального источника. Решение с воздушным зазором имеет совершенно иные ограничения по обновлению, распространению моделей и наблюдаемости.\u003C\u002Fp>\n\u003Cp>Поэтому архитектор разделяет \u003Cstrong>среду выполнения\u003C\u002Fstrong>, \u003Cstrong>среду инференса\u003C\u002Fstrong>, \u003Cstrong>расположение данных\u003C\u002Fstrong> и \u003Cstrong>плоскость управления\u003C\u002Fstrong>. Их смешение создаёт ложные предположения о безопасности и развёртывании.\u003C\u002Fp>\n\u003Ch3 id=\"section-38\">7. Определите оценку, наблюдаемость и операционную приёмку\u003C\u002Fh3>\n\u003Cp>Поведение ИИ частично недетерминировано, поэтому определение релиза не может опираться только на обычные модульные тесты. Архитектуре нужна измеримая приёмка: успешность задачи, обоснованность или корректность цитирования там, где это важно, поведение отказов, безопасность инструментов, задержка, стоимость, надёжность и тесты безопасности. Точные метрики зависят от сценария использования.\u003C\u002Fp>\n\u003Cp>Текущее руководство Microsoft Well-Architected для ИИ рассматривает мониторинг как непрерывный и применяет его к поведению модели, промптам\u002Fответам, аномалиям, безопасности и контрольным точкам качества в продакшене. AWS аналогично рассматривает наблюдаемость, управление жизненным циклом и прослеживаемость моделей\u002Fпромптов как вопросы операционной архитектуры.\u003C\u002Fp>\n\u003Ch2 id=\"section-41\">Что должна создавать эта роль?\u003C\u002Fh2>\n\u003Cp>Архитектура — это не презентация. Полезные результаты — это артефакты, которые позволяют инженерам, безопасности, продукту и операциям принимать согласованные решения и позже понимать, почему система существует в текущем виде.\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\">Контекст и границы решения\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поиск, модель, инструменты, идентичность и взаимодействия среды выполнения\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\">Связывает требования, решения, работу по реализации, тесты и операционные доказательства\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-44\">Работа — это в основном компромиссы, а не выбор «лучших практик»\u003C\u002Fh2>\n\u003Cp>Архитектура существует потому, что желаемые качества конфликтуют. Более дешёвая модель может снизить качество. Более способная модель может увеличить задержку или ограничения управления данными. Агрессивное кэширование может улучшить стоимость и скорость, усложняя актуальность. Более автономные агенты могут снизить человеческие усилия, увеличивая радиус поражения и требования к аудиту.\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>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Потенциальная стоимость \u002F риск\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>\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\">Контроль, офлайн\u002Fприватные варианты\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\">Проще реализация, полные возможности провайдера\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\">Риск наименьшего общего знаменателя, больше кода\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>\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>\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>\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-47\">Чем это отличается от смежных ролей?\u003C\u002Fh2>\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\">Роль\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\">Основной фокус архитектуры\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 solution\u002Fworkload\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">How requirements, data, models, tools, security, runtime and operations fit together to deliver the target outcome\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\">Reusable AI platform capabilities across many solutions\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Shared provider gateways, model access, identity, evaluation, retrieval services, observability, deployment patterns and developer experience\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\">Organization\u002Fportfolio-level target architecture\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Capability landscape, governance, integration principles, shared platforms, standards, sourcing and strategic constraints across domains\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Инженер по ИИ \u002F МО\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Implementation of AI\u002FML behavior and pipelines\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Models, data, inference, evaluation, application logic and engineering tasks within the architecture\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\">Security architecture across systems\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Threats, identity, authorization, data protection, controls, assurance and compliance boundaries\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Руководитель продукта \u002F поставки\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Outcome, scope, prioritization and delivery system\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Why\u002Fwhat to build, sequencing, stakeholders, milestones, acceptance and value realization\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Cp>В небольшой продуктовой команде один человек может охватывать несколько из этих областей. В крупном предприятии это могут быть отдельные роли с формальными советами по проверке. Архитектурная ответственность не исчезает при смене названия.\u003C\u002Fp>\n\u003Ch2 id=\"section-51\">Доказательства реализации: как эти границы проявляются в моей собственной работе\u003C\u002Fh2>\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>оригинальные доказательства реализации\u002Fпроекта\u003C\u002Fstrong>. Они показывают, как я разделял потребность продукта, требования, архитектуру, среду выполнения, модель\u002Fпровайдера, разрешения и валидацию в реальной проектной работе. Они не утверждают, что каждая организация должна использовать ту же структуру, и не подразумевают внедрение заказчиком или развёртывание корпоративного масштаба.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch3 id=\"section-53\">SenseFlow: потребность → требования → архитектура → валидация\u003C\u002Fh3>\n\u003Cp>В проекте SenseFlow Source of Truth технология явно подчинена видению продукта. Структура разработки движется от проблемы и видения продукта через потребности пользователей, ценность, область, эпики, истории и критерии приёмки к архитектуре, реализации, валидации и итерации.\u003C\u002Fp>\n\u003Cp>Требования спроектированы так, чтобы прослеживаться от Цели продукта → Возможности → Эпика → Пользовательской истории → Критериев приёмки → Технических задач. Где это практически осуществимо, они включают функциональные требования, нефункциональные требования, зависимости, риски, допущения, критерии приёмки и методы валидации. Значимые решения сохраняют решение, причину, альтернативы, компромиссы, статус и дату\u002Fверсию.\u003C\u002Fp>\n\u003Cp>Это архитектурная работа до выбора конкретного AI-фреймворка или модели: она защищает связь между замыслом продукта и техническими решениями и делает последующие изменения проверяемыми, а не неявными.\u003C\u002Fp>\n\u003Ch3 id=\"section-57\">Aaasaasa AI Client: разделяйте концепции до их интеграции\u003C\u002Fh3>\n\u003Cp>Aaasaasa AI Client представляет пример более низкого уровня реализации. Его AI Hub намеренно разделяет \u003Cstrong>агента\u002Fклиента\u003C\u002Fstrong>, \u003Cstrong>провайдера\u003C\u002Fstrong>, \u003Cstrong>модель\u003C\u002Fstrong>, \u003Cstrong>расположение подключения\u002Fсреды выполнения\u003C\u002Fstrong>, \u003Cstrong>разрешения\u003C\u002Fstrong> и \u003Cstrong>веб-клиент\u003C\u002Fstrong>. Локальная среда выполнения не предполагает локальный вывод, а разрешения рассматриваются как политика среды выполнения\u002Fинструментов, а не как свойство модели.\u003C\u002Fp>\n\u003Cp>Архитектура десктопного приложения также определяет границу доверия: рендерер Nuxt не является доверенным по отношению к главному процессу Electron. Узкий preload и валидированный IPC опосредуют доступ к AI-сервисам, настройкам, зашифрованным секретам, сервисам рабочего пространства\u002Fданных и средам выполнения. Облачные учётные данные остаются в привилегированном главном процессе; код рендерера получает нормализованное состояние вместо необработанных секретов или неограниченного доступа к операционной системе.\u003C\u002Fp>\n\u003Cp>Решения о маршрутизации также являются архитектурными. Реализация не выполняет неявный откат с локального маршрута на платный облачный вывод; облачный маршрут требует явного подтверждения. Direct Chat по умолчанию не имеет инструментов файловой системы или оболочки, тогда как выполнение агента применяет выбранное рабочее пространство и профиль разрешений. Это решения уровня решения о доверии, стоимости, выполнении и ожиданиях пользователя — а не функции модели.\u003C\u002Fp>\n\u003Ch2 id=\"section-61\">Как современные архитектурные фреймворки поддерживают этот более широкий охват\u003C\u002Fh2>\n\u003Cp>ISO\u002FIEC\u002FIEEE 42010:2022 предоставляет общую дисциплину для описаний архитектуры в программном обеспечении, системах и предприятиях. Он намеренно шире, чем AI, и не предписывает единственный метод архитектурирования или название должности. Это делает его полезным здесь как границу: архитектура AI-решения — это всё ещё архитектура, с concerns заинтересованных сторон, множественными представлениями и значимыми отношениями, которые должны быть выражены ясно.\u003C\u002Fp>\n\u003Cp>NIST AI RMF 1.0 описывает управление рисками AI через \u003Cstrong>Govern, Map, Measure и Manage\u003C\u002Fstrong> и подчёркивает, что управление рисками должно быть непрерывным на протяжении жизненного цикла AI-системы. Профиль генеративного AI (NIST AI 600-1) адаптирует этот фреймворк к рискам GAI и организационным приоритетам. Это подтверждает, что архитектура не может ограничиваться функциональной производительностью модели.\u003C\u002Fp>\n\u003Cp>Текущее руководство Microsoft Azure Well-Architected AI разделяет concerns проектирования приложений, платформы приложений, данных обучения, данных заземления и платформы данных и неоднократно связывает их с надёжностью, безопасностью, операционным совершенством, производительностью и стоимостью. Линзы AWS Generative AI и Agentic AI аналогично рассматривают наблюдаемость, безопасность, надёжность, жизненный цикл модели\u002Fинструмента, стоимость и человеческий надзор как архитектурные concerns.\u003C\u002Fp>\n\u003Ch2 id=\"section-65\">Распространённые заблуждения\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\">«Архитектор выбирает LLM.»\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\">«RAG решает проблему корпоративных знаний.»\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локальный AI.»\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\">«Если поставщик предлагает guardrails, безопасность обеспечена.»\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>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-67\">Режимы отказа, которые архитектор 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>\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\">Общие учётные данные и широкий доступ сохраняются после PoC\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\">Передавайте контекст пользователя\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>\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>\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\">Модели, промпты, извлечение или разрешения меняются без архитектурной истории\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\">Поведение AI не наблюдаемо после развёртывания\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-69\">Практическая последовательность решений\u003C\u002Fh2>\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\">Результат\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Определите пользовательский\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\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Доказательства и ограничения\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\">Граница системы\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Сопоставьте пользователей, идентичности, приложения, данные, модели\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\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Варианты архитектуры\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\">Решения о компромиссах\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\">Контракты реализации\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Преобразуйте решения в API, схемы, правила разрешений, определения развёртывания и инженерные задачи.\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\">Валидация\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\">Операционная обратная связь\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Используйте производственные доказательства, инциденты, метрики качества и сигналы стоимости\u002Fбезопасности для запуска контролируемых изменений.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-71\">Краевые случаи и ограничения роли\u003C\u002Fh2>\n\u003Cp>Некоторые AI-продукты определяются обучением моделей, научными экспериментами или специализированным оборудованием. В таких случаях наука о моделях\u002Fданных и архитектура ML-систем могут стать гораздо глубже, чем показанная здесь карта уровня решения. Архитектор AI-решений всё ещё нуждается в интеграции и операционных границах, но специализированная архитектура может владеть самой платформой обучения.\u003C\u002Fp>\n\u003Cp>На другом полюсе простая интеграция SaaS может не оправдывать выделенного архитектора. Старший инженер или технический руководитель продукта может нести ту же архитектурную ответственность. Полезная проверка — не должность, а то, принимаются ли значимые кросс-слойные решения осознанно и подтверждаются ли они.\u003C\u002Fp>\n\u003Cp>Регулируемые, суверенные, изолированные, критичные для безопасности, высокоавтономные или мультитенантные системы также смещают центр тяжести. Идентификация, изоляция, резидентность данных, гарантии, механизмы обновления, человеческий надзор и аудируемость могут доминировать над качеством модели в архитектуре.\u003C\u002Fp>\n\u003Ch2 id=\"section-75\">Что могло бы изменить этот ответ?\u003C\u002Fh2>\n\u003Cp>Точная граница ответственности меняется, когда архитектура переходит от одного приложения к переиспользуемой платформе или к общеорганизационной целевой архитектуре. Именно поэтому \u003Cstrong>AI Platform Architect\u003C\u002Fstrong> и \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> заслуживают отдельного канонического рассмотрения, а не объединения в эту роль.\u003C\u002Fp>\n\u003Cp>Технологические изменения также важны. Новые возможности моделей, протоколы, локальные среды выполнения и управляемые сервисы могут устранить часть работы по реализации, одновременно создавая новые границы доверия или эксплуатации. Устойчивая ответственность — понимать эти изменения как изменения системы, а не воспринимать новый фреймворк как замену архитектуры.\u003C\u002Fp>\n\u003Ch2 id=\"section-78\">Чек-лист AI Solution 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\">Явно ли определены пользовательский\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\">Поиск\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\">Связан ли выбор модели\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\">Определены ли человеческие\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\">Ясна ли ответственность за развертывание, откат, инциденты и жизненный цикл?\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-80\">Заключение\u003C\u002Fh2>\n\u003Cp>AI Solution Architect — это человек или архитектурная функция, которая превращает возможность AI в согласованную техническую систему. Ключевой навык — не знание наибольшего числа названий моделей, а связывание потребности продукта, требований, данных, архитектуры приложения, возможностей AI, безопасности, среды выполнения, поставки и валидации без потери границ между ними.\u003C\u002Fp>\n\u003Cp>Таким образом, сильную архитектуру AI-решения можно резюмировать так: \u003Cstrong>определить цель → установить требования и ограничения → спроектировать границы системы → сделать значимые компромиссы явными → реализовать через четкие контракты → подтвердить доказательствами → эксплуатировать и развивать осознанно.\u003C\u002Fstrong> Модель важна. Продукт — это решение.\u003C\u002Fp>\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\">AI Solution Architect — FAQ\u003C\u002Fh3>\u003Cdiv id=\"faq1\" 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\">Что такое AI Solution Architect?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">AI Solution Architect переводит бизнес- или продуктовую потребность в архитектуру конкретного AI-решения, определяя, как логика приложения, данные\u002Fпоиск, модели, инструменты, идентификация, безопасность, среда выполнения, оценка и эксплуатация работают вместе.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq2\" 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\">AI Solution Architect — то же самое, что AI-инженер?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Нет. Роли могут пересекаться, особенно в небольших командах, но AI-инженер — это прежде всего роль реализации, тогда как архитектор решения владеет или координирует кросс-слойные архитектурные решения и компромиссы для полной рабочей нагрузки.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq3\" 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\">Нужно ли AI Solution Architect уметь программировать?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">По определению нет, но практические знания реализации крайне ценны, поскольку архитектура AI пересекает API, данные, поиск, безопасность, среды выполнения и эксплуатационное поведение. Роль определяется архитектурной ответственностью, а не написанием каждого компонента лично.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq4\" 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\">Выбор LLM — главная работа?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Нет. Выбор модели — одно из решений. Продакшн-архитектура также требует границ данных и поиска, разрешений, инструментов, выбора провайдера\u002Fсреды выполнения, наблюдаемости, оценки, надежности, затрат и проектирования жизненного цикла.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq5\" 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\">В чем разница между AI Solution Architect и AI Platform Architect?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">AI Solution Architect фокусируется на одном конкретном решении или рабочей нагрузке. AI Platform Architect фокусируется на переиспользуемых возможностях AI и ограничениях, поддерживающих множество решений.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq6\" 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\">В чем разница между AI Solution Architect и Enterprise AI Architect?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Архитектор решения работает в масштабе приложения\u002Fрабочей нагрузки. Архитектура Enterprise AI работает в масштабе организационного портфеля, целевой архитектуры, управления, общих возможностей, принципов интеграции и стратегических ограничений.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq7\" 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\">Где место RAG и агентов?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Это архитектурные паттерны или подсистемы внутри решения, когда требования их оправдывают. RAG обеспечивает контекст, обоснованный поиском; агенты добавляют планирование\u002Fвыполнение инструментов и, следовательно, дополнительные вопросы идентификации, разрешений, оркестрации и эксплуатации.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq8\" 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>\u003C\u002Fsection>\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-solution-architect\" 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\">AI Solution Architect\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Архитектурная ответственность за одно конкретное AI-решение или рабочую нагрузку, объединяющая требования продукта с проектированием приложения, данных, модели, инструментов, безопасности, среды выполнения и эксплуатации.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"system-boundary\" 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=\"trust-boundary\" 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\" 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\">Обоснование (grounding)\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Предоставление AI-модели релевантной внешней информации или доказательств, чтобы ее ответ мог основываться на источниках за пределами параметров модели.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"provider-abstraction\" 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=\"evaluation\" 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\">Структурированное измерение поведения AI-нагрузки по заданным критериям приемки, включая качество выполнения задачи и соответствующие свойства безопасности, защищенности, производительности и эксплуатации.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"ai-platform-architect\" 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\">AI Platform Architect\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Архитектурная роль, сосредоточенная на переиспользуемых возможностях AI-платформы, используемых множеством решений, а не на архитектуре одной рабочей нагрузки.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"enterprise-ai-architecture\" 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\">Enterprise AI Architecture\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Архитектура уровня организации, координирующая возможности AI, платформы, управление, интеграцию и стратегические ограничения в рамках портфеля.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-85\">Связанные канонические знания\u003C\u002Fh2>\n\u003Cp>Эта статья находится в кластере AI Architecture Foundations. Ее непосредственные основы — \u003Cstrong>Generative AI Explained: Models, Retrieval, Tools and Applications Are Not the Same Thing\u003C\u002Fstrong> и \u003Cstrong>ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing\u003C\u002Fstrong>. Смежные канонические узлы включают \u003Cstrong>Agentic AI Explained\u003C\u002Fstrong>, \u003Cstrong>Source of Truth in AI Systems\u003C\u002Fstrong>, \u003Cstrong>Vector Databases, Embeddings and Reranking\u003C\u002Fstrong>, \u003Cstrong>What Is Context Engineering?\u003C\u002Fstrong>, \u003Cstrong>RBAC vs Tenant Isolation\u003C\u002Fstrong>, \u003Cstrong>AI Platform Architect\u003C\u002Fstrong>, \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> и \u003Cstrong>AI Governance\u003C\u002Fstrong>. URL-адреса намеренно не выдумываются там, где эти узлы еще не опубликованы.\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\">What Is RAG? The Simplest Explanation of How It Works\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Существующее каноническое объяснение stajic.de генерации с дополненной выборкой, полезное для части поиска\u002Fобоснования в архитектуре AI-решения.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ch2 id=\"section-88\">Первичные источники и актуальные рекомендации по архитектуре\u003C\u002Fh2>\n\u003Cp>Внешние источники ниже поддерживают общие архитектурные утверждения; разделы SenseFlow и Aaasaasa AI Client являются явными доказательствами оригинального проекта\u002Fреализации. Ссылки на текущее состояние были проверены 8 октября 2026 года. NIST отмечает, что AI RMF 1.0 пересматривается, поэтому зависящие от версии ссылки на управление следует перепроверять при публикации преемника.\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 — Architecture Description\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. По состоянию на октябрь 2026 года на ней указано, что AI RMF 1.0 пересматривается, и приведены ссылки на Generative AI Profile и связанные ресурсы.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fairc.nist.gov\u002Fairmf-resources\u002Fairmf\u002F5-sec-core\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\">NIST AI RMF Core — Govern, Map, Measure, Manage\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Официальная презентация NIST AIRC ядра AI RMF 1.0, включая четыре функции и ориентированную на жизненный цикл структуру управления рисками.\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 — Generative AI Profile\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Межотраслевой профиль генеративного ИИ для AI RMF 1.0, опубликованный 26 июля 2024 года и обновлённый NIST в 2026 году.\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 — AI Workloads\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\u002Fapplication-design\" 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 — Application Design for AI Workloads\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 — Design Principles for AI Workloads\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\u002Fmlops-genaiops\" 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 — MLOps and GenAIOps for AI Workloads\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\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 Generative AI Lens\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Архитектурное руководство AWS для рабочих нагрузок генеративного ИИ в области операционного совершенства, безопасности, надёжности, эффективности производительности, оптимизации затрат и устойчивости.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fagentic-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 Agentic AI Lens\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Опубликовано в 2026 году; охватывает архитектурные вопросы, специфичные для агентных систем, включая идентичности, инструменты, оркестрацию, человеческий надзор, надёжность, трассировку и стоимость циклов рассуждения.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1071},1791477039589,[214,219,226,232,237,244,248,252,256,300,304,308,312,340,344,348,352,356,360,408,412,416,420,424,428,432,436,440,444,448,452,456,460,464,468,472,476,480,484,488,492,496,500,531,535,539,583,587,591,639,643,647,653,657,661,665,669,673,677,681,685,689,693,697,701,705,733,737,777,781,810,814,818,822,826,830,834,838,842,882,886,890,894,931,965,969,973,983,987,991,999,1007,1015,1023,1031,1039,1047,1055,1063],{"id":215,"data":216,"type":218},"intro",{"text":217},"\u003Cstrong>Архитектор AI-решений\u003C\u002Fstrong> переводит бизнес- или продуктовую потребность в архитектуру конкретного AI-решения. Роль определяет границы системы и значимые решения по логике приложения, авторитетным данным, поиску и контексту, моделям и провайдерам, инструментам или агентам, идентичности и разрешениям, безопасности, среде выполнения и развёртыванию, наблюдаемости, оценке, стоимости и операционному поведению. Это не просто выбор модели или промпт-инжиниринг: архитектурная ответственность состоит в том, чтобы всё решение было реализуемым, управляемым, тестируемым и эксплуатируемым.","paragraph",{"id":220,"data":221,"type":225},"direct",{"body":222,"title":223,"variant":224},"\u003Cstrong>Архитектор AI-решений проектирует полное AI-решение, а не только AI-модель.\u003C\u002Fstrong> Роль связывает требования и нефункциональные требования с архитектурными решениями, компонует необходимые слои приложения, данных, моделей, инструментов и среды выполнения, делает границы доверия и отказов явными и определяет, как реализованная система будет проверяться и эксплуатироваться.","Прямой ответ","info","callout",{"id":227,"data":228,"type":225},"role-note",{"body":229,"title":230,"variant":231},"\u003Cstrong>Архитектор AI-решений — это практическое обозначение роли, а не универсально стандартизированное название должности.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 стандартизирует понятия для описаний архитектуры; он не определяет эту должностную роль. Организации могут распределять обязанности между несколькими людьми. В этой статье термин означает архитектурную ответственность за одно конкретное AI-решение или рабочую нагрузку.","Примечание о терминологии","note",{"id":233,"data":234,"type":225},"version-note",{"body":235,"title":236,"variant":231},"Изложенные здесь архитектурные принципы намеренно не привязаны к вендорам, тогда как актуальные рекомендации вендоров используются как свидетельства реализации. NIST AI RMF 1.0 в настоящее время пересматривается; NIST AI 600-1 остаётся опубликованным профилем генеративного ИИ. Упоминаемые ниже рекомендации Microsoft и AWS отражают текущие производственные вопросы, такие как идентичность, границы данных, абстракция моделей, безопасность, наблюдаемость, оценка, надёжность и стоимость.","Примечание об актуальных источниках — 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>. Архитектор AI-решений работает по всей этой цепочке, взаимодействуя с продуктом, инженерией, данными, безопасностью, инфраструктурой, управлением и предметными специалистами.",{"id":257,"data":258,"type":299},"solution-vs-model",{"rows":259,"title":290,"layout":291,"columns":292},[260,266,272,278,284],{"id":261,"label":262,"values":263},"m1","Возможность",{"model":264,"solution":265},"Which model can generate or reason well enough?","Which combination of model, data, application logic, retrieval, tools and controls produces the required behavior?",{"id":267,"label":268,"values":269},"m2","Данные",{"model":270,"solution":271},"What context can fit in the prompt?","What is authoritative, who may access it, how is it retrieved, versioned, filtered and cited?",{"id":273,"label":274,"values":275},"m3","Безопасность",{"model":276,"solution":277},"Does the provider offer security features?","What are the trust boundaries, identities, permissions, secrets, data flows and failure containment mechanisms?",{"id":279,"label":280,"values":281},"m4","Эксплуатация",{"model":282,"solution":283},"What is the token latency?","How is the complete workload deployed, observed, evaluated, recovered, versioned and cost-controlled?",{"id":285,"label":286,"values":287},"m5","Изменение",{"model":288,"solution":289},"Can we switch models?","Which dependencies are abstracted, what changes require an ADR, and how do we validate that a replacement still meets requirements?","Решение шире, чем модель","table",[293,296],{"id":294,"label":295},"model","Вопрос, ориентированный на модель",{"id":297,"label":298},"solution","Вопрос архитектуры решения","comparison",{"id":301,"data":302,"type":42},"h-simple",{"text":303,"level":242},"Простейший пример",{"id":305,"data":306,"type":218},"p-simple-1",{"text":307},"Представьте, что компания хочет создать внутреннего ассистента, который отвечает на вопросы техников по руководствам по обслуживанию и рабочим процедурам. Видимая функция звучит просто: введите вопрос и получите ответ с источниками.",{"id":309,"data":310,"type":218},"p-simple-2",{"text":311},"Архитектурный вопрос гораздо шире. Какие документы являются авторитетными? Как аутентифицируются пользователи? Должен ли поиск учитывать разрешения отдела или площадки? Разрешено ли ответу использовать только найденные доказательства? Какая модель допустима для данной классификации данных? Может ли облачный провайдер получать содержимое? Что происходит, когда поиск ничего не находит? Как формируются ссылки на источники? Как оценивается качество ответа? Какие задержка и стоимость приемлемы? Кто может видеть логи и что в них можно хранить?",{"id":313,"data":314,"type":339},"simple-flow",{"steps":315,"title":337,"orientation":338},[316,319,322,325,328,331,334],{"label":317,"description":318},"1. Определите результат","Уточните пользователя, бизнес-ценность, границу задачи и то, что означает успешный ответ или действие.",{"label":320,"description":321},"2. Зафиксируйте требования","Сделайте явными функциональные требования, нефункциональные требования, ограничения, правила работы с данными, допустимый риск и критерии приёмки.",{"label":323,"description":324},"3. Установите границы","Определите пользователей, идентичности, приложения, авторитетные данные, зависимости от моделей и провайдеров, инструменты, внешние системы и зоны доверия.",{"label":326,"description":327},"4. Спроектируйте архитектуру","Выберите паттерны данных и поиска, модели, оркестрации, инструментов, разрешений, среды выполнения, развёртывания, отказоустойчивости и наблюдаемости.",{"label":329,"description":330},"5. Зафиксируйте значимые решения","Сохраните архитектурные выборы, альтернативы, компромиссы и последствия, чтобы последующие изменения оставались понятными.",{"label":332,"description":333},"6. Реализуйте и интегрируйте","Превратите архитектуру в код приложения, API, политики, инфраструктуру, рабочие процессы и операционные средства контроля.",{"label":335,"description":336},"7. Проверяйте и эксплуатируйте","Тестируйте качество, безопасность, надёжность, стоимость и результаты для пользователей; наблюдайте за реальной рабочей нагрузкой и возвращайте свидетельства в решения.","От потребности к эксплуатируемому AI-решению","auto","processFlow",{"id":341,"data":342,"type":42},"h-where-simple-stops",{"text":343,"level":242},"Где заканчивается простой пример",{"id":345,"data":346,"type":218},"p-stop-1",{"text":347},"Прототип часто может пропустить ту архитектуру, без которой не обойтись в продакшене. Разработчик может жёстко задать одного провайдера, использовать общий API-ключ, поместить все документы в один индекс, выполнять поиск без фильтрации по контексту пользователя, логировать промпты дословно и оценивать качество вручную. Это может продемонстрировать осуществимость, но не создаёт производственную архитектуру.",{"id":349,"data":350,"type":218},"p-stop-2",{"text":351},"Продакшен вводит ограничения, которые взаимодействуют: изоляция арендаторов или пользователей, конфиденциальность, резидентность данных, пропускная способность, задержка, стоимость, квоты провайдеров, поведение при отказах, аудируемость, изменения версий моделей, качество поиска, разрешения инструментов, реагирование на инциденты и жизненный цикл развёртывания. Задача архитектора — не максимизировать каждое качество сразу, а сделать компромиссы явными и спроектировать решение, удовлетворяющее фактическому набору приоритетов.",{"id":353,"data":354,"type":42},"h-responsibility-map",{"text":355,"level":242},"Карта архитектурной ответственности",{"id":357,"data":358,"type":218},"p-resp-intro",{"text":359},"Точное распределение зависит от организации, но приведённая ниже карта отражает повторяющиеся обязанности архитектуры AI на уровне решения. Архитектор может лично не реализовывать каждый слой; ответственность состоит в том, чтобы слои согласованно сочетались, а критические решения оставались прослеживаемыми.",{"id":361,"data":362,"type":291},"responsibility-table",{"content":363,"stretched":43,"withHeadings":14},[364,368,372,376,380,384,388,392,396,400,404],[365,366,367],"Область архитектуры","Вопросы, которые должен решить архитектор AI-решения","Типичные результаты",[369,370,371],"Результат и область охвата","Кто пользователь? Какая задача входит в область охвата? Что система не должна делать? Что считается успехом?","Контекст решения, границы возможностей, критерии приемки",[373,374,375],"Требования и нефункциональные требования","Какие ограничения по качеству, безопасности, доступности, задержке, стоимости, размещению данных и соответствию применимы?","Карта требований, нефункциональные требования, ограничения, критерии валидации",[377,378,379],"Приложение и оркестрация","Где заканчивается детерминированная логика приложения и начинается поведение AI? Как координируются рабочие процессы?","Модель компонентов, API, границы оркестрации, пути отказов",[381,382,383],"Авторитетные данные и извлечение","Что является источником истины? Как данные поступают, авторизуются, извлекаются, фильтруются, ранжируются и цитируются?","Потоки данных, архитектура извлечения, метаданные и правила авторизации",[385,386,387],"Уровень модели и провайдера","Какие возможности требуются? Какие ограничения провайдера\u002Fсреды выполнения важны? Что следует абстрагировать?","Решение о модели\u002Fпровайдере, политика маршрутизации\u002Fрезервирования, граница абстракции",[389,390,391],"Инструменты и агенты","Какие действия может выполнять система? Какие действия требуют одобрения? Как обеспечиваются идентификация и разрешения инструментов?","Контракты инструментов, границы агентов, правила одобрения и минимальных привилегий",[393,394,395],"Идентификация и безопасность","Какие человеческие и машинные идентификаторы существуют? Где хранятся секреты? Какие границы доверия пересекаются?","Модель угроз\u002Fграниц доверия, распространение идентификаторов, проектирование секретов и авторизации",[397,398,399],"Среда выполнения и развертывание","Где выполняются компоненты? Что является локальным, облачным, граничным или гибридным? Какие предположения о сети и доступности существуют?","Представление развертывания, топология среды выполнения, решения по окружению и связности",[401,402,403],"Оценка и наблюдаемость","Как измеряется качество до и после выпуска? Какие трассировки, метрики, журналы и доказательства необходимы?","План оценки, телеметрия, журнал аудита, шлюзы выпуска",[405,406,407],"Эксплуатация и изменения","Как изменяются, откатываются и поддерживаются версии моделей\u002Fподсказок\u002Fконфигурации\u002Fданных?","Операционная модель, управление жизненным циклом, ADR, инструкции, правила изменений",{"id":409,"data":410,"type":42},"h-requirements",{"text":411,"level":241},"1. Превратите потребность продукта в архитектурные требования",{"id":413,"data":414,"type":218},"p-requirements-1",{"text":415},"AI-архитектура начинается до выбора модели. Сначала архитектор определяет, чего должно достичь решение и при каких ограничениях. Это включает функциональное поведение, но также нефункциональные требования и политики, которые сужают пространство проектирования: безопасность, надежность, задержка, конфиденциальность, размещение данных, сопровождаемость, стоимость и операционная поддержка.",{"id":417,"data":418,"type":218},"p-requirements-2",{"text":419},"Здесь важно различие из A02: требование вроде «неавторизованные пользователи не должны извлекать документы с ограниченным доступом» не является архитектурным решением. Это движущий фактор. Решения о распространении идентификаторов, секционировании индекса, фильтрации метаданных, границах API и обеспечении авторизации — это архитектурные ответы, которые позже должны быть проверены.",{"id":421,"data":422,"type":42},"h-data",{"text":423,"level":241},"2. Проектируйте авторитетные данные, извлечение и контекст",{"id":425,"data":426,"type":218},"p-data-1",{"text":427},"AI-системы часто терпят неудачу на границе между поведением модели и корпоративной истиной. Архитектор должен определить, какие источники являются авторитетными, что означают свежесть и происхождение данных, как контроль доступа достигает извлечения и как извлеченные доказательства становятся контекстом модели. Векторная база данных, модель эмбеддингов или библиотека RAG сами по себе не являются архитектурой.",{"id":429,"data":430,"type":218},"p-data-2",{"text":431},"Текущие рекомендации Microsoft по AI-нагрузкам явно устанавливают такое же разделение: код приложения не должен обходить границы доступа к данным; контекст пользователя или арендатора должен распространяться на извлечение и фильтрацию; данные для обоснования должны быть спроектированы для поиска, одновременно соответствуя требованиям безопасности и соответствия.",{"id":433,"data":434,"type":42},"h-model",{"text":435,"level":241},"3. Рассматривайте модели и провайдеров как зависимости, а не как всю систему",{"id":437,"data":438,"type":218},"p-model-1",{"text":439},"Выбор модели важен, но он должен определяться требуемыми возможностями и ограничениями. Архитектор учитывает качество рассуждений или генерации, модальность, ограничения контекста, задержку, обработку данных, место развертывания, доступность провайдера, стоимость, наблюдаемость и риск замены.",{"id":441,"data":442,"type":218},"p-model-2",{"text":443},"Абстракция провайдера не является автоматически «лучшей архитектурой». Она добавляет инженерные затраты и может скрывать возможности, специфичные для провайдера. Она оправдана, когда переносимость, резервирование, разделение политик или маршрутизация между несколькими провайдерами являются явным требованием. В противном случае прямая интеграция может быть лучшим решением. Смысл в том, чтобы сделать компромисс осознанным.",{"id":445,"data":446,"type":42},"h-tools",{"text":447,"level":241},"4. Проектируйте инструменты, действия и границы агентов",{"id":449,"data":450,"type":218},"p-tools-1",{"text":451},"Когда AI-система может вызывать инструменты, изменять данные, отправлять сообщения, выполнять код или управлять бизнес-системами, архитектурный риск меняется. Доступ к инструментам требует собственной модели идентификации и авторизации. Способность модели запросить действие не равна разрешению на его выполнение.",{"id":453,"data":454,"type":218},"p-tools-2",{"text":455},"Для агентных нагрузок текущие рекомендации AWS подчеркивают дополнительные измерения, такие как идентификаторы агентов, доступ к инструментам, оркестрация, человеческий надзор, трассировка, обработка сбоев и стоимость итеративных циклов рассуждения. Это вопросы решения, даже когда фреймворк скрывает часть механики реализации.",{"id":457,"data":458,"type":42},"h-security",{"text":459,"level":241},"5. Сделайте границы доверия и разрешения явными",{"id":461,"data":462,"type":218},"p-security-1",{"text":463},"Производственное AI-решение имеет несколько границ доверия: браузер или клиент, серверная часть приложения, AI-оркестрация, службы извлечения\u002Fданных, провайдеры моделей, API инструментов, локальные среды выполнения и внешние системы. Каждая граница должна отвечать: кто вызывает, от чьего имени, с какими учетными данными, для какого ресурса, с каким журналом аудита и с каким ограничением последствий сбоя?",{"id":465,"data":466,"type":218},"p-security-2",{"text":467},"Безопасность нельзя откладывать на «ограждение» вокруг модели. Рекомендации Microsoft по AI-нагрузкам явно размещают безопасность на всех архитектурных уровнях и требуют управления идентификацией\u002Fдоступом, защиты данных, контроля содержимого и безопасности жизненного цикла. NIST также рассматривает управление и управление рисками как непрерывные на протяжении жизненного цикла AI.",{"id":469,"data":470,"type":42},"h-runtime",{"text":471,"level":241},"6. Решите, где система фактически работает",{"id":473,"data":474,"type":218},"p-runtime-1",{"text":475},"«Локальный AI», «облачный AI» и «гибридный AI» являются архитектурными утверждениями только тогда, когда пути выполнения и данных точны. Локальный процесс на рабочем столе все еще может вызывать облачную модель. Приложение, размещенное в облаке, может извлекать данные из локального источника. Решение с воздушным зазором имеет совершенно иные ограничения по обновлению, распространению моделей и наблюдаемости.",{"id":477,"data":478,"type":218},"p-runtime-2",{"text":479},"Поэтому архитектор разделяет \u003Cstrong>среду выполнения\u003C\u002Fstrong>, \u003Cstrong>среду инференса\u003C\u002Fstrong>, \u003Cstrong>расположение данных\u003C\u002Fstrong> и \u003Cstrong>плоскость управления\u003C\u002Fstrong>. Их смешение создаёт ложные предположения о безопасности и развёртывании.",{"id":481,"data":482,"type":42},"h-eval",{"text":483,"level":241},"7. Определите оценку, наблюдаемость и операционную приёмку",{"id":485,"data":486,"type":218},"p-eval-1",{"text":487},"Поведение ИИ частично недетерминировано, поэтому определение релиза не может опираться только на обычные модульные тесты. Архитектуре нужна измеримая приёмка: успешность задачи, обоснованность или корректность цитирования там, где это важно, поведение отказов, безопасность инструментов, задержка, стоимость, надёжность и тесты безопасности. Точные метрики зависят от сценария использования.",{"id":489,"data":490,"type":218},"p-eval-2",{"text":491},"Текущее руководство Microsoft Well-Architected для ИИ рассматривает мониторинг как непрерывный и применяет его к поведению модели, промптам\u002Fответам, аномалиям, безопасности и контрольным точкам качества в продакшене. AWS аналогично рассматривает наблюдаемость, управление жизненным циклом и прослеживаемость моделей\u002Fпромптов как вопросы операционной архитектуры.",{"id":493,"data":494,"type":42},"h-artifacts",{"text":495,"level":242},"Что должна создавать эта роль?",{"id":497,"data":498,"type":218},"p-artifacts-1",{"text":499},"Архитектура — это не презентация. Полезные результаты — это артефакты, которые позволяют инженерам, безопасности, продукту и операциям принимать согласованные решения и позже понимать, почему система существует в текущем виде.",{"id":501,"data":502,"type":291},"artifacts-table",{"content":503,"stretched":43,"withHeadings":14},[504,507,510,513,516,519,522,525,528],[505,506],"Артефакт","Назначение",[508,509],"Контекст и границы решения","Показывает пользователей, внешние системы, основные обязанности и то, что вне области",[511,512],"Карта требований\u002FНФТ","Связывает потребность продукта и ограничения с архитектурной работой и валидацией",[514,515],"Представления компонентов и потоков данных","Показывает приложение, данные\u002Fпоиск, модель, инструменты, идентичность и взаимодействия среды выполнения",[517,518],"Модель доверия и разрешений","Делает явными идентичности, секреты, авторизацию, чувствительные данные и действия с высоким риском",[520,521],"Записи архитектурных решений","Сохраняет значимые выборы, альтернативы, компромиссы, статус и последствия",[523,524],"План оценки и приёмки","Определяет доказательства, необходимые для утверждения, что решение соответствует ожиданиям по качеству и безопасности",[526,527],"Представление развёртывания и эксплуатации","Определяет среды, расположения среды выполнения, наблюдаемость, откат, инциденты и обязанности жизненного цикла",[529,530],"Ссылки прослеживаемости","Связывает требования, решения, работу по реализации, тесты и операционные доказательства",{"id":532,"data":533,"type":42},"h-tradeoffs",{"text":534,"level":242},"Работа — это в основном компромиссы, а не выбор «лучших практик»",{"id":536,"data":537,"type":218},"p-tradeoffs-1",{"text":538},"Архитектура существует потому, что желаемые качества конфликтуют. Более дешёвая модель может снизить качество. Более способная модель может увеличить задержку или ограничения управления данными. Агрессивное кэширование может улучшить стоимость и скорость, усложняя актуальность. Более автономные агенты могут снизить человеческие усилия, увеличивая радиус поражения и требования к аудиту.",{"id":540,"data":541,"type":291},"tradeoff-table",{"content":542,"stretched":43,"withHeadings":14},[543,548,553,558,563,568,573,578],[544,545,546,547],"Решение","Потенциальная выгода","Потенциальная стоимость \u002F риск","Архитектурный вопрос",[549,550,551,552],"Управляемая облачная модель","Быстрое внедрение, сильные управляемые возможности","Внешняя зависимость, ограничения по данным и стоимости","Допускает ли рабочая нагрузка путь провайдера\u002Fданных и соответствует ли потребностям устойчивости?",[554,555,556,557],"Локальный\u002Fсамостоятельный инференс","Контроль, офлайн\u002Fприватные варианты","Оборудование, операции, бремя жизненного цикла модели","Оправдывает ли выгода контроля операционную ответственность?",[559,560,561,562],"Интеграция с одним провайдером","Проще реализация, полные возможности провайдера","Более высокая концентрация переключения\u002Fотказов","Действительно ли требуется переносимость или резервный вариант?",[564,565,566,567],"Абстракция провайдера","Переносимость, маршрутизация и разделение политик","Риск наименьшего общего знаменателя, больше кода\u002Fтестов","Какие различия должны оставаться видимыми, а не абстрагированными?",[569,570,571,572],"Большой контекст","Больше информации на запрос","Задержка, стоимость, размывание внимания, поверхность утечки","Следует ли извлекать\u002Fфильтровать данные вместо постоянной инъекции?",[574,575,576,577],"Мощные инструменты \u002F автономность","Больше сквозной автоматизации","Более высокие привилегии и радиус поражения при сбое","Какие действия требуют минимальных привилегий, подтверждения или одобрения человеком?",[579,580,581,582],"Строгая валидация и логирование","Лучшие доказательства и операции","Задержка, хранение, конфиденциальность и сложность","Какие доказательства требуются для этого уровня риска?",{"id":584,"data":585,"type":42},"h-adjacent",{"text":586,"level":242},"Чем это отличается от смежных ролей?",{"id":588,"data":589,"type":218},"p-adjacent-intro",{"text":590},"Названия должностей сильно пересекаются в разных компаниях. Полезное различие — это \u003Cstrong>объём архитектурной ответственности\u003C\u002Fstrong>, а не ярлык отдела кадров.",{"id":592,"data":593,"type":299},"role-comparison",{"rows":594,"title":631,"layout":291,"columns":632},[595,601,607,613,619,625],{"id":596,"label":597,"values":598},"r1","Архитектор ИИ-решений",{"role":599,"focus":600},"One concrete AI-enabled solution\u002Fworkload","How requirements, data, models, tools, security, runtime and operations fit together to deliver the target outcome",{"id":602,"label":603,"values":604},"r2","Архитектор ИИ-платформы",{"role":605,"focus":606},"Reusable AI platform capabilities across many solutions","Shared provider gateways, model access, identity, evaluation, retrieval services, observability, deployment patterns and developer experience",{"id":608,"label":609,"values":610},"r3","Корпоративный архитектор ИИ",{"role":611,"focus":612},"Organization\u002Fportfolio-level target architecture","Capability landscape, governance, integration principles, shared platforms, standards, sourcing and strategic constraints across domains",{"id":614,"label":615,"values":616},"r4","Инженер по ИИ \u002F МО",{"role":617,"focus":618},"Implementation of AI\u002FML behavior and pipelines","Models, data, inference, evaluation, application logic and engineering tasks within the architecture",{"id":620,"label":621,"values":622},"r5","Архитектор по безопасности",{"role":623,"focus":624},"Security architecture across systems","Threats, identity, authorization, data protection, controls, assurance and compliance boundaries",{"id":626,"label":627,"values":628},"r6","Руководитель продукта \u002F поставки",{"role":629,"focus":630},"Outcome, scope, prioritization and delivery system","Why\u002Fwhat to build, sequencing, stakeholders, milestones, acceptance and value realization","Смежные роли отвечают на разные основные вопросы",[633,636],{"id":634,"label":635},"role","Роль",{"id":637,"label":638},"focus","Основной фокус архитектуры",{"id":640,"data":641,"type":218},"p-adjacent-2",{"text":642},"В небольшой продуктовой команде один человек может охватывать несколько из этих областей. В крупном предприятии это могут быть отдельные роли с формальными советами по проверке. Архитектурная ответственность не исчезает при смене названия.",{"id":644,"data":645,"type":42},"h-implementation",{"text":646,"level":242},"Доказательства реализации: как эти границы проявляются в моей собственной работе",{"id":648,"data":649,"type":225},"implementation-boundary",{"body":650,"title":651,"variant":652},"Примеры ниже — это \u003Cstrong>оригинальные доказательства реализации\u002Fпроекта\u003C\u002Fstrong>. Они показывают, как я разделял потребность продукта, требования, архитектуру, среду выполнения, модель\u002Fпровайдера, разрешения и валидацию в реальной проектной работе. Они не утверждают, что каждая организация должна использовать ту же структуру, и не подразумевают внедрение заказчиком или развёртывание корпоративного масштаба.","Доказательства реализации, а не универсальное правило","success",{"id":654,"data":655,"type":42},"h-senseflow",{"text":656,"level":241},"SenseFlow: потребность → требования → архитектура → валидация",{"id":658,"data":659,"type":218},"p-senseflow-1",{"text":660},"В проекте SenseFlow Source of Truth технология явно подчинена видению продукта. Структура разработки движется от проблемы и видения продукта через потребности пользователей, ценность, область, эпики, истории и критерии приёмки к архитектуре, реализации, валидации и итерации.",{"id":662,"data":663,"type":218},"p-senseflow-2",{"text":664},"Требования спроектированы так, чтобы прослеживаться от Цели продукта → Возможности → Эпика → Пользовательской истории → Критериев приёмки → Технических задач. Где это практически осуществимо, они включают функциональные требования, нефункциональные требования, зависимости, риски, допущения, критерии приёмки и методы валидации. Значимые решения сохраняют решение, причину, альтернативы, компромиссы, статус и дату\u002Fверсию.",{"id":666,"data":667,"type":218},"p-senseflow-3",{"text":668},"Это архитектурная работа до выбора конкретного AI-фреймворка или модели: она защищает связь между замыслом продукта и техническими решениями и делает последующие изменения проверяемыми, а не неявными.",{"id":670,"data":671,"type":42},"h-client",{"text":672,"level":241},"Aaasaasa AI Client: разделяйте концепции до их интеграции",{"id":674,"data":675,"type":218},"p-client-1",{"text":676},"Aaasaasa AI Client представляет пример более низкого уровня реализации. Его AI Hub намеренно разделяет \u003Cstrong>агента\u002Fклиента\u003C\u002Fstrong>, \u003Cstrong>провайдера\u003C\u002Fstrong>, \u003Cstrong>модель\u003C\u002Fstrong>, \u003Cstrong>расположение подключения\u002Fсреды выполнения\u003C\u002Fstrong>, \u003Cstrong>разрешения\u003C\u002Fstrong> и \u003Cstrong>веб-клиент\u003C\u002Fstrong>. Локальная среда выполнения не предполагает локальный вывод, а разрешения рассматриваются как политика среды выполнения\u002Fинструментов, а не как свойство модели.",{"id":678,"data":679,"type":218},"p-client-2",{"text":680},"Архитектура десктопного приложения также определяет границу доверия: рендерер Nuxt не является доверенным по отношению к главному процессу Electron. Узкий preload и валидированный IPC опосредуют доступ к AI-сервисам, настройкам, зашифрованным секретам, сервисам рабочего пространства\u002Fданных и средам выполнения. Облачные учётные данные остаются в привилегированном главном процессе; код рендерера получает нормализованное состояние вместо необработанных секретов или неограниченного доступа к операционной системе.",{"id":682,"data":683,"type":218},"p-client-3",{"text":684},"Решения о маршрутизации также являются архитектурными. Реализация не выполняет неявный откат с локального маршрута на платный облачный вывод; облачный маршрут требует явного подтверждения. Direct Chat по умолчанию не имеет инструментов файловой системы или оболочки, тогда как выполнение агента применяет выбранное рабочее пространство и профиль разрешений. Это решения уровня решения о доверии, стоимости, выполнении и ожиданиях пользователя — а не функции модели.",{"id":686,"data":687,"type":42},"h-current-frameworks",{"text":688,"level":242},"Как современные архитектурные фреймворки поддерживают этот более широкий охват",{"id":690,"data":691,"type":218},"p-frameworks-1",{"text":692},"ISO\u002FIEC\u002FIEEE 42010:2022 предоставляет общую дисциплину для описаний архитектуры в программном обеспечении, системах и предприятиях. Он намеренно шире, чем AI, и не предписывает единственный метод архитектурирования или название должности. Это делает его полезным здесь как границу: архитектура AI-решения — это всё ещё архитектура, с concerns заинтересованных сторон, множественными представлениями и значимыми отношениями, которые должны быть выражены ясно.",{"id":694,"data":695,"type":218},"p-frameworks-2",{"text":696},"NIST AI RMF 1.0 описывает управление рисками AI через \u003Cstrong>Govern, Map, Measure и Manage\u003C\u002Fstrong> и подчёркивает, что управление рисками должно быть непрерывным на протяжении жизненного цикла AI-системы. Профиль генеративного AI (NIST AI 600-1) адаптирует этот фреймворк к рискам GAI и организационным приоритетам. Это подтверждает, что архитектура не может ограничиваться функциональной производительностью модели.",{"id":698,"data":699,"type":218},"p-frameworks-3",{"text":700},"Текущее руководство Microsoft Azure Well-Architected AI разделяет concerns проектирования приложений, платформы приложений, данных обучения, данных заземления и платформы данных и неоднократно связывает их с надёжностью, безопасностью, операционным совершенством, производительностью и стоимостью. Линзы AWS Generative AI и Agentic AI аналогично рассматривают наблюдаемость, безопасность, надёжность, жизненный цикл модели\u002Fинструмента, стоимость и человеческий надзор как архитектурные concerns.",{"id":702,"data":703,"type":42},"h-misconceptions",{"text":704,"level":242},"Распространённые заблуждения",{"id":706,"data":707,"type":291},"misconceptions-table",{"content":708,"stretched":43,"withHeadings":14},[709,712,715,718,721,724,727,730],[710,711],"Заблуждение","Исправление",[713,714],"«Архитектор выбирает LLM.»","Выбор модели — это одно решение внутри более крупной архитектуры решения.",[716,717],"«Промпт-инжиниринг — это архитектура.»","Промпты влияют на поведение, но они не определяют идентичность, доступ к данным, границы доверия, развёртывание, разрешения инструментов или операции.",[719,720],"«RAG решает проблему корпоративных знаний.»","Извлечение — это лишь одна подсистема; авторизация, происхождение, актуальность, доказательства, индексация, оценка и управление источниками всё ещё требуют проектирования.",[722,723],"«Локальная среда выполнения означает приватный\u002Fлокальный AI.»","Расположение среды выполнения, вывода, данных и плоскости управления — это отдельные архитектурные свойства.",[725,726],"«Если поставщик предлагает guardrails, безопасность обеспечена.»","Безопасность охватывает идентичность, авторизацию, секреты, потоки данных, инструменты, логирование, развёртывание, человеческое одобрение и границы провайдера.",[728,729],"«Архитектор должен написать каждый компонент.»","Практическая реализация может улучшить архитектурное качество, но роль определяется интегрированной ответственностью за решения, а не личным написанием кода каждого слоя.",[731,732],"«Диаграмма архитектуры доказывает готовность к продакшену.»","Готовность требует реализованных контролей и доказательств валидации по качеству, безопасности, операциям и бизнес-приёмке.",{"id":734,"data":735,"type":42},"h-failures",{"text":736,"level":242},"Режимы отказа, которые архитектор AI-решений должен предотвращать",{"id":738,"data":739,"type":291},"failures-table",{"content":740,"stretched":43,"withHeadings":14},[741,745,749,753,757,761,765,769,773],[742,743,744],"Режим отказа","Почему это происходит","Архитектурная коррекция",[746,747,748],"Проектирование от модели","Многообещающая демонстрация модели становится чертежом системы","Начинайте с результата, ограничений и валидации; выбирайте модель внутри этой рамки",[750,751,752],"Разрешения прототипа в продакшене","Общие учётные данные и широкий доступ сохраняются после PoC","Определите распространение идентичности, наименьшие привилегии, области инструментов и границы одобрения на раннем этапе",[754,755,756],"Извлечение без авторизации","Качество поиска проектируется до правил доступа к данным","Передавайте контекст пользователя\u002Fарендатора в извлечение и применяйте авторизацию на границах доступа к данным",[758,759,760],"Неявные допущения о провайдере\u002Fсреде выполнения","«Локальный», «облачный» и «офлайн» используются неточно","Документируйте расположение среды выполнения, вывода, данных и плоскости управления отдельно",[762,763,764],"Отсутствие контракта отказа","Проектируется только успешный путь, но не поведение при отказе\u002Fоткате\u002Fошибке","Определите поведение при пустом извлечении, недоступности модели, сбое инструмента и отказе политики",[766,767,768],"Оценка после реализации","Качество оценивается вручную ближе к запуску","Определите измеримые критерии приёмки и репрезентативные наборы оценки до фиксации архитектуры",[770,771,772],"Непрослеживаемое изменение","Модели, промпты, извлечение или разрешения меняются без архитектурной истории","Версионируйте критическую конфигурацию и фиксируйте значимые решения\u002Fдоказательства валидации",[774,775,776],"Операции рассматриваются только как инфраструктура","Поведение AI не наблюдаемо после развёртывания","Проектируйте трассировки, метрики качества, события безопасности, телеметрию стоимости и откат вместе",{"id":778,"data":779,"type":42},"h-decision-framework",{"text":780,"level":242},"Практическая последовательность решений",{"id":782,"data":783,"type":339},"decision-flow",{"steps":784,"title":809,"orientation":338},[785,788,791,794,797,800,803,806],{"label":786,"description":787},"Результат","Определите пользовательский\u002Fбизнес-результат и явные не-цели.",{"label":789,"description":790},"Доказательства и ограничения","Определите авторитетные данные, политики, нефункциональные требования, риски и условия приёмки.",{"label":792,"description":793},"Граница системы","Сопоставьте пользователей, идентичности, приложения, данные, модели\u002Fпровайдеров, инструменты и внешние системы.",{"label":795,"description":796},"Варианты архитектуры","Сравните паттерны для извлечения, доступа к модели, оркестрации, развёртывания, разрешений, оценки и наблюдаемости.",{"label":798,"description":799},"Решения о компромиссах","Выберите значимые варианты и сохраните обоснование, альтернативы и последствия.",{"label":801,"description":802},"Контракты реализации","Преобразуйте решения в API, схемы, правила разрешений, определения развёртывания и инженерные задачи.",{"label":804,"description":805},"Валидация","Протестируйте реализованную систему на соответствие исходным функциональным и нефункциональным требованиям.",{"label":807,"description":808},"Операционная обратная связь","Используйте производственные доказательства, инциденты, метрики качества и сигналы стоимости\u002Fбезопасности для запуска контролируемых изменений.","Последовательность решений архитектуры AI-решения",{"id":811,"data":812,"type":42},"h-edge",{"text":813,"level":242},"Краевые случаи и ограничения роли",{"id":815,"data":816,"type":218},"p-edge-1",{"text":817},"Некоторые AI-продукты определяются обучением моделей, научными экспериментами или специализированным оборудованием. В таких случаях наука о моделях\u002Fданных и архитектура ML-систем могут стать гораздо глубже, чем показанная здесь карта уровня решения. Архитектор AI-решений всё ещё нуждается в интеграции и операционных границах, но специализированная архитектура может владеть самой платформой обучения.",{"id":819,"data":820,"type":218},"p-edge-2",{"text":821},"На другом полюсе простая интеграция SaaS может не оправдывать выделенного архитектора. Старший инженер или технический руководитель продукта может нести ту же архитектурную ответственность. Полезная проверка — не должность, а то, принимаются ли значимые кросс-слойные решения осознанно и подтверждаются ли они.",{"id":823,"data":824,"type":218},"p-edge-3",{"text":825},"Регулируемые, суверенные, изолированные, критичные для безопасности, высокоавтономные или мультитенантные системы также смещают центр тяжести. Идентификация, изоляция, резидентность данных, гарантии, механизмы обновления, человеческий надзор и аудируемость могут доминировать над качеством модели в архитектуре.",{"id":827,"data":828,"type":42},"h-change-answer",{"text":829,"level":242},"Что могло бы изменить этот ответ?",{"id":831,"data":832,"type":218},"p-change-1",{"text":833},"Точная граница ответственности меняется, когда архитектура переходит от одного приложения к переиспользуемой платформе или к общеорганизационной целевой архитектуре. Именно поэтому \u003Cstrong>AI Platform Architect\u003C\u002Fstrong> и \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> заслуживают отдельного канонического рассмотрения, а не объединения в эту роль.",{"id":835,"data":836,"type":218},"p-change-2",{"text":837},"Технологические изменения также важны. Новые возможности моделей, протоколы, локальные среды выполнения и управляемые сервисы могут устранить часть работы по реализации, одновременно создавая новые границы доверия или эксплуатации. Устойчивая ответственность — понимать эти изменения как изменения системы, а не воспринимать новый фреймворк как замену архитектуры.",{"id":839,"data":840,"type":42},"h-checklist",{"text":841,"level":242},"Чек-лист AI Solution Architect",{"id":843,"data":844,"type":291},"checklist-table",{"content":845,"stretched":43,"withHeadings":14},[846,849,851,854,856,859,862,865,868,871,874,877,880],[847,848],"Проверка","Вопрос",[786,850],"Явно ли определены пользовательский\u002Fбизнес-результат и граница не-целей?",[852,853],"Требования","Прослеживаются ли функциональные требования, нефункциональные требования, ограничения и критерии приемки?",[268,855],"Определены ли авторитетные источники, происхождение, актуальность, хранение и правила доступа?",[857,858],"Поиск\u002Fконтекст","Достигает ли авторизация поиска и построения контекста?",[860,861],"Модель\u002Fпровайдер","Связан ли выбор модели\u002Fпровайдера с возможностями и ограничениями, а не с предпочтениями?",[863,864],"Инструменты\u002Fагенты","Явно ли определены границы действий, разрешения, согласования и поведение при сбоях?",[866,867],"Идентификация\u002Fбезопасность","Определены ли человеческие\u002Fмашинные идентичности, секреты и границы доверия?",[869,870],"Среда выполнения","Различаются ли расположения среды выполнения, инференса, данных и плоскости управления?",[872,873],"Оценка","Есть ли измеримые доказательства качества, безопасности и приемки?",[875,876],"Наблюдаемость","Можно ли исследовать поведение в продакшене, сбои, затраты и события безопасности?",[878,879],"Изменения","Прослеживаются ли значимые архитектурные решения и замены?",[280,881],"Ясна ли ответственность за развертывание, откат, инциденты и жизненный цикл?",{"id":883,"data":884,"type":42},"h-conclusion",{"text":885,"level":242},"Заключение",{"id":887,"data":888,"type":218},"p-conclusion-1",{"text":889},"AI Solution Architect — это человек или архитектурная функция, которая превращает возможность AI в согласованную техническую систему. Ключевой навык — не знание наибольшего числа названий моделей, а связывание потребности продукта, требований, данных, архитектуры приложения, возможностей AI, безопасности, среды выполнения, поставки и валидации без потери границ между ними.",{"id":891,"data":892,"type":218},"p-conclusion-2",{"text":893},"Таким образом, сильную архитектуру AI-решения можно резюмировать так: \u003Cstrong>определить цель → установить требования и ограничения → спроектировать границы системы → сделать значимые компромиссы явными → реализовать через четкие контракты → подтвердить доказательствами → эксплуатировать и развивать осознанно.\u003C\u002Fstrong> Модель важна. Продукт — это решение.",{"id":895,"data":896,"type":895},"faq",{"items":897,"title":930},[898,902,906,910,914,918,922,926],{"id":899,"answer":900,"question":901},"faq1","AI Solution Architect переводит бизнес- или продуктовую потребность в архитектуру конкретного AI-решения, определяя, как логика приложения, данные\u002Fпоиск, модели, инструменты, идентификация, безопасность, среда выполнения, оценка и эксплуатация работают вместе.","Что такое AI Solution Architect?",{"id":903,"answer":904,"question":905},"faq2","Нет. Роли могут пересекаться, особенно в небольших командах, но AI-инженер — это прежде всего роль реализации, тогда как архитектор решения владеет или координирует кросс-слойные архитектурные решения и компромиссы для полной рабочей нагрузки.","AI Solution Architect — то же самое, что AI-инженер?",{"id":907,"answer":908,"question":909},"faq3","По определению нет, но практические знания реализации крайне ценны, поскольку архитектура AI пересекает API, данные, поиск, безопасность, среды выполнения и эксплуатационное поведение. Роль определяется архитектурной ответственностью, а не написанием каждого компонента лично.","Нужно ли AI Solution Architect уметь программировать?",{"id":911,"answer":912,"question":913},"faq4","Нет. Выбор модели — одно из решений. Продакшн-архитектура также требует границ данных и поиска, разрешений, инструментов, выбора провайдера\u002Fсреды выполнения, наблюдаемости, оценки, надежности, затрат и проектирования жизненного цикла.","Выбор LLM — главная работа?",{"id":915,"answer":916,"question":917},"faq5","AI Solution Architect фокусируется на одном конкретном решении или рабочей нагрузке. AI Platform Architect фокусируется на переиспользуемых возможностях AI и ограничениях, поддерживающих множество решений.","В чем разница между AI Solution Architect и AI Platform Architect?",{"id":919,"answer":920,"question":921},"faq6","Архитектор решения работает в масштабе приложения\u002Fрабочей нагрузки. Архитектура Enterprise AI работает в масштабе организационного портфеля, целевой архитектуры, управления, общих возможностей, принципов интеграции и стратегических ограничений.","В чем разница между AI Solution Architect и Enterprise AI Architect?",{"id":923,"answer":924,"question":925},"faq7","Это архитектурные паттерны или подсистемы внутри решения, когда требования их оправдывают. RAG обеспечивает контекст, обоснованный поиском; агенты добавляют планирование\u002Fвыполнение инструментов и, следовательно, дополнительные вопросы идентификации, разрешений, оркестрации и эксплуатации.","Где место RAG и агентов?",{"id":927,"answer":928,"question":929},"faq8","Реализация плюс доказательства валидации: функциональные тесты, результаты оценки, тесты безопасности\u002Fавторизации, измерения производительности и надежности, наблюдаемость, эксплуатационная репетиция и приемка по исходным требованиям.","Что доказывает, что архитектура работает?","AI Solution Architect — FAQ",{"id":932,"data":933,"type":932},"glossary",{"title":934,"entries":935},"Ключевые термины",[936,940,943,947,951,954,957,961],{"term":937,"anchor":938,"definition":939},"AI Solution Architect","ai-solution-architect","Архитектурная ответственность за одно конкретное AI-решение или рабочую нагрузку, объединяющая требования продукта с проектированием приложения, данных, модели, инструментов, безопасности, среды выполнения и эксплуатации.",{"term":792,"anchor":941,"definition":942},"system-boundary","Явное разделение между тем, что принадлежит решению, и пользователями, системами, провайдерами, источниками данных и средами, с которыми оно взаимодействует.",{"term":944,"anchor":945,"definition":946},"Граница доверия","trust-boundary","Точка, где данные, идентичности или управление пересекают границу между компонентами с разными допущениями доверия и поэтому требуют явных мер безопасности.",{"term":948,"anchor":949,"definition":950},"Обоснование (grounding)","grounding","Предоставление AI-модели релевантной внешней информации или доказательств, чтобы ее ответ мог основываться на источниках за пределами параметров модели.",{"term":564,"anchor":952,"definition":953},"provider-abstraction","Граница приложения, отделяющая части решения от интерфейса одной модели\u002Fпровайдера. Полезна, когда оправдана потребностями маршрутизации, переносимости или политики, но не свободна от компромиссов.",{"term":872,"anchor":955,"definition":956},"evaluation","Структурированное измерение поведения AI-нагрузки по заданным критериям приемки, включая качество выполнения задачи и соответствующие свойства безопасности, защищенности, производительности и эксплуатации.",{"term":958,"anchor":959,"definition":960},"AI Platform Architect","ai-platform-architect","Архитектурная роль, сосредоточенная на переиспользуемых возможностях AI-платформы, используемых множеством решений, а не на архитектуре одной рабочей нагрузки.",{"term":962,"anchor":963,"definition":964},"Enterprise AI Architecture","enterprise-ai-architecture","Архитектура уровня организации, координирующая возможности AI, платформы, управление, интеграцию и стратегические ограничения в рамках портфеля.",{"id":966,"data":967,"type":42},"h-related",{"text":968,"level":242},"Связанные канонические знания",{"id":970,"data":971,"type":218},"p-related-1",{"text":972},"Эта статья находится в кластере AI Architecture Foundations. Ее непосредственные основы — \u003Cstrong>Generative AI Explained: Models, Retrieval, Tools and Applications Are Not the Same Thing\u003C\u002Fstrong> и \u003Cstrong>ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing\u003C\u002Fstrong>. Смежные канонические узлы включают \u003Cstrong>Agentic AI Explained\u003C\u002Fstrong>, \u003Cstrong>Source of Truth in AI Systems\u003C\u002Fstrong>, \u003Cstrong>Vector Databases, Embeddings and Reranking\u003C\u002Fstrong>, \u003Cstrong>What Is Context Engineering?\u003C\u002Fstrong>, \u003Cstrong>RBAC vs Tenant Isolation\u003C\u002Fstrong>, \u003Cstrong>AI Platform Architect\u003C\u002Fstrong>, \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> и \u003Cstrong>AI Governance\u003C\u002Fstrong>. URL-адреса намеренно не выдумываются там, где эти узлы еще не опубликованы.",{"id":974,"data":975,"type":982},"related-rag",{"link":976,"meta":977},"https:\u002F\u002Fstajic.de\u002Fru\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works",{"image":978,"title":980,"description":981},{"url":979},"","What Is RAG? The Simplest Explanation of How It Works","Существующее каноническое объяснение stajic.de генерации с дополненной выборкой, полезное для части поиска\u002Fобоснования в архитектуре AI-решения.","linkTool",{"id":984,"data":985,"type":42},"h-sources",{"text":986,"level":242},"Первичные источники и актуальные рекомендации по архитектуре",{"id":988,"data":989,"type":218},"p-sources-note",{"text":990},"Внешние источники ниже поддерживают общие архитектурные утверждения; разделы SenseFlow и Aaasaasa AI Client являются явными доказательствами оригинального проекта\u002Fреализации. Ссылки на текущее состояние были проверены 8 октября 2026 года. NIST отмечает, что AI RMF 1.0 пересматривается, поэтому зависящие от версии ссылки на управление следует перепроверять при публикации преемника.",{"id":992,"data":993,"type":982},"src-iso-42010",{"link":994,"meta":995},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html",{"image":996,"title":997,"description":998},{"url":979},"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description","Действующий международный стандарт структуры и выражения архитектурных описаний. Он отличает архитектуру от ее описания и не предписывает один метод архитектурного проектирования, инструмент или формат записи.",{"id":1000,"data":1001,"type":982},"src-nist-rmf",{"link":1002,"meta":1003},"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework",{"image":1004,"title":1005,"description":1006},{"url":979},"NIST AI Risk Management Framework","Страница ресурсов NIST по AI RMF. По состоянию на октябрь 2026 года на ней указано, что AI RMF 1.0 пересматривается, и приведены ссылки на Generative AI Profile и связанные ресурсы.",{"id":1008,"data":1009,"type":982},"src-nist-core",{"link":1010,"meta":1011},"https:\u002F\u002Fairc.nist.gov\u002Fairmf-resources\u002Fairmf\u002F5-sec-core\u002F",{"image":1012,"title":1013,"description":1014},{"url":979},"NIST AI RMF Core — Govern, Map, Measure, Manage","Официальная презентация NIST AIRC ядра AI RMF 1.0, включая четыре функции и ориентированную на жизненный цикл структуру управления рисками.",{"id":1016,"data":1017,"type":982},"src-nist-gai",{"link":1018,"meta":1019},"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fartificial-intelligence-risk-management-framework-generative-artificial-intelligence",{"image":1020,"title":1021,"description":1022},{"url":979},"NIST AI 600-1 — Generative AI Profile","Межотраслевой профиль генеративного ИИ для AI RMF 1.0, опубликованный 26 июля 2024 года и обновлённый NIST в 2026 году.",{"id":1024,"data":1025,"type":982},"src-ms-start",{"link":1026,"meta":1027},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fget-started",{"image":1028,"title":1029,"description":1030},{"url":979},"Microsoft Azure Well-Architected — AI Workloads","Актуальное руководство по архитектуре на уровне рабочих нагрузок, охватывающее проектирование приложений ИИ, платформу приложений, данные для обучения, данные для заземления, платформу данных и вопросы готовности к эксплуатации.",{"id":1032,"data":1033,"type":982},"src-ms-app",{"link":1034,"meta":1035},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fapplication-design",{"image":1036,"title":1037,"description":1038},{"url":979},"Microsoft — Application Design for AI Workloads","Руководство по абстракции моделей и инструментов, границам доступа к данным, распространению идентичности, авторизации и разделению слоёв клиента, интеллекта, знаний и инструментов.",{"id":1040,"data":1041,"type":982},"src-ms-security",{"link":1042,"meta":1043},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fdesign-principles",{"image":1044,"title":1045,"description":1046},{"url":979},"Microsoft — Design Principles for AI Workloads","Актуальные принципы проектирования рабочих нагрузок ИИ в области надёжности, безопасности, затрат, операционного совершенства и производительности, включая ответственность за идентичность и защиту данных.",{"id":1048,"data":1049,"type":982},"src-ms-ops",{"link":1050,"meta":1051},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fmlops-genaiops",{"image":1052,"title":1053,"description":1054},{"url":979},"Microsoft — MLOps and GenAIOps for AI Workloads","Руководство по жизненному циклу в производственной среде, охватывающее мониторинг, контроль качества, поведение моделей и промптов, безопасность и операционные измерения.",{"id":1056,"data":1057,"type":982},"src-aws-genai",{"link":1058,"meta":1059},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fgenerative-ai-lens\u002F",{"image":1060,"title":1061,"description":1062},{"url":979},"AWS Well-Architected Generative AI Lens","Архитектурное руководство AWS для рабочих нагрузок генеративного ИИ в области операционного совершенства, безопасности, надёжности, эффективности производительности, оптимизации затрат и устойчивости.",{"id":1064,"data":1065,"type":982},"src-aws-agentic",{"link":1066,"meta":1067},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fagentic-ai-lens\u002F",{"image":1068,"title":1069,"description":1070},{"url":979},"AWS Well-Architected Agentic AI Lens","Опубликовано в 2026 году; охватывает архитектурные вопросы, специфичные для агентных систем, включая идентичности, инструменты, оркестрацию, человеческий надзор, надёжность, трассировку и стоимость циклов рассуждения.","2.31","Архитектор решений ИИ превращает бизнес-требования в готовую к производству систему ИИ, охватывающую данные, модели, инструменты, безопасность, среду выполнения, оценку и операции.","\u002Fuploads\u002F2026\u002F10\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs-1791476643267-1st5xz.webp","what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs-1791476643267-1st5xz","PUBLISHED","2026-10-08T12:23:00.000Z","2026-10-08T16:23:08.916Z","2026-10-08T16:31:54.093Z",{"en":1080,"de":1081,"sr":1082,"es":1083,"fr":1084,"it":1085,"ru":1086,"zh":1087},"\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u002Fde\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u002Fsr\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u002Fes\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u002Ffr\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u002Fit\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u002Fru\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u002Fzh\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs",[1089,1093,1097,1101],{"id":1090,"name":1091,"slug":1092},57,"Границы данных","data-boundaries",{"id":1094,"name":1095,"slug":1096},84,"Политики и границы данных","policy-and-data",{"id":1098,"name":1099,"slug":1100},80,"Доступ и идентичность","access-and-identity",{"id":1102,"name":1103,"slug":1104},54,"Модель угроз","threat-model",{"id":1106,"login":1107,"email":1108,"displayName":1109},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1111,1783],{"lang":1112,"title":1113,"content":1114,"contentJson":1115,"excerpt":1782},"en","What Is an AI Solution Architect? System Boundaries, Responsibilities and Trade-offs","{\"time\":1791476244367,\"blocks\":[{\"id\":\"intro\",\"type\":\"paragraph\",\"data\":{\"text\":\"An \u003Cstrong>AI Solution Architect\u003C\u002Fstrong> translates a business or product need into the architecture of a concrete AI-enabled solution. The role defines system boundaries and the significant choices across application logic, authoritative data, retrieval and context, models and providers, tools or agents, identity and permissions, security, runtime and deployment, observability, evaluation, cost and operational behavior. It is not simply model selection or prompt engineering: the architectural responsibility is to make the whole solution implementable, governable, testable and operable.\"}},{\"id\":\"direct\",\"type\":\"callout\",\"data\":{\"variant\":\"info\",\"title\":\"Direct answer\",\"body\":\"\u003Cstrong>An AI Solution Architect designs the complete AI-enabled solution, not just the AI model.\u003C\u002Fstrong> The role connects requirements and non-functional requirements to architecture decisions, composes the necessary application\u002Fdata\u002Fmodel\u002Ftool\u002Fruntime layers, makes trust and failure boundaries explicit, and defines how the implemented system will be validated and operated.\"}},{\"id\":\"role-note\",\"type\":\"callout\",\"data\":{\"variant\":\"note\",\"title\":\"Terminology note\",\"body\":\"\u003Cstrong>AI Solution Architect is a practical role label, not a universally standardized job title.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 standardizes concepts for architecture descriptions; it does not define this job role. Organizations can distribute the responsibilities across several people. In this article, the term means the architecture responsibility for one concrete AI-enabled solution or workload.\"}},{\"id\":\"version-note\",\"type\":\"callout\",\"data\":{\"variant\":\"note\",\"title\":\"Current-source note — 8 October 2026\",\"body\":\"The architecture principles here are intentionally vendor-neutral, while current vendor guidance is used as implementation evidence. NIST AI RMF 1.0 is currently under revision; NIST AI 600-1 remains the published Generative AI Profile. Microsoft and AWS guidance cited below reflects current production concerns such as identity, data boundaries, model abstraction, security, observability, evaluation, reliability and cost.\"}},{\"id\":\"toc\",\"type\":\"tableOfContents\",\"data\":{\"title\":\"Contents\",\"minLevel\":2,\"maxLevel\":3}},{\"id\":\"h-meaning\",\"type\":\"header\",\"data\":{\"text\":\"What does an AI Solution Architect actually architect?\",\"level\":2}},{\"id\":\"p-meaning-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The object of the work is the \u003Cstrong>solution\u003C\u002Fstrong>: the complete socio-technical system that turns a need into useful, controlled behavior. A model may be central to that system, but it is still only one dependency. The same model can participate in a safe internal search assistant, an unsafe over-privileged agent, a low-latency customer feature, or a high-cost prototype that cannot be operated economically. Architecture determines those differences.\"}},{\"id\":\"p-meaning-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"A useful boundary is therefore: \u003Cstrong>business outcome → requirements → system responsibilities → architecture decisions → implementation → validation → operation\u003C\u002Fstrong>. The AI Solution Architect works across this chain while collaborating with product, engineering, data, security, infrastructure, governance and domain specialists.\"}},{\"id\":\"solution-vs-model\",\"type\":\"comparison\",\"data\":{\"title\":\"The solution is wider than the model\",\"layout\":\"table\",\"columns\":[{\"id\":\"model\",\"label\":\"Model-centric question\"},{\"id\":\"solution\",\"label\":\"Solution-architecture question\"}],\"rows\":[{\"id\":\"m1\",\"label\":\"Capability\",\"values\":{\"model\":\"Which model can generate or reason well enough?\",\"solution\":\"Which combination of model, data, application logic, retrieval, tools and controls produces the required behavior?\"}},{\"id\":\"m2\",\"label\":\"Data\",\"values\":{\"model\":\"What context can fit in the prompt?\",\"solution\":\"What is authoritative, who may access it, how is it retrieved, versioned, filtered and cited?\"}},{\"id\":\"m3\",\"label\":\"Security\",\"values\":{\"model\":\"Does the provider offer security features?\",\"solution\":\"What are the trust boundaries, identities, permissions, secrets, data flows and failure containment mechanisms?\"}},{\"id\":\"m4\",\"label\":\"Operations\",\"values\":{\"model\":\"What is the token latency?\",\"solution\":\"How is the complete workload deployed, observed, evaluated, recovered, versioned and cost-controlled?\"}},{\"id\":\"m5\",\"label\":\"Change\",\"values\":{\"model\":\"Can we switch models?\",\"solution\":\"Which dependencies are abstracted, what changes require an ADR, and how do we validate that a replacement still meets requirements?\"}}]}},{\"id\":\"h-simple\",\"type\":\"header\",\"data\":{\"text\":\"The simplest example\",\"level\":2}},{\"id\":\"p-simple-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Imagine a company wants an internal assistant that answers technicians’ questions from maintenance manuals and operating procedures. The visible feature sounds simple: type a question and receive an answer with sources.\"}},{\"id\":\"p-simple-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The architecture question is much larger. Which documents are authoritative? How are users authenticated? Must retrieval respect department or site permissions? Is the answer allowed to use only retrieved evidence? Which model is acceptable for the data classification? Can a cloud provider receive the content? What happens when retrieval finds nothing? How are citations produced? How is answer quality evaluated? What latency and cost are acceptable? Who can see logs, and what may be stored in them?\"}},{\"id\":\"simple-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"From need to an operable AI solution\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"1. Define the outcome\",\"description\":\"Clarify the user, business value, task boundary and what a successful answer or action means.\"},{\"label\":\"2. Capture requirements\",\"description\":\"Make functional requirements, NFRs, constraints, data rules, risk tolerance and acceptance criteria explicit.\"},{\"label\":\"3. Establish boundaries\",\"description\":\"Identify users, identities, applications, authoritative data, model\u002Fprovider dependencies, tools, external systems and trust zones.\"},{\"label\":\"4. Design the architecture\",\"description\":\"Choose data\u002Fretrieval, model, orchestration, tool, permission, runtime, deployment, fallback and observability patterns.\"},{\"label\":\"5. Record significant decisions\",\"description\":\"Preserve architectural choices, alternatives, trade-offs and consequences so later changes remain understandable.\"},{\"label\":\"6. Implement and integrate\",\"description\":\"Turn the architecture into application code, APIs, policies, infrastructure, workflows and operational controls.\"},{\"label\":\"7. Validate and operate\",\"description\":\"Test quality, security, reliability, cost and user outcomes; monitor the real workload and feed evidence back into decisions.\"}]}},{\"id\":\"h-where-simple-stops\",\"type\":\"header\",\"data\":{\"text\":\"Where the simple example stops\",\"level\":2}},{\"id\":\"p-stop-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A proof of concept can often skip architecture that production cannot. A developer may hard-code one provider, use a shared API key, place all documents in one index, run retrieval without user-context filtering, log prompts verbatim and judge quality manually. That can demonstrate feasibility, but it does not establish a production architecture.\"}},{\"id\":\"p-stop-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Production introduces constraints that interact: tenant or user isolation, privacy, data residency, throughput, latency, cost, provider quotas, fallback behavior, auditability, model version changes, retrieval quality, tool permissions, incident response and deployment lifecycle. The architect’s job is not to maximize every quality at once; it is to make the trade-offs explicit and design a solution that satisfies the actual priority set.\"}},{\"id\":\"h-responsibility-map\",\"type\":\"header\",\"data\":{\"text\":\"Architecture responsibility map\",\"level\":2}},{\"id\":\"p-resp-intro\",\"type\":\"paragraph\",\"data\":{\"text\":\"The exact split varies by organization, but the following map captures the recurring responsibilities of solution-level AI architecture. The architect may not personally implement every layer; the responsibility is to make the layers fit together coherently and to keep the critical decisions traceable.\"}},{\"id\":\"responsibility-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Architecture area\",\"Questions the AI Solution Architect must resolve\",\"Typical outputs\"],[\"Outcome and scope\",\"Who is the user? What task is in scope? What must the system not do? What constitutes success?\",\"Solution context, capability boundary, acceptance criteria\"],[\"Requirements and NFRs\",\"What quality, security, availability, latency, cost, residency and compliance constraints apply?\",\"Requirement map, NFRs, constraints, validation criteria\"],[\"Application and orchestration\",\"Where does deterministic application logic end and AI behavior begin? How are workflows coordinated?\",\"Component model, APIs, orchestration boundaries, failure paths\"],[\"Authoritative data and retrieval\",\"What is the Source of Truth? How is data ingested, authorized, retrieved, filtered, ranked and cited?\",\"Data flows, retrieval architecture, metadata and authorization rules\"],[\"Model and provider layer\",\"Which capabilities are required? Which provider\u002Fruntime constraints matter? What should be abstracted?\",\"Model\u002Fprovider decision, routing\u002Ffallback policy, abstraction boundary\"],[\"Tools and agents\",\"What actions can the system take? Which actions require approval? How are tool identities and permissions enforced?\",\"Tool contracts, agent boundaries, approval and least-privilege rules\"],[\"Identity and security\",\"Which human and machine identities exist? Where are secrets held? Which trust boundaries are crossed?\",\"Threat\u002Ftrust boundary model, identity propagation, secrets and authorization design\"],[\"Runtime and deployment\",\"Where do components execute? What is local, cloud, edge or hybrid? What network and availability assumptions exist?\",\"Deployment view, runtime topology, environment and connectivity decisions\"],[\"Evaluation and observability\",\"How is quality measured before and after release? What traces, metrics, logs and evidence are needed?\",\"Evaluation plan, telemetry, audit trail, release gates\"],[\"Operations and change\",\"How are models\u002Fprompts\u002Fconfiguration\u002Fdata versions changed, rolled back and supported?\",\"Operational model, lifecycle controls, ADRs, runbooks, change rules\"]]}},{\"id\":\"h-requirements\",\"type\":\"header\",\"data\":{\"text\":\"1. Turn product need into architectural requirements\",\"level\":3}},{\"id\":\"p-requirements-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI architecture begins before model selection. The architect first determines what the solution is expected to achieve and under which constraints. This includes functional behavior, but also the NFRs and policies that narrow the design space: security, reliability, latency, privacy, residency, maintainability, cost and operational support.\"}},{\"id\":\"p-requirements-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"This is where A02’s distinction matters: a requirement such as “unauthorized users must not retrieve restricted documents” is not an architecture decision. It is a driver. Decisions about identity propagation, index partitioning, metadata filtering, API boundaries and authorization enforcement are architectural responses that must later be validated.\"}},{\"id\":\"h-data\",\"type\":\"header\",\"data\":{\"text\":\"2. Design authoritative data, retrieval and context\",\"level\":3}},{\"id\":\"p-data-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI systems often fail at the boundary between model behavior and enterprise truth. An architect must define which sources are authoritative, what freshness and provenance mean, how access control reaches retrieval, and how retrieved evidence becomes model context. A vector database, embedding model or RAG library is not the architecture by itself.\"}},{\"id\":\"p-data-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Microsoft’s current AI workload guidance makes the same separation explicit: application code should not bypass data-access boundaries; user or tenant context should propagate into retrieval and filtering; grounding data must be designed for searchability while still meeting security and compliance requirements.\"}},{\"id\":\"h-model\",\"type\":\"header\",\"data\":{\"text\":\"3. Treat models and providers as dependencies, not the whole system\",\"level\":3}},{\"id\":\"p-model-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Model selection matters, but it should be driven by required capability and constraints. The architect considers reasoning or generation quality, modality, context limits, latency, data handling, deployment location, provider availability, cost, observability and replacement risk.\"}},{\"id\":\"p-model-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Provider abstraction is not automatically “better architecture.” It adds engineering cost and can hide provider-specific capabilities. It is justified when portability, fallback, policy separation or multi-provider routing is an explicit requirement. Otherwise a direct integration can be the better decision. The point is to make the trade-off intentional.\"}},{\"id\":\"h-tools\",\"type\":\"header\",\"data\":{\"text\":\"4. Architect tools, actions and agent boundaries\",\"level\":3}},{\"id\":\"p-tools-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"When an AI system can call tools, modify data, send messages, run code or operate business systems, the architectural risk changes. Tool access needs its own identity and authorization model. The model’s ability to request an action is not the same as permission to execute it.\"}},{\"id\":\"p-tools-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"For agentic workloads, current AWS guidance emphasizes additional dimensions such as agent identities, tool access, orchestration, human oversight, tracing, failure handling and cost of iterative reasoning loops. These are solution concerns even when a framework hides some of the implementation mechanics.\"}},{\"id\":\"h-security\",\"type\":\"header\",\"data\":{\"text\":\"5. Make trust boundaries and permissions explicit\",\"level\":3}},{\"id\":\"p-security-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A production AI solution has multiple trust boundaries: browser or client, application backend, AI orchestration, retrieval\u002Fdata services, model providers, tool APIs, local runtimes and external systems. Each boundary should answer: who is calling, on whose behalf, with what credential, for which resource, with what audit trail, and with what failure containment?\"}},{\"id\":\"p-security-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Security cannot be deferred to a “guardrail” around the model. Microsoft’s AI workload guidance explicitly places security across all architecture layers and calls for identity\u002Faccess management, data protection, content controls and lifecycle security. NIST likewise treats governance and risk management as continuous across the AI lifecycle.\"}},{\"id\":\"h-runtime\",\"type\":\"header\",\"data\":{\"text\":\"6. Decide where the system actually runs\",\"level\":3}},{\"id\":\"p-runtime-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"“Local AI,” “cloud AI,” and “hybrid AI” are architectural statements only when the execution and data paths are precise. A local desktop process can still call a cloud model. A cloud-hosted application can retrieve from an on-premises data source. An air-gapped solution has entirely different update, model-distribution and observability constraints.\"}},{\"id\":\"p-runtime-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The architect therefore separates \u003Cstrong>runtime location\u003C\u002Fstrong>, \u003Cstrong>inference location\u003C\u002Fstrong>, \u003Cstrong>data location\u003C\u002Fstrong> and \u003Cstrong>control plane\u003C\u002Fstrong>. Conflating them creates false security and deployment assumptions.\"}},{\"id\":\"h-eval\",\"type\":\"header\",\"data\":{\"text\":\"7. Define evaluation, observability and operational acceptance\",\"level\":3}},{\"id\":\"p-eval-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI behavior is partly nondeterministic, so the release definition cannot rely only on conventional unit tests. The architecture needs measurable acceptance: task success, groundedness or citation correctness where relevant, refusal behavior, tool safety, latency, cost, reliability and security tests. The exact metrics depend on the use case.\"}},{\"id\":\"p-eval-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Microsoft’s current Well-Architected AI guidance treats monitoring as continuous and applies it across model behavior, prompts\u002Fcompletions, anomalies, security and production quality gates. AWS similarly treats observability, lifecycle management and model\u002Fprompt traceability as operational architecture concerns.\"}},{\"id\":\"h-artifacts\",\"type\":\"header\",\"data\":{\"text\":\"What should the role produce?\",\"level\":2}},{\"id\":\"p-artifacts-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Architecture is not the slide deck. The useful outputs are the artifacts that let engineering, security, product and operations make consistent decisions and later understand why the system exists in its current form.\"}},{\"id\":\"artifacts-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Artifact\",\"Purpose\"],[\"Solution context and boundary\",\"Shows users, external systems, major responsibilities and what is outside scope\"],[\"Requirement\u002FNFR map\",\"Connects product need and constraints to architecture work and validation\"],[\"Component and data-flow views\",\"Shows application, data\u002Fretrieval, model, tools, identity and runtime interactions\"],[\"Trust and permission model\",\"Makes identities, secrets, authorization, sensitive data and high-risk actions explicit\"],[\"Architecture Decision Records\",\"Preserves significant choices, alternatives, trade-offs, status and consequences\"],[\"Evaluation and acceptance plan\",\"Defines evidence required to claim that the solution meets quality and safety expectations\"],[\"Deployment and operational view\",\"Defines environments, runtime locations, observability, rollback, incident and lifecycle responsibilities\"],[\"Traceability links\",\"Connects requirements, decisions, implementation work, tests and operational evidence\"]]}},{\"id\":\"h-tradeoffs\",\"type\":\"header\",\"data\":{\"text\":\"The work is mostly trade-offs, not “best practice” selection\",\"level\":2}},{\"id\":\"p-tradeoffs-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Architecture exists because desirable qualities conflict. A lower-cost model may reduce quality. A more capable model may increase latency or data-governance constraints. Aggressive caching can improve cost and speed while complicating freshness. More autonomous agents can reduce human effort while increasing blast radius and audit requirements.\"}},{\"id\":\"tradeoff-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Decision\",\"Potential benefit\",\"Potential cost \u002F risk\",\"Architectural question\"],[\"Managed cloud model\",\"Fast adoption, strong managed capabilities\",\"External dependency, data and cost constraints\",\"Does the workload permit the provider\u002Fdata path and meet resilience needs?\"],[\"Local\u002Fself-hosted inference\",\"Control, offline\u002Fprivate options\",\"Hardware, operations, model lifecycle burden\",\"Is the control benefit worth the operational responsibility?\"],[\"Single provider integration\",\"Simpler implementation, full provider features\",\"Higher switching\u002Ffailure concentration\",\"Is portability or fallback actually required?\"],[\"Provider abstraction\",\"Portability, routing and policy separation\",\"Lowest-common-denominator risk, more code\u002Ftests\",\"Which differences must remain visible rather than abstracted?\"],[\"Large context\",\"More information per request\",\"Latency, cost, attention dilution, leakage surface\",\"Should data be retrieved\u002Ffiltered instead of always injected?\"],[\"Powerful tools \u002F autonomy\",\"More end-to-end automation\",\"Higher privilege and failure blast radius\",\"Which actions require least privilege, confirmation or human approval?\"],[\"Strict validation and logging\",\"Better evidence and operations\",\"Latency, storage, privacy and complexity cost\",\"What evidence is required for this risk level?\"]]}},{\"id\":\"h-adjacent\",\"type\":\"header\",\"data\":{\"text\":\"How is this different from adjacent roles?\",\"level\":2}},{\"id\":\"p-adjacent-intro\",\"type\":\"paragraph\",\"data\":{\"text\":\"Titles overlap heavily across companies. The useful distinction is the \u003Cstrong>scope of architecture responsibility\u003C\u002Fstrong>, not the HR label.\"}},{\"id\":\"role-comparison\",\"type\":\"comparison\",\"data\":{\"title\":\"Adjacent roles answer different primary questions\",\"layout\":\"table\",\"columns\":[{\"id\":\"role\",\"label\":\"Role\"},{\"id\":\"focus\",\"label\":\"Primary architecture focus\"}],\"rows\":[{\"id\":\"r1\",\"label\":\"AI Solution Architect\",\"values\":{\"role\":\"One concrete AI-enabled solution\u002Fworkload\",\"focus\":\"How requirements, data, models, tools, security, runtime and operations fit together to deliver the target outcome\"}},{\"id\":\"r2\",\"label\":\"AI Platform Architect\",\"values\":{\"role\":\"Reusable AI platform capabilities across many solutions\",\"focus\":\"Shared provider gateways, model access, identity, evaluation, retrieval services, observability, deployment patterns and developer experience\"}},{\"id\":\"r3\",\"label\":\"Enterprise AI Architect\",\"values\":{\"role\":\"Organization\u002Fportfolio-level target architecture\",\"focus\":\"Capability landscape, governance, integration principles, shared platforms, standards, sourcing and strategic constraints across domains\"}},{\"id\":\"r4\",\"label\":\"AI \u002F ML Engineer\",\"values\":{\"role\":\"Implementation of AI\u002FML behavior and pipelines\",\"focus\":\"Models, data, inference, evaluation, application logic and engineering tasks within the architecture\"}},{\"id\":\"r5\",\"label\":\"Security Architect\",\"values\":{\"role\":\"Security architecture across systems\",\"focus\":\"Threats, identity, authorization, data protection, controls, assurance and compliance boundaries\"}},{\"id\":\"r6\",\"label\":\"Product \u002F Delivery Lead\",\"values\":{\"role\":\"Outcome, scope, prioritization and delivery system\",\"focus\":\"Why\u002Fwhat to build, sequencing, stakeholders, milestones, acceptance and value realization\"}}]}},{\"id\":\"p-adjacent-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"In a small product team, one person may cover several of these scopes. In a large enterprise, they may be separate roles with formal review boards. The architecture responsibility does not disappear when the title changes.\"}},{\"id\":\"h-implementation\",\"type\":\"header\",\"data\":{\"text\":\"Implementation evidence: how these boundaries appear in my own work\",\"level\":2}},{\"id\":\"implementation-boundary\",\"type\":\"callout\",\"data\":{\"variant\":\"success\",\"title\":\"Implementation evidence, not a universal rule\",\"body\":\"The examples below are \u003Cstrong>original implementation\u002Fproject evidence\u003C\u002Fstrong>. They show how I have separated product need, requirements, architecture, runtime, model\u002Fprovider, permissions and validation in real project work. They are not claims that every organization must use the same structure, and they do not imply customer adoption or enterprise-scale deployment.\"}},{\"id\":\"h-senseflow\",\"type\":\"header\",\"data\":{\"text\":\"SenseFlow: need → requirements → architecture → validation\",\"level\":3}},{\"id\":\"p-senseflow-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"In the SenseFlow project Source of Truth, technology is explicitly subordinate to Product Vision. The development structure moves from problem and product vision through user needs, value, scope, epics, stories and acceptance criteria into architecture, implementation, validation and iteration.\"}},{\"id\":\"p-senseflow-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Requirements are designed to be traceable from Product Goal → Capability → Epic → User Story → Acceptance Criteria → Technical Tasks. Where practical, they include functional requirements, NFRs, dependencies, risks, assumptions, acceptance criteria and validation methods. Significant decisions preserve the decision, reason, alternatives, trade-offs, status and date\u002Fversion.\"}},{\"id\":\"p-senseflow-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"That is architectural work before a specific AI framework or model is chosen: it protects the connection between product intent and technical decisions and makes later change reviewable rather than implicit.\"}},{\"id\":\"h-client\",\"type\":\"header\",\"data\":{\"text\":\"Aaasaasa AI Client: separate concepts before integrating them\",\"level\":3}},{\"id\":\"p-client-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Aaasaasa AI Client provides a more implementation-level example. Its AI Hub deliberately separates \u003Cstrong>agent\u002Fclient\u003C\u002Fstrong>, \u003Cstrong>provider\u003C\u002Fstrong>, \u003Cstrong>model\u003C\u002Fstrong>, \u003Cstrong>connection\u002Fruntime location\u003C\u002Fstrong>, \u003Cstrong>permissions\u003C\u002Fstrong> and \u003Cstrong>web client\u003C\u002Fstrong>. A local runtime is not assumed to mean local inference, and permissions are treated as runtime\u002Ftool policy rather than as a property of the model.\"}},{\"id\":\"p-client-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The desktop architecture also defines a trust boundary: the Nuxt renderer is untrusted relative to Electron main. A narrow preload and validated IPC mediate access to AI services, settings, encrypted secrets, workspace\u002Fdata services and runtimes. Cloud credentials remain in the privileged main process; renderer code receives normalized state instead of raw secrets or unrestricted operating-system access.\"}},{\"id\":\"p-client-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Routing decisions are similarly architectural. The implementation does not silently fall back from a local route to paid cloud inference; a cloud route requires explicit confirmation. Direct Chat has no filesystem or shell tools by default, while agent execution applies a selected workspace and permission profile. These are solution-level decisions about trust, cost, execution and user expectation—not model features.\"}},{\"id\":\"h-current-frameworks\",\"type\":\"header\",\"data\":{\"text\":\"How current architecture frameworks support this broader scope\",\"level\":2}},{\"id\":\"p-frameworks-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"ISO\u002FIEC\u002FIEEE 42010:2022 provides a general discipline for architecture descriptions across software, systems and enterprises. It is deliberately broader than AI and does not prescribe one architecting method or job title. That makes it useful here as a boundary: AI solution architecture is still architecture, with stakeholder concerns, multiple views and significant relationships that must be expressed clearly.\"}},{\"id\":\"p-frameworks-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"NIST AI RMF 1.0 frames AI risk management through \u003Cstrong>Govern, Map, Measure and Manage\u003C\u002Fstrong> and emphasizes that risk management should be continuous across the AI system lifecycle. The Generative AI Profile (NIST AI 600-1) adapts that framework to GAI risks and organizational priorities. This reinforces that architecture cannot stop at functional model performance.\"}},{\"id\":\"p-frameworks-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Microsoft’s current Azure Well-Architected AI guidance separates application design, application platform, training data, grounding data and data platform concerns and repeatedly connects them to reliability, security, operational excellence, performance and cost. AWS’s Generative AI and Agentic AI lenses similarly treat observability, security, reliability, model\u002Ftool lifecycle, cost and human oversight as architecture concerns.\"}},{\"id\":\"h-misconceptions\",\"type\":\"header\",\"data\":{\"text\":\"Common misconceptions\",\"level\":2}},{\"id\":\"misconceptions-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Misconception\",\"Correction\"],[\"“The architect chooses the LLM.”\",\"Model choice is one decision inside a larger solution architecture.\"],[\"“Prompt engineering is the architecture.”\",\"Prompts affect behavior, but they do not define identity, data access, trust boundaries, deployment, tool permissions or operations.\"],[\"“RAG solves enterprise knowledge.”\",\"Retrieval is only one subsystem; authorization, provenance, freshness, evidence, indexing, evaluation and source governance still need design.\"],[\"“Local runtime means private\u002Flocal AI.”\",\"Runtime, inference, data and control-plane locations are separate architectural properties.\"],[\"“If a vendor offers guardrails, security is covered.”\",\"Security spans identity, authorization, secrets, data flows, tools, logging, deployment, human approval and provider boundaries.\"],[\"“The architect must write every component.”\",\"Hands-on implementation can improve architectural quality, but the role is defined by integrated decision responsibility, not by personally coding every layer.\"],[\"“An architecture diagram proves production readiness.”\",\"Readiness requires implemented controls and validation evidence across quality, security, operations and business acceptance.\"]]}},{\"id\":\"h-failures\",\"type\":\"header\",\"data\":{\"text\":\"Failure modes an AI Solution Architect should prevent\",\"level\":2}},{\"id\":\"failures-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Failure mode\",\"Why it happens\",\"Architectural correction\"],[\"Model-first design\",\"A promising model demo becomes the system blueprint\",\"Start from outcome, constraints and validation; select the model inside that frame\"],[\"Prototype permissions in production\",\"Shared credentials and broad access survive the PoC\",\"Define identity propagation, least privilege, tool scopes and approval boundaries early\"],[\"Retrieval without authorization\",\"Search quality is designed before data-access rules\",\"Carry user\u002Ftenant context into retrieval and enforce authorization at data-access boundaries\"],[\"Silent provider\u002Fruntime assumptions\",\"“Local”, “cloud” and “offline” are used imprecisely\",\"Document runtime, inference, data and control-plane location separately\"],[\"No failure contract\",\"The happy path is designed but refusal\u002Ffallback\u002Ferror behavior is not\",\"Specify retrieval-empty, model-unavailable, tool-failure and policy-denied behavior\"],[\"Evaluation after implementation\",\"Quality is judged manually near launch\",\"Define measurable acceptance and representative evaluation sets before architecture freezes\"],[\"Untraceable change\",\"Models, prompts, retrieval or permissions change without architectural history\",\"Version critical configuration and record significant decisions\u002Fvalidation evidence\"],[\"Operations treated as infrastructure only\",\"AI behavior is not observable after deployment\",\"Design traces, quality metrics, security events, cost telemetry and rollback together\"]]}},{\"id\":\"h-decision-framework\",\"type\":\"header\",\"data\":{\"text\":\"A practical decision sequence\",\"level\":2}},{\"id\":\"decision-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"AI solution architecture decision sequence\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"Outcome\",\"description\":\"Define the user\u002Fbusiness result and explicit non-goals.\"},{\"label\":\"Evidence and constraints\",\"description\":\"Identify authoritative data, policies, NFRs, risks and acceptance conditions.\"},{\"label\":\"System boundary\",\"description\":\"Map users, identities, applications, data, models\u002Fproviders, tools and external systems.\"},{\"label\":\"Architecture options\",\"description\":\"Compare patterns for retrieval, model access, orchestration, deployment, permissions, evaluation and observability.\"},{\"label\":\"Trade-off decisions\",\"description\":\"Select significant options and preserve the rationale, alternatives and consequences.\"},{\"label\":\"Implementation contracts\",\"description\":\"Turn decisions into APIs, schemas, permission rules, deployment definitions and engineering tasks.\"},{\"label\":\"Validation\",\"description\":\"Test the implemented system against the original functional and non-functional requirements.\"},{\"label\":\"Operational feedback\",\"description\":\"Use production evidence, incidents, quality metrics and cost\u002Fsecurity signals to trigger controlled change.\"}]}},{\"id\":\"h-edge\",\"type\":\"header\",\"data\":{\"text\":\"Edge cases and limits of the role\",\"level\":2}},{\"id\":\"p-edge-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Some AI products are dominated by model training, scientific experimentation or specialized hardware. In those cases, model\u002Fdata science and ML systems architecture can become much deeper than the solution-level map shown here. The AI Solution Architect still needs integration and operational boundaries, but specialist architecture may own the training platform itself.\"}},{\"id\":\"p-edge-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"At the other extreme, a simple SaaS integration may not justify a dedicated architect. A senior engineer or technical product lead can carry the same architecture responsibility. The useful test is not the title but whether significant cross-layer decisions are being made deliberately and validated.\"}},{\"id\":\"p-edge-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Regulated, sovereign, air-gapped, safety-critical, highly autonomous or multi-tenant systems also shift the center of gravity. Identity, isolation, residency, assurance, update mechanisms, human oversight and auditability may dominate model quality in the architecture.\"}},{\"id\":\"h-change-answer\",\"type\":\"header\",\"data\":{\"text\":\"What would change this answer?\",\"level\":2}},{\"id\":\"p-change-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The exact responsibility boundary changes when architecture moves from one application to a reusable platform or to enterprise-wide target architecture. That is why \u003Cstrong>AI Platform Architect\u003C\u002Fstrong> and \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> deserve separate canonical treatment rather than being merged into this role.\"}},{\"id\":\"p-change-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Technology changes also matter. New model capabilities, protocols, local runtimes and managed services can remove some implementation work while creating new trust or operational boundaries. The stable responsibility is to understand those changes as system changes—not to treat a new framework as a replacement for architecture.\"}},{\"id\":\"h-checklist\",\"type\":\"header\",\"data\":{\"text\":\"AI Solution Architect checklist\",\"level\":2}},{\"id\":\"checklist-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Check\",\"Question\"],[\"Outcome\",\"Is the user\u002Fbusiness result and non-goal boundary explicit?\"],[\"Requirements\",\"Are functional requirements, NFRs, constraints and acceptance criteria traceable?\"],[\"Data\",\"Are authoritative sources, provenance, freshness, retention and access rules defined?\"],[\"Retrieval\u002Fcontext\",\"Does authorization reach retrieval and context construction?\"],[\"Model\u002Fprovider\",\"Is model\u002Fprovider selection tied to capabilities and constraints rather than preference?\"],[\"Tools\u002Fagents\",\"Are action boundaries, permissions, approvals and failure behavior explicit?\"],[\"Identity\u002Fsecurity\",\"Are human\u002Fmachine identities, secrets and trust boundaries defined?\"],[\"Runtime\",\"Are runtime, inference, data and control-plane locations distinguished?\"],[\"Evaluation\",\"Is there measurable evidence for quality, security and acceptance?\"],[\"Observability\",\"Can production behavior, failures, cost and security events be investigated?\"],[\"Change\",\"Are significant architecture decisions and replacements traceable?\"],[\"Operations\",\"Is ownership for deployment, rollback, incidents and lifecycle clear?\"]]}},{\"id\":\"h-conclusion\",\"type\":\"header\",\"data\":{\"text\":\"Conclusion\",\"level\":2}},{\"id\":\"p-conclusion-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"An AI Solution Architect is the person or architecture function that turns an AI opportunity into a coherent technical system. The key skill is not knowing the most model names; it is connecting product need, requirements, data, application architecture, AI capabilities, security, runtime, delivery and validation without losing the boundaries between them.\"}},{\"id\":\"p-conclusion-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"A strong AI solution architecture can therefore be summarized as: \u003Cstrong>define the target → establish requirements and constraints → design the system boundaries → make significant trade-offs explicit → implement through clear contracts → validate against evidence → operate and evolve deliberately.\u003C\u002Fstrong> The model is important. The solution is the product.\"}},{\"id\":\"faq\",\"type\":\"faq\",\"data\":{\"title\":\"AI Solution Architect — FAQ\",\"items\":[{\"id\":\"faq1\",\"question\":\"What is an AI Solution Architect?\",\"answer\":\"An AI Solution Architect translates a business or product need into the architecture of a concrete AI-enabled solution, defining how application logic, data\u002Fretrieval, models, tools, identity, security, runtime, evaluation and operations work together.\"},{\"id\":\"faq2\",\"question\":\"Is an AI Solution Architect the same as an AI engineer?\",\"answer\":\"No. The roles can overlap, especially in small teams, but an AI engineer is primarily an implementation role while the solution architect owns or coordinates cross-layer architecture decisions and trade-offs for the complete workload.\"},{\"id\":\"faq3\",\"question\":\"Does an AI Solution Architect need to code?\",\"answer\":\"Not by definition, but hands-on implementation knowledge is highly valuable because AI architecture crosses APIs, data, retrieval, security, runtimes and operational behavior. The role is defined by architecture responsibility, not by writing every component personally.\"},{\"id\":\"faq4\",\"question\":\"Is choosing an LLM the main job?\",\"answer\":\"No. Model selection is one decision. Production architecture also needs data and retrieval boundaries, permissions, tools, provider\u002Fruntime choices, observability, evaluation, reliability, cost and lifecycle design.\"},{\"id\":\"faq5\",\"question\":\"What is the difference between an AI Solution Architect and an AI Platform Architect?\",\"answer\":\"An AI Solution Architect focuses on one concrete solution or workload. An AI Platform Architect focuses on reusable AI capabilities and guardrails that support multiple solutions.\"},{\"id\":\"faq6\",\"question\":\"What is the difference between an AI Solution Architect and an Enterprise AI Architect?\",\"answer\":\"The solution architect works at application\u002Fworkload scope. Enterprise AI architecture works across the organizational portfolio, target architecture, governance, shared capabilities, integration principles and strategic constraints.\"},{\"id\":\"faq7\",\"question\":\"Where do RAG and agents fit?\",\"answer\":\"They are architectural patterns or subsystems inside a solution when the requirements justify them. RAG addresses retrieval-grounded context; agents add planning\u002Ftool execution and therefore additional identity, permission, orchestration and operational concerns.\"},{\"id\":\"faq8\",\"question\":\"What proves that the architecture works?\",\"answer\":\"Implementation plus validation evidence: functional tests, evaluation results, security\u002Fauthorization tests, performance and reliability measurements, observability, operational rehearsal and acceptance against the original requirements.\"}]}},{\"id\":\"glossary\",\"type\":\"glossary\",\"data\":{\"title\":\"Core terms\",\"entries\":[{\"term\":\"AI Solution Architect\",\"definition\":\"Architecture responsibility for one concrete AI-enabled solution or workload, integrating product requirements with application, data, model, tool, security, runtime and operational design.\",\"anchor\":\"ai-solution-architect\"},{\"term\":\"System boundary\",\"definition\":\"The explicit separation between what belongs to the solution and the users, systems, providers, data sources and environments it interacts with.\",\"anchor\":\"system-boundary\"},{\"term\":\"Trust boundary\",\"definition\":\"A point where data, identities or control cross between components with different trust assumptions and therefore require explicit security controls.\",\"anchor\":\"trust-boundary\"},{\"term\":\"Grounding\",\"definition\":\"Supplying an AI model with relevant external information or evidence so its response can be based on sources beyond model parameters.\",\"anchor\":\"grounding\"},{\"term\":\"Provider abstraction\",\"definition\":\"An application boundary that decouples parts of the solution from one model\u002Fprovider interface. Useful when justified by routing, portability or policy needs, but not free of trade-offs.\",\"anchor\":\"provider-abstraction\"},{\"term\":\"Evaluation\",\"definition\":\"Structured measurement of AI workload behavior against defined acceptance criteria, including task quality and relevant safety, security, performance and operational properties.\",\"anchor\":\"evaluation\"},{\"term\":\"AI Platform Architect\",\"definition\":\"Architectural role focused on reusable AI platform capabilities used by multiple solutions rather than the architecture of one workload.\",\"anchor\":\"ai-platform-architect\"},{\"term\":\"Enterprise AI Architecture\",\"definition\":\"Organization-level architecture that coordinates AI capabilities, platforms, governance, integration and strategic constraints across a portfolio.\",\"anchor\":\"enterprise-ai-architecture\"}]}},{\"id\":\"h-related\",\"type\":\"header\",\"data\":{\"text\":\"Related canonical knowledge\",\"level\":2}},{\"id\":\"p-related-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"This article sits in the AI Architecture Foundations cluster. Its direct foundations are \u003Cstrong>Generative AI Explained: Models, Retrieval, Tools and Applications Are Not the Same Thing\u003C\u002Fstrong> and \u003Cstrong>ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing\u003C\u002Fstrong>. Adjacent canonical nodes include \u003Cstrong>Agentic AI Explained\u003C\u002Fstrong>, \u003Cstrong>Source of Truth in AI Systems\u003C\u002Fstrong>, \u003Cstrong>Vector Databases, Embeddings and Reranking\u003C\u002Fstrong>, \u003Cstrong>What Is Context Engineering?\u003C\u002Fstrong>, \u003Cstrong>RBAC vs Tenant Isolation\u003C\u002Fstrong>, \u003Cstrong>AI Platform Architect\u003C\u002Fstrong>, \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> and \u003Cstrong>AI Governance\u003C\u002Fstrong>. URLs are intentionally not fabricated where those nodes are not yet published.\"}},{\"id\":\"related-rag\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fstajic.de\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works\",\"meta\":{\"title\":\"What Is RAG? The Simplest Explanation of How It Works\",\"description\":\"Existing stajic.de canonical explanation of retrieval-augmented generation, useful for the retrieval\u002Fgrounding part of AI solution architecture.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"h-sources\",\"type\":\"header\",\"data\":{\"text\":\"Primary sources and current architecture guidance\",\"level\":2}},{\"id\":\"p-sources-note\",\"type\":\"paragraph\",\"data\":{\"text\":\"External sources below support the general architecture claims; the SenseFlow and Aaasaasa AI Client sections are explicitly original project\u002Fimplementation evidence. Current-state references were checked on 8 October 2026. NIST notes that AI RMF 1.0 is being revised, so version-sensitive governance references should be rechecked when a successor is published.\"}},{\"id\":\"src-iso-42010\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html\",\"meta\":{\"title\":\"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description\",\"description\":\"Current international standard for the structure and expression of architecture descriptions. It distinguishes architecture from its description and does not prescribe one architecting method, tool or recording format.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-nist-rmf\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework\",\"meta\":{\"title\":\"NIST AI Risk Management Framework\",\"description\":\"NIST’s AI RMF resource page. As of October 2026 it states that AI RMF 1.0 is being revised and links the Generative AI Profile and related resources.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-nist-core\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fairc.nist.gov\u002Fairmf-resources\u002Fairmf\u002F5-sec-core\u002F\",\"meta\":{\"title\":\"NIST AI RMF Core — Govern, Map, Measure, Manage\",\"description\":\"Official NIST AIRC presentation of the AI RMF 1.0 Core, including the four functions and lifecycle-oriented risk-management framing.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-nist-gai\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fartificial-intelligence-risk-management-framework-generative-artificial-intelligence\",\"meta\":{\"title\":\"NIST AI 600-1 — Generative AI Profile\",\"description\":\"Cross-sectoral Generative AI profile for AI RMF 1.0, published 26 July 2024 and updated by NIST in 2026.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-ms-start\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fget-started\",\"meta\":{\"title\":\"Microsoft Azure Well-Architected — AI Workloads\",\"description\":\"Current workload-level architecture guidance covering AI application design, application platform, training data, grounding data, data platform and production-readiness concerns.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-ms-app\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fapplication-design\",\"meta\":{\"title\":\"Microsoft — Application Design for AI Workloads\",\"description\":\"Guidance on model\u002Ftool abstraction, data-access boundaries, identity propagation, authorization and separation of client, intelligence, knowledge and tool layers.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-ms-security\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fdesign-principles\",\"meta\":{\"title\":\"Microsoft — Design Principles for AI Workloads\",\"description\":\"Current AI workload design principles across reliability, security, cost, operational excellence and performance, including identity and data-protection responsibilities.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-ms-ops\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fmlops-genaiops\",\"meta\":{\"title\":\"Microsoft — MLOps and GenAIOps for AI Workloads\",\"description\":\"Production lifecycle guidance covering monitoring, quality gates, model\u002Fprompt behavior, security and operational measurement.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-aws-genai\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fgenerative-ai-lens\u002F\",\"meta\":{\"title\":\"AWS Well-Architected Generative AI Lens\",\"description\":\"AWS architectural guidance for generative AI workloads across operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-aws-agentic\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fagentic-ai-lens\u002F\",\"meta\":{\"title\":\"AWS Well-Architected Agentic AI Lens\",\"description\":\"Published in 2026, covering agentic-specific architecture concerns including identities, tools, orchestration, human oversight, reliability, tracing and reasoning-loop cost.\",\"image\":{\"url\":\"\"}}}}],\"version\":\"2.31.0\"}",{"time":1116,"blocks":1117,"version":1781},1791476244367,[1118,1121,1125,1129,1133,1136,1139,1142,1145,1169,1172,1175,1178,1203,1206,1209,1212,1215,1218,1265,1268,1271,1274,1277,1280,1283,1286,1289,1292,1295,1298,1301,1304,1307,1310,1313,1316,1319,1322,1325,1328,1331,1334,1364,1367,1370,1413,1416,1419,1444,1447,1450,1454,1457,1460,1463,1466,1469,1472,1475,1478,1481,1484,1487,1490,1493,1520,1523,1562,1565,1593,1596,1599,1602,1605,1608,1611,1614,1617,1655,1658,1661,1664,1691,1713,1716,1719,1725,1728,1731,1736,1741,1746,1751,1756,1761,1766,1771,1776],{"id":215,"data":1119,"type":218},{"text":1120},"An \u003Cstrong>AI Solution Architect\u003C\u002Fstrong> translates a business or product need into the architecture of a concrete AI-enabled solution. The role defines system boundaries and the significant choices across application logic, authoritative data, retrieval and context, models and providers, tools or agents, identity and permissions, security, runtime and deployment, observability, evaluation, cost and operational behavior. It is not simply model selection or prompt engineering: the architectural responsibility is to make the whole solution implementable, governable, testable and operable.",{"id":220,"data":1122,"type":225},{"body":1123,"title":1124,"variant":224},"\u003Cstrong>An AI Solution Architect designs the complete AI-enabled solution, not just the AI model.\u003C\u002Fstrong> The role connects requirements and non-functional requirements to architecture decisions, composes the necessary application\u002Fdata\u002Fmodel\u002Ftool\u002Fruntime layers, makes trust and failure boundaries explicit, and defines how the implemented system will be validated and operated.","Direct answer",{"id":227,"data":1126,"type":225},{"body":1127,"title":1128,"variant":231},"\u003Cstrong>AI Solution Architect is a practical role label, not a universally standardized job title.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 standardizes concepts for architecture descriptions; it does not define this job role. Organizations can distribute the responsibilities across several people. In this article, the term means the architecture responsibility for one concrete AI-enabled solution or workload.","Terminology note",{"id":233,"data":1130,"type":225},{"body":1131,"title":1132,"variant":231},"The architecture principles here are intentionally vendor-neutral, while current vendor guidance is used as implementation evidence. NIST AI RMF 1.0 is currently under revision; NIST AI 600-1 remains the published Generative AI Profile. Microsoft and AWS guidance cited below reflects current production concerns such as identity, data boundaries, model abstraction, security, observability, evaluation, reliability and cost.","Current-source note — 8 October 2026",{"id":238,"data":1134,"type":243},{"title":1135,"maxLevel":241,"minLevel":242},"Contents",{"id":245,"data":1137,"type":42},{"text":1138,"level":242},"What does an AI Solution Architect actually architect?",{"id":249,"data":1140,"type":218},{"text":1141},"The object of the work is the \u003Cstrong>solution\u003C\u002Fstrong>: the complete socio-technical system that turns a need into useful, controlled behavior. A model may be central to that system, but it is still only one dependency. The same model can participate in a safe internal search assistant, an unsafe over-privileged agent, a low-latency customer feature, or a high-cost prototype that cannot be operated economically. Architecture determines those differences.",{"id":253,"data":1143,"type":218},{"text":1144},"A useful boundary is therefore: \u003Cstrong>business outcome → requirements → system responsibilities → architecture decisions → implementation → validation → operation\u003C\u002Fstrong>. The AI Solution Architect works across this chain while collaborating with product, engineering, data, security, infrastructure, governance and domain specialists.",{"id":257,"data":1146,"type":299},{"rows":1147,"title":1163,"layout":291,"columns":1164},[1148,1151,1154,1157,1160],{"id":261,"label":1149,"values":1150},"Capability",{"model":264,"solution":265},{"id":267,"label":1152,"values":1153},"Data",{"model":270,"solution":271},{"id":273,"label":1155,"values":1156},"Security",{"model":276,"solution":277},{"id":279,"label":1158,"values":1159},"Operations",{"model":282,"solution":283},{"id":285,"label":1161,"values":1162},"Change",{"model":288,"solution":289},"The solution is wider than the model",[1165,1167],{"id":294,"label":1166},"Model-centric question",{"id":297,"label":1168},"Solution-architecture question",{"id":301,"data":1170,"type":42},{"text":1171,"level":242},"The simplest example",{"id":305,"data":1173,"type":218},{"text":1174},"Imagine a company wants an internal assistant that answers technicians’ questions from maintenance manuals and operating procedures. The visible feature sounds simple: type a question and receive an answer with sources.",{"id":309,"data":1176,"type":218},{"text":1177},"The architecture question is much larger. Which documents are authoritative? How are users authenticated? Must retrieval respect department or site permissions? Is the answer allowed to use only retrieved evidence? Which model is acceptable for the data classification? Can a cloud provider receive the content? What happens when retrieval finds nothing? How are citations produced? How is answer quality evaluated? What latency and cost are acceptable? Who can see logs, and what may be stored in them?",{"id":313,"data":1179,"type":339},{"steps":1180,"title":1202,"orientation":338},[1181,1184,1187,1190,1193,1196,1199],{"label":1182,"description":1183},"1. Define the outcome","Clarify the user, business value, task boundary and what a successful answer or action means.",{"label":1185,"description":1186},"2. Capture requirements","Make functional requirements, NFRs, constraints, data rules, risk tolerance and acceptance criteria explicit.",{"label":1188,"description":1189},"3. Establish boundaries","Identify users, identities, applications, authoritative data, model\u002Fprovider dependencies, tools, external systems and trust zones.",{"label":1191,"description":1192},"4. Design the architecture","Choose data\u002Fretrieval, model, orchestration, tool, permission, runtime, deployment, fallback and observability patterns.",{"label":1194,"description":1195},"5. Record significant decisions","Preserve architectural choices, alternatives, trade-offs and consequences so later changes remain understandable.",{"label":1197,"description":1198},"6. Implement and integrate","Turn the architecture into application code, APIs, policies, infrastructure, workflows and operational controls.",{"label":1200,"description":1201},"7. Validate and operate","Test quality, security, reliability, cost and user outcomes; monitor the real workload and feed evidence back into decisions.","From need to an operable AI solution",{"id":341,"data":1204,"type":42},{"text":1205,"level":242},"Where the simple example stops",{"id":345,"data":1207,"type":218},{"text":1208},"A proof of concept can often skip architecture that production cannot. A developer may hard-code one provider, use a shared API key, place all documents in one index, run retrieval without user-context filtering, log prompts verbatim and judge quality manually. That can demonstrate feasibility, but it does not establish a production architecture.",{"id":349,"data":1210,"type":218},{"text":1211},"Production introduces constraints that interact: tenant or user isolation, privacy, data residency, throughput, latency, cost, provider quotas, fallback behavior, auditability, model version changes, retrieval quality, tool permissions, incident response and deployment lifecycle. The architect’s job is not to maximize every quality at once; it is to make the trade-offs explicit and design a solution that satisfies the actual priority set.",{"id":353,"data":1213,"type":42},{"text":1214,"level":242},"Architecture responsibility map",{"id":357,"data":1216,"type":218},{"text":1217},"The exact split varies by organization, but the following map captures the recurring responsibilities of solution-level AI architecture. The architect may not personally implement every layer; the responsibility is to make the layers fit together coherently and to keep the critical decisions traceable.",{"id":361,"data":1219,"type":291},{"content":1220,"stretched":43,"withHeadings":14},[1221,1225,1229,1233,1237,1241,1245,1249,1253,1257,1261],[1222,1223,1224],"Architecture area","Questions the AI Solution Architect must resolve","Typical outputs",[1226,1227,1228],"Outcome and scope","Who is the user? What task is in scope? What must the system not do? What constitutes success?","Solution context, capability boundary, acceptance criteria",[1230,1231,1232],"Requirements and NFRs","What quality, security, availability, latency, cost, residency and compliance constraints apply?","Requirement map, NFRs, constraints, validation criteria",[1234,1235,1236],"Application and orchestration","Where does deterministic application logic end and AI behavior begin? How are workflows coordinated?","Component model, APIs, orchestration boundaries, failure paths",[1238,1239,1240],"Authoritative data and retrieval","What is the Source of Truth? How is data ingested, authorized, retrieved, filtered, ranked and cited?","Data flows, retrieval architecture, metadata and authorization rules",[1242,1243,1244],"Model and provider layer","Which capabilities are required? Which provider\u002Fruntime constraints matter? What should be abstracted?","Model\u002Fprovider decision, routing\u002Ffallback policy, abstraction boundary",[1246,1247,1248],"Tools and agents","What actions can the system take? Which actions require approval? How are tool identities and permissions enforced?","Tool contracts, agent boundaries, approval and least-privilege rules",[1250,1251,1252],"Identity and security","Which human and machine identities exist? Where are secrets held? Which trust boundaries are crossed?","Threat\u002Ftrust boundary model, identity propagation, secrets and authorization design",[1254,1255,1256],"Runtime and deployment","Where do components execute? What is local, cloud, edge or hybrid? What network and availability assumptions exist?","Deployment view, runtime topology, environment and connectivity decisions",[1258,1259,1260],"Evaluation and observability","How is quality measured before and after release? What traces, metrics, logs and evidence are needed?","Evaluation plan, telemetry, audit trail, release gates",[1262,1263,1264],"Operations and change","How are models\u002Fprompts\u002Fconfiguration\u002Fdata versions changed, rolled back and supported?","Operational model, lifecycle controls, ADRs, runbooks, change rules",{"id":409,"data":1266,"type":42},{"text":1267,"level":241},"1. Turn product need into architectural requirements",{"id":413,"data":1269,"type":218},{"text":1270},"AI architecture begins before model selection. The architect first determines what the solution is expected to achieve and under which constraints. This includes functional behavior, but also the NFRs and policies that narrow the design space: security, reliability, latency, privacy, residency, maintainability, cost and operational support.",{"id":417,"data":1272,"type":218},{"text":1273},"This is where A02’s distinction matters: a requirement such as “unauthorized users must not retrieve restricted documents” is not an architecture decision. It is a driver. Decisions about identity propagation, index partitioning, metadata filtering, API boundaries and authorization enforcement are architectural responses that must later be validated.",{"id":421,"data":1275,"type":42},{"text":1276,"level":241},"2. Design authoritative data, retrieval and context",{"id":425,"data":1278,"type":218},{"text":1279},"AI systems often fail at the boundary between model behavior and enterprise truth. An architect must define which sources are authoritative, what freshness and provenance mean, how access control reaches retrieval, and how retrieved evidence becomes model context. A vector database, embedding model or RAG library is not the architecture by itself.",{"id":429,"data":1281,"type":218},{"text":1282},"Microsoft’s current AI workload guidance makes the same separation explicit: application code should not bypass data-access boundaries; user or tenant context should propagate into retrieval and filtering; grounding data must be designed for searchability while still meeting security and compliance requirements.",{"id":433,"data":1284,"type":42},{"text":1285,"level":241},"3. Treat models and providers as dependencies, not the whole system",{"id":437,"data":1287,"type":218},{"text":1288},"Model selection matters, but it should be driven by required capability and constraints. The architect considers reasoning or generation quality, modality, context limits, latency, data handling, deployment location, provider availability, cost, observability and replacement risk.",{"id":441,"data":1290,"type":218},{"text":1291},"Provider abstraction is not automatically “better architecture.” It adds engineering cost and can hide provider-specific capabilities. It is justified when portability, fallback, policy separation or multi-provider routing is an explicit requirement. Otherwise a direct integration can be the better decision. The point is to make the trade-off intentional.",{"id":445,"data":1293,"type":42},{"text":1294,"level":241},"4. Architect tools, actions and agent boundaries",{"id":449,"data":1296,"type":218},{"text":1297},"When an AI system can call tools, modify data, send messages, run code or operate business systems, the architectural risk changes. Tool access needs its own identity and authorization model. The model’s ability to request an action is not the same as permission to execute it.",{"id":453,"data":1299,"type":218},{"text":1300},"For agentic workloads, current AWS guidance emphasizes additional dimensions such as agent identities, tool access, orchestration, human oversight, tracing, failure handling and cost of iterative reasoning loops. These are solution concerns even when a framework hides some of the implementation mechanics.",{"id":457,"data":1302,"type":42},{"text":1303,"level":241},"5. Make trust boundaries and permissions explicit",{"id":461,"data":1305,"type":218},{"text":1306},"A production AI solution has multiple trust boundaries: browser or client, application backend, AI orchestration, retrieval\u002Fdata services, model providers, tool APIs, local runtimes and external systems. Each boundary should answer: who is calling, on whose behalf, with what credential, for which resource, with what audit trail, and with what failure containment?",{"id":465,"data":1308,"type":218},{"text":1309},"Security cannot be deferred to a “guardrail” around the model. Microsoft’s AI workload guidance explicitly places security across all architecture layers and calls for identity\u002Faccess management, data protection, content controls and lifecycle security. NIST likewise treats governance and risk management as continuous across the AI lifecycle.",{"id":469,"data":1311,"type":42},{"text":1312,"level":241},"6. Decide where the system actually runs",{"id":473,"data":1314,"type":218},{"text":1315},"“Local AI,” “cloud AI,” and “hybrid AI” are architectural statements only when the execution and data paths are precise. A local desktop process can still call a cloud model. A cloud-hosted application can retrieve from an on-premises data source. An air-gapped solution has entirely different update, model-distribution and observability constraints.",{"id":477,"data":1317,"type":218},{"text":1318},"The architect therefore separates \u003Cstrong>runtime location\u003C\u002Fstrong>, \u003Cstrong>inference location\u003C\u002Fstrong>, \u003Cstrong>data location\u003C\u002Fstrong> and \u003Cstrong>control plane\u003C\u002Fstrong>. Conflating them creates false security and deployment assumptions.",{"id":481,"data":1320,"type":42},{"text":1321,"level":241},"7. Define evaluation, observability and operational acceptance",{"id":485,"data":1323,"type":218},{"text":1324},"AI behavior is partly nondeterministic, so the release definition cannot rely only on conventional unit tests. The architecture needs measurable acceptance: task success, groundedness or citation correctness where relevant, refusal behavior, tool safety, latency, cost, reliability and security tests. The exact metrics depend on the use case.",{"id":489,"data":1326,"type":218},{"text":1327},"Microsoft’s current Well-Architected AI guidance treats monitoring as continuous and applies it across model behavior, prompts\u002Fcompletions, anomalies, security and production quality gates. AWS similarly treats observability, lifecycle management and model\u002Fprompt traceability as operational architecture concerns.",{"id":493,"data":1329,"type":42},{"text":1330,"level":242},"What should the role produce?",{"id":497,"data":1332,"type":218},{"text":1333},"Architecture is not the slide deck. The useful outputs are the artifacts that let engineering, security, product and operations make consistent decisions and later understand why the system exists in its current form.",{"id":501,"data":1335,"type":291},{"content":1336,"stretched":43,"withHeadings":14},[1337,1340,1343,1346,1349,1352,1355,1358,1361],[1338,1339],"Artifact","Purpose",[1341,1342],"Solution context and boundary","Shows users, external systems, major responsibilities and what is outside scope",[1344,1345],"Requirement\u002FNFR map","Connects product need and constraints to architecture work and validation",[1347,1348],"Component and data-flow views","Shows application, data\u002Fretrieval, model, tools, identity and runtime interactions",[1350,1351],"Trust and permission model","Makes identities, secrets, authorization, sensitive data and high-risk actions explicit",[1353,1354],"Architecture Decision Records","Preserves significant choices, alternatives, trade-offs, status and consequences",[1356,1357],"Evaluation and acceptance plan","Defines evidence required to claim that the solution meets quality and safety expectations",[1359,1360],"Deployment and operational view","Defines environments, runtime locations, observability, rollback, incident and lifecycle responsibilities",[1362,1363],"Traceability links","Connects requirements, decisions, implementation work, tests and operational evidence",{"id":532,"data":1365,"type":42},{"text":1366,"level":242},"The work is mostly trade-offs, not “best practice” selection",{"id":536,"data":1368,"type":218},{"text":1369},"Architecture exists because desirable qualities conflict. A lower-cost model may reduce quality. A more capable model may increase latency or data-governance constraints. Aggressive caching can improve cost and speed while complicating freshness. More autonomous agents can reduce human effort while increasing blast radius and audit requirements.",{"id":540,"data":1371,"type":291},{"content":1372,"stretched":43,"withHeadings":14},[1373,1378,1383,1388,1393,1398,1403,1408],[1374,1375,1376,1377],"Decision","Potential benefit","Potential cost \u002F risk","Architectural question",[1379,1380,1381,1382],"Managed cloud model","Fast adoption, strong managed capabilities","External dependency, data and cost constraints","Does the workload permit the provider\u002Fdata path and meet resilience needs?",[1384,1385,1386,1387],"Local\u002Fself-hosted inference","Control, offline\u002Fprivate options","Hardware, operations, model lifecycle burden","Is the control benefit worth the operational responsibility?",[1389,1390,1391,1392],"Single provider integration","Simpler implementation, full provider features","Higher switching\u002Ffailure concentration","Is portability or fallback actually required?",[1394,1395,1396,1397],"Provider abstraction","Portability, routing and policy separation","Lowest-common-denominator risk, more code\u002Ftests","Which differences must remain visible rather than abstracted?",[1399,1400,1401,1402],"Large context","More information per request","Latency, cost, attention dilution, leakage surface","Should data be retrieved\u002Ffiltered instead of always injected?",[1404,1405,1406,1407],"Powerful tools \u002F autonomy","More end-to-end automation","Higher privilege and failure blast radius","Which actions require least privilege, confirmation or human approval?",[1409,1410,1411,1412],"Strict validation and logging","Better evidence and operations","Latency, storage, privacy and complexity cost","What evidence is required for this risk level?",{"id":584,"data":1414,"type":42},{"text":1415,"level":242},"How is this different from adjacent roles?",{"id":588,"data":1417,"type":218},{"text":1418},"Titles overlap heavily across companies. The useful distinction is the \u003Cstrong>scope of architecture responsibility\u003C\u002Fstrong>, not the HR label.",{"id":592,"data":1420,"type":299},{"rows":1421,"title":1438,"layout":291,"columns":1439},[1422,1424,1426,1429,1432,1435],{"id":596,"label":937,"values":1423},{"role":599,"focus":600},{"id":602,"label":958,"values":1425},{"role":605,"focus":606},{"id":608,"label":1427,"values":1428},"Enterprise AI Architect",{"role":611,"focus":612},{"id":614,"label":1430,"values":1431},"AI \u002F ML Engineer",{"role":617,"focus":618},{"id":620,"label":1433,"values":1434},"Security Architect",{"role":623,"focus":624},{"id":626,"label":1436,"values":1437},"Product \u002F Delivery Lead",{"role":629,"focus":630},"Adjacent roles answer different primary questions",[1440,1442],{"id":634,"label":1441},"Role",{"id":637,"label":1443},"Primary architecture focus",{"id":640,"data":1445,"type":218},{"text":1446},"In a small product team, one person may cover several of these scopes. In a large enterprise, they may be separate roles with formal review boards. The architecture responsibility does not disappear when the title changes.",{"id":644,"data":1448,"type":42},{"text":1449,"level":242},"Implementation evidence: how these boundaries appear in my own work",{"id":648,"data":1451,"type":225},{"body":1452,"title":1453,"variant":652},"The examples below are \u003Cstrong>original implementation\u002Fproject evidence\u003C\u002Fstrong>. They show how I have separated product need, requirements, architecture, runtime, model\u002Fprovider, permissions and validation in real project work. They are not claims that every organization must use the same structure, and they do not imply customer adoption or enterprise-scale deployment.","Implementation evidence, not a universal rule",{"id":654,"data":1455,"type":42},{"text":1456,"level":241},"SenseFlow: need → requirements → architecture → validation",{"id":658,"data":1458,"type":218},{"text":1459},"In the SenseFlow project Source of Truth, technology is explicitly subordinate to Product Vision. The development structure moves from problem and product vision through user needs, value, scope, epics, stories and acceptance criteria into architecture, implementation, validation and iteration.",{"id":662,"data":1461,"type":218},{"text":1462},"Requirements are designed to be traceable from Product Goal → Capability → Epic → User Story → Acceptance Criteria → Technical Tasks. Where practical, they include functional requirements, NFRs, dependencies, risks, assumptions, acceptance criteria and validation methods. Significant decisions preserve the decision, reason, alternatives, trade-offs, status and date\u002Fversion.",{"id":666,"data":1464,"type":218},{"text":1465},"That is architectural work before a specific AI framework or model is chosen: it protects the connection between product intent and technical decisions and makes later change reviewable rather than implicit.",{"id":670,"data":1467,"type":42},{"text":1468,"level":241},"Aaasaasa AI Client: separate concepts before integrating them",{"id":674,"data":1470,"type":218},{"text":1471},"Aaasaasa AI Client provides a more implementation-level example. Its AI Hub deliberately separates \u003Cstrong>agent\u002Fclient\u003C\u002Fstrong>, \u003Cstrong>provider\u003C\u002Fstrong>, \u003Cstrong>model\u003C\u002Fstrong>, \u003Cstrong>connection\u002Fruntime location\u003C\u002Fstrong>, \u003Cstrong>permissions\u003C\u002Fstrong> and \u003Cstrong>web client\u003C\u002Fstrong>. A local runtime is not assumed to mean local inference, and permissions are treated as runtime\u002Ftool policy rather than as a property of the model.",{"id":678,"data":1473,"type":218},{"text":1474},"The desktop architecture also defines a trust boundary: the Nuxt renderer is untrusted relative to Electron main. A narrow preload and validated IPC mediate access to AI services, settings, encrypted secrets, workspace\u002Fdata services and runtimes. Cloud credentials remain in the privileged main process; renderer code receives normalized state instead of raw secrets or unrestricted operating-system access.",{"id":682,"data":1476,"type":218},{"text":1477},"Routing decisions are similarly architectural. The implementation does not silently fall back from a local route to paid cloud inference; a cloud route requires explicit confirmation. Direct Chat has no filesystem or shell tools by default, while agent execution applies a selected workspace and permission profile. These are solution-level decisions about trust, cost, execution and user expectation—not model features.",{"id":686,"data":1479,"type":42},{"text":1480,"level":242},"How current architecture frameworks support this broader scope",{"id":690,"data":1482,"type":218},{"text":1483},"ISO\u002FIEC\u002FIEEE 42010:2022 provides a general discipline for architecture descriptions across software, systems and enterprises. It is deliberately broader than AI and does not prescribe one architecting method or job title. That makes it useful here as a boundary: AI solution architecture is still architecture, with stakeholder concerns, multiple views and significant relationships that must be expressed clearly.",{"id":694,"data":1485,"type":218},{"text":1486},"NIST AI RMF 1.0 frames AI risk management through \u003Cstrong>Govern, Map, Measure and Manage\u003C\u002Fstrong> and emphasizes that risk management should be continuous across the AI system lifecycle. The Generative AI Profile (NIST AI 600-1) adapts that framework to GAI risks and organizational priorities. This reinforces that architecture cannot stop at functional model performance.",{"id":698,"data":1488,"type":218},{"text":1489},"Microsoft’s current Azure Well-Architected AI guidance separates application design, application platform, training data, grounding data and data platform concerns and repeatedly connects them to reliability, security, operational excellence, performance and cost. AWS’s Generative AI and Agentic AI lenses similarly treat observability, security, reliability, model\u002Ftool lifecycle, cost and human oversight as architecture concerns.",{"id":702,"data":1491,"type":42},{"text":1492,"level":242},"Common misconceptions",{"id":706,"data":1494,"type":291},{"content":1495,"stretched":43,"withHeadings":14},[1496,1499,1502,1505,1508,1511,1514,1517],[1497,1498],"Misconception","Correction",[1500,1501],"“The architect chooses the LLM.”","Model choice is one decision inside a larger solution architecture.",[1503,1504],"“Prompt engineering is the architecture.”","Prompts affect behavior, but they do not define identity, data access, trust boundaries, deployment, tool permissions or operations.",[1506,1507],"“RAG solves enterprise knowledge.”","Retrieval is only one subsystem; authorization, provenance, freshness, evidence, indexing, evaluation and source governance still need design.",[1509,1510],"“Local runtime means private\u002Flocal AI.”","Runtime, inference, data and control-plane locations are separate architectural properties.",[1512,1513],"“If a vendor offers guardrails, security is covered.”","Security spans identity, authorization, secrets, data flows, tools, logging, deployment, human approval and provider boundaries.",[1515,1516],"“The architect must write every component.”","Hands-on implementation can improve architectural quality, but the role is defined by integrated decision responsibility, not by personally coding every layer.",[1518,1519],"“An architecture diagram proves production readiness.”","Readiness requires implemented controls and validation evidence across quality, security, operations and business acceptance.",{"id":734,"data":1521,"type":42},{"text":1522,"level":242},"Failure modes an AI Solution Architect should prevent",{"id":738,"data":1524,"type":291},{"content":1525,"stretched":43,"withHeadings":14},[1526,1530,1534,1538,1542,1546,1550,1554,1558],[1527,1528,1529],"Failure mode","Why it happens","Architectural correction",[1531,1532,1533],"Model-first design","A promising model demo becomes the system blueprint","Start from outcome, constraints and validation; select the model inside that frame",[1535,1536,1537],"Prototype permissions in production","Shared credentials and broad access survive the PoC","Define identity propagation, least privilege, tool scopes and approval boundaries early",[1539,1540,1541],"Retrieval without authorization","Search quality is designed before data-access rules","Carry user\u002Ftenant context into retrieval and enforce authorization at data-access boundaries",[1543,1544,1545],"Silent provider\u002Fruntime assumptions","“Local”, “cloud” and “offline” are used imprecisely","Document runtime, inference, data and control-plane location separately",[1547,1548,1549],"No failure contract","The happy path is designed but refusal\u002Ffallback\u002Ferror behavior is not","Specify retrieval-empty, model-unavailable, tool-failure and policy-denied behavior",[1551,1552,1553],"Evaluation after implementation","Quality is judged manually near launch","Define measurable acceptance and representative evaluation sets before architecture freezes",[1555,1556,1557],"Untraceable change","Models, prompts, retrieval or permissions change without architectural history","Version critical configuration and record significant decisions\u002Fvalidation evidence",[1559,1560,1561],"Operations treated as infrastructure only","AI behavior is not observable after deployment","Design traces, quality metrics, security events, cost telemetry and rollback together",{"id":778,"data":1563,"type":42},{"text":1564,"level":242},"A practical decision sequence",{"id":782,"data":1566,"type":339},{"steps":1567,"title":1592,"orientation":338},[1568,1571,1574,1577,1580,1583,1586,1589],{"label":1569,"description":1570},"Outcome","Define the user\u002Fbusiness result and explicit non-goals.",{"label":1572,"description":1573},"Evidence and constraints","Identify authoritative data, policies, NFRs, risks and acceptance conditions.",{"label":1575,"description":1576},"System boundary","Map users, identities, applications, data, models\u002Fproviders, tools and external systems.",{"label":1578,"description":1579},"Architecture options","Compare patterns for retrieval, model access, orchestration, deployment, permissions, evaluation and observability.",{"label":1581,"description":1582},"Trade-off decisions","Select significant options and preserve the rationale, alternatives and consequences.",{"label":1584,"description":1585},"Implementation contracts","Turn decisions into APIs, schemas, permission rules, deployment definitions and engineering tasks.",{"label":1587,"description":1588},"Validation","Test the implemented system against the original functional and non-functional requirements.",{"label":1590,"description":1591},"Operational feedback","Use production evidence, incidents, quality metrics and cost\u002Fsecurity signals to trigger controlled change.","AI solution architecture decision sequence",{"id":811,"data":1594,"type":42},{"text":1595,"level":242},"Edge cases and limits of the role",{"id":815,"data":1597,"type":218},{"text":1598},"Some AI products are dominated by model training, scientific experimentation or specialized hardware. In those cases, model\u002Fdata science and ML systems architecture can become much deeper than the solution-level map shown here. The AI Solution Architect still needs integration and operational boundaries, but specialist architecture may own the training platform itself.",{"id":819,"data":1600,"type":218},{"text":1601},"At the other extreme, a simple SaaS integration may not justify a dedicated architect. A senior engineer or technical product lead can carry the same architecture responsibility. The useful test is not the title but whether significant cross-layer decisions are being made deliberately and validated.",{"id":823,"data":1603,"type":218},{"text":1604},"Regulated, sovereign, air-gapped, safety-critical, highly autonomous or multi-tenant systems also shift the center of gravity. Identity, isolation, residency, assurance, update mechanisms, human oversight and auditability may dominate model quality in the architecture.",{"id":827,"data":1606,"type":42},{"text":1607,"level":242},"What would change this answer?",{"id":831,"data":1609,"type":218},{"text":1610},"The exact responsibility boundary changes when architecture moves from one application to a reusable platform or to enterprise-wide target architecture. That is why \u003Cstrong>AI Platform Architect\u003C\u002Fstrong> and \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> deserve separate canonical treatment rather than being merged into this role.",{"id":835,"data":1612,"type":218},{"text":1613},"Technology changes also matter. New model capabilities, protocols, local runtimes and managed services can remove some implementation work while creating new trust or operational boundaries. The stable responsibility is to understand those changes as system changes—not to treat a new framework as a replacement for architecture.",{"id":839,"data":1615,"type":42},{"text":1616,"level":242},"AI Solution Architect checklist",{"id":843,"data":1618,"type":291},{"content":1619,"stretched":43,"withHeadings":14},[1620,1623,1625,1628,1630,1633,1636,1639,1642,1645,1648,1651,1653],[1621,1622],"Check","Question",[1569,1624],"Is the user\u002Fbusiness result and non-goal boundary explicit?",[1626,1627],"Requirements","Are functional requirements, NFRs, constraints and acceptance criteria traceable?",[1152,1629],"Are authoritative sources, provenance, freshness, retention and access rules defined?",[1631,1632],"Retrieval\u002Fcontext","Does authorization reach retrieval and context construction?",[1634,1635],"Model\u002Fprovider","Is model\u002Fprovider selection tied to capabilities and constraints rather than preference?",[1637,1638],"Tools\u002Fagents","Are action boundaries, permissions, approvals and failure behavior explicit?",[1640,1641],"Identity\u002Fsecurity","Are human\u002Fmachine identities, secrets and trust boundaries defined?",[1643,1644],"Runtime","Are runtime, inference, data and control-plane locations distinguished?",[1646,1647],"Evaluation","Is there measurable evidence for quality, security and acceptance?",[1649,1650],"Observability","Can production behavior, failures, cost and security events be investigated?",[1161,1652],"Are significant architecture decisions and replacements traceable?",[1158,1654],"Is ownership for deployment, rollback, incidents and lifecycle clear?",{"id":883,"data":1656,"type":42},{"text":1657,"level":242},"Conclusion",{"id":887,"data":1659,"type":218},{"text":1660},"An AI Solution Architect is the person or architecture function that turns an AI opportunity into a coherent technical system. The key skill is not knowing the most model names; it is connecting product need, requirements, data, application architecture, AI capabilities, security, runtime, delivery and validation without losing the boundaries between them.",{"id":891,"data":1662,"type":218},{"text":1663},"A strong AI solution architecture can therefore be summarized as: \u003Cstrong>define the target → establish requirements and constraints → design the system boundaries → make significant trade-offs explicit → implement through clear contracts → validate against evidence → operate and evolve deliberately.\u003C\u002Fstrong> The model is important. The solution is the product.",{"id":895,"data":1665,"type":895},{"items":1666,"title":930},[1667,1670,1673,1676,1679,1682,1685,1688],{"id":899,"answer":1668,"question":1669},"An AI Solution Architect translates a business or product need into the architecture of a concrete AI-enabled solution, defining how application logic, data\u002Fretrieval, models, tools, identity, security, runtime, evaluation and operations work together.","What is an AI Solution Architect?",{"id":903,"answer":1671,"question":1672},"No. The roles can overlap, especially in small teams, but an AI engineer is primarily an implementation role while the solution architect owns or coordinates cross-layer architecture decisions and trade-offs for the complete workload.","Is an AI Solution Architect the same as an AI engineer?",{"id":907,"answer":1674,"question":1675},"Not by definition, but hands-on implementation knowledge is highly valuable because AI architecture crosses APIs, data, retrieval, security, runtimes and operational behavior. The role is defined by architecture responsibility, not by writing every component personally.","Does an AI Solution Architect need to code?",{"id":911,"answer":1677,"question":1678},"No. Model selection is one decision. Production architecture also needs data and retrieval boundaries, permissions, tools, provider\u002Fruntime choices, observability, evaluation, reliability, cost and lifecycle design.","Is choosing an LLM the main job?",{"id":915,"answer":1680,"question":1681},"An AI Solution Architect focuses on one concrete solution or workload. An AI Platform Architect focuses on reusable AI capabilities and guardrails that support multiple solutions.","What is the difference between an AI Solution Architect and an AI Platform Architect?",{"id":919,"answer":1683,"question":1684},"The solution architect works at application\u002Fworkload scope. Enterprise AI architecture works across the organizational portfolio, target architecture, governance, shared capabilities, integration principles and strategic constraints.","What is the difference between an AI Solution Architect and an Enterprise AI Architect?",{"id":923,"answer":1686,"question":1687},"They are architectural patterns or subsystems inside a solution when the requirements justify them. RAG addresses retrieval-grounded context; agents add planning\u002Ftool execution and therefore additional identity, permission, orchestration and operational concerns.","Where do RAG and agents fit?",{"id":927,"answer":1689,"question":1690},"Implementation plus validation evidence: functional tests, evaluation results, security\u002Fauthorization tests, performance and reliability measurements, observability, operational rehearsal and acceptance against the original requirements.","What proves that the architecture works?",{"id":932,"data":1692,"type":932},{"title":1693,"entries":1694},"Core terms",[1695,1697,1699,1702,1705,1707,1709,1711],{"term":937,"anchor":938,"definition":1696},"Architecture responsibility for one concrete AI-enabled solution or workload, integrating product requirements with application, data, model, tool, security, runtime and operational design.",{"term":1575,"anchor":941,"definition":1698},"The explicit separation between what belongs to the solution and the users, systems, providers, data sources and environments it interacts with.",{"term":1700,"anchor":945,"definition":1701},"Trust boundary","A point where data, identities or control cross between components with different trust assumptions and therefore require explicit security controls.",{"term":1703,"anchor":949,"definition":1704},"Grounding","Supplying an AI model with relevant external information or evidence so its response can be based on sources beyond model parameters.",{"term":1394,"anchor":952,"definition":1706},"An application boundary that decouples parts of the solution from one model\u002Fprovider interface. Useful when justified by routing, portability or policy needs, but not free of trade-offs.",{"term":1646,"anchor":955,"definition":1708},"Structured measurement of AI workload behavior against defined acceptance criteria, including task quality and relevant safety, security, performance and operational properties.",{"term":958,"anchor":959,"definition":1710},"Architectural role focused on reusable AI platform capabilities used by multiple solutions rather than the architecture of one workload.",{"term":962,"anchor":963,"definition":1712},"Organization-level architecture that coordinates AI capabilities, platforms, governance, integration and strategic constraints across a portfolio.",{"id":966,"data":1714,"type":42},{"text":1715,"level":242},"Related canonical knowledge",{"id":970,"data":1717,"type":218},{"text":1718},"This article sits in the AI Architecture Foundations cluster. Its direct foundations are \u003Cstrong>Generative AI Explained: Models, Retrieval, Tools and Applications Are Not the Same Thing\u003C\u002Fstrong> and \u003Cstrong>ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing\u003C\u002Fstrong>. Adjacent canonical nodes include \u003Cstrong>Agentic AI Explained\u003C\u002Fstrong>, \u003Cstrong>Source of Truth in AI Systems\u003C\u002Fstrong>, \u003Cstrong>Vector Databases, Embeddings and Reranking\u003C\u002Fstrong>, \u003Cstrong>What Is Context Engineering?\u003C\u002Fstrong>, \u003Cstrong>RBAC vs Tenant Isolation\u003C\u002Fstrong>, \u003Cstrong>AI Platform Architect\u003C\u002Fstrong>, \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> and \u003Cstrong>AI Governance\u003C\u002Fstrong>. URLs are intentionally not fabricated where those nodes are not yet published.",{"id":974,"data":1720,"type":982},{"link":1721,"meta":1722},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works",{"image":1723,"title":980,"description":1724},{"url":979},"Existing stajic.de canonical explanation of retrieval-augmented generation, useful for the retrieval\u002Fgrounding part of AI solution architecture.",{"id":984,"data":1726,"type":42},{"text":1727,"level":242},"Primary sources and current architecture guidance",{"id":988,"data":1729,"type":218},{"text":1730},"External sources below support the general architecture claims; the SenseFlow and Aaasaasa AI Client sections are explicitly original project\u002Fimplementation evidence. Current-state references were checked on 8 October 2026. NIST notes that AI RMF 1.0 is being revised, so version-sensitive governance references should be rechecked when a successor is published.",{"id":992,"data":1732,"type":982},{"link":994,"meta":1733},{"image":1734,"title":997,"description":1735},{"url":979},"Current international standard for the structure and expression of architecture descriptions. It distinguishes architecture from its description and does not prescribe one architecting method, tool or recording format.",{"id":1000,"data":1737,"type":982},{"link":1002,"meta":1738},{"image":1739,"title":1005,"description":1740},{"url":979},"NIST’s AI RMF resource page. As of October 2026 it states that AI RMF 1.0 is being revised and links the Generative AI Profile and related resources.",{"id":1008,"data":1742,"type":982},{"link":1010,"meta":1743},{"image":1744,"title":1013,"description":1745},{"url":979},"Official NIST AIRC presentation of the AI RMF 1.0 Core, including the four functions and lifecycle-oriented risk-management framing.",{"id":1016,"data":1747,"type":982},{"link":1018,"meta":1748},{"image":1749,"title":1021,"description":1750},{"url":979},"Cross-sectoral Generative AI profile for AI RMF 1.0, published 26 July 2024 and updated by NIST in 2026.",{"id":1024,"data":1752,"type":982},{"link":1026,"meta":1753},{"image":1754,"title":1029,"description":1755},{"url":979},"Current workload-level architecture guidance covering AI application design, application platform, training data, grounding data, data platform and production-readiness concerns.",{"id":1032,"data":1757,"type":982},{"link":1034,"meta":1758},{"image":1759,"title":1037,"description":1760},{"url":979},"Guidance on model\u002Ftool abstraction, data-access boundaries, identity propagation, authorization and separation of client, intelligence, knowledge and tool layers.",{"id":1040,"data":1762,"type":982},{"link":1042,"meta":1763},{"image":1764,"title":1045,"description":1765},{"url":979},"Current AI workload design principles across reliability, security, cost, operational excellence and performance, including identity and data-protection responsibilities.",{"id":1048,"data":1767,"type":982},{"link":1050,"meta":1768},{"image":1769,"title":1053,"description":1770},{"url":979},"Production lifecycle guidance covering monitoring, quality gates, model\u002Fprompt behavior, security and operational measurement.",{"id":1056,"data":1772,"type":982},{"link":1058,"meta":1773},{"image":1774,"title":1061,"description":1775},{"url":979},"AWS architectural guidance for generative AI workloads across operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.",{"id":1064,"data":1777,"type":982},{"link":1066,"meta":1778},{"image":1779,"title":1069,"description":1780},{"url":979},"Published in 2026, covering agentic-specific architecture concerns including identities, tools, orchestration, human oversight, reliability, tracing and reasoning-loop cost.","2.31.0","An AI Solution Architect turns business requirements into a production-ready AI system across data, models, tools, security, runtime, evaluation and operations.",{"lang":7,"title":208,"content":210,"contentJson":1784,"excerpt":1072},{"time":212,"blocks":1785,"version":1071},[1786,1788,1790,1792,1794,1796,1798,1800,1802,1818,1820,1822,1824,1834,1836,1838,1840,1842,1844,1858,1860,1862,1864,1866,1868,1870,1872,1874,1876,1878,1880,1882,1884,1886,1888,1890,1892,1894,1896,1898,1900,1902,1904,1916,1918,1920,1931,1933,1935,1953,1955,1957,1959,1961,1963,1965,1967,1969,1971,1973,1975,1977,1979,1981,1983,1985,1996,1998,2010,2012,2023,2025,2027,2029,2031,2033,2035,2037,2039,2055,2057,2059,2061,2072,2083,2085,2087,2091,2093,2095,2099,2103,2107,2111,2115,2119,2123,2127,2131],{"id":215,"data":1787,"type":218},{"text":217},{"id":220,"data":1789,"type":225},{"body":222,"title":223,"variant":224},{"id":227,"data":1791,"type":225},{"body":229,"title":230,"variant":231},{"id":233,"data":1793,"type":225},{"body":235,"title":236,"variant":231},{"id":238,"data":1795,"type":243},{"title":240,"maxLevel":241,"minLevel":242},{"id":245,"data":1797,"type":42},{"text":247,"level":242},{"id":249,"data":1799,"type":218},{"text":251},{"id":253,"data":1801,"type":218},{"text":255},{"id":257,"data":1803,"type":299},{"rows":1804,"title":290,"layout":291,"columns":1815},[1805,1807,1809,1811,1813],{"id":261,"label":262,"values":1806},{"model":264,"solution":265},{"id":267,"label":268,"values":1808},{"model":270,"solution":271},{"id":273,"label":274,"values":1810},{"model":276,"solution":277},{"id":279,"label":280,"values":1812},{"model":282,"solution":283},{"id":285,"label":286,"values":1814},{"model":288,"solution":289},[1816,1817],{"id":294,"label":295},{"id":297,"label":298},{"id":301,"data":1819,"type":42},{"text":303,"level":242},{"id":305,"data":1821,"type":218},{"text":307},{"id":309,"data":1823,"type":218},{"text":311},{"id":313,"data":1825,"type":339},{"steps":1826,"title":337,"orientation":338},[1827,1828,1829,1830,1831,1832,1833],{"label":317,"description":318},{"label":320,"description":321},{"label":323,"description":324},{"label":326,"description":327},{"label":329,"description":330},{"label":332,"description":333},{"label":335,"description":336},{"id":341,"data":1835,"type":42},{"text":343,"level":242},{"id":345,"data":1837,"type":218},{"text":347},{"id":349,"data":1839,"type":218},{"text":351},{"id":353,"data":1841,"type":42},{"text":355,"level":242},{"id":357,"data":1843,"type":218},{"text":359},{"id":361,"data":1845,"type":291},{"content":1846,"stretched":43,"withHeadings":14},[1847,1848,1849,1850,1851,1852,1853,1854,1855,1856,1857],[365,366,367],[369,370,371],[373,374,375],[377,378,379],[381,382,383],[385,386,387],[389,390,391],[393,394,395],[397,398,399],[401,402,403],[405,406,407],{"id":409,"data":1859,"type":42},{"text":411,"level":241},{"id":413,"data":1861,"type":218},{"text":415},{"id":417,"data":1863,"type":218},{"text":419},{"id":421,"data":1865,"type":42},{"text":423,"level":241},{"id":425,"data":1867,"type":218},{"text":427},{"id":429,"data":1869,"type":218},{"text":431},{"id":433,"data":1871,"type":42},{"text":435,"level":241},{"id":437,"data":1873,"type":218},{"text":439},{"id":441,"data":1875,"type":218},{"text":443},{"id":445,"data":1877,"type":42},{"text":447,"level":241},{"id":449,"data":1879,"type":218},{"text":451},{"id":453,"data":1881,"type":218},{"text":455},{"id":457,"data":1883,"type":42},{"text":459,"level":241},{"id":461,"data":1885,"type":218},{"text":463},{"id":465,"data":1887,"type":218},{"text":467},{"id":469,"data":1889,"type":42},{"text":471,"level":241},{"id":473,"data":1891,"type":218},{"text":475},{"id":477,"data":1893,"type":218},{"text":479},{"id":481,"data":1895,"type":42},{"text":483,"level":241},{"id":485,"data":1897,"type":218},{"text":487},{"id":489,"data":1899,"type":218},{"text":491},{"id":493,"data":1901,"type":42},{"text":495,"level":242},{"id":497,"data":1903,"type":218},{"text":499},{"id":501,"data":1905,"type":291},{"content":1906,"stretched":43,"withHeadings":14},[1907,1908,1909,1910,1911,1912,1913,1914,1915],[505,506],[508,509],[511,512],[514,515],[517,518],[520,521],[523,524],[526,527],[529,530],{"id":532,"data":1917,"type":42},{"text":534,"level":242},{"id":536,"data":1919,"type":218},{"text":538},{"id":540,"data":1921,"type":291},{"content":1922,"stretched":43,"withHeadings":14},[1923,1924,1925,1926,1927,1928,1929,1930],[544,545,546,547],[549,550,551,552],[554,555,556,557],[559,560,561,562],[564,565,566,567],[569,570,571,572],[574,575,576,577],[579,580,581,582],{"id":584,"data":1932,"type":42},{"text":586,"level":242},{"id":588,"data":1934,"type":218},{"text":590},{"id":592,"data":1936,"type":299},{"rows":1937,"title":631,"layout":291,"columns":1950},[1938,1940,1942,1944,1946,1948],{"id":596,"label":597,"values":1939},{"role":599,"focus":600},{"id":602,"label":603,"values":1941},{"role":605,"focus":606},{"id":608,"label":609,"values":1943},{"role":611,"focus":612},{"id":614,"label":615,"values":1945},{"role":617,"focus":618},{"id":620,"label":621,"values":1947},{"role":623,"focus":624},{"id":626,"label":627,"values":1949},{"role":629,"focus":630},[1951,1952],{"id":634,"label":635},{"id":637,"label":638},{"id":640,"data":1954,"type":218},{"text":642},{"id":644,"data":1956,"type":42},{"text":646,"level":242},{"id":648,"data":1958,"type":225},{"body":650,"title":651,"variant":652},{"id":654,"data":1960,"type":42},{"text":656,"level":241},{"id":658,"data":1962,"type":218},{"text":660},{"id":662,"data":1964,"type":218},{"text":664},{"id":666,"data":1966,"type":218},{"text":668},{"id":670,"data":1968,"type":42},{"text":672,"level":241},{"id":674,"data":1970,"type":218},{"text":676},{"id":678,"data":1972,"type":218},{"text":680},{"id":682,"data":1974,"type":218},{"text":684},{"id":686,"data":1976,"type":42},{"text":688,"level":242},{"id":690,"data":1978,"type":218},{"text":692},{"id":694,"data":1980,"type":218},{"text":696},{"id":698,"data":1982,"type":218},{"text":700},{"id":702,"data":1984,"type":42},{"text":704,"level":242},{"id":706,"data":1986,"type":291},{"content":1987,"stretched":43,"withHeadings":14},[1988,1989,1990,1991,1992,1993,1994,1995],[710,711],[713,714],[716,717],[719,720],[722,723],[725,726],[728,729],[731,732],{"id":734,"data":1997,"type":42},{"text":736,"level":242},{"id":738,"data":1999,"type":291},{"content":2000,"stretched":43,"withHeadings":14},[2001,2002,2003,2004,2005,2006,2007,2008,2009],[742,743,744],[746,747,748],[750,751,752],[754,755,756],[758,759,760],[762,763,764],[766,767,768],[770,771,772],[774,775,776],{"id":778,"data":2011,"type":42},{"text":780,"level":242},{"id":782,"data":2013,"type":339},{"steps":2014,"title":809,"orientation":338},[2015,2016,2017,2018,2019,2020,2021,2022],{"label":786,"description":787},{"label":789,"description":790},{"label":792,"description":793},{"label":795,"description":796},{"label":798,"description":799},{"label":801,"description":802},{"label":804,"description":805},{"label":807,"description":808},{"id":811,"data":2024,"type":42},{"text":813,"level":242},{"id":815,"data":2026,"type":218},{"text":817},{"id":819,"data":2028,"type":218},{"text":821},{"id":823,"data":2030,"type":218},{"text":825},{"id":827,"data":2032,"type":42},{"text":829,"level":242},{"id":831,"data":2034,"type":218},{"text":833},{"id":835,"data":2036,"type":218},{"text":837},{"id":839,"data":2038,"type":42},{"text":841,"level":242},{"id":843,"data":2040,"type":291},{"content":2041,"stretched":43,"withHeadings":14},[2042,2043,2044,2045,2046,2047,2048,2049,2050,2051,2052,2053,2054],[847,848],[786,850],[852,853],[268,855],[857,858],[860,861],[863,864],[866,867],[869,870],[872,873],[875,876],[878,879],[280,881],{"id":883,"data":2056,"type":42},{"text":885,"level":242},{"id":887,"data":2058,"type":218},{"text":889},{"id":891,"data":2060,"type":218},{"text":893},{"id":895,"data":2062,"type":895},{"items":2063,"title":930},[2064,2065,2066,2067,2068,2069,2070,2071],{"id":899,"answer":900,"question":901},{"id":903,"answer":904,"question":905},{"id":907,"answer":908,"question":909},{"id":911,"answer":912,"question":913},{"id":915,"answer":916,"question":917},{"id":919,"answer":920,"question":921},{"id":923,"answer":924,"question":925},{"id":927,"answer":928,"question":929},{"id":932,"data":2073,"type":932},{"title":934,"entries":2074},[2075,2076,2077,2078,2079,2080,2081,2082],{"term":937,"anchor":938,"definition":939},{"term":792,"anchor":941,"definition":942},{"term":944,"anchor":945,"definition":946},{"term":948,"anchor":949,"definition":950},{"term":564,"anchor":952,"definition":953},{"term":872,"anchor":955,"definition":956},{"term":958,"anchor":959,"definition":960},{"term":962,"anchor":963,"definition":964},{"id":966,"data":2084,"type":42},{"text":968,"level":242},{"id":970,"data":2086,"type":218},{"text":972},{"id":974,"data":2088,"type":982},{"link":976,"meta":2089},{"image":2090,"title":980,"description":981},{"url":979},{"id":984,"data":2092,"type":42},{"text":986,"level":242},{"id":988,"data":2094,"type":218},{"text":990},{"id":992,"data":2096,"type":982},{"link":994,"meta":2097},{"image":2098,"title":997,"description":998},{"url":979},{"id":1000,"data":2100,"type":982},{"link":1002,"meta":2101},{"image":2102,"title":1005,"description":1006},{"url":979},{"id":1008,"data":2104,"type":982},{"link":1010,"meta":2105},{"image":2106,"title":1013,"description":1014},{"url":979},{"id":1016,"data":2108,"type":982},{"link":1018,"meta":2109},{"image":2110,"title":1021,"description":1022},{"url":979},{"id":1024,"data":2112,"type":982},{"link":1026,"meta":2113},{"image":2114,"title":1029,"description":1030},{"url":979},{"id":1032,"data":2116,"type":982},{"link":1034,"meta":2117},{"image":2118,"title":1037,"description":1038},{"url":979},{"id":1040,"data":2120,"type":982},{"link":1042,"meta":2121},{"image":2122,"title":1045,"description":1046},{"url":979},{"id":1048,"data":2124,"type":982},{"link":1050,"meta":2125},{"image":2126,"title":1053,"description":1054},{"url":979},{"id":1056,"data":2128,"type":982},{"link":1058,"meta":2129},{"image":2130,"title":1061,"description":1062},{"url":979},{"id":1064,"data":2132,"type":982},{"link":1066,"meta":2133},{"image":2134,"title":1069,"description":1070},{"url":979},"Post erfolgreich abgerufen",{"items":2137,"source":2222,"manualIds":2223,"manualMatchedIds":2224},[2138,2145,2152,2159,2166,2173,2180,2187,2194,2201,2208,2215],{"id":2139,"slug":2140,"title":2141,"excerpt":2142,"featuredImage":2143,"publishedAt":2144},"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":2146,"slug":2147,"title":2148,"excerpt":2149,"featuredImage":2150,"publishedAt":2151},"468","ai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context","Память ИИ-агента — это не RAG: как разграничить память, извлечение, состояние и контекст","Память агента, RAG, состояние и контекст часто используются так, будто они взаимозаменяемы. Это не так. Эта практическая архитектурная модель разделяет четыре уровня, показывает, где место каждого из них, и объясняет, что ломается, когда системы объединяют их в одно целое.","\u002Fuploads\u002F2026\u002F09\u002Fai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context-1790350560308-np0xy6.webp","2026-09-25T11:34:00.000Z",{"id":2153,"slug":2154,"title":2155,"excerpt":2156,"featuredImage":2157,"publishedAt":2158},"381","enterprise-grade-multi-tenant-architecture-for-an-international-platform","Мультитенантная архитектура корпоративного уровня для международной платформы","Loving Rocks является корпоративной свадебной платформой, разработанной с истинной многоарендной архитектурой, изолированными базами данных для каждого арендатора и встроенной интернационализацией для глобальной масштабируемости, безопасности и долгосрочной операционной стабильности.","\u002Fuploads\u002F2026\u002F01\u002Fenterprise-grade-multi-tenant-architecture-for-an-international-platform-1769789121298-b6v7ak.webp","2026-01-30T12:04:00.000Z",{"id":2160,"slug":2161,"title":2162,"excerpt":2163,"featuredImage":2164,"publishedAt":2165},"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":2167,"slug":2168,"title":2169,"excerpt":2170,"featuredImage":2171,"publishedAt":2172},"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":2174,"slug":2175,"title":2176,"excerpt":2177,"featuredImage":2178,"publishedAt":2179},"484","what-is-an-ai-platform-architect-models-data-runtime-security-and-operations","Что такое архитектор AI-платформы? Модели, данные, среда выполнения, безопасность и операции","Архитектор платформы ИИ проектирует многоразовые основы ИИ для моделей, провайдеров, поиска, агентов, идентификации, безопасности, оценки, наблюдаемости и операций.","\u002Fuploads\u002F2026\u002F10\u002Fwhat-is-an-ai-platform-architect-models-data-runtime-security-and-operations-1791477229171-ou3zcc.webp","2026-10-08T12:32:00.000Z",{"id":2181,"slug":2182,"title":2183,"excerpt":2184,"featuredImage":2185,"publishedAt":2186},"494","air-gapped-ai-how-ai-systems-work-without-internet-or-cloud-access","Air-Gapped AI: как работают ИИ-системы без интернета и облачного доступа","AI-системы в изолированной среде запускают модели, RAG и AI-приложения внутри изолированного домена безопасности без зависимости от интернета или облачных сервисов. Узнайте, как модели, данные, обновления и инструменты работают в автономном режиме.","\u002Fuploads\u002F2026\u002F10\u002Fair-gapped-ai-how-ai-systems-work-without-internet-or-cloud-access-1791487983978-e6xqf0.webp","2026-10-08T11:32:00.000Z",{"id":2188,"slug":2189,"title":2190,"excerpt":2191,"featuredImage":2192,"publishedAt":2193},"466","the-gpu-is-not-the-product-future-proof-private-ai-architecture","GPU — не продукт: перспективная архитектура приватного ИИ","Инфраструктура приватного ИИ не должна проектироваться вокруг одного GPU или одной модели. Более устойчивый подход объединяет быстрые GPU для инференса, ИИ-системы с большим объемом памяти, узлы физического ИИ и опциональные передовые облачные модели за уровнем маршрутизации, учитывающим возможности.","\u002Fuploads\u002F2026\u002F09\u002Fthe-gpu-is-not-the-product-future-proof-private-ai-architecture-1790140878812-8hsl39.webp","2026-09-23T01:19:00.000Z",{"id":2195,"slug":2196,"title":2197,"excerpt":2198,"featuredImage":2199,"publishedAt":2200},"478","what-is-rag-the-simplest-explanation-of-how-it-works","Что такое RAG? Самое простое объяснение того, как это работает","RAG звучит сложно, но идея проста: прежде чем ИИ ответит, он сначала находит полезную информацию из источника знаний и передаёт эту информацию языковой модели. В этом руководстве объясняются RAG, LLM, состояние, память и инструменты с помощью одной простой ментальной модели.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works-1790377492124-khjagt.webp","2026-09-25T19:03:00.000Z",{"id":2202,"slug":2203,"title":2204,"excerpt":2205,"featuredImage":2206,"publishedAt":2207},"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",{"id":2209,"slug":2210,"title":2211,"excerpt":2212,"featuredImage":2213,"publishedAt":2214},"470","what-should-an-ai-agent-remember-forget-recompute-or-retrieve-again","Что ИИ-агент должен помнить, забывать, перевычислять или извлекать повторно?","Долгоживущие агенты не должны помнить всё. В этой статье представлена практическая модель жизненного цикла для определения того, что относится к долговременной памяти, что следует извлекать повторно, что безопаснее пересчитать, а что должно истечь по сроку действия или быть заменено.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-should-an-ai-agent-remember-forget-recompute-or-retrieve-again-1790351131087-iehz28.webp","2026-09-25T09:43:00.000Z",{"id":2216,"slug":2217,"title":2218,"excerpt":2219,"featuredImage":2220,"publishedAt":2221},"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","fallback",[],[]]