创建数据术语词条

术语名称：数据主权（Data Sovereignty）

定义：
数据主权是指数据受其所在或被收集、处理、存储之法域的法律、监管与公共政策约束，并需在跨境流动、访问与使用过程中持续满足该法域对数据权利、合规和安全的要求。其核心关注点是数据的法律归属与管辖权，而不仅是数据物理驻留位置。

核心要素：
- 法域管辖：明确数据受哪个（或多个）国家/地区法律约束，包括域外适用条款。
- 跨境传输机制：为数据在法域之间流动建立合法机制及风险控制。
- 政府与监管访问：处理第三国政府或监管机构的访问请求与冲突法域风险。
- 权利与义务：保障数据主体权利、履行控制者/处理者义务（透明度、目的限制、保留期限、数据安全等）。
- 技术与组织控制：以技术手段和制度设计实现主权要求的可执行性与可审计性。

与相关概念的区别：
- 数据驻留（Data Residency）：指数据存储于特定地理位置或云区域的要求，是实现主权的一种技术手段，但不等同于满足主权要求。
- 数据本地化（Data Localization）：法律强制将数据在本国境内存储与处理（或限制跨境），是数据主权的强约束表现之一。
- 数据主权：更广，强调法律管辖与合规性，可包含驻留与本地化要求，也涉及跨境合规机制与政府访问问题。

适用范围与触发条件：
- 个人信息与敏感个人信息（例如身份、健康、金融数据）
- 重要数据与关键行业数据（能源、金融、通信、公共服务等）
- 行业或地区法定本地化要求
- 使用跨境云、全球共享服务、国际外包或数据交换场景
- 第三国政府访问风险（含域外执法或信息要求）

主要监管与合规参考（示例，需结合法务解读）：
- 欧盟：GDPR（跨境传输机制：SCC、BCR；Schrems II判决要求实质性保障与传输影响评估；欧盟—美国数据隐私框架适用于已认证的接收方）
- 中国：网络安全法、数据安全法、个人信息保护法（PIPL）；依据数据类型与规模触发的安全评估、标准合同或认证等跨境传输机制
- 巴西：LGPD（充分性、合同条款、同意等机制）
- 加拿大：PIPEDA（问责制与跨境转移要求）
- 俄罗斯：个人数据本地化法律框架（对本地存储有要求）
- 印度：DPDP法案（跨境传输由政府指定允许国家，细化规则需关注后续配套）
- 美国：无联邦综合隐私法，州法（如加州CPRA）对转移与披露有要求；CLOUD Act对第三国政府访问风险具有影响

治理目标：
- 确认并记录每类数据的主权要求与适用法域
- 为跨境处理建立合法、透明、可审计的传输与访问控制
- 降低第三国政府访问与冲突法域的合规风险
- 将主权要求纳入数据生命周期与架构决策，确保持续合规

治理控制与实践：
- 政策与标准
  - 数据主权政策：定义法域识别、驻留/本地化要求、跨境机制、政府访问应对与升级路径
  - 数据分类与标记：按主权要求、敏感性与行业归类，标记主权等级与传输限制
  - 跨境传输标准：SCC/BCR模板、合同附录、政府访问条款、补充保障措施（加密、拆分处理、访问限制）
- 组织与流程
  - 数据位置与流向登记：维护数据位置、处理活动与跨境流向台账（含备份、日志、监控数据）
  - 传输影响评估（TIA）/数据保护影响评估（DPIA）：评估第三国法律与政府访问风险，确定技术与合同补救措施
  - 供应商与分处理方治理：尽职调查、分处理方清单披露、地域与转移链路透明、政府访问通知义务
  - 监管请求应对流程：合法性审查、挑战与上诉策略、通知控制者/数据主体、记录与审计
  - 监管观察与变更管理：持续跟踪法域变化并更新控制
- 技术与架构
  - 地域控制：云区域固定（region pinning）、数据地理围栏（geo-fencing）、内容分发与缓存策略限制
  - 加密与密钥主权：端到端加密、客户自持密钥（CMK）、本地域HSM/KMS、密钥分离与分权管理
  - 访问控制与支援隔离：限制跨境管理访问与支持操作；最小权限与基于属性的访问控制（ABAC）
  - 数据最小化与去标识：分层数据集、脱敏/假名化/令牌化，减少跨境可识别数据
  - 可审计性：日志与证据在本地域保存，跨境导出受控；策略即代码（policy-as-code）
  - 备份与灾备主权：同域备份与演练；跨域容灾需具备合法机制与技术隔离
  - 主权云/隔离域：选择具备主权承诺与技术隔离的云与托管方案，防止第三国不当访问
- 合同与法律保障
  - 充分性机制、SCC/BCR、生效的认证路径（因法域而异）
  - 政府访问条款与通知义务、机密信息保护、数据驻留/本地化承诺、次级转移限制
  - 补充保障条款：强加密、密钥控制在本法域、挑战非透明访问请求

组织职责：
- 数据治理委员会：制定主权政策与优先级，监督合规与风险处置
- 法务与隐私：法域适用判定、合同机制、监管交互与争议处理
- 信息安全与架构：技术控制设计与落地、密钥策略、访问隔离与审计
- 业务与数据管理：数据分类、台账维护、跨境需求评估与替代方案设计
- 供应链与采购：供应商主权能力评估与持续监控
- 审计与合规：控制有效性验证、证据留存、改进建议

指标与审计证据：
- 已建立主权标记的数据集比例
- 具有合法跨境机制的传输比例与缺陷数
- 完成TIA/DPIA的跨境项目占比与整改周期
- 云区域固定与地理围栏覆盖率
- 客户自持密钥覆盖率、跨境支持访问事件数
- 监管或政府访问请求处理时效与合规性
- 审计发现数量、重复问题与闭环率

常见风险与误区：
- 误以为数据驻留等于满足主权要求（忽视政府访问与域外适用）
- 忽略备份、日志、遥测、CDN缓存、模型训练数据的跨境流动
- 管理平面与支持访问跨境绕过数据平面限制
- 密钥托管在他法域或由供应商控制，削弱主权保障
- 未维护分处理方与转移链路透明，导致不可控的次级转移
- 合同机制存在但缺乏实质性技术保障（Schrems II风险）
- 新法或判例变更未及时纳管，造成合规漂移

示例场景（简要）：
- 全球HR系统：在员工所在法域存储可识别数据；跨境仅传输假名化聚合报表；使用SCC与TIA并实施客户自持密钥。
- 医疗研究协作：本地保存原始敏感数据；跨境共享经去标识的数据；研究访问采用受控环境与审计。
- 金融云迁移：选择具有主权承诺的云区域；限制跨境管理访问；本地域HSM与密钥分离；分处理方清单公开与审批。

在数据治理框架中的位置：
数据主权是数据政策与合规域的核心主题，贯穿数据生命周期与架构决策，需与隐私、信息安全、数据质量、供应商治理、记录与审计等模块协同实施。

备注：
各法域要求、充分性决定、标准合同文本与阈值条件存在动态变化，实施前需结合最新监管文件与法务意见进行判定与更新。

Term: Data Lineage

Definition:
Data lineage is the complete, end-to-end record of how data moves, transforms, and is used across an organization’s ecosystem. It captures the origin of data, the systems and processes that ingest, transform, and deliver it, and the downstream assets and consumers that depend on it. Lineage is expressed as connected metadata describing datasets, fields, processes, jobs, systems, and their directional relationships over time.

Purpose:
- Traceability and accountability for critical data used in reporting, analytics, and operations.
- Impact analysis for changes, incidents, and regulatory inquiries.
- Risk reduction through visibility into dependencies, controls, and data usage.
- Evidence for compliance with internal policies and external regulations.

Scope and Granularity:
- Coverage: End-to-end (from external sources to consumption) across batch, streaming, API, and manual processes.
- Levels:
  - System-level: Movement between platforms or domains.
  - Dataset-level: Flow between tables, files, topics, reports.
  - Field/column-level: Derivations and transformations for individual attributes.
  - Record-level (provenance): Event- or record-specific lineage when required by high-assurance use cases.

Lineage Types:
- Business lineage: Abstract, understandable view aligned to business terms and processes.
- Technical lineage: Detailed implementation view derived from code, jobs, and runtime metadata.
- Logical lineage: Conceptual relationships independent of specific technologies.
- Physical lineage: Concrete paths across specific systems and assets.
- Static lineage: Derived from code and configurations.
- Runtime/operational lineage: Derived from executed jobs and runtime telemetry.
- Bidirectional lineage: Upstream (origins) and downstream (impacts).

Core Components:
- Nodes:
  - Dataset/asset (e.g., table, file, topic, report, model, API).
  - Field/attribute.
  - Process/transformation (e.g., SQL query, Spark job, ELT step).
  - Job/run (execution instance with timestamps and status).
  - System/application (platforms hosting assets/processes).
  - Actor/role (human or service).
- Edges:
  - Consumes/produces.
  - Derives from (field-level).
  - Reads/writes.
  - Executes/controlled by.
- Attributes:
  - Timestamps, versions, code references, configurations, data classifications, controls applied, data contracts, data quality checks.

Representation Model:
- Directed acyclic graphs (DAGs) for deterministic flows; may include cycles for iterative workflows.
- Temporal lineage: Versioned representations per code version and per job run for point-in-time reconstruction.
- Semantics:
  - Entities and relationships must be uniquely identifiable and resolvable.
  - Transformations should encode logic where feasible (e.g., SQL parse trees, UDF references).
  - Lineage should link to business glossary terms, policies, data quality rules, and ownership.

Capture and Maintenance Methods:
- Automated harvesting:
  - Static code parsing (SQL, ETL configurations, orchestration DAGs).
  - Runtime instrumentation and event capture from executors and orchestrators.
  - Connectors to catalogs, ETL/ELT tools, BI/reporting platforms, and streaming frameworks.
- Declared/manual lineage:
  - Curated mappings for opaque processes, legacy systems, or external vendors.
- Reconciliation and validation:
  - Compare declared lineage with observed runtime events.
  - Detect breaks due to schema drift, refactors, or undocumented processes.
- Change management:
  - Version control integration and CI/CD checks for lineage-impact assertions.
  - Approval workflows for lineage updates.

Governance Controls and Roles:
- Policies:
  - Mandatory lineage for Critical Data Elements (CDEs), regulatory reports, and PII flows.
  - Minimum granularity requirements (e.g., column-level for financial metrics).
  - Freshness SLAs for lineage updates tied to deployment and execution.
  - Access controls to prevent exposure of sensitive code, keys, or PII in lineage views.
  - Vendor and data-sharing lineage obligations in contracts.
- Roles and responsibilities:
  - Data Owner: Ensures policy adherence for owned domains.
  - Data Steward: Curates and validates lineage, resolves breaks, aligns with glossary.
  - Engineering/Platform: Implements harvesters, storage, APIs, and access control.
  - Producers/Developers: Provide code annotations and data contracts.
  - Risk/Compliance/Audit: Consumes lineage as evidence and for testing controls.

Quality Metrics (examples):
- Coverage: Percentage of CDEs with end-to-end lineage to consumption.
- Granularity: Percentage of lineage at column level for scoped assets.
- Accuracy: Ratio of validated edges vs total edges; discrepancy rate vs runtime events.
- Freshness: Median lag between execution and lineage availability.
- Completeness: Number of orphan nodes or dangling edges.
- Stability: Rate of lineage-breaking changes detected per release.

Common Use Cases:
- Impact analysis for schema changes, deprecations, and platform migrations.
- Root cause analysis for data incidents and quality regressions.
- Regulatory traceability for financial reporting, risk aggregation, and privacy obligations.
- Data access reviews and least-privilege validation.
- Model governance: Track features, training data, and model outputs to sources.
- Cost and performance optimization by identifying redundant pipelines and unused assets.

Risks and Pitfalls:
- Incomplete capture leading to false assurance.
- Overexposure of sensitive logic or data in lineage UI.
- Stale lineage due to missing runtime events or failed harvesters.
- Opaque transformations (UDFs, scripts) without declared mappings.
- Fragmentation across tools without a common model or identifiers.
- Confusing business users with overly technical views; lack of business lineage.

Standards and Interoperability:
- OpenLineage: Open standard for lineage events from data pipelines.
- W3C PROV: Conceptual model for provenance (useful for record-level provenance and interchange).
- ISO/IEC 11179: Metadata registry principles relevant to entity identification.
- Align lineage metadata with enterprise glossary, data contracts, and quality frameworks.

Related Terms:
- Data provenance: Event-level or record-level history and evidence; lineage is broader and typically at dataset/field abstraction.
- Data catalog: System that often stores and visualizes lineage with metadata and glossary.
- Data contract: Formal producer–consumer agreement that can be enforced and traced via lineage.
- Critical Data Element (CDE): High-priority elements requiring stricter lineage controls.

Example (conceptual):
Customer table fields are ingested nightly from CRM to a raw zone, standardized in a curated zone, joined with Orders to compute Customer_LTV in the Analytics schema, and visualized in a Finance dashboard. Column-level lineage maps Customer_LTV to its source fields and transformation logic, with job runs timestamped and linked to data quality checks and owners.

Notes for Implementation:
- Prioritize CDEs and regulated data flows for column-level, runtime-validated lineage.
- Use a central lineage store with APIs; enforce unique identifiers for systems, datasets, and fields.
- Integrate lineage checks into CI/CD and orchestrator hooks; alert on breaks and stale edges.
- Present both business and technical views, filtered by role-based access controls.

术语：敏感个人信息（个人敏感信息）

定义：
敏感个人信息是指一类个人信息，其泄露或被非法使用，容易导致对个人尊严造成侵害或对人身、财产安全造成严重危害。依据《中华人民共和国个人信息保护法》（PIPL）第28条，敏感个人信息包括但不限于：生物识别特征、宗教信仰、特定身份、医疗健康、金融账户、行踪轨迹，以及14周岁以下未成年人的个人信息。

术语边界与适用范围：
- 适用主体：所有在中国境内处理个人信息的组织与个人，以及对境内自然人个人信息进行处理的境外组织（符合PIPL适用条件）。
- 信息载体：电子与纸质形态的数据，含结构化与非结构化数据（日志、多媒体、文档、影像等）。
- 风险属性：以结果风险为导向的认定，除法定列举外，结合处理目的、方式、规模与可能影响，在具体场景中可将其他个人信息认定为敏感。

典型类别与示例（非穷尽）：
- 生物识别特征：指纹、人脸、虹膜、声纹、步态、DNA等。
- 宗教信仰：个人的宗教归属与相关活动记录。
- 特定身份信息：指能够体现个人在特定社会身份类别中的属性与标识的信息（依据具体法律场景认定）。
- 医疗健康：诊断、病历、检验结果、处方、残疾信息、心理与精神健康记录等。
- 金融账户：银行账户号、支付账户及其鉴权要素、账户余额与交易明细等。
- 行踪轨迹：定位数据、出行路径、连续位置记录（含基站、GPS、Wi‑Fi定位等）。
- 未满14周岁未成年人信息：任何与该年龄段未成年人相关的个人信息。

法律与合规要求（中国，PIPL为主）：
- 事前评估：在处理敏感个人信息前开展个人信息保护影响评估（PIPI），形成并留存评估报告与处理记录（PIPL第55条）。
- 单独同意：取得个人的“单独同意”，并向其告知必要性、处理目的、方式、范围、影响与保护措施（PIPL第29条）。
- 最小必要：遵循最小化原则，仅在达成明确、正当目的所必需的范围内收集与处理（PIPL第6条）。
- 强化保护措施：采取加密、去标识化/脱敏、访问控制、分级授权、日志审计与安全存储等措施（PIPL第51条）。
- 展示与公开：对外呈现时默认采取去标识化或必要的脱敏处理，避免可识别性与过度暴露。
- 跨境传输：开展安全评估或认证/签署标准合同，并履行告知与单独同意等要求（PIPL第38—43条及配套办法）。
- 权利保障：支持查询访问、更正、删除、撤回同意等权利；对未成年人需监护人同意与专门保护（PIPL第31、38条及相关条款）。
- 数据泄露应急：建立并演练处置流程，发生泄露时依法告知与报告（PIPL第57条）。

与其他法域的对应关系（简要）：
- 欧盟GDPR的“特殊类别个人数据”（special categories of personal data）包括：种族或民族、政治观点、宗教或哲学信仰、工会会员、遗传和生物识别数据（用于唯一识别自然人）、健康、性生活与性取向。该范围与PIPL存在交叉但不完全等同。
- 跨法域治理需进行映射与最严格规则对齐，避免合规空档。

数据治理要求与控制框架：
- 分类分级：在数据目录中建立“敏感个人信息”标签与分级规则（如S3/最高级），纳入元数据管理与血缘追踪。
- 准入与授权：实行基于角色与属性的访问控制（RBAC/ABAC），默认拒绝策略，临时授权与用途绑定，定期复核。
- 数据生命周期：从采集、传输、存储、使用、共享到销毁的端到端控制；明确保留期限与销毁标准（可审计）。
- 技术措施：加密（传输与静态、密钥分级管理）、脱敏（掩码、泛化、哈希、令牌化）、隔离（逻辑与物理）、数据泄露防护（DLP）。
- 运营与监督：设立数据所有者与数据保管人职责，建立审批与变更控制；对涉及敏感个人信息的项目强制PIPI与安全测试。
- 第三方管理：对受托处理者实施尽职审查、合同条款（保密、用途限制、子处理约束）、持续评估与现场审计。
- 监控与度量：关键指标包括分类准确率、PIPI覆盖率、单独同意获取率、访问违规率、DLP拦截事件、数据泄露MTTR、跨境合规完成率。

常见误区与校正：
- 误将所有身份证件号码一概认定为敏感：在中国法下，身份证号通常为个人信息；是否构成敏感取决于处理场景与风险（基于结果风险原则）。在高风险用途（如鉴权、金融交易）中应按敏感级别管理。
- 单独同意不足以替代最小化与评估：合规需同时满足必要性、PIPI与强化技术措施。
- 脱敏非一劳永逸：需评估重识别风险，结合数据用途动态调整技术策略。

参考依据（提名）：
- 《中华人民共和国个人信息保护法》：第6、28、29、31、38—43、51、55、57条等。
- 国家网信办等配套制度：个人信息跨境传输标准合同、出境安全评估相关规定（用于跨境场景）。

使用建议：
在组织的数据治理政策中，将“敏感个人信息”作为强管控对象进行专章阐述，明确定义、分级标准、处理准入门槛、技术与管理控制、审计与报告机制，并与安全、法务、合规职能形成闭环治理。