Governance & Audit

Why governance is part of this role

The JD: "Classify all automation builds by risk tier before work begins. No build goes to production without a named Process Owner, documented data flows, and access controls confirmed." And: "Halt or redesign builds that introduce unacceptable payroll, legal, or data privacy risk."

This is not a separate compliance role hovering over engineering. The architect is the governance owner for People AI. You bring the framework; you maintain it; you say no when needed. Most candidates underprepare here because it doesn't feel like engineering. It is — it's the operating discipline that makes the engineering trustworthy.

Risk tiering framework

Every build is tiered before work begins. The tier dictates HITL, audit retention, model selection, eval rigor, and approval surface. A workable 4-tier model:

The tiering happens before a line of code. You bring a one-page proposal to a governance review:

• What problem this solves
• Proposed tier and why
• Data classification of inputs and outputs
• Proposed Process Owner (a named human)
• HITL design
• Halt criteria
• Eval plan
• Rollback plan

Named Process Owner

Every production agent has one named human on the People team who owns it operationally. The Process Owner:

• Approves any change to the agent's prompts, tools, or scope
• Reviews monthly metrics (approval rate, edit rate, refusal rate)
• Is the escalation point when something looks wrong
• Is named in every Slack alert the agent generates
• Owns the runbook

The architect is not the Process Owner — the architect is the builder and consultant. This is what "multiply the team's capability" means in practice: ownership transfers.

Data classification for HR data

A workable 4-class model. Whatever the company's policy is, expect something like this:

Implications for agent design:

• Restricted data triggers a separate code path — different MCP server, different audit retention, different approver pool
• Class travels with the data — when a Restricted field is pulled into a prompt, that prompt run is classified Restricted; its log retention and access list follow
• Restricted-class agent outputs are watermarked in any human-visible surface

Cross-jurisdictional privacy — what to actually know

You're not a lawyer. You should sound aware:

GDPR (EU / UK)

• Lawful basis — employer processing employee data has lawful bases (contract, legitimate interests, legal obligation). Sensitive data (health, biometrics) needs additional bases.
• Data minimization — collect / process only what's needed
• Purpose limitation — repurposing data for new uses needs review
• DSAR (Data Subject Access Request) — employees can request all data held about them. Your audit logs must be searchable per-subject.
• Right to erasure — limited in employment context (retention obligations dominate) but real for some data classes
• Cross-border transfer mechanisms — SCCs (Standard Contractual Clauses), Adequacy Decisions, BCRs. EU PII going to US-hosted services needs one of these.

US state-level

• California CCPA / CPRA — employee data is in scope as of 2023; rights to know, delete, correct, limit use of sensitive PI
• Colorado, Virginia, Connecticut, Utah, others — proliferating; employee data treatment varies; track an org-wide source of truth
• Illinois BIPA — biometric data has special restrictions

APAC

• Singapore PDPA — consent-based, with employment exceptions
• Japan APPI — strict cross-border transfer requirements
• Australia Privacy Act — APP framework, recent reforms tightening
• India DPDP Act — recent, evolving, requires attention

HITL checkpoint policy — the rules

HITL isn't a vibe; it's a policy. Document yours:

• What requires HITL: any action affecting pay, comp, FTE, employment status, benefits, tax, leaves, or any commit to Restricted data
• Who can approve: per-action approver pool, defined by role (HRBP, Payroll Ops, Legal). Two-key for T4.
• What "approve" means technically: a signed approval record with approver identity, timestamp, decision, optional edit, reason text
• What "edit" means: any change to the proposed payload invalidates the original idempotency key; a new key is issued; the edit is logged
• Time-out behavior: if no approval in N hours, the proposal expires; re-proposing requires fresh agent run
• Override path: emergency override requires CHRO designee + Payroll lead, logged with rationale

Halt criteria — when to stop

Every agent has explicit halt criteria, codified, not folkloric. Examples for the leaver agent:

• Worker country payroll is locked and termination effective date is within lock window
• Equity treatment proposal requires plan-document interpretation outside agent's training scope
• Severance amount exceeds country/role threshold ($X or 3× monthly base, whichever lower)
• Termination is involuntary and the worker is on protected leave (FMLA, parental, statutory)
• Worker is in a country the agent hasn't been evaluated for
• Schema validation fails on any proposed payload
• PII leakage test in canary input fails

Halt criteria are in the runbook. The agent doesn't just halt — it tells the Process Owner why, with the run_id, with the proposed action that triggered the halt.

Audit log design

The audit log is the regulator's view of your system. It must be:

• Complete — every input, every retrieved chunk, every prompt, every tool call, every tool result, every output, every approver decision, every commit, every error
• Immutable — append-only; corrections are new rows referencing the original
• Replayable — given a run_id, you can reconstruct what the agent saw and did
• Subject-searchable — for DSAR, find every entry referencing a worker_id
• Class-aware — Restricted-class entries have tighter access and longer retention
• Time-stamped to a trusted clock — not the agent process's local clock alone

@dataclass
class AuditEntry:
    run_id: str                    # ULID for this agent run
    parent_run_id: str | None      # for sub-agent chains
    step_kind: str                 # "prompt", "tool_call", "tool_result", "approval", "commit", "error"
    timestamp_utc: str             # ISO 8601 with timezone
    actor: str                     # "agent:onboarding-v3", "approver:user@", "system"
    data_class: str                # "public" | "internal" | "confidential" | "restricted"
    payload: dict                  # the actual content; redacted per data_class rules
    payload_hash: str              # sha256 of pre-redaction payload, for forensic correlation
    affected_subjects: list[str]   # worker_ids touched, for DSAR lookup
    workday_correlation_id: str | None  # ties to Workday BP / EIB run when applicable

Storage: a dedicated Postgres or warehouse table with row-level encryption for restricted-class entries; retention managed per policy; backups follow the same access controls.

Retention & DSAR — the policy collision

Two forces pull in opposite directions:

• Audit retention — internal policy + jurisdictional employment law may require 7+ years
• DSAR / erasure — employees in some jurisdictions can request data deletion

Design that handles both:

• Separate "operational data" (the worker record) from "audit data" (what the agent did)
• Audit data typically has a stronger retention obligation that overrides erasure
• Operational data can be redacted-in-place when erasure is granted; audit references stay as hash-only references
• Legal owns the call on what's retained vs erased; the architect provides the technical handle

The risk register — your operating artifact

A single source of truth for all production People AI builds. One row per agent:

This is the artifact you walk Legal, Privacy, Payroll, and Internal Audit through. It's also what an external auditor would ask for.

Interview framings worth memorizing

• "Every build gets risk-tiered before code. T1 to T4. Tier dictates HITL, audit retention, model selection, eval rigor."
• "I am not the Process Owner of anything I ship. A named HRKX human owns each agent operationally. That's how 'multiply the team' lands."
• "For cross-jurisdictional privacy I respect GDPR, UK GDPR, the major US state laws, and APAC frameworks. I flag for Legal; I don't unilaterally interpret."
• "Audit logs are immutable, replayable, subject-searchable for DSAR, and have class-aware retention. They are the regulator's view of the system."
• "My halt criteria are codified, not folkloric. They live in the runbook and the agent checks them explicitly."