Governing ServiceNow AI agents: employee data under authority
ITSM and HR agents process the most sensitive data a company holds after its customers': its employees'. And automated decisions about employees are exactly what several regimes regulate most strictly.
ServiceNow's AI agents triage incidents, resolve requests, orchestrate HR and IT processes. Their raw material is tickets — and an HR or support ticket often contains far more than its category suggests: a sick leave, a payroll issue, a complaint, health data.
Platform roles and scopes decide which agent reads which tables. What they do not carry is the law that applies to the processing: an automated decision about an employee — prioritizing a complaint, handling an absence file — triggers, in several jurisdictions, duties of notice, human review and documentation. The workflow does not know that; your regulatory profile does.
The integration scenario
ServiceNow excels at calling external services from its flows: where your processing flow precedes the sensitive action — automated assignment of an HR file, communication of employee data, export to a third-party tool — an HTTP step calls the decision endpoint and routes on the answer. No application to install.
- 1
Generate your organization's profile
The free assessment (start here) establishes your jurisdictions, sector and data categories. The decisions your agents receive rest on that profile — not on generic rules.
- 2
Create an API key with the authority scope
From your StructureClerk dashboard. Evidence verification stays public and account-free — only the personalized decision goes through the key.
- 3
Insert the decision step in the flow
Before the sensitive action, an HTTP step calls the endpoint with metadata: action type, data categories, the affected employee's jurisdiction.
curl -X POST https://structureclerk.ca/api/v1/authority/decide \ -H 'Authorization: Bearer $API_KEY' \ -H 'Content-Type: application/json' \ -d '{"agent":{"id":"servicenow-hr-triage","autonomy_level":3},"action":{"type":"process.employee_feedback","data_categories":["personal","health"]},"context":{"jurisdictions":["CA_QC"],"sector":"health"}}' - 4
Route on the four verbs
ALLOW continues the flow. APPROVE creates a manager approval task. DENY stops the automated processing — the file returns to a human, with the reason. ESCALATE notifies compliance. The evidence attaches to the ticket: the audit lives in the file.
The decision contract
POST https://structureclerk.ca/api/v1/authority/decide
{
"agent": { "id": "servicenow-hr-triage", "autonomy_level": 3 },
"action": {
"type": "process.employee_feedback",
"data_categories": ["personal", "health"]
},
"context": { "jurisdictions": ["CA_QC"], "sector": "health" }
}
// →
{
"decision": "APPROVE",
"reason": "human_involvement_required_in_jurisdiction",
"confidence": 0.97,
"evidence_id": "ev_c93e…7b12"
}The decision is advisory — StructureClerk decides, your infrastructure enforces. The engine never reads the ticket: it decides on metadata, which keeps your employee data where it is.
| Decision | Effect in ServiceNow |
|---|---|
| ALLOW | The flow continues, evidence attached to the ticket |
| APPROVE | A manager approval is inserted before the action |
| DENY | Automated processing stops, a human takes the file back |
| ESCALATE | Compliance is notified, the action waits |
The audit trail your employees deserve
Every decision leaves Ed25519-signed, chained evidence. When an employee, a union or a regulator asks how an automated decision was made, you produce the trace — verifiable on our verification page, without an account, by anyone.
The jurisdictional dimension counts double in HR: the same automated processing can be unrestricted in one jurisdiction and require prior notice plus a human-review right in another. The engine carries that difference; a generic workflow cannot see it.
+How do I audit automated decisions about employees?
By rendering an authority decision before each processing step: the signed evidence carries the rule applied, the jurisdiction and the reason — including human involvement required in this jurisdiction. That is exactly the trace a regulator or staff representative will ask for.
+Do our ServiceNow agents really decide alone?
That is the right question, and the answer depends on the jurisdiction: some regimes specifically regulate fully automated decisions about individuals — notice, documented parameters, a right to human review. The authority layer makes that framework operational: it answers APPROVE or DENY when a human must step in.
+Do we need to install an app in our instance?
No. The integration is an HTTP step in your existing flows, before the sensitive action. The engine only receives metadata — never ticket content or employee files.
+What happens if our flow ignores the decision?
The action happens: the layer is advisory by design — StructureClerk decides, your infrastructure enforces. That choice keeps it out of your critical path. But the evidence exists and shows the decision was rendered: ignoring a DENY becomes a traceable choice, not an invisible accident.
Start with the profile
The assessment is what personalizes the decisions your agents receive. It is free, and only needs your website address.