Should Digital Workers Enter HR Systems? The Governance Case for a Unified Worker Registry

Introduction: The Registration Chaos

As AI agents ("digital workers") proliferate in enterprises, HR and IT face a new registration problem. Digital workers are scattered across IT agent platforms and business-unit systems with no unified ledger: who created them, what they can do, who governs them, and how permissions are revoked upon decommissioning often remain unmanaged. Meanwhile, HR systems only recognize "people." This raises a deceptively simple question: should digital workers enter the HR system?

Pre‑AI Precedent: HCM Systems Already Use a "Worker" Superclass

Mainstream Human Capital Management (HCM) platforms such as SAP and Workday have long used a two‑level hierarchy. The top level is Worker (工作者) — a superclass covering every entity that performs work for the enterprise. The subtype Employee (雇员) refers only to those with a labor contract, on the payroll, and covered by social insurance. External consultants, on‑site contractors, and dispatched personnel have always been placed under Worker but outside Employee. This design exists precisely because enterprises have never relied solely on employees to get work done.

Key insight: The Worker/Employee distinction is not an AI‑driven invention; it has been standard in HCM systems for years.

Two Pre‑Existing Worker Categories (Before Digital Workers)

Employee: Labor contract, labor relationship, on payroll, social insurance. Includes full‑time, part‑time, fixed‑term, interns, apprentices.

Contingent Worker (灵活用工工作者): Commercial/service contract, no labor relationship, off payroll, paid per delivery. Includes contractors, external consultants, dispatched staff, freelancers, individual partners.

The boundary is determined by three questions: labor contract vs. commercial contract? Labor relationship? On payroll? The nature of the work (coding, design, consulting) is irrelevant — the same task can be done by an employee or a contingent worker.

Why Digital Workers Are a Third Category, Not a Subtype of Contingent Worker

At first glance, digital workers resemble contingent workers: no labor contract, no social insurance, pay‑per‑use, elastic scaling. For procurement and cost accounting, the analogy holds. But master data modeling must also answer: who governs this object, how is accountability structured, and what data relationships does it require? On these grounds, digital workers differ fundamentally:

Governance object differs. Contingent workers are natural persons; governance covers employment relations, attendance, and service acceptance. Digital workers are software entities; governance requires identity, authorization scope, dependent model/skill versions, runtime guardianship, quality/cost monitoring, and permission revocation at retirement — closer to software asset and configuration management.

Behavior and responsibility differ. Digital workers execute automatically within authorized scope; actions are logged, auditable, and state changes can be rolled back before commitment. They have no volition and no labor relationship, yet cannot be treated as "another person" for delegation. Contingent workers exercise autonomous judgment and bear personal responsibility; their actions cannot be rolled back like instructions.

Data associations differ. Digital workers must link to invoked capabilities (skills, models), connected systems (registered as Configuration Items in CMDB), and task contracts. Contingent workers link to contracts, billing, and service periods. Stuffing digital workers into the contingent worker bucket leaves no place to attach these software‑side relationships.

Exclusion: Pure hardware robots (e.g., floor‑scrubbing bots, material‑handling AGVs) remain fixed assets managed by equipment owners. Only software agents that cross system boundaries, process business data, and hand off results to others qualify as digital workers.

Three Implementation Patterns for the Unified Worker Registry

Regardless of where the registry lives, the enterprise must be able to answer in one place: who is working, what can they do, who is accountable, and when do they go offline? Three viable patterns:

HR system extension. Add a Digital Worker subtype under the existing Worker superclass. Suits enterprises with a strong HR platform and unified human capital system.

Organizational Operating System (OOS) as system‑of‑record with bidirectional sync. HR manages human workers; OOS manages digital workers. Both share the same Worker superclass, ID scheme, and identity rules; state changes sync both ways. Suits IT‑centric organizations with fast‑growing digital worker populations.

Lightweight unified ledger first. Before systems are integrated, maintain a single spreadsheet or simple database listing all workers (human + digital) with identity, type, owner, authorization scope, and status. Solve "is there a registry?" first, decide system ownership later.

Common baseline: System ownership can be flexible, but the Worker superclass must be unified. Long‑term coexistence of HR‑only human rosters and scattered digital‑worker silos is unacceptable.

Master Data Structure: Fields and Relationships

Following standard master data practice, the Worker superclass holds common attributes; each subtype holds its specific attributes.

Worker Superclass (shared)

Worker ID

Type (Employee / Contingent Worker / Digital Worker)

Name

Current status

Belonging organization

Roles played

Accountability scope

Subtype‑Specific Attributes

Employee: labor contract, position, payroll link, social insurance links.

Contingent Worker: commercial contract, service period, settlement method.

Digital Worker: authorization scope, referenced capabilities/models, versions, named guardian, runtime monitoring config, retirement plan.

Relationships to Other Core Entities

Worker is a subtype of Party (参与方), alongside Organization (internal departments and external legal entities).

Workers are assigned to tasks via Task Contracts (任务契约) and reference required Capabilities .

Customer, supplier, partner are roles a Party plays in different contexts; collaboration and reporting lines hang on Party, not on separate entities.

This structure keeps commonalities in the superclass, specialties in subclasses, and prevents conflating human employment data with software governance data while allowing both to be discovered, scheduled, and audited from a single registry.

Conclusion

Whether digital workers "enter HR" is not a software feature question but an organizational governance question: does the enterprise want every actual working entity in a single identifiable, authorizable, and accountable registry? Using Worker as the superclass spanning humans and AI is not about coining a new term; it lets both categories be visible under one order while preserving their distinct boundaries — employees keep labor relations, contingent workers keep contract boundaries, digital workers keep authorization and guardianship. A practical starting point: inventory existing digital workers, merge them with human workers into a unified worker ledger, then decide whether HR or an Organizational Operating System will own it. Digital workers can scale rapidly, but the organization must not let them linger in a "no registry, no owner" state.