SEO / GEO 数据治理与规范标准细则（四）：Data Owner / Data Steward——企业的数据到底应该由谁负责？

系列：SEO / GEO 数据治理与规范标准细则（四）

发布日期：2026年10月8日

前三篇，我们已经建立了三层基础。

第一篇解决：

为什么SEO/GEO需要进入数据治理。

第二篇解决：

Raw Data如何逐步变成Searchable Knowledge。

第三篇解决：

当五个系统存在五个不同答案时，哪个数据才有资格成为Source of Truth。

但Source of Truth一旦真正落地，一个更加现实的问题马上出现：

谁负责保证Source of Truth一直是真的？

假设某款产品的额定功率正式由：

75 kW

修改为：

82 kW

工程部门批准了新参数。

PIM仍然是75 kW。

官网仍然是75 kW。

PDF仍然是75 kW。

Schema仍然是75 kW。

销售人员继续使用旧Excel。

AI知识库也仍然保存旧资料。

这时候，真正的问题已经不是：

哪个值是正确的？

因为第三篇已经解决：

Authoritative Source
=
PLM

Canonical Value
=
82 kW

现在的问题变成：

谁负责修改PLM？

谁负责确认变更？

谁负责同步PIM？

谁负责更新CMS？

谁负责旧PDF失效？

谁负责Schema？

谁负责经销商数据？

谁负责AI知识库重新同步？

谁负责最终验证所有渠道已经一致？

如果这些问题没有明确答案，那么：

Source of Truth仍然只是一个技术概念。

所以第四篇正式进入：

Data Ownership & Stewardship

也就是：

数据所有权与数据治理责任体系。

一、很多企业的数据问题，本质上不是技术问题，而是“没人真正负责”

这是企业数据治理中非常常见的一种状态：

Everyone uses the data.

Nobody owns the data.

销售部门使用产品数据。

市场部门使用产品数据。

SEO团队使用产品数据。

网站编辑使用产品数据。

工程部门产生产品数据。

IT部门保存产品数据。

AI系统调用产品数据。

但真正出现问题以后，每个人都说：

“这个不是我负责的。”

这就是典型的：

Accountability Gap

也就是：

数据问责缺口。

二、企业最常见的错误：谁在系统里操作，谁就被认为“负责数据”

例如：

WordPress编辑每天更新网站。

于是企业认为：

网站数据归网站编辑负责。

这并不严谨。

因为编辑可能只有：

Edit Permission

但没有：

Business Authority

一个CMS编辑可以把：

75 kW

改成：

82 kW

但这并不意味着他拥有定义：

额定功率到底是多少

的权力。

所以必须先建立第一条原则：

Ability to Edit
≠
Authority to Define

也就是：

能够修改数据，不等于有权定义数据。

三、这就是为什么必须区分Data Owner和Data Steward

IBM关于Data Governance的资料区分了Data Owner与Data Steward：Data Owner通常负责某个业务数据域，对数据准确性、质量、一致性和治理政策承担更高层级责任；Data Steward则承担特定数据域的日常治理工作。

官方资料：IBM：Data Governance

Microsoft Purview的数据治理模型同样将Data Owners与Data Stewards作为不同治理角色。Data Owner侧重资产、分类、访问和质量标准等治理责任，Data Steward则更偏向数据质量、发现、术语、一致性和Lineage等日常治理工作。

官方资料：Microsoft Purview：Data Governance overview

所以可以先用一句非常简单的话区分：

Data Owner
=
Accountable

Data Steward
=
Operationally Responsible

即：

Owner承担最终责任。

Steward负责日常治理。

四、Data Owner到底是什么？

本系列将Data Owner定义为：

对某个Data Domain、Entity、Dataset或Critical Data Element拥有业务解释权，并对其质量、规则、使用边界与最终治理结果承担Accountability的角色。

例如：

产品额定功率
Owner:
Engineering

产品价格
Owner:
Finance / Commercial

企业Legal Name
Owner:
Legal

认证状态
Owner:
Compliance

SEO Title
Owner:
SEO / Content

注意：

Data Owner首先是：

Business Role。

而不只是：

IT Role。

五、Data Owner最重要的不是“维护数据”，而是拥有决策权

Data Owner应该能够回答：

这条数据到底是什么意思？

哪个系统具有最终Authority？

哪个值应该成为Canonical Value？

什么情况下允许修改？

谁可以修改？

修改是否需要审批？

什么情况下数据可以公开？

出现冲突时谁做最终裁决？

质量下降到什么程度必须整改？

也就是说：

Data Owner
=
Decision Authority
+
Accountability

六、Data Steward又是什么？

IBM将Data Stewardship描述为一组帮助保证数据质量和可访问性的数据管理实践，并将数据质量指标、Metadata、Reference Data、Lineage以及敏感数据分类等列为Data Steward常见职责。

官方资料：IBM：Data Stewardship

因此，本系列定义Data Steward为：

依据Data Owner确定的治理原则，对数据的定义、质量、元数据、规则、异常、标准化、Lineage和日常治理流程进行持续执行与维护的角色。

如果Data Owner回答：

What should be true?

Data Steward更接近回答：

How do we keep it true?

七、Owner与Steward最大的区别，是Accountability与Execution

例如：

Engineering Director
=
Data Owner

Product Data Specialist
=
Data Steward

工程负责人规定：

rated_power
必须来自
Approved Engineering Specification

Data Steward则负责检查：

字段是否完整，单位是否正确，PIM是否同步，是否存在75 / 80 / 82多个版本，旧数据是否失效，Data Quality Rule是否通过，异常是否进入工单。

Owner
↓
Defines Governance

Steward
↓
Operates Governance

八、Data Owner不能把Accountability“外包”给Data Steward

这是治理设计中非常重要的一点。

现实里很容易发生：

“这个数据问题找数据管理员。”

然后Owner就不再承担任何责任。

这是错误的。

Steward可以检查、清理、标准化、监测、协调、升级异常。

但如果出现两个工程规范冲突，究竟哪个版本有效，最终仍然需要Authority Holder进行裁决。

Steward
can manage the issue.

Owner
must own the decision.

九、企业不能只设置Owner和Steward

成熟的数据运行体系至少应该区分：

Data Owner
Data Steward
Data Producer
Data Operator
Data Custodian
Data Consumer
Governance Council

十、Data Producer——谁真正产生数据？

Data Producer指：

在业务流程中产生原始数据或事实的人、部门、设备或系统。

例如：

工程师
→ Technical Specification

销售人员
→ Lead Status

财务系统
→ Invoice

实验室
→ Test Result

Search Console
→ Search Performance Data

GA4
→ Analytics Event Data

所以：

Producer
≠
Owner

数据由谁产生，并不等于谁拥有最终治理权。

十一、Data Operator——谁负责录入或修改？

Data Operator指：

按照既定规则，在业务系统中创建、修改、录入、发布或同步数据的人或自动化程序。

例如：

WordPress Editor。

PIM Operator。

ERP Clerk。

Content Publisher。

SEO Automation Agent。

它们都有可能拥有：

Write Permission

但不代表拥有：

Policy Authority

因此：

Operator
executes change.

Owner
authorizes meaning.

十二、Data Custodian——谁负责技术保管？

Data Custodian更偏向Technical Responsibility。

本系列将其定义为：

负责数据基础设施、数据库、权限系统、备份、安全、存储、传输和技术可用性的技术角色。

例如IT部门负责：

数据库可用、备份、访问控制、灾难恢复、API、Encryption。

但IT部门不应该决定：

产品额定功率到底是75还是82。

Custody
≠
Business Ownership

十三、Data Consumer——谁使用数据？

Data Consumer就是数据使用者。

例如：

SEO团队使用Product Data。

销售团队使用Price。

AI Agent使用Knowledge Base。

客户通过网站读取技术参数。

分析师读取GA4和CRM。

管理层读取BI报告。

Consumer通常拥有：

Read
Query
Analyze
Use

权限。

但一般不应该因为“使用不方便”，就直接修改Source of Truth。

十四、Governance Council——当Owner之间发生冲突怎么办？

现实企业一定会出现跨部门冲突。

例如Engineering认为产品名称应该是：

Model FW-30 Observation Wheel

Marketing认为应该叫：

30m Giant Ferris Wheel

Legal又要求合同使用：

FW30 Series Observation Wheel

此时并不一定存在一个单一Owner可以解决所有问题。

因此需要：

Data Governance Council

或者：

Data Governance Committee。

它负责：

跨Domain规则、Owner冲突、重大例外、治理优先级、标准审批、高风险数据事故。

IBM也把Steering Committee / Governance Council作为典型Data Governance Framework中的治理角色，用于监督整体治理战略与方向。

十五、完整责任链

Governance Council
↓
Data Owner
↓
Data Steward
↓
Producer / Operator
↓
Custodian
↓
Consumer

需要注意：

这不是严格的组织层级图。

而是：

Governance Responsibility Chain。

十六、回到第三篇的82 kW案例

Data Domain:
Engineering Product Data

Data Owner:
Engineering Director

Data Steward:
Product Data Engineer

Data Producer:
Design Engineer

Data Operator:
PIM Administrator

Data Custodian:
IT / Platform Team

Data Consumer:
SEO
Sales
Marketing
Website
AI Knowledge Base

这样企业第一次可以回答：

谁做什么？

十七、如果官网仍然是75 kW，找谁？

首先不是找SEO Writer。

而是建立责任链。

Data Steward检查：

PLM是不是82？

PIM是不是82？

CMS是不是75？

同步任务是否失败？

如果Source正确但CMS错误，问题可能属于：

Distribution Incident。

如果PLM本身就是75，则需要Engineering Owner判断Source是否错误。

这就是责任分离的意义。

十八、SEO团队到底应该拥有什么数据？

SEO团队通常可以拥有：

SEO Title
Meta Description
Search Intent Classification
Keyword Mapping
Internal Link Rule
Content Taxonomy
SERP Annotation
Query Cluster
SEO Content Brief

但通常不应该拥有：

Engineering Specification
Official Product Capacity
Legal Entity Name
Certification Status
Financial Price
Inventory

这些数据应该：

Consume, not redefine。

十九、SEO团队最大的治理风险：无意间成为“事实制造者”

一个内容编辑看到产品没有写最大容量。

于是询问AI：

“类似设备一般能坐多少人？”

AI回答：

96人。

编辑直接写：

Capacity: 96 passengers

页面发布。

Google收录。

AI搜索再次引用。

第三方网站复制。

几个月后，这条没有工程依据的数据已经遍布互联网。

这就是：

Unauthorized Data Creation。

SEO团队本来只是Data Consumer，却在没有Authority的情况下变成Data Producer，甚至Pseudo Data Owner。

二十、因此Content Creation必须增加Authority Gate

对于事实型字段：

Technical Parameter
Certification
Safety Claim
Performance Claim
Price
Warranty
Compliance
Production Capacity

内容团队不能自由生成。

应该经过：

Draft
↓
Source Lookup
↓
Authority Check
↓
Evidence Check
↓
Publish

这就是：

Fact Authority Gate。

二十一、AI生成内容以后，这个问题更加重要

传统人工写作每天可能产生5篇文章。

AI系统一天可能产生500篇。

如果没有Owner、Steward、Authority、Evidence，AI就会把一个错误：

× 500

所以：

AI Content Governance的第一原则不是Prompt Engineering，而是Authority Engineering。

二十二、AI Agent可以成为Data Operator，但通常不能自动成为Data Owner

例如AI Agent可以：

读取PLM。

读取PIM。

更新CMS。

生成Schema。

更新FAQ。

但是AI Agent不应该自行决定：

82 kW
→
85 kW

除非企业明确授予规则范围、数据来源、审批机制和Authority。

AI Agent
=
Operator / Processor

AI Agent
≠
Default Owner

二十三、Data Steward在AI时代的重要性反而会上升

Microsoft Purview的治理模型把Data Steward与数据质量、业务术语、一致性、Lineage和治理策略联系起来。

IBM也强调，随着AI大量消费和生产数据，Data Stewardship对于保证数据质量与完整性变得更加重要。

原因很简单：

AI越自动，越需要有人维护：

Definitions
Rules
Context
Quality
Evidence
Exceptions

二十四、企业不一定需要招聘一群“专职Data Steward”

这是中小企业最容易误解的地方。

Data Steward可以是一种角色，不一定是一份全职Job Title。

例如：

Product Manager可以兼任Product Data Steward。

SEO Manager可以兼任Search Data Steward。

CRM Manager可以兼任Customer Data Steward。

关键不是职位名称，而是：

责任是否被正式定义。

二十五、Data Domain应该成为责任划分的第一层

企业可以先定义：

Organization Data
Product Data
Customer Data
Commercial Data
Content Data
Search Data
Analytics Data
Compliance Data
Project Data

然后每个Domain指定Owner和Steward。

Data Domain	Owner	Steward
Product	Product Director	Product Data Manager
Engineering	Engineering Director	Technical Data Engineer
Customer	Sales Director	CRM Manager
Content	Marketing Director	Content Manager
Search	SEO Lead	SEO Analyst
Analytics	Digital Director	Analytics Specialist
Compliance	Compliance Director	Compliance Specialist

这比：

“IT部门统一负责数据”

合理得多。

二十六、为什么不能让IT成为所有Data Owner？

因为IT负责Systems。

不等于Business Meaning。

数据库管理员知道：

column = rated_power
type = decimal

但未必知道：

rated_power应该按照哪个工程标准定义。

IT owns infrastructure.

Business owns meaning.

这是非常重要的治理分界。

二十七、Federated Governance

Microsoft Purview将Federated Data Governance描述为一种中央规则与各业务Domain治理责任结合的模式：中央数据团队制定共同标准，而真正理解业务数据的部门和角色负责在各自Domain中执行治理。

这种模式非常适合SEO/GEO治理。

因为SEO团队不可能理解全部工程数据、全部财务数据、全部合规数据。

所以更合理的是：

Central Governance
+
Domain Ownership

二十八、建立SEO/GEO Federated Governance Model

Central Governance Standard
↓
Domain Owner
↓
Domain Steward
↓
Publishing / Search / AI

Central Governance负责：

命名原则、Version规则、Evidence规则、数据质量规范、权限规则、审计规则。

Domain Owner负责：

业务Authority。

Steward负责：

日常质量。

SEO/GEO负责：

将Governed Data正确发布出去。

二十九、Content Team应该成为“Knowledge Publisher”，而不是“Truth Creator”

未来成熟的SEO团队应该逐渐从：

Content Creator

升级为：

Knowledge Publisher

Knowledge Publisher使用：

Governed Data
+
Verified Evidence
+
Approved Entity
+
User Intent

形成内容。

这样SEO的创造力仍然存在，但事实不再随意创造。

三十、Data Ownership应该精确到Critical Data Element

仅仅说：

Product Team owns Product Data

仍然太粗。

更成熟的治理应该识别：

Critical Data Element，CDE。

也就是真正影响交易、合规、搜索、AI回答、客户决策的关键字段。

Product ID
Model
Height
Capacity
Power
Price
Certification
Warranty
Lead Time
Legal Name
Country of Origin

三十一、每个Critical Data Element至少要指定一个Accountable Owner

CDE:
rated_power

Owner:
Engineering Director

Steward:
Product Data Engineer

SOR:
PLM

Quality Rule:
value > 0

Unit:
kW

这样关键字段不再处于：

“大家都能改”

的状态。

三十二、一个数据字段不应该有五个Owner

为了“跨部门协作”，企业可能说工程、产品、市场、销售都负责Power。

结果就是：

4 Owners
=
0 Clear Owner

更成熟的做法是：

One Accountable Owner。

可以有多个Contributor。

可以有多个Steward。

但最终Accountability要明确。

三十三、引入RACI

RACI是组织治理中非常实用的方法。

R = Responsible
A = Accountable
C = Consulted
I = Informed

例如产品Power修改：

Role	RACI
Engineering Director	A
Product Data Steward	R
Product Manager	C
SEO Team	I
Sales	I
IT	C

这样谁做、谁批准、问谁意见、通知谁，全部明确。

三十四、Data Owner通常应该是A，而不是R

因为Owner并不一定亲自修字段、跑脚本、改CMS。

Owner真正承担的是：

Accountable。

Steward更常承担：

Responsible。

Owner = A

Steward = R

这是非常实用的默认设计。

三十五、建立Data Responsibility Matrix

Activity	Owner	Steward	Producer	Operator	Custodian	Consumer
Define meaning	A	R	C	I	I	C
Create data	I	C	R	R	I	—
Validate	A	R	C	C	I	—
Approve	A	R	C	—	—	—
Publish	I	C	—	R	C	I
Store	I	C	—	—	R	—
Monitor quality	A	R	C	C	C	I
Report issue	I	R	C	C	C	R
Resolve conflict	A	R	C	C	I	I

三十六、数据质量问题应该首先进入Steward Queue

例如检测到：

PLM:
82

CMS:
75

系统创建：

Data Issue:
ISSUE-00281

进入Data Steward Queue。

Steward负责确认是否真正冲突、检查Context、检查Version、检查同步。

能够解决，直接处理。

不能解决，升级到Data Owner。

三十七、Steward本质上还是Data Issue Router

一个优秀Data Steward并不需要知道所有答案。

但必须知道：

Which issue
belongs to
which authority?

例如：

价格问题：Finance。

认证问题：Compliance。

技术参数：Engineering。

SEO Metadata：SEO。

这样企业的数据问题不会一直在群聊里转发。

三十八、建立Escalation Path

Data Quality Alert
↓
Steward Review
↓
Resolvable?
├─ Yes → Fix
└─ No
   ↓
Data Owner
↓
Cross-domain Conflict?
├─ No → Decision
└─ Yes
   ↓
Governance Council

这就是：

Data Governance Escalation Path。

三十九、Owner还应该定义Data Quality Threshold

例如Product Critical Data：

Completeness ≥ 99%

Validity = 100%

Critical Conflict = 0

Source Traceability = 100%

Search Analytics Data则可能允许不同标准。

不同Data Domain可以有不同质量阈值。

Owner应该决定：

什么程度才叫“可接受”。

四十、Steward负责监测这些Threshold

例如每周报告：

Product Data
Completeness: 99.4%

Consistency: 98.8%

Freshness: 97.2%

Source Traceability: 100%

Open Issues: 14

Critical Issues: 2

这样Data Stewardship开始变成：

Operational Discipline。

四十一、Owner不能只挂名字，必须拥有KPI

如果Data Owner只是Excel表里的一列姓名，治理不会真正发生。

可以为Owner建立：

Data Quality Score
Critical Issue SLA
Conflict Resolution Time
Policy Compliance
Truth Consistency Rate

这样Ownership才真正连接Accountability。

四十二、Steward也需要Operational KPI

Issue Resolution Time
Data Quality Pass Rate
Metadata Completeness
Lineage Coverage
Rule Coverage
Open Issue Aging
Duplicate Rate
Drift Detection Rate

否则Steward会慢慢变成：

“维护表格的人”。

四十三、SEO/GEO应该加入一组特殊治理KPI

Website vs Source Consistency
Schema vs Visible Content Consistency
Published Claim Traceability
Entity Naming Consistency
AI Knowledge Freshness
Old PDF Exposure
Citation Source Consistency
Structured Data Drift

这些指标会比发布篇数更接近下一阶段SEO/GEO运营成熟度。

四十四、建立Data Ownership Registry

企业至少应该拥有一张：

Data Ownership Registry。

字段包括：

data_domain
entity_type
critical_attribute
owner
steward
system_of_record
authoritative_source
operator
custodian
consumer
quality_rule
update_frequency
escalation_path

例如：

Domain:
Engineering

Entity:
Product

Attribute:
rated_power

Owner:
Engineering Director

Steward:
Product Data Engineer

SOR:
PLM

Operator:
PLM Admin

Custodian:
IT

Consumers:
PIM
Website
SEO
Sales
AI KB

四十五、不要用个人姓名作为唯一治理标识

假设：

Data Owner:
Zhang San

张三离职以后怎么办？

更合理的记录应该是：

Owner Role:
Engineering Director

Current Assignee:
Zhang San

也就是说：

Role-based Ownership

优先于：

Person-only Ownership。

四十六、Owner必须有Backup

对于关键数据，一个Owner不应该成为Single Point of Failure。

企业内部可以采用：

Primary Owner
+
Deputy Owner

保证治理责任不会完全依赖单一人员。

四十七、权限应该跟责任绑定

企业最危险的一种结构是：

Everyone can edit everything.

成熟模型应该是：

Owner
→ Approve

Steward
→ Govern

Operator
→ Execute

Consumer
→ Read

因此Data Governance必须与Access Governance连接。

四十八、RBAC是基础，但还不够

传统系统使用Role-Based Access Control。

例如Editor、Administrator、Viewer。

但数据治理进一步需要考虑：

Which domain?
Which attribute?
Which action?
Which context?
Which environment?

例如SEO Editor可以修改meta_title，但不能修改rated_power，即使两者都在同一个WordPress页面里。

四十九、未来需要Field-level Governance

SEO
may edit:
meta_title
meta_description
content_summary

Engineering
may approve:
height
power
capacity

Compliance
may approve:
certification
safety_claim

这就是：

Attribute-level Permission。

五十、WordPress不应该成为治理Authority

WordPress可以提供Editing Interface。

但真正Authority应该来自：

Data Ownership Registry
+
Source Authority Matrix

所以成熟系统应该尽量实现：

Governed Data
↓
CMS

而不是：

CMS Permission
=
Data Authority

五十一、Structured Data由谁负责？

Schema既涉及SEO，又涉及业务事实。

例如Product Schema中：

name：产品团队负责事实。

brand：品牌团队负责事实。

offers.price：ERP / Finance负责事实。

description：Content负责。

JSON-LD技术实现：SEO / Development负责。

所以Schema Owner不能简单只有一个。

Schema Implementation Owner
≠
Schema Field Data Owner

五十二、SEO团队可以负责Schema实现，但不能拥有所有Schema字段的业务含义

例如：

SEO负责Schema Mapping。

Developer负责Rendering。

Engineering负责technical attribute。

Finance负责price。

这就是：

Separation of Concerns。

五十三、AI Knowledge Base由谁负责？

同样不能简单说：

IT负责。

IT可以维护Vector Database、Embedding Pipeline、权限、备份。

但Knowledge中的事实仍然属于不同Domain Owner。

所以AI Knowledge Base需要：

Technical Custodian
+
Knowledge Steward
+
Domain Owner

三层责任。

五十四、AI回答错误以后找谁？

不能统一找AI Team。

应该先识别错误来自哪里。

如果Source错误：找Domain Owner。

如果Source正确但RAG使用旧版本：找Knowledge Steward / AI Operator。

如果Retrieval选择错误：找AI System Team。

如果内容发布错误：找Content Operator。

如果Source冲突：找Data Steward，再升级Owner。

这就是治理价值：

Error Attribution。

五十五、Data Incident也必须有Owner

第三篇提出Data Incident。

第四篇继续增加：

Incident Owner。

Incident:
Product power conflict

Data Owner:
Engineering

Incident Coordinator:
Product Data Steward

Technical Resolver:
Integration Team

Affected Consumers:
SEO
Sales
AI
Website

这样Data Incident不会成为所有人在群里讨论，但没人Closing。

五十六、建立Issue Severity

P0：法律、价格、安全、认证、严重技术错误。

P1：核心产品参数冲突。

P2：Metadata、分类、次要字段问题。

P3：格式、拼写、非关键描述。

不同Severity对应不同SLA。

五十七、Owner决定风险，Steward推动关闭

例如P0：

Owner decision:
15 min

Containment:
1 hour

Downstream correction:
4 hours

P2：

Resolution:
3 business days

于是治理开始变成可执行制度。

五十八、数据修改还需要Change Control

关键数据不应该直接修改。

可以建立：

Change Request
↓
Steward Validation
↓
Owner Approval
↓
Operator Execution
↓
Downstream Sync
↓
Verification

这和软件工程中的Pull Request非常类似。

五十九、可以把它叫Data Pull Request

Change:
rated_power

Old:
75

New:
82

Reason:
ECO-8821

Source:
Engineering Spec V4.2

Requested By:
Engineer

Reviewed By:
Data Steward

Approved By:
Data Owner

然后才进入Production Data。

六十、AI Agent修改数据，也必须经过同样流程

例如AI Agent发现PDF与PLM不一致。

正确行为应该是：

Detect
↓
Create Issue
↓
Recommend Change
↓
Approval
↓
Execute

而不是：

Detect
↓
Rewrite Everything

六十一、这就是Human-in-the-Loop真正应该出现的位置

Human-in-the-Loop不是所有事情都人工确认。

而应该出现在：

Authority Boundary
Risk Boundary
Exception Boundary

例如SEO Title可以低风险自动化。

Engineering Specification属于高风险数据，需要Owner Approval。

六十二、Data Owner还必须负责Definition

一个字段如果没有统一Definition，数据再准确也可能产生歧义。

例如：

capacity

到底是：

每小时吞吐量？

单次载客量？

最大理论容量？

推荐运营容量？

因此Owner必须批准Business Definition。

rated_capacity
=
maximum number of passengers
per operating cycle
under approved configuration

六十三、Data Steward负责把Definition变成Metadata

field:
rated_capacity

type:
integer

unit:
passengers

nullable:
no

owner:
engineering

source:
PLM

definition:
...

quality_rule:
value > 0

这就是Business Meaning向Machine-readable Governance转换。

六十四、Steward是业务与技术之间的桥梁

IBM Stewardship相关资料强调Data Steward在业务与IT之间协调Data Quality Issue、信息政策、术语与治理流程的作用。

官方资料：IBM：Stewardship Center overview

这也是Data Steward最有价值的地方。

它既不能只是业务专家，也不能只是数据库管理员。

而应该理解：

Business Meaning
+
Data Structure
+
Governance Rule

六十五、SEO Data Steward应该负责什么？

可以包括：

Query Taxonomy。

Intent Classification。

Landing Page Mapping。

SEO Metadata Quality。

Canonical Mapping。

Internal Link Rules。

Search Console Data Definition。

AI Visibility Dataset。

Search Entity Naming。

但是不负责定义工程事实、财务事实、法律事实。

六十六、Content Data Steward应该负责什么？

例如：

Content Type。

Author Identity。

Publication Date。

Modified Date。

Content Status。

Claim Traceability。

Evidence Link。

Topic Taxonomy。

Article Version。

Content Relationship。

这些数据对SEO、GEO、AI Retrieval都越来越重要。

六十七、Product Data Steward应该负责什么？

Product ID。

Canonical Name。

Attribute Definition。

Unit。

Category。

Variant Relationship。

Data Quality。

PIM Synchronization。

Product Data Lineage。

这和SEO团队形成协作。

六十八、Analytics Data Steward应该负责什么？

例如：

GA4 Event Naming。

Conversion Definition。

Lead Definition。

MQL。

SQL。

Revenue Attribution。

UTM规则。

Channel Grouping。

如果这些没有Owner与Steward，最终每个部门都会拥有自己的“转化率”。

六十九、搜索数据同样需要Source of Truth和Owner

例如：

“Organic Traffic”到底取GA4、Search Console还是服务器日志？

三者不是同一个概念。

因此Metric也必须有：

Owner
Definition
Source
Calculation Rule

否则企业会出现：

Metric Conflict。

七十、Data Ownership最终也适用于KPI

Metric:
Organic Search Clicks

Source:
Google Search Console

Owner:
SEO

Steward:
SEO Analyst

Refresh:
Daily

Definition:
...

而Website Sessions来自GA4，是另一个Metric。

不要因为两个数不同，就认为一个错。

七十一、这就是Semantic Ownership

企业除了Data Ownership，还需要：

Semantic Ownership。

也就是：

谁定义Lead、Revenue、Product、Active Customer、Organic Traffic、AI Citation这些词的业务含义。

因为：

没有Definition，就没有真正的数据一致性。

七十二、Glossary也需要Owner和Steward

Microsoft Purview把Glossary和Business Concepts作为治理的重要组成部分，并把Steward作为维护一致性和业务理解的重要角色。

企业可以建立：

Business Term:
Qualified Lead

Definition:
...

Owner:
Sales Director

Steward:
CRM Manager

这样所有CRM、GA4、Looker Studio、SEO报告都使用同一语义。

七十三、Data Governance不是“数据部门自己做”

数据治理不能只是IT Project。

也不能只是Data Team Project。

因为数据来自业务。

真正可持续的结构应该是：

Business Ownership
+
Data Stewardship
+
Technical Custody
+
Governance Standards

七十四、Centralized Governance也不适合管理所有细节

如果所有字段修改都需要总部Data Office审批，治理会变成Bottleneck。

所以需要Federated Governance。

中央制定规则。

Domain自己负责事实。

Steward执行。

七十五、建议企业建立三级治理结构

Level 1｜Governance Council

负责政策、跨Domain争议、高风险决策、治理框架。

Level 2｜Domain Owner

负责业务Authority、定义、质量目标、关键决策。

Level 3｜Data Steward

负责日常执行、Metadata、Quality、Issue、Lineage、Synchronization。

Policy
↓
Authority
↓
Operation

七十六、SEO/GEO Data Ownership的MUST规范

1. 每个Critical Data Domain必须指定明确Data Owner。
2. 关键数据必须至少指定日常治理责任角色，即Data Steward或等效角色。
3. Data Owner必须对数据定义、Authority、质量要求和异常裁决承担最终Accountability。
4. Data Steward必须拥有明确的日常治理职责，而不能只是名义角色。
5. Data Operator不得自动获得业务事实解释权。
6. Data Custodian不得因为负责技术存储而自动成为业务Data Owner。
7. SEO、Content和AI系统不得未经Authority生成或修改关键业务事实。
8. Critical Data Element必须拥有明确Owner。
9. 跨Domain数据冲突必须存在Escalation Path。
10. 关键数据变更必须能够识别Requestor、Reviewer、Approver与Executor。

七十七、SHOULD｜建议

企业应该：

建立Data Ownership Registry。

建立RACI Matrix。

建立Critical Data Element清单。

建立Backup Owner。

建立Data Steward Queue。

建立Data Issue SLA。

建立Role-based Ownership。

建立Data Quality KPI。

建立Business Glossary Ownership。

建立Field-level Permission。

建立Data Change Approval。

建立Incident Escalation机制。

七十八、MAY｜可选

Data Governance Council
Enterprise Data Office
Data Catalog
Workflow Engine
Automated Issue Routing
Field-level RBAC
Policy-as-Code
Data Contract
Data Quality Platform
Data Observability
Metadata Automation
AI Governance

但需要再次强调：

工具只能执行治理，不能替企业决定谁应该承担责任。

七十九、企业可以立即建立的Data Ownership表

Domain	Data	Owner	Steward	SOR	Operator	Consumer
Engineering	Power	Engineering Director	Product Data Engineer	PLM	PLM Admin	Web / Sales / AI
Product	Name	Product Director	PIM Manager	PIM	PIM Admin	SEO / Sales
Commercial	Price	Finance Director	Commercial Ops	ERP	ERP User	Website
Compliance	Certificate	Compliance Director	Compliance Specialist	Compliance DB	Compliance Ops	Web / Sales
Search	Meta Title	SEO Lead	SEO Specialist	CMS	Content Editor	Search
Analytics	Organic Clicks	SEO Lead	SEO Analyst	GSC	Data Pipeline	Reporting

这张表本身就可以成为：

SEO/GEO Data Governance最早的一项正式制度。

八十、Data Ownership Checklist

Ownership：每个核心Data Domain是否存在Owner？

Stewardship：是否有人负责日常治理？

Authority：Owner是否真正拥有业务决策权？

Definition：字段是否存在统一业务定义？

Producer：是否知道数据是谁产生的？

Operator：是否知道谁可以修改？

Custodian：是否知道谁维护基础设施？

Consumer：是否知道哪些系统和部门依赖这条数据？

RACI：谁Responsible？谁Accountable？谁Consulted？谁Informed？

Quality：谁确定质量标准？

Incident：数据出错以后由谁负责推动解决？

Escalation：两个Owner发生冲突时找谁？

如果这些问题没有明确答案：

企业很可能拥有：

Data Systems

却还没有：

Data Accountability

八十一、第四篇真正要解决的，是Accountability

Article 1
Why Data Governance?

Article 2
How does Data become Knowledge?

Article 3
Which Data is Truth?

Article 4
Who is Accountable for Truth?

于是SEO/GEO数据治理第一次完整进入：

Truth
+
Authority
+
Ownership
+
Accountability

八十二、最终可以把Data Ownership压缩成一个公式

Governed Data
=
Defined Data
+
Authoritative Source
+
Data Owner
+
Data Steward
+
Quality Rule
+
Access Rule
+
Change Rule
+
Escalation Rule
+
Audit Trail

没有Owner：没有最终解释权。

没有Steward：没人保证日常质量。

没有Custodian：技术无法可靠运行。

没有Operator边界：任何人都可能修改事实。

没有Consumer Mapping：修改以后不知道影响谁。

没有Escalation：冲突永远无法关闭。

八十三、回到最开始的问题

企业的数据到底应该由谁负责？

答案不是IT。

也不是SEO。

不是网站编辑。

甚至不是一个统一的Data Department。

更准确的答案应该是：

由最理解业务含义、拥有合法决策Authority的Domain承担Ownership；由Data Steward持续执行治理；由Operator按照规则执行变更；由Custodian保障技术运行；由Consumer在明确语义和权限下使用数据。

最终形成：

Business Authority
↓
Data Owner
↓
Data Steward
↓
Data Operator
↓
Technical Custodian
↓
Data Consumer

这样企业的数据才真正开始拥有：

责任链。

写在最后

SEO和GEO过去很少讨论Accountability。

因为传统SEO通常只关心页面有没有上线、排名有没有提升、流量有没有增长。

但生成式AI正在改变这个问题。

AI系统可以非常快速地读取数据、组合事实、重新生成内容、传播信息。

这意味着，如果一条错误数据进入系统，它可能经过：

Source
↓
PIM
↓
CMS
↓
Website
↓
Search
↓
RAG
↓
AI
↓
Answer

被不断放大。

所以AI时代的数据治理不能只有：

Who can access the data?

还必须回答：

Who is accountable for the data?

这也是第四篇最核心的结论：

真正成熟的数据治理，不是让所有人共同负责，而是让每一条关键数据都能够找到明确的Authority、Owner、Steward与责任链。

只有这样，Source of Truth才不是静态数据库，而会成为：

可持续运行的治理体系。

下一篇

《SEO / GEO 数据治理与规范标准细则（五）：数据源治理——不是所有数据都应该进入知识库》

前四篇已经解决：

为什么治理
↓
如何形成Knowledge
↓
哪个数据是真相
↓
谁负责真相

第五篇将正式进入：

Data Source Governance。

也就是：

什么数据有资格进入SEO/GEO知识体系。

下一篇将重点解决：

第一方数据、第二方数据、第三方数据应该怎样分级？

官方来源、行业来源、AI生成内容分别属于什么Source Class？

为什么AI Output不能天然成为Source of Truth？

论坛、Reddit、竞争对手网站、新闻媒体、研究报告应该怎样使用？

Primary Source与Secondary Source怎样区分？

如何建立：

Source Registry
Source Tier
Source Authority
Source Risk
Source Freshness
Source License
Source Provenance

最终形成一套：

SEO / GEO Source Admission Standard

——让企业不再把“搜集到的信息”直接等同于“可以进入知识库的数据”。

参考依据与标准边界

Microsoft Purview：Data Governance overview。Microsoft将Data Owners、Data Stewards及中央治理团队作为不同治理角色，并采用Federated Governance模式把中央规则与业务Domain责任结合起来。

官方资料：https://learn.microsoft.com/en-us/purview/data-governance-overview

Microsoft Purview：Data Governance roles and permissions。不同治理角色拥有不同级别的管理、质量、规则和访问职责，说明Owner、Steward与Reader/Consumer并不是同一层级的责任。

官方资料：https://learn.microsoft.com/en-us/purview/data-governance-roles-permissions

IBM：Data Governance。IBM的数据治理框架提出需要定义Data Owners、Data Stewards及其他Stakeholders的角色与职责，其中Data Owners对特定业务数据域承担准确性、质量和一致性等责任，而Data Stewards负责日常管理。

官方资料：https://www.ibm.com/think/topics/data-governance

IBM：Data Stewardship。IBM将Data Stewardship描述为数据治理的Operational Aspect，并将数据质量指标、Metadata、Reference Data、Lineage和数据分类列为典型职责。

官方资料：https://www.ibm.com/think/topics/data-stewardship

IBM：Stewardship Center。相关资料强调Data Steward在业务部门与IT之间处理Data Quality Issue、信息政策与治理流程的协作作用。

官方资料：https://www.ibm.com/docs/en/iis/11.3.0?topic=mgeisc-overview-stewardship-center

本文提出的 SEO/GEO Data Ownership Registry、Fact Authority Gate、Data Responsibility Matrix、Data Governance Escalation Path、Data Pull Request、SEO Data Steward、Knowledge Steward、AI Agent Operator Boundary以及Attribute-level Permission Model，属于本系列针对SEO、GEO、AI搜索与数字营销数据实践建立的工程治理框架，并不是Microsoft、IBM或其他机构联合发布的一套统一行业标准。