[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:es":3,"public-menus:all":38,"post:what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs:es":205,"related:post:what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs:es:1":2146},{"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","es","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":2145},{"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","¿Qué es un arquitecto de soluciones de IA? Límites del sistema, responsabilidades y compensaciones","what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u003Cp>Un \u003Cstrong>Arquitecto de Soluciones de IA\u003C\u002Fstrong> traduce una necesidad de negocio o de producto en la arquitectura de una solución concreta habilitada por IA. El rol define los límites del sistema y las decisiones significativas en cuanto a lógica de aplicación, datos autorizados, recuperación y contexto, modelos y proveedores, herramientas o agentes, identidad y permisos, seguridad, tiempo de ejecución y despliegue, observabilidad, evaluación, costo y comportamiento operativo. No se trata simplemente de selección de modelos o ingeniería de prompts: la responsabilidad arquitectónica es hacer que toda la solución sea implementable, gobernable, verificable y operable.\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\">Respuesta directa\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>Un Arquitecto de Soluciones de IA diseña la solución completa habilitada por IA, no solo el modelo de IA.\u003C\u002Fstrong> El rol conecta los requisitos y los requisitos no funcionales con las decisiones de arquitectura, compone las capas necesarias de aplicación\u002Fdatos\u002Fmodelo\u002Fherramientas\u002Ftiempo de ejecución, hace explícitos los límites de confianza y de fallo, y define cómo se validará y operará el sistema implementado.\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\">Nota terminológica\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>Arquitecto de Soluciones de IA es una etiqueta práctica de rol, no un título profesional universalmente estandarizado.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 estandariza conceptos para descripciones de arquitectura; no define este rol laboral. Las organizaciones pueden distribuir las responsabilidades entre varias personas. En este artículo, el término significa la responsabilidad de arquitectura para una solución o carga de trabajo concreta habilitada por IA.\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\">Nota sobre fuentes actuales — 8 de octubre de 2026\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Los principios de arquitectura aquí son intencionalmente neutrales respecto al proveedor, mientras que la guía actual de proveedores se utiliza como evidencia de implementación. NIST AI RMF 1.0 está actualmente en revisión; NIST AI 600-1 sigue siendo el Perfil de IA Generativa publicado. La guía de Microsoft y AWS citada a continuación refleja preocupaciones actuales de producción como identidad, límites de datos, abstracción de modelos, seguridad, observabilidad, evaluación, confiabilidad y costo.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Contenido\">\u003Cstrong class=\"editorjs-toc__title\">Contenido\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\">¿Qué arquitecta realmente un Arquitecto de Soluciones de IA?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">El ejemplo más simple\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-14\" class=\"editorjs-toc__link\">Donde se detiene el ejemplo simple\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-17\" class=\"editorjs-toc__link\">Mapa de responsabilidades de arquitectura\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. Convertir la necesidad del producto en requisitos arquitectónicos\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-23\" class=\"editorjs-toc__link\">2. Diseñar datos autoritativos, recuperación y contexto\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-26\" class=\"editorjs-toc__link\">3. Tratar los modelos y proveedores como dependencias, no como todo el sistema\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-29\" class=\"editorjs-toc__link\">4. Arquitecturar herramientas, acciones y límites de agentes\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-32\" class=\"editorjs-toc__link\">5. Hacer explícitos los límites de confianza y los permisos\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-35\" class=\"editorjs-toc__link\">6. Decidir dónde se ejecuta realmente el sistema\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-38\" class=\"editorjs-toc__link\">7. Definir la evaluación, la observabilidad y la aceptación operativa\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-41\" class=\"editorjs-toc__link\">¿Qué debería producir el rol?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-44\" class=\"editorjs-toc__link\">El trabajo es principalmente compensaciones, no selección de 'mejores prácticas'\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-47\" class=\"editorjs-toc__link\">¿En qué se diferencia de roles adyacentes?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-51\" class=\"editorjs-toc__link\">Evidencia de implementación: cómo aparecen estos límites en mi propio trabajo\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: necesidad → requisitos → arquitectura → validación\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-57\" class=\"editorjs-toc__link\">Aaasaasa AI Client: separar conceptos antes de integrarlos\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-61\" class=\"editorjs-toc__link\">Cómo los marcos de arquitectura actuales apoyan este alcance más amplio\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-65\" class=\"editorjs-toc__link\">Conceptos erróneos comunes\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-67\" class=\"editorjs-toc__link\">Modos de falla que un Arquitecto de Soluciones de IA debe prevenir\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-69\" class=\"editorjs-toc__link\">Una secuencia de decisión práctica\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-71\" class=\"editorjs-toc__link\">Casos límite y límites del rol\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-75\" class=\"editorjs-toc__link\">¿Qué cambiaría esta respuesta?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-78\" class=\"editorjs-toc__link\">Lista de verificación del AI Solution Architect\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-80\" class=\"editorjs-toc__link\">Conclusión\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-85\" class=\"editorjs-toc__link\">Conocimiento canónico relacionado\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-88\" class=\"editorjs-toc__link\">Fuentes primarias y guía arquitectónica actual\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-6\">¿Qué arquitecta realmente un Arquitecto de Soluciones de IA?\u003C\u002Fh2>\n\u003Cp>El objeto del trabajo es la \u003Cstrong>solución\u003C\u002Fstrong>: el sistema sociotécnico completo que convierte una necesidad en un comportamiento útil y controlado. Un modelo puede ser central para ese sistema, pero sigue siendo solo una dependencia. El mismo modelo puede participar en un asistente de búsqueda interno seguro, un agente inseguro con privilegios excesivos, una función de cliente de baja latencia o un prototipo de alto costo que no puede operarse económicamente. La arquitectura determina esas diferencias.\u003C\u002Fp>\n\u003Cp>Un límite útil es, por lo tanto: \u003Cstrong>resultado de negocio → requisitos → responsabilidades del sistema → decisiones de arquitectura → implementación → validación → operación\u003C\u002Fstrong>. El Arquitecto de Soluciones de IA trabaja a lo largo de esta cadena mientras colabora con producto, ingeniería, datos, seguridad, infraestructura, gobernanza y especialistas de dominio.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">La solución es más amplia que el modelo\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\">Pregunta centrada en el modelo\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\">Pregunta de arquitectura de solución\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\">Capacidad\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\">Datos\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\">Seguridad\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\">Operaciones\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\">Cambio\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\">El ejemplo más simple\u003C\u002Fh2>\n\u003Cp>Imagina que una empresa quiere un asistente interno que responda las preguntas de los técnicos a partir de manuales de mantenimiento y procedimientos operativos. La función visible suena simple: escribir una pregunta y recibir una respuesta con fuentes.\u003C\u002Fp>\n\u003Cp>La pregunta de arquitectura es mucho más amplia. ¿Qué documentos son autorizados? ¿Cómo se autentican los usuarios? ¿La recuperación debe respetar los permisos de departamento o sitio? ¿La respuesta puede usar solo evidencia recuperada? ¿Qué modelo es aceptable para la clasificación de datos? ¿Puede un proveedor de nube recibir el contenido? ¿Qué sucede cuando la recuperación no encuentra nada? ¿Cómo se producen las citas? ¿Cómo se evalúa la calidad de las respuestas? ¿Qué latencia y costo son aceptables? ¿Quién puede ver los registros y qué puede almacenarse en ellos?\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">De la necesidad a una solución de IA operable\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. Definir el resultado\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Aclarar el usuario, el valor de negocio, el límite de la tarea y qué significa una respuesta o acción exitosa.\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. Capturar requisitos\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Hacer explícitos los requisitos funcionales, los RNF, las restricciones, las reglas de datos, la tolerancia al riesgo y los criterios de aceptación.\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. Establecer límites\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Identificar usuarios, identidades, aplicaciones, datos autorizados, dependencias de modelo\u002Fproveedor, herramientas, sistemas externos y zonas de confianza.\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. Diseñar la arquitectura\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Elegir patrones de datos\u002Frecuperación, modelo, orquestación, herramientas, permisos, tiempo de ejecución, despliegue, respaldo y observabilidad.\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. Registrar decisiones significativas\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Preservar las elecciones arquitectónicas, alternativas, compensaciones y consecuencias para que los cambios posteriores sigan siendo comprensibles.\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. Implementar e integrar\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Convertir la arquitectura en código de aplicación, API, políticas, infraestructura, flujos de trabajo y controles operativos.\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. Validar y operar\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Probar calidad, seguridad, confiabilidad, costo y resultados de usuario; monitorear la carga de trabajo real y retroalimentar las decisiones con evidencia.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-14\">Donde se detiene el ejemplo simple\u003C\u002Fh2>\n\u003Cp>Una prueba de concepto a menudo puede omitir la arquitectura que producción no puede. Un desarrollador puede codificar un solo proveedor, usar una clave de API compartida, colocar todos los documentos en un solo índice, ejecutar la recuperación sin filtrado por contexto de usuario, registrar los prompts textualmente y juzgar la calidad manualmente. Eso puede demostrar viabilidad, pero no establece una arquitectura de producción.\u003C\u002Fp>\n\u003Cp>Producción introduce restricciones que interactúan: aislamiento de inquilino o usuario, privacidad, residencia de datos, rendimiento, latencia, costo, cuotas del proveedor, comportamiento de respaldo, auditabilidad, cambios de versión del modelo, calidad de recuperación, permisos de herramientas, respuesta a incidentes y ciclo de vida de despliegue. El trabajo del arquitecto no es maximizar cada cualidad a la vez; es hacer explícitas las compensaciones y diseñar una solución que satisfaga el conjunto de prioridades real.\u003C\u002Fp>\n\u003Ch2 id=\"section-17\">Mapa de responsabilidades de arquitectura\u003C\u002Fh2>\n\u003Cp>La división exacta varía según la organización, pero el siguiente mapa captura las responsabilidades recurrentes de la arquitectura de IA a nivel de solución. Es posible que el arquitecto no implemente personalmente cada capa; la responsabilidad es hacer que las capas encajen de forma coherente y mantener trazables las decisiones críticas.\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\">Área de arquitectura\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Preguntas que el Arquitecto de Soluciones de IA debe resolver\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Salidas típicas\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Resultado y alcance\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Quién es el usuario? ¿Qué tarea está en alcance? ¿Qué no debe hacer el sistema? ¿Qué constituye el éxito?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Contexto de la solución, límite de capacidad, criterios de aceptación\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Requisitos y NFR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Qué restricciones de calidad, seguridad, disponibilidad, latencia, costo, residencia y cumplimiento aplican?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mapa de requisitos, NFR, restricciones, criterios de validación\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Aplicación y orquestación\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Dónde termina la lógica de aplicación determinista y dónde comienza el comportamiento de IA? ¿Cómo se coordinan los flujos de trabajo?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modelo de componentes, API, límites de orquestación, rutas de fallo\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Datos autoritativos y recuperación\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Cuál es la Fuente de Verdad? ¿Cómo se ingieren, autorizan, recuperan, filtran, clasifican y citan los datos?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Flujos de datos, arquitectura de recuperación, metadatos y reglas de autorización\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Capa de modelo y proveedor\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Qué capacidades se requieren? ¿Qué restricciones de proveedor\u002Fentorno de ejecución importan? ¿Qué debería abstraerse?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Decisión de modelo\u002Fproveedor, política de enrutamiento\u002Ffallback, límite de abstracción\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Herramientas y agentes\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Qué acciones puede tomar el sistema? ¿Qué acciones requieren aprobación? ¿Cómo se aplican las identidades y permisos de las herramientas?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Contratos de herramientas, límites de agentes, reglas de aprobación y privilegio mínimo\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Identidad y seguridad\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Qué identidades humanas y de máquina existen? ¿Dónde se guardan los secretos? ¿Qué límites de confianza se cruzan?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modelo de amenazas\u002Flímites de confianza, propagación de identidad, diseño de secretos y autorización\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Entorno de ejecución y despliegue\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Dónde se ejecutan los componentes? ¿Qué es local, nube, borde o híbrido? ¿Qué suposiciones de red y disponibilidad existen?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Vista de despliegue, topología de ejecución, decisiones de entorno y conectividad\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Evaluación y observabilidad\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Cómo se mide la calidad antes y después del lanzamiento? ¿Qué trazas, métricas, registros y evidencia se necesitan?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Plan de evaluación, telemetría, pista de auditoría, puertas de lanzamiento\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Operaciones y cambio\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Cómo se cambian, revierten y soportan las versiones de modelos\u002Fprompts\u002Fconfiguración\u002Fdatos?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modelo operativo, controles de ciclo de vida, ADR, runbooks, reglas de cambio\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch3 id=\"section-20\">1. Convertir la necesidad del producto en requisitos arquitectónicos\u003C\u002Fh3>\n\u003Cp>La arquitectura de IA comienza antes de la selección del modelo. El arquitecto primero determina qué se espera que logre la solución y bajo qué restricciones. Esto incluye el comportamiento funcional, pero también los NFR y las políticas que reducen el espacio de diseño: seguridad, fiabilidad, latencia, privacidad, residencia, mantenibilidad, costo y soporte operativo.\u003C\u002Fp>\n\u003Cp>Aquí es donde importa la distinción de A02: un requisito como “los usuarios no autorizados no deben recuperar documentos restringidos” no es una decisión de arquitectura. Es un impulsor. Las decisiones sobre propagación de identidad, particionamiento de índices, filtrado de metadatos, límites de API y aplicación de autorización son respuestas arquitectónicas que deben validarse posteriormente.\u003C\u002Fp>\n\u003Ch3 id=\"section-23\">2. Diseñar datos autoritativos, recuperación y contexto\u003C\u002Fh3>\n\u003Cp>Los sistemas de IA a menudo fallan en el límite entre el comportamiento del modelo y la verdad empresarial. Un arquitecto debe definir qué fuentes son autoritativas, qué significan la frescura y la procedencia, cómo el control de acceso llega a la recuperación y cómo la evidencia recuperada se convierte en contexto del modelo. Una base de datos vectorial, un modelo de embeddings o una biblioteca RAG no son la arquitectura por sí mismos.\u003C\u002Fp>\n\u003Cp>La guía actual de Microsoft sobre cargas de trabajo de IA hace explícita la misma separación: el código de aplicación no debe eludir los límites de acceso a datos; el contexto de usuario o inquilino debe propagarse hacia la recuperación y el filtrado; los datos de fundamentación deben diseñarse para la capacidad de búsqueda sin dejar de cumplir los requisitos de seguridad y cumplimiento.\u003C\u002Fp>\n\u003Ch3 id=\"section-26\">3. Tratar los modelos y proveedores como dependencias, no como todo el sistema\u003C\u002Fh3>\n\u003Cp>La selección del modelo importa, pero debe guiarse por la capacidad requerida y las restricciones. El arquitecto considera la calidad de razonamiento o generación, la modalidad, los límites de contexto, la latencia, el manejo de datos, la ubicación de despliegue, la disponibilidad del proveedor, el costo, la observabilidad y el riesgo de reemplazo.\u003C\u002Fp>\n\u003Cp>La abstracción del proveedor no es automáticamente “mejor arquitectura”. Añade costo de ingeniería y puede ocultar capacidades específicas del proveedor. Se justifica cuando la portabilidad, el fallback, la separación de políticas o el enrutamiento multiproveedor son un requisito explícito. De lo contrario, una integración directa puede ser la mejor decisión. El punto es hacer que la compensación sea intencional.\u003C\u002Fp>\n\u003Ch3 id=\"section-29\">4. Arquitecturar herramientas, acciones y límites de agentes\u003C\u002Fh3>\n\u003Cp>Cuando un sistema de IA puede llamar herramientas, modificar datos, enviar mensajes, ejecutar código u operar sistemas empresariales, el riesgo arquitectónico cambia. El acceso a herramientas necesita su propio modelo de identidad y autorización. La capacidad del modelo de solicitar una acción no es lo mismo que el permiso para ejecutarla.\u003C\u002Fp>\n\u003Cp>Para cargas de trabajo agénticas, la guía actual de AWS enfatiza dimensiones adicionales como identidades de agentes, acceso a herramientas, orquestación, supervisión humana, trazabilidad, manejo de fallos y costo de los bucles de razonamiento iterativo. Estas son preocupaciones de solución incluso cuando un framework oculta parte de la mecánica de implementación.\u003C\u002Fp>\n\u003Ch3 id=\"section-32\">5. Hacer explícitos los límites de confianza y los permisos\u003C\u002Fh3>\n\u003Cp>Una solución de IA en producción tiene múltiples límites de confianza: navegador o cliente, backend de aplicación, orquestación de IA, servicios de recuperación\u002Fdatos, proveedores de modelos, API de herramientas, entornos de ejecución locales y sistemas externos. Cada límite debe responder: ¿quién llama, en nombre de quién, con qué credencial, para qué recurso, con qué pista de auditoría y con qué contención de fallos?\u003C\u002Fp>\n\u003Cp>La seguridad no puede diferirse a una “barrera de protección” alrededor del modelo. La guía de Microsoft sobre cargas de trabajo de IA sitúa explícitamente la seguridad en todas las capas de la arquitectura y exige gestión de identidad\u002Facceso, protección de datos, controles de contenido y seguridad del ciclo de vida. NIST también trata la gobernanza y la gestión de riesgos como continuas a lo largo del ciclo de vida de la IA.\u003C\u002Fp>\n\u003Ch3 id=\"section-35\">6. Decidir dónde se ejecuta realmente el sistema\u003C\u002Fh3>\n\u003Cp>“IA local”, “IA en la nube” e “IA híbrida” son afirmaciones arquitectónicas solo cuando las rutas de ejecución y datos son precisas. Un proceso local de escritorio aún puede llamar a un modelo en la nube. Una aplicación alojada en la nube puede recuperar de una fuente de datos local. Una solución con aislamiento total tiene restricciones completamente diferentes de actualización, distribución de modelos y observabilidad.\u003C\u002Fp>\n\u003Cp>Por lo tanto, el arquitecto separa la \u003Cstrong>ubicación de ejecución\u003C\u002Fstrong>, la \u003Cstrong>ubicación de inferencia\u003C\u002Fstrong>, la \u003Cstrong>ubicación de datos\u003C\u002Fstrong> y el \u003Cstrong>plano de control\u003C\u002Fstrong>. Confundirlos crea falsas suposiciones de seguridad y despliegue.\u003C\u002Fp>\n\u003Ch3 id=\"section-38\">7. Definir la evaluación, la observabilidad y la aceptación operativa\u003C\u002Fh3>\n\u003Cp>El comportamiento de la IA es parcialmente no determinista, por lo que la definición de la versión no puede depender únicamente de pruebas unitarias convencionales. La arquitectura necesita una aceptación medible: éxito de la tarea, fundamentación o corrección de citas cuando sea relevante, comportamiento de rechazo, seguridad de las herramientas, latencia, costo, confiabilidad y pruebas de seguridad. Las métricas exactas dependen del caso de uso.\u003C\u002Fp>\n\u003Cp>La guía actual de Well-Architected AI de Microsoft trata el monitoreo como continuo y lo aplica en el comportamiento del modelo, las indicaciones\u002Fcompletaciones, las anomalías, la seguridad y las puertas de calidad de producción. AWS de manera similar trata la observabilidad, la gestión del ciclo de vida y la trazabilidad del modelo\u002Findicaciones como preocupaciones de la arquitectura operativa.\u003C\u002Fp>\n\u003Ch2 id=\"section-41\">¿Qué debería producir el rol?\u003C\u002Fh2>\n\u003Cp>La arquitectura no es la presentación de diapositivas. Los resultados útiles son los artefactos que permiten a ingeniería, seguridad, producto y operaciones tomar decisiones consistentes y luego entender por qué el sistema existe en su forma actual.\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\">Artefacto\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Propósito\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Contexto y límite de la solución\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Muestra usuarios, sistemas externos, responsabilidades principales y lo que está fuera del alcance\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mapa de requisitos\u002FNFR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Conecta la necesidad del producto y las restricciones con el trabajo de arquitectura y la validación\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Vistas de componentes y flujo de datos\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Muestra las interacciones de aplicación, datos\u002Frecuperación, modelo, herramientas, identidad y tiempo de ejecución\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modelo de confianza y permisos\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Hace explícitos las identidades, secretos, autorización, datos sensibles y acciones de alto riesgo\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Registros de decisiones de arquitectura\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Preserva decisiones significativas, alternativas, compensaciones, estado y consecuencias\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Plan de evaluación y aceptación\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Define la evidencia requerida para afirmar que la solución cumple con las expectativas de calidad y seguridad\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Vista de despliegue y operativa\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Define entornos, ubicaciones de ejecución, observabilidad, reversión, incidentes y responsabilidades del ciclo de vida\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Enlaces de trazabilidad\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Conecta requisitos, decisiones, trabajo de implementación, pruebas y evidencia operativa\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-44\">El trabajo es principalmente compensaciones, no selección de 'mejores prácticas'\u003C\u002Fh2>\n\u003Cp>La arquitectura existe porque las cualidades deseables entran en conflicto. Un modelo de menor costo puede reducir la calidad. Un modelo más capaz puede aumentar la latencia o las restricciones de gobernanza de datos. El almacenamiento en caché agresivo puede mejorar el costo y la velocidad mientras complica la frescura. Los agentes más autónomos pueden reducir el esfuerzo humano mientras aumentan el radio de impacto y los requisitos de auditoría.\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\">Decisión\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Beneficio potencial\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Costo \u002F riesgo potencial\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Pregunta arquitectónica\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modelo en la nube gestionado\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Adopción rápida, capacidades gestionadas sólidas\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Dependencia externa, restricciones de datos y costo\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿La carga de trabajo permite el proveedor\u002Fruta de datos y cumple con las necesidades de resiliencia?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Inferencia local\u002Fautoalojada\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Control, opciones sin conexión\u002Fprivadas\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Carga de hardware, operaciones, ciclo de vida del modelo\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Vale la pena el beneficio de control frente a la responsabilidad operativa?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Integración con un solo proveedor\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Implementación más simple, características completas del proveedor\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mayor concentración de cambio\u002Ffallo\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Se requiere realmente portabilidad o respaldo?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Abstracción del proveedor\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Portabilidad, enrutamiento y separación de políticas\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Riesgo de mínimo común denominador, más código\u002Fpruebas\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Qué diferencias deben permanecer visibles en lugar de abstraerse?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Contexto grande\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Más información por solicitud\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Latencia, costo, dilución de atención, superficie de fuga\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Deberían recuperarse\u002Ffiltrarse los datos en lugar de inyectarse siempre?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Herramientas potentes \u002F autonomía\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Más automatización de extremo a extremo\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mayor privilegio y radio de impacto de fallos\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Qué acciones requieren privilegio mínimo, confirmación o aprobación humana?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Validación y registro estrictos\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mejor evidencia y operaciones\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Costo de latencia, almacenamiento, privacidad y complejidad\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Qué evidencia se requiere para este nivel de riesgo?\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-47\">¿En qué se diferencia de roles adyacentes?\u003C\u002Fh2>\n\u003Cp>Los títulos se superponen mucho entre empresas. La distinción útil es el \u003Cstrong>alcance de la responsabilidad de arquitectura\u003C\u002Fstrong>, no la etiqueta de recursos humanos.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Los roles adyacentes responden a preguntas principales diferentes\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\">Rol\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\">Enfoque principal de arquitectura\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\">Arquitecto de Soluciones de IA\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\">Arquitecto de Plataforma de IA\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\">Arquitecto de IA Empresarial\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\">Ingeniero de IA \u002F ML\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\">Arquitecto de Seguridad\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\">Líder de Producto \u002F Entrega\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>En un equipo de producto pequeño, una persona puede cubrir varios de estos alcances. En una gran empresa, pueden ser roles separados con juntas de revisión formales. La responsabilidad de arquitectura no desaparece cuando cambia el título.\u003C\u002Fp>\n\u003Ch2 id=\"section-51\">Evidencia de implementación: cómo aparecen estos límites en mi propio trabajo\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\">Evidencia de implementación, no una regla universal\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Los ejemplos a continuación son \u003Cstrong>evidencia original de implementación\u002Fproyecto\u003C\u002Fstrong>. Muestran cómo he separado la necesidad del producto, los requisitos, la arquitectura, el tiempo de ejecución, el modelo\u002Fproveedor, los permisos y la validación en el trabajo real del proyecto. No son afirmaciones de que cada organización deba usar la misma estructura, y no implican adopción por parte de clientes ni despliegue a escala empresarial.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch3 id=\"section-53\">SenseFlow: necesidad → requisitos → arquitectura → validación\u003C\u002Fh3>\n\u003Cp>En la Fuente de Verdad del proyecto SenseFlow, la tecnología está explícitamente subordinada a la Visión del Producto. La estructura de desarrollo avanza desde el problema y la visión del producto a través de las necesidades del usuario, el valor, el alcance, las epopeyas, las historias y los criterios de aceptación hacia la arquitectura, la implementación, la validación y la iteración.\u003C\u002Fp>\n\u003Cp>Los requisitos están diseñados para ser trazables desde Objetivo del Producto → Capacidad → Épica → Historia de Usuario → Criterios de Aceptación → Tareas Técnicas. Cuando es práctico, incluyen requisitos funcionales, RNF, dependencias, riesgos, supuestos, criterios de aceptación y métodos de validación. Las decisiones significativas preservan la decisión, la razón, las alternativas, las compensaciones, el estado y la fecha\u002Fversión.\u003C\u002Fp>\n\u003Cp>Eso es trabajo arquitectónico antes de que se elija un marco de IA o modelo específico: protege la conexión entre la intención del producto y las decisiones técnicas y hace que los cambios posteriores sean revisables en lugar de implícitos.\u003C\u002Fp>\n\u003Ch3 id=\"section-57\">Aaasaasa AI Client: separar conceptos antes de integrarlos\u003C\u002Fh3>\n\u003Cp>Aaasaasa AI Client proporciona un ejemplo más a nivel de implementación. Su AI Hub separa deliberadamente \u003Cstrong>agente\u002Fcliente\u003C\u002Fstrong>, \u003Cstrong>proveedor\u003C\u002Fstrong>, \u003Cstrong>modelo\u003C\u002Fstrong>, \u003Cstrong>conexión\u002Fubicación del runtime\u003C\u002Fstrong>, \u003Cstrong>permisos\u003C\u002Fstrong> y \u003Cstrong>cliente web\u003C\u002Fstrong>. No se asume que un runtime local signifique inferencia local, y los permisos se tratan como política de runtime\u002Fherramientas en lugar de como una propiedad del modelo.\u003C\u002Fp>\n\u003Cp>La arquitectura de escritorio también define un límite de confianza: el renderizador de Nuxt no es de confianza en relación con el proceso principal de Electron. Un preload estrecho y una IPC validada median el acceso a servicios de IA, configuración, secretos cifrados, servicios de espacio de trabajo\u002Fdatos y runtimes. Las credenciales en la nube permanecen en el proceso principal privilegiado; el código del renderizador recibe estado normalizado en lugar de secretos sin procesar o acceso sin restricciones al sistema operativo.\u003C\u002Fp>\n\u003Cp>Las decisiones de enrutamiento son igualmente arquitectónicas. La implementación no recurre silenciosamente de una ruta local a inferencia en la nube de pago; una ruta en la nube requiere confirmación explícita. El Chat Directo no tiene herramientas de sistema de archivos o shell por defecto, mientras que la ejecución del agente aplica un espacio de trabajo y un perfil de permisos seleccionados. Estas son decisiones a nivel de solución sobre confianza, costo, ejecución y expectativas del usuario, no características del modelo.\u003C\u002Fp>\n\u003Ch2 id=\"section-61\">Cómo los marcos de arquitectura actuales apoyan este alcance más amplio\u003C\u002Fh2>\n\u003Cp>ISO\u002FIEC\u002FIEEE 42010:2022 proporciona una disciplina general para descripciones de arquitectura en software, sistemas y empresas. Es deliberadamente más amplio que la IA y no prescribe un método de arquitectura o título de trabajo único. Eso lo hace útil aquí como un límite: la arquitectura de soluciones de IA sigue siendo arquitectura, con preocupaciones de las partes interesadas, múltiples vistas y relaciones significativas que deben expresarse claramente.\u003C\u002Fp>\n\u003Cp>NIST AI RMF 1.0 enmarca la gestión de riesgos de IA a través de \u003Cstrong>Govern, Map, Measure y Manage\u003C\u002Fstrong> y enfatiza que la gestión de riesgos debe ser continua a lo largo del ciclo de vida del sistema de IA. El Perfil de IA Generativa (NIST AI 600-1) adapta ese marco a los riesgos de GAI y las prioridades organizacionales. Esto refuerza que la arquitectura no puede detenerse en el rendimiento funcional del modelo.\u003C\u002Fp>\n\u003Cp>La guía actual de Azure Well-Architected AI de Microsoft separa el diseño de aplicaciones, la plataforma de aplicaciones, los datos de entrenamiento, los datos de fundamentación y las preocupaciones de la plataforma de datos y las conecta repetidamente con la confiabilidad, la seguridad, la excelencia operativa, el rendimiento y el costo. Las lentes de IA Generativa e IA Agéntica de AWS tratan de manera similar la observabilidad, la seguridad, la confiabilidad, el ciclo de vida del modelo\u002Fherramienta, el costo y la supervisión humana como preocupaciones arquitectónicas.\u003C\u002Fp>\n\u003Ch2 id=\"section-65\">Conceptos erróneos comunes\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\">Concepto erróneo\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Corrección\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“El arquitecto elige el LLM.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La elección del modelo es una decisión dentro de una arquitectura de solución más amplia.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“La ingeniería de prompts es la arquitectura.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Los prompts afectan el comportamiento, pero no definen identidad, acceso a datos, límites de confianza, despliegue, permisos de herramientas u operaciones.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“RAG resuelve el conocimiento empresarial.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La recuperación es solo un subsistema; la autorización, la procedencia, la actualidad, la evidencia, la indexación, la evaluación y la gobernanza de fuentes aún necesitan diseño.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“Runtime local significa IA privada\u002Flocal.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Las ubicaciones del runtime, la inferencia, los datos y el plano de control son propiedades arquitectónicas separadas.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“Si un proveedor ofrece barreras de protección, la seguridad está cubierta.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La seguridad abarca identidad, autorización, secretos, flujos de datos, herramientas, registro, despliegue, aprobación humana y límites del proveedor.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“El arquitecto debe escribir cada componente.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La implementación práctica puede mejorar la calidad arquitectónica, pero el rol se define por la responsabilidad de decisiones integradas, no por codificar personalmente cada capa.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“Un diagrama de arquitectura demuestra preparación para producción.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La preparación requiere controles implementados y evidencia de validación en calidad, seguridad, operaciones y aceptación empresarial.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-67\">Modos de falla que un Arquitecto de Soluciones de IA debe prevenir\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\">Modo de falla\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Por qué ocurre\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Corrección arquitectónica\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Diseño centrado primero en el modelo\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Una demostración prometedora de un modelo se convierte en el plano del sistema\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Comenzar por el resultado, las restricciones y la validación; seleccionar el modelo dentro de ese marco\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Permisos de prototipo en producción\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Las credenciales compartidas y el acceso amplio sobreviven a la PoC\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Definir la propagación de identidad, el privilegio mínimo, los alcances de herramientas y los límites de aprobación desde el principio\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Recuperación sin autorización\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La calidad de búsqueda se diseña antes que las reglas de acceso a datos\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Llevar el contexto de usuario\u002Finquilino a la recuperación y aplicar autorización en los límites de acceso a datos\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Supuestos silenciosos de proveedor\u002Fruntime\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“Local”, “nube” y “sin conexión” se usan de manera imprecisa\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Documentar por separado la ubicación del runtime, la inferencia, los datos y el plano de control\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sin contrato de falla\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Se diseña el camino feliz pero no el comportamiento de rechazo\u002Ffallback\u002Ferror\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Especificar el comportamiento cuando la recuperación está vacía, el modelo no está disponible, falla una herramienta o se deniega por política\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Evaluación después de la implementación\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La calidad se juzga manualmente cerca del lanzamiento\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Definir aceptación medible y conjuntos de evaluación representativos antes de que se congele la arquitectura\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Cambio no trazable\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modelos, prompts, recuperación o permisos cambian sin historial arquitectónico\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Versionar la configuración crítica y registrar decisiones significativas\u002Fevidencia de validación\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Operaciones tratadas solo como infraestructura\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">El comportamiento de la IA no es observable después del despliegue\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Diseñar juntos trazas, métricas de calidad, eventos de seguridad, telemetría de costos y reversión\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-69\">Una secuencia de decisión práctica\u003C\u002Fh2>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Secuencia de decisión de arquitectura de soluciones de IA\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\">Resultado\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Definir el resultado del usuario\u002Fnegocio y los no objetivos explícitos.\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\">Evidencia y restricciones\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Identificar datos autorizados, políticas, RNF, riesgos y condiciones de aceptación.\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\">Límite del sistema\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Mapear usuarios, identidades, aplicaciones, datos, modelos\u002Fproveedores, herramientas y sistemas externos.\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\">Opciones de arquitectura\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Comparar patrones para recuperación, acceso a modelos, orquestación, despliegue, permisos, evaluación y observabilidad.\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\">Decisiones de compensación\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Seleccionar opciones significativas y preservar la justificación, las alternativas y las consecuencias.\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\">Contratos de implementación\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Convertir decisiones en API, esquemas, reglas de permisos, definiciones de despliegue y tareas de ingeniería.\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\">Validación\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Probar el sistema implementado contra los requisitos funcionales y no funcionales originales.\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\">Retroalimentación operativa\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Usar evidencia de producción, incidentes, métricas de calidad y señales de costo\u002Fseguridad para desencadenar cambios controlados.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-71\">Casos límite y límites del rol\u003C\u002Fh2>\n\u003Cp>Algunos productos de IA están dominados por el entrenamiento de modelos, la experimentación científica o el hardware especializado. En esos casos, la ciencia de datos\u002Fmodelos y la arquitectura de sistemas de ML pueden volverse mucho más profundas que el mapa a nivel de solución que se muestra aquí. El Arquitecto de Soluciones de IA aún necesita límites de integración y operativos, pero la arquitectura especializada puede ser propietaria de la plataforma de entrenamiento en sí.\u003C\u002Fp>\n\u003Cp>En el otro extremo, una integración SaaS simple puede no justificar un arquitecto dedicado. Un ingeniero sénior o un líder técnico de producto puede asumir la misma responsabilidad de arquitectura. La prueba útil no es el título, sino si se están tomando decisiones significativas entre capas de forma deliberada y validada.\u003C\u002Fp>\n\u003Cp>Los sistemas regulados, soberanos, con aislamiento de red, de seguridad crítica, altamente autónomos o multiinquilino también desplazan el centro de gravedad. La identidad, el aislamiento, la residencia, la garantía, los mecanismos de actualización, la supervisión humana y la auditabilidad pueden dominar la calidad del modelo en la arquitectura.\u003C\u002Fp>\n\u003Ch2 id=\"section-75\">¿Qué cambiaría esta respuesta?\u003C\u002Fh2>\n\u003Cp>El límite exacto de responsabilidad cambia cuando la arquitectura pasa de una aplicación a una plataforma reutilizable o a una arquitectura objetivo a nivel empresarial. Por eso \u003Cstrong>AI Platform Architect\u003C\u002Fstrong> y \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> merecen un tratamiento canónico separado en lugar de fusionarse en este rol.\u003C\u002Fp>\n\u003Cp>Los cambios tecnológicos también importan. Las nuevas capacidades de los modelos, los protocolos, los entornos de ejecución locales y los servicios gestionados pueden eliminar parte del trabajo de implementación mientras crean nuevos límites de confianza u operativos. La responsabilidad estable es entender esos cambios como cambios del sistema, no tratar un nuevo framework como un reemplazo de la arquitectura.\u003C\u002Fp>\n\u003Ch2 id=\"section-78\">Lista de verificación del 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\">Verificación\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Pregunta\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Resultado\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Están explícitos el resultado de usuario\u002Fnegocio y el límite de no objetivos?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Requisitos\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Son trazables los requisitos funcionales, los RNF, las restricciones y los criterios de aceptación?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Datos\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Están definidas las fuentes autorizadas, la procedencia, la frescura, la retención y las reglas de acceso?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Recuperación\u002Fcontexto\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿La autorización alcanza la recuperación y la construcción de contexto?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modelo\u002Fproveedor\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿La selección de modelo\u002Fproveedor está vinculada a capacidades y restricciones en lugar de a preferencias?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Herramientas\u002Fagentes\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Están explícitos los límites de acción, los permisos, las aprobaciones y el comportamiento ante fallos?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Identidad\u002Fseguridad\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Están definidas las identidades humanas\u002Fmáquina, los secretos y los límites de confianza?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Entorno de ejecución\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Se distinguen las ubicaciones del entorno de ejecución, la inferencia, los datos y el plano de control?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Evaluación\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Existe evidencia medible de calidad, seguridad y aceptación?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Observabilidad\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Se puede investigar el comportamiento en producción, los fallos, el coste y los eventos de seguridad?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Cambio\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Son trazables las decisiones de arquitectura significativas y los reemplazos?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Operaciones\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">¿Está clara la responsabilidad sobre el despliegue, la reversión, los incidentes y el ciclo de vida?\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-80\">Conclusión\u003C\u002Fh2>\n\u003Cp>Un AI Solution Architect es la persona o la función de arquitectura que convierte una oportunidad de IA en un sistema técnico coherente. La habilidad clave no es conocer la mayor cantidad de nombres de modelos; es conectar la necesidad del producto, los requisitos, los datos, la arquitectura de la aplicación, las capacidades de IA, la seguridad, el entorno de ejecución, la entrega y la validación sin perder los límites entre ellos.\u003C\u002Fp>\n\u003Cp>Por lo tanto, una sólida arquitectura de solución de IA puede resumirse así: \u003Cstrong>definir el objetivo → establecer requisitos y restricciones → diseñar los límites del sistema → hacer explícitos los compromisos significativos → implementar mediante contratos claros → validar con evidencia → operar y evolucionar de forma deliberada.\u003C\u002Fstrong> El modelo es importante. La solución es el producto.\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 — Preguntas frecuentes\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\">¿Qué es un AI Solution Architect?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Un AI Solution Architect traduce una necesidad de negocio o de producto en la arquitectura de una solución concreta habilitada por IA, definiendo cómo funcionan juntos la lógica de la aplicación, los datos\u002Frecuperación, los modelos, las herramientas, la identidad, la seguridad, el entorno de ejecución, la evaluación y las operaciones.\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\">¿Es un AI Solution Architect lo mismo que un ingeniero de IA?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">No. Los roles pueden solaparse, especialmente en equipos pequeños, pero un ingeniero de IA es principalmente un rol de implementación, mientras que el arquitecto de soluciones posee o coordina las decisiones de arquitectura entre capas y los compromisos para la carga de trabajo completa.\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\">¿Un AI Solution Architect necesita programar?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">No por definición, pero el conocimiento práctico de implementación es muy valioso porque la arquitectura de IA cruza API, datos, recuperación, seguridad, entornos de ejecución y comportamiento operativo. El rol se define por la responsabilidad de arquitectura, no por escribir personalmente cada componente.\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\">¿Elegir un LLM es el trabajo principal?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">No. La selección del modelo es una decisión. La arquitectura de producción también necesita límites de datos y recuperación, permisos, herramientas, elecciones de proveedor\u002Fentorno de ejecución, observabilidad, evaluación, fiabilidad, coste y diseño del ciclo de vida.\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\">¿Cuál es la diferencia entre un AI Solution Architect y un AI Platform Architect?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Un AI Solution Architect se centra en una solución o carga de trabajo concreta. Un AI Platform Architect se centra en capacidades y barreras de seguridad de IA reutilizables que dan soporte a múltiples soluciones.\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\">¿Cuál es la diferencia entre un AI Solution Architect y un Enterprise AI Architect?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">El arquitecto de soluciones trabaja en el ámbito de aplicación\u002Fcarga de trabajo. La arquitectura empresarial de IA trabaja en todo el portafolio organizacional, la arquitectura objetivo, la gobernanza, las capacidades compartidas, los principios de integración y las restricciones estratégicas.\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\">¿Dónde encajan RAG y los agentes?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Son patrones arquitectónicos o subsistemas dentro de una solución cuando los requisitos los justifican. RAG aborda el contexto fundamentado en la recuperación; los agentes añaden planificación\u002Fejecución de herramientas y, por lo tanto, preocupaciones adicionales de identidad, permisos, orquestación y operación.\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\">¿Qué demuestra que la arquitectura funciona?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">La implementación más la evidencia de validación: pruebas funcionales, resultados de evaluación, pruebas de seguridad\u002Fautorización, mediciones de rendimiento y fiabilidad, observabilidad, ensayo operativo y aceptación frente a los requisitos originales.\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\">Términos clave\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\">Responsabilidad de arquitectura para una solución o carga de trabajo concreta habilitada por IA, integrando los requisitos del producto con el diseño de aplicación, datos, modelo, herramientas, seguridad, entorno de ejecución y operaciones.\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\">Límite del sistema\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">La separación explícita entre lo que pertenece a la solución y los usuarios, sistemas, proveedores, fuentes de datos y entornos con los que interactúa.\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\">Límite de confianza\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un punto donde los datos, las identidades o el control cruzan entre componentes con diferentes supuestos de confianza y, por lo tanto, requieren controles de seguridad explícitos.\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\">Fundamentación\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Proporcionar a un modelo de IA información o evidencia externa relevante para que su respuesta pueda basarse en fuentes más allá de los parámetros del modelo.\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\">Abstracción de proveedor\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un límite de aplicación que desacopla partes de la solución de una interfaz de modelo\u002Fproveedor. Útil cuando lo justifican necesidades de enrutamiento, portabilidad o políticas, pero no exento de compromisos.\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\">Evaluación\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Medición estructurada del comportamiento de la carga de trabajo de IA frente a criterios de aceptación definidos, incluida la calidad de la tarea y las propiedades relevantes de seguridad, protección, rendimiento y operación.\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\">Rol arquitectónico centrado en capacidades de plataforma de IA reutilizables utilizadas por múltiples soluciones en lugar de la arquitectura de una sola carga de trabajo.\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\">Arquitectura a nivel de organización que coordina capacidades de IA, plataformas, gobernanza, integración y restricciones estratégicas en todo un portafolio.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-85\">Conocimiento canónico relacionado\u003C\u002Fh2>\n\u003Cp>Este artículo se sitúa en el clúster de Fundamentos de Arquitectura de IA. Sus fundamentos directos son \u003Cstrong>Generative AI Explained: Models, Retrieval, Tools and Applications Are Not the Same Thing\u003C\u002Fstrong> y \u003Cstrong>ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing\u003C\u002Fstrong>. Los nodos canónicos adyacentes incluyen \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> y \u003Cstrong>AI Governance\u003C\u002Fstrong>. Las URL no se fabrican intencionadamente donde esos nodos aún no se han publicado.\u003C\u002Fp>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fes\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\">Explicación canónica existente en stajic.de sobre la generación aumentada por recuperación, útil para la parte de recuperación\u002Ffundamentación de la arquitectura de soluciones de IA.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ch2 id=\"section-88\">Fuentes primarias y guía arquitectónica actual\u003C\u002Fh2>\n\u003Cp>Las fuentes externas a continuación respaldan las afirmaciones arquitectónicas generales; las secciones de SenseFlow y Aaasaasa AI Client son evidencia explícita y original del proyecto\u002Fimplementación. Las referencias al estado actual se verificaron el 8 de octubre de 2026. NIST señala que AI RMF 1.0 está siendo revisado, por lo que las referencias de gobernanza sensibles a la versión deben volver a verificarse cuando se publique un sucesor.\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\">Estándar internacional actual para la estructura y expresión de descripciones de arquitectura. Distingue la arquitectura de su descripción y no prescribe un único método, herramienta o formato de registro de arquitectura.\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\">Marco de Gestión de Riesgos de IA del NIST\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Página de recursos del AI RMF del NIST. A partir de octubre de 2026, indica que el AI RMF 1.0 está siendo revisado y enlaza el Perfil de IA Generativa y recursos relacionados.\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\">Núcleo del AI RMF del NIST — Gobernar, Mapear, Medir, Gestionar\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Presentación oficial del Núcleo del AI RMF 1.0 del AIRC del NIST, que incluye las cuatro funciones y el enfoque de gestión de riesgos orientado al ciclo de vida.\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 — Perfil de IA Generativa\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Perfil intersectorial de IA Generativa para el AI RMF 1.0, publicado el 26 de julio de 2024 y actualizado por el NIST en 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 — Cargas de trabajo de IA\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Guía actual de arquitectura a nivel de carga de trabajo que abarca el diseño de aplicaciones de IA, la plataforma de aplicaciones, los datos de entrenamiento, los datos de fundamentación, la plataforma de datos y las preocupaciones de preparación para producción.\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 — Diseño de aplicaciones para cargas de trabajo de IA\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Guía sobre la abstracción de modelos\u002Fherramientas, los límites de acceso a datos, la propagación de identidad, la autorización y la separación de las capas de cliente, inteligencia, conocimiento y herramientas.\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 — Principios de diseño para cargas de trabajo de IA\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Principios actuales de diseño de cargas de trabajo de IA en materia de confiabilidad, seguridad, costo, excelencia operativa y rendimiento, incluidos las responsabilidades de identidad y protección de datos.\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 y GenAIOps para cargas de trabajo de IA\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Guía del ciclo de vida de producción que abarca el monitoreo, las puertas de calidad, el comportamiento de modelos\u002Fprompts, la seguridad y la medición operativa.\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\">Lente de IA Generativa de AWS Well-Architected\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Guía arquitectónica de AWS para cargas de trabajo de IA generativa en materia de excelencia operativa, seguridad, confiabilidad, eficiencia de rendimiento, optimización de costos y sostenibilidad.\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\">Lente de IA Agéntica de AWS Well-Architected\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Publicado en 2026, abarca preocupaciones arquitectónicas específicas de agentes, incluidas identidades, herramientas, orquestación, supervisión humana, confiabilidad, trazabilidad y costo del bucle de razonamiento.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1071},1791476872484,[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,881,885,889,893,930,965,969,973,983,987,991,999,1007,1015,1023,1031,1039,1047,1055,1063],{"id":215,"data":216,"type":218},"intro",{"text":217},"Un \u003Cstrong>Arquitecto de Soluciones de IA\u003C\u002Fstrong> traduce una necesidad de negocio o de producto en la arquitectura de una solución concreta habilitada por IA. El rol define los límites del sistema y las decisiones significativas en cuanto a lógica de aplicación, datos autorizados, recuperación y contexto, modelos y proveedores, herramientas o agentes, identidad y permisos, seguridad, tiempo de ejecución y despliegue, observabilidad, evaluación, costo y comportamiento operativo. No se trata simplemente de selección de modelos o ingeniería de prompts: la responsabilidad arquitectónica es hacer que toda la solución sea implementable, gobernable, verificable y operable.","paragraph",{"id":220,"data":221,"type":225},"direct",{"body":222,"title":223,"variant":224},"\u003Cstrong>Un Arquitecto de Soluciones de IA diseña la solución completa habilitada por IA, no solo el modelo de IA.\u003C\u002Fstrong> El rol conecta los requisitos y los requisitos no funcionales con las decisiones de arquitectura, compone las capas necesarias de aplicación\u002Fdatos\u002Fmodelo\u002Fherramientas\u002Ftiempo de ejecución, hace explícitos los límites de confianza y de fallo, y define cómo se validará y operará el sistema implementado.","Respuesta directa","info","callout",{"id":227,"data":228,"type":225},"role-note",{"body":229,"title":230,"variant":231},"\u003Cstrong>Arquitecto de Soluciones de IA es una etiqueta práctica de rol, no un título profesional universalmente estandarizado.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 estandariza conceptos para descripciones de arquitectura; no define este rol laboral. Las organizaciones pueden distribuir las responsabilidades entre varias personas. En este artículo, el término significa la responsabilidad de arquitectura para una solución o carga de trabajo concreta habilitada por IA.","Nota terminológica","note",{"id":233,"data":234,"type":225},"version-note",{"body":235,"title":236,"variant":231},"Los principios de arquitectura aquí son intencionalmente neutrales respecto al proveedor, mientras que la guía actual de proveedores se utiliza como evidencia de implementación. NIST AI RMF 1.0 está actualmente en revisión; NIST AI 600-1 sigue siendo el Perfil de IA Generativa publicado. La guía de Microsoft y AWS citada a continuación refleja preocupaciones actuales de producción como identidad, límites de datos, abstracción de modelos, seguridad, observabilidad, evaluación, confiabilidad y costo.","Nota sobre fuentes actuales — 8 de octubre de 2026",{"id":238,"data":239,"type":243},"toc",{"title":240,"maxLevel":241,"minLevel":242},"Contenido",3,2,"tableOfContents",{"id":245,"data":246,"type":42},"h-meaning",{"text":247,"level":242},"¿Qué arquitecta realmente un Arquitecto de Soluciones de IA?",{"id":249,"data":250,"type":218},"p-meaning-1",{"text":251},"El objeto del trabajo es la \u003Cstrong>solución\u003C\u002Fstrong>: el sistema sociotécnico completo que convierte una necesidad en un comportamiento útil y controlado. Un modelo puede ser central para ese sistema, pero sigue siendo solo una dependencia. El mismo modelo puede participar en un asistente de búsqueda interno seguro, un agente inseguro con privilegios excesivos, una función de cliente de baja latencia o un prototipo de alto costo que no puede operarse económicamente. La arquitectura determina esas diferencias.",{"id":253,"data":254,"type":218},"p-meaning-2",{"text":255},"Un límite útil es, por lo tanto: \u003Cstrong>resultado de negocio → requisitos → responsabilidades del sistema → decisiones de arquitectura → implementación → validación → operación\u003C\u002Fstrong>. El Arquitecto de Soluciones de IA trabaja a lo largo de esta cadena mientras colabora con producto, ingeniería, datos, seguridad, infraestructura, gobernanza y especialistas de dominio.",{"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","Capacidad",{"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","Datos",{"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","Seguridad",{"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","Operaciones",{"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","Cambio",{"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?","La solución es más amplia que el modelo","table",[293,296],{"id":294,"label":295},"model","Pregunta centrada en el modelo",{"id":297,"label":298},"solution","Pregunta de arquitectura de solución","comparison",{"id":301,"data":302,"type":42},"h-simple",{"text":303,"level":242},"El ejemplo más simple",{"id":305,"data":306,"type":218},"p-simple-1",{"text":307},"Imagina que una empresa quiere un asistente interno que responda las preguntas de los técnicos a partir de manuales de mantenimiento y procedimientos operativos. La función visible suena simple: escribir una pregunta y recibir una respuesta con fuentes.",{"id":309,"data":310,"type":218},"p-simple-2",{"text":311},"La pregunta de arquitectura es mucho más amplia. ¿Qué documentos son autorizados? ¿Cómo se autentican los usuarios? ¿La recuperación debe respetar los permisos de departamento o sitio? ¿La respuesta puede usar solo evidencia recuperada? ¿Qué modelo es aceptable para la clasificación de datos? ¿Puede un proveedor de nube recibir el contenido? ¿Qué sucede cuando la recuperación no encuentra nada? ¿Cómo se producen las citas? ¿Cómo se evalúa la calidad de las respuestas? ¿Qué latencia y costo son aceptables? ¿Quién puede ver los registros y qué puede almacenarse en ellos?",{"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. Definir el resultado","Aclarar el usuario, el valor de negocio, el límite de la tarea y qué significa una respuesta o acción exitosa.",{"label":320,"description":321},"2. Capturar requisitos","Hacer explícitos los requisitos funcionales, los RNF, las restricciones, las reglas de datos, la tolerancia al riesgo y los criterios de aceptación.",{"label":323,"description":324},"3. Establecer límites","Identificar usuarios, identidades, aplicaciones, datos autorizados, dependencias de modelo\u002Fproveedor, herramientas, sistemas externos y zonas de confianza.",{"label":326,"description":327},"4. Diseñar la arquitectura","Elegir patrones de datos\u002Frecuperación, modelo, orquestación, herramientas, permisos, tiempo de ejecución, despliegue, respaldo y observabilidad.",{"label":329,"description":330},"5. Registrar decisiones significativas","Preservar las elecciones arquitectónicas, alternativas, compensaciones y consecuencias para que los cambios posteriores sigan siendo comprensibles.",{"label":332,"description":333},"6. Implementar e integrar","Convertir la arquitectura en código de aplicación, API, políticas, infraestructura, flujos de trabajo y controles operativos.",{"label":335,"description":336},"7. Validar y operar","Probar calidad, seguridad, confiabilidad, costo y resultados de usuario; monitorear la carga de trabajo real y retroalimentar las decisiones con evidencia.","De la necesidad a una solución de IA operable","auto","processFlow",{"id":341,"data":342,"type":42},"h-where-simple-stops",{"text":343,"level":242},"Donde se detiene el ejemplo simple",{"id":345,"data":346,"type":218},"p-stop-1",{"text":347},"Una prueba de concepto a menudo puede omitir la arquitectura que producción no puede. Un desarrollador puede codificar un solo proveedor, usar una clave de API compartida, colocar todos los documentos en un solo índice, ejecutar la recuperación sin filtrado por contexto de usuario, registrar los prompts textualmente y juzgar la calidad manualmente. Eso puede demostrar viabilidad, pero no establece una arquitectura de producción.",{"id":349,"data":350,"type":218},"p-stop-2",{"text":351},"Producción introduce restricciones que interactúan: aislamiento de inquilino o usuario, privacidad, residencia de datos, rendimiento, latencia, costo, cuotas del proveedor, comportamiento de respaldo, auditabilidad, cambios de versión del modelo, calidad de recuperación, permisos de herramientas, respuesta a incidentes y ciclo de vida de despliegue. El trabajo del arquitecto no es maximizar cada cualidad a la vez; es hacer explícitas las compensaciones y diseñar una solución que satisfaga el conjunto de prioridades real.",{"id":353,"data":354,"type":42},"h-responsibility-map",{"text":355,"level":242},"Mapa de responsabilidades de arquitectura",{"id":357,"data":358,"type":218},"p-resp-intro",{"text":359},"La división exacta varía según la organización, pero el siguiente mapa captura las responsabilidades recurrentes de la arquitectura de IA a nivel de solución. Es posible que el arquitecto no implemente personalmente cada capa; la responsabilidad es hacer que las capas encajen de forma coherente y mantener trazables las decisiones críticas.",{"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],"Área de arquitectura","Preguntas que el Arquitecto de Soluciones de IA debe resolver","Salidas típicas",[369,370,371],"Resultado y alcance","¿Quién es el usuario? ¿Qué tarea está en alcance? ¿Qué no debe hacer el sistema? ¿Qué constituye el éxito?","Contexto de la solución, límite de capacidad, criterios de aceptación",[373,374,375],"Requisitos y NFR","¿Qué restricciones de calidad, seguridad, disponibilidad, latencia, costo, residencia y cumplimiento aplican?","Mapa de requisitos, NFR, restricciones, criterios de validación",[377,378,379],"Aplicación y orquestación","¿Dónde termina la lógica de aplicación determinista y dónde comienza el comportamiento de IA? ¿Cómo se coordinan los flujos de trabajo?","Modelo de componentes, API, límites de orquestación, rutas de fallo",[381,382,383],"Datos autoritativos y recuperación","¿Cuál es la Fuente de Verdad? ¿Cómo se ingieren, autorizan, recuperan, filtran, clasifican y citan los datos?","Flujos de datos, arquitectura de recuperación, metadatos y reglas de autorización",[385,386,387],"Capa de modelo y proveedor","¿Qué capacidades se requieren? ¿Qué restricciones de proveedor\u002Fentorno de ejecución importan? ¿Qué debería abstraerse?","Decisión de modelo\u002Fproveedor, política de enrutamiento\u002Ffallback, límite de abstracción",[389,390,391],"Herramientas y agentes","¿Qué acciones puede tomar el sistema? ¿Qué acciones requieren aprobación? ¿Cómo se aplican las identidades y permisos de las herramientas?","Contratos de herramientas, límites de agentes, reglas de aprobación y privilegio mínimo",[393,394,395],"Identidad y seguridad","¿Qué identidades humanas y de máquina existen? ¿Dónde se guardan los secretos? ¿Qué límites de confianza se cruzan?","Modelo de amenazas\u002Flímites de confianza, propagación de identidad, diseño de secretos y autorización",[397,398,399],"Entorno de ejecución y despliegue","¿Dónde se ejecutan los componentes? ¿Qué es local, nube, borde o híbrido? ¿Qué suposiciones de red y disponibilidad existen?","Vista de despliegue, topología de ejecución, decisiones de entorno y conectividad",[401,402,403],"Evaluación y observabilidad","¿Cómo se mide la calidad antes y después del lanzamiento? ¿Qué trazas, métricas, registros y evidencia se necesitan?","Plan de evaluación, telemetría, pista de auditoría, puertas de lanzamiento",[405,406,407],"Operaciones y cambio","¿Cómo se cambian, revierten y soportan las versiones de modelos\u002Fprompts\u002Fconfiguración\u002Fdatos?","Modelo operativo, controles de ciclo de vida, ADR, runbooks, reglas de cambio",{"id":409,"data":410,"type":42},"h-requirements",{"text":411,"level":241},"1. Convertir la necesidad del producto en requisitos arquitectónicos",{"id":413,"data":414,"type":218},"p-requirements-1",{"text":415},"La arquitectura de IA comienza antes de la selección del modelo. El arquitecto primero determina qué se espera que logre la solución y bajo qué restricciones. Esto incluye el comportamiento funcional, pero también los NFR y las políticas que reducen el espacio de diseño: seguridad, fiabilidad, latencia, privacidad, residencia, mantenibilidad, costo y soporte operativo.",{"id":417,"data":418,"type":218},"p-requirements-2",{"text":419},"Aquí es donde importa la distinción de A02: un requisito como “los usuarios no autorizados no deben recuperar documentos restringidos” no es una decisión de arquitectura. Es un impulsor. Las decisiones sobre propagación de identidad, particionamiento de índices, filtrado de metadatos, límites de API y aplicación de autorización son respuestas arquitectónicas que deben validarse posteriormente.",{"id":421,"data":422,"type":42},"h-data",{"text":423,"level":241},"2. Diseñar datos autoritativos, recuperación y contexto",{"id":425,"data":426,"type":218},"p-data-1",{"text":427},"Los sistemas de IA a menudo fallan en el límite entre el comportamiento del modelo y la verdad empresarial. Un arquitecto debe definir qué fuentes son autoritativas, qué significan la frescura y la procedencia, cómo el control de acceso llega a la recuperación y cómo la evidencia recuperada se convierte en contexto del modelo. Una base de datos vectorial, un modelo de embeddings o una biblioteca RAG no son la arquitectura por sí mismos.",{"id":429,"data":430,"type":218},"p-data-2",{"text":431},"La guía actual de Microsoft sobre cargas de trabajo de IA hace explícita la misma separación: el código de aplicación no debe eludir los límites de acceso a datos; el contexto de usuario o inquilino debe propagarse hacia la recuperación y el filtrado; los datos de fundamentación deben diseñarse para la capacidad de búsqueda sin dejar de cumplir los requisitos de seguridad y cumplimiento.",{"id":433,"data":434,"type":42},"h-model",{"text":435,"level":241},"3. Tratar los modelos y proveedores como dependencias, no como todo el sistema",{"id":437,"data":438,"type":218},"p-model-1",{"text":439},"La selección del modelo importa, pero debe guiarse por la capacidad requerida y las restricciones. El arquitecto considera la calidad de razonamiento o generación, la modalidad, los límites de contexto, la latencia, el manejo de datos, la ubicación de despliegue, la disponibilidad del proveedor, el costo, la observabilidad y el riesgo de reemplazo.",{"id":441,"data":442,"type":218},"p-model-2",{"text":443},"La abstracción del proveedor no es automáticamente “mejor arquitectura”. Añade costo de ingeniería y puede ocultar capacidades específicas del proveedor. Se justifica cuando la portabilidad, el fallback, la separación de políticas o el enrutamiento multiproveedor son un requisito explícito. De lo contrario, una integración directa puede ser la mejor decisión. El punto es hacer que la compensación sea intencional.",{"id":445,"data":446,"type":42},"h-tools",{"text":447,"level":241},"4. Arquitecturar herramientas, acciones y límites de agentes",{"id":449,"data":450,"type":218},"p-tools-1",{"text":451},"Cuando un sistema de IA puede llamar herramientas, modificar datos, enviar mensajes, ejecutar código u operar sistemas empresariales, el riesgo arquitectónico cambia. El acceso a herramientas necesita su propio modelo de identidad y autorización. La capacidad del modelo de solicitar una acción no es lo mismo que el permiso para ejecutarla.",{"id":453,"data":454,"type":218},"p-tools-2",{"text":455},"Para cargas de trabajo agénticas, la guía actual de AWS enfatiza dimensiones adicionales como identidades de agentes, acceso a herramientas, orquestación, supervisión humana, trazabilidad, manejo de fallos y costo de los bucles de razonamiento iterativo. Estas son preocupaciones de solución incluso cuando un framework oculta parte de la mecánica de implementación.",{"id":457,"data":458,"type":42},"h-security",{"text":459,"level":241},"5. Hacer explícitos los límites de confianza y los permisos",{"id":461,"data":462,"type":218},"p-security-1",{"text":463},"Una solución de IA en producción tiene múltiples límites de confianza: navegador o cliente, backend de aplicación, orquestación de IA, servicios de recuperación\u002Fdatos, proveedores de modelos, API de herramientas, entornos de ejecución locales y sistemas externos. Cada límite debe responder: ¿quién llama, en nombre de quién, con qué credencial, para qué recurso, con qué pista de auditoría y con qué contención de fallos?",{"id":465,"data":466,"type":218},"p-security-2",{"text":467},"La seguridad no puede diferirse a una “barrera de protección” alrededor del modelo. La guía de Microsoft sobre cargas de trabajo de IA sitúa explícitamente la seguridad en todas las capas de la arquitectura y exige gestión de identidad\u002Facceso, protección de datos, controles de contenido y seguridad del ciclo de vida. NIST también trata la gobernanza y la gestión de riesgos como continuas a lo largo del ciclo de vida de la IA.",{"id":469,"data":470,"type":42},"h-runtime",{"text":471,"level":241},"6. Decidir dónde se ejecuta realmente el sistema",{"id":473,"data":474,"type":218},"p-runtime-1",{"text":475},"“IA local”, “IA en la nube” e “IA híbrida” son afirmaciones arquitectónicas solo cuando las rutas de ejecución y datos son precisas. Un proceso local de escritorio aún puede llamar a un modelo en la nube. Una aplicación alojada en la nube puede recuperar de una fuente de datos local. Una solución con aislamiento total tiene restricciones completamente diferentes de actualización, distribución de modelos y observabilidad.",{"id":477,"data":478,"type":218},"p-runtime-2",{"text":479},"Por lo tanto, el arquitecto separa la \u003Cstrong>ubicación de ejecución\u003C\u002Fstrong>, la \u003Cstrong>ubicación de inferencia\u003C\u002Fstrong>, la \u003Cstrong>ubicación de datos\u003C\u002Fstrong> y el \u003Cstrong>plano de control\u003C\u002Fstrong>. Confundirlos crea falsas suposiciones de seguridad y despliegue.",{"id":481,"data":482,"type":42},"h-eval",{"text":483,"level":241},"7. Definir la evaluación, la observabilidad y la aceptación operativa",{"id":485,"data":486,"type":218},"p-eval-1",{"text":487},"El comportamiento de la IA es parcialmente no determinista, por lo que la definición de la versión no puede depender únicamente de pruebas unitarias convencionales. La arquitectura necesita una aceptación medible: éxito de la tarea, fundamentación o corrección de citas cuando sea relevante, comportamiento de rechazo, seguridad de las herramientas, latencia, costo, confiabilidad y pruebas de seguridad. Las métricas exactas dependen del caso de uso.",{"id":489,"data":490,"type":218},"p-eval-2",{"text":491},"La guía actual de Well-Architected AI de Microsoft trata el monitoreo como continuo y lo aplica en el comportamiento del modelo, las indicaciones\u002Fcompletaciones, las anomalías, la seguridad y las puertas de calidad de producción. AWS de manera similar trata la observabilidad, la gestión del ciclo de vida y la trazabilidad del modelo\u002Findicaciones como preocupaciones de la arquitectura operativa.",{"id":493,"data":494,"type":42},"h-artifacts",{"text":495,"level":242},"¿Qué debería producir el rol?",{"id":497,"data":498,"type":218},"p-artifacts-1",{"text":499},"La arquitectura no es la presentación de diapositivas. Los resultados útiles son los artefactos que permiten a ingeniería, seguridad, producto y operaciones tomar decisiones consistentes y luego entender por qué el sistema existe en su forma actual.",{"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],"Artefacto","Propósito",[508,509],"Contexto y límite de la solución","Muestra usuarios, sistemas externos, responsabilidades principales y lo que está fuera del alcance",[511,512],"Mapa de requisitos\u002FNFR","Conecta la necesidad del producto y las restricciones con el trabajo de arquitectura y la validación",[514,515],"Vistas de componentes y flujo de datos","Muestra las interacciones de aplicación, datos\u002Frecuperación, modelo, herramientas, identidad y tiempo de ejecución",[517,518],"Modelo de confianza y permisos","Hace explícitos las identidades, secretos, autorización, datos sensibles y acciones de alto riesgo",[520,521],"Registros de decisiones de arquitectura","Preserva decisiones significativas, alternativas, compensaciones, estado y consecuencias",[523,524],"Plan de evaluación y aceptación","Define la evidencia requerida para afirmar que la solución cumple con las expectativas de calidad y seguridad",[526,527],"Vista de despliegue y operativa","Define entornos, ubicaciones de ejecución, observabilidad, reversión, incidentes y responsabilidades del ciclo de vida",[529,530],"Enlaces de trazabilidad","Conecta requisitos, decisiones, trabajo de implementación, pruebas y evidencia operativa",{"id":532,"data":533,"type":42},"h-tradeoffs",{"text":534,"level":242},"El trabajo es principalmente compensaciones, no selección de 'mejores prácticas'",{"id":536,"data":537,"type":218},"p-tradeoffs-1",{"text":538},"La arquitectura existe porque las cualidades deseables entran en conflicto. Un modelo de menor costo puede reducir la calidad. Un modelo más capaz puede aumentar la latencia o las restricciones de gobernanza de datos. El almacenamiento en caché agresivo puede mejorar el costo y la velocidad mientras complica la frescura. Los agentes más autónomos pueden reducir el esfuerzo humano mientras aumentan el radio de impacto y los requisitos de auditoría.",{"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],"Decisión","Beneficio potencial","Costo \u002F riesgo potencial","Pregunta arquitectónica",[549,550,551,552],"Modelo en la nube gestionado","Adopción rápida, capacidades gestionadas sólidas","Dependencia externa, restricciones de datos y costo","¿La carga de trabajo permite el proveedor\u002Fruta de datos y cumple con las necesidades de resiliencia?",[554,555,556,557],"Inferencia local\u002Fautoalojada","Control, opciones sin conexión\u002Fprivadas","Carga de hardware, operaciones, ciclo de vida del modelo","¿Vale la pena el beneficio de control frente a la responsabilidad operativa?",[559,560,561,562],"Integración con un solo proveedor","Implementación más simple, características completas del proveedor","Mayor concentración de cambio\u002Ffallo","¿Se requiere realmente portabilidad o respaldo?",[564,565,566,567],"Abstracción del proveedor","Portabilidad, enrutamiento y separación de políticas","Riesgo de mínimo común denominador, más código\u002Fpruebas","¿Qué diferencias deben permanecer visibles en lugar de abstraerse?",[569,570,571,572],"Contexto grande","Más información por solicitud","Latencia, costo, dilución de atención, superficie de fuga","¿Deberían recuperarse\u002Ffiltrarse los datos en lugar de inyectarse siempre?",[574,575,576,577],"Herramientas potentes \u002F autonomía","Más automatización de extremo a extremo","Mayor privilegio y radio de impacto de fallos","¿Qué acciones requieren privilegio mínimo, confirmación o aprobación humana?",[579,580,581,582],"Validación y registro estrictos","Mejor evidencia y operaciones","Costo de latencia, almacenamiento, privacidad y complejidad","¿Qué evidencia se requiere para este nivel de riesgo?",{"id":584,"data":585,"type":42},"h-adjacent",{"text":586,"level":242},"¿En qué se diferencia de roles adyacentes?",{"id":588,"data":589,"type":218},"p-adjacent-intro",{"text":590},"Los títulos se superponen mucho entre empresas. La distinción útil es el \u003Cstrong>alcance de la responsabilidad de arquitectura\u003C\u002Fstrong>, no la etiqueta de recursos humanos.",{"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","Arquitecto de Soluciones de IA",{"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","Arquitecto de Plataforma de IA",{"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","Arquitecto de IA Empresarial",{"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","Ingeniero de IA \u002F ML",{"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","Arquitecto de Seguridad",{"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","Líder de Producto \u002F Entrega",{"role":629,"focus":630},"Outcome, scope, prioritization and delivery system","Why\u002Fwhat to build, sequencing, stakeholders, milestones, acceptance and value realization","Los roles adyacentes responden a preguntas principales diferentes",[633,636],{"id":634,"label":635},"role","Rol",{"id":637,"label":638},"focus","Enfoque principal de arquitectura",{"id":640,"data":641,"type":218},"p-adjacent-2",{"text":642},"En un equipo de producto pequeño, una persona puede cubrir varios de estos alcances. En una gran empresa, pueden ser roles separados con juntas de revisión formales. La responsabilidad de arquitectura no desaparece cuando cambia el título.",{"id":644,"data":645,"type":42},"h-implementation",{"text":646,"level":242},"Evidencia de implementación: cómo aparecen estos límites en mi propio trabajo",{"id":648,"data":649,"type":225},"implementation-boundary",{"body":650,"title":651,"variant":652},"Los ejemplos a continuación son \u003Cstrong>evidencia original de implementación\u002Fproyecto\u003C\u002Fstrong>. Muestran cómo he separado la necesidad del producto, los requisitos, la arquitectura, el tiempo de ejecución, el modelo\u002Fproveedor, los permisos y la validación en el trabajo real del proyecto. No son afirmaciones de que cada organización deba usar la misma estructura, y no implican adopción por parte de clientes ni despliegue a escala empresarial.","Evidencia de implementación, no una regla universal","success",{"id":654,"data":655,"type":42},"h-senseflow",{"text":656,"level":241},"SenseFlow: necesidad → requisitos → arquitectura → validación",{"id":658,"data":659,"type":218},"p-senseflow-1",{"text":660},"En la Fuente de Verdad del proyecto SenseFlow, la tecnología está explícitamente subordinada a la Visión del Producto. La estructura de desarrollo avanza desde el problema y la visión del producto a través de las necesidades del usuario, el valor, el alcance, las epopeyas, las historias y los criterios de aceptación hacia la arquitectura, la implementación, la validación y la iteración.",{"id":662,"data":663,"type":218},"p-senseflow-2",{"text":664},"Los requisitos están diseñados para ser trazables desde Objetivo del Producto → Capacidad → Épica → Historia de Usuario → Criterios de Aceptación → Tareas Técnicas. Cuando es práctico, incluyen requisitos funcionales, RNF, dependencias, riesgos, supuestos, criterios de aceptación y métodos de validación. Las decisiones significativas preservan la decisión, la razón, las alternativas, las compensaciones, el estado y la fecha\u002Fversión.",{"id":666,"data":667,"type":218},"p-senseflow-3",{"text":668},"Eso es trabajo arquitectónico antes de que se elija un marco de IA o modelo específico: protege la conexión entre la intención del producto y las decisiones técnicas y hace que los cambios posteriores sean revisables en lugar de implícitos.",{"id":670,"data":671,"type":42},"h-client",{"text":672,"level":241},"Aaasaasa AI Client: separar conceptos antes de integrarlos",{"id":674,"data":675,"type":218},"p-client-1",{"text":676},"Aaasaasa AI Client proporciona un ejemplo más a nivel de implementación. Su AI Hub separa deliberadamente \u003Cstrong>agente\u002Fcliente\u003C\u002Fstrong>, \u003Cstrong>proveedor\u003C\u002Fstrong>, \u003Cstrong>modelo\u003C\u002Fstrong>, \u003Cstrong>conexión\u002Fubicación del runtime\u003C\u002Fstrong>, \u003Cstrong>permisos\u003C\u002Fstrong> y \u003Cstrong>cliente web\u003C\u002Fstrong>. No se asume que un runtime local signifique inferencia local, y los permisos se tratan como política de runtime\u002Fherramientas en lugar de como una propiedad del modelo.",{"id":678,"data":679,"type":218},"p-client-2",{"text":680},"La arquitectura de escritorio también define un límite de confianza: el renderizador de Nuxt no es de confianza en relación con el proceso principal de Electron. Un preload estrecho y una IPC validada median el acceso a servicios de IA, configuración, secretos cifrados, servicios de espacio de trabajo\u002Fdatos y runtimes. Las credenciales en la nube permanecen en el proceso principal privilegiado; el código del renderizador recibe estado normalizado en lugar de secretos sin procesar o acceso sin restricciones al sistema operativo.",{"id":682,"data":683,"type":218},"p-client-3",{"text":684},"Las decisiones de enrutamiento son igualmente arquitectónicas. La implementación no recurre silenciosamente de una ruta local a inferencia en la nube de pago; una ruta en la nube requiere confirmación explícita. El Chat Directo no tiene herramientas de sistema de archivos o shell por defecto, mientras que la ejecución del agente aplica un espacio de trabajo y un perfil de permisos seleccionados. Estas son decisiones a nivel de solución sobre confianza, costo, ejecución y expectativas del usuario, no características del modelo.",{"id":686,"data":687,"type":42},"h-current-frameworks",{"text":688,"level":242},"Cómo los marcos de arquitectura actuales apoyan este alcance más amplio",{"id":690,"data":691,"type":218},"p-frameworks-1",{"text":692},"ISO\u002FIEC\u002FIEEE 42010:2022 proporciona una disciplina general para descripciones de arquitectura en software, sistemas y empresas. Es deliberadamente más amplio que la IA y no prescribe un método de arquitectura o título de trabajo único. Eso lo hace útil aquí como un límite: la arquitectura de soluciones de IA sigue siendo arquitectura, con preocupaciones de las partes interesadas, múltiples vistas y relaciones significativas que deben expresarse claramente.",{"id":694,"data":695,"type":218},"p-frameworks-2",{"text":696},"NIST AI RMF 1.0 enmarca la gestión de riesgos de IA a través de \u003Cstrong>Govern, Map, Measure y Manage\u003C\u002Fstrong> y enfatiza que la gestión de riesgos debe ser continua a lo largo del ciclo de vida del sistema de IA. El Perfil de IA Generativa (NIST AI 600-1) adapta ese marco a los riesgos de GAI y las prioridades organizacionales. Esto refuerza que la arquitectura no puede detenerse en el rendimiento funcional del modelo.",{"id":698,"data":699,"type":218},"p-frameworks-3",{"text":700},"La guía actual de Azure Well-Architected AI de Microsoft separa el diseño de aplicaciones, la plataforma de aplicaciones, los datos de entrenamiento, los datos de fundamentación y las preocupaciones de la plataforma de datos y las conecta repetidamente con la confiabilidad, la seguridad, la excelencia operativa, el rendimiento y el costo. Las lentes de IA Generativa e IA Agéntica de AWS tratan de manera similar la observabilidad, la seguridad, la confiabilidad, el ciclo de vida del modelo\u002Fherramienta, el costo y la supervisión humana como preocupaciones arquitectónicas.",{"id":702,"data":703,"type":42},"h-misconceptions",{"text":704,"level":242},"Conceptos erróneos comunes",{"id":706,"data":707,"type":291},"misconceptions-table",{"content":708,"stretched":43,"withHeadings":14},[709,712,715,718,721,724,727,730],[710,711],"Concepto erróneo","Corrección",[713,714],"“El arquitecto elige el LLM.”","La elección del modelo es una decisión dentro de una arquitectura de solución más amplia.",[716,717],"“La ingeniería de prompts es la arquitectura.”","Los prompts afectan el comportamiento, pero no definen identidad, acceso a datos, límites de confianza, despliegue, permisos de herramientas u operaciones.",[719,720],"“RAG resuelve el conocimiento empresarial.”","La recuperación es solo un subsistema; la autorización, la procedencia, la actualidad, la evidencia, la indexación, la evaluación y la gobernanza de fuentes aún necesitan diseño.",[722,723],"“Runtime local significa IA privada\u002Flocal.”","Las ubicaciones del runtime, la inferencia, los datos y el plano de control son propiedades arquitectónicas separadas.",[725,726],"“Si un proveedor ofrece barreras de protección, la seguridad está cubierta.”","La seguridad abarca identidad, autorización, secretos, flujos de datos, herramientas, registro, despliegue, aprobación humana y límites del proveedor.",[728,729],"“El arquitecto debe escribir cada componente.”","La implementación práctica puede mejorar la calidad arquitectónica, pero el rol se define por la responsabilidad de decisiones integradas, no por codificar personalmente cada capa.",[731,732],"“Un diagrama de arquitectura demuestra preparación para producción.”","La preparación requiere controles implementados y evidencia de validación en calidad, seguridad, operaciones y aceptación empresarial.",{"id":734,"data":735,"type":42},"h-failures",{"text":736,"level":242},"Modos de falla que un Arquitecto de Soluciones de IA debe prevenir",{"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],"Modo de falla","Por qué ocurre","Corrección arquitectónica",[746,747,748],"Diseño centrado primero en el modelo","Una demostración prometedora de un modelo se convierte en el plano del sistema","Comenzar por el resultado, las restricciones y la validación; seleccionar el modelo dentro de ese marco",[750,751,752],"Permisos de prototipo en producción","Las credenciales compartidas y el acceso amplio sobreviven a la PoC","Definir la propagación de identidad, el privilegio mínimo, los alcances de herramientas y los límites de aprobación desde el principio",[754,755,756],"Recuperación sin autorización","La calidad de búsqueda se diseña antes que las reglas de acceso a datos","Llevar el contexto de usuario\u002Finquilino a la recuperación y aplicar autorización en los límites de acceso a datos",[758,759,760],"Supuestos silenciosos de proveedor\u002Fruntime","“Local”, “nube” y “sin conexión” se usan de manera imprecisa","Documentar por separado la ubicación del runtime, la inferencia, los datos y el plano de control",[762,763,764],"Sin contrato de falla","Se diseña el camino feliz pero no el comportamiento de rechazo\u002Ffallback\u002Ferror","Especificar el comportamiento cuando la recuperación está vacía, el modelo no está disponible, falla una herramienta o se deniega por política",[766,767,768],"Evaluación después de la implementación","La calidad se juzga manualmente cerca del lanzamiento","Definir aceptación medible y conjuntos de evaluación representativos antes de que se congele la arquitectura",[770,771,772],"Cambio no trazable","Modelos, prompts, recuperación o permisos cambian sin historial arquitectónico","Versionar la configuración crítica y registrar decisiones significativas\u002Fevidencia de validación",[774,775,776],"Operaciones tratadas solo como infraestructura","El comportamiento de la IA no es observable después del despliegue","Diseñar juntos trazas, métricas de calidad, eventos de seguridad, telemetría de costos y reversión",{"id":778,"data":779,"type":42},"h-decision-framework",{"text":780,"level":242},"Una secuencia de decisión práctica",{"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},"Resultado","Definir el resultado del usuario\u002Fnegocio y los no objetivos explícitos.",{"label":789,"description":790},"Evidencia y restricciones","Identificar datos autorizados, políticas, RNF, riesgos y condiciones de aceptación.",{"label":792,"description":793},"Límite del sistema","Mapear usuarios, identidades, aplicaciones, datos, modelos\u002Fproveedores, herramientas y sistemas externos.",{"label":795,"description":796},"Opciones de arquitectura","Comparar patrones para recuperación, acceso a modelos, orquestación, despliegue, permisos, evaluación y observabilidad.",{"label":798,"description":799},"Decisiones de compensación","Seleccionar opciones significativas y preservar la justificación, las alternativas y las consecuencias.",{"label":801,"description":802},"Contratos de implementación","Convertir decisiones en API, esquemas, reglas de permisos, definiciones de despliegue y tareas de ingeniería.",{"label":804,"description":805},"Validación","Probar el sistema implementado contra los requisitos funcionales y no funcionales originales.",{"label":807,"description":808},"Retroalimentación operativa","Usar evidencia de producción, incidentes, métricas de calidad y señales de costo\u002Fseguridad para desencadenar cambios controlados.","Secuencia de decisión de arquitectura de soluciones de IA",{"id":811,"data":812,"type":42},"h-edge",{"text":813,"level":242},"Casos límite y límites del rol",{"id":815,"data":816,"type":218},"p-edge-1",{"text":817},"Algunos productos de IA están dominados por el entrenamiento de modelos, la experimentación científica o el hardware especializado. En esos casos, la ciencia de datos\u002Fmodelos y la arquitectura de sistemas de ML pueden volverse mucho más profundas que el mapa a nivel de solución que se muestra aquí. El Arquitecto de Soluciones de IA aún necesita límites de integración y operativos, pero la arquitectura especializada puede ser propietaria de la plataforma de entrenamiento en sí.",{"id":819,"data":820,"type":218},"p-edge-2",{"text":821},"En el otro extremo, una integración SaaS simple puede no justificar un arquitecto dedicado. Un ingeniero sénior o un líder técnico de producto puede asumir la misma responsabilidad de arquitectura. La prueba útil no es el título, sino si se están tomando decisiones significativas entre capas de forma deliberada y validada.",{"id":823,"data":824,"type":218},"p-edge-3",{"text":825},"Los sistemas regulados, soberanos, con aislamiento de red, de seguridad crítica, altamente autónomos o multiinquilino también desplazan el centro de gravedad. La identidad, el aislamiento, la residencia, la garantía, los mecanismos de actualización, la supervisión humana y la auditabilidad pueden dominar la calidad del modelo en la arquitectura.",{"id":827,"data":828,"type":42},"h-change-answer",{"text":829,"level":242},"¿Qué cambiaría esta respuesta?",{"id":831,"data":832,"type":218},"p-change-1",{"text":833},"El límite exacto de responsabilidad cambia cuando la arquitectura pasa de una aplicación a una plataforma reutilizable o a una arquitectura objetivo a nivel empresarial. Por eso \u003Cstrong>AI Platform Architect\u003C\u002Fstrong> y \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> merecen un tratamiento canónico separado en lugar de fusionarse en este rol.",{"id":835,"data":836,"type":218},"p-change-2",{"text":837},"Los cambios tecnológicos también importan. Las nuevas capacidades de los modelos, los protocolos, los entornos de ejecución locales y los servicios gestionados pueden eliminar parte del trabajo de implementación mientras crean nuevos límites de confianza u operativos. La responsabilidad estable es entender esos cambios como cambios del sistema, no tratar un nuevo framework como un reemplazo de la arquitectura.",{"id":839,"data":840,"type":42},"h-checklist",{"text":841,"level":242},"Lista de verificación del 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,879],[847,848],"Verificación","Pregunta",[786,850],"¿Están explícitos el resultado de usuario\u002Fnegocio y el límite de no objetivos?",[852,853],"Requisitos","¿Son trazables los requisitos funcionales, los RNF, las restricciones y los criterios de aceptación?",[268,855],"¿Están definidas las fuentes autorizadas, la procedencia, la frescura, la retención y las reglas de acceso?",[857,858],"Recuperación\u002Fcontexto","¿La autorización alcanza la recuperación y la construcción de contexto?",[860,861],"Modelo\u002Fproveedor","¿La selección de modelo\u002Fproveedor está vinculada a capacidades y restricciones en lugar de a preferencias?",[863,864],"Herramientas\u002Fagentes","¿Están explícitos los límites de acción, los permisos, las aprobaciones y el comportamiento ante fallos?",[866,867],"Identidad\u002Fseguridad","¿Están definidas las identidades humanas\u002Fmáquina, los secretos y los límites de confianza?",[869,870],"Entorno de ejecución","¿Se distinguen las ubicaciones del entorno de ejecución, la inferencia, los datos y el plano de control?",[872,873],"Evaluación","¿Existe evidencia medible de calidad, seguridad y aceptación?",[875,876],"Observabilidad","¿Se puede investigar el comportamiento en producción, los fallos, el coste y los eventos de seguridad?",[286,878],"¿Son trazables las decisiones de arquitectura significativas y los reemplazos?",[280,880],"¿Está clara la responsabilidad sobre el despliegue, la reversión, los incidentes y el ciclo de vida?",{"id":882,"data":883,"type":42},"h-conclusion",{"text":884,"level":242},"Conclusión",{"id":886,"data":887,"type":218},"p-conclusion-1",{"text":888},"Un AI Solution Architect es la persona o la función de arquitectura que convierte una oportunidad de IA en un sistema técnico coherente. La habilidad clave no es conocer la mayor cantidad de nombres de modelos; es conectar la necesidad del producto, los requisitos, los datos, la arquitectura de la aplicación, las capacidades de IA, la seguridad, el entorno de ejecución, la entrega y la validación sin perder los límites entre ellos.",{"id":890,"data":891,"type":218},"p-conclusion-2",{"text":892},"Por lo tanto, una sólida arquitectura de solución de IA puede resumirse así: \u003Cstrong>definir el objetivo → establecer requisitos y restricciones → diseñar los límites del sistema → hacer explícitos los compromisos significativos → implementar mediante contratos claros → validar con evidencia → operar y evolucionar de forma deliberada.\u003C\u002Fstrong> El modelo es importante. La solución es el producto.",{"id":894,"data":895,"type":894},"faq",{"items":896,"title":929},[897,901,905,909,913,917,921,925],{"id":898,"answer":899,"question":900},"faq1","Un AI Solution Architect traduce una necesidad de negocio o de producto en la arquitectura de una solución concreta habilitada por IA, definiendo cómo funcionan juntos la lógica de la aplicación, los datos\u002Frecuperación, los modelos, las herramientas, la identidad, la seguridad, el entorno de ejecución, la evaluación y las operaciones.","¿Qué es un AI Solution Architect?",{"id":902,"answer":903,"question":904},"faq2","No. Los roles pueden solaparse, especialmente en equipos pequeños, pero un ingeniero de IA es principalmente un rol de implementación, mientras que el arquitecto de soluciones posee o coordina las decisiones de arquitectura entre capas y los compromisos para la carga de trabajo completa.","¿Es un AI Solution Architect lo mismo que un ingeniero de IA?",{"id":906,"answer":907,"question":908},"faq3","No por definición, pero el conocimiento práctico de implementación es muy valioso porque la arquitectura de IA cruza API, datos, recuperación, seguridad, entornos de ejecución y comportamiento operativo. El rol se define por la responsabilidad de arquitectura, no por escribir personalmente cada componente.","¿Un AI Solution Architect necesita programar?",{"id":910,"answer":911,"question":912},"faq4","No. La selección del modelo es una decisión. La arquitectura de producción también necesita límites de datos y recuperación, permisos, herramientas, elecciones de proveedor\u002Fentorno de ejecución, observabilidad, evaluación, fiabilidad, coste y diseño del ciclo de vida.","¿Elegir un LLM es el trabajo principal?",{"id":914,"answer":915,"question":916},"faq5","Un AI Solution Architect se centra en una solución o carga de trabajo concreta. Un AI Platform Architect se centra en capacidades y barreras de seguridad de IA reutilizables que dan soporte a múltiples soluciones.","¿Cuál es la diferencia entre un AI Solution Architect y un AI Platform Architect?",{"id":918,"answer":919,"question":920},"faq6","El arquitecto de soluciones trabaja en el ámbito de aplicación\u002Fcarga de trabajo. La arquitectura empresarial de IA trabaja en todo el portafolio organizacional, la arquitectura objetivo, la gobernanza, las capacidades compartidas, los principios de integración y las restricciones estratégicas.","¿Cuál es la diferencia entre un AI Solution Architect y un Enterprise AI Architect?",{"id":922,"answer":923,"question":924},"faq7","Son patrones arquitectónicos o subsistemas dentro de una solución cuando los requisitos los justifican. RAG aborda el contexto fundamentado en la recuperación; los agentes añaden planificación\u002Fejecución de herramientas y, por lo tanto, preocupaciones adicionales de identidad, permisos, orquestación y operación.","¿Dónde encajan RAG y los agentes?",{"id":926,"answer":927,"question":928},"faq8","La implementación más la evidencia de validación: pruebas funcionales, resultados de evaluación, pruebas de seguridad\u002Fautorización, mediciones de rendimiento y fiabilidad, observabilidad, ensayo operativo y aceptación frente a los requisitos originales.","¿Qué demuestra que la arquitectura funciona?","AI Solution Architect — Preguntas frecuentes",{"id":931,"data":932,"type":931},"glossary",{"title":933,"entries":934},"Términos clave",[935,939,942,946,950,954,957,961],{"term":936,"anchor":937,"definition":938},"AI Solution Architect","ai-solution-architect","Responsabilidad de arquitectura para una solución o carga de trabajo concreta habilitada por IA, integrando los requisitos del producto con el diseño de aplicación, datos, modelo, herramientas, seguridad, entorno de ejecución y operaciones.",{"term":792,"anchor":940,"definition":941},"system-boundary","La separación explícita entre lo que pertenece a la solución y los usuarios, sistemas, proveedores, fuentes de datos y entornos con los que interactúa.",{"term":943,"anchor":944,"definition":945},"Límite de confianza","trust-boundary","Un punto donde los datos, las identidades o el control cruzan entre componentes con diferentes supuestos de confianza y, por lo tanto, requieren controles de seguridad explícitos.",{"term":947,"anchor":948,"definition":949},"Fundamentación","grounding","Proporcionar a un modelo de IA información o evidencia externa relevante para que su respuesta pueda basarse en fuentes más allá de los parámetros del modelo.",{"term":951,"anchor":952,"definition":953},"Abstracción de proveedor","provider-abstraction","Un límite de aplicación que desacopla partes de la solución de una interfaz de modelo\u002Fproveedor. Útil cuando lo justifican necesidades de enrutamiento, portabilidad o políticas, pero no exento de compromisos.",{"term":872,"anchor":955,"definition":956},"evaluation","Medición estructurada del comportamiento de la carga de trabajo de IA frente a criterios de aceptación definidos, incluida la calidad de la tarea y las propiedades relevantes de seguridad, protección, rendimiento y operación.",{"term":958,"anchor":959,"definition":960},"AI Platform Architect","ai-platform-architect","Rol arquitectónico centrado en capacidades de plataforma de IA reutilizables utilizadas por múltiples soluciones en lugar de la arquitectura de una sola carga de trabajo.",{"term":962,"anchor":963,"definition":964},"Enterprise AI Architecture","enterprise-ai-architecture","Arquitectura a nivel de organización que coordina capacidades de IA, plataformas, gobernanza, integración y restricciones estratégicas en todo un portafolio.",{"id":966,"data":967,"type":42},"h-related",{"text":968,"level":242},"Conocimiento canónico relacionado",{"id":970,"data":971,"type":218},"p-related-1",{"text":972},"Este artículo se sitúa en el clúster de Fundamentos de Arquitectura de IA. Sus fundamentos directos son \u003Cstrong>Generative AI Explained: Models, Retrieval, Tools and Applications Are Not the Same Thing\u003C\u002Fstrong> y \u003Cstrong>ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing\u003C\u002Fstrong>. Los nodos canónicos adyacentes incluyen \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> y \u003Cstrong>AI Governance\u003C\u002Fstrong>. Las URL no se fabrican intencionadamente donde esos nodos aún no se han publicado.",{"id":974,"data":975,"type":982},"related-rag",{"link":976,"meta":977},"https:\u002F\u002Fstajic.de\u002Fes\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","Explicación canónica existente en stajic.de sobre la generación aumentada por recuperación, útil para la parte de recuperación\u002Ffundamentación de la arquitectura de soluciones de IA.","linkTool",{"id":984,"data":985,"type":42},"h-sources",{"text":986,"level":242},"Fuentes primarias y guía arquitectónica actual",{"id":988,"data":989,"type":218},"p-sources-note",{"text":990},"Las fuentes externas a continuación respaldan las afirmaciones arquitectónicas generales; las secciones de SenseFlow y Aaasaasa AI Client son evidencia explícita y original del proyecto\u002Fimplementación. Las referencias al estado actual se verificaron el 8 de octubre de 2026. NIST señala que AI RMF 1.0 está siendo revisado, por lo que las referencias de gobernanza sensibles a la versión deben volver a verificarse cuando se publique un sucesor.",{"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","Estándar internacional actual para la estructura y expresión de descripciones de arquitectura. Distingue la arquitectura de su descripción y no prescribe un único método, herramienta o formato de registro de arquitectura.",{"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},"Marco de Gestión de Riesgos de IA del NIST","Página de recursos del AI RMF del NIST. A partir de octubre de 2026, indica que el AI RMF 1.0 está siendo revisado y enlaza el Perfil de IA Generativa y recursos relacionados.",{"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},"Núcleo del AI RMF del NIST — Gobernar, Mapear, Medir, Gestionar","Presentación oficial del Núcleo del AI RMF 1.0 del AIRC del NIST, que incluye las cuatro funciones y el enfoque de gestión de riesgos orientado al ciclo de vida.",{"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 — Perfil de IA Generativa","Perfil intersectorial de IA Generativa para el AI RMF 1.0, publicado el 26 de julio de 2024 y actualizado por el NIST en 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 — Cargas de trabajo de IA","Guía actual de arquitectura a nivel de carga de trabajo que abarca el diseño de aplicaciones de IA, la plataforma de aplicaciones, los datos de entrenamiento, los datos de fundamentación, la plataforma de datos y las preocupaciones de preparación para producción.",{"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 — Diseño de aplicaciones para cargas de trabajo de IA","Guía sobre la abstracción de modelos\u002Fherramientas, los límites de acceso a datos, la propagación de identidad, la autorización y la separación de las capas de cliente, inteligencia, conocimiento y herramientas.",{"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 — Principios de diseño para cargas de trabajo de IA","Principios actuales de diseño de cargas de trabajo de IA en materia de confiabilidad, seguridad, costo, excelencia operativa y rendimiento, incluidos las responsabilidades de identidad y protección de datos.",{"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 y GenAIOps para cargas de trabajo de IA","Guía del ciclo de vida de producción que abarca el monitoreo, las puertas de calidad, el comportamiento de modelos\u002Fprompts, la seguridad y la medición operativa.",{"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},"Lente de IA Generativa de AWS Well-Architected","Guía arquitectónica de AWS para cargas de trabajo de IA generativa en materia de excelencia operativa, seguridad, confiabilidad, eficiencia de rendimiento, optimización de costos y sostenibilidad.",{"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},"Lente de IA Agéntica de AWS Well-Architected","Publicado en 2026, abarca preocupaciones arquitectónicas específicas de agentes, incluidas identidades, herramientas, orquestación, supervisión humana, confiabilidad, trazabilidad y costo del bucle de razonamiento.","2.31","Un Arquitecto de Soluciones de IA convierte los requisitos empresariales en un sistema de IA listo para producción que abarca datos, modelos, herramientas, seguridad, tiempo de ejecución, evaluación y operaciones.","\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,"Límites de datos","data-boundaries",{"id":1094,"name":1095,"slug":1096},84,"Política y límites de datos","policy-and-data",{"id":1098,"name":1099,"slug":1100},80,"Acceso e identidad","access-and-identity",{"id":1102,"name":1103,"slug":1104},54,"Modelo de amenazas","threat-model",{"id":1106,"login":1107,"email":1108,"displayName":1109},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1111,1793],{"lang":1112,"title":1113,"content":1114,"contentJson":1115,"excerpt":1792},"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":1791},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,1692,1714,1717,1720,1726,1729,1732,1737,1743,1749,1755,1761,1767,1773,1779,1785],{"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":936,"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":882,"data":1656,"type":42},{"text":1657,"level":242},"Conclusion",{"id":886,"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":890,"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":894,"data":1665,"type":894},{"items":1666,"title":1691},[1667,1670,1673,1676,1679,1682,1685,1688],{"id":898,"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":902,"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":906,"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":910,"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":914,"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":918,"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":922,"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":926,"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?","AI Solution Architect — FAQ",{"id":931,"data":1693,"type":931},{"title":1694,"entries":1695},"Core terms",[1696,1698,1700,1703,1706,1708,1710,1712],{"term":936,"anchor":937,"definition":1697},"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":940,"definition":1699},"The explicit separation between what belongs to the solution and the users, systems, providers, data sources and environments it interacts with.",{"term":1701,"anchor":944,"definition":1702},"Trust boundary","A point where data, identities or control cross between components with different trust assumptions and therefore require explicit security controls.",{"term":1704,"anchor":948,"definition":1705},"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":1707},"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":1709},"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":1711},"Architectural role focused on reusable AI platform capabilities used by multiple solutions rather than the architecture of one workload.",{"term":962,"anchor":963,"definition":1713},"Organization-level architecture that coordinates AI capabilities, platforms, governance, integration and strategic constraints across a portfolio.",{"id":966,"data":1715,"type":42},{"text":1716,"level":242},"Related canonical knowledge",{"id":970,"data":1718,"type":218},{"text":1719},"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":1721,"type":982},{"link":1722,"meta":1723},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works",{"image":1724,"title":980,"description":1725},{"url":979},"Existing stajic.de canonical explanation of retrieval-augmented generation, useful for the retrieval\u002Fgrounding part of AI solution architecture.",{"id":984,"data":1727,"type":42},{"text":1728,"level":242},"Primary sources and current architecture guidance",{"id":988,"data":1730,"type":218},{"text":1731},"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":1733,"type":982},{"link":994,"meta":1734},{"image":1735,"title":997,"description":1736},{"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":1738,"type":982},{"link":1002,"meta":1739},{"image":1740,"title":1741,"description":1742},{"url":979},"NIST AI Risk Management Framework","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":1744,"type":982},{"link":1010,"meta":1745},{"image":1746,"title":1747,"description":1748},{"url":979},"NIST AI RMF Core — Govern, Map, Measure, Manage","Official NIST AIRC presentation of the AI RMF 1.0 Core, including the four functions and lifecycle-oriented risk-management framing.",{"id":1016,"data":1750,"type":982},{"link":1018,"meta":1751},{"image":1752,"title":1753,"description":1754},{"url":979},"NIST AI 600-1 — Generative AI Profile","Cross-sectoral Generative AI profile for AI RMF 1.0, published 26 July 2024 and updated by NIST in 2026.",{"id":1024,"data":1756,"type":982},{"link":1026,"meta":1757},{"image":1758,"title":1759,"description":1760},{"url":979},"Microsoft Azure Well-Architected — AI Workloads","Current workload-level architecture guidance covering AI application design, application platform, training data, grounding data, data platform and production-readiness concerns.",{"id":1032,"data":1762,"type":982},{"link":1034,"meta":1763},{"image":1764,"title":1765,"description":1766},{"url":979},"Microsoft — Application Design for AI Workloads","Guidance on model\u002Ftool abstraction, data-access boundaries, identity propagation, authorization and separation of client, intelligence, knowledge and tool layers.",{"id":1040,"data":1768,"type":982},{"link":1042,"meta":1769},{"image":1770,"title":1771,"description":1772},{"url":979},"Microsoft — Design Principles for AI Workloads","Current AI workload design principles across reliability, security, cost, operational excellence and performance, including identity and data-protection responsibilities.",{"id":1048,"data":1774,"type":982},{"link":1050,"meta":1775},{"image":1776,"title":1777,"description":1778},{"url":979},"Microsoft — MLOps and GenAIOps for AI Workloads","Production lifecycle guidance covering monitoring, quality gates, model\u002Fprompt behavior, security and operational measurement.",{"id":1056,"data":1780,"type":982},{"link":1058,"meta":1781},{"image":1782,"title":1783,"description":1784},{"url":979},"AWS Well-Architected Generative AI Lens","AWS architectural guidance for generative AI workloads across operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.",{"id":1064,"data":1786,"type":982},{"link":1066,"meta":1787},{"image":1788,"title":1789,"description":1790},{"url":979},"AWS Well-Architected Agentic AI Lens","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":1794,"excerpt":1072},{"time":212,"blocks":1795,"version":1071},[1796,1798,1800,1802,1804,1806,1808,1810,1812,1828,1830,1832,1834,1844,1846,1848,1850,1852,1854,1868,1870,1872,1874,1876,1878,1880,1882,1884,1886,1888,1890,1892,1894,1896,1898,1900,1902,1904,1906,1908,1910,1912,1914,1926,1928,1930,1941,1943,1945,1963,1965,1967,1969,1971,1973,1975,1977,1979,1981,1983,1985,1987,1989,1991,1993,1995,2006,2008,2020,2022,2033,2035,2037,2039,2041,2043,2045,2047,2049,2065,2067,2069,2071,2082,2093,2095,2097,2101,2103,2105,2109,2113,2117,2121,2125,2129,2133,2137,2141],{"id":215,"data":1797,"type":218},{"text":217},{"id":220,"data":1799,"type":225},{"body":222,"title":223,"variant":224},{"id":227,"data":1801,"type":225},{"body":229,"title":230,"variant":231},{"id":233,"data":1803,"type":225},{"body":235,"title":236,"variant":231},{"id":238,"data":1805,"type":243},{"title":240,"maxLevel":241,"minLevel":242},{"id":245,"data":1807,"type":42},{"text":247,"level":242},{"id":249,"data":1809,"type":218},{"text":251},{"id":253,"data":1811,"type":218},{"text":255},{"id":257,"data":1813,"type":299},{"rows":1814,"title":290,"layout":291,"columns":1825},[1815,1817,1819,1821,1823],{"id":261,"label":262,"values":1816},{"model":264,"solution":265},{"id":267,"label":268,"values":1818},{"model":270,"solution":271},{"id":273,"label":274,"values":1820},{"model":276,"solution":277},{"id":279,"label":280,"values":1822},{"model":282,"solution":283},{"id":285,"label":286,"values":1824},{"model":288,"solution":289},[1826,1827],{"id":294,"label":295},{"id":297,"label":298},{"id":301,"data":1829,"type":42},{"text":303,"level":242},{"id":305,"data":1831,"type":218},{"text":307},{"id":309,"data":1833,"type":218},{"text":311},{"id":313,"data":1835,"type":339},{"steps":1836,"title":337,"orientation":338},[1837,1838,1839,1840,1841,1842,1843],{"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":1845,"type":42},{"text":343,"level":242},{"id":345,"data":1847,"type":218},{"text":347},{"id":349,"data":1849,"type":218},{"text":351},{"id":353,"data":1851,"type":42},{"text":355,"level":242},{"id":357,"data":1853,"type":218},{"text":359},{"id":361,"data":1855,"type":291},{"content":1856,"stretched":43,"withHeadings":14},[1857,1858,1859,1860,1861,1862,1863,1864,1865,1866,1867],[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":1869,"type":42},{"text":411,"level":241},{"id":413,"data":1871,"type":218},{"text":415},{"id":417,"data":1873,"type":218},{"text":419},{"id":421,"data":1875,"type":42},{"text":423,"level":241},{"id":425,"data":1877,"type":218},{"text":427},{"id":429,"data":1879,"type":218},{"text":431},{"id":433,"data":1881,"type":42},{"text":435,"level":241},{"id":437,"data":1883,"type":218},{"text":439},{"id":441,"data":1885,"type":218},{"text":443},{"id":445,"data":1887,"type":42},{"text":447,"level":241},{"id":449,"data":1889,"type":218},{"text":451},{"id":453,"data":1891,"type":218},{"text":455},{"id":457,"data":1893,"type":42},{"text":459,"level":241},{"id":461,"data":1895,"type":218},{"text":463},{"id":465,"data":1897,"type":218},{"text":467},{"id":469,"data":1899,"type":42},{"text":471,"level":241},{"id":473,"data":1901,"type":218},{"text":475},{"id":477,"data":1903,"type":218},{"text":479},{"id":481,"data":1905,"type":42},{"text":483,"level":241},{"id":485,"data":1907,"type":218},{"text":487},{"id":489,"data":1909,"type":218},{"text":491},{"id":493,"data":1911,"type":42},{"text":495,"level":242},{"id":497,"data":1913,"type":218},{"text":499},{"id":501,"data":1915,"type":291},{"content":1916,"stretched":43,"withHeadings":14},[1917,1918,1919,1920,1921,1922,1923,1924,1925],[505,506],[508,509],[511,512],[514,515],[517,518],[520,521],[523,524],[526,527],[529,530],{"id":532,"data":1927,"type":42},{"text":534,"level":242},{"id":536,"data":1929,"type":218},{"text":538},{"id":540,"data":1931,"type":291},{"content":1932,"stretched":43,"withHeadings":14},[1933,1934,1935,1936,1937,1938,1939,1940],[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":1942,"type":42},{"text":586,"level":242},{"id":588,"data":1944,"type":218},{"text":590},{"id":592,"data":1946,"type":299},{"rows":1947,"title":631,"layout":291,"columns":1960},[1948,1950,1952,1954,1956,1958],{"id":596,"label":597,"values":1949},{"role":599,"focus":600},{"id":602,"label":603,"values":1951},{"role":605,"focus":606},{"id":608,"label":609,"values":1953},{"role":611,"focus":612},{"id":614,"label":615,"values":1955},{"role":617,"focus":618},{"id":620,"label":621,"values":1957},{"role":623,"focus":624},{"id":626,"label":627,"values":1959},{"role":629,"focus":630},[1961,1962],{"id":634,"label":635},{"id":637,"label":638},{"id":640,"data":1964,"type":218},{"text":642},{"id":644,"data":1966,"type":42},{"text":646,"level":242},{"id":648,"data":1968,"type":225},{"body":650,"title":651,"variant":652},{"id":654,"data":1970,"type":42},{"text":656,"level":241},{"id":658,"data":1972,"type":218},{"text":660},{"id":662,"data":1974,"type":218},{"text":664},{"id":666,"data":1976,"type":218},{"text":668},{"id":670,"data":1978,"type":42},{"text":672,"level":241},{"id":674,"data":1980,"type":218},{"text":676},{"id":678,"data":1982,"type":218},{"text":680},{"id":682,"data":1984,"type":218},{"text":684},{"id":686,"data":1986,"type":42},{"text":688,"level":242},{"id":690,"data":1988,"type":218},{"text":692},{"id":694,"data":1990,"type":218},{"text":696},{"id":698,"data":1992,"type":218},{"text":700},{"id":702,"data":1994,"type":42},{"text":704,"level":242},{"id":706,"data":1996,"type":291},{"content":1997,"stretched":43,"withHeadings":14},[1998,1999,2000,2001,2002,2003,2004,2005],[710,711],[713,714],[716,717],[719,720],[722,723],[725,726],[728,729],[731,732],{"id":734,"data":2007,"type":42},{"text":736,"level":242},{"id":738,"data":2009,"type":291},{"content":2010,"stretched":43,"withHeadings":14},[2011,2012,2013,2014,2015,2016,2017,2018,2019],[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":2021,"type":42},{"text":780,"level":242},{"id":782,"data":2023,"type":339},{"steps":2024,"title":809,"orientation":338},[2025,2026,2027,2028,2029,2030,2031,2032],{"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":2034,"type":42},{"text":813,"level":242},{"id":815,"data":2036,"type":218},{"text":817},{"id":819,"data":2038,"type":218},{"text":821},{"id":823,"data":2040,"type":218},{"text":825},{"id":827,"data":2042,"type":42},{"text":829,"level":242},{"id":831,"data":2044,"type":218},{"text":833},{"id":835,"data":2046,"type":218},{"text":837},{"id":839,"data":2048,"type":42},{"text":841,"level":242},{"id":843,"data":2050,"type":291},{"content":2051,"stretched":43,"withHeadings":14},[2052,2053,2054,2055,2056,2057,2058,2059,2060,2061,2062,2063,2064],[847,848],[786,850],[852,853],[268,855],[857,858],[860,861],[863,864],[866,867],[869,870],[872,873],[875,876],[286,878],[280,880],{"id":882,"data":2066,"type":42},{"text":884,"level":242},{"id":886,"data":2068,"type":218},{"text":888},{"id":890,"data":2070,"type":218},{"text":892},{"id":894,"data":2072,"type":894},{"items":2073,"title":929},[2074,2075,2076,2077,2078,2079,2080,2081],{"id":898,"answer":899,"question":900},{"id":902,"answer":903,"question":904},{"id":906,"answer":907,"question":908},{"id":910,"answer":911,"question":912},{"id":914,"answer":915,"question":916},{"id":918,"answer":919,"question":920},{"id":922,"answer":923,"question":924},{"id":926,"answer":927,"question":928},{"id":931,"data":2083,"type":931},{"title":933,"entries":2084},[2085,2086,2087,2088,2089,2090,2091,2092],{"term":936,"anchor":937,"definition":938},{"term":792,"anchor":940,"definition":941},{"term":943,"anchor":944,"definition":945},{"term":947,"anchor":948,"definition":949},{"term":951,"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":2094,"type":42},{"text":968,"level":242},{"id":970,"data":2096,"type":218},{"text":972},{"id":974,"data":2098,"type":982},{"link":976,"meta":2099},{"image":2100,"title":980,"description":981},{"url":979},{"id":984,"data":2102,"type":42},{"text":986,"level":242},{"id":988,"data":2104,"type":218},{"text":990},{"id":992,"data":2106,"type":982},{"link":994,"meta":2107},{"image":2108,"title":997,"description":998},{"url":979},{"id":1000,"data":2110,"type":982},{"link":1002,"meta":2111},{"image":2112,"title":1005,"description":1006},{"url":979},{"id":1008,"data":2114,"type":982},{"link":1010,"meta":2115},{"image":2116,"title":1013,"description":1014},{"url":979},{"id":1016,"data":2118,"type":982},{"link":1018,"meta":2119},{"image":2120,"title":1021,"description":1022},{"url":979},{"id":1024,"data":2122,"type":982},{"link":1026,"meta":2123},{"image":2124,"title":1029,"description":1030},{"url":979},{"id":1032,"data":2126,"type":982},{"link":1034,"meta":2127},{"image":2128,"title":1037,"description":1038},{"url":979},{"id":1040,"data":2130,"type":982},{"link":1042,"meta":2131},{"image":2132,"title":1045,"description":1046},{"url":979},{"id":1048,"data":2134,"type":982},{"link":1050,"meta":2135},{"image":2136,"title":1053,"description":1054},{"url":979},{"id":1056,"data":2138,"type":982},{"link":1058,"meta":2139},{"image":2140,"title":1061,"description":1062},{"url":979},{"id":1064,"data":2142,"type":982},{"link":1066,"meta":2143},{"image":2144,"title":1069,"description":1070},{"url":979},"Post erfolgreich abgerufen",{"items":2147,"source":2232,"manualIds":2233,"manualMatchedIds":2234},[2148,2155,2162,2169,2176,2183,2190,2197,2204,2211,2218,2225],{"id":2149,"slug":2150,"title":2151,"excerpt":2152,"featuredImage":2153,"publishedAt":2154},"381","enterprise-grade-multi-tenant-architecture-for-an-international-platform","Arquitectura Multi-Inquilino de Grado Empresarial para una Plataforma Internacional","Loving Rocks es una plataforma de bodas de nivel empresarial diseñada con una verdadera arquitectura multiinquilino, bases de datos aisladas por inquilino e internacionalización integrada para escalabilidad global, seguridad y estabilidad operativa a largo plazo.","\u002Fuploads\u002F2026\u002F01\u002Fenterprise-grade-multi-tenant-architecture-for-an-international-platform-1769789121298-b6v7ak.webp","2026-01-30T12:04:00.000Z",{"id":2156,"slug":2157,"title":2158,"excerpt":2159,"featuredImage":2160,"publishedAt":2161},"484","what-is-an-ai-platform-architect-models-data-runtime-security-and-operations","¿Qué es un arquitecto de plataforma de IA? Modelos, datos, entorno de ejecución, seguridad y operaciones","Un Arquitecto de Plataformas de IA diseña fundamentos de IA reutilizables a través de modelos, proveedores, recuperación, agentes, identidad, seguridad, evaluación, observabilidad y operaciones.","\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":2163,"slug":2164,"title":2165,"excerpt":2166,"featuredImage":2167,"publishedAt":2168},"480","when-should-an-ai-stop-trusting-its-own-knowledge-the-retrieval-trigger","¿Cuándo debería una IA dejar de confiar en su propio conocimiento? — El desencadenante de la recuperación","Un modelo de IA no necesita recuperación para cada pregunta. El problema importante es saber cuándo su conocimiento interno ya no es suficiente. El Disparador de Recuperación es un límite de decisión práctico que determina cuándo un sistema de IA debe dejar de depender únicamente del conocimiento del modelo y obtener evidencia externa antes de responder.","\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":2170,"slug":2171,"title":2172,"excerpt":2173,"featuredImage":2174,"publishedAt":2175},"470","what-should-an-ai-agent-remember-forget-recompute-or-retrieve-again","¿Qué debería recordar, olvidar, recalcular o volver a recuperar un agente de IA?","Los agentes de larga duración no deberían recordarlo todo. Este artículo proporciona un modelo práctico de ciclo de vida para decidir qué pertenece a la memoria duradera, qué se debería recuperar de nuevo, qué es más seguro recalcular y qué debería expirar o ser sustituido.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-should-an-ai-agent-remember-forget-recompute-or-retrieve-again-1790351131087-iehz28.webp","2026-09-25T09:43:00.000Z",{"id":2177,"slug":2178,"title":2179,"excerpt":2180,"featuredImage":2181,"publishedAt":2182},"487","vector-databases-embeddings-and-reranking-three-different-parts-of-retrieval","Bases de datos vectoriales, embeddings y reranking: tres partes diferentes de la recuperación","Las incrustaciones representan el significado, las bases de datos vectoriales recuperan candidatos y los rerankers refinan los resultados. Aprende en qué se diferencian y cómo trabajan juntas estas tres capas de recuperación en RAG.","\u002Fuploads\u002F2026\u002F10\u002Fvector-databases-embeddings-and-reranking-three-different-parts-of-retrieval-1791480129884-9dtasz.webp","2026-10-08T11:21:00.000Z",{"id":2184,"slug":2185,"title":2186,"excerpt":2187,"featuredImage":2188,"publishedAt":2189},"479","where-does-an-llm-get-its-data-rag-data-sources-in-python","¿De dónde obtiene sus datos un LLM? Fuentes de datos RAG en Python","Un LLM no conoce mágicamente tus archivos, bases de datos o APIs. Esta continuación práctica de la serie RAG muestra, con Python sencillo, cómo los datos externos se convierten en evidencia recuperable: desde archivos de texto y SQL hasta búsqueda de texto completo, embeddings, ensamblaje de contexto y la llamada final al LLM.","\u002Fuploads\u002F2026\u002F09\u002Fwhere-does-an-llm-get-its-data-rag-data-sources-in-python-1790517200521-nfsi5i.webp","2026-09-27T05:51:00.000Z",{"id":2191,"slug":2192,"title":2193,"excerpt":2194,"featuredImage":2195,"publishedAt":2196},"481","generative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing","IA generativa explicada: modelos, recuperación, herramientas y aplicaciones no son lo mismo","La IA generativa es más que un modelo. Aprende cómo los modelos, la recuperación, las herramientas, el contexto, los entornos de ejecución y las aplicaciones encajan en los sistemas de IA en producción.","\u002Fuploads\u002F2026\u002F10\u002Fgenerative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing-1791475411822-pp0dvz.webp","2026-10-08T12:00:00.000Z",{"id":2198,"slug":2199,"title":2200,"excerpt":2201,"featuredImage":2202,"publishedAt":2203},"489","agentic-ai-explained-when-an-ai-system-can-plan-use-tools-and-act","IA agéntica explicada: cuando un sistema de IA puede planificar, usar herramientas y actuar","La IA agéntica utiliza modelos dentro de bucles de ejecución de varios pasos, donde pueden elegir herramientas, observar resultados, actualizar el estado y adaptar su siguiente acción dentro de límites explícitos de tiempo de ejecución y permisos.","\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":2205,"slug":2206,"title":2207,"excerpt":2208,"featuredImage":2209,"publishedAt":2210},"471","how-to-know-whether-an-ai-agent-actually-used-the-right-evidence","Cómo saber si un agente de IA realmente utilizó la evidencia correcta","Un agente de IA puede citar fuentes y aun así usar la evidencia incorrecta. Este artículo presenta un método práctico para verificar el respaldo de las afirmaciones, la autoridad de la fuente, la aplicabilidad, la procedencia y si la evidencia realmente influyó en la respuesta.","\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":2212,"slug":2213,"title":2214,"excerpt":2215,"featuredImage":2216,"publishedAt":2217},"478","what-is-rag-the-simplest-explanation-of-how-it-works","¿Qué es RAG? La explicación más sencilla de cómo funciona","RAG suena complicado, pero la idea es simple: antes de que una IA responda, primero busca información útil de una fuente de conocimiento y le da esa información al modelo de lenguaje. Esta guía explica RAG, los LLM, el estado, la memoria y las herramientas usando un modelo mental simple.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works-1790377492124-khjagt.webp","2026-09-25T19:03:00.000Z",{"id":2219,"slug":2220,"title":2221,"excerpt":2222,"featuredImage":2223,"publishedAt":2224},"466","the-gpu-is-not-the-product-future-proof-private-ai-architecture","La GPU no es el producto: arquitectura de IA privada a prueba de futuro","La infraestructura de IA privada no debe diseñarse en torno a una sola GPU o un solo modelo. Un enfoque más resiliente combina GPUs de inferencia rápida, sistemas de IA ricos en memoria, nodos de IA física y modelos en la nube frontier opcionales detrás de una capa de enrutamiento consciente de las capacidades.","\u002Fuploads\u002F2026\u002F09\u002Fthe-gpu-is-not-the-product-future-proof-private-ai-architecture-1790140878812-8hsl39.webp","2026-09-23T01:19:00.000Z",{"id":2226,"slug":2227,"title":2228,"excerpt":2229,"featuredImage":2230,"publishedAt":2231},"467","the-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers","El límite de validez de la respuesta: la capa faltante entre la relevancia y las respuestas fiables de la IA","Una fuente puede ser relevante, autorizada y aun así ser incorrecta para la pregunta que se plantea. La capa que falta es la aplicabilidad: las condiciones bajo las cuales una respuesta es válida y los cambios que obligan a reconsiderarla. Este artículo presenta el Límite de Validez de la Respuesta como un patrón de diseño de fuentes para personas, sistemas de búsqueda con IA y sistemas 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",[],[]]