AI驱动下企业架构概要设计的变革思考

最近一直在探索AI项目，一些思考与大家分享：企业架构到底适不适用AI时代了？

我认为传统那套信息化环境下的架构模式一旦被嵌入AI，则将被逐步瓦解。

因为你目标实体及其结构关系在变，架构及其资产一定也要随之演进。

我们今天拿企业架构的概要设计来说，我们之前做概设，一般要涉及到逻辑、参与角色、产出形态与决策范式的设计。传统范式遵循业务愿景驱动、技术方案承接、资源决策落地的线性逻辑，核心是确保IT能力对业务战略的支撑。

而在AI驱动的环境中，设计框架必须系统性地考虑从规则引擎、机器学习到生成式AI与智能体等多元技术的融合与治理，并由此重新审视业务与技术的协同模式、决策依据的维度，以及设计成果。

一、从选型适配到体系化设计

传统概要设计中的技术选型，侧重于为明确的业务场景选择单一或组合的技术解决方案，路径相对清晰。

但AI技术栈呈现多层次、快迭代的特点，概要设计需从选型适配转向体系化设计。设计需统筹考虑基础规则引擎、预测模型、生成式内容引擎及自主智能体等不同层级技术的协同关系、数据流与治理边界。

重点不在于堆砌前沿技术，而在于构建一个层次清晰、接口标准、能力可复用的技术能力基座。

例如，一个智能客服系统的设计，需明确业务规则、意图识别模型、话术生成引擎与工单处理智能体之间的责任边界与协作协议，确保能力解耦与可持续迭代。

1.背景

传统概要设计通常只考虑技术选型：

·比如：“我要做一个客服系统，用 Dialogflow 做意图识别，用规则引擎做自动回复。”

·这里路径清晰，但系统很难升级或整合更多 AI 能力。

现在：

2.技术能力分层

一个完整的智能客服系统可以拆成几个层次，每层有明确职责。

3.数据流与协作

·用户发消息 → 意图识别模型判断意图；

·如果是常规问题 → 规则引擎直接匹配标准答案；

·如果需要生成个性化回复 → 生成式内容引擎生成话术；

·如果涉及工单操作 → 智能体接管任务，调用工单系统 API 完成操作；

·系统把操作结果反馈给用户，并记录日志用于后续模型优化。

4.架构治理重点

·能力解耦：意图识别、内容生成、工单处理都是独立模块，可替换或升级。

·接口标准化：各层之间用统一 API/消息协议通信，确保层与层之间的协作。

·治理边界明确：规则层只处理明确业务规则，智能体只处理可自动化操作，生成层不直接操作业务系统。

5.好处

·当业务增加新的客服场景（如投诉、售后退换货），只需：

o增加新规则；

o增加或微调意图模型；

o新增智能体任务；

·系统整体架构不动，能力可复用，迭代成本低。

二、角色体系的扩展

传统设计依赖于业务负责人与技术架构师的紧密协同。

AI项目的复杂性要求角色体系进一步扩展，形成融合型设计团队。

业务负责人需深度参与，将业务目标转化为可量化、可训练的智能体目标与约束条件。

技术负责人需确保多元AI能力与现有IT体系的融合及资源供给。

AI架构师成为关键角色，负责设计兼顾性能、成本、伦理与可解释性的整体AI技术架构。

领域专家的作用被强化，需为模型训练提供高质量、符合业务实质的样本与评判标准。

此外，设计过程中可引入AI辅助工具进行模拟推演与方案比对，但决策主体与责任是人。

企业架构实战案例：银行智能贷款审批系统

1 项目背景

一家银行希望把原来人工审批贷款的流程升级为 AI辅助审批系统。

原流程：

·客户提交贷款申请

·客户经理审核资料

·风控部门评估风险

·决定是否放款

审批周期：2–5天

银行目标：

·审批时间缩短到 10分钟

·自动审批比例达到 70%

于是启动 AI 项目。

2、传统 IT 项目角色

如果是传统系统（比如开发一个贷款管理系统），团队通常是：

·业务负责人

·技术架构师

·开发团队

他们主要做的是：

·设计数据库

·写审批流程系统

·做业务规则

架构相对简单。

3、AI 项目角色会扩展

因为 AI 系统不仅是软件，还涉及数据、模型、训练、伦理、风险。

于是团队会变成融合型设计团队。

第一、业务负责人：定义 AI 的目标

业务负责人不再只是提需求，而是要把业务目标转化为模型目标。

例如：

贷款审批目标：

业务目标	AI需要理解的目标
控制坏账率	模型预测违约概率
提高审批速度	自动化审批比例
风控合规	设定审批规则边界

举例：

业务负责人要定义：

·违约概率 > 20% → 必须人工审核

·收入稳定+信用高 → 自动通过

这其实是在给 AI模型设定约束条件。

第二、技术负责人：保证系统能运行

技术负责人负责的是 IT系统整合。

他需要解决：

·AI模型部署在哪里

·如何接入银行核心系统

·算力和资源

例如架构：

手机银行│贷款申请系统│AI审批服务│风险模型 + 规则引擎│银行核心系统

他要确保：

·模型调用延迟 < 1秒

·数据安全合规

·系统高可用

第三、AI架构师：AI系统整体设计

这是 AI时代新增的关键角色。

AI架构师负责设计：

·模型结构

·数据流

·成本

·可解释性

例如贷款审批系统的 AI 架构：

数据层客户征信 + 交易数据 + 行为数据 ——模型层违约预测模型反欺诈模型——决策层规则引擎 &审批策略——服务层&贷款审批API

AI架构师要考虑：

·模型准确率

·算力成本

·是否可解释（监管要求）

银行监管要求：为什么拒贷必须解释

AI架构师要设计可解释模型。

第四、领域专家：提供训练数据

AI模型需要训练数据，而数据必须由业务专家提供和标注。

例如银行风控专家会标注：

历史贷款数据：

客户	是否违约
A	否
B	是
C	否

同时定义判断标准：

·什么叫高风险客户

·哪些行为属于欺诈

没有领域专家，模型会训练偏差。

第五、AI辅助工具：模拟方案

在架构设计阶段，还可以用 AI 做方案推演。

例如模拟：

如果审批规则变成：

违约概率 > 15% → 人工审核

系统可以模拟：

·自动审批比例

·坏账率变化

AI可以帮助架构师做方案对比。

但最终决策：

必须是人

因为涉及：

·风险

·合规

·责任

4 整个项目角色分工

一个真实 AI 项目团队可能是：

角色	职责
业务负责人	定义业务目标
AI架构师	设计AI系统结构
技术负责人	IT系统整合
数据科学家	训练模型
领域专家	提供数据和规则
工程团队	实现系统

5 核心变化

传统 IT 项目：业务 + IT

AI 项目：业务+ IT+ 数据+ 模型+ 领域知识+ 风控

所以必须多角色协同设计。

三、产出从静态文档到可追溯、可运营的设计资产

传统概要设计的产出是一份用于评审与立项的阶段性文档。

AI时代，其产出应演进为一份可追溯、可运营的初始设计资产。

它不仅是方案描述，更应明确核心智能体的职责边界、关键模型的数据血缘与版本管理策略、各技术组件间的服务等级协议（SLA）以及贯穿全周期的伦理与合规检查点。

这份资产应能与后续的开发运维流程衔接，其关键假设与设计决策需被结构化记录，以便在模型效果偏离预期或法规环境变化时，能够快速追溯根源，指导调优。

其形态从冻结的蓝图转向活的设计基线。

四、决策维度的深化

传统决策通常在业务价值、实施成本与时间进度之间进行权衡。

引入AI后，决策维度显著增加且相互耦合，需要在多约束条件下进行系统性寻优。

这包括：

1 技术效能与成本约束，需评估模型精度、响应速度与算力成本的平衡；

2 合规与伦理约束，数据隐私、算法公平性、可解释性成为必须前置评估的刚性要求；

3 系统融合度约束，评估新AI能力与既有业务流程、数据资产及IT系统的集成复杂度与改造范围；

4 长期演进约束，考量技术组件的可替代性、架构的扩展性以及知识资产的沉淀能力。

5 决策过程从一次性评审，转变为基于持续验证与反馈的阶段性门径评审。

五、生命周期属性的转变

传统上，概要设计是项目启动前的临时性里程碑。

在AI驱动的持续交付与运营模式下，概要设计应被视为企业一项核心数字能力演进周期的关键路标。

其中定义的技术架构原则、数据治理框架、伦理合规基线，应作为后续迭代的共同约束。

设计文档本身也应作为资产纳入架构资源库，其经验教训可用于指导同类项目。

它的价值不再随项目启动而结束，而是转化为组织AI治理能力的一部分，为能力的持续建设与优化提供初始上下文和治理依据。

SUMALL：从解决方案蓝图到能力治理框架

AI对概要设计的重塑，核心在于将其从定义一个IT的解决方案，升级为规划一项企业级数字能力的治理框架。成功的产出，不在于描绘一个技术炫酷的未来图景，而在于交付一个边界清晰、权责明确、风险受控且具备进化能力的务实设计。

以上内容为个人观点，欢迎各位联系探讨交流。