[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:zh":3,"public-menus:all":38,"post:ai-governance-models-data-permissions-risk-and-auditability:zh":205,"related:post:ai-governance-models-data-permissions-risk-and-auditability:zh:1":3757},{"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","zh","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":3756},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":1718,"featuredImage":1719,"featuredImageAlt":1720,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":1721,"publishedAt":1722,"createdAt":1723,"updatedAt":1724,"seoLocalePaths":1725,"categories":1734,"author":1735,"translations":1740},"491","AI治理：模型、数据、权限、风险与可审计性","ai-governance-models-data-permissions-risk-and-auditability","\u003Cp>AI 治理是一套由决策权、职责、控制措施和证据构成的体系，用于决定组织可以如何开发、获取、部署、运营、变更和退役 AI 系统。它比一份政策文件更广泛，但又比整体企业架构更狭窄。有效的 AI 治理将业务所有权、模型与供应商选择、数据权限、许可、风险分类、评估、监控、事件处理、可审计性和生命周期决策连接起来，使人们不仅能够回答“AI 是否有效？”，还能够回答“谁批准了它、在什么条件下批准、依据什么证据，以及该决策何时必须重新审视？”\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--info my-6 rounded-xl border p-5 border-blue-300 bg-blue-50 dark:border-blue-900 dark:bg-blue-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">直接回答\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>AI 治理将 AI 从一种非正式的技术能力转变为一种可问责的组织能力。\u003C\u002Fstrong>\u003Cbr>\u003Cbr>架构决定系统如何构建。工程负责实现它。风险管理评估不确定性和危害。合规处理适用的义务。治理则通过所有权、决策权、所需控制措施、证据和生命周期关卡将这些活动连接起来。\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">治理不是委员会，也不是一份 PDF\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">治理委员会可以是一种机制，政策也可以记录期望，但只有当决策能够改变系统被允许做什么时，治理才真正投入运行：可以使用哪些模型、哪些数据可以进入这些模型、智能体可以执行哪些工具、需要哪些评估、谁可以批准例外、必须记录什么，以及什么会触发暂停或退役。\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\">当前来源说明 — 2026 年 10 月 8 日\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">NIST AI RMF 1.0 仍是当前已发布的框架，同时 NIST 正在对其进行修订。其核心围绕 \u003Cstrong>GOVERN、MAP、MEASURE 和 MANAGE\u003C\u002Fstrong> 组织，其中 GOVERN 是贯穿各领域的职能。ISO\u002FIEC 42001:2023 仍是用于建立、运行和持续改进 AI 管理体系的国际 AI 管理体系标准。欧盟《人工智能法案》现已自 2026 年 8 月 2 日起普遍适用，但部分义务有更早的适用日期，部分高风险要求有更晚的过渡日期。在做出具体合规决策之前，始终应重新核查监管时间表。\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"目录\">\u003Cstrong class=\"editorjs-toc__title\">目录\u003C\u002Fstrong>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-0\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-6\" class=\"editorjs-toc__link\">AI 治理的真正含义\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">最简单的例子\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-15\" class=\"editorjs-toc__link\">简单例子止步之处\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-19\" class=\"editorjs-toc__link\">什么是AI治理——以及它不是什么\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-21\" class=\"editorjs-toc__link\">治理的范围比合规更广\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-25\" class=\"editorjs-toc__link\">NIST AI RMF和ISO\u002FIEC 42001解决不同的治理需求\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-28\" class=\"editorjs-toc__link\">当前EU AI Act的时间安排很重要\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-32\" class=\"editorjs-toc__link\">AI治理从清单开始\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-37\" class=\"editorjs-toc__link\">治理需要明确的责任归属\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-41\" class=\"editorjs-toc__link\">决策权应当明确\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-43\" class=\"editorjs-toc__link\">模型治理不仅仅是选择模型\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-47\" class=\"editorjs-toc__link\">提供商治理是一个独立的依赖层\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-51\" class=\"editorjs-toc__link\">数据治理仍然是事实来源层\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-55\" class=\"editorjs-toc__link\">权限是治理决策，并在运行时强制执行\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-59\" class=\"editorjs-toc__link\">风险分类应改变控制集\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-63\" class=\"editorjs-toc__link\">治理必须保留用例上下文\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-67\" class=\"editorjs-toc__link\">评估是治理证据\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-72\" class=\"editorjs-toc__link\">治理关口应贯穿整个生命周期\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-74\" class=\"editorjs-toc__link\">变更管理是AI治理的核心\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-78\" class=\"editorjs-toc__link\">例外需要负责人、到期时间和补偿性控制措施\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-82\" class=\"editorjs-toc__link\">可审计性是重建决策和执行的能力\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-87\" class=\"editorjs-toc__link\">监控闭合治理循环\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-91\" class=\"editorjs-toc__link\">AI事件需要明确的操作路径\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-95\" class=\"editorjs-toc__link\">采购是AI治理的一部分\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-99\" class=\"editorjs-toc__link\">人工监督应被设计，而不仅仅是声明\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-103\" class=\"editorjs-toc__link\">平台治理和用例治理是不同的\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-106\" class=\"editorjs-toc__link\">AI治理与企业AI架构\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-110\" class=\"editorjs-toc__link\">原始项目证据\u003C\u002Fa>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-1\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-111\" class=\"editorjs-toc__link\">Enterprise Aaasaasa 0.1：作为交付结构的治理\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-116\" class=\"editorjs-toc__link\">SenseFlow：需求和决策可追溯性\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-119\" class=\"editorjs-toc__link\">Aaasaasa AI Client：权限和运行时作为受治理的配置\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-124\" class=\"editorjs-toc__link\">常见 AI 治理失败模式\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-126\" class=\"editorjs-toc__link\">中央治理并不意味着集中每一个决策\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-130\" class=\"editorjs-toc__link\">治理治理系统本身\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-134\" class=\"editorjs-toc__link\">实用的AI治理实施顺序\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-136\" class=\"editorjs-toc__link\">AI治理检查清单\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-138\" class=\"editorjs-toc__link\">常见误解\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-140\" class=\"editorjs-toc__link\">边缘情况和局限性\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-146\" class=\"editorjs-toc__link\">什么会改变这个答案？\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-150\" class=\"editorjs-toc__link\">相关规范知识\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-157\" class=\"editorjs-toc__link\">常见问题\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-159\" class=\"editorjs-toc__link\">术语表\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-161\" class=\"editorjs-toc__link\">结论\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-165\" class=\"editorjs-toc__link\">主要来源和当前参考\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-6\">AI 治理的真正含义\u003C\u002Fh2>\n\u003Cp>AI 治理回答的是模型、SDK 或架构图本身无法回答的组织问题。谁拥有业务成果？谁可以批准新的供应商？哪些数据类别被禁止进行外部处理？部署前需要哪些证据？智能体可以获得哪些权限？谁可以接受剩余风险？当模型在升级后行为发生变化时会发生什么？\u003C\u002Fp>\n\u003Cp>其目的不是阻止变化。良好的治理使变化清晰可辨：决策有负责人、证据、条件、例外、复审日期以及回滚或升级路径。\u003C\u002Fp>\n\u003Cp>这就是为什么 NIST 将 GOVERN 置于整个 AI 风险管理生命周期之中，而不是将治理视为最后一个审批步骤。治理确立了文化、政策、问责制和组织结构，使映射、衡量和管理 AI 风险成为可能。\u003C\u002Fp>\n\u003Ch2 id=\"section-10\">最简单的例子\u003C\u002Fh2>\n\u003Cp>一个产品团队希望添加一个外部生成式 AI 供应商，用于总结内部客户支持工单。从技术上讲，集成可能只需要一次 API 调用。\u003C\u002Fp>\n\u003Cp>治理会提出另一组问题：工单内容是否被允许离开组织环境？批准了哪个供应商和模型版本？是否禁用了保留？哪些用户可以调用该功能？如何评估输出？是否需要人工审核？记录哪些内容？谁负责事件？如果供应商更改条款或模型行为会发生什么？\u003C\u002Fp>\n\u003Cp>治理结果可能仍然是“部署它”。区别在于，部署现在是一个具有明确条件、可追踪的决策，而不是一项未被记录的工程选择。\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">一个基本的受治理 AI 决策\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. 登记用例\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">记录目的、负责人、用户、数据、模型\u002F供应商以及预期成果。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. 对风险和义务进行分类\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">确定业务后果、数据敏感性、自主性、监管暴露和滥用可能性。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. 定义所需控制措施\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">明确权限、数据处理、评估、人工监督、安全、日志记录和供应商约束。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. 收集证据\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">运行测试、安全\u002F隐私审查、架构审查以及相关法律\u002F合规检查。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. 做出决策\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">批准、有条件批准、要求修改、暂缓或拒绝。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. 在受控配置下部署\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">固定已批准的模型\u002F供应商\u002F运行时，并强制执行所需边界。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">7. 监控并重新评估\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">跟踪事件、质量、漂移、供应商变更、新风险和法规变化。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">8. 变更、暂停或退役\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">使用证据和所有权规则来决定下一个生命周期状态。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-15\">简单例子止步之处\u003C\u002Fh2>\n\u003Cp>大型组织很少孤立地治理一个 AI 系统。同一个模型可能支持数十个产品；同一个供应商可能处理多个数据类别；一个智能体平台可能向许多团队暴露共享工具。\u003C\u002Fp>\n\u003Cp>因此，治理既需要系统级控制，也需要组合级结构：AI 清单、已批准供应商、模型目录、共享评估基线、安全模式、风险阈值、例外登记册和所有权映射。\u003C\u002Fp>\n\u003Cp>治理也不可能对每一种 AI 用途都完全相同。公共内容摘要器、内部编码助手、招聘支持系统以及能够发起支付的智能体，在后果和控制配置上存在实质性差异。\u003C\u002Fp>\n\u003Ch2 id=\"section-19\">什么是AI治理——以及它不是什么\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">AI治理与相邻学科的对比\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">AI治理\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">相邻学科\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\">企业\u002F解决方案架构\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">AI风险管理\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">合规\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">安全\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">MLOps \u002F LLMOps\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">AI伦理原则\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-21\">治理的范围比合规更广\u003C\u002Fh2>\n\u003Cp>合规是治理的一项输入，而非整个治理体系。一个AI用例可以合法被允许，但仍可能违反公司风险偏好、安全政策、合同义务或产品质量要求。\u003C\u002Fp>\n\u003Cp>反过来也同样重要：内部批准不能凌驾于法律之上。治理应使适用的法律义务在用于架构、安全和业务风险的同一决策路径中可见。\u003C\u002Fp>\n\u003Cp>ISO\u002FIEC 42001明确将AI管理体系界定为一种结构化方式，用于建立负责任AI的政策、目标和流程。ISO还指出，该标准不替代法律或法规；它提供了一个可支持合规的管理框架。\u003C\u002Fp>\n\u003Ch2 id=\"section-25\">NIST AI RMF和ISO\u002FIEC 42001解决不同的治理需求\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\">框架\u002F标准\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">主要作用\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">有用的治理价值\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">NIST AI RMF 1.0\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">自愿性AI风险管理框架\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">围绕GOVERN、MAP、MEASURE和MANAGE在整个生命周期内组织成果\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">NIST AI 600-1\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">AI RMF的生成式AI配置文件\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">增加针对GenAI的风险考量和行动\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">ISO\u002FIEC 42001:2023\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">AI管理体系要求\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">创建组织范围的管理体系，包括政策、角色、流程和持续改进\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">ISO\u002FIEC 23894:2023\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">AI风险管理指南\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">指导将AI特定风险管理整合到组织活动中\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">EU AI Act\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">欧盟具有约束力的法规\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">根据行为者、AI类别和用例创建法律义务\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>这些来源不应被合并为一份检查清单。NIST AI RMF是风险管理指南。ISO\u002FIEC 42001是管理体系标准。EU AI Act是法律。组织可以将它们一起使用，但它们的权威性、范围和实施目的各不相同。\u003C\u002Fp>\n\u003Ch2 id=\"section-28\">当前EU AI Act的时间安排很重要\u003C\u002Fh2>\n\u003Cp>截至2026年10月8日，欧盟委员会表示AI Act于2026年8月2日普遍适用。禁止性做法和AI素养条款自2025年2月2日起适用，而通用AI模型的治理规则和义务自2025年8月2日起适用。\u003C\u002Fp>\n\u003Cp>委员会当前的指南还反映了某些高风险要求的较晚适用日期。确切的日期和过渡规则是不断变化的合规输入，在做出部署决定前应依据委员会当前材料进行核实。\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">架构文章，非法律建议\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">此处的监管示例解释了为什么治理需要版本化的法律\u002F合规输入。它们并不决定某个特定产品在法律上是否被归类为禁止、高风险、GPAI、部署者、提供者或其他受监管行为者。\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-32\">AI治理从清单开始\u003C\u002Fh2>\n\u003Cp>组织无法治理其无法识别的AI系统。清单应涵盖的不仅仅是自定义训练的模型。它可能包括外部模型API、嵌入式copilot、本地模型、支持AI的SaaS功能、代理运行时、检索系统和自动化决策组件。\u003C\u002Fp>\n\u003Cp>有用的清单将AI能力与其业务负责人、技术负责人、用例、用户、数据类别、模型\u002F提供者、部署环境、权限、风险分类、评估状态、适用义务和生命周期状态联系起来。\u003C\u002Fp>\n\u003Cp>清单不仅仅是给审计人员看的电子表格。它是索引，让组织知道当提供者变更、漏洞出现、法规变得适用或模型退役时必须审查什么。\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">清单字段\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">治理为何需要它\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">用例\u002F目的\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">定义AI存在的原因以及成功的含义\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">业务负责人\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">拥有成果和业务风险\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">技术负责人\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">拥有架构、实施和运营\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">模型+版本\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">识别产生行为的依赖项\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">提供者\u002F运行时\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">识别合同、托管和运营依赖项\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">数据类别\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">确定隐私、机密性和真相来源约束\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">用户\u002F受影响方\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">确定暴露和人类影响背景\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">工具\u002F操作\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">确定自主性和副作用风险\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">权限\u002F身份\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">定义谁或什么可以调用该能力\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">风险分类\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">确定所需控制和审批路径\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">评估证据\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">显示预期行为是否经过测试\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">生命周期状态\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">草稿、审查、批准、限制、暂停或退役\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">审查日期\u002F触发条件\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">定义何时必须重新审视治理决定\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-37\">治理需要明确的责任归属\u003C\u002Fh2>\n\u003Cp>AI 故障往往跨越组织边界。模型质量问题可能演变为产品故障、安全问题、隐私事件或合同违约。治理需要在事件发生之前就明确责任人。\u003C\u002Fp>\n\u003Cp>责任归属并不意味着一个人对所有事情负责。一个健全的模型会分离决策权：业务负责人、产品负责人、技术负责人、数据负责人、安全\u002F隐私专家、法律\u002F合规角色和运营支持。\u003C\u002Fp>\n\u003Cp>关键特性是每项必需的决策都有负责人，并且每位负责人都知道他们需要审查哪些证据。\u003C\u002Fp>\n\u003Ch2 id=\"section-41\">决策权应当明确\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">决策\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">典型责任职能\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">此 AI 用例是否可以存在？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">业务\u002F产品负责人，结合治理\u002F风险意见\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">此数据类别是否可以处理？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">数据负责人 + 根据政策的隐私\u002F安全\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">此提供商\u002F模型是否可以使用？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">架构\u002F平台 + 安全\u002F采购 + 治理\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">此代理是否可以执行此操作？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">应用负责人 + 授权\u002F业务政策负责人\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">质量是否足以部署？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">产品\u002F技术负责人对照既定验收标准\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">剩余风险是否可以接受？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">适当权限级别的指定风险负责人\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">是否可以授予例外？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">明确的例外授权，有时间限制并记录在案\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">系统是否应暂停？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">在事件或风险触发下的运营\u002F业务负责人\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">模型升级是否可以上线？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">在回归\u002F评估证据之后的变更负责人\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-43\">模型治理不仅仅是选择模型\u003C\u002Fh2>\n\u003Cp>模型治理跟踪使用哪个模型、用于什么目的、在何种配置和证据下。这适用于外部 API、本地托管模型、微调模型以及嵌入第三方软件中的模型。\u003C\u002Fp>\n\u003Cp>模型决策应考虑能力、评估结果、成本、延迟、数据处理、提供商条款、生命周期支持、地理\u002F托管限制、安全性、回退行为以及版本变更的后果。\u003C\u002Fp>\n\u003Cp>诸如“latest”之类的模型别名在操作上可能很方便，但如果行为在没有受治理的发布流程下发生变化，则会削弱可复现性。有重大后果的系统受益于明确的版本跟踪和回归评估。\u003C\u002Fp>\n\u003Ch2 id=\"section-47\">提供商治理是一个独立的依赖层\u003C\u002Fh2>\n\u003Cp>使用同一模型系列的两个系统可能具有不同的治理风险，如果一个在本地运行，另一个将数据发送给外部提供商。提供商治理涵盖合同条款、处理位置、保留、日志记录、子处理者、可用性、弃用和退出策略。\u003C\u002Fp>\n\u003Cp>提供商抽象可以减少技术锁定，但并不能消除治理工作。更换提供商可能会改变数据流、模型行为、安全假设、成本和合规义务。\u003C\u002Fp>\n\u003Cp>因此，已批准的提供商列表不应被解释为“来自此提供商的每个模型和每个数据类别都自动获得批准”。批准需要范围。\u003C\u002Fp>\n\u003Ch2 id=\"section-51\">数据治理仍然是事实来源层\u003C\u002Fh2>\n\u003Cp>AI 治理并不会使模型成为组织事实的权威。数据治理仍然决定源数据的所有权、分类、保留、质量和允许使用。\u003C\u002Fp>\n\u003Cp>对于 RAG 和代理，治理应确定哪些来源是权威的、哪些是建议性的、如何保留来源、哪些数据可以进入模型上下文以及必须强制执行哪些租户\u002F用户边界。\u003C\u002Fp>\n\u003Cp>生成的输出也会产生新的数据治理问题：提示和响应是否保留、谁可以访问跟踪、生成的摘要是否成为记录，以及当源数据被删除时如何删除派生的嵌入或索引。\u003C\u002Fp>\n\u003Ch2 id=\"section-55\">权限是治理决策，并在运行时强制执行\u003C\u002Fh2>\n\u003Cp>代理式人工智能使权限成为一等治理对象。组织需要决定每个代理或用户可以访问哪些工具、文件、API、数据库和副作用。\u003C\u002Fp>\n\u003Cp>治理定义策略和审批逻辑；可信运行时执行它。诸如“不要删除文件”之类的自然语言指令不能替代文件系统、API 或服务授权。\u003C\u002Fp>\n\u003Cp>同样的原则适用于租户隔离：角色可以授权某项操作，而租户范围限制该操作可以触及哪个客户的资源。\u003C\u002Fp>\n\u003Ch2 id=\"section-59\">风险分类应改变控制集\u003C\u002Fh2>\n\u003Cp>并非每个 AI 系统都需要相同的审查深度。当风险分类改变证据、审批和监控要求时，治理就变得可扩展。\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">风险驱动因素\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">较低控制示例\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">较高控制示例\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">业务后果\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">起草内部文本\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">批准财务结算\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">人类影响\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">可选的写作辅助\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">就业或资格决策支持\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">数据敏感性\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">公开文档\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">健康、人力资源、财务或机密数据\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">自主性\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">只读建议\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">具有写入\u002F支付\u002F部署工具的代理\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">可逆性\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">易于重新生成的摘要\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">不可逆的外部交易\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">暴露程度\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">小型内部试点\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">面向公众\u002F客户的大规模系统\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">来源权威性\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">咨询性内容\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">依赖受监管或合同事实的系统\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">故障可检测性\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">明显的格式缺陷\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">看似合理但实质错误的建议\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>分类方法可以简单或复杂，但应映射到具体后果：更多测试、更窄的权限、所需的人工监督、安全审查、高管风险接受或部署禁止。\u003C\u002Fp>\n\u003Ch2 id=\"section-63\">治理必须保留用例上下文\u003C\u002Fh2>\n\u003Cp>NIST 的 MAP 功能强调预期目的、用户、部署上下文、假设、影响以及适用的法律或规范。这很重要，因为同一个模型在一个用例中可能是低风险，而在另一个用例中可能产生高后果。\u003C\u002Fp>\n\u003Cp>因此，治理记录应对应用进行分类，而不仅仅是模型。“我们使用模型 X”不足以确定风险。\u003C\u002Fp>\n\u003Cp>相关的治理对象是系统\u002F用例：模型 + 数据 + 上下文 + 工具 + 用户 + 部署环境 + 业务流程。\u003C\u002Fp>\n\u003Ch2 id=\"section-67\">评估是治理证据\u003C\u002Fh2>\n\u003Cp>AI 治理流程不应仅基于供应商基准或成功的演示来批准部署。系统需要与其实际预期用途相关的证据。\u003C\u002Fp>\n\u003Cp>有用的证据可以包括任务成功评估、检索质量、事实依据、安全测试、权限测试、对抗性场景、人工审查研究、延迟\u002F成本、鲁棒性和回归比较。\u003C\u002Fp>\n\u003Cp>NIST 的 MEASURE 功能明确说明了这一点：组织应识别并应用适当的方法和指标来应对映射期间识别的风险，同时记录无法或不会测量的风险。\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--success my-6 rounded-xl border p-5 border-emerald-300 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">治理关口应要求证据，而非信心\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">“团队认为模型足够好”是一个薄弱的审批产物。“系统在代表性测试中达到了定义的验收标准，并具有这些已知限制和剩余风险”是可治理的。\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-72\">治理关口应贯穿整个生命周期\u003C\u002Fh2>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">示例生命周期关卡\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">创意\u002F发现关卡\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">确认业务目的、负责人以及AI是否为合适的解决方案。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">架构关卡\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">审查模型\u002F提供商、数据流、身份、权限、隔离和运营设计。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">风险\u002F合规关卡\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">对风险进行分类并确定适用义务；定义所需控制措施。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">验证关卡\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">要求提供功能、安全、安保和质量标准均已满足的证据。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">部署关卡\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">批准具体配置、版本、环境和运营负责人。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">变更关卡\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">根据重要性重新评估模型\u002F提供商\u002F工具\u002F数据变更。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">事件关卡\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">当定义的风险触发条件出现时，暂停、限制或回滚。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">退役关卡\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">干净地移除访问权限、数据衍生品、凭据和过时依赖项。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-74\">变更管理是AI治理的核心\u003C\u002Fh2>\n\u003Cp>即使应用程序代码没有变化，AI系统也会发生变化。提供商会更新模型、安全过滤器、上下文限制、定价、政策和基础设施。检索语料库会变化。代理工具会获得权限。法规和合同也在演变。\u003C\u002Fp>\n\u003Cp>因此，治理应定义重大变更触发条件。轻微的提示词措辞调整可能只需要常规回归测试；更换模型、启用写入工具或引入敏感数据可能需要新的审批关卡。\u003C\u002Fp>\n\u003Cp>治理记录应保留哪个版本获得了批准，以及哪些条件使该批准有效。\u003C\u002Fp>\n\u003Ch2 id=\"section-78\">例外需要负责人、到期时间和补偿性控制措施\u003C\u002Fh2>\n\u003Cp>现实组织需要例外。团队可能需要使用未经批准的模型进行有时间限制的实验，或者遗留系统可能尚未满足新的日志记录要求。\u003C\u002Fp>\n\u003Cp>危险的模式是永久性的未记录例外。可治理的例外应明确负责人、理由、范围、剩余风险、补偿性控制措施、到期日期和审查条件。\u003C\u002Fp>\n\u003Cp>例外处理应成为正常治理系统的一部分，而不是非正式的旁路渠道。\u003C\u002Fp>\n\u003Ch2 id=\"section-82\">可审计性是重建决策和执行的能力\u003C\u002Fh2>\n\u003Cp>AI可审计性不仅仅是存储模型提示词。它意味着能够重建使用了哪个系统版本、应用了哪些数据和权限、谁批准了配置、哪些评估支持了部署，以及相关执行期间发生了什么。\u003C\u002Fp>\n\u003Cp>对于代理，这可能要求主体身份、工具调用、审批、目标资源、状态变更和结果。对于RAG，这可能要求语料库\u002F索引版本、检索查询、选定的证据和来源。对于模型变更，这可能要求之前和新的评估结果。\u003C\u002Fp>\n\u003Cp>审计证据应适度。记录每一个可能的令牌本身可能会带来隐私和安全风险。治理应定义哪些证据是必要的、保留多长时间以及谁可以访问。\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">审计对象\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">有用证据\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">治理决策\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">负责人、日期、决策、条件、证据、例外\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">模型发布\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">模型\u002F提供商\u002F版本、配置、回归结果\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">数据访问\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">主体、租户\u002F范围、来源类别、策略决策\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">代理操作\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">工具、参数\u002F目标、审批、结果、状态变更\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">RAG答案\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">语料库\u002F索引版本、检索集、选定证据、引用\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">事件\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">触发条件、受影响系统、遏制措施、决策负责人、补救措施\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">退役\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">已禁用端点、已撤销凭据、已删除衍生数据、归档决策\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-87\">监控闭合治理循环\u003C\u002Fh2>\n\u003Cp>批准是一个快照。生产监控告诉治理层批准背后的假设是否仍然成立。\u003C\u002Fp>\n\u003Cp>有用的信号取决于用例：质量回归、不安全输出、工具故障、策略拒绝、异常成本、延迟、用户投诉、漂移、检索新鲜度、提供商事件、安全警报或新的监管分类。\u003C\u002Fp>\n\u003Cp>治理应定义触发行动的阈值：调查、限制、要求人工审查、回滚、切换提供商、暂停或退役。\u003C\u002Fp>\n\u003Ch2 id=\"section-91\">AI事件需要明确的操作路径\u003C\u002Fh2>\n\u003Cp>AI特定事件可能涉及有害内容、数据泄露、未授权操作、持续的事实性失败、模型\u002F提供商中断、提示注入、跨租户检索或模型更新后的意外行为。\u003C\u002Fp>\n\u003Cp>事件流程应将技术响应与治理责任联系起来。必须有人被授权禁用模型、移除工具、撤销凭证、限制用户、通知受影响的职能部门，并决定系统是否可以恢复服务。\u003C\u002Fp>\n\u003Cp>事件中的经验教训应更新政策、测试、风险分类和可复用的平台控制措施，而不是仅停留在某个团队内部。\u003C\u002Fp>\n\u003Ch2 id=\"section-95\">采购是AI治理的一部分\u003C\u002Fh2>\n\u003Cp>组织可以通过普通的SaaS采购获得大量AI能力。因此，治理应覆盖购买的AI功能以及内部工程化系统。\u003C\u002Fp>\n\u003Cp>供应商审查可以包括数据使用、保留、模型训练政策、子处理者、安全性、事件通知、导出\u002F删除、地理处理、版本变更、服务连续性和合同退出。\u003C\u002Fp>\n\u003Cp>技术架构审查和采购审查应共享同一系统清单，以免商业批准偏离实际部署的数据流。\u003C\u002Fp>\n\u003Ch2 id=\"section-99\">人工监督应被设计，而不仅仅是声明\u003C\u002Fh2>\n\u003Cp>“人在回路中”只有在人拥有权限、时间、信息和可用的干预机制时才有意义。\u003C\u002Fp>\n\u003Cp>如果审查者只看到AI建议，而看不到其证据、不确定性或来源状态，可能只是对输出进行橡皮图章式批准。治理应明确审查者可以检查什么，以及有哪些可用操作：批准、拒绝、编辑、升级或停止。\u003C\u002Fp>\n\u003Cp>人工监督还应基于风险。低后果系统可以使用抽样或事后审查，而高后果副作用可能需要在执行前获得批准。\u003C\u002Fp>\n\u003Ch2 id=\"section-103\">平台治理和用例治理是不同的\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">两个治理层级\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">共享AI平台\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">单个AI用例\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">主要关注点\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">典型批准\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">证据\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">治理失败\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Cp>因此，平台批准应减少重复工作，而不是消除用例责任。“模型已获批准”不同于“该模型在此处的应用已获批准”。\u003C\u002Fp>\n\u003Ch2 id=\"section-106\">AI治理与企业AI架构\u003C\u002Fh2>\n\u003Cp>企业AI架构描述了AI系统、平台、数据、身份、提供商、运营和组织系统如何协同工作。AI治理描述了决定这些架构可以如何创建和变更的决策与控制系统。\u003C\u002Fp>\n\u003Cp>两者紧密耦合。没有架构的治理可能变成抽象政策。没有治理的架构可能产生技术上优雅但所有权不明确、提供商采用不受控制或风险未经审查的系统。\u003C\u002Fp>\n\u003Cp>最强的设计是双向的：治理要求成为架构控制，而架构则揭示治理必须拥有的真实决策。\u003C\u002Fp>\n\u003Ch2 id=\"section-110\">原始项目证据\u003C\u002Fh2>\n\u003Ch3 id=\"section-111\">Enterprise Aaasaasa 0.1：作为交付结构的治理\u003C\u002Fh3>\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\">项目 \u002F PoC 证据\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Enterprise Aaasaasa 0.1 是项目和培训\u002FPoC 证据，而非商业企业采用的证据。它在这里很有用，因为其交付结构明确连接了架构、里程碑、风险、利益相关者、验证和项目决策。\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cp>Enterprise Aaasaasa 0.1 为需求、架构、原型、验证和项目收尾使用了定义的里程碑。该结构说明了一个核心治理原则：生命周期转换应具有明确的输出和决策点，而不是非正式的“先构建，后审查”流程。\u003C\u002Fp>\n\u003Cp>该项目还跟踪范围蔓延、架构延迟和 AI\u002FGDPR 问题等风险，并识别利益相关者群体，包括赞助、指导、架构、安全、营销、外部 API 和托管。\u003C\u002Fp>\n\u003Cp>这不构成 ISO\u002FIEC 42001 管理体系。它是更狭义的项目证据，展示了所有权、风险、里程碑和验证如何整合到技术交付中。\u003C\u002Fp>\n\u003Ch3 id=\"section-116\">SenseFlow：需求和决策可追溯性\u003C\u002Fh3>\n\u003Cp>SenseFlow 使用从产品目标和用户需求，经过史诗、用户故事、验收标准、架构、实现和验证的结构化路径。决策记录保留决策、理由、替代方案、权衡、状态和日期\u002F版本。\u003C\u002Fp>\n\u003Cp>这种可追溯性模式与治理直接相关，因为 AI 控制应连接到证明其合理性的需求或风险。当从业务需求到架构决策再到验证证据的链条可以被重建时，治理体系会变得更强大。\u003C\u002Fp>\n\u003Ch3 id=\"section-119\">Aaasaasa AI Client：权限和运行时作为受治理的配置\u003C\u002Fh3>\n\u003Cp>Aaasaasa AI Client 将提供商、模型、运行时位置和权限分开，而不是将它们视为一个“AI 设置”。中央工作区权限配置文件管理工具访问，Direct Chat 没有文件系统\u002Fshell 工具，具备代理能力的运行时在明确的权限配置文件下运行。\u003C\u002Fp>\n\u003Cp>这种分离展示了一个重要的治理模式：模型选择和行动权限应是独立的配置对象。更强的模型不会自动获得更广泛的文件系统、shell 或业务权限。\u003C\u002Fp>\n\u003Cp>实现证据是架构性的，并非声称该应用程序构成经认证的组织 AI 治理体系。\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">观察到的项目模式\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">治理经验\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">里程碑关卡\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">生命周期转换可能需要明确证据\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">风险登记册\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">已知不确定性成为受管理对象，而非非正式关切\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">利益相关者映射\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">决策责任可以被有意识地分配\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">验收标准 + 验证\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">部署决策可以依赖证据\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">决策记录\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">架构权衡保持可追溯\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">分离模型\u002F提供商\u002F运行时\u002F权限\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">能力和权限可以独立治理\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">明确的项目成熟度标签\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">PoC 证据不会被误报为生产或市场证明\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-124\">常见 AI 治理失败模式\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">失败模式\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">出了什么问题\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">治理只是政策 PDF\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">团队无法将政策转化为运行时控制或部署决策\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">没有 AI 清单\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">组织无法识别模型、代理或嵌入式 AI 的使用位置\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">模型批准被当作用例批准\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">已批准的模型被用于风险背景实质性不同的场景\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">没有指定的业务负责人\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">技术团队默认继承业务风险决策\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">风险分类没有控制后果\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">每个系统无论后果如何都接受相同的审查\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">权限仅存在于提示中\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">模型指令成为真实授权的替代品\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">提供商变更不可见\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">行为\u002F数据\u002F合规假设在未重新评估的情况下发生变化\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">演示成功即批准证据\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">生产风险从小型顺利路径测试中推断\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">人工监督流于形式\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">审查者无法检查证据或停止操作\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">例外没有到期时间\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">临时变通方案成为永久治理债务\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">日志存在但无法重建决策\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">可审计性与原始数据保留相混淆\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">合规部门独自拥有治理\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">产品、工程、安全和运营脱离问责\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">每个决策都提交中央委员会\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">治理成为瓶颈，而非可扩展的控制系统\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-126\">中央治理并不意味着集中每一个决策\u003C\u002Fh2>\n\u003Cp>成熟的组织可以集中管理策略、控制模式和升级机制，同时将低风险决策委托给产品或平台团队。\u003C\u002Fp>\n\u003Cp>这种联邦式模型比要求中央委员会批准每一次提示变更更具扩展性。中央职能定义风险层级、强制性控制、提供商政策、例外授权和审计要求；团队在这些边界内自主运作。\u003C\u002Fp>\n\u003Cp>设计目标是实现一致的问责制，而非最大程度的集中化。\u003C\u002Fp>\n\u003Ch2 id=\"section-130\">治理治理系统本身\u003C\u002Fh2>\n\u003Cp>治理需要反馈。否则控制措施可能变成昂贵且无法降低风险的仪式。\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">指标\u002F信号\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">可揭示的内容\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">清单覆盖率\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">AI采用是否对治理可见\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">决策时间\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">治理是否不必要地阻碍交付\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">例外数量与时长\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">政策是否切合实际或经常被绕过\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">评估失败率\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">部署前控制是否能发现缺陷\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">部署后事故率\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">审批证据是否能预测生产行为\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">未授权工具拒绝率\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">权限边界是否被积极执行\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">模型\u002F提供商变更频率\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">已批准的假设多久可能过时\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">已退役但仍活跃的系统\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">生命周期清理\u002F控制失败\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">重复事故模式\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">经验教训是否正在转化为可复用的平台控制\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>治理指标不应奖励文书工作量。有用的衡量标准是决策质量、可追溯性、风险检测和安全交付是否得到改善。\u003C\u002Fp>\n\u003Ch2 id=\"section-134\">实用的AI治理实施顺序\u003C\u002Fh2>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">从可见性到控制构建治理\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. 定义治理范围\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">确定哪些内部构建、采购、嵌入和实验性AI系统被覆盖。\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. 创建AI清单\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">记录所有者、用例、模型\u002F提供商、数据、工具、用户、生命周期状态和风险类别。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. 定义决策权\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">明确谁可以批准提供商、数据使用、风险接受、例外、部署和退役。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. 建立风险层级\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">将后果和暴露映射到不同的控制要求。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. 定义可复用的最低控制\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">为身份、权限、数据、安全、评估、日志记录和人工监督设定基线要求。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. 将治理与架构连接\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">将策略转化为平台\u002F运行时控制，使团队无法意外绕过。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">7. 构建基于证据的关卡\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">在生命周期转换前要求相关的评估、安全、隐私、架构和合规证据。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">8. 治理模型\u002F提供商变更\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">通过回归证据跟踪版本、弃用和重大变更。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">9\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">9. 添加监控和事故触发条件\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">定义哪些生产信号强制进行调查、限制或暂停。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">10\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">10. 形式化例外\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">要求范围、所有者、剩余风险、补偿控制和到期时间。\u003C\u002Fdiv>\u003C\u002Fdiv>\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\">11\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">11. 审计决策与执行\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">保留将所有者、配置、权限、评估和重大操作关联起来的适当证据。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">12\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">12. 改进治理系统\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">利用事故、延迟和重复例外来修订控制和平台模式。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-136\">AI治理检查清单\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">问题\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">预期的治理证据\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">为什么存在这个AI系统？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">目的、业务所有者和预期成果\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">谁负责技术运营？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">指定的技术\u002F平台所有者\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">使用哪个模型\u002F提供商\u002F版本？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">已注册且带版本的依赖项\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">哪些数据可以进入系统？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">分类、权限和允许使用的决策\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">哪些身份可以使用它？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">身份验证和授权模型\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">它可以执行哪些操作？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">工具\u002F权限矩阵和自主边界\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">风险层级是什么？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">带理由的文档化分类\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">哪些控制是强制性的？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">风险层级控制基线\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">如何评估的？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">代表性测试和验收标准\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">谁接受了剩余风险？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">指定的问责机构\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">什么需要人工审查？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">明确的监督\u002F批准规则\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">记录哪些内容？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">与后果成比例的审计\u002F可观测性策略\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">什么触发重新审查？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">模型\u002F提供商\u002F数据\u002F工具\u002F法规\u002F重大变更事件\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">如何暂停？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">操作终止\u002F限制路径和所有者\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">如何退役？\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">凭证、数据、衍生品、端点和记录清理\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-138\">常见误解\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">误解\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">纠正\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“AI治理就是合规。”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">合规是治理的一个输入；治理还涵盖所有权、架构、权限、质量、风险和生命周期决策。\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“治理意味着审查委员会。”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">委员会可以批准例外或高风险系统，但许多控制应嵌入正常交付和平台架构中。\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“已批准的模型对每种用途都安全。”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">风险属于用例和系统上下文，而不仅仅是模型。\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“供应商为我们处理治理。”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">提供商控制部分技术栈；组织仍然拥有其用例、数据、权限和业务后果。\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“人在回路中自动解决风险。”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">只有当审查者拥有权限、上下文和干预能力时，监督才有效。\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“记录一切就能实现可审计性。”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">可审计性需要可重建的相关证据，并具有受控的保留和访问。\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“治理阻碍创新。”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">糟糕的治理会阻碍交付；设计良好的治理创造可复用的安全路径和更清晰的决策所有权。\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“低风险试点不需要治理。”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">它们可以使用轻量级治理，但清单、所有权和数据\u002F工具边界仍然重要。\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“本地AI需要更少的治理。”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">本地托管可以改变隐私\u002F提供商风险，但模型质量、权限、安全和生命周期治理仍然存在。\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“一旦批准，系统就保持批准状态。”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">模型、提供商、数据、法规和用途都可能变化；治理决策需要审查触发条件。\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-140\">边缘情况和局限性\u003C\u002Fh2>\n\u003Cp>非常小的组织可能不需要专门的AI治理职能。相同的原则可以通过轻量级架构决策、风险登记册、所有者映射和发布关卡来实施。\u003C\u002Fp>\n\u003Cp>高度受监管的组织可能需要比这篇架构级文章所描述的更为正式的治理、独立保证、文档化合规流程和法律解释。\u003C\u002Fp>\n\u003Cp>开源和自托管模型减少了一些提供商依赖，但产生了其他依赖：补丁、模型来源、评估、基础设施安全、许可和运营所有权。\u003C\u002Fp>\n\u003Cp>通用AI模型可以在许多上下文中使用。治理应避免假设提供商级别的模型控制完全决定下游应用风险。\u003C\u002Fp>\n\u003Cp>没有任何治理框架能保证AI系统是安全或正确的。治理提升问责性和决策质量；技术验证、监控和人类判断仍然必不可少。\u003C\u002Fp>\n\u003Ch2 id=\"section-146\">什么会改变这个答案？\u003C\u002Fh2>\n\u003Cp>具体的控制措施集合会随法律、行业、组织规模、数据敏感性、自主性、部署模式和业务后果而变化。\u003C\u002Fp>\n\u003Cp>NIST目前正在修订AI RMF 1.0，因此未来的NIST术语或推荐实践可能会发生变化。ISO标准也可能被修订，而欧盟AI法案的指南和过渡细节也在持续演变。\u003C\u002Fp>\n\u003Cp>稳定的架构原则是：AI决策需要明确的负责人、证据、权限、风险处理和生命周期审查，而不是隐藏在模型或应用程序配置中。\u003C\u002Fp>\n\u003Ch2 id=\"section-150\">相关规范知识\u003C\u002Fh2>\n\u003Cp>AI治理依赖于本知识图谱中已在其他地方分离的概念：真相来源决定权威性，RBAC和租户隔离约束访问，上下文工程控制模型可见信息，而智能体架构定义工具和行动如何进入执行循环。\u003C\u002Fp>\n\u003Cp>企业AI架构是父级组织架构概念。治理是运营控制层，决定这些企业AI组件如何被引入、变更和退役。\u003C\u002Fp>\n\u003Cp>智能体系统增加了治理要求，因为模型决策可能产生真实的副作用。因此，权限、审批和审计控制必须存在于模型本身之外。\u003C\u002Fp>\n\u003Caside class=\"editorjs-referral my-6\">\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fzh\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough\" class=\"flex flex-col sm:flex-row gap-4 rounded-xl border border-gray-200 dark:border-gray-700 p-4 transition hover:border-primary-500\">\u003Cdiv class=\"min-w-0 flex-1\">\u003Cstrong class=\"block text-lg text-gray-900 dark:text-gray-100\">AI智能体可靠性：为什么仅有最终答案是不够的\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">智能体治理需要关于执行轨迹、工具使用、状态变化和可恢复性的证据——而不仅仅是最终输出质量。\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">阅读智能体可靠性文章 →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Caside class=\"editorjs-referral my-6\">\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fzh\u002Fblog\u002Fai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context\" class=\"flex flex-col sm:flex-row gap-4 rounded-xl border border-gray-200 dark:border-gray-700 p-4 transition hover:border-primary-500\">\u003Cdiv class=\"min-w-0 flex-1\">\u003Cstrong class=\"block text-lg text-gray-900 dark:text-gray-100\">AI智能体记忆不是RAG：如何区分记忆、检索、状态和上下文\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">治理需要对持久记忆、权威状态、检索信息和临时模型上下文采取不同的策略。\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">阅读记忆架构文章 →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Caside class=\"editorjs-referral my-6\">\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fzh\u002Fblog\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers\" class=\"flex flex-col sm:flex-row gap-4 rounded-xl border border-gray-200 dark:border-gray-700 p-4 transition hover:border-primary-500\">\u003Cdiv class=\"min-w-0 flex-1\">\u003Cstrong class=\"block text-lg text-gray-900 dark:text-gray-100\">答案有效性边界：相关性与可靠AI答案之间缺失的层\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">治理决策应保留证据和审批保持有效的条件，包括版本、范围、来源和时间。\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">阅读答案有效性边界 →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Ch2 id=\"section-157\">常见问题\u003C\u002Fh2>\n\u003Csection class=\"editorjs-faq my-6 rounded-xl border border-gray-200 p-5 dark:border-gray-700\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">AI治理常见问题\u003C\u002Fh3>\u003Cdiv id=\"faq1\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">什么是AI治理？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">AI治理是用于管理AI系统如何被开发、采购、部署、运营、变更和退役的所有权、决策权、控制和证据体系。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq2\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">AI治理与AI风险管理相同吗？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">不相同。风险管理识别、评估和处理风险。治理定义谁必须做这项工作、哪些决策需要它以及需要什么证据或权限。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq3\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">AI治理与合规相同吗？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">不相同。合规涉及适用的法律、监管、合同或内部义务。治理将合规与架构、安全、数据、质量、权限和业务所有权整合在一起。\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\">AI治理与企业AI架构有什么区别？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">企业AI架构定义AI能力和系统如何融入组织。AI治理定义管理这些组件如何被引入、运营和变更的决策与控制体系。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq5\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">小公司需要AI治理吗？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">需要，但不一定需要专门的部门。轻量级的清单、所有权、权限、评估和变更控制可以实现相同的原则。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq6\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">AI清单应包含什么？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">至少包括：用例、负责人、模型\u002F提供商\u002F版本、数据类别、用户、工具\u002F行动、权限、风险分类、评估状态、生命周期状态和审查触发条件。\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\">使用已批准的模型意味着用例已获批准吗？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">不。风险取决于应用场景：数据、用户、工具、自主性、后果和业务流程。\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\">什么使AI系统可审计？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">组织能够重建相关的所有权、已批准的配置、模型\u002F提供商\u002F版本、数据\u002F权限上下文、评估证据、重要行动和生命周期决策。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq9\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">AI治理决策应多久审查一次？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">使用基于风险的审查间隔加上事件触发条件，例如模型\u002F提供商变更、新数据、新工具、事件、重大性能变化或监管更新。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-159\">术语表\u003C\u002Fh2>\n\u003Csection class=\"editorjs-glossary my-6 rounded-xl border border-gray-200 dark:border-gray-700 p-5\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">关键AI治理术语\u003C\u002Fh3>\u003Cdl>\u003Cdiv id=\"ai-governance\" 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治理\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">管理AI生命周期的所有权、决策权、控制和证据的组织体系。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"ai-management-system\" 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管理体系\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">用于负责任地开发、提供或使用AI的相互关联的组织政策、目标和流程；ISO\u002FIEC 42001规定了此类体系的要求。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"ai-inventory\" 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清单\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">AI系统、模型、提供商、用例、负责人、数据、风险分类和生命周期状态的登记册。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"risk-owner\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">风险负责人\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">被指定负责决定如何处理已定义风险或是否接受剩余风险的权威人员。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"control\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">控制措施\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">旨在预防、检测、减少或应对风险的技术、组织或程序措施。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"governance-gate\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">治理关口\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">生命周期决策点，在继续之前需要定义的证据和权限。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"residual-risk\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">剩余风险\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">在应用控制措施或缓解措施后仍然存在的风险。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"exception\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">例外\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">明确、有范围且通常有时间限制的授权，允许偏离正常的治理要求。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"auditability\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">可审计性\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">重建相关决策、配置、证据、身份和执行事件的能力。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"model-governance\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">模型治理\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">涵盖模型选择、版本管理、评估、允许使用、变更和退役的控制和决策。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"provider-governance\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">提供商治理\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">涵盖外部或内部AI提供商依赖关系、数据处理、安全、合同、生命周期和退出的控制。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"human-oversight\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">人类监督\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">在定义的点上为AI决策或行动设计的人类审查或干预能力。\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-161\">结论\u003C\u002Fh2>\n\u003Cp>AI治理是围绕AI的组织控制平面。它为那些否则会隐藏在代码、提供商设置、提示词或非正式团队判断中的决策赋予名称和证据。\u003C\u002Fp>\n\u003Cp>强有力的治理连接整个系统：业务目的、模型、提供商、数据权限、身份、权限、评估、风险、合规、监控、事件、变更和退役。\u003C\u002Fp>\n\u003Cp>实际目标不是最大化流程。而是最小化的治理结构，使重要的AI决策在整个生命周期中拥有明确的责任归属、基于证据、可执行、可审查和可审计。\u003C\u002Fp>\n\u003Ch2 id=\"section-165\">主要来源和当前参考\u003C\u002Fh2>\n\u003Cp>以下来源为AI管理、风险和监管提供了当前的外部依据。项目部分是原始的实施\u002F项目证据，并明确区别于正式标准或认证的治理体系。\u003C\u002Fp>\n\u003Ca href=\"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">NIST — AI风险管理框架\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">NIST当前关于AI RMF 1.0、正在进行的修订、GenAI配置文件及相关风险管理资源的中心。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fairc.nist.gov\u002Fairmf-resources\u002Fairmf\u002F5-sec-core\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">NIST AIRC — AI RMF核心\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">官方AI RMF核心描述了治理、映射、测量和管理，其中治理是跨生命周期的职能。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework\u002Fnist-ai-rmf-playbook\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">NIST — AI RMF操作手册\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">在AI生命周期中实施可信度和风险管理的建议行动。\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 — 生成式AI配置文件\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">NIST配套配置文件，将AI RMF概念应用于生成式AI风险和生命周期管理。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F42001\" 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 42001:2023 — AI管理系统\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">国际标准，规定了建立、实施、维护和持续改进AI管理系统的要求。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F77304.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 23894:2023 — AI风险管理\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">将AI特定风险管理整合到组织活动和职能中的国际指南。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdigital-strategy.ec.europa.eu\u002Fen\u002Fpolicies\u002Fregulatory-framework-ai\" 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\">欧盟委员会 — AI法案\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">欧盟委员会当前关于欧盟AI法案、应用时间表和实施框架的概述。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdigital-strategy.ec.europa.eu\u002Fen\u002Ffaqs\u002Fnavigating-ai-act\" 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\">欧盟委员会 — 导航AI法案\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">当前常见问题解答，涵盖治理、执法、实施和不断变化的应用时间表。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdigital-strategy.ec.europa.eu\u002Fen\u002Ffactpages\u002Fgeneral-purpose-ai-obligations-under-ai-act\" 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\">欧盟委员会 — 通用AI义务\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">当前关于GPAI提供商的文件、版权、训练内容和系统性风险义务的概述。\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1717},1791486417710,[214,220,228,235,242,250,255,260,265,270,275,280,285,290,322,327,332,337,342,347,387,392,397,402,407,412,441,446,451,456,461,467,472,477,482,487,534,539,544,549,554,559,594,599,604,609,614,619,624,629,634,639,644,649,654,659,664,669,674,679,684,725,730,735,740,745,750,755,760,765,770,777,782,812,817,822,827,832,837,842,847,852,857,862,867,872,901,906,911,916,921,926,931,936,941,946,951,956,961,966,971,976,981,986,1015,1020,1025,1030,1035,1040,1045,1050,1056,1061,1066,1071,1076,1081,1086,1091,1096,1101,1106,1135,1140,1187,1192,1197,1202,1207,1212,1217,1252,1257,1262,1304,1309,1362,1367,1405,1410,1415,1420,1425,1430,1435,1440,1445,1450,1455,1460,1465,1470,1475,1484,1492,1500,1505,1547,1552,1605,1610,1615,1620,1625,1630,1635,1645,1654,1663,1672,1681,1690,1699,1708],{"id":215,"data":216,"type":218,"tunes":219},"intro",{"text":217},"AI 治理是一套由决策权、职责、控制措施和证据构成的体系，用于决定组织可以如何开发、获取、部署、运营、变更和退役 AI 系统。它比一份政策文件更广泛，但又比整体企业架构更狭窄。有效的 AI 治理将业务所有权、模型与供应商选择、数据权限、许可、风险分类、评估、监控、事件处理、可审计性和生命周期决策连接起来，使人们不仅能够回答“AI 是否有效？”，还能够回答“谁批准了它、在什么条件下批准、依据什么证据，以及该决策何时必须重新审视？”","paragraph",{},{"id":221,"data":222,"type":226,"tunes":227},"direct",{"body":223,"title":224,"variant":225},"\u003Cstrong>AI 治理将 AI 从一种非正式的技术能力转变为一种可问责的组织能力。\u003C\u002Fstrong>\u003Cbr>\u003Cbr>架构决定系统如何构建。工程负责实现它。风险管理评估不确定性和危害。合规处理适用的义务。治理则通过所有权、决策权、所需控制措施、证据和生命周期关卡将这些活动连接起来。","直接回答","info","callout",{},{"id":229,"data":230,"type":226,"tunes":234},"boundary",{"body":231,"title":232,"variant":233},"治理委员会可以是一种机制，政策也可以记录期望，但只有当决策能够改变系统被允许做什么时，治理才真正投入运行：可以使用哪些模型、哪些数据可以进入这些模型、智能体可以执行哪些工具、需要哪些评估、谁可以批准例外、必须记录什么，以及什么会触发暂停或退役。","治理不是委员会，也不是一份 PDF","warning",{},{"id":236,"data":237,"type":226,"tunes":241},"current",{"body":238,"title":239,"variant":240},"NIST AI RMF 1.0 仍是当前已发布的框架，同时 NIST 正在对其进行修订。其核心围绕 \u003Cstrong>GOVERN、MAP、MEASURE 和 MANAGE\u003C\u002Fstrong> 组织，其中 GOVERN 是贯穿各领域的职能。ISO\u002FIEC 42001:2023 仍是用于建立、运行和持续改进 AI 管理体系的国际 AI 管理体系标准。欧盟《人工智能法案》现已自 2026 年 8 月 2 日起普遍适用，但部分义务有更早的适用日期，部分高风险要求有更晚的过渡日期。在做出具体合规决策之前，始终应重新核查监管时间表。","当前来源说明 — 2026 年 10 月 8 日","note",{},{"id":243,"data":244,"type":248,"tunes":249},"toc",{"title":245,"maxLevel":246,"minLevel":247},"目录",3,2,"tableOfContents",{},{"id":251,"data":252,"type":42,"tunes":254},"h-meaning",{"text":253,"level":247},"AI 治理的真正含义",{},{"id":256,"data":257,"type":218,"tunes":259},"p-meaning-1",{"text":258},"AI 治理回答的是模型、SDK 或架构图本身无法回答的组织问题。谁拥有业务成果？谁可以批准新的供应商？哪些数据类别被禁止进行外部处理？部署前需要哪些证据？智能体可以获得哪些权限？谁可以接受剩余风险？当模型在升级后行为发生变化时会发生什么？",{},{"id":261,"data":262,"type":218,"tunes":264},"p-meaning-2",{"text":263},"其目的不是阻止变化。良好的治理使变化清晰可辨：决策有负责人、证据、条件、例外、复审日期以及回滚或升级路径。",{},{"id":266,"data":267,"type":218,"tunes":269},"p-meaning-3",{"text":268},"这就是为什么 NIST 将 GOVERN 置于整个 AI 风险管理生命周期之中，而不是将治理视为最后一个审批步骤。治理确立了文化、政策、问责制和组织结构，使映射、衡量和管理 AI 风险成为可能。",{},{"id":271,"data":272,"type":42,"tunes":274},"h-simple",{"text":273,"level":247},"最简单的例子",{},{"id":276,"data":277,"type":218,"tunes":279},"p-simple-1",{"text":278},"一个产品团队希望添加一个外部生成式 AI 供应商，用于总结内部客户支持工单。从技术上讲，集成可能只需要一次 API 调用。",{},{"id":281,"data":282,"type":218,"tunes":284},"p-simple-2",{"text":283},"治理会提出另一组问题：工单内容是否被允许离开组织环境？批准了哪个供应商和模型版本？是否禁用了保留？哪些用户可以调用该功能？如何评估输出？是否需要人工审核？记录哪些内容？谁负责事件？如果供应商更改条款或模型行为会发生什么？",{},{"id":286,"data":287,"type":218,"tunes":289},"p-simple-3",{"text":288},"治理结果可能仍然是“部署它”。区别在于，部署现在是一个具有明确条件、可追踪的决策，而不是一项未被记录的工程选择。",{},{"id":291,"data":292,"type":320,"tunes":321},"simple-flow",{"steps":293,"title":318,"orientation":319},[294,297,300,303,306,309,312,315],{"label":295,"description":296},"1. 登记用例","记录目的、负责人、用户、数据、模型\u002F供应商以及预期成果。",{"label":298,"description":299},"2. 对风险和义务进行分类","确定业务后果、数据敏感性、自主性、监管暴露和滥用可能性。",{"label":301,"description":302},"3. 定义所需控制措施","明确权限、数据处理、评估、人工监督、安全、日志记录和供应商约束。",{"label":304,"description":305},"4. 收集证据","运行测试、安全\u002F隐私审查、架构审查以及相关法律\u002F合规检查。",{"label":307,"description":308},"5. 做出决策","批准、有条件批准、要求修改、暂缓或拒绝。",{"label":310,"description":311},"6. 在受控配置下部署","固定已批准的模型\u002F供应商\u002F运行时，并强制执行所需边界。",{"label":313,"description":314},"7. 监控并重新评估","跟踪事件、质量、漂移、供应商变更、新风险和法规变化。",{"label":316,"description":317},"8. 变更、暂停或退役","使用证据和所有权规则来决定下一个生命周期状态。","一个基本的受治理 AI 决策","auto","processFlow",{},{"id":323,"data":324,"type":42,"tunes":326},"h-stops",{"text":325,"level":247},"简单例子止步之处",{},{"id":328,"data":329,"type":218,"tunes":331},"p-stops-1",{"text":330},"大型组织很少孤立地治理一个 AI 系统。同一个模型可能支持数十个产品；同一个供应商可能处理多个数据类别；一个智能体平台可能向许多团队暴露共享工具。",{},{"id":333,"data":334,"type":218,"tunes":336},"p-stops-2",{"text":335},"因此，治理既需要系统级控制，也需要组合级结构：AI 清单、已批准供应商、模型目录、共享评估基线、安全模式、风险阈值、例外登记册和所有权映射。",{},{"id":338,"data":339,"type":218,"tunes":341},"p-stops-3",{"text":340},"治理也不可能对每一种 AI 用途都完全相同。公共内容摘要器、内部编码助手、招聘支持系统以及能够发起支付的智能体，在后果和控制配置上存在实质性差异。",{},{"id":343,"data":344,"type":42,"tunes":346},"h-not",{"text":345,"level":247},"什么是AI治理——以及它不是什么",{},{"id":348,"data":349,"type":385,"tunes":386},"not-comparison",{"rows":350,"title":376,"layout":377,"columns":378},[351,356,360,364,368,372],{"id":352,"label":353,"values":354},"architecture","企业\u002F解决方案架构",[355,355],"",{"id":357,"label":358,"values":359},"risk","AI风险管理",[355,355],{"id":361,"label":362,"values":363},"compliance","合规",[355,355],{"id":365,"label":366,"values":367},"security","安全",[355,355],{"id":369,"label":370,"values":371},"mlops","MLOps \u002F LLMOps",[355,355],{"id":373,"label":374,"values":375},"ethics","AI伦理原则",[355,355],"AI治理与相邻学科的对比","table",[379,382],{"id":380,"label":381},"governance","AI治理",{"id":383,"label":384},"adjacent","相邻学科","comparison",{},{"id":388,"data":389,"type":42,"tunes":391},"h-governance-compliance",{"text":390,"level":247},"治理的范围比合规更广",{},{"id":393,"data":394,"type":218,"tunes":396},"p-compliance-1",{"text":395},"合规是治理的一项输入，而非整个治理体系。一个AI用例可以合法被允许，但仍可能违反公司风险偏好、安全政策、合同义务或产品质量要求。",{},{"id":398,"data":399,"type":218,"tunes":401},"p-compliance-2",{"text":400},"反过来也同样重要：内部批准不能凌驾于法律之上。治理应使适用的法律义务在用于架构、安全和业务风险的同一决策路径中可见。",{},{"id":403,"data":404,"type":218,"tunes":406},"p-compliance-3",{"text":405},"ISO\u002FIEC 42001明确将AI管理体系界定为一种结构化方式，用于建立负责任AI的政策、目标和流程。ISO还指出，该标准不替代法律或法规；它提供了一个可支持合规的管理框架。",{},{"id":408,"data":409,"type":42,"tunes":411},"h-frameworks",{"text":410,"level":247},"NIST AI RMF和ISO\u002FIEC 42001解决不同的治理需求",{},{"id":413,"data":414,"type":377,"tunes":440},"framework-table",{"content":415,"stretched":43,"withHeadings":14},[416,420,424,428,432,436],[417,418,419],"框架\u002F标准","主要作用","有用的治理价值",[421,422,423],"NIST AI RMF 1.0","自愿性AI风险管理框架","围绕GOVERN、MAP、MEASURE和MANAGE在整个生命周期内组织成果",[425,426,427],"NIST AI 600-1","AI RMF的生成式AI配置文件","增加针对GenAI的风险考量和行动",[429,430,431],"ISO\u002FIEC 42001:2023","AI管理体系要求","创建组织范围的管理体系，包括政策、角色、流程和持续改进",[433,434,435],"ISO\u002FIEC 23894:2023","AI风险管理指南","指导将AI特定风险管理整合到组织活动中",[437,438,439],"EU AI Act","欧盟具有约束力的法规","根据行为者、AI类别和用例创建法律义务",{},{"id":442,"data":443,"type":218,"tunes":445},"p-framework-1",{"text":444},"这些来源不应被合并为一份检查清单。NIST AI RMF是风险管理指南。ISO\u002FIEC 42001是管理体系标准。EU AI Act是法律。组织可以将它们一起使用，但它们的权威性、范围和实施目的各不相同。",{},{"id":447,"data":448,"type":42,"tunes":450},"h-current-eu",{"text":449,"level":247},"当前EU AI Act的时间安排很重要",{},{"id":452,"data":453,"type":218,"tunes":455},"p-eu-1",{"text":454},"截至2026年10月8日，欧盟委员会表示AI Act于2026年8月2日普遍适用。禁止性做法和AI素养条款自2025年2月2日起适用，而通用AI模型的治理规则和义务自2025年8月2日起适用。",{},{"id":457,"data":458,"type":218,"tunes":460},"p-eu-2",{"text":459},"委员会当前的指南还反映了某些高风险要求的较晚适用日期。确切的日期和过渡规则是不断变化的合规输入，在做出部署决定前应依据委员会当前材料进行核实。",{},{"id":462,"data":463,"type":226,"tunes":466},"eu-boundary",{"body":464,"title":465,"variant":233},"此处的监管示例解释了为什么治理需要版本化的法律\u002F合规输入。它们并不决定某个特定产品在法律上是否被归类为禁止、高风险、GPAI、部署者、提供者或其他受监管行为者。","架构文章，非法律建议",{},{"id":468,"data":469,"type":42,"tunes":471},"h-inventory",{"text":470,"level":247},"AI治理从清单开始",{},{"id":473,"data":474,"type":218,"tunes":476},"p-inventory-1",{"text":475},"组织无法治理其无法识别的AI系统。清单应涵盖的不仅仅是自定义训练的模型。它可能包括外部模型API、嵌入式copilot、本地模型、支持AI的SaaS功能、代理运行时、检索系统和自动化决策组件。",{},{"id":478,"data":479,"type":218,"tunes":481},"p-inventory-2",{"text":480},"有用的清单将AI能力与其业务负责人、技术负责人、用例、用户、数据类别、模型\u002F提供者、部署环境、权限、风险分类、评估状态、适用义务和生命周期状态联系起来。",{},{"id":483,"data":484,"type":218,"tunes":486},"p-inventory-3",{"text":485},"清单不仅仅是给审计人员看的电子表格。它是索引，让组织知道当提供者变更、漏洞出现、法规变得适用或模型退役时必须审查什么。",{},{"id":488,"data":489,"type":377,"tunes":533},"inventory-table",{"content":490,"stretched":43,"withHeadings":14},[491,494,497,500,503,506,509,512,515,518,521,524,527,530],[492,493],"清单字段","治理为何需要它",[495,496],"用例\u002F目的","定义AI存在的原因以及成功的含义",[498,499],"业务负责人","拥有成果和业务风险",[501,502],"技术负责人","拥有架构、实施和运营",[504,505],"模型+版本","识别产生行为的依赖项",[507,508],"提供者\u002F运行时","识别合同、托管和运营依赖项",[510,511],"数据类别","确定隐私、机密性和真相来源约束",[513,514],"用户\u002F受影响方","确定暴露和人类影响背景",[516,517],"工具\u002F操作","确定自主性和副作用风险",[519,520],"权限\u002F身份","定义谁或什么可以调用该能力",[522,523],"风险分类","确定所需控制和审批路径",[525,526],"评估证据","显示预期行为是否经过测试",[528,529],"生命周期状态","草稿、审查、批准、限制、暂停或退役",[531,532],"审查日期\u002F触发条件","定义何时必须重新审视治理决定",{},{"id":535,"data":536,"type":42,"tunes":538},"h-ownership",{"text":537,"level":247},"治理需要明确的责任归属",{},{"id":540,"data":541,"type":218,"tunes":543},"p-own-1",{"text":542},"AI 故障往往跨越组织边界。模型质量问题可能演变为产品故障、安全问题、隐私事件或合同违约。治理需要在事件发生之前就明确责任人。",{},{"id":545,"data":546,"type":218,"tunes":548},"p-own-2",{"text":547},"责任归属并不意味着一个人对所有事情负责。一个健全的模型会分离决策权：业务负责人、产品负责人、技术负责人、数据负责人、安全\u002F隐私专家、法律\u002F合规角色和运营支持。",{},{"id":550,"data":551,"type":218,"tunes":553},"p-own-3",{"text":552},"关键特性是每项必需的决策都有负责人，并且每位负责人都知道他们需要审查哪些证据。",{},{"id":555,"data":556,"type":42,"tunes":558},"h-decision-rights",{"text":557,"level":247},"决策权应当明确",{},{"id":560,"data":561,"type":377,"tunes":593},"decision-table",{"content":562,"stretched":43,"withHeadings":14},[563,566,569,572,575,578,581,584,587,590],[564,565],"决策","典型责任职能",[567,568],"此 AI 用例是否可以存在？","业务\u002F产品负责人，结合治理\u002F风险意见",[570,571],"此数据类别是否可以处理？","数据负责人 + 根据政策的隐私\u002F安全",[573,574],"此提供商\u002F模型是否可以使用？","架构\u002F平台 + 安全\u002F采购 + 治理",[576,577],"此代理是否可以执行此操作？","应用负责人 + 授权\u002F业务政策负责人",[579,580],"质量是否足以部署？","产品\u002F技术负责人对照既定验收标准",[582,583],"剩余风险是否可以接受？","适当权限级别的指定风险负责人",[585,586],"是否可以授予例外？","明确的例外授权，有时间限制并记录在案",[588,589],"系统是否应暂停？","在事件或风险触发下的运营\u002F业务负责人",[591,592],"模型升级是否可以上线？","在回归\u002F评估证据之后的变更负责人",{},{"id":595,"data":596,"type":42,"tunes":598},"h-model",{"text":597,"level":247},"模型治理不仅仅是选择模型",{},{"id":600,"data":601,"type":218,"tunes":603},"p-model-1",{"text":602},"模型治理跟踪使用哪个模型、用于什么目的、在何种配置和证据下。这适用于外部 API、本地托管模型、微调模型以及嵌入第三方软件中的模型。",{},{"id":605,"data":606,"type":218,"tunes":608},"p-model-2",{"text":607},"模型决策应考虑能力、评估结果、成本、延迟、数据处理、提供商条款、生命周期支持、地理\u002F托管限制、安全性、回退行为以及版本变更的后果。",{},{"id":610,"data":611,"type":218,"tunes":613},"p-model-3",{"text":612},"诸如“latest”之类的模型别名在操作上可能很方便，但如果行为在没有受治理的发布流程下发生变化，则会削弱可复现性。有重大后果的系统受益于明确的版本跟踪和回归评估。",{},{"id":615,"data":616,"type":42,"tunes":618},"h-provider",{"text":617,"level":247},"提供商治理是一个独立的依赖层",{},{"id":620,"data":621,"type":218,"tunes":623},"p-provider-1",{"text":622},"使用同一模型系列的两个系统可能具有不同的治理风险，如果一个在本地运行，另一个将数据发送给外部提供商。提供商治理涵盖合同条款、处理位置、保留、日志记录、子处理者、可用性、弃用和退出策略。",{},{"id":625,"data":626,"type":218,"tunes":628},"p-provider-2",{"text":627},"提供商抽象可以减少技术锁定，但并不能消除治理工作。更换提供商可能会改变数据流、模型行为、安全假设、成本和合规义务。",{},{"id":630,"data":631,"type":218,"tunes":633},"p-provider-3",{"text":632},"因此，已批准的提供商列表不应被解释为“来自此提供商的每个模型和每个数据类别都自动获得批准”。批准需要范围。",{},{"id":635,"data":636,"type":42,"tunes":638},"h-data",{"text":637,"level":247},"数据治理仍然是事实来源层",{},{"id":640,"data":641,"type":218,"tunes":643},"p-data-1",{"text":642},"AI 治理并不会使模型成为组织事实的权威。数据治理仍然决定源数据的所有权、分类、保留、质量和允许使用。",{},{"id":645,"data":646,"type":218,"tunes":648},"p-data-2",{"text":647},"对于 RAG 和代理，治理应确定哪些来源是权威的、哪些是建议性的、如何保留来源、哪些数据可以进入模型上下文以及必须强制执行哪些租户\u002F用户边界。",{},{"id":650,"data":651,"type":218,"tunes":653},"p-data-3",{"text":652},"生成的输出也会产生新的数据治理问题：提示和响应是否保留、谁可以访问跟踪、生成的摘要是否成为记录，以及当源数据被删除时如何删除派生的嵌入或索引。",{},{"id":655,"data":656,"type":42,"tunes":658},"h-permissions",{"text":657,"level":247},"权限是治理决策，并在运行时强制执行",{},{"id":660,"data":661,"type":218,"tunes":663},"p-perm-1",{"text":662},"代理式人工智能使权限成为一等治理对象。组织需要决定每个代理或用户可以访问哪些工具、文件、API、数据库和副作用。",{},{"id":665,"data":666,"type":218,"tunes":668},"p-perm-2",{"text":667},"治理定义策略和审批逻辑；可信运行时执行它。诸如“不要删除文件”之类的自然语言指令不能替代文件系统、API 或服务授权。",{},{"id":670,"data":671,"type":218,"tunes":673},"p-perm-3",{"text":672},"同样的原则适用于租户隔离：角色可以授权某项操作，而租户范围限制该操作可以触及哪个客户的资源。",{},{"id":675,"data":676,"type":42,"tunes":678},"h-risk",{"text":677,"level":247},"风险分类应改变控制集",{},{"id":680,"data":681,"type":218,"tunes":683},"p-risk-1",{"text":682},"并非每个 AI 系统都需要相同的审查深度。当风险分类改变证据、审批和监控要求时，治理就变得可扩展。",{},{"id":685,"data":686,"type":377,"tunes":724},"risk-table",{"content":687,"stretched":43,"withHeadings":14},[688,692,696,700,704,708,712,716,720],[689,690,691],"风险驱动因素","较低控制示例","较高控制示例",[693,694,695],"业务后果","起草内部文本","批准财务结算",[697,698,699],"人类影响","可选的写作辅助","就业或资格决策支持",[701,702,703],"数据敏感性","公开文档","健康、人力资源、财务或机密数据",[705,706,707],"自主性","只读建议","具有写入\u002F支付\u002F部署工具的代理",[709,710,711],"可逆性","易于重新生成的摘要","不可逆的外部交易",[713,714,715],"暴露程度","小型内部试点","面向公众\u002F客户的大规模系统",[717,718,719],"来源权威性","咨询性内容","依赖受监管或合同事实的系统",[721,722,723],"故障可检测性","明显的格式缺陷","看似合理但实质错误的建议",{},{"id":726,"data":727,"type":218,"tunes":729},"p-risk-2",{"text":728},"分类方法可以简单或复杂，但应映射到具体后果：更多测试、更窄的权限、所需的人工监督、安全审查、高管风险接受或部署禁止。",{},{"id":731,"data":732,"type":42,"tunes":734},"h-map",{"text":733,"level":247},"治理必须保留用例上下文",{},{"id":736,"data":737,"type":218,"tunes":739},"p-map-1",{"text":738},"NIST 的 MAP 功能强调预期目的、用户、部署上下文、假设、影响以及适用的法律或规范。这很重要，因为同一个模型在一个用例中可能是低风险，而在另一个用例中可能产生高后果。",{},{"id":741,"data":742,"type":218,"tunes":744},"p-map-2",{"text":743},"因此，治理记录应对应用进行分类，而不仅仅是模型。“我们使用模型 X”不足以确定风险。",{},{"id":746,"data":747,"type":218,"tunes":749},"p-map-3",{"text":748},"相关的治理对象是系统\u002F用例：模型 + 数据 + 上下文 + 工具 + 用户 + 部署环境 + 业务流程。",{},{"id":751,"data":752,"type":42,"tunes":754},"h-evaluation",{"text":753,"level":247},"评估是治理证据",{},{"id":756,"data":757,"type":218,"tunes":759},"p-eval-1",{"text":758},"AI 治理流程不应仅基于供应商基准或成功的演示来批准部署。系统需要与其实际预期用途相关的证据。",{},{"id":761,"data":762,"type":218,"tunes":764},"p-eval-2",{"text":763},"有用的证据可以包括任务成功评估、检索质量、事实依据、安全测试、权限测试、对抗性场景、人工审查研究、延迟\u002F成本、鲁棒性和回归比较。",{},{"id":766,"data":767,"type":218,"tunes":769},"p-eval-3",{"text":768},"NIST 的 MEASURE 功能明确说明了这一点：组织应识别并应用适当的方法和指标来应对映射期间识别的风险，同时记录无法或不会测量的风险。",{},{"id":771,"data":772,"type":226,"tunes":776},"eval-boundary",{"body":773,"title":774,"variant":775},"“团队认为模型足够好”是一个薄弱的审批产物。“系统在代表性测试中达到了定义的验收标准，并具有这些已知限制和剩余风险”是可治理的。","治理关口应要求证据，而非信心","success",{},{"id":778,"data":779,"type":42,"tunes":781},"h-gates",{"text":780,"level":247},"治理关口应贯穿整个生命周期",{},{"id":783,"data":784,"type":320,"tunes":811},"gate-flow",{"steps":785,"title":810,"orientation":319},[786,789,792,795,798,801,804,807],{"label":787,"description":788},"创意\u002F发现关卡","确认业务目的、负责人以及AI是否为合适的解决方案。",{"label":790,"description":791},"架构关卡","审查模型\u002F提供商、数据流、身份、权限、隔离和运营设计。",{"label":793,"description":794},"风险\u002F合规关卡","对风险进行分类并确定适用义务；定义所需控制措施。",{"label":796,"description":797},"验证关卡","要求提供功能、安全、安保和质量标准均已满足的证据。",{"label":799,"description":800},"部署关卡","批准具体配置、版本、环境和运营负责人。",{"label":802,"description":803},"变更关卡","根据重要性重新评估模型\u002F提供商\u002F工具\u002F数据变更。",{"label":805,"description":806},"事件关卡","当定义的风险触发条件出现时，暂停、限制或回滚。",{"label":808,"description":809},"退役关卡","干净地移除访问权限、数据衍生品、凭据和过时依赖项。","示例生命周期关卡",{},{"id":813,"data":814,"type":42,"tunes":816},"h-change",{"text":815,"level":247},"变更管理是AI治理的核心",{},{"id":818,"data":819,"type":218,"tunes":821},"p-change-1",{"text":820},"即使应用程序代码没有变化，AI系统也会发生变化。提供商会更新模型、安全过滤器、上下文限制、定价、政策和基础设施。检索语料库会变化。代理工具会获得权限。法规和合同也在演变。",{},{"id":823,"data":824,"type":218,"tunes":826},"p-change-2",{"text":825},"因此，治理应定义重大变更触发条件。轻微的提示词措辞调整可能只需要常规回归测试；更换模型、启用写入工具或引入敏感数据可能需要新的审批关卡。",{},{"id":828,"data":829,"type":218,"tunes":831},"p-change-3",{"text":830},"治理记录应保留哪个版本获得了批准，以及哪些条件使该批准有效。",{},{"id":833,"data":834,"type":42,"tunes":836},"h-exceptions",{"text":835,"level":247},"例外需要负责人、到期时间和补偿性控制措施",{},{"id":838,"data":839,"type":218,"tunes":841},"p-exc-1",{"text":840},"现实组织需要例外。团队可能需要使用未经批准的模型进行有时间限制的实验，或者遗留系统可能尚未满足新的日志记录要求。",{},{"id":843,"data":844,"type":218,"tunes":846},"p-exc-2",{"text":845},"危险的模式是永久性的未记录例外。可治理的例外应明确负责人、理由、范围、剩余风险、补偿性控制措施、到期日期和审查条件。",{},{"id":848,"data":849,"type":218,"tunes":851},"p-exc-3",{"text":850},"例外处理应成为正常治理系统的一部分，而不是非正式的旁路渠道。",{},{"id":853,"data":854,"type":42,"tunes":856},"h-audit",{"text":855,"level":247},"可审计性是重建决策和执行的能力",{},{"id":858,"data":859,"type":218,"tunes":861},"p-audit-1",{"text":860},"AI可审计性不仅仅是存储模型提示词。它意味着能够重建使用了哪个系统版本、应用了哪些数据和权限、谁批准了配置、哪些评估支持了部署，以及相关执行期间发生了什么。",{},{"id":863,"data":864,"type":218,"tunes":866},"p-audit-2",{"text":865},"对于代理，这可能要求主体身份、工具调用、审批、目标资源、状态变更和结果。对于RAG，这可能要求语料库\u002F索引版本、检索查询、选定的证据和来源。对于模型变更，这可能要求之前和新的评估结果。",{},{"id":868,"data":869,"type":218,"tunes":871},"p-audit-3",{"text":870},"审计证据应适度。记录每一个可能的令牌本身可能会带来隐私和安全风险。治理应定义哪些证据是必要的、保留多长时间以及谁可以访问。",{},{"id":873,"data":874,"type":377,"tunes":900},"audit-table",{"content":875,"stretched":43,"withHeadings":14},[876,879,882,885,888,891,894,897],[877,878],"审计对象","有用证据",[880,881],"治理决策","负责人、日期、决策、条件、证据、例外",[883,884],"模型发布","模型\u002F提供商\u002F版本、配置、回归结果",[886,887],"数据访问","主体、租户\u002F范围、来源类别、策略决策",[889,890],"代理操作","工具、参数\u002F目标、审批、结果、状态变更",[892,893],"RAG答案","语料库\u002F索引版本、检索集、选定证据、引用",[895,896],"事件","触发条件、受影响系统、遏制措施、决策负责人、补救措施",[898,899],"退役","已禁用端点、已撤销凭据、已删除衍生数据、归档决策",{},{"id":902,"data":903,"type":42,"tunes":905},"h-observability",{"text":904,"level":247},"监控闭合治理循环",{},{"id":907,"data":908,"type":218,"tunes":910},"p-monitor-1",{"text":909},"批准是一个快照。生产监控告诉治理层批准背后的假设是否仍然成立。",{},{"id":912,"data":913,"type":218,"tunes":915},"p-monitor-2",{"text":914},"有用的信号取决于用例：质量回归、不安全输出、工具故障、策略拒绝、异常成本、延迟、用户投诉、漂移、检索新鲜度、提供商事件、安全警报或新的监管分类。",{},{"id":917,"data":918,"type":218,"tunes":920},"p-monitor-3",{"text":919},"治理应定义触发行动的阈值：调查、限制、要求人工审查、回滚、切换提供商、暂停或退役。",{},{"id":922,"data":923,"type":42,"tunes":925},"h-incidents",{"text":924,"level":247},"AI事件需要明确的操作路径",{},{"id":927,"data":928,"type":218,"tunes":930},"p-inc-1",{"text":929},"AI特定事件可能涉及有害内容、数据泄露、未授权操作、持续的事实性失败、模型\u002F提供商中断、提示注入、跨租户检索或模型更新后的意外行为。",{},{"id":932,"data":933,"type":218,"tunes":935},"p-inc-2",{"text":934},"事件流程应将技术响应与治理责任联系起来。必须有人被授权禁用模型、移除工具、撤销凭证、限制用户、通知受影响的职能部门，并决定系统是否可以恢复服务。",{},{"id":937,"data":938,"type":218,"tunes":940},"p-inc-3",{"text":939},"事件中的经验教训应更新政策、测试、风险分类和可复用的平台控制措施，而不是仅停留在某个团队内部。",{},{"id":942,"data":943,"type":42,"tunes":945},"h-procurement",{"text":944,"level":247},"采购是AI治理的一部分",{},{"id":947,"data":948,"type":218,"tunes":950},"p-proc-1",{"text":949},"组织可以通过普通的SaaS采购获得大量AI能力。因此，治理应覆盖购买的AI功能以及内部工程化系统。",{},{"id":952,"data":953,"type":218,"tunes":955},"p-proc-2",{"text":954},"供应商审查可以包括数据使用、保留、模型训练政策、子处理者、安全性、事件通知、导出\u002F删除、地理处理、版本变更、服务连续性和合同退出。",{},{"id":957,"data":958,"type":218,"tunes":960},"p-proc-3",{"text":959},"技术架构审查和采购审查应共享同一系统清单，以免商业批准偏离实际部署的数据流。",{},{"id":962,"data":963,"type":42,"tunes":965},"h-human",{"text":964,"level":247},"人工监督应被设计，而不仅仅是声明",{},{"id":967,"data":968,"type":218,"tunes":970},"p-human-1",{"text":969},"“人在回路中”只有在人拥有权限、时间、信息和可用的干预机制时才有意义。",{},{"id":972,"data":973,"type":218,"tunes":975},"p-human-2",{"text":974},"如果审查者只看到AI建议，而看不到其证据、不确定性或来源状态，可能只是对输出进行橡皮图章式批准。治理应明确审查者可以检查什么，以及有哪些可用操作：批准、拒绝、编辑、升级或停止。",{},{"id":977,"data":978,"type":218,"tunes":980},"p-human-3",{"text":979},"人工监督还应基于风险。低后果系统可以使用抽样或事后审查，而高后果副作用可能需要在执行前获得批准。",{},{"id":982,"data":983,"type":42,"tunes":985},"h-platform",{"text":984,"level":247},"平台治理和用例治理是不同的",{},{"id":987,"data":988,"type":385,"tunes":1014},"platform-comparison",{"rows":989,"title":1006,"layout":377,"columns":1007},[990,994,998,1002],{"id":991,"label":992,"values":993},"owner","主要关注点",[355,355],{"id":995,"label":996,"values":997},"approval","典型批准",[355,355],{"id":999,"label":1000,"values":1001},"evidence","证据",[355,355],{"id":1003,"label":1004,"values":1005},"failure","治理失败",[355,355],"两个治理层级",[1008,1011],{"id":1009,"label":1010},"platform","共享AI平台",{"id":1012,"label":1013},"usecase","单个AI用例",{},{"id":1016,"data":1017,"type":218,"tunes":1019},"p-platform-1",{"text":1018},"因此，平台批准应减少重复工作，而不是消除用例责任。“模型已获批准”不同于“该模型在此处的应用已获批准”。",{},{"id":1021,"data":1022,"type":42,"tunes":1024},"h-architecture",{"text":1023,"level":247},"AI治理与企业AI架构",{},{"id":1026,"data":1027,"type":218,"tunes":1029},"p-arch-1",{"text":1028},"企业AI架构描述了AI系统、平台、数据、身份、提供商、运营和组织系统如何协同工作。AI治理描述了决定这些架构可以如何创建和变更的决策与控制系统。",{},{"id":1031,"data":1032,"type":218,"tunes":1034},"p-arch-2",{"text":1033},"两者紧密耦合。没有架构的治理可能变成抽象政策。没有治理的架构可能产生技术上优雅但所有权不明确、提供商采用不受控制或风险未经审查的系统。",{},{"id":1036,"data":1037,"type":218,"tunes":1039},"p-arch-3",{"text":1038},"最强的设计是双向的：治理要求成为架构控制，而架构则揭示治理必须拥有的真实决策。",{},{"id":1041,"data":1042,"type":42,"tunes":1044},"h-implementation",{"text":1043,"level":247},"原始项目证据",{},{"id":1046,"data":1047,"type":42,"tunes":1049},"h-enterprise",{"text":1048,"level":246},"Enterprise Aaasaasa 0.1：作为交付结构的治理",{},{"id":1051,"data":1052,"type":226,"tunes":1055},"enterprise-note",{"body":1053,"title":1054,"variant":240},"Enterprise Aaasaasa 0.1 是项目和培训\u002FPoC 证据，而非商业企业采用的证据。它在这里很有用，因为其交付结构明确连接了架构、里程碑、风险、利益相关者、验证和项目决策。","项目 \u002F PoC 证据",{},{"id":1057,"data":1058,"type":218,"tunes":1060},"p-ent-1",{"text":1059},"Enterprise Aaasaasa 0.1 为需求、架构、原型、验证和项目收尾使用了定义的里程碑。该结构说明了一个核心治理原则：生命周期转换应具有明确的输出和决策点，而不是非正式的“先构建，后审查”流程。",{},{"id":1062,"data":1063,"type":218,"tunes":1065},"p-ent-2",{"text":1064},"该项目还跟踪范围蔓延、架构延迟和 AI\u002FGDPR 问题等风险，并识别利益相关者群体，包括赞助、指导、架构、安全、营销、外部 API 和托管。",{},{"id":1067,"data":1068,"type":218,"tunes":1070},"p-ent-3",{"text":1069},"这不构成 ISO\u002FIEC 42001 管理体系。它是更狭义的项目证据，展示了所有权、风险、里程碑和验证如何整合到技术交付中。",{},{"id":1072,"data":1073,"type":42,"tunes":1075},"h-senseflow",{"text":1074,"level":246},"SenseFlow：需求和决策可追溯性",{},{"id":1077,"data":1078,"type":218,"tunes":1080},"p-sense-1",{"text":1079},"SenseFlow 使用从产品目标和用户需求，经过史诗、用户故事、验收标准、架构、实现和验证的结构化路径。决策记录保留决策、理由、替代方案、权衡、状态和日期\u002F版本。",{},{"id":1082,"data":1083,"type":218,"tunes":1085},"p-sense-2",{"text":1084},"这种可追溯性模式与治理直接相关，因为 AI 控制应连接到证明其合理性的需求或风险。当从业务需求到架构决策再到验证证据的链条可以被重建时，治理体系会变得更强大。",{},{"id":1087,"data":1088,"type":42,"tunes":1090},"h-client",{"text":1089,"level":246},"Aaasaasa AI Client：权限和运行时作为受治理的配置",{},{"id":1092,"data":1093,"type":218,"tunes":1095},"p-client-1",{"text":1094},"Aaasaasa AI Client 将提供商、模型、运行时位置和权限分开，而不是将它们视为一个“AI 设置”。中央工作区权限配置文件管理工具访问，Direct Chat 没有文件系统\u002Fshell 工具，具备代理能力的运行时在明确的权限配置文件下运行。",{},{"id":1097,"data":1098,"type":218,"tunes":1100},"p-client-2",{"text":1099},"这种分离展示了一个重要的治理模式：模型选择和行动权限应是独立的配置对象。更强的模型不会自动获得更广泛的文件系统、shell 或业务权限。",{},{"id":1102,"data":1103,"type":218,"tunes":1105},"p-client-3",{"text":1104},"实现证据是架构性的，并非声称该应用程序构成经认证的组织 AI 治理体系。",{},{"id":1107,"data":1108,"type":377,"tunes":1134},"impl-table",{"content":1109,"stretched":43,"withHeadings":14},[1110,1113,1116,1119,1122,1125,1128,1131],[1111,1112],"观察到的项目模式","治理经验",[1114,1115],"里程碑关卡","生命周期转换可能需要明确证据",[1117,1118],"风险登记册","已知不确定性成为受管理对象，而非非正式关切",[1120,1121],"利益相关者映射","决策责任可以被有意识地分配",[1123,1124],"验收标准 + 验证","部署决策可以依赖证据",[1126,1127],"决策记录","架构权衡保持可追溯",[1129,1130],"分离模型\u002F提供商\u002F运行时\u002F权限","能力和权限可以独立治理",[1132,1133],"明确的项目成熟度标签","PoC 证据不会被误报为生产或市场证明",{},{"id":1136,"data":1137,"type":42,"tunes":1139},"h-failures",{"text":1138,"level":247},"常见 AI 治理失败模式",{},{"id":1141,"data":1142,"type":377,"tunes":1186},"failures-table",{"content":1143,"stretched":43,"withHeadings":14},[1144,1147,1150,1153,1156,1159,1162,1165,1168,1171,1174,1177,1180,1183],[1145,1146],"失败模式","出了什么问题",[1148,1149],"治理只是政策 PDF","团队无法将政策转化为运行时控制或部署决策",[1151,1152],"没有 AI 清单","组织无法识别模型、代理或嵌入式 AI 的使用位置",[1154,1155],"模型批准被当作用例批准","已批准的模型被用于风险背景实质性不同的场景",[1157,1158],"没有指定的业务负责人","技术团队默认继承业务风险决策",[1160,1161],"风险分类没有控制后果","每个系统无论后果如何都接受相同的审查",[1163,1164],"权限仅存在于提示中","模型指令成为真实授权的替代品",[1166,1167],"提供商变更不可见","行为\u002F数据\u002F合规假设在未重新评估的情况下发生变化",[1169,1170],"演示成功即批准证据","生产风险从小型顺利路径测试中推断",[1172,1173],"人工监督流于形式","审查者无法检查证据或停止操作",[1175,1176],"例外没有到期时间","临时变通方案成为永久治理债务",[1178,1179],"日志存在但无法重建决策","可审计性与原始数据保留相混淆",[1181,1182],"合规部门独自拥有治理","产品、工程、安全和运营脱离问责",[1184,1185],"每个决策都提交中央委员会","治理成为瓶颈，而非可扩展的控制系统",{},{"id":1188,"data":1189,"type":42,"tunes":1191},"h-federated",{"text":1190,"level":247},"中央治理并不意味着集中每一个决策",{},{"id":1193,"data":1194,"type":218,"tunes":1196},"p-fed-1",{"text":1195},"成熟的组织可以集中管理策略、控制模式和升级机制，同时将低风险决策委托给产品或平台团队。",{},{"id":1198,"data":1199,"type":218,"tunes":1201},"p-fed-2",{"text":1200},"这种联邦式模型比要求中央委员会批准每一次提示变更更具扩展性。中央职能定义风险层级、强制性控制、提供商政策、例外授权和审计要求；团队在这些边界内自主运作。",{},{"id":1203,"data":1204,"type":218,"tunes":1206},"p-fed-3",{"text":1205},"设计目标是实现一致的问责制，而非最大程度的集中化。",{},{"id":1208,"data":1209,"type":42,"tunes":1211},"h-metrics",{"text":1210,"level":247},"治理治理系统本身",{},{"id":1213,"data":1214,"type":218,"tunes":1216},"p-metric-1",{"text":1215},"治理需要反馈。否则控制措施可能变成昂贵且无法降低风险的仪式。",{},{"id":1218,"data":1219,"type":377,"tunes":1251},"metrics-table",{"content":1220,"stretched":43,"withHeadings":14},[1221,1224,1227,1230,1233,1236,1239,1242,1245,1248],[1222,1223],"指标\u002F信号","可揭示的内容",[1225,1226],"清单覆盖率","AI采用是否对治理可见",[1228,1229],"决策时间","治理是否不必要地阻碍交付",[1231,1232],"例外数量与时长","政策是否切合实际或经常被绕过",[1234,1235],"评估失败率","部署前控制是否能发现缺陷",[1237,1238],"部署后事故率","审批证据是否能预测生产行为",[1240,1241],"未授权工具拒绝率","权限边界是否被积极执行",[1243,1244],"模型\u002F提供商变更频率","已批准的假设多久可能过时",[1246,1247],"已退役但仍活跃的系统","生命周期清理\u002F控制失败",[1249,1250],"重复事故模式","经验教训是否正在转化为可复用的平台控制",{},{"id":1253,"data":1254,"type":218,"tunes":1256},"p-metric-2",{"text":1255},"治理指标不应奖励文书工作量。有用的衡量标准是决策质量、可追溯性、风险检测和安全交付是否得到改善。",{},{"id":1258,"data":1259,"type":42,"tunes":1261},"h-sequence",{"text":1260,"level":247},"实用的AI治理实施顺序",{},{"id":1263,"data":1264,"type":320,"tunes":1303},"design-flow",{"steps":1265,"title":1302,"orientation":319},[1266,1269,1272,1275,1278,1281,1284,1287,1290,1293,1296,1299],{"label":1267,"description":1268},"1. 定义治理范围","确定哪些内部构建、采购、嵌入和实验性AI系统被覆盖。",{"label":1270,"description":1271},"2. 创建AI清单","记录所有者、用例、模型\u002F提供商、数据、工具、用户、生命周期状态和风险类别。",{"label":1273,"description":1274},"3. 定义决策权","明确谁可以批准提供商、数据使用、风险接受、例外、部署和退役。",{"label":1276,"description":1277},"4. 建立风险层级","将后果和暴露映射到不同的控制要求。",{"label":1279,"description":1280},"5. 定义可复用的最低控制","为身份、权限、数据、安全、评估、日志记录和人工监督设定基线要求。",{"label":1282,"description":1283},"6. 将治理与架构连接","将策略转化为平台\u002F运行时控制，使团队无法意外绕过。",{"label":1285,"description":1286},"7. 构建基于证据的关卡","在生命周期转换前要求相关的评估、安全、隐私、架构和合规证据。",{"label":1288,"description":1289},"8. 治理模型\u002F提供商变更","通过回归证据跟踪版本、弃用和重大变更。",{"label":1291,"description":1292},"9. 添加监控和事故触发条件","定义哪些生产信号强制进行调查、限制或暂停。",{"label":1294,"description":1295},"10. 形式化例外","要求范围、所有者、剩余风险、补偿控制和到期时间。",{"label":1297,"description":1298},"11. 审计决策与执行","保留将所有者、配置、权限、评估和重大操作关联起来的适当证据。",{"label":1300,"description":1301},"12. 改进治理系统","利用事故、延迟和重复例外来修订控制和平台模式。","从可见性到控制构建治理",{},{"id":1305,"data":1306,"type":42,"tunes":1308},"h-checklist",{"text":1307,"level":247},"AI治理检查清单",{},{"id":1310,"data":1311,"type":377,"tunes":1361},"checklist-table",{"content":1312,"stretched":43,"withHeadings":14},[1313,1316,1319,1322,1325,1328,1331,1334,1337,1340,1343,1346,1349,1352,1355,1358],[1314,1315],"问题","预期的治理证据",[1317,1318],"为什么存在这个AI系统？","目的、业务所有者和预期成果",[1320,1321],"谁负责技术运营？","指定的技术\u002F平台所有者",[1323,1324],"使用哪个模型\u002F提供商\u002F版本？","已注册且带版本的依赖项",[1326,1327],"哪些数据可以进入系统？","分类、权限和允许使用的决策",[1329,1330],"哪些身份可以使用它？","身份验证和授权模型",[1332,1333],"它可以执行哪些操作？","工具\u002F权限矩阵和自主边界",[1335,1336],"风险层级是什么？","带理由的文档化分类",[1338,1339],"哪些控制是强制性的？","风险层级控制基线",[1341,1342],"如何评估的？","代表性测试和验收标准",[1344,1345],"谁接受了剩余风险？","指定的问责机构",[1347,1348],"什么需要人工审查？","明确的监督\u002F批准规则",[1350,1351],"记录哪些内容？","与后果成比例的审计\u002F可观测性策略",[1353,1354],"什么触发重新审查？","模型\u002F提供商\u002F数据\u002F工具\u002F法规\u002F重大变更事件",[1356,1357],"如何暂停？","操作终止\u002F限制路径和所有者",[1359,1360],"如何退役？","凭证、数据、衍生品、端点和记录清理",{},{"id":1363,"data":1364,"type":42,"tunes":1366},"h-misconceptions",{"text":1365,"level":247},"常见误解",{},{"id":1368,"data":1369,"type":377,"tunes":1404},"misconceptions-table",{"content":1370,"stretched":43,"withHeadings":14},[1371,1374,1377,1380,1383,1386,1389,1392,1395,1398,1401],[1372,1373],"误解","纠正",[1375,1376],"“AI治理就是合规。”","合规是治理的一个输入；治理还涵盖所有权、架构、权限、质量、风险和生命周期决策。",[1378,1379],"“治理意味着审查委员会。”","委员会可以批准例外或高风险系统，但许多控制应嵌入正常交付和平台架构中。",[1381,1382],"“已批准的模型对每种用途都安全。”","风险属于用例和系统上下文，而不仅仅是模型。",[1384,1385],"“供应商为我们处理治理。”","提供商控制部分技术栈；组织仍然拥有其用例、数据、权限和业务后果。",[1387,1388],"“人在回路中自动解决风险。”","只有当审查者拥有权限、上下文和干预能力时，监督才有效。",[1390,1391],"“记录一切就能实现可审计性。”","可审计性需要可重建的相关证据，并具有受控的保留和访问。",[1393,1394],"“治理阻碍创新。”","糟糕的治理会阻碍交付；设计良好的治理创造可复用的安全路径和更清晰的决策所有权。",[1396,1397],"“低风险试点不需要治理。”","它们可以使用轻量级治理，但清单、所有权和数据\u002F工具边界仍然重要。",[1399,1400],"“本地AI需要更少的治理。”","本地托管可以改变隐私\u002F提供商风险，但模型质量、权限、安全和生命周期治理仍然存在。",[1402,1403],"“一旦批准，系统就保持批准状态。”","模型、提供商、数据、法规和用途都可能变化；治理决策需要审查触发条件。",{},{"id":1406,"data":1407,"type":42,"tunes":1409},"h-edge",{"text":1408,"level":247},"边缘情况和局限性",{},{"id":1411,"data":1412,"type":218,"tunes":1414},"p-edge-1",{"text":1413},"非常小的组织可能不需要专门的AI治理职能。相同的原则可以通过轻量级架构决策、风险登记册、所有者映射和发布关卡来实施。",{},{"id":1416,"data":1417,"type":218,"tunes":1419},"p-edge-2",{"text":1418},"高度受监管的组织可能需要比这篇架构级文章所描述的更为正式的治理、独立保证、文档化合规流程和法律解释。",{},{"id":1421,"data":1422,"type":218,"tunes":1424},"p-edge-3",{"text":1423},"开源和自托管模型减少了一些提供商依赖，但产生了其他依赖：补丁、模型来源、评估、基础设施安全、许可和运营所有权。",{},{"id":1426,"data":1427,"type":218,"tunes":1429},"p-edge-4",{"text":1428},"通用AI模型可以在许多上下文中使用。治理应避免假设提供商级别的模型控制完全决定下游应用风险。",{},{"id":1431,"data":1432,"type":218,"tunes":1434},"p-edge-5",{"text":1433},"没有任何治理框架能保证AI系统是安全或正确的。治理提升问责性和决策质量；技术验证、监控和人类判断仍然必不可少。",{},{"id":1436,"data":1437,"type":42,"tunes":1439},"h-change-answer",{"text":1438,"level":247},"什么会改变这个答案？",{},{"id":1441,"data":1442,"type":218,"tunes":1444},"p-change-answer-1",{"text":1443},"具体的控制措施集合会随法律、行业、组织规模、数据敏感性、自主性、部署模式和业务后果而变化。",{},{"id":1446,"data":1447,"type":218,"tunes":1449},"p-change-answer-2",{"text":1448},"NIST目前正在修订AI RMF 1.0，因此未来的NIST术语或推荐实践可能会发生变化。ISO标准也可能被修订，而欧盟AI法案的指南和过渡细节也在持续演变。",{},{"id":1451,"data":1452,"type":218,"tunes":1454},"p-change-answer-3",{"text":1453},"稳定的架构原则是：AI决策需要明确的负责人、证据、权限、风险处理和生命周期审查，而不是隐藏在模型或应用程序配置中。",{},{"id":1456,"data":1457,"type":42,"tunes":1459},"h-related",{"text":1458,"level":247},"相关规范知识",{},{"id":1461,"data":1462,"type":218,"tunes":1464},"p-related-1",{"text":1463},"AI治理依赖于本知识图谱中已在其他地方分离的概念：真相来源决定权威性，RBAC和租户隔离约束访问，上下文工程控制模型可见信息，而智能体架构定义工具和行动如何进入执行循环。",{},{"id":1466,"data":1467,"type":218,"tunes":1469},"p-related-2",{"text":1468},"企业AI架构是父级组织架构概念。治理是运营控制层，决定这些企业AI组件如何被引入、变更和退役。",{},{"id":1471,"data":1472,"type":218,"tunes":1474},"p-related-3",{"text":1473},"智能体系统增加了治理要求，因为模型决策可能产生真实的副作用。因此，权限、审批和审计控制必须存在于模型本身之外。",{},{"id":1476,"data":1477,"type":1482,"tunes":1483},"ref-agent-reliability",{"url":1478,"title":1479,"excerpt":1480,"ctaLabel":1481},"https:\u002F\u002Fstajic.de\u002Fzh\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","AI智能体可靠性：为什么仅有最终答案是不够的","智能体治理需要关于执行轨迹、工具使用、状态变化和可恢复性的证据——而不仅仅是最终输出质量。","阅读智能体可靠性文章","referralArticle",{},{"id":1485,"data":1486,"type":1482,"tunes":1491},"ref-memory",{"url":1487,"title":1488,"excerpt":1489,"ctaLabel":1490},"https:\u002F\u002Fstajic.de\u002Fzh\u002Fblog\u002Fai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context","AI智能体记忆不是RAG：如何区分记忆、检索、状态和上下文","治理需要对持久记忆、权威状态、检索信息和临时模型上下文采取不同的策略。","阅读记忆架构文章",{},{"id":1493,"data":1494,"type":1482,"tunes":1499},"ref-avb",{"url":1495,"title":1496,"excerpt":1497,"ctaLabel":1498},"https:\u002F\u002Fstajic.de\u002Fzh\u002Fblog\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers","答案有效性边界：相关性与可靠AI答案之间缺失的层","治理决策应保留证据和审批保持有效的条件，包括版本、范围、来源和时间。","阅读答案有效性边界",{},{"id":1501,"data":1502,"type":42,"tunes":1504},"h-faq",{"text":1503,"level":247},"常见问题",{},{"id":1506,"data":1507,"type":1506,"tunes":1546},"faq",{"items":1508,"title":1545},[1509,1513,1517,1521,1525,1529,1533,1537,1541],{"id":1510,"answer":1511,"question":1512},"faq1","AI治理是用于管理AI系统如何被开发、采购、部署、运营、变更和退役的所有权、决策权、控制和证据体系。","什么是AI治理？",{"id":1514,"answer":1515,"question":1516},"faq2","不相同。风险管理识别、评估和处理风险。治理定义谁必须做这项工作、哪些决策需要它以及需要什么证据或权限。","AI治理与AI风险管理相同吗？",{"id":1518,"answer":1519,"question":1520},"faq3","不相同。合规涉及适用的法律、监管、合同或内部义务。治理将合规与架构、安全、数据、质量、权限和业务所有权整合在一起。","AI治理与合规相同吗？",{"id":1522,"answer":1523,"question":1524},"faq4","企业AI架构定义AI能力和系统如何融入组织。AI治理定义管理这些组件如何被引入、运营和变更的决策与控制体系。","AI治理与企业AI架构有什么区别？",{"id":1526,"answer":1527,"question":1528},"faq5","需要，但不一定需要专门的部门。轻量级的清单、所有权、权限、评估和变更控制可以实现相同的原则。","小公司需要AI治理吗？",{"id":1530,"answer":1531,"question":1532},"faq6","至少包括：用例、负责人、模型\u002F提供商\u002F版本、数据类别、用户、工具\u002F行动、权限、风险分类、评估状态、生命周期状态和审查触发条件。","AI清单应包含什么？",{"id":1534,"answer":1535,"question":1536},"faq7","不。风险取决于应用场景：数据、用户、工具、自主性、后果和业务流程。","使用已批准的模型意味着用例已获批准吗？",{"id":1538,"answer":1539,"question":1540},"faq8","组织能够重建相关的所有权、已批准的配置、模型\u002F提供商\u002F版本、数据\u002F权限上下文、评估证据、重要行动和生命周期决策。","什么使AI系统可审计？",{"id":1542,"answer":1543,"question":1544},"faq9","使用基于风险的审查间隔加上事件触发条件，例如模型\u002F提供商变更、新数据、新工具、事件、重大性能变化或监管更新。","AI治理决策应多久审查一次？","AI治理常见问题",{},{"id":1548,"data":1549,"type":42,"tunes":1551},"h-glossary",{"text":1550,"level":247},"术语表",{},{"id":1553,"data":1554,"type":1553,"tunes":1604},"glossary",{"title":1555,"entries":1556},"关键AI治理术语",[1557,1560,1564,1568,1572,1576,1580,1584,1588,1592,1596,1600],{"term":381,"anchor":1558,"definition":1559},"ai-governance","管理AI生命周期的所有权、决策权、控制和证据的组织体系。",{"term":1561,"anchor":1562,"definition":1563},"AI管理体系","ai-management-system","用于负责任地开发、提供或使用AI的相互关联的组织政策、目标和流程；ISO\u002FIEC 42001规定了此类体系的要求。",{"term":1565,"anchor":1566,"definition":1567},"AI清单","ai-inventory","AI系统、模型、提供商、用例、负责人、数据、风险分类和生命周期状态的登记册。",{"term":1569,"anchor":1570,"definition":1571},"风险负责人","risk-owner","被指定负责决定如何处理已定义风险或是否接受剩余风险的权威人员。",{"term":1573,"anchor":1574,"definition":1575},"控制措施","control","旨在预防、检测、减少或应对风险的技术、组织或程序措施。",{"term":1577,"anchor":1578,"definition":1579},"治理关口","governance-gate","生命周期决策点，在继续之前需要定义的证据和权限。",{"term":1581,"anchor":1582,"definition":1583},"剩余风险","residual-risk","在应用控制措施或缓解措施后仍然存在的风险。",{"term":1585,"anchor":1586,"definition":1587},"例外","exception","明确、有范围且通常有时间限制的授权，允许偏离正常的治理要求。",{"term":1589,"anchor":1590,"definition":1591},"可审计性","auditability","重建相关决策、配置、证据、身份和执行事件的能力。",{"term":1593,"anchor":1594,"definition":1595},"模型治理","model-governance","涵盖模型选择、版本管理、评估、允许使用、变更和退役的控制和决策。",{"term":1597,"anchor":1598,"definition":1599},"提供商治理","provider-governance","涵盖外部或内部AI提供商依赖关系、数据处理、安全、合同、生命周期和退出的控制。",{"term":1601,"anchor":1602,"definition":1603},"人类监督","human-oversight","在定义的点上为AI决策或行动设计的人类审查或干预能力。",{},{"id":1606,"data":1607,"type":42,"tunes":1609},"h-conclusion",{"text":1608,"level":247},"结论",{},{"id":1611,"data":1612,"type":218,"tunes":1614},"p-conclusion-1",{"text":1613},"AI治理是围绕AI的组织控制平面。它为那些否则会隐藏在代码、提供商设置、提示词或非正式团队判断中的决策赋予名称和证据。",{},{"id":1616,"data":1617,"type":218,"tunes":1619},"p-conclusion-2",{"text":1618},"强有力的治理连接整个系统：业务目的、模型、提供商、数据权限、身份、权限、评估、风险、合规、监控、事件、变更和退役。",{},{"id":1621,"data":1622,"type":218,"tunes":1624},"p-conclusion-3",{"text":1623},"实际目标不是最大化流程。而是最小化的治理结构，使重要的AI决策在整个生命周期中拥有明确的责任归属、基于证据、可执行、可审查和可审计。",{},{"id":1626,"data":1627,"type":42,"tunes":1629},"h-sources",{"text":1628,"level":247},"主要来源和当前参考",{},{"id":1631,"data":1632,"type":218,"tunes":1634},"p-sources-note",{"text":1633},"以下来源为AI管理、风险和监管提供了当前的外部依据。项目部分是原始的实施\u002F项目证据，并明确区别于正式标准或认证的治理体系。",{},{"id":1636,"data":1637,"type":1643,"tunes":1644},"src-nist-rmf",{"link":1638,"meta":1639},"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework",{"image":1640,"title":1641,"description":1642},{"url":355},"NIST — AI风险管理框架","NIST当前关于AI RMF 1.0、正在进行的修订、GenAI配置文件及相关风险管理资源的中心。","linkTool",{},{"id":1646,"data":1647,"type":1643,"tunes":1653},"src-nist-core",{"link":1648,"meta":1649},"https:\u002F\u002Fairc.nist.gov\u002Fairmf-resources\u002Fairmf\u002F5-sec-core\u002F",{"image":1650,"title":1651,"description":1652},{"url":355},"NIST AIRC — AI RMF核心","官方AI RMF核心描述了治理、映射、测量和管理，其中治理是跨生命周期的职能。",{},{"id":1655,"data":1656,"type":1643,"tunes":1662},"src-nist-playbook",{"link":1657,"meta":1658},"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework\u002Fnist-ai-rmf-playbook",{"image":1659,"title":1660,"description":1661},{"url":355},"NIST — AI RMF操作手册","在AI生命周期中实施可信度和风险管理的建议行动。",{},{"id":1664,"data":1665,"type":1643,"tunes":1671},"src-nist-genai",{"link":1666,"meta":1667},"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fartificial-intelligence-risk-management-framework-generative-artificial-intelligence",{"image":1668,"title":1669,"description":1670},{"url":355},"NIST AI 600-1 — 生成式AI配置文件","NIST配套配置文件，将AI RMF概念应用于生成式AI风险和生命周期管理。",{},{"id":1673,"data":1674,"type":1643,"tunes":1680},"src-iso42001",{"link":1675,"meta":1676},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F42001",{"image":1677,"title":1678,"description":1679},{"url":355},"ISO\u002FIEC 42001:2023 — AI管理系统","国际标准，规定了建立、实施、维护和持续改进AI管理系统的要求。",{},{"id":1682,"data":1683,"type":1643,"tunes":1689},"src-iso23894",{"link":1684,"meta":1685},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F77304.html",{"image":1686,"title":1687,"description":1688},{"url":355},"ISO\u002FIEC 23894:2023 — AI风险管理","将AI特定风险管理整合到组织活动和职能中的国际指南。",{},{"id":1691,"data":1692,"type":1643,"tunes":1698},"src-eu-act",{"link":1693,"meta":1694},"https:\u002F\u002Fdigital-strategy.ec.europa.eu\u002Fen\u002Fpolicies\u002Fregulatory-framework-ai",{"image":1695,"title":1696,"description":1697},{"url":355},"欧盟委员会 — AI法案","欧盟委员会当前关于欧盟AI法案、应用时间表和实施框架的概述。",{},{"id":1700,"data":1701,"type":1643,"tunes":1707},"src-eu-faq",{"link":1702,"meta":1703},"https:\u002F\u002Fdigital-strategy.ec.europa.eu\u002Fen\u002Ffaqs\u002Fnavigating-ai-act",{"image":1704,"title":1705,"description":1706},{"url":355},"欧盟委员会 — 导航AI法案","当前常见问题解答，涵盖治理、执法、实施和不断变化的应用时间表。",{},{"id":1709,"data":1710,"type":1643,"tunes":1716},"src-eu-gpai",{"link":1711,"meta":1712},"https:\u002F\u002Fdigital-strategy.ec.europa.eu\u002Fen\u002Ffactpages\u002Fgeneral-purpose-ai-obligations-under-ai-act",{"image":1713,"title":1714,"description":1715},{"url":355},"欧盟委员会 — 通用AI义务","当前关于GPAI提供商的文件、版权、训练内容和系统性风险义务的概述。",{},"2.31","AI治理定义了在模型、提供商、数据、权限、风险、评估及整个生命周期中，谁可以批准、操作、更改和审计AI系统。","\u002Fuploads\u002F2026\u002F10\u002Fai-governance-models-data-permissions-risk-and-auditability-1791485901301-g60xyu.webp","ai-governance-models-data-permissions-risk-and-auditability-1791485901301-g60xyu","PUBLISHED","2026-10-08T14:56:00.000Z","2026-10-08T18:56:36.234Z","2026-10-08T19:08:41.676Z",{"en":1726,"de":1727,"sr":1728,"es":1729,"fr":1730,"it":1731,"ru":1732,"zh":1733},"\u002Fblog\u002Fai-governance-models-data-permissions-risk-and-auditability","\u002Fde\u002Fblog\u002Fai-governance-models-data-permissions-risk-and-auditability","\u002Fsr\u002Fblog\u002Fai-governance-models-data-permissions-risk-and-auditability","\u002Fes\u002Fblog\u002Fai-governance-models-data-permissions-risk-and-auditability","\u002Ffr\u002Fblog\u002Fai-governance-models-data-permissions-risk-and-auditability","\u002Fit\u002Fblog\u002Fai-governance-models-data-permissions-risk-and-auditability","\u002Fru\u002Fblog\u002Fai-governance-models-data-permissions-risk-and-auditability","\u002Fzh\u002Fblog\u002Fai-governance-models-data-permissions-risk-and-auditability",[],{"id":1736,"login":1737,"email":1738,"displayName":1739},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1741,3012],{"lang":1742,"title":1743,"content":1744,"contentJson":1745,"excerpt":3011},"en","AI Governance: Models, Data, Permissions, Risk and Auditability","{\"time\":1791485902655,\"blocks\":[{\"id\":\"intro\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI governance is the system of decision rights, responsibilities, controls and evidence used to decide how an organization may develop, acquire, deploy, operate, change and retire AI systems. It is broader than a policy document and narrower than enterprise architecture as a whole. Effective AI governance connects business ownership, model and provider choices, data authority, permissions, risk classification, evaluation, monitoring, incident handling, auditability and lifecycle decisions so that someone can answer not only “does the AI work?” but also “who approved it, under which conditions, with what evidence, and when must that decision be revisited?”\"},\"tunes\":{}},{\"id\":\"direct\",\"type\":\"callout\",\"data\":{\"variant\":\"info\",\"title\":\"Direct answer\",\"body\":\"\u003Cstrong>AI governance turns AI from an informal technical capability into an accountable organizational capability.\u003C\u002Fstrong>\u003Cbr>\u003Cbr>Architecture determines how the system is built. Engineering implements it. Risk management evaluates uncertainty and harm. Compliance addresses applicable obligations. Governance connects these activities through ownership, decision rights, required controls, evidence and lifecycle gates.\"},\"tunes\":{}},{\"id\":\"boundary\",\"type\":\"callout\",\"data\":{\"variant\":\"warning\",\"title\":\"Governance is not a committee and not a PDF\",\"body\":\"A governance board can be one mechanism, and policies can document expectations, but governance only becomes operational when decisions change what systems are allowed to do: which models may be used, which data may enter them, which tools an agent may execute, which evaluations are required, who can approve exceptions, what must be logged and what triggers suspension or retirement.\"},\"tunes\":{}},{\"id\":\"current\",\"type\":\"callout\",\"data\":{\"variant\":\"note\",\"title\":\"Current-source note — 8 October 2026\",\"body\":\"NIST AI RMF 1.0 remains the current published framework while NIST is revising it. Its core is organized around \u003Cstrong>GOVERN, MAP, MEASURE and MANAGE\u003C\u002Fstrong>, with GOVERN as a cross-cutting function. ISO\u002FIEC 42001:2023 remains the international AI management-system standard for establishing, operating and continually improving an AI management system. The EU AI Act is now generally applicable from 2 August 2026, while some obligations had earlier application dates and some high-risk requirements have later transition dates. Regulatory timelines should always be rechecked before making a concrete compliance decision.\"},\"tunes\":{}},{\"id\":\"toc\",\"type\":\"tableOfContents\",\"data\":{\"title\":\"Contents\",\"minLevel\":2,\"maxLevel\":3},\"tunes\":{}},{\"id\":\"h-meaning\",\"type\":\"header\",\"data\":{\"text\":\"What AI governance really means\",\"level\":2},\"tunes\":{}},{\"id\":\"p-meaning-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI governance answers organizational questions that a model, SDK or architecture diagram cannot answer by itself. Who owns the business outcome? Who may approve a new provider? Which data classes are prohibited from external processing? What evidence is required before deployment? Which permissions may an agent receive? Who can accept residual risk? What happens when a model changes behavior after an upgrade?\"},\"tunes\":{}},{\"id\":\"p-meaning-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The purpose is not to prevent change. Good governance makes change legible: decisions have owners, evidence, conditions, exceptions, review dates and rollback or escalation paths.\"},\"tunes\":{}},{\"id\":\"p-meaning-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"This is why NIST places GOVERN across the entire AI risk-management lifecycle rather than treating governance as one final approval step. Governance establishes the culture, policies, accountability and organizational structures that make mapping, measuring and managing AI risk possible.\"},\"tunes\":{}},{\"id\":\"h-simple\",\"type\":\"header\",\"data\":{\"text\":\"The simplest example\",\"level\":2},\"tunes\":{}},{\"id\":\"p-simple-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A product team wants to add an external generative-AI provider to summarize internal customer-support tickets. Technically, the integration may require only an API call.\"},\"tunes\":{}},{\"id\":\"p-simple-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Governance asks a different set of questions: Are the ticket contents permitted to leave the organization's environment? Which provider and model version are approved? Is retention disabled? Which users may invoke the feature? How is output evaluated? Is human review required? What gets logged? Who owns incidents? What happens if the provider changes its terms or model behavior?\"},\"tunes\":{}},{\"id\":\"p-simple-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The governance result may still be “deploy it.” The difference is that deployment is now a traceable decision with explicit conditions instead of an unrecorded engineering choice.\"},\"tunes\":{}},{\"id\":\"simple-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"A basic governed AI decision\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"1. Register the use case\",\"description\":\"Record purpose, owner, users, data, model\u002Fprovider and intended outcome.\"},{\"label\":\"2. Classify risk and obligations\",\"description\":\"Determine business consequence, data sensitivity, autonomy, regulatory exposure and misuse potential.\"},{\"label\":\"3. Define required controls\",\"description\":\"Specify permissions, data handling, evaluations, human oversight, security, logging and provider constraints.\"},{\"label\":\"4. Collect evidence\",\"description\":\"Run tests, security\u002Fprivacy review, architecture review and relevant legal\u002Fcompliance checks.\"},{\"label\":\"5. Make a decision\",\"description\":\"Approve, approve with conditions, request changes, hold or reject.\"},{\"label\":\"6. Deploy under controlled configuration\",\"description\":\"Pin the approved model\u002Fprovider\u002Fruntime and enforce required boundaries.\"},{\"label\":\"7. Monitor and re-evaluate\",\"description\":\"Track incidents, quality, drift, provider changes, new risks and changed regulations.\"},{\"label\":\"8. Change, suspend or retire\",\"description\":\"Use evidence and ownership rules to decide the next lifecycle state.\"}]},\"tunes\":{}},{\"id\":\"h-stops\",\"type\":\"header\",\"data\":{\"text\":\"Where the simple example stops\",\"level\":2},\"tunes\":{}},{\"id\":\"p-stops-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Large organizations rarely govern one AI system in isolation. The same model may support dozens of products; one provider may process several data classes; an agent platform may expose shared tools to many teams.\"},\"tunes\":{}},{\"id\":\"p-stops-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Governance therefore needs portfolio-level structures as well as system-level controls: AI inventory, approved providers, model catalogs, shared evaluation baselines, security patterns, risk thresholds, exception registers and ownership mappings.\"},\"tunes\":{}},{\"id\":\"p-stops-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Governance also cannot be identical for every AI use. A public-content summarizer, an internal coding assistant, a hiring-support system and an agent that can initiate payments have materially different consequence and control profiles.\"},\"tunes\":{}},{\"id\":\"h-not\",\"type\":\"header\",\"data\":{\"text\":\"What AI governance is — and what it is not\",\"level\":2},\"tunes\":{}},{\"id\":\"not-comparison\",\"type\":\"comparison\",\"data\":{\"title\":\"AI governance compared with adjacent disciplines\",\"layout\":\"table\",\"columns\":[{\"id\":\"governance\",\"label\":\"AI governance\"},{\"id\":\"adjacent\",\"label\":\"Adjacent discipline\"}],\"rows\":[{\"id\":\"architecture\",\"label\":\"Enterprise \u002F solution architecture\",\"values\":[\"\",\"\"]},{\"id\":\"risk\",\"label\":\"AI risk management\",\"values\":[\"\",\"\"]},{\"id\":\"compliance\",\"label\":\"Compliance\",\"values\":[\"\",\"\"]},{\"id\":\"security\",\"label\":\"Security\",\"values\":[\"\",\"\"]},{\"id\":\"mlops\",\"label\":\"MLOps \u002F LLMOps\",\"values\":[\"\",\"\"]},{\"id\":\"ethics\",\"label\":\"AI ethics principles\",\"values\":[\"\",\"\"]}]},\"tunes\":{}},{\"id\":\"h-governance-compliance\",\"type\":\"header\",\"data\":{\"text\":\"Governance is broader than compliance\",\"level\":2},\"tunes\":{}},{\"id\":\"p-compliance-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Compliance is one input to governance, not the entire governance system. An AI use case can be legally permitted yet still violate company risk appetite, security policy, contractual obligations or product-quality requirements.\"},\"tunes\":{}},{\"id\":\"p-compliance-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The reverse also matters: internal approval does not override law. Governance should make applicable legal obligations visible inside the same decision path used for architecture, security and business risk.\"},\"tunes\":{}},{\"id\":\"p-compliance-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"ISO\u002FIEC 42001 explicitly frames an AI management system as a structured way to establish policies, objectives and processes for responsible AI. ISO also states that the standard does not replace laws or regulations; it provides a management framework that can support compliance.\"},\"tunes\":{}},{\"id\":\"h-frameworks\",\"type\":\"header\",\"data\":{\"text\":\"NIST AI RMF and ISO\u002FIEC 42001 solve different governance needs\",\"level\":2},\"tunes\":{}},{\"id\":\"framework-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Framework \u002F standard\",\"Primary role\",\"Useful governance value\"],[\"NIST AI RMF 1.0\",\"Voluntary AI risk-management framework\",\"Organizes outcomes around GOVERN, MAP, MEASURE and MANAGE across the lifecycle\"],[\"NIST AI 600-1\",\"Generative-AI profile for AI RMF\",\"Adds GenAI-specific risk considerations and actions\"],[\"ISO\u002FIEC 42001:2023\",\"AI management-system requirements\",\"Creates an organization-wide management system with policy, roles, processes and continual improvement\"],[\"ISO\u002FIEC 23894:2023\",\"AI risk-management guidance\",\"Guides integration of AI-specific risk management into organizational activities\"],[\"EU AI Act\",\"Binding regulation in the EU\",\"Creates legal obligations according to actor, AI category and use case\"]]},\"tunes\":{}},{\"id\":\"p-framework-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"These sources should not be collapsed into one checklist. NIST AI RMF is risk-management guidance. ISO\u002FIEC 42001 is a management-system standard. The EU AI Act is law. An organization can use them together, but their authority, scope and implementation purpose are different.\"},\"tunes\":{}},{\"id\":\"h-current-eu\",\"type\":\"header\",\"data\":{\"text\":\"Current EU AI Act timing matters\",\"level\":2},\"tunes\":{}},{\"id\":\"p-eu-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"As of 8 October 2026, the European Commission states that the AI Act became generally applicable on 2 August 2026. Prohibited-practice and AI-literacy provisions applied from 2 February 2025, while governance rules and obligations for general-purpose AI models applied from 2 August 2025.\"},\"tunes\":{}},{\"id\":\"p-eu-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The Commission's current guidance also reflects later application dates for certain high-risk requirements. Exact dates and transition rules are a moving compliance input and should be verified against current Commission material before a deployment decision.\"},\"tunes\":{}},{\"id\":\"eu-boundary\",\"type\":\"callout\",\"data\":{\"variant\":\"warning\",\"title\":\"Architecture article, not legal advice\",\"body\":\"The regulatory examples here explain why governance needs versioned legal\u002Fcompliance inputs. They do not determine whether a specific product is legally classified as prohibited, high-risk, GPAI, deployer, provider or another regulated actor.\"},\"tunes\":{}},{\"id\":\"h-inventory\",\"type\":\"header\",\"data\":{\"text\":\"AI governance starts with an inventory\",\"level\":2},\"tunes\":{}},{\"id\":\"p-inventory-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"An organization cannot govern AI systems it cannot identify. The inventory should cover more than custom-trained models. It may include external model APIs, embedded copilots, local models, AI-enabled SaaS features, agent runtimes, retrieval systems and automated decision components.\"},\"tunes\":{}},{\"id\":\"p-inventory-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"A useful inventory connects the AI capability to its business owner, technical owner, use case, users, data classes, model\u002Fprovider, deployment environment, permissions, risk classification, evaluation status, applicable obligations and lifecycle state.\"},\"tunes\":{}},{\"id\":\"p-inventory-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The inventory is not only a spreadsheet for auditors. It is the index that lets the organization know what must be reviewed when a provider changes, a vulnerability appears, a regulation becomes applicable or a model is retired.\"},\"tunes\":{}},{\"id\":\"inventory-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Inventory field\",\"Why governance needs it\"],[\"Use case \u002F purpose\",\"Defines why AI exists and what success means\"],[\"Business owner\",\"Owns outcome and business risk\"],[\"Technical owner\",\"Owns architecture, implementation and operation\"],[\"Model + version\",\"Identifies the behavior-producing dependency\"],[\"Provider \u002F runtime\",\"Identifies contractual, hosting and operational dependency\"],[\"Data classes\",\"Determines privacy, confidentiality and Source-of-Truth constraints\"],[\"Users \u002F affected parties\",\"Determines exposure and human-impact context\"],[\"Tools \u002F actions\",\"Determines autonomy and side-effect risk\"],[\"Permissions \u002F identity\",\"Defines who or what may invoke the capability\"],[\"Risk classification\",\"Determines required controls and approval path\"],[\"Evaluation evidence\",\"Shows whether intended behavior was tested\"],[\"Lifecycle state\",\"Draft, review, approved, restricted, suspended or retired\"],[\"Review date \u002F triggers\",\"Defines when the governance decision must be revisited\"]]},\"tunes\":{}},{\"id\":\"h-ownership\",\"type\":\"header\",\"data\":{\"text\":\"Governance requires named ownership\",\"level\":2},\"tunes\":{}},{\"id\":\"p-own-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI failures often cross organizational boundaries. A model-quality problem may become a product failure, security issue, privacy incident or contractual breach. Governance needs named owners before the incident occurs.\"},\"tunes\":{}},{\"id\":\"p-own-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Ownership does not mean one person is responsible for everything. A strong model separates decision rights: business owner, product owner, technical owner, data owner, security\u002Fprivacy specialists, legal\u002Fcompliance actors and operational support.\"},\"tunes\":{}},{\"id\":\"p-own-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The critical property is that every required decision has an owner and every owner knows which evidence they are expected to review.\"},\"tunes\":{}},{\"id\":\"h-decision-rights\",\"type\":\"header\",\"data\":{\"text\":\"Decision rights should be explicit\",\"level\":2},\"tunes\":{}},{\"id\":\"decision-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Decision\",\"Typical accountable function\"],[\"May this AI use case exist?\",\"Business\u002Fproduct owner with governance\u002Frisk input\"],[\"May this data class be processed?\",\"Data owner + privacy\u002Fsecurity according to policy\"],[\"May this provider\u002Fmodel be used?\",\"Architecture\u002Fplatform + security\u002Fprocurement + governance\"],[\"May this agent execute this action?\",\"Application owner + authorization\u002Fbusiness-policy owner\"],[\"Is quality sufficient for deployment?\",\"Product\u002Ftechnical owner against defined acceptance criteria\"],[\"Can residual risk be accepted?\",\"Named risk owner at appropriate authority level\"],[\"Can an exception be granted?\",\"Explicit exception authority, time-bounded and documented\"],[\"Should the system be suspended?\",\"Operational\u002Fbusiness owner under incident or risk triggers\"],[\"Can a model upgrade go live?\",\"Change owner after regression\u002Fevaluation evidence\"]]},\"tunes\":{}},{\"id\":\"h-model\",\"type\":\"header\",\"data\":{\"text\":\"Model governance is more than choosing a model\",\"level\":2},\"tunes\":{}},{\"id\":\"p-model-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Model governance tracks which model is used, for what purpose, under which configuration and evidence. This applies to external APIs, locally hosted models, fine-tuned models and models embedded in third-party software.\"},\"tunes\":{}},{\"id\":\"p-model-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"A model decision should consider capability, evaluation results, cost, latency, data handling, provider terms, lifecycle support, geographic\u002Fhosting constraints, security, fallback behavior and the consequences of version change.\"},\"tunes\":{}},{\"id\":\"p-model-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Model aliases such as “latest” can be operationally convenient but weaken reproducibility if behavior changes without a governed release process. Consequential systems benefit from explicit version tracking and regression evaluation.\"},\"tunes\":{}},{\"id\":\"h-provider\",\"type\":\"header\",\"data\":{\"text\":\"Provider governance is a separate dependency layer\",\"level\":2},\"tunes\":{}},{\"id\":\"p-provider-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Two systems using the same model family can have different governance risk if one runs locally and another sends data to an external provider. Provider governance covers contractual terms, processing location, retention, logging, sub-processors, availability, deprecation and exit strategy.\"},\"tunes\":{}},{\"id\":\"p-provider-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Provider abstraction can reduce technical lock-in, but it does not remove governance work. Swapping providers can change data flows, model behavior, security assumptions, cost and compliance obligations.\"},\"tunes\":{}},{\"id\":\"p-provider-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"An approved provider list should therefore not be interpreted as “every model and every data class from this provider is automatically approved.” Approval needs scope.\"},\"tunes\":{}},{\"id\":\"h-data\",\"type\":\"header\",\"data\":{\"text\":\"Data governance remains the Source-of-Truth layer\",\"level\":2},\"tunes\":{}},{\"id\":\"p-data-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI governance does not make the model the authority for organizational facts. Data governance still determines ownership, classification, retention, quality and permitted use of source data.\"},\"tunes\":{}},{\"id\":\"p-data-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"For RAG and agents, governance should identify which sources are authoritative, which are advisory, how provenance is preserved, which data may enter model context and which tenant\u002Fuser boundaries must be enforced.\"},\"tunes\":{}},{\"id\":\"p-data-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Generated outputs create new data-governance questions as well: whether prompts and responses are retained, who may access traces, whether generated summaries become records and how derived embeddings or indexes are deleted when source data is removed.\"},\"tunes\":{}},{\"id\":\"h-permissions\",\"type\":\"header\",\"data\":{\"text\":\"Permissions are governance decisions with runtime enforcement\",\"level\":2},\"tunes\":{}},{\"id\":\"p-perm-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Agentic AI makes permissions a first-class governance object. The organization needs to decide which tools, files, APIs, databases and side effects each agent or user may access.\"},\"tunes\":{}},{\"id\":\"p-perm-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Governance defines the policy and approval logic; the trusted runtime enforces it. Natural-language instructions such as “do not delete files” are not a substitute for filesystem, API or service authorization.\"},\"tunes\":{}},{\"id\":\"p-perm-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The same principle applies to tenant isolation: a role can authorize an operation while tenant scope constrains which customer's resources that operation may reach.\"},\"tunes\":{}},{\"id\":\"h-risk\",\"type\":\"header\",\"data\":{\"text\":\"Risk classification should change the control set\",\"level\":2},\"tunes\":{}},{\"id\":\"p-risk-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Not every AI system needs the same review depth. Governance becomes scalable when risk classification changes the evidence, approval and monitoring requirements.\"},\"tunes\":{}},{\"id\":\"risk-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Risk driver\",\"Lower-control example\",\"Higher-control example\"],[\"Business consequence\",\"Draft internal text\",\"Approve financial settlement\"],[\"Human impact\",\"Optional writing aid\",\"Employment or eligibility decision support\"],[\"Data sensitivity\",\"Public documentation\",\"Health, HR, financial or confidential data\"],[\"Autonomy\",\"Read-only recommendation\",\"Agent with write\u002Fpayment\u002Fdeployment tools\"],[\"Reversibility\",\"Easily regenerated summary\",\"Irreversible external transaction\"],[\"Exposure\",\"Small internal pilot\",\"Public\u002Fcustomer-facing system at scale\"],[\"Source authority\",\"Advisory content\",\"System relied on for regulated or contractual fact\"],[\"Failure detectability\",\"Obvious formatting defect\",\"Plausible but materially wrong recommendation\"]]},\"tunes\":{}},{\"id\":\"p-risk-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The classification method can be simple or sophisticated, but it should map to concrete consequences: more testing, narrower permissions, required human oversight, security review, executive risk acceptance or deployment prohibition.\"},\"tunes\":{}},{\"id\":\"h-map\",\"type\":\"header\",\"data\":{\"text\":\"Governance must preserve use-case context\",\"level\":2},\"tunes\":{}},{\"id\":\"p-map-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"NIST's MAP function emphasizes intended purpose, users, deployment context, assumptions, impacts and applicable laws or norms. This matters because the same model can be low risk in one use case and high consequence in another.\"},\"tunes\":{}},{\"id\":\"p-map-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Governance records should therefore classify the application, not only the model. “We use model X” is not enough to determine risk.\"},\"tunes\":{}},{\"id\":\"p-map-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The relevant governance object is the system\u002Fuse case: model + data + context + tools + users + deployment environment + business process.\"},\"tunes\":{}},{\"id\":\"h-evaluation\",\"type\":\"header\",\"data\":{\"text\":\"Evaluation is governance evidence\",\"level\":2},\"tunes\":{}},{\"id\":\"p-eval-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"An AI governance process should not approve deployment based only on vendor benchmarks or a successful demo. The system needs evidence tied to its actual intended use.\"},\"tunes\":{}},{\"id\":\"p-eval-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Useful evidence can include task-success evaluation, retrieval quality, factual grounding, security tests, permission tests, adversarial scenarios, human-review studies, latency\u002Fcost, robustness and regression comparisons.\"},\"tunes\":{}},{\"id\":\"p-eval-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"NIST's MEASURE function makes this explicit: organizations should identify and apply appropriate methods and metrics for risks identified during mapping, while documenting risks that cannot or will not be measured.\"},\"tunes\":{}},{\"id\":\"eval-boundary\",\"type\":\"callout\",\"data\":{\"variant\":\"success\",\"title\":\"A governance gate should ask for evidence, not confidence\",\"body\":\"“The team thinks the model is good enough” is a weak approval artifact. “The system met defined acceptance criteria on representative tests, with these known limitations and residual risks” is governable.\"},\"tunes\":{}},{\"id\":\"h-gates\",\"type\":\"header\",\"data\":{\"text\":\"Governance gates should exist across the lifecycle\",\"level\":2},\"tunes\":{}},{\"id\":\"gate-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"Example lifecycle gates\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"Idea \u002F discovery gate\",\"description\":\"Confirm business purpose, owner and whether AI is an appropriate solution.\"},{\"label\":\"Architecture gate\",\"description\":\"Review model\u002Fprovider, data flow, identity, permissions, isolation and operational design.\"},{\"label\":\"Risk\u002Fcompliance gate\",\"description\":\"Classify risk and applicable obligations; define required controls.\"},{\"label\":\"Validation gate\",\"description\":\"Require evidence that functional, safety, security and quality criteria are met.\"},{\"label\":\"Deployment gate\",\"description\":\"Approve concrete configuration, version, environment and operational owner.\"},{\"label\":\"Change gate\",\"description\":\"Re-evaluate model\u002Fprovider\u002Ftool\u002Fdata changes according to materiality.\"},{\"label\":\"Incident gate\",\"description\":\"Pause, restrict or roll back when defined risk triggers occur.\"},{\"label\":\"Retirement gate\",\"description\":\"Remove access, data derivatives, credentials and obsolete dependencies cleanly.\"}]},\"tunes\":{}},{\"id\":\"h-change\",\"type\":\"header\",\"data\":{\"text\":\"Change management is central to AI governance\",\"level\":2},\"tunes\":{}},{\"id\":\"p-change-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI systems change even when application code does not. Providers update models, safety filters, context limits, pricing, policies and infrastructure. Retrieval corpora change. Agent tools gain permissions. Regulations and contracts evolve.\"},\"tunes\":{}},{\"id\":\"p-change-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Governance should therefore define material-change triggers. A minor prompt wording adjustment may need ordinary regression tests; replacing the model, enabling write tools or introducing sensitive data may require a new approval gate.\"},\"tunes\":{}},{\"id\":\"p-change-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The governance record should preserve which version was approved and what conditions made the approval valid.\"},\"tunes\":{}},{\"id\":\"h-exceptions\",\"type\":\"header\",\"data\":{\"text\":\"Exceptions need owners, expiry and compensating controls\",\"level\":2},\"tunes\":{}},{\"id\":\"p-exc-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Real organizations need exceptions. A team may need an unapproved model for a time-bounded experiment, or a legacy system may not yet meet a new logging requirement.\"},\"tunes\":{}},{\"id\":\"p-exc-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The dangerous pattern is a permanent undocumented exception. Governable exceptions specify owner, rationale, scope, residual risk, compensating control, expiration date and review condition.\"},\"tunes\":{}},{\"id\":\"p-exc-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Exception handling should be part of the normal governance system rather than an informal side channel.\"},\"tunes\":{}},{\"id\":\"h-audit\",\"type\":\"header\",\"data\":{\"text\":\"Auditability is the ability to reconstruct the decision and execution\",\"level\":2},\"tunes\":{}},{\"id\":\"p-audit-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI auditability is not merely storing model prompts. It means being able to reconstruct which system version was used, which data and permissions applied, who approved the configuration, what evaluations supported deployment and what happened during relevant execution.\"},\"tunes\":{}},{\"id\":\"p-audit-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"For an agent, this may require principal identity, tool calls, approvals, target resources, state changes and outcomes. For RAG, it may require corpus\u002Findex version, retrieval query, selected evidence and provenance. For a model change, it may require the previous and new evaluation results.\"},\"tunes\":{}},{\"id\":\"p-audit-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Audit evidence should be proportionate. Logging every possible token can create privacy and security risk of its own. Governance should define which evidence is necessary, how long it is retained and who may access it.\"},\"tunes\":{}},{\"id\":\"audit-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Audit object\",\"Useful evidence\"],[\"Governance decision\",\"Owner, date, decision, conditions, evidence, exceptions\"],[\"Model release\",\"Model\u002Fprovider\u002Fversion, configuration, regression results\"],[\"Data access\",\"Principal, tenant\u002Fscope, source class, policy decision\"],[\"Agent action\",\"Tool, arguments\u002Ftarget, approval, result, state change\"],[\"RAG answer\",\"Corpus\u002Findex version, retrieval set, selected evidence, citations\"],[\"Incident\",\"Trigger, affected systems, containment, decision owner, remediation\"],[\"Retirement\",\"Disabled endpoints, revoked credentials, deleted derived data, archive decision\"]]},\"tunes\":{}},{\"id\":\"h-observability\",\"type\":\"header\",\"data\":{\"text\":\"Monitoring closes the governance loop\",\"level\":2},\"tunes\":{}},{\"id\":\"p-monitor-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Approval is a snapshot. Production monitoring tells governance whether the assumptions behind approval still hold.\"},\"tunes\":{}},{\"id\":\"p-monitor-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Useful signals depend on the use case: quality regression, unsafe outputs, tool failures, policy denials, unusual cost, latency, user complaints, drift, retrieval freshness, provider incidents, security alerts or new regulatory classifications.\"},\"tunes\":{}},{\"id\":\"p-monitor-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Governance should define thresholds that cause action: investigate, restrict, require human review, roll back, switch provider, suspend or retire.\"},\"tunes\":{}},{\"id\":\"h-incidents\",\"type\":\"header\",\"data\":{\"text\":\"AI incidents need a defined operational path\",\"level\":2},\"tunes\":{}},{\"id\":\"p-inc-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI-specific incidents may involve harmful content, data leakage, unauthorized actions, persistent factual failure, model\u002Fprovider outage, prompt injection, cross-tenant retrieval or unexpected behavior after a model update.\"},\"tunes\":{}},{\"id\":\"p-inc-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The incident process should connect technical response with governance ownership. Someone must be authorized to disable a model, remove a tool, revoke credentials, restrict users, notify affected functions and decide whether the system may return to service.\"},\"tunes\":{}},{\"id\":\"p-inc-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The lessons from incidents should update policies, tests, risk classification and reusable platform controls rather than remain isolated in one team.\"},\"tunes\":{}},{\"id\":\"h-procurement\",\"type\":\"header\",\"data\":{\"text\":\"Procurement is part of AI governance\",\"level\":2},\"tunes\":{}},{\"id\":\"p-proc-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Organizations can acquire substantial AI capability through ordinary SaaS procurement. Governance should therefore cover purchased AI features as well as internally engineered systems.\"},\"tunes\":{}},{\"id\":\"p-proc-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Vendor review can include data use, retention, model training policy, sub-processors, security, incident notification, export\u002Fdeletion, geographic processing, version change, service continuity and contractual exit.\"},\"tunes\":{}},{\"id\":\"p-proc-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"A technical architecture review and procurement review should share the same system inventory so commercial approval does not drift away from the actual deployed data flow.\"},\"tunes\":{}},{\"id\":\"h-human\",\"type\":\"header\",\"data\":{\"text\":\"Human oversight should be designed, not merely declared\",\"level\":2},\"tunes\":{}},{\"id\":\"p-human-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"“Human in the loop” is meaningful only if the human has authority, time, information and a usable intervention mechanism.\"},\"tunes\":{}},{\"id\":\"p-human-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"A reviewer who sees only the AI recommendation but not its evidence, uncertainty or source state may simply rubber-stamp the output. Governance should specify what the reviewer can inspect and what actions are available: approve, reject, edit, escalate or stop.\"},\"tunes\":{}},{\"id\":\"p-human-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Human oversight should also be risk-based. Low-consequence systems may use sampling or post-hoc review, while high-consequence side effects may require approval before execution.\"},\"tunes\":{}},{\"id\":\"h-platform\",\"type\":\"header\",\"data\":{\"text\":\"Platform governance and use-case governance are different\",\"level\":2},\"tunes\":{}},{\"id\":\"platform-comparison\",\"type\":\"comparison\",\"data\":{\"title\":\"Two governance levels\",\"layout\":\"table\",\"columns\":[{\"id\":\"platform\",\"label\":\"Shared AI platform\"},{\"id\":\"usecase\",\"label\":\"Individual AI use case\"}],\"rows\":[{\"id\":\"owner\",\"label\":\"Primary concern\",\"values\":[\"\",\"\"]},{\"id\":\"approval\",\"label\":\"Typical approval\",\"values\":[\"\",\"\"]},{\"id\":\"evidence\",\"label\":\"Evidence\",\"values\":[\"\",\"\"]},{\"id\":\"failure\",\"label\":\"Governance failure\",\"values\":[\"\",\"\"]}]},\"tunes\":{}},{\"id\":\"p-platform-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Platform approval should therefore reduce repeated work, not eliminate use-case accountability. “The model is approved” is different from “this application of the model is approved.”\"},\"tunes\":{}},{\"id\":\"h-architecture\",\"type\":\"header\",\"data\":{\"text\":\"AI governance and Enterprise AI Architecture\",\"level\":2},\"tunes\":{}},{\"id\":\"p-arch-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Enterprise AI Architecture describes how AI systems, platforms, data, identities, providers, operations and organizational systems fit together. AI governance describes the decision and control system that determines how those architectures may be created and changed.\"},\"tunes\":{}},{\"id\":\"p-arch-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The two are tightly coupled. Governance without architecture can become abstract policy. Architecture without governance can produce technically elegant systems with unclear ownership, uncontrolled provider adoption or unreviewed risk.\"},\"tunes\":{}},{\"id\":\"p-arch-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The strongest design is bidirectional: governance requirements become architecture controls, while architecture exposes the real decisions that governance must own.\"},\"tunes\":{}},{\"id\":\"h-implementation\",\"type\":\"header\",\"data\":{\"text\":\"Original project evidence\",\"level\":2},\"tunes\":{}},{\"id\":\"h-enterprise\",\"type\":\"header\",\"data\":{\"text\":\"Enterprise Aaasaasa 0.1: governance as delivery structure\",\"level\":3},\"tunes\":{}},{\"id\":\"enterprise-note\",\"type\":\"callout\",\"data\":{\"variant\":\"note\",\"title\":\"Project \u002F PoC evidence\",\"body\":\"Enterprise Aaasaasa 0.1 is project and training\u002FPoC evidence, not evidence of commercial enterprise adoption. It is useful here because its delivery structure explicitly connects architecture, milestones, risks, stakeholders, validation and project decisions.\"},\"tunes\":{}},{\"id\":\"p-ent-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Enterprise Aaasaasa 0.1 uses defined milestones for requirements, architecture, prototype, validation and project closure. That structure illustrates a core governance principle: lifecycle transitions should have explicit outputs and decision points instead of an informal “build first, review later” process.\"},\"tunes\":{}},{\"id\":\"p-ent-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The project also tracks risks such as scope creep, architecture delay and AI\u002FGDPR concerns and identifies stakeholder groups including sponsorship, steering, architecture, security, marketing, external APIs and hosting.\"},\"tunes\":{}},{\"id\":\"p-ent-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"This does not constitute an ISO\u002FIEC 42001 management system. It is narrower project evidence showing how ownership, risk, milestones and validation can be integrated into technical delivery.\"},\"tunes\":{}},{\"id\":\"h-senseflow\",\"type\":\"header\",\"data\":{\"text\":\"SenseFlow: requirements and decision traceability\",\"level\":3},\"tunes\":{}},{\"id\":\"p-sense-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"SenseFlow uses a structured path from product goal and user need through epics, user stories, acceptance criteria, architecture, implementation and validation. Decision records preserve the decision, rationale, alternatives, trade-offs, status and date\u002Fversion.\"},\"tunes\":{}},{\"id\":\"p-sense-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"That traceability pattern is directly relevant to governance because an AI control should connect to the requirement or risk that justified it. A governance system becomes stronger when the chain from business need to architecture decision to validation evidence can be reconstructed.\"},\"tunes\":{}},{\"id\":\"h-client\",\"type\":\"header\",\"data\":{\"text\":\"Aaasaasa AI Client: permissions and runtime as governed configuration\",\"level\":3},\"tunes\":{}},{\"id\":\"p-client-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Aaasaasa AI Client separates provider, model, runtime location and permissions rather than treating them as one “AI setting.” Central workspace permission profiles govern tool access, Direct Chat has no filesystem\u002Fshell tools, and agent-capable runtimes operate under explicit permission profiles.\"},\"tunes\":{}},{\"id\":\"p-client-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"That separation demonstrates an important governance pattern: model choice and action authority should be independent configuration objects. A stronger model does not automatically receive broader filesystem, shell or business permissions.\"},\"tunes\":{}},{\"id\":\"p-client-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The implementation evidence is architectural, not a claim that the application constitutes a certified organizational AI governance system.\"},\"tunes\":{}},{\"id\":\"impl-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Observed project pattern\",\"Governance lesson\"],[\"Milestone gates\",\"Lifecycle transitions can require explicit evidence\"],[\"Risk register\",\"Known uncertainties become managed objects rather than informal concerns\"],[\"Stakeholder mapping\",\"Decision responsibility can be distributed deliberately\"],[\"Acceptance criteria + validation\",\"Deployment decisions can depend on evidence\"],[\"Decision records\",\"Architecture trade-offs remain traceable\"],[\"Separate model\u002Fprovider\u002Fruntime\u002Fpermissions\",\"Capability and authority can be governed independently\"],[\"Explicit project maturity labels\",\"PoC evidence is not misrepresented as production or market proof\"]]},\"tunes\":{}},{\"id\":\"h-failures\",\"type\":\"header\",\"data\":{\"text\":\"Common AI governance failure modes\",\"level\":2},\"tunes\":{}},{\"id\":\"failures-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Failure mode\",\"What goes wrong\"],[\"Governance is only a policy PDF\",\"Teams cannot translate policy into runtime controls or deployment decisions\"],[\"No AI inventory\",\"The organization cannot identify where models, agents or embedded AI are used\"],[\"Model approval is treated as use-case approval\",\"An approved model is used for a materially different risk context\"],[\"No named business owner\",\"Technical teams inherit business-risk decisions by default\"],[\"Risk classification has no control consequence\",\"Every system receives the same review regardless of consequence\"],[\"Permissions live only in prompts\",\"Model instructions become a substitute for real authorization\"],[\"Provider change is invisible\",\"Behavior\u002Fdata\u002Fcompliance assumptions change without re-evaluation\"],[\"Demo success is approval evidence\",\"Production risk is inferred from a small happy-path test\"],[\"Human oversight is ceremonial\",\"Reviewer cannot inspect evidence or stop the action\"],[\"Exception has no expiry\",\"Temporary workaround becomes permanent governance debt\"],[\"Logs exist but cannot reconstruct decisions\",\"Auditability is confused with raw data retention\"],[\"Compliance owns governance alone\",\"Product, engineering, security and operations disengage from accountability\"],[\"Every decision goes to a central board\",\"Governance becomes a bottleneck instead of a scalable control system\"]]},\"tunes\":{}},{\"id\":\"h-federated\",\"type\":\"header\",\"data\":{\"text\":\"Central governance does not mean centralizing every decision\",\"level\":2},\"tunes\":{}},{\"id\":\"p-fed-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A mature organization can centralize policy, control patterns and escalation while delegating low-risk decisions to product or platform teams.\"},\"tunes\":{}},{\"id\":\"p-fed-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"This federated model scales better than requiring a central committee to approve every prompt change. The central function defines risk tiers, mandatory controls, provider policy, exception authority and audit requirements; teams operate autonomously inside those boundaries.\"},\"tunes\":{}},{\"id\":\"p-fed-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The design objective is consistent accountability, not maximum centralization.\"},\"tunes\":{}},{\"id\":\"h-metrics\",\"type\":\"header\",\"data\":{\"text\":\"Govern the governance system itself\",\"level\":2},\"tunes\":{}},{\"id\":\"p-metric-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Governance needs feedback. Otherwise controls can become expensive rituals that do not reduce risk.\"},\"tunes\":{}},{\"id\":\"metrics-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Metric \u002F signal\",\"What it can reveal\"],[\"Inventory coverage\",\"Whether AI adoption is visible to governance\"],[\"Time to decision\",\"Whether governance blocks delivery unnecessarily\"],[\"Exception count and age\",\"Whether policies are realistic or routinely bypassed\"],[\"Evaluation failure rate\",\"Whether pre-deployment controls catch defects\"],[\"Post-deployment incident rate\",\"Whether approval evidence predicts production behavior\"],[\"Unauthorized-tool denial rate\",\"Whether permission boundaries are actively exercised\"],[\"Model\u002Fprovider change frequency\",\"How often approved assumptions may become stale\"],[\"Retired-but-active systems\",\"Lifecycle cleanup\u002Fcontrol failure\"],[\"Repeated incident patterns\",\"Whether lessons are becoming reusable platform controls\"]]},\"tunes\":{}},{\"id\":\"p-metric-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Governance metrics should not reward paperwork volume. The useful measure is whether decision quality, traceability, risk detection and safe delivery improve.\"},\"tunes\":{}},{\"id\":\"h-sequence\",\"type\":\"header\",\"data\":{\"text\":\"A practical AI governance implementation sequence\",\"level\":2},\"tunes\":{}},{\"id\":\"design-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"Build governance from visibility to control\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"1. Define governance scope\",\"description\":\"Decide which internally built, purchased, embedded and experimental AI systems are covered.\"},{\"label\":\"2. Create the AI inventory\",\"description\":\"Capture owners, use cases, models\u002Fproviders, data, tools, users, lifecycle state and risk class.\"},{\"label\":\"3. Define decision rights\",\"description\":\"Name who can approve providers, data use, risk acceptance, exceptions, deployment and retirement.\"},{\"label\":\"4. Establish risk tiers\",\"description\":\"Map consequence and exposure to different control requirements.\"},{\"label\":\"5. Define reusable minimum controls\",\"description\":\"Set baseline requirements for identity, permissions, data, security, evaluation, logging and human oversight.\"},{\"label\":\"6. Connect governance to architecture\",\"description\":\"Turn policy into platform\u002Fruntime controls that teams cannot accidentally bypass.\"},{\"label\":\"7. Build evidence-based gates\",\"description\":\"Require relevant evaluation, security, privacy, architecture and compliance evidence before lifecycle transitions.\"},{\"label\":\"8. Govern model\u002Fprovider change\",\"description\":\"Track versions, deprecations and material changes with regression evidence.\"},{\"label\":\"9. Add monitoring and incident triggers\",\"description\":\"Define which production signals force investigation, restriction or suspension.\"},{\"label\":\"10. Formalize exceptions\",\"description\":\"Require scope, owner, residual risk, compensating controls and expiry.\"},{\"label\":\"11. Audit decisions and execution\",\"description\":\"Retain proportionate evidence that links owners, configuration, permissions, evaluations and significant actions.\"},{\"label\":\"12. Improve the governance system\",\"description\":\"Use incidents, delays and repeated exceptions to revise controls and platform patterns.\"}]},\"tunes\":{}},{\"id\":\"h-checklist\",\"type\":\"header\",\"data\":{\"text\":\"AI governance checklist\",\"level\":2},\"tunes\":{}},{\"id\":\"checklist-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Question\",\"Expected governance evidence\"],[\"Why does this AI system exist?\",\"Purpose, business owner and intended outcome\"],[\"Who owns technical operation?\",\"Named technical\u002Fplatform owner\"],[\"Which model\u002Fprovider\u002Fversion is used?\",\"Registered and versioned dependency\"],[\"Which data may enter the system?\",\"Classification, authority and permitted-use decision\"],[\"Which identities may use it?\",\"Authentication and authorization model\"],[\"Which actions may it perform?\",\"Tool\u002Fpermission matrix and autonomy boundary\"],[\"What is the risk tier?\",\"Documented classification with rationale\"],[\"Which controls are mandatory?\",\"Risk-tier control baseline\"],[\"How was it evaluated?\",\"Representative tests and acceptance criteria\"],[\"Who accepted residual risk?\",\"Named accountable authority\"],[\"What requires human review?\",\"Explicit oversight\u002Fapproval rules\"],[\"What gets logged?\",\"Audit\u002Fobservability policy proportional to consequence\"],[\"What triggers re-review?\",\"Model\u002Fprovider\u002Fdata\u002Ftool\u002Fregulatory\u002Fmaterial-change events\"],[\"How can it be suspended?\",\"Operational kill\u002Frestriction path and owner\"],[\"How is it retired?\",\"Credential, data, derivative, endpoint and record cleanup\"]]},\"tunes\":{}},{\"id\":\"h-misconceptions\",\"type\":\"header\",\"data\":{\"text\":\"Common misconceptions\",\"level\":2},\"tunes\":{}},{\"id\":\"misconceptions-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Misconception\",\"Correction\"],[\"“AI governance is compliance.”\",\"Compliance is one governance input; governance also covers ownership, architecture, permissions, quality, risk and lifecycle decisions.\"],[\"“Governance means a review committee.”\",\"Committees can approve exceptions or high-risk systems, but many controls should be embedded in normal delivery and platform architecture.\"],[\"“An approved model is safe for every use.”\",\"Risk belongs to the use case and system context, not only the model.\"],[\"“A vendor handles governance for us.”\",\"A provider controls part of the stack; the organization still owns its use case, data, permissions and business consequences.\"],[\"“Human-in-the-loop automatically solves risk.”\",\"Oversight only works when reviewers have authority, context and intervention capability.\"],[\"“Logging everything gives auditability.”\",\"Auditability requires reconstructable relevant evidence with controlled retention and access.\"],[\"“Governance blocks innovation.”\",\"Poor governance can block delivery; well-designed governance creates reusable safe paths and clearer decision ownership.\"],[\"“Low-risk pilots need no governance.”\",\"They can use lightweight governance, but inventory, ownership and data\u002Ftool boundaries still matter.\"],[\"“Local AI needs less governance.”\",\"Local hosting can change privacy\u002Fprovider risk, but model quality, permissions, security and lifecycle governance remain.\"],[\"“Once approved, the system stays approved.”\",\"Model, provider, data, regulation and use can change; governance decisions need review triggers.\"]]},\"tunes\":{}},{\"id\":\"h-edge\",\"type\":\"header\",\"data\":{\"text\":\"Edge cases and limitations\",\"level\":2},\"tunes\":{}},{\"id\":\"p-edge-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Very small organizations may not need a dedicated AI governance function. The same principles can be implemented through lightweight architecture decisions, risk registers, owner mappings and release gates.\"},\"tunes\":{}},{\"id\":\"p-edge-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Highly regulated organizations may need much more formal governance, independent assurance, documented conformity processes and legal interpretation than this architecture-level article describes.\"},\"tunes\":{}},{\"id\":\"p-edge-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Open-source and self-hosted models reduce some provider dependencies but create others: patching, model provenance, evaluation, infrastructure security, licensing and operational ownership.\"},\"tunes\":{}},{\"id\":\"p-edge-4\",\"type\":\"paragraph\",\"data\":{\"text\":\"General-purpose AI models can be used across many contexts. Governance should avoid assuming that provider-level model controls fully determine downstream application risk.\"},\"tunes\":{}},{\"id\":\"p-edge-5\",\"type\":\"paragraph\",\"data\":{\"text\":\"No governance framework guarantees that an AI system is safe or correct. Governance improves accountability and decision quality; technical validation, monitoring and human judgment remain necessary.\"},\"tunes\":{}},{\"id\":\"h-change-answer\",\"type\":\"header\",\"data\":{\"text\":\"What would change this answer?\",\"level\":2},\"tunes\":{}},{\"id\":\"p-change-answer-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The exact control set changes with law, industry, organization size, data sensitivity, autonomy, deployment model and business consequence.\"},\"tunes\":{}},{\"id\":\"p-change-answer-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"NIST is currently revising AI RMF 1.0, so future NIST terminology or recommended practices may change. ISO standards can also be revised, and EU AI Act guidance and transition details continue to evolve.\"},\"tunes\":{}},{\"id\":\"p-change-answer-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The stable architectural principle is that AI decisions need explicit owners, evidence, permissions, risk treatment and lifecycle review rather than being hidden inside model or application configuration.\"},\"tunes\":{}},{\"id\":\"h-related\",\"type\":\"header\",\"data\":{\"text\":\"Related canonical knowledge\",\"level\":2},\"tunes\":{}},{\"id\":\"p-related-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI governance depends on concepts already separated elsewhere in this knowledge graph: Source of Truth determines authority, RBAC and tenant isolation constrain access, context engineering controls model-visible information, and agentic architecture defines how tools and actions enter an execution loop.\"},\"tunes\":{}},{\"id\":\"p-related-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Enterprise AI Architecture is the parent organizational architecture concept. Governance is the operating control layer that determines how those enterprise AI components may be introduced, changed and retired.\"},\"tunes\":{}},{\"id\":\"p-related-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Agentic systems increase governance requirements because model decisions can become real side effects. Permission, approval and audit controls must therefore exist outside the model itself.\"},\"tunes\":{}},{\"id\":\"ref-agent-reliability\",\"type\":\"referralArticle\",\"data\":{\"url\":\"https:\u002F\u002Fstajic.de\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough\",\"title\":\"AI Agent Reliability: Why the Final Answer Is Not Enough\",\"excerpt\":\"Agent governance requires evidence about execution trajectories, tool use, state changes and recoverability — not only final output quality.\",\"ctaLabel\":\"Read the agent reliability article\"},\"tunes\":{}},{\"id\":\"ref-memory\",\"type\":\"referralArticle\",\"data\":{\"url\":\"https:\u002F\u002Fstajic.de\u002Fblog\u002Fai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context\",\"title\":\"AI Agent Memory Is Not RAG: How to Separate Memory, Retrieval, State and Context\",\"excerpt\":\"Governance needs different policies for durable memory, authoritative state, retrieved information and temporary model context.\",\"ctaLabel\":\"Read the memory architecture article\"},\"tunes\":{}},{\"id\":\"ref-avb\",\"type\":\"referralArticle\",\"data\":{\"url\":\"https:\u002F\u002Fstajic.de\u002Fblog\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers\",\"title\":\"The Answer Validity Boundary: The Missing Layer Between Relevance and Reliable AI Answers\",\"excerpt\":\"Governance decisions should preserve the conditions under which evidence and approval remain valid, including version, scope, source and time.\",\"ctaLabel\":\"Read the Answer Validity Boundary\"},\"tunes\":{}},{\"id\":\"h-faq\",\"type\":\"header\",\"data\":{\"text\":\"Frequently asked questions\",\"level\":2},\"tunes\":{}},{\"id\":\"faq\",\"type\":\"faq\",\"data\":{\"title\":\"AI governance FAQ\",\"items\":[{\"id\":\"faq1\",\"question\":\"What is AI governance?\",\"answer\":\"AI governance is the system of ownership, decision rights, controls and evidence used to manage how AI systems are developed, acquired, deployed, operated, changed and retired.\"},{\"id\":\"faq2\",\"question\":\"Is AI governance the same as AI risk management?\",\"answer\":\"No. Risk management identifies, assesses and treats risk. Governance defines who must do that work, which decisions require it and what evidence or authority is required.\"},{\"id\":\"faq3\",\"question\":\"Is AI governance the same as compliance?\",\"answer\":\"No. Compliance concerns applicable legal, regulatory, contractual or internal obligations. Governance integrates compliance with architecture, security, data, quality, permissions and business ownership.\"},{\"id\":\"faq4\",\"question\":\"What is the difference between AI governance and Enterprise AI Architecture?\",\"answer\":\"Enterprise AI Architecture defines how AI capabilities and systems fit into the organization. AI governance defines the decision and control system governing how those components may be introduced, operated and changed.\"},{\"id\":\"faq5\",\"question\":\"Do small companies need AI governance?\",\"answer\":\"Yes, but not necessarily a dedicated department. Lightweight inventory, ownership, permissions, evaluation and change controls can implement the same principles.\"},{\"id\":\"faq6\",\"question\":\"What should an AI inventory contain?\",\"answer\":\"At minimum: use case, owners, model\u002Fprovider\u002Fversion, data classes, users, tools\u002Factions, permissions, risk classification, evaluation status, lifecycle state and review triggers.\"},{\"id\":\"faq7\",\"question\":\"Does using an approved model mean a use case is approved?\",\"answer\":\"No. Risk depends on the application context: data, users, tools, autonomy, consequences and business process.\"},{\"id\":\"faq8\",\"question\":\"What makes an AI system auditable?\",\"answer\":\"The organization can reconstruct relevant ownership, approved configuration, model\u002Fprovider\u002Fversion, data\u002Fpermission context, evaluation evidence, significant actions and lifecycle decisions.\"},{\"id\":\"faq9\",\"question\":\"How often should AI governance decisions be reviewed?\",\"answer\":\"Use risk-based review intervals plus event triggers such as model\u002Fprovider changes, new data, new tools, incidents, material performance change or regulatory updates.\"}]},\"tunes\":{}},{\"id\":\"h-glossary\",\"type\":\"header\",\"data\":{\"text\":\"Glossary\",\"level\":2},\"tunes\":{}},{\"id\":\"glossary\",\"type\":\"glossary\",\"data\":{\"title\":\"Key AI governance terms\",\"entries\":[{\"term\":\"AI governance\",\"definition\":\"Organizational system of ownership, decision rights, controls and evidence governing the AI lifecycle.\",\"anchor\":\"ai-governance\"},{\"term\":\"AI management system\",\"definition\":\"Interrelated organizational policies, objectives and processes for responsible development, provision or use of AI; ISO\u002FIEC 42001 specifies requirements for such a system.\",\"anchor\":\"ai-management-system\"},{\"term\":\"AI inventory\",\"definition\":\"Registry of AI systems, models, providers, use cases, owners, data, risk classifications and lifecycle state.\",\"anchor\":\"ai-inventory\"},{\"term\":\"Risk owner\",\"definition\":\"Named authority accountable for deciding how a defined risk is treated or whether residual risk is accepted.\",\"anchor\":\"risk-owner\"},{\"term\":\"Control\",\"definition\":\"Technical, organizational or procedural measure intended to prevent, detect, reduce or respond to risk.\",\"anchor\":\"control\"},{\"term\":\"Governance gate\",\"definition\":\"Lifecycle decision point at which defined evidence and authority are required before proceeding.\",\"anchor\":\"governance-gate\"},{\"term\":\"Residual risk\",\"definition\":\"Risk that remains after controls or mitigation have been applied.\",\"anchor\":\"residual-risk\"},{\"term\":\"Exception\",\"definition\":\"Explicit, scoped and usually time-bounded authorization to deviate from a normal governance requirement.\",\"anchor\":\"exception\"},{\"term\":\"Auditability\",\"definition\":\"Ability to reconstruct relevant decisions, configurations, evidence, identities and execution events.\",\"anchor\":\"auditability\"},{\"term\":\"Model governance\",\"definition\":\"Controls and decisions covering model selection, versioning, evaluation, permitted use, change and retirement.\",\"anchor\":\"model-governance\"},{\"term\":\"Provider governance\",\"definition\":\"Controls covering external or internal AI provider dependencies, data handling, security, contracts, lifecycle and exit.\",\"anchor\":\"provider-governance\"},{\"term\":\"Human oversight\",\"definition\":\"Designed human review or intervention capability for AI decisions or actions at defined points.\",\"anchor\":\"human-oversight\"}]},\"tunes\":{}},{\"id\":\"h-conclusion\",\"type\":\"header\",\"data\":{\"text\":\"Conclusion\",\"level\":2},\"tunes\":{}},{\"id\":\"p-conclusion-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI governance is the organizational control plane around AI. It gives names and evidence to decisions that otherwise remain hidden inside code, provider settings, prompts or informal team judgment.\"},\"tunes\":{}},{\"id\":\"p-conclusion-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Strong governance connects the complete system: business purpose, models, providers, data authority, identity, permissions, evaluation, risk, compliance, monitoring, incidents, change and retirement.\"},\"tunes\":{}},{\"id\":\"p-conclusion-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The practical goal is not maximum process. It is the minimum governance structure that makes important AI decisions owned, evidence-based, enforceable, reviewable and auditable throughout the lifecycle.\"},\"tunes\":{}},{\"id\":\"h-sources\",\"type\":\"header\",\"data\":{\"text\":\"Primary sources and current references\",\"level\":2},\"tunes\":{}},{\"id\":\"p-sources-note\",\"type\":\"paragraph\",\"data\":{\"text\":\"The sources below provide current external grounding for AI management, risk and regulation. Project sections are original implementation\u002Fproject evidence and are explicitly distinguished from formal standards or certified governance systems.\"},\"tunes\":{}},{\"id\":\"src-nist-rmf\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"NIST — AI Risk Management Framework\",\"description\":\"Current NIST hub for AI RMF 1.0, the ongoing revision, the GenAI Profile and related risk-management resources.\"}},\"tunes\":{}},{\"id\":\"src-nist-core\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fairc.nist.gov\u002Fairmf-resources\u002Fairmf\u002F5-sec-core\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"NIST AIRC — AI RMF Core\",\"description\":\"Official AI RMF Core describing GOVERN, MAP, MEASURE and MANAGE, with GOVERN as a cross-cutting lifecycle function.\"}},\"tunes\":{}},{\"id\":\"src-nist-playbook\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework\u002Fnist-ai-rmf-playbook\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"NIST — AI RMF Playbook\",\"description\":\"Suggested actions for operationalizing trustworthiness and risk management across the AI lifecycle.\"}},\"tunes\":{}},{\"id\":\"src-nist-genai\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fartificial-intelligence-risk-management-framework-generative-artificial-intelligence\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"NIST AI 600-1 — Generative AI Profile\",\"description\":\"NIST companion profile applying AI RMF concepts to generative-AI risks and lifecycle management.\"}},\"tunes\":{}},{\"id\":\"src-iso42001\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F42001\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC 42001:2023 — AI management systems\",\"description\":\"International standard specifying requirements for establishing, implementing, maintaining and continually improving an AI management system.\"}},\"tunes\":{}},{\"id\":\"src-iso23894\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F77304.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC 23894:2023 — AI risk management\",\"description\":\"International guidance for integrating AI-specific risk management into organizational activities and functions.\"}},\"tunes\":{}},{\"id\":\"src-eu-act\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdigital-strategy.ec.europa.eu\u002Fen\u002Fpolicies\u002Fregulatory-framework-ai\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"European Commission — AI Act\",\"description\":\"Current Commission overview of the EU AI Act, application timeline and implementation framework.\"}},\"tunes\":{}},{\"id\":\"src-eu-faq\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdigital-strategy.ec.europa.eu\u002Fen\u002Ffaqs\u002Fnavigating-ai-act\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"European Commission — Navigating the AI Act\",\"description\":\"Current FAQ covering governance, enforcement, implementation and the evolving application timeline.\"}},\"tunes\":{}},{\"id\":\"src-eu-gpai\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdigital-strategy.ec.europa.eu\u002Fen\u002Ffactpages\u002Fgeneral-purpose-ai-obligations-under-ai-act\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"European Commission — General-purpose AI obligations\",\"description\":\"Current overview of documentation, copyright, training-content and systemic-risk obligations for GPAI providers.\"}},\"tunes\":{}}],\"version\":\"2.31.6\"}",{"time":1746,"blocks":1747,"version":3010},1791485902655,[1748,1752,1757,1762,1767,1771,1775,1779,1783,1787,1791,1795,1799,1803,1832,1836,1840,1844,1848,1852,1879,1883,1887,1891,1895,1899,1922,1926,1930,1934,1938,1943,1947,1951,1955,1959,2005,2009,2013,2017,2021,2025,2059,2063,2067,2071,2075,2079,2083,2087,2091,2095,2099,2103,2107,2111,2115,2119,2123,2127,2131,2171,2175,2179,2183,2187,2191,2195,2199,2203,2207,2212,2216,2245,2249,2253,2257,2261,2265,2269,2273,2277,2281,2285,2289,2293,2321,2325,2329,2333,2337,2341,2345,2349,2353,2357,2361,2365,2369,2373,2377,2381,2385,2389,2411,2415,2419,2423,2427,2431,2435,2439,2444,2448,2452,2456,2460,2464,2468,2472,2476,2480,2484,2512,2516,2562,2566,2570,2574,2578,2582,2586,2620,2624,2628,2669,2673,2725,2729,2766,2770,2774,2778,2782,2786,2790,2794,2798,2802,2806,2810,2814,2818,2822,2829,2836,2843,2847,2879,2883,2923,2927,2931,2935,2939,2943,2947,2954,2961,2968,2975,2982,2989,2996,3003],{"id":215,"data":1749,"type":218,"tunes":1751},{"text":1750},"AI governance is the system of decision rights, responsibilities, controls and evidence used to decide how an organization may develop, acquire, deploy, operate, change and retire AI systems. It is broader than a policy document and narrower than enterprise architecture as a whole. Effective AI governance connects business ownership, model and provider choices, data authority, permissions, risk classification, evaluation, monitoring, incident handling, auditability and lifecycle decisions so that someone can answer not only “does the AI work?” but also “who approved it, under which conditions, with what evidence, and when must that decision be revisited?”",{},{"id":221,"data":1753,"type":226,"tunes":1756},{"body":1754,"title":1755,"variant":225},"\u003Cstrong>AI governance turns AI from an informal technical capability into an accountable organizational capability.\u003C\u002Fstrong>\u003Cbr>\u003Cbr>Architecture determines how the system is built. Engineering implements it. Risk management evaluates uncertainty and harm. Compliance addresses applicable obligations. Governance connects these activities through ownership, decision rights, required controls, evidence and lifecycle gates.","Direct answer",{},{"id":229,"data":1758,"type":226,"tunes":1761},{"body":1759,"title":1760,"variant":233},"A governance board can be one mechanism, and policies can document expectations, but governance only becomes operational when decisions change what systems are allowed to do: which models may be used, which data may enter them, which tools an agent may execute, which evaluations are required, who can approve exceptions, what must be logged and what triggers suspension or retirement.","Governance is not a committee and not a PDF",{},{"id":236,"data":1763,"type":226,"tunes":1766},{"body":1764,"title":1765,"variant":240},"NIST AI RMF 1.0 remains the current published framework while NIST is revising it. Its core is organized around \u003Cstrong>GOVERN, MAP, MEASURE and MANAGE\u003C\u002Fstrong>, with GOVERN as a cross-cutting function. ISO\u002FIEC 42001:2023 remains the international AI management-system standard for establishing, operating and continually improving an AI management system. The EU AI Act is now generally applicable from 2 August 2026, while some obligations had earlier application dates and some high-risk requirements have later transition dates. Regulatory timelines should always be rechecked before making a concrete compliance decision.","Current-source note — 8 October 2026",{},{"id":243,"data":1768,"type":248,"tunes":1770},{"title":1769,"maxLevel":246,"minLevel":247},"Contents",{},{"id":251,"data":1772,"type":42,"tunes":1774},{"text":1773,"level":247},"What AI governance really means",{},{"id":256,"data":1776,"type":218,"tunes":1778},{"text":1777},"AI governance answers organizational questions that a model, SDK or architecture diagram cannot answer by itself. Who owns the business outcome? Who may approve a new provider? Which data classes are prohibited from external processing? What evidence is required before deployment? Which permissions may an agent receive? Who can accept residual risk? What happens when a model changes behavior after an upgrade?",{},{"id":261,"data":1780,"type":218,"tunes":1782},{"text":1781},"The purpose is not to prevent change. Good governance makes change legible: decisions have owners, evidence, conditions, exceptions, review dates and rollback or escalation paths.",{},{"id":266,"data":1784,"type":218,"tunes":1786},{"text":1785},"This is why NIST places GOVERN across the entire AI risk-management lifecycle rather than treating governance as one final approval step. Governance establishes the culture, policies, accountability and organizational structures that make mapping, measuring and managing AI risk possible.",{},{"id":271,"data":1788,"type":42,"tunes":1790},{"text":1789,"level":247},"The simplest example",{},{"id":276,"data":1792,"type":218,"tunes":1794},{"text":1793},"A product team wants to add an external generative-AI provider to summarize internal customer-support tickets. Technically, the integration may require only an API call.",{},{"id":281,"data":1796,"type":218,"tunes":1798},{"text":1797},"Governance asks a different set of questions: Are the ticket contents permitted to leave the organization's environment? Which provider and model version are approved? Is retention disabled? Which users may invoke the feature? How is output evaluated? Is human review required? What gets logged? Who owns incidents? What happens if the provider changes its terms or model behavior?",{},{"id":286,"data":1800,"type":218,"tunes":1802},{"text":1801},"The governance result may still be “deploy it.” The difference is that deployment is now a traceable decision with explicit conditions instead of an unrecorded engineering choice.",{},{"id":291,"data":1804,"type":320,"tunes":1831},{"steps":1805,"title":1830,"orientation":319},[1806,1809,1812,1815,1818,1821,1824,1827],{"label":1807,"description":1808},"1. Register the use case","Record purpose, owner, users, data, model\u002Fprovider and intended outcome.",{"label":1810,"description":1811},"2. Classify risk and obligations","Determine business consequence, data sensitivity, autonomy, regulatory exposure and misuse potential.",{"label":1813,"description":1814},"3. Define required controls","Specify permissions, data handling, evaluations, human oversight, security, logging and provider constraints.",{"label":1816,"description":1817},"4. Collect evidence","Run tests, security\u002Fprivacy review, architecture review and relevant legal\u002Fcompliance checks.",{"label":1819,"description":1820},"5. Make a decision","Approve, approve with conditions, request changes, hold or reject.",{"label":1822,"description":1823},"6. Deploy under controlled configuration","Pin the approved model\u002Fprovider\u002Fruntime and enforce required boundaries.",{"label":1825,"description":1826},"7. Monitor and re-evaluate","Track incidents, quality, drift, provider changes, new risks and changed regulations.",{"label":1828,"description":1829},"8. Change, suspend or retire","Use evidence and ownership rules to decide the next lifecycle state.","A basic governed AI decision",{},{"id":323,"data":1833,"type":42,"tunes":1835},{"text":1834,"level":247},"Where the simple example stops",{},{"id":328,"data":1837,"type":218,"tunes":1839},{"text":1838},"Large organizations rarely govern one AI system in isolation. The same model may support dozens of products; one provider may process several data classes; an agent platform may expose shared tools to many teams.",{},{"id":333,"data":1841,"type":218,"tunes":1843},{"text":1842},"Governance therefore needs portfolio-level structures as well as system-level controls: AI inventory, approved providers, model catalogs, shared evaluation baselines, security patterns, risk thresholds, exception registers and ownership mappings.",{},{"id":338,"data":1845,"type":218,"tunes":1847},{"text":1846},"Governance also cannot be identical for every AI use. A public-content summarizer, an internal coding assistant, a hiring-support system and an agent that can initiate payments have materially different consequence and control profiles.",{},{"id":343,"data":1849,"type":42,"tunes":1851},{"text":1850,"level":247},"What AI governance is — and what it is not",{},{"id":348,"data":1853,"type":385,"tunes":1878},{"rows":1854,"title":1872,"layout":377,"columns":1873},[1855,1858,1861,1864,1867,1869],{"id":352,"label":1856,"values":1857},"Enterprise \u002F solution architecture",[355,355],{"id":357,"label":1859,"values":1860},"AI risk management",[355,355],{"id":361,"label":1862,"values":1863},"Compliance",[355,355],{"id":365,"label":1865,"values":1866},"Security",[355,355],{"id":369,"label":370,"values":1868},[355,355],{"id":373,"label":1870,"values":1871},"AI ethics principles",[355,355],"AI governance compared with adjacent disciplines",[1874,1876],{"id":380,"label":1875},"AI governance",{"id":383,"label":1877},"Adjacent discipline",{},{"id":388,"data":1880,"type":42,"tunes":1882},{"text":1881,"level":247},"Governance is broader than compliance",{},{"id":393,"data":1884,"type":218,"tunes":1886},{"text":1885},"Compliance is one input to governance, not the entire governance system. An AI use case can be legally permitted yet still violate company risk appetite, security policy, contractual obligations or product-quality requirements.",{},{"id":398,"data":1888,"type":218,"tunes":1890},{"text":1889},"The reverse also matters: internal approval does not override law. Governance should make applicable legal obligations visible inside the same decision path used for architecture, security and business risk.",{},{"id":403,"data":1892,"type":218,"tunes":1894},{"text":1893},"ISO\u002FIEC 42001 explicitly frames an AI management system as a structured way to establish policies, objectives and processes for responsible AI. ISO also states that the standard does not replace laws or regulations; it provides a management framework that can support compliance.",{},{"id":408,"data":1896,"type":42,"tunes":1898},{"text":1897,"level":247},"NIST AI RMF and ISO\u002FIEC 42001 solve different governance needs",{},{"id":413,"data":1900,"type":377,"tunes":1921},{"content":1901,"stretched":43,"withHeadings":14},[1902,1906,1909,1912,1915,1918],[1903,1904,1905],"Framework \u002F standard","Primary role","Useful governance value",[421,1907,1908],"Voluntary AI risk-management framework","Organizes outcomes around GOVERN, MAP, MEASURE and MANAGE across the lifecycle",[425,1910,1911],"Generative-AI profile for AI RMF","Adds GenAI-specific risk considerations and actions",[429,1913,1914],"AI management-system requirements","Creates an organization-wide management system with policy, roles, processes and continual improvement",[433,1916,1917],"AI risk-management guidance","Guides integration of AI-specific risk management into organizational activities",[437,1919,1920],"Binding regulation in the EU","Creates legal obligations according to actor, AI category and use case",{},{"id":442,"data":1923,"type":218,"tunes":1925},{"text":1924},"These sources should not be collapsed into one checklist. NIST AI RMF is risk-management guidance. ISO\u002FIEC 42001 is a management-system standard. The EU AI Act is law. An organization can use them together, but their authority, scope and implementation purpose are different.",{},{"id":447,"data":1927,"type":42,"tunes":1929},{"text":1928,"level":247},"Current EU AI Act timing matters",{},{"id":452,"data":1931,"type":218,"tunes":1933},{"text":1932},"As of 8 October 2026, the European Commission states that the AI Act became generally applicable on 2 August 2026. Prohibited-practice and AI-literacy provisions applied from 2 February 2025, while governance rules and obligations for general-purpose AI models applied from 2 August 2025.",{},{"id":457,"data":1935,"type":218,"tunes":1937},{"text":1936},"The Commission's current guidance also reflects later application dates for certain high-risk requirements. Exact dates and transition rules are a moving compliance input and should be verified against current Commission material before a deployment decision.",{},{"id":462,"data":1939,"type":226,"tunes":1942},{"body":1940,"title":1941,"variant":233},"The regulatory examples here explain why governance needs versioned legal\u002Fcompliance inputs. They do not determine whether a specific product is legally classified as prohibited, high-risk, GPAI, deployer, provider or another regulated actor.","Architecture article, not legal advice",{},{"id":468,"data":1944,"type":42,"tunes":1946},{"text":1945,"level":247},"AI governance starts with an inventory",{},{"id":473,"data":1948,"type":218,"tunes":1950},{"text":1949},"An organization cannot govern AI systems it cannot identify. The inventory should cover more than custom-trained models. It may include external model APIs, embedded copilots, local models, AI-enabled SaaS features, agent runtimes, retrieval systems and automated decision components.",{},{"id":478,"data":1952,"type":218,"tunes":1954},{"text":1953},"A useful inventory connects the AI capability to its business owner, technical owner, use case, users, data classes, model\u002Fprovider, deployment environment, permissions, risk classification, evaluation status, applicable obligations and lifecycle state.",{},{"id":483,"data":1956,"type":218,"tunes":1958},{"text":1957},"The inventory is not only a spreadsheet for auditors. It is the index that lets the organization know what must be reviewed when a provider changes, a vulnerability appears, a regulation becomes applicable or a model is retired.",{},{"id":488,"data":1960,"type":377,"tunes":2004},{"content":1961,"stretched":43,"withHeadings":14},[1962,1965,1968,1971,1974,1977,1980,1983,1986,1989,1992,1995,1998,2001],[1963,1964],"Inventory field","Why governance needs it",[1966,1967],"Use case \u002F purpose","Defines why AI exists and what success means",[1969,1970],"Business owner","Owns outcome and business risk",[1972,1973],"Technical owner","Owns architecture, implementation and operation",[1975,1976],"Model + version","Identifies the behavior-producing dependency",[1978,1979],"Provider \u002F runtime","Identifies contractual, hosting and operational dependency",[1981,1982],"Data classes","Determines privacy, confidentiality and Source-of-Truth constraints",[1984,1985],"Users \u002F affected parties","Determines exposure and human-impact context",[1987,1988],"Tools \u002F actions","Determines autonomy and side-effect risk",[1990,1991],"Permissions \u002F identity","Defines who or what may invoke the capability",[1993,1994],"Risk classification","Determines required controls and approval path",[1996,1997],"Evaluation evidence","Shows whether intended behavior was tested",[1999,2000],"Lifecycle state","Draft, review, approved, restricted, suspended or retired",[2002,2003],"Review date \u002F triggers","Defines when the governance decision must be revisited",{},{"id":535,"data":2006,"type":42,"tunes":2008},{"text":2007,"level":247},"Governance requires named ownership",{},{"id":540,"data":2010,"type":218,"tunes":2012},{"text":2011},"AI failures often cross organizational boundaries. A model-quality problem may become a product failure, security issue, privacy incident or contractual breach. Governance needs named owners before the incident occurs.",{},{"id":545,"data":2014,"type":218,"tunes":2016},{"text":2015},"Ownership does not mean one person is responsible for everything. A strong model separates decision rights: business owner, product owner, technical owner, data owner, security\u002Fprivacy specialists, legal\u002Fcompliance actors and operational support.",{},{"id":550,"data":2018,"type":218,"tunes":2020},{"text":2019},"The critical property is that every required decision has an owner and every owner knows which evidence they are expected to review.",{},{"id":555,"data":2022,"type":42,"tunes":2024},{"text":2023,"level":247},"Decision rights should be explicit",{},{"id":560,"data":2026,"type":377,"tunes":2058},{"content":2027,"stretched":43,"withHeadings":14},[2028,2031,2034,2037,2040,2043,2046,2049,2052,2055],[2029,2030],"Decision","Typical accountable function",[2032,2033],"May this AI use case exist?","Business\u002Fproduct owner with governance\u002Frisk input",[2035,2036],"May this data class be processed?","Data owner + privacy\u002Fsecurity according to policy",[2038,2039],"May this provider\u002Fmodel be used?","Architecture\u002Fplatform + security\u002Fprocurement + governance",[2041,2042],"May this agent execute this action?","Application owner + authorization\u002Fbusiness-policy owner",[2044,2045],"Is quality sufficient for deployment?","Product\u002Ftechnical owner against defined acceptance criteria",[2047,2048],"Can residual risk be accepted?","Named risk owner at appropriate authority level",[2050,2051],"Can an exception be granted?","Explicit exception authority, time-bounded and documented",[2053,2054],"Should the system be suspended?","Operational\u002Fbusiness owner under incident or risk triggers",[2056,2057],"Can a model upgrade go live?","Change owner after regression\u002Fevaluation evidence",{},{"id":595,"data":2060,"type":42,"tunes":2062},{"text":2061,"level":247},"Model governance is more than choosing a model",{},{"id":600,"data":2064,"type":218,"tunes":2066},{"text":2065},"Model governance tracks which model is used, for what purpose, under which configuration and evidence. This applies to external APIs, locally hosted models, fine-tuned models and models embedded in third-party software.",{},{"id":605,"data":2068,"type":218,"tunes":2070},{"text":2069},"A model decision should consider capability, evaluation results, cost, latency, data handling, provider terms, lifecycle support, geographic\u002Fhosting constraints, security, fallback behavior and the consequences of version change.",{},{"id":610,"data":2072,"type":218,"tunes":2074},{"text":2073},"Model aliases such as “latest” can be operationally convenient but weaken reproducibility if behavior changes without a governed release process. Consequential systems benefit from explicit version tracking and regression evaluation.",{},{"id":615,"data":2076,"type":42,"tunes":2078},{"text":2077,"level":247},"Provider governance is a separate dependency layer",{},{"id":620,"data":2080,"type":218,"tunes":2082},{"text":2081},"Two systems using the same model family can have different governance risk if one runs locally and another sends data to an external provider. Provider governance covers contractual terms, processing location, retention, logging, sub-processors, availability, deprecation and exit strategy.",{},{"id":625,"data":2084,"type":218,"tunes":2086},{"text":2085},"Provider abstraction can reduce technical lock-in, but it does not remove governance work. Swapping providers can change data flows, model behavior, security assumptions, cost and compliance obligations.",{},{"id":630,"data":2088,"type":218,"tunes":2090},{"text":2089},"An approved provider list should therefore not be interpreted as “every model and every data class from this provider is automatically approved.” Approval needs scope.",{},{"id":635,"data":2092,"type":42,"tunes":2094},{"text":2093,"level":247},"Data governance remains the Source-of-Truth layer",{},{"id":640,"data":2096,"type":218,"tunes":2098},{"text":2097},"AI governance does not make the model the authority for organizational facts. Data governance still determines ownership, classification, retention, quality and permitted use of source data.",{},{"id":645,"data":2100,"type":218,"tunes":2102},{"text":2101},"For RAG and agents, governance should identify which sources are authoritative, which are advisory, how provenance is preserved, which data may enter model context and which tenant\u002Fuser boundaries must be enforced.",{},{"id":650,"data":2104,"type":218,"tunes":2106},{"text":2105},"Generated outputs create new data-governance questions as well: whether prompts and responses are retained, who may access traces, whether generated summaries become records and how derived embeddings or indexes are deleted when source data is removed.",{},{"id":655,"data":2108,"type":42,"tunes":2110},{"text":2109,"level":247},"Permissions are governance decisions with runtime enforcement",{},{"id":660,"data":2112,"type":218,"tunes":2114},{"text":2113},"Agentic AI makes permissions a first-class governance object. The organization needs to decide which tools, files, APIs, databases and side effects each agent or user may access.",{},{"id":665,"data":2116,"type":218,"tunes":2118},{"text":2117},"Governance defines the policy and approval logic; the trusted runtime enforces it. Natural-language instructions such as “do not delete files” are not a substitute for filesystem, API or service authorization.",{},{"id":670,"data":2120,"type":218,"tunes":2122},{"text":2121},"The same principle applies to tenant isolation: a role can authorize an operation while tenant scope constrains which customer's resources that operation may reach.",{},{"id":675,"data":2124,"type":42,"tunes":2126},{"text":2125,"level":247},"Risk classification should change the control set",{},{"id":680,"data":2128,"type":218,"tunes":2130},{"text":2129},"Not every AI system needs the same review depth. Governance becomes scalable when risk classification changes the evidence, approval and monitoring requirements.",{},{"id":685,"data":2132,"type":377,"tunes":2170},{"content":2133,"stretched":43,"withHeadings":14},[2134,2138,2142,2146,2150,2154,2158,2162,2166],[2135,2136,2137],"Risk driver","Lower-control example","Higher-control example",[2139,2140,2141],"Business consequence","Draft internal text","Approve financial settlement",[2143,2144,2145],"Human impact","Optional writing aid","Employment or eligibility decision support",[2147,2148,2149],"Data sensitivity","Public documentation","Health, HR, financial or confidential data",[2151,2152,2153],"Autonomy","Read-only recommendation","Agent with write\u002Fpayment\u002Fdeployment tools",[2155,2156,2157],"Reversibility","Easily regenerated summary","Irreversible external transaction",[2159,2160,2161],"Exposure","Small internal pilot","Public\u002Fcustomer-facing system at scale",[2163,2164,2165],"Source authority","Advisory content","System relied on for regulated or contractual fact",[2167,2168,2169],"Failure detectability","Obvious formatting defect","Plausible but materially wrong recommendation",{},{"id":726,"data":2172,"type":218,"tunes":2174},{"text":2173},"The classification method can be simple or sophisticated, but it should map to concrete consequences: more testing, narrower permissions, required human oversight, security review, executive risk acceptance or deployment prohibition.",{},{"id":731,"data":2176,"type":42,"tunes":2178},{"text":2177,"level":247},"Governance must preserve use-case context",{},{"id":736,"data":2180,"type":218,"tunes":2182},{"text":2181},"NIST's MAP function emphasizes intended purpose, users, deployment context, assumptions, impacts and applicable laws or norms. This matters because the same model can be low risk in one use case and high consequence in another.",{},{"id":741,"data":2184,"type":218,"tunes":2186},{"text":2185},"Governance records should therefore classify the application, not only the model. “We use model X” is not enough to determine risk.",{},{"id":746,"data":2188,"type":218,"tunes":2190},{"text":2189},"The relevant governance object is the system\u002Fuse case: model + data + context + tools + users + deployment environment + business process.",{},{"id":751,"data":2192,"type":42,"tunes":2194},{"text":2193,"level":247},"Evaluation is governance evidence",{},{"id":756,"data":2196,"type":218,"tunes":2198},{"text":2197},"An AI governance process should not approve deployment based only on vendor benchmarks or a successful demo. The system needs evidence tied to its actual intended use.",{},{"id":761,"data":2200,"type":218,"tunes":2202},{"text":2201},"Useful evidence can include task-success evaluation, retrieval quality, factual grounding, security tests, permission tests, adversarial scenarios, human-review studies, latency\u002Fcost, robustness and regression comparisons.",{},{"id":766,"data":2204,"type":218,"tunes":2206},{"text":2205},"NIST's MEASURE function makes this explicit: organizations should identify and apply appropriate methods and metrics for risks identified during mapping, while documenting risks that cannot or will not be measured.",{},{"id":771,"data":2208,"type":226,"tunes":2211},{"body":2209,"title":2210,"variant":775},"“The team thinks the model is good enough” is a weak approval artifact. “The system met defined acceptance criteria on representative tests, with these known limitations and residual risks” is governable.","A governance gate should ask for evidence, not confidence",{},{"id":778,"data":2213,"type":42,"tunes":2215},{"text":2214,"level":247},"Governance gates should exist across the lifecycle",{},{"id":783,"data":2217,"type":320,"tunes":2244},{"steps":2218,"title":2243,"orientation":319},[2219,2222,2225,2228,2231,2234,2237,2240],{"label":2220,"description":2221},"Idea \u002F discovery gate","Confirm business purpose, owner and whether AI is an appropriate solution.",{"label":2223,"description":2224},"Architecture gate","Review model\u002Fprovider, data flow, identity, permissions, isolation and operational design.",{"label":2226,"description":2227},"Risk\u002Fcompliance gate","Classify risk and applicable obligations; define required controls.",{"label":2229,"description":2230},"Validation gate","Require evidence that functional, safety, security and quality criteria are met.",{"label":2232,"description":2233},"Deployment gate","Approve concrete configuration, version, environment and operational owner.",{"label":2235,"description":2236},"Change gate","Re-evaluate model\u002Fprovider\u002Ftool\u002Fdata changes according to materiality.",{"label":2238,"description":2239},"Incident gate","Pause, restrict or roll back when defined risk triggers occur.",{"label":2241,"description":2242},"Retirement gate","Remove access, data derivatives, credentials and obsolete dependencies cleanly.","Example lifecycle gates",{},{"id":813,"data":2246,"type":42,"tunes":2248},{"text":2247,"level":247},"Change management is central to AI governance",{},{"id":818,"data":2250,"type":218,"tunes":2252},{"text":2251},"AI systems change even when application code does not. Providers update models, safety filters, context limits, pricing, policies and infrastructure. Retrieval corpora change. Agent tools gain permissions. Regulations and contracts evolve.",{},{"id":823,"data":2254,"type":218,"tunes":2256},{"text":2255},"Governance should therefore define material-change triggers. A minor prompt wording adjustment may need ordinary regression tests; replacing the model, enabling write tools or introducing sensitive data may require a new approval gate.",{},{"id":828,"data":2258,"type":218,"tunes":2260},{"text":2259},"The governance record should preserve which version was approved and what conditions made the approval valid.",{},{"id":833,"data":2262,"type":42,"tunes":2264},{"text":2263,"level":247},"Exceptions need owners, expiry and compensating controls",{},{"id":838,"data":2266,"type":218,"tunes":2268},{"text":2267},"Real organizations need exceptions. A team may need an unapproved model for a time-bounded experiment, or a legacy system may not yet meet a new logging requirement.",{},{"id":843,"data":2270,"type":218,"tunes":2272},{"text":2271},"The dangerous pattern is a permanent undocumented exception. Governable exceptions specify owner, rationale, scope, residual risk, compensating control, expiration date and review condition.",{},{"id":848,"data":2274,"type":218,"tunes":2276},{"text":2275},"Exception handling should be part of the normal governance system rather than an informal side channel.",{},{"id":853,"data":2278,"type":42,"tunes":2280},{"text":2279,"level":247},"Auditability is the ability to reconstruct the decision and execution",{},{"id":858,"data":2282,"type":218,"tunes":2284},{"text":2283},"AI auditability is not merely storing model prompts. It means being able to reconstruct which system version was used, which data and permissions applied, who approved the configuration, what evaluations supported deployment and what happened during relevant execution.",{},{"id":863,"data":2286,"type":218,"tunes":2288},{"text":2287},"For an agent, this may require principal identity, tool calls, approvals, target resources, state changes and outcomes. For RAG, it may require corpus\u002Findex version, retrieval query, selected evidence and provenance. For a model change, it may require the previous and new evaluation results.",{},{"id":868,"data":2290,"type":218,"tunes":2292},{"text":2291},"Audit evidence should be proportionate. Logging every possible token can create privacy and security risk of its own. Governance should define which evidence is necessary, how long it is retained and who may access it.",{},{"id":873,"data":2294,"type":377,"tunes":2320},{"content":2295,"stretched":43,"withHeadings":14},[2296,2299,2302,2305,2308,2311,2314,2317],[2297,2298],"Audit object","Useful evidence",[2300,2301],"Governance decision","Owner, date, decision, conditions, evidence, exceptions",[2303,2304],"Model release","Model\u002Fprovider\u002Fversion, configuration, regression results",[2306,2307],"Data access","Principal, tenant\u002Fscope, source class, policy decision",[2309,2310],"Agent action","Tool, arguments\u002Ftarget, approval, result, state change",[2312,2313],"RAG answer","Corpus\u002Findex version, retrieval set, selected evidence, citations",[2315,2316],"Incident","Trigger, affected systems, containment, decision owner, remediation",[2318,2319],"Retirement","Disabled endpoints, revoked credentials, deleted derived data, archive decision",{},{"id":902,"data":2322,"type":42,"tunes":2324},{"text":2323,"level":247},"Monitoring closes the governance loop",{},{"id":907,"data":2326,"type":218,"tunes":2328},{"text":2327},"Approval is a snapshot. Production monitoring tells governance whether the assumptions behind approval still hold.",{},{"id":912,"data":2330,"type":218,"tunes":2332},{"text":2331},"Useful signals depend on the use case: quality regression, unsafe outputs, tool failures, policy denials, unusual cost, latency, user complaints, drift, retrieval freshness, provider incidents, security alerts or new regulatory classifications.",{},{"id":917,"data":2334,"type":218,"tunes":2336},{"text":2335},"Governance should define thresholds that cause action: investigate, restrict, require human review, roll back, switch provider, suspend or retire.",{},{"id":922,"data":2338,"type":42,"tunes":2340},{"text":2339,"level":247},"AI incidents need a defined operational path",{},{"id":927,"data":2342,"type":218,"tunes":2344},{"text":2343},"AI-specific incidents may involve harmful content, data leakage, unauthorized actions, persistent factual failure, model\u002Fprovider outage, prompt injection, cross-tenant retrieval or unexpected behavior after a model update.",{},{"id":932,"data":2346,"type":218,"tunes":2348},{"text":2347},"The incident process should connect technical response with governance ownership. Someone must be authorized to disable a model, remove a tool, revoke credentials, restrict users, notify affected functions and decide whether the system may return to service.",{},{"id":937,"data":2350,"type":218,"tunes":2352},{"text":2351},"The lessons from incidents should update policies, tests, risk classification and reusable platform controls rather than remain isolated in one team.",{},{"id":942,"data":2354,"type":42,"tunes":2356},{"text":2355,"level":247},"Procurement is part of AI governance",{},{"id":947,"data":2358,"type":218,"tunes":2360},{"text":2359},"Organizations can acquire substantial AI capability through ordinary SaaS procurement. Governance should therefore cover purchased AI features as well as internally engineered systems.",{},{"id":952,"data":2362,"type":218,"tunes":2364},{"text":2363},"Vendor review can include data use, retention, model training policy, sub-processors, security, incident notification, export\u002Fdeletion, geographic processing, version change, service continuity and contractual exit.",{},{"id":957,"data":2366,"type":218,"tunes":2368},{"text":2367},"A technical architecture review and procurement review should share the same system inventory so commercial approval does not drift away from the actual deployed data flow.",{},{"id":962,"data":2370,"type":42,"tunes":2372},{"text":2371,"level":247},"Human oversight should be designed, not merely declared",{},{"id":967,"data":2374,"type":218,"tunes":2376},{"text":2375},"“Human in the loop” is meaningful only if the human has authority, time, information and a usable intervention mechanism.",{},{"id":972,"data":2378,"type":218,"tunes":2380},{"text":2379},"A reviewer who sees only the AI recommendation but not its evidence, uncertainty or source state may simply rubber-stamp the output. Governance should specify what the reviewer can inspect and what actions are available: approve, reject, edit, escalate or stop.",{},{"id":977,"data":2382,"type":218,"tunes":2384},{"text":2383},"Human oversight should also be risk-based. Low-consequence systems may use sampling or post-hoc review, while high-consequence side effects may require approval before execution.",{},{"id":982,"data":2386,"type":42,"tunes":2388},{"text":2387,"level":247},"Platform governance and use-case governance are different",{},{"id":987,"data":2390,"type":385,"tunes":2410},{"rows":2391,"title":2404,"layout":377,"columns":2405},[2392,2395,2398,2401],{"id":991,"label":2393,"values":2394},"Primary concern",[355,355],{"id":995,"label":2396,"values":2397},"Typical approval",[355,355],{"id":999,"label":2399,"values":2400},"Evidence",[355,355],{"id":1003,"label":2402,"values":2403},"Governance failure",[355,355],"Two governance levels",[2406,2408],{"id":1009,"label":2407},"Shared AI platform",{"id":1012,"label":2409},"Individual AI use case",{},{"id":1016,"data":2412,"type":218,"tunes":2414},{"text":2413},"Platform approval should therefore reduce repeated work, not eliminate use-case accountability. “The model is approved” is different from “this application of the model is approved.”",{},{"id":1021,"data":2416,"type":42,"tunes":2418},{"text":2417,"level":247},"AI governance and Enterprise AI Architecture",{},{"id":1026,"data":2420,"type":218,"tunes":2422},{"text":2421},"Enterprise AI Architecture describes how AI systems, platforms, data, identities, providers, operations and organizational systems fit together. AI governance describes the decision and control system that determines how those architectures may be created and changed.",{},{"id":1031,"data":2424,"type":218,"tunes":2426},{"text":2425},"The two are tightly coupled. Governance without architecture can become abstract policy. Architecture without governance can produce technically elegant systems with unclear ownership, uncontrolled provider adoption or unreviewed risk.",{},{"id":1036,"data":2428,"type":218,"tunes":2430},{"text":2429},"The strongest design is bidirectional: governance requirements become architecture controls, while architecture exposes the real decisions that governance must own.",{},{"id":1041,"data":2432,"type":42,"tunes":2434},{"text":2433,"level":247},"Original project evidence",{},{"id":1046,"data":2436,"type":42,"tunes":2438},{"text":2437,"level":246},"Enterprise Aaasaasa 0.1: governance as delivery structure",{},{"id":1051,"data":2440,"type":226,"tunes":2443},{"body":2441,"title":2442,"variant":240},"Enterprise Aaasaasa 0.1 is project and training\u002FPoC evidence, not evidence of commercial enterprise adoption. It is useful here because its delivery structure explicitly connects architecture, milestones, risks, stakeholders, validation and project decisions.","Project \u002F PoC evidence",{},{"id":1057,"data":2445,"type":218,"tunes":2447},{"text":2446},"Enterprise Aaasaasa 0.1 uses defined milestones for requirements, architecture, prototype, validation and project closure. That structure illustrates a core governance principle: lifecycle transitions should have explicit outputs and decision points instead of an informal “build first, review later” process.",{},{"id":1062,"data":2449,"type":218,"tunes":2451},{"text":2450},"The project also tracks risks such as scope creep, architecture delay and AI\u002FGDPR concerns and identifies stakeholder groups including sponsorship, steering, architecture, security, marketing, external APIs and hosting.",{},{"id":1067,"data":2453,"type":218,"tunes":2455},{"text":2454},"This does not constitute an ISO\u002FIEC 42001 management system. It is narrower project evidence showing how ownership, risk, milestones and validation can be integrated into technical delivery.",{},{"id":1072,"data":2457,"type":42,"tunes":2459},{"text":2458,"level":246},"SenseFlow: requirements and decision traceability",{},{"id":1077,"data":2461,"type":218,"tunes":2463},{"text":2462},"SenseFlow uses a structured path from product goal and user need through epics, user stories, acceptance criteria, architecture, implementation and validation. Decision records preserve the decision, rationale, alternatives, trade-offs, status and date\u002Fversion.",{},{"id":1082,"data":2465,"type":218,"tunes":2467},{"text":2466},"That traceability pattern is directly relevant to governance because an AI control should connect to the requirement or risk that justified it. A governance system becomes stronger when the chain from business need to architecture decision to validation evidence can be reconstructed.",{},{"id":1087,"data":2469,"type":42,"tunes":2471},{"text":2470,"level":246},"Aaasaasa AI Client: permissions and runtime as governed configuration",{},{"id":1092,"data":2473,"type":218,"tunes":2475},{"text":2474},"Aaasaasa AI Client separates provider, model, runtime location and permissions rather than treating them as one “AI setting.” Central workspace permission profiles govern tool access, Direct Chat has no filesystem\u002Fshell tools, and agent-capable runtimes operate under explicit permission profiles.",{},{"id":1097,"data":2477,"type":218,"tunes":2479},{"text":2478},"That separation demonstrates an important governance pattern: model choice and action authority should be independent configuration objects. A stronger model does not automatically receive broader filesystem, shell or business permissions.",{},{"id":1102,"data":2481,"type":218,"tunes":2483},{"text":2482},"The implementation evidence is architectural, not a claim that the application constitutes a certified organizational AI governance system.",{},{"id":1107,"data":2485,"type":377,"tunes":2511},{"content":2486,"stretched":43,"withHeadings":14},[2487,2490,2493,2496,2499,2502,2505,2508],[2488,2489],"Observed project pattern","Governance lesson",[2491,2492],"Milestone gates","Lifecycle transitions can require explicit evidence",[2494,2495],"Risk register","Known uncertainties become managed objects rather than informal concerns",[2497,2498],"Stakeholder mapping","Decision responsibility can be distributed deliberately",[2500,2501],"Acceptance criteria + validation","Deployment decisions can depend on evidence",[2503,2504],"Decision records","Architecture trade-offs remain traceable",[2506,2507],"Separate model\u002Fprovider\u002Fruntime\u002Fpermissions","Capability and authority can be governed independently",[2509,2510],"Explicit project maturity labels","PoC evidence is not misrepresented as production or market proof",{},{"id":1136,"data":2513,"type":42,"tunes":2515},{"text":2514,"level":247},"Common AI governance failure modes",{},{"id":1141,"data":2517,"type":377,"tunes":2561},{"content":2518,"stretched":43,"withHeadings":14},[2519,2522,2525,2528,2531,2534,2537,2540,2543,2546,2549,2552,2555,2558],[2520,2521],"Failure mode","What goes wrong",[2523,2524],"Governance is only a policy PDF","Teams cannot translate policy into runtime controls or deployment decisions",[2526,2527],"No AI inventory","The organization cannot identify where models, agents or embedded AI are used",[2529,2530],"Model approval is treated as use-case approval","An approved model is used for a materially different risk context",[2532,2533],"No named business owner","Technical teams inherit business-risk decisions by default",[2535,2536],"Risk classification has no control consequence","Every system receives the same review regardless of consequence",[2538,2539],"Permissions live only in prompts","Model instructions become a substitute for real authorization",[2541,2542],"Provider change is invisible","Behavior\u002Fdata\u002Fcompliance assumptions change without re-evaluation",[2544,2545],"Demo success is approval evidence","Production risk is inferred from a small happy-path test",[2547,2548],"Human oversight is ceremonial","Reviewer cannot inspect evidence or stop the action",[2550,2551],"Exception has no expiry","Temporary workaround becomes permanent governance debt",[2553,2554],"Logs exist but cannot reconstruct decisions","Auditability is confused with raw data retention",[2556,2557],"Compliance owns governance alone","Product, engineering, security and operations disengage from accountability",[2559,2560],"Every decision goes to a central board","Governance becomes a bottleneck instead of a scalable control system",{},{"id":1188,"data":2563,"type":42,"tunes":2565},{"text":2564,"level":247},"Central governance does not mean centralizing every decision",{},{"id":1193,"data":2567,"type":218,"tunes":2569},{"text":2568},"A mature organization can centralize policy, control patterns and escalation while delegating low-risk decisions to product or platform teams.",{},{"id":1198,"data":2571,"type":218,"tunes":2573},{"text":2572},"This federated model scales better than requiring a central committee to approve every prompt change. The central function defines risk tiers, mandatory controls, provider policy, exception authority and audit requirements; teams operate autonomously inside those boundaries.",{},{"id":1203,"data":2575,"type":218,"tunes":2577},{"text":2576},"The design objective is consistent accountability, not maximum centralization.",{},{"id":1208,"data":2579,"type":42,"tunes":2581},{"text":2580,"level":247},"Govern the governance system itself",{},{"id":1213,"data":2583,"type":218,"tunes":2585},{"text":2584},"Governance needs feedback. Otherwise controls can become expensive rituals that do not reduce risk.",{},{"id":1218,"data":2587,"type":377,"tunes":2619},{"content":2588,"stretched":43,"withHeadings":14},[2589,2592,2595,2598,2601,2604,2607,2610,2613,2616],[2590,2591],"Metric \u002F signal","What it can reveal",[2593,2594],"Inventory coverage","Whether AI adoption is visible to governance",[2596,2597],"Time to decision","Whether governance blocks delivery unnecessarily",[2599,2600],"Exception count and age","Whether policies are realistic or routinely bypassed",[2602,2603],"Evaluation failure rate","Whether pre-deployment controls catch defects",[2605,2606],"Post-deployment incident rate","Whether approval evidence predicts production behavior",[2608,2609],"Unauthorized-tool denial rate","Whether permission boundaries are actively exercised",[2611,2612],"Model\u002Fprovider change frequency","How often approved assumptions may become stale",[2614,2615],"Retired-but-active systems","Lifecycle cleanup\u002Fcontrol failure",[2617,2618],"Repeated incident patterns","Whether lessons are becoming reusable platform controls",{},{"id":1253,"data":2621,"type":218,"tunes":2623},{"text":2622},"Governance metrics should not reward paperwork volume. The useful measure is whether decision quality, traceability, risk detection and safe delivery improve.",{},{"id":1258,"data":2625,"type":42,"tunes":2627},{"text":2626,"level":247},"A practical AI governance implementation sequence",{},{"id":1263,"data":2629,"type":320,"tunes":2668},{"steps":2630,"title":2667,"orientation":319},[2631,2634,2637,2640,2643,2646,2649,2652,2655,2658,2661,2664],{"label":2632,"description":2633},"1. Define governance scope","Decide which internally built, purchased, embedded and experimental AI systems are covered.",{"label":2635,"description":2636},"2. Create the AI inventory","Capture owners, use cases, models\u002Fproviders, data, tools, users, lifecycle state and risk class.",{"label":2638,"description":2639},"3. Define decision rights","Name who can approve providers, data use, risk acceptance, exceptions, deployment and retirement.",{"label":2641,"description":2642},"4. Establish risk tiers","Map consequence and exposure to different control requirements.",{"label":2644,"description":2645},"5. Define reusable minimum controls","Set baseline requirements for identity, permissions, data, security, evaluation, logging and human oversight.",{"label":2647,"description":2648},"6. Connect governance to architecture","Turn policy into platform\u002Fruntime controls that teams cannot accidentally bypass.",{"label":2650,"description":2651},"7. Build evidence-based gates","Require relevant evaluation, security, privacy, architecture and compliance evidence before lifecycle transitions.",{"label":2653,"description":2654},"8. Govern model\u002Fprovider change","Track versions, deprecations and material changes with regression evidence.",{"label":2656,"description":2657},"9. Add monitoring and incident triggers","Define which production signals force investigation, restriction or suspension.",{"label":2659,"description":2660},"10. Formalize exceptions","Require scope, owner, residual risk, compensating controls and expiry.",{"label":2662,"description":2663},"11. Audit decisions and execution","Retain proportionate evidence that links owners, configuration, permissions, evaluations and significant actions.",{"label":2665,"description":2666},"12. Improve the governance system","Use incidents, delays and repeated exceptions to revise controls and platform patterns.","Build governance from visibility to control",{},{"id":1305,"data":2670,"type":42,"tunes":2672},{"text":2671,"level":247},"AI governance checklist",{},{"id":1310,"data":2674,"type":377,"tunes":2724},{"content":2675,"stretched":43,"withHeadings":14},[2676,2679,2682,2685,2688,2691,2694,2697,2700,2703,2706,2709,2712,2715,2718,2721],[2677,2678],"Question","Expected governance evidence",[2680,2681],"Why does this AI system exist?","Purpose, business owner and intended outcome",[2683,2684],"Who owns technical operation?","Named technical\u002Fplatform owner",[2686,2687],"Which model\u002Fprovider\u002Fversion is used?","Registered and versioned dependency",[2689,2690],"Which data may enter the system?","Classification, authority and permitted-use decision",[2692,2693],"Which identities may use it?","Authentication and authorization model",[2695,2696],"Which actions may it perform?","Tool\u002Fpermission matrix and autonomy boundary",[2698,2699],"What is the risk tier?","Documented classification with rationale",[2701,2702],"Which controls are mandatory?","Risk-tier control baseline",[2704,2705],"How was it evaluated?","Representative tests and acceptance criteria",[2707,2708],"Who accepted residual risk?","Named accountable authority",[2710,2711],"What requires human review?","Explicit oversight\u002Fapproval rules",[2713,2714],"What gets logged?","Audit\u002Fobservability policy proportional to consequence",[2716,2717],"What triggers re-review?","Model\u002Fprovider\u002Fdata\u002Ftool\u002Fregulatory\u002Fmaterial-change events",[2719,2720],"How can it be suspended?","Operational kill\u002Frestriction path and owner",[2722,2723],"How is it retired?","Credential, data, derivative, endpoint and record cleanup",{},{"id":1363,"data":2726,"type":42,"tunes":2728},{"text":2727,"level":247},"Common misconceptions",{},{"id":1368,"data":2730,"type":377,"tunes":2765},{"content":2731,"stretched":43,"withHeadings":14},[2732,2735,2738,2741,2744,2747,2750,2753,2756,2759,2762],[2733,2734],"Misconception","Correction",[2736,2737],"“AI governance is compliance.”","Compliance is one governance input; governance also covers ownership, architecture, permissions, quality, risk and lifecycle decisions.",[2739,2740],"“Governance means a review committee.”","Committees can approve exceptions or high-risk systems, but many controls should be embedded in normal delivery and platform architecture.",[2742,2743],"“An approved model is safe for every use.”","Risk belongs to the use case and system context, not only the model.",[2745,2746],"“A vendor handles governance for us.”","A provider controls part of the stack; the organization still owns its use case, data, permissions and business consequences.",[2748,2749],"“Human-in-the-loop automatically solves risk.”","Oversight only works when reviewers have authority, context and intervention capability.",[2751,2752],"“Logging everything gives auditability.”","Auditability requires reconstructable relevant evidence with controlled retention and access.",[2754,2755],"“Governance blocks innovation.”","Poor governance can block delivery; well-designed governance creates reusable safe paths and clearer decision ownership.",[2757,2758],"“Low-risk pilots need no governance.”","They can use lightweight governance, but inventory, ownership and data\u002Ftool boundaries still matter.",[2760,2761],"“Local AI needs less governance.”","Local hosting can change privacy\u002Fprovider risk, but model quality, permissions, security and lifecycle governance remain.",[2763,2764],"“Once approved, the system stays approved.”","Model, provider, data, regulation and use can change; governance decisions need review triggers.",{},{"id":1406,"data":2767,"type":42,"tunes":2769},{"text":2768,"level":247},"Edge cases and limitations",{},{"id":1411,"data":2771,"type":218,"tunes":2773},{"text":2772},"Very small organizations may not need a dedicated AI governance function. The same principles can be implemented through lightweight architecture decisions, risk registers, owner mappings and release gates.",{},{"id":1416,"data":2775,"type":218,"tunes":2777},{"text":2776},"Highly regulated organizations may need much more formal governance, independent assurance, documented conformity processes and legal interpretation than this architecture-level article describes.",{},{"id":1421,"data":2779,"type":218,"tunes":2781},{"text":2780},"Open-source and self-hosted models reduce some provider dependencies but create others: patching, model provenance, evaluation, infrastructure security, licensing and operational ownership.",{},{"id":1426,"data":2783,"type":218,"tunes":2785},{"text":2784},"General-purpose AI models can be used across many contexts. Governance should avoid assuming that provider-level model controls fully determine downstream application risk.",{},{"id":1431,"data":2787,"type":218,"tunes":2789},{"text":2788},"No governance framework guarantees that an AI system is safe or correct. Governance improves accountability and decision quality; technical validation, monitoring and human judgment remain necessary.",{},{"id":1436,"data":2791,"type":42,"tunes":2793},{"text":2792,"level":247},"What would change this answer?",{},{"id":1441,"data":2795,"type":218,"tunes":2797},{"text":2796},"The exact control set changes with law, industry, organization size, data sensitivity, autonomy, deployment model and business consequence.",{},{"id":1446,"data":2799,"type":218,"tunes":2801},{"text":2800},"NIST is currently revising AI RMF 1.0, so future NIST terminology or recommended practices may change. ISO standards can also be revised, and EU AI Act guidance and transition details continue to evolve.",{},{"id":1451,"data":2803,"type":218,"tunes":2805},{"text":2804},"The stable architectural principle is that AI decisions need explicit owners, evidence, permissions, risk treatment and lifecycle review rather than being hidden inside model or application configuration.",{},{"id":1456,"data":2807,"type":42,"tunes":2809},{"text":2808,"level":247},"Related canonical knowledge",{},{"id":1461,"data":2811,"type":218,"tunes":2813},{"text":2812},"AI governance depends on concepts already separated elsewhere in this knowledge graph: Source of Truth determines authority, RBAC and tenant isolation constrain access, context engineering controls model-visible information, and agentic architecture defines how tools and actions enter an execution loop.",{},{"id":1466,"data":2815,"type":218,"tunes":2817},{"text":2816},"Enterprise AI Architecture is the parent organizational architecture concept. Governance is the operating control layer that determines how those enterprise AI components may be introduced, changed and retired.",{},{"id":1471,"data":2819,"type":218,"tunes":2821},{"text":2820},"Agentic systems increase governance requirements because model decisions can become real side effects. Permission, approval and audit controls must therefore exist outside the model itself.",{},{"id":1476,"data":2823,"type":1482,"tunes":2828},{"url":2824,"title":2825,"excerpt":2826,"ctaLabel":2827},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","AI Agent Reliability: Why the Final Answer Is Not Enough","Agent governance requires evidence about execution trajectories, tool use, state changes and recoverability — not only final output quality.","Read the agent reliability article",{},{"id":1485,"data":2830,"type":1482,"tunes":2835},{"url":2831,"title":2832,"excerpt":2833,"ctaLabel":2834},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context","AI Agent Memory Is Not RAG: How to Separate Memory, Retrieval, State and Context","Governance needs different policies for durable memory, authoritative state, retrieved information and temporary model context.","Read the memory architecture article",{},{"id":1493,"data":2837,"type":1482,"tunes":2842},{"url":2838,"title":2839,"excerpt":2840,"ctaLabel":2841},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers","The Answer Validity Boundary: The Missing Layer Between Relevance and Reliable AI Answers","Governance decisions should preserve the conditions under which evidence and approval remain valid, including version, scope, source and time.","Read the Answer Validity Boundary",{},{"id":1501,"data":2844,"type":42,"tunes":2846},{"text":2845,"level":247},"Frequently asked questions",{},{"id":1506,"data":2848,"type":1506,"tunes":2878},{"items":2849,"title":2877},[2850,2853,2856,2859,2862,2865,2868,2871,2874],{"id":1510,"answer":2851,"question":2852},"AI governance is the system of ownership, decision rights, controls and evidence used to manage how AI systems are developed, acquired, deployed, operated, changed and retired.","What is AI governance?",{"id":1514,"answer":2854,"question":2855},"No. Risk management identifies, assesses and treats risk. Governance defines who must do that work, which decisions require it and what evidence or authority is required.","Is AI governance the same as AI risk management?",{"id":1518,"answer":2857,"question":2858},"No. Compliance concerns applicable legal, regulatory, contractual or internal obligations. Governance integrates compliance with architecture, security, data, quality, permissions and business ownership.","Is AI governance the same as compliance?",{"id":1522,"answer":2860,"question":2861},"Enterprise AI Architecture defines how AI capabilities and systems fit into the organization. AI governance defines the decision and control system governing how those components may be introduced, operated and changed.","What is the difference between AI governance and Enterprise AI Architecture?",{"id":1526,"answer":2863,"question":2864},"Yes, but not necessarily a dedicated department. Lightweight inventory, ownership, permissions, evaluation and change controls can implement the same principles.","Do small companies need AI governance?",{"id":1530,"answer":2866,"question":2867},"At minimum: use case, owners, model\u002Fprovider\u002Fversion, data classes, users, tools\u002Factions, permissions, risk classification, evaluation status, lifecycle state and review triggers.","What should an AI inventory contain?",{"id":1534,"answer":2869,"question":2870},"No. Risk depends on the application context: data, users, tools, autonomy, consequences and business process.","Does using an approved model mean a use case is approved?",{"id":1538,"answer":2872,"question":2873},"The organization can reconstruct relevant ownership, approved configuration, model\u002Fprovider\u002Fversion, data\u002Fpermission context, evaluation evidence, significant actions and lifecycle decisions.","What makes an AI system auditable?",{"id":1542,"answer":2875,"question":2876},"Use risk-based review intervals plus event triggers such as model\u002Fprovider changes, new data, new tools, incidents, material performance change or regulatory updates.","How often should AI governance decisions be reviewed?","AI governance FAQ",{},{"id":1548,"data":2880,"type":42,"tunes":2882},{"text":2881,"level":247},"Glossary",{},{"id":1553,"data":2884,"type":1553,"tunes":2922},{"title":2885,"entries":2886},"Key AI governance terms",[2887,2889,2892,2895,2898,2901,2904,2907,2910,2913,2916,2919],{"term":1875,"anchor":1558,"definition":2888},"Organizational system of ownership, decision rights, controls and evidence governing the AI lifecycle.",{"term":2890,"anchor":1562,"definition":2891},"AI management system","Interrelated organizational policies, objectives and processes for responsible development, provision or use of AI; ISO\u002FIEC 42001 specifies requirements for such a system.",{"term":2893,"anchor":1566,"definition":2894},"AI inventory","Registry of AI systems, models, providers, use cases, owners, data, risk classifications and lifecycle state.",{"term":2896,"anchor":1570,"definition":2897},"Risk owner","Named authority accountable for deciding how a defined risk is treated or whether residual risk is accepted.",{"term":2899,"anchor":1574,"definition":2900},"Control","Technical, organizational or procedural measure intended to prevent, detect, reduce or respond to risk.",{"term":2902,"anchor":1578,"definition":2903},"Governance gate","Lifecycle decision point at which defined evidence and authority are required before proceeding.",{"term":2905,"anchor":1582,"definition":2906},"Residual risk","Risk that remains after controls or mitigation have been applied.",{"term":2908,"anchor":1586,"definition":2909},"Exception","Explicit, scoped and usually time-bounded authorization to deviate from a normal governance requirement.",{"term":2911,"anchor":1590,"definition":2912},"Auditability","Ability to reconstruct relevant decisions, configurations, evidence, identities and execution events.",{"term":2914,"anchor":1594,"definition":2915},"Model governance","Controls and decisions covering model selection, versioning, evaluation, permitted use, change and retirement.",{"term":2917,"anchor":1598,"definition":2918},"Provider governance","Controls covering external or internal AI provider dependencies, data handling, security, contracts, lifecycle and exit.",{"term":2920,"anchor":1602,"definition":2921},"Human oversight","Designed human review or intervention capability for AI decisions or actions at defined points.",{},{"id":1606,"data":2924,"type":42,"tunes":2926},{"text":2925,"level":247},"Conclusion",{},{"id":1611,"data":2928,"type":218,"tunes":2930},{"text":2929},"AI governance is the organizational control plane around AI. It gives names and evidence to decisions that otherwise remain hidden inside code, provider settings, prompts or informal team judgment.",{},{"id":1616,"data":2932,"type":218,"tunes":2934},{"text":2933},"Strong governance connects the complete system: business purpose, models, providers, data authority, identity, permissions, evaluation, risk, compliance, monitoring, incidents, change and retirement.",{},{"id":1621,"data":2936,"type":218,"tunes":2938},{"text":2937},"The practical goal is not maximum process. It is the minimum governance structure that makes important AI decisions owned, evidence-based, enforceable, reviewable and auditable throughout the lifecycle.",{},{"id":1626,"data":2940,"type":42,"tunes":2942},{"text":2941,"level":247},"Primary sources and current references",{},{"id":1631,"data":2944,"type":218,"tunes":2946},{"text":2945},"The sources below provide current external grounding for AI management, risk and regulation. Project sections are original implementation\u002Fproject evidence and are explicitly distinguished from formal standards or certified governance systems.",{},{"id":1636,"data":2948,"type":1643,"tunes":2953},{"link":1638,"meta":2949},{"image":2950,"title":2951,"description":2952},{"url":355},"NIST — AI Risk Management Framework","Current NIST hub for AI RMF 1.0, the ongoing revision, the GenAI Profile and related risk-management resources.",{},{"id":1646,"data":2955,"type":1643,"tunes":2960},{"link":1648,"meta":2956},{"image":2957,"title":2958,"description":2959},{"url":355},"NIST AIRC — AI RMF Core","Official AI RMF Core describing GOVERN, MAP, MEASURE and MANAGE, with GOVERN as a cross-cutting lifecycle function.",{},{"id":1655,"data":2962,"type":1643,"tunes":2967},{"link":1657,"meta":2963},{"image":2964,"title":2965,"description":2966},{"url":355},"NIST — AI RMF Playbook","Suggested actions for operationalizing trustworthiness and risk management across the AI lifecycle.",{},{"id":1664,"data":2969,"type":1643,"tunes":2974},{"link":1666,"meta":2970},{"image":2971,"title":2972,"description":2973},{"url":355},"NIST AI 600-1 — Generative AI Profile","NIST companion profile applying AI RMF concepts to generative-AI risks and lifecycle management.",{},{"id":1673,"data":2976,"type":1643,"tunes":2981},{"link":1675,"meta":2977},{"image":2978,"title":2979,"description":2980},{"url":355},"ISO\u002FIEC 42001:2023 — AI management systems","International standard specifying requirements for establishing, implementing, maintaining and continually improving an AI management system.",{},{"id":1682,"data":2983,"type":1643,"tunes":2988},{"link":1684,"meta":2984},{"image":2985,"title":2986,"description":2987},{"url":355},"ISO\u002FIEC 23894:2023 — AI risk management","International guidance for integrating AI-specific risk management into organizational activities and functions.",{},{"id":1691,"data":2990,"type":1643,"tunes":2995},{"link":1693,"meta":2991},{"image":2992,"title":2993,"description":2994},{"url":355},"European Commission — AI Act","Current Commission overview of the EU AI Act, application timeline and implementation framework.",{},{"id":1700,"data":2997,"type":1643,"tunes":3002},{"link":1702,"meta":2998},{"image":2999,"title":3000,"description":3001},{"url":355},"European Commission — Navigating the AI Act","Current FAQ covering governance, enforcement, implementation and the evolving application timeline.",{},{"id":1709,"data":3004,"type":1643,"tunes":3009},{"link":1711,"meta":3005},{"image":3006,"title":3007,"description":3008},{"url":355},"European Commission — General-purpose AI obligations","Current overview of documentation, copyright, training-content and systemic-risk obligations for GPAI providers.",{},"2.31.6","AI governance defines who can approve, operate, change and audit AI systems across models, providers, data, permissions, risk, evaluation and the full lifecycle.",{"lang":7,"title":208,"content":210,"contentJson":3013,"excerpt":1718},{"time":212,"blocks":3014,"version":1717},[3015,3018,3021,3024,3027,3030,3033,3036,3039,3042,3045,3048,3051,3054,3066,3069,3072,3075,3078,3081,3100,3103,3106,3109,3112,3115,3125,3128,3131,3134,3137,3140,3143,3146,3149,3152,3170,3173,3176,3179,3182,3185,3199,3202,3205,3208,3211,3214,3217,3220,3223,3226,3229,3232,3235,3238,3241,3244,3247,3250,3253,3266,3269,3272,3275,3278,3281,3284,3287,3290,3293,3296,3299,3311,3314,3317,3320,3323,3326,3329,3332,3335,3338,3341,3344,3347,3359,3362,3365,3368,3371,3374,3377,3380,3383,3386,3389,3392,3395,3398,3401,3404,3407,3410,3425,3428,3431,3434,3437,3440,3443,3446,3449,3452,3455,3458,3461,3464,3467,3470,3473,3476,3479,3491,3494,3512,3515,3518,3521,3524,3527,3530,3544,3547,3550,3566,3569,3589,3592,3607,3610,3613,3616,3619,3622,3625,3628,3631,3634,3637,3640,3643,3646,3649,3652,3655,3658,3661,3674,3677,3693,3696,3699,3702,3705,3708,3711,3716,3721,3726,3731,3736,3741,3746,3751],{"id":215,"data":3016,"type":218,"tunes":3017},{"text":217},{},{"id":221,"data":3019,"type":226,"tunes":3020},{"body":223,"title":224,"variant":225},{},{"id":229,"data":3022,"type":226,"tunes":3023},{"body":231,"title":232,"variant":233},{},{"id":236,"data":3025,"type":226,"tunes":3026},{"body":238,"title":239,"variant":240},{},{"id":243,"data":3028,"type":248,"tunes":3029},{"title":245,"maxLevel":246,"minLevel":247},{},{"id":251,"data":3031,"type":42,"tunes":3032},{"text":253,"level":247},{},{"id":256,"data":3034,"type":218,"tunes":3035},{"text":258},{},{"id":261,"data":3037,"type":218,"tunes":3038},{"text":263},{},{"id":266,"data":3040,"type":218,"tunes":3041},{"text":268},{},{"id":271,"data":3043,"type":42,"tunes":3044},{"text":273,"level":247},{},{"id":276,"data":3046,"type":218,"tunes":3047},{"text":278},{},{"id":281,"data":3049,"type":218,"tunes":3050},{"text":283},{},{"id":286,"data":3052,"type":218,"tunes":3053},{"text":288},{},{"id":291,"data":3055,"type":320,"tunes":3065},{"steps":3056,"title":318,"orientation":319},[3057,3058,3059,3060,3061,3062,3063,3064],{"label":295,"description":296},{"label":298,"description":299},{"label":301,"description":302},{"label":304,"description":305},{"label":307,"description":308},{"label":310,"description":311},{"label":313,"description":314},{"label":316,"description":317},{},{"id":323,"data":3067,"type":42,"tunes":3068},{"text":325,"level":247},{},{"id":328,"data":3070,"type":218,"tunes":3071},{"text":330},{},{"id":333,"data":3073,"type":218,"tunes":3074},{"text":335},{},{"id":338,"data":3076,"type":218,"tunes":3077},{"text":340},{},{"id":343,"data":3079,"type":42,"tunes":3080},{"text":345,"level":247},{},{"id":348,"data":3082,"type":385,"tunes":3099},{"rows":3083,"title":376,"layout":377,"columns":3096},[3084,3086,3088,3090,3092,3094],{"id":352,"label":353,"values":3085},[355,355],{"id":357,"label":358,"values":3087},[355,355],{"id":361,"label":362,"values":3089},[355,355],{"id":365,"label":366,"values":3091},[355,355],{"id":369,"label":370,"values":3093},[355,355],{"id":373,"label":374,"values":3095},[355,355],[3097,3098],{"id":380,"label":381},{"id":383,"label":384},{},{"id":388,"data":3101,"type":42,"tunes":3102},{"text":390,"level":247},{},{"id":393,"data":3104,"type":218,"tunes":3105},{"text":395},{},{"id":398,"data":3107,"type":218,"tunes":3108},{"text":400},{},{"id":403,"data":3110,"type":218,"tunes":3111},{"text":405},{},{"id":408,"data":3113,"type":42,"tunes":3114},{"text":410,"level":247},{},{"id":413,"data":3116,"type":377,"tunes":3124},{"content":3117,"stretched":43,"withHeadings":14},[3118,3119,3120,3121,3122,3123],[417,418,419],[421,422,423],[425,426,427],[429,430,431],[433,434,435],[437,438,439],{},{"id":442,"data":3126,"type":218,"tunes":3127},{"text":444},{},{"id":447,"data":3129,"type":42,"tunes":3130},{"text":449,"level":247},{},{"id":452,"data":3132,"type":218,"tunes":3133},{"text":454},{},{"id":457,"data":3135,"type":218,"tunes":3136},{"text":459},{},{"id":462,"data":3138,"type":226,"tunes":3139},{"body":464,"title":465,"variant":233},{},{"id":468,"data":3141,"type":42,"tunes":3142},{"text":470,"level":247},{},{"id":473,"data":3144,"type":218,"tunes":3145},{"text":475},{},{"id":478,"data":3147,"type":218,"tunes":3148},{"text":480},{},{"id":483,"data":3150,"type":218,"tunes":3151},{"text":485},{},{"id":488,"data":3153,"type":377,"tunes":3169},{"content":3154,"stretched":43,"withHeadings":14},[3155,3156,3157,3158,3159,3160,3161,3162,3163,3164,3165,3166,3167,3168],[492,493],[495,496],[498,499],[501,502],[504,505],[507,508],[510,511],[513,514],[516,517],[519,520],[522,523],[525,526],[528,529],[531,532],{},{"id":535,"data":3171,"type":42,"tunes":3172},{"text":537,"level":247},{},{"id":540,"data":3174,"type":218,"tunes":3175},{"text":542},{},{"id":545,"data":3177,"type":218,"tunes":3178},{"text":547},{},{"id":550,"data":3180,"type":218,"tunes":3181},{"text":552},{},{"id":555,"data":3183,"type":42,"tunes":3184},{"text":557,"level":247},{},{"id":560,"data":3186,"type":377,"tunes":3198},{"content":3187,"stretched":43,"withHeadings":14},[3188,3189,3190,3191,3192,3193,3194,3195,3196,3197],[564,565],[567,568],[570,571],[573,574],[576,577],[579,580],[582,583],[585,586],[588,589],[591,592],{},{"id":595,"data":3200,"type":42,"tunes":3201},{"text":597,"level":247},{},{"id":600,"data":3203,"type":218,"tunes":3204},{"text":602},{},{"id":605,"data":3206,"type":218,"tunes":3207},{"text":607},{},{"id":610,"data":3209,"type":218,"tunes":3210},{"text":612},{},{"id":615,"data":3212,"type":42,"tunes":3213},{"text":617,"level":247},{},{"id":620,"data":3215,"type":218,"tunes":3216},{"text":622},{},{"id":625,"data":3218,"type":218,"tunes":3219},{"text":627},{},{"id":630,"data":3221,"type":218,"tunes":3222},{"text":632},{},{"id":635,"data":3224,"type":42,"tunes":3225},{"text":637,"level":247},{},{"id":640,"data":3227,"type":218,"tunes":3228},{"text":642},{},{"id":645,"data":3230,"type":218,"tunes":3231},{"text":647},{},{"id":650,"data":3233,"type":218,"tunes":3234},{"text":652},{},{"id":655,"data":3236,"type":42,"tunes":3237},{"text":657,"level":247},{},{"id":660,"data":3239,"type":218,"tunes":3240},{"text":662},{},{"id":665,"data":3242,"type":218,"tunes":3243},{"text":667},{},{"id":670,"data":3245,"type":218,"tunes":3246},{"text":672},{},{"id":675,"data":3248,"type":42,"tunes":3249},{"text":677,"level":247},{},{"id":680,"data":3251,"type":218,"tunes":3252},{"text":682},{},{"id":685,"data":3254,"type":377,"tunes":3265},{"content":3255,"stretched":43,"withHeadings":14},[3256,3257,3258,3259,3260,3261,3262,3263,3264],[689,690,691],[693,694,695],[697,698,699],[701,702,703],[705,706,707],[709,710,711],[713,714,715],[717,718,719],[721,722,723],{},{"id":726,"data":3267,"type":218,"tunes":3268},{"text":728},{},{"id":731,"data":3270,"type":42,"tunes":3271},{"text":733,"level":247},{},{"id":736,"data":3273,"type":218,"tunes":3274},{"text":738},{},{"id":741,"data":3276,"type":218,"tunes":3277},{"text":743},{},{"id":746,"data":3279,"type":218,"tunes":3280},{"text":748},{},{"id":751,"data":3282,"type":42,"tunes":3283},{"text":753,"level":247},{},{"id":756,"data":3285,"type":218,"tunes":3286},{"text":758},{},{"id":761,"data":3288,"type":218,"tunes":3289},{"text":763},{},{"id":766,"data":3291,"type":218,"tunes":3292},{"text":768},{},{"id":771,"data":3294,"type":226,"tunes":3295},{"body":773,"title":774,"variant":775},{},{"id":778,"data":3297,"type":42,"tunes":3298},{"text":780,"level":247},{},{"id":783,"data":3300,"type":320,"tunes":3310},{"steps":3301,"title":810,"orientation":319},[3302,3303,3304,3305,3306,3307,3308,3309],{"label":787,"description":788},{"label":790,"description":791},{"label":793,"description":794},{"label":796,"description":797},{"label":799,"description":800},{"label":802,"description":803},{"label":805,"description":806},{"label":808,"description":809},{},{"id":813,"data":3312,"type":42,"tunes":3313},{"text":815,"level":247},{},{"id":818,"data":3315,"type":218,"tunes":3316},{"text":820},{},{"id":823,"data":3318,"type":218,"tunes":3319},{"text":825},{},{"id":828,"data":3321,"type":218,"tunes":3322},{"text":830},{},{"id":833,"data":3324,"type":42,"tunes":3325},{"text":835,"level":247},{},{"id":838,"data":3327,"type":218,"tunes":3328},{"text":840},{},{"id":843,"data":3330,"type":218,"tunes":3331},{"text":845},{},{"id":848,"data":3333,"type":218,"tunes":3334},{"text":850},{},{"id":853,"data":3336,"type":42,"tunes":3337},{"text":855,"level":247},{},{"id":858,"data":3339,"type":218,"tunes":3340},{"text":860},{},{"id":863,"data":3342,"type":218,"tunes":3343},{"text":865},{},{"id":868,"data":3345,"type":218,"tunes":3346},{"text":870},{},{"id":873,"data":3348,"type":377,"tunes":3358},{"content":3349,"stretched":43,"withHeadings":14},[3350,3351,3352,3353,3354,3355,3356,3357],[877,878],[880,881],[883,884],[886,887],[889,890],[892,893],[895,896],[898,899],{},{"id":902,"data":3360,"type":42,"tunes":3361},{"text":904,"level":247},{},{"id":907,"data":3363,"type":218,"tunes":3364},{"text":909},{},{"id":912,"data":3366,"type":218,"tunes":3367},{"text":914},{},{"id":917,"data":3369,"type":218,"tunes":3370},{"text":919},{},{"id":922,"data":3372,"type":42,"tunes":3373},{"text":924,"level":247},{},{"id":927,"data":3375,"type":218,"tunes":3376},{"text":929},{},{"id":932,"data":3378,"type":218,"tunes":3379},{"text":934},{},{"id":937,"data":3381,"type":218,"tunes":3382},{"text":939},{},{"id":942,"data":3384,"type":42,"tunes":3385},{"text":944,"level":247},{},{"id":947,"data":3387,"type":218,"tunes":3388},{"text":949},{},{"id":952,"data":3390,"type":218,"tunes":3391},{"text":954},{},{"id":957,"data":3393,"type":218,"tunes":3394},{"text":959},{},{"id":962,"data":3396,"type":42,"tunes":3397},{"text":964,"level":247},{},{"id":967,"data":3399,"type":218,"tunes":3400},{"text":969},{},{"id":972,"data":3402,"type":218,"tunes":3403},{"text":974},{},{"id":977,"data":3405,"type":218,"tunes":3406},{"text":979},{},{"id":982,"data":3408,"type":42,"tunes":3409},{"text":984,"level":247},{},{"id":987,"data":3411,"type":385,"tunes":3424},{"rows":3412,"title":1006,"layout":377,"columns":3421},[3413,3415,3417,3419],{"id":991,"label":992,"values":3414},[355,355],{"id":995,"label":996,"values":3416},[355,355],{"id":999,"label":1000,"values":3418},[355,355],{"id":1003,"label":1004,"values":3420},[355,355],[3422,3423],{"id":1009,"label":1010},{"id":1012,"label":1013},{},{"id":1016,"data":3426,"type":218,"tunes":3427},{"text":1018},{},{"id":1021,"data":3429,"type":42,"tunes":3430},{"text":1023,"level":247},{},{"id":1026,"data":3432,"type":218,"tunes":3433},{"text":1028},{},{"id":1031,"data":3435,"type":218,"tunes":3436},{"text":1033},{},{"id":1036,"data":3438,"type":218,"tunes":3439},{"text":1038},{},{"id":1041,"data":3441,"type":42,"tunes":3442},{"text":1043,"level":247},{},{"id":1046,"data":3444,"type":42,"tunes":3445},{"text":1048,"level":246},{},{"id":1051,"data":3447,"type":226,"tunes":3448},{"body":1053,"title":1054,"variant":240},{},{"id":1057,"data":3450,"type":218,"tunes":3451},{"text":1059},{},{"id":1062,"data":3453,"type":218,"tunes":3454},{"text":1064},{},{"id":1067,"data":3456,"type":218,"tunes":3457},{"text":1069},{},{"id":1072,"data":3459,"type":42,"tunes":3460},{"text":1074,"level":246},{},{"id":1077,"data":3462,"type":218,"tunes":3463},{"text":1079},{},{"id":1082,"data":3465,"type":218,"tunes":3466},{"text":1084},{},{"id":1087,"data":3468,"type":42,"tunes":3469},{"text":1089,"level":246},{},{"id":1092,"data":3471,"type":218,"tunes":3472},{"text":1094},{},{"id":1097,"data":3474,"type":218,"tunes":3475},{"text":1099},{},{"id":1102,"data":3477,"type":218,"tunes":3478},{"text":1104},{},{"id":1107,"data":3480,"type":377,"tunes":3490},{"content":3481,"stretched":43,"withHeadings":14},[3482,3483,3484,3485,3486,3487,3488,3489],[1111,1112],[1114,1115],[1117,1118],[1120,1121],[1123,1124],[1126,1127],[1129,1130],[1132,1133],{},{"id":1136,"data":3492,"type":42,"tunes":3493},{"text":1138,"level":247},{},{"id":1141,"data":3495,"type":377,"tunes":3511},{"content":3496,"stretched":43,"withHeadings":14},[3497,3498,3499,3500,3501,3502,3503,3504,3505,3506,3507,3508,3509,3510],[1145,1146],[1148,1149],[1151,1152],[1154,1155],[1157,1158],[1160,1161],[1163,1164],[1166,1167],[1169,1170],[1172,1173],[1175,1176],[1178,1179],[1181,1182],[1184,1185],{},{"id":1188,"data":3513,"type":42,"tunes":3514},{"text":1190,"level":247},{},{"id":1193,"data":3516,"type":218,"tunes":3517},{"text":1195},{},{"id":1198,"data":3519,"type":218,"tunes":3520},{"text":1200},{},{"id":1203,"data":3522,"type":218,"tunes":3523},{"text":1205},{},{"id":1208,"data":3525,"type":42,"tunes":3526},{"text":1210,"level":247},{},{"id":1213,"data":3528,"type":218,"tunes":3529},{"text":1215},{},{"id":1218,"data":3531,"type":377,"tunes":3543},{"content":3532,"stretched":43,"withHeadings":14},[3533,3534,3535,3536,3537,3538,3539,3540,3541,3542],[1222,1223],[1225,1226],[1228,1229],[1231,1232],[1234,1235],[1237,1238],[1240,1241],[1243,1244],[1246,1247],[1249,1250],{},{"id":1253,"data":3545,"type":218,"tunes":3546},{"text":1255},{},{"id":1258,"data":3548,"type":42,"tunes":3549},{"text":1260,"level":247},{},{"id":1263,"data":3551,"type":320,"tunes":3565},{"steps":3552,"title":1302,"orientation":319},[3553,3554,3555,3556,3557,3558,3559,3560,3561,3562,3563,3564],{"label":1267,"description":1268},{"label":1270,"description":1271},{"label":1273,"description":1274},{"label":1276,"description":1277},{"label":1279,"description":1280},{"label":1282,"description":1283},{"label":1285,"description":1286},{"label":1288,"description":1289},{"label":1291,"description":1292},{"label":1294,"description":1295},{"label":1297,"description":1298},{"label":1300,"description":1301},{},{"id":1305,"data":3567,"type":42,"tunes":3568},{"text":1307,"level":247},{},{"id":1310,"data":3570,"type":377,"tunes":3588},{"content":3571,"stretched":43,"withHeadings":14},[3572,3573,3574,3575,3576,3577,3578,3579,3580,3581,3582,3583,3584,3585,3586,3587],[1314,1315],[1317,1318],[1320,1321],[1323,1324],[1326,1327],[1329,1330],[1332,1333],[1335,1336],[1338,1339],[1341,1342],[1344,1345],[1347,1348],[1350,1351],[1353,1354],[1356,1357],[1359,1360],{},{"id":1363,"data":3590,"type":42,"tunes":3591},{"text":1365,"level":247},{},{"id":1368,"data":3593,"type":377,"tunes":3606},{"content":3594,"stretched":43,"withHeadings":14},[3595,3596,3597,3598,3599,3600,3601,3602,3603,3604,3605],[1372,1373],[1375,1376],[1378,1379],[1381,1382],[1384,1385],[1387,1388],[1390,1391],[1393,1394],[1396,1397],[1399,1400],[1402,1403],{},{"id":1406,"data":3608,"type":42,"tunes":3609},{"text":1408,"level":247},{},{"id":1411,"data":3611,"type":218,"tunes":3612},{"text":1413},{},{"id":1416,"data":3614,"type":218,"tunes":3615},{"text":1418},{},{"id":1421,"data":3617,"type":218,"tunes":3618},{"text":1423},{},{"id":1426,"data":3620,"type":218,"tunes":3621},{"text":1428},{},{"id":1431,"data":3623,"type":218,"tunes":3624},{"text":1433},{},{"id":1436,"data":3626,"type":42,"tunes":3627},{"text":1438,"level":247},{},{"id":1441,"data":3629,"type":218,"tunes":3630},{"text":1443},{},{"id":1446,"data":3632,"type":218,"tunes":3633},{"text":1448},{},{"id":1451,"data":3635,"type":218,"tunes":3636},{"text":1453},{},{"id":1456,"data":3638,"type":42,"tunes":3639},{"text":1458,"level":247},{},{"id":1461,"data":3641,"type":218,"tunes":3642},{"text":1463},{},{"id":1466,"data":3644,"type":218,"tunes":3645},{"text":1468},{},{"id":1471,"data":3647,"type":218,"tunes":3648},{"text":1473},{},{"id":1476,"data":3650,"type":1482,"tunes":3651},{"url":1478,"title":1479,"excerpt":1480,"ctaLabel":1481},{},{"id":1485,"data":3653,"type":1482,"tunes":3654},{"url":1487,"title":1488,"excerpt":1489,"ctaLabel":1490},{},{"id":1493,"data":3656,"type":1482,"tunes":3657},{"url":1495,"title":1496,"excerpt":1497,"ctaLabel":1498},{},{"id":1501,"data":3659,"type":42,"tunes":3660},{"text":1503,"level":247},{},{"id":1506,"data":3662,"type":1506,"tunes":3673},{"items":3663,"title":1545},[3664,3665,3666,3667,3668,3669,3670,3671,3672],{"id":1510,"answer":1511,"question":1512},{"id":1514,"answer":1515,"question":1516},{"id":1518,"answer":1519,"question":1520},{"id":1522,"answer":1523,"question":1524},{"id":1526,"answer":1527,"question":1528},{"id":1530,"answer":1531,"question":1532},{"id":1534,"answer":1535,"question":1536},{"id":1538,"answer":1539,"question":1540},{"id":1542,"answer":1543,"question":1544},{},{"id":1548,"data":3675,"type":42,"tunes":3676},{"text":1550,"level":247},{},{"id":1553,"data":3678,"type":1553,"tunes":3692},{"title":1555,"entries":3679},[3680,3681,3682,3683,3684,3685,3686,3687,3688,3689,3690,3691],{"term":381,"anchor":1558,"definition":1559},{"term":1561,"anchor":1562,"definition":1563},{"term":1565,"anchor":1566,"definition":1567},{"term":1569,"anchor":1570,"definition":1571},{"term":1573,"anchor":1574,"definition":1575},{"term":1577,"anchor":1578,"definition":1579},{"term":1581,"anchor":1582,"definition":1583},{"term":1585,"anchor":1586,"definition":1587},{"term":1589,"anchor":1590,"definition":1591},{"term":1593,"anchor":1594,"definition":1595},{"term":1597,"anchor":1598,"definition":1599},{"term":1601,"anchor":1602,"definition":1603},{},{"id":1606,"data":3694,"type":42,"tunes":3695},{"text":1608,"level":247},{},{"id":1611,"data":3697,"type":218,"tunes":3698},{"text":1613},{},{"id":1616,"data":3700,"type":218,"tunes":3701},{"text":1618},{},{"id":1621,"data":3703,"type":218,"tunes":3704},{"text":1623},{},{"id":1626,"data":3706,"type":42,"tunes":3707},{"text":1628,"level":247},{},{"id":1631,"data":3709,"type":218,"tunes":3710},{"text":1633},{},{"id":1636,"data":3712,"type":1643,"tunes":3715},{"link":1638,"meta":3713},{"image":3714,"title":1641,"description":1642},{"url":355},{},{"id":1646,"data":3717,"type":1643,"tunes":3720},{"link":1648,"meta":3718},{"image":3719,"title":1651,"description":1652},{"url":355},{},{"id":1655,"data":3722,"type":1643,"tunes":3725},{"link":1657,"meta":3723},{"image":3724,"title":1660,"description":1661},{"url":355},{},{"id":1664,"data":3727,"type":1643,"tunes":3730},{"link":1666,"meta":3728},{"image":3729,"title":1669,"description":1670},{"url":355},{},{"id":1673,"data":3732,"type":1643,"tunes":3735},{"link":1675,"meta":3733},{"image":3734,"title":1678,"description":1679},{"url":355},{},{"id":1682,"data":3737,"type":1643,"tunes":3740},{"link":1684,"meta":3738},{"image":3739,"title":1687,"description":1688},{"url":355},{},{"id":1691,"data":3742,"type":1643,"tunes":3745},{"link":1693,"meta":3743},{"image":3744,"title":1696,"description":1697},{"url":355},{},{"id":1700,"data":3747,"type":1643,"tunes":3750},{"link":1702,"meta":3748},{"image":3749,"title":1705,"description":1706},{"url":355},{},{"id":1709,"data":3752,"type":1643,"tunes":3755},{"link":1711,"meta":3753},{"image":3754,"title":1714,"description":1715},{"url":355},{},"Post erfolgreich abgerufen",{"items":3758,"source":3843,"manualIds":3844,"manualMatchedIds":3845},[3759,3766,3773,3780,3787,3794,3801,3808,3815,3822,3829,3836],{"id":3760,"slug":3761,"title":3762,"excerpt":3763,"featuredImage":3764,"publishedAt":3765},"455","zbt-z8102ax-dual-sim-failover-test","ZBT Z8102AX 双SIM卡故障切换：有效功能、缺失功能及固件需改进之处","ZBT Z8102AX是一款双SIM卡5G OpenWrt路由器，但仅具备双SIM卡硬件并不等同于智能故障切换。该路由器能识别SIM卡并成功连接，但自动切换、调制解调器恢复、基于信号的决策以及清晰的故障切换逻辑仍需更深入的测试。","\u002Fuploads\u002F2026\u002F06\u002Fopenwrt-router-review-dual-sim-03-1781620592829-7t77j7.webp","2026-06-16T10:40:00.000Z",{"id":3767,"slug":3768,"title":3769,"excerpt":3770,"featuredImage":3771,"publishedAt":3772},"492","mcp-explained-what-it-connects-what-it-does-not-do-and-where-it-fits","MCP 解析：它连接什么、不做什么以及它适用于何处","模型上下文协议通过标准的客户端-服务器边界，将AI应用程序连接到外部工具、资源和提示。了解MCP能做什么、不能做什么，以及它在智能体架构中的定位。","\u002Fuploads\u002F2026\u002F10\u002Fmcp-explained-what-it-connects-what-it-does-not-do-and-where-it-fits-1791486640275-7ub1cq.webp","2026-10-08T15:09:00.000Z",{"id":3774,"slug":3775,"title":3776,"excerpt":3777,"featuredImage":3778,"publishedAt":3779},"481","generative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing","生成式人工智能解析：模型、检索、工具与应用并非同一回事","生成式AI不仅仅是一个模型。了解模型、检索、工具、上下文、运行时和应用程序如何在生产AI系统中协同工作。","\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":3781,"slug":3782,"title":3783,"excerpt":3784,"featuredImage":3785,"publishedAt":3786},"484","what-is-an-ai-platform-architect-models-data-runtime-security-and-operations","什么是AI平台架构师？模型、数据、运行时、安全与运维","AI平台架构师负责跨模型、提供商、检索、智能体、身份、安全、评估、可观测性和运营设计可复用的AI基础。","\u002Fuploads\u002F2026\u002F10\u002Fwhat-is-an-ai-platform-architect-models-data-runtime-security-and-operations-1791477229171-ou3zcc.webp","2026-10-08T12:32:00.000Z",{"id":3788,"slug":3789,"title":3790,"excerpt":3791,"featuredImage":3792,"publishedAt":3793},"479","where-does-an-llm-get-its-data-rag-data-sources-in-python","LLM从哪里获取数据？Python中的RAG数据源","LLM 并不会神奇地知道你的文件、数据库或 API。这个 RAG 系列的实用续篇用简单的 Python 展示了外部数据如何变成可检索的证据：从文本文件和 SQL 到全文搜索、嵌入、上下文组装以及最终的 LLM 调用。","\u002Fuploads\u002F2026\u002F09\u002Fwhere-does-an-llm-get-its-data-rag-data-sources-in-python-1790517200521-nfsi5i.webp","2026-09-27T05:51:00.000Z",{"id":3795,"slug":3796,"title":3797,"excerpt":3798,"featuredImage":3799,"publishedAt":3800},"480","when-should-an-ai-stop-trusting-its-own-knowledge-the-retrieval-trigger","人工智能何时应停止信任自身知识？——检索触发机制","AI 模型并非每个问题都需要检索。重要的问题在于知道何时其内部知识已不再足够。检索触发器是一个实用的决策边界，它决定 AI 系统何时应停止仅依赖模型知识，并在回答前获取外部证据。","\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":3802,"slug":3803,"title":3804,"excerpt":3805,"featuredImage":3806,"publishedAt":3807},"490","rbac-vs-tenant-isolation-two-different-security-boundaries","RBAC与租户隔离：两种不同的安全边界","RBAC 控制用户可以做什么；租户隔离控制该操作可以触及哪个租户的资源。了解为什么多租户 SaaS 安全需要这两道边界。","\u002Fuploads\u002F2026\u002F10\u002Frbac-vs-tenant-isolation-two-different-security-boundaries-1791485111528-qqtzby.webp","2026-10-08T14:43:00.000Z",{"id":3809,"slug":3810,"title":3811,"excerpt":3812,"featuredImage":3813,"publishedAt":3814},"443","linux","2026年新兴Linux趋势：塑造服务器基础设施的未来","探索2026年Linux关键趋势：从Kubernetes主导地位与不可变发行版，到人工智能集成与eBPF安全技术。","\u002Fuploads\u002F2026\u002F03\u002Flinux-1773696098750-knp03t.webp","2026-03-01T13:52:00.000Z",{"id":3816,"slug":3817,"title":3818,"excerpt":3819,"featuredImage":3820,"publishedAt":3821},"495","sovereign-ai-control-of-models-data-infrastructure-and-dependencies","主权人工智能：模型、数据、基础设施与依赖关系的控制","主权人工智能关乎对模型、数据、基础设施、软件、运营和战略依赖的有效控制——而不仅仅是人工智能模型托管在哪里。","\u002Fuploads\u002F2026\u002F10\u002Fsovereign-ai-control-of-models-data-infrastructure-and-dependencies-1791488833132-niy85x.webp","2026-10-08T15:45:00.000Z",{"id":3823,"slug":3824,"title":3825,"excerpt":3826,"featuredImage":3827,"publishedAt":3828},"483","what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","什么是AI解决方案架构师？系统边界、职责与权衡","AI解决方案架构师将业务需求转化为生产就绪的AI系统，涵盖数据、模型、工具、安全、运行时、评估和运维。","\u002Fuploads\u002F2026\u002F10\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs-1791476643267-1st5xz.webp","2026-10-08T12:23:00.000Z",{"id":3830,"slug":3831,"title":3832,"excerpt":3833,"featuredImage":3834,"publishedAt":3835},"446","google-io-2026-architectural-pivots-agentic-ai-and-the-unified-ecosystem-reality-check","Google I\u002FO 2026：架构转型、自主AI与统一生态的现实检验","Google I\u002FO 2026 不仅仅是一场模范活动。它展示了 Gemini 模型、开发者工具、Android 相关界面以及智能设备之间更深层次的平台变革。本文作为核心报道，为需要区分实际运行时影响与舞台炒作的技术工程师、架构师和产品团队解读这场主题演讲。","\u002Fuploads\u002F2026\u002F05\u002Fgoogle-io-2026-architectural-pivots-agentic-ai-and-the-unified-ecosystem-reality-check-1779228056169-bcrcs0.webp","2026-05-21T11:10:00.000Z",{"id":3837,"slug":3838,"title":3839,"excerpt":3840,"featuredImage":3841,"publishedAt":3842},"448","google-io-2026-android-xr-and-intelligent-eyewear","Google I\u002FO 2026：Android XR、智能眼镜与环境AI界面","Google I\u002FO 2026 将 Android XR 和智能眼镜从概念推向实际平台方向。本文解析了音频眼镜、显示眼镜、Gemini 驱动的上下文感知、开发者影响、隐私风险，以及为何可穿戴 AI 更关乎创造环境辅助界面，而非取代手机。","\u002Fuploads\u002F2026\u002F05\u002Fgoogle-io-2026-android-xr-and-intelligent-eyewear-1779227942270-dtsm9y.webp","2026-05-21T11:05:00.000Z","fallback",[],[]]