This is Chapter 6, the final chapter in a series walking through ServiceNow's AI stack from the ground up. The first five chapters moved from platform fundamentals through Now Assist, agentic AI, and integration layers — each one adding capability. This chapter is different in kind: it's not about what's possible, it's about what you're accountable for once it's running.
Every capability chapter so far ended with "here's what to review before trusting the output." This chapter is what happens when that review discipline has to scale past one person checking one script — to an enterprise instance, multiple modules, and an audit trail someone else will eventually read.
1. Data Residency: Where Does It Actually Go?
"Where does the data go" isn't one answer for "AI on ServiceNow" — it depends on which feature, which model, and how it's configured. A useful habit is running every new AI feature through the same short decision tree before enabling it against real data.
Is the model hosted within your instance's own tenant boundary,
or a shared multi-tenant service?
├─ Own tenant → confirm data doesn't leave your compliance boundary
└─ Shared service → ask: is the data used for further model training?
├─ Yes → this needs explicit compliance sign-off, not assumption
└─ No, per vendor terms → confirm that contractually, not verbally
Does the feature send full record content, or only specific fields?
├─ Full record → higher exposure if the record has sensitive fields
└─ Scoped fields → lower exposure, but confirm the scope is enforced,
not just documented
Is there a regional/geographic processing constraint on this data?
├─ Yes (e.g. data residency law, contractual clause) → verify the
processing region matches before enabling
└─ No known constraint → still worth documenting that you checked
What to actually learn: run this tree per feature, not once for "AI" as a category. Now Assist's summarization skill and a custom Agent Studio agent calling an external model may have entirely different answers to the same three questions, even on the same instance.
2. License & Consumption Impact
AI features typically consume against separate entitlements from the base platform license, and consumption can scale in ways that aren't obvious until you've enabled a few modules at once.
Example — a sample cost-impact view across three modules:
| Module | AI Feature Enabled | Consumption Driver |
|---|---|---|
| ITSM | Incident summarization | Per-summary generation, scales with ticket volume |
| CSM | Case summarization + Virtual Agent | Case volume plus conversational turn count |
| HRSD | Case summarization | Case volume, typically lower than CSM but seasonal spikes (open enrollment, etc.) |
The point of a table like this isn't the exact numbers — those depend on your actual contract and usage — it's the shape: consumption drivers differ by module, and a module with a seasonal spike (HR case volume around open enrollment, for instance) can produce a consumption spike that looks alarming in isolation but is entirely predictable if someone mapped it in advance.
What to actually learn: build this kind of module-by-module consumption map before rollout, not after the first invoice surprises someone. It's also useful ammunition for exactly the ROI conversations that come up when justifying AI feature adoption to budget holders.
3. How AI-Generated Changes Show Up in the Audit Trail
This is worth checking directly rather than assuming, because it affects whether an AI-assisted change is actually distinguishable later from a manual one.
Example — a human-made change vs. an AI-drafted one, in the audit log:
Human-made change (sys_audit record):
fieldname: close_notes
oldvalue: (empty)
newvalue: "Replaced faulty network cable, confirmed connectivity restored."
user: jane.smith
reason: (not typically captured)
AI-drafted, human-approved change (sys_audit record):
fieldname: close_notes
oldvalue: (empty)
newvalue: "Replaced faulty network cable, confirmed connectivity restored."
user: jane.smith
reason: (not typically captured — the record looks identical to the
human-made one above)
That similarity is the actual finding worth sitting with: unless your instance is specifically configured to tag AI-assisted edits — for instance, logging that a field's content originated from a generative action before a human edited and submitted it — the standard audit trail doesn't distinguish "an agent drafted this and a human approved it" from "a human wrote this from scratch." For most day-to-day work that's fine. For anything falling under a compliance framework that cares about decision provenance, it's a gap worth closing deliberately, not discovering during an audit.
What to actually learn: if AI-assisted decision provenance matters for your compliance posture, verify explicitly whether your instance captures that distinction, and if it doesn't, treat that as a configuration gap to raise — don't assume the audit trail is telling a more complete story than it is.
4. Infrastructure Dependencies Underneath It All
AI workloads don't run in a vacuum — they add query and processing load to the same platform infrastructure everything else depends on, and that infrastructure is itself changing underneath ServiceNow with RaptorDB's rollout as the HTAP replacement for MariaDB/MySQL.
A real example of why this isn't a footnote: a prior IRE (Identification & Reconciliation Engine) schema mismatch incident occurred when VR USEM, Rapid7 AppSec, and Discovery/Service Mapping were upgraded simultaneously — the resulting log volume ran to roughly 6 million entries per hour. That's not an AI-specific incident, but it's exactly the kind of platform-level fragility that matters more, not less, once AI features are layered on top and depending on the same CMDB reconciliation pipeline for grounding data. An agent summarizing "related CIs" during a period like that isn't just slow — it may be working against data mid-reconciliation.
What to actually learn: treat plugin upgrade governance and infrastructure changes like RaptorDB as directly relevant to AI feature reliability, not a separate platform-ops concern. Before rolling out or expanding an AI feature that depends on CMDB or reconciliation data, ask whether there are any upgrades scheduled that touch the same pipeline — the two workstreams should be coordinated, not siloed.
Series Wrap-Up
Six chapters, one thread running through all of them: every layer of ServiceNow's AI stack is only as trustworthy as your ability to review what it hands you, and that review discipline has to scale as the stakes go up — from a single generated script in Chapter 3, to an agent composing its own tool-call sequence in Chapter 4, to a governance posture that holds across an entire instance in this chapter.
If there's one habit worth carrying forward past this series, it's the question this chapter kept returning to: where does this data actually go, and who's accountable for what it did? Ask that before enabling a feature, not after.
This series:
- Chapter 1 — Platform Fundamentals for AI-Ready ServiceNow
- Chapter 2 — Now Assist as a Consumer
- Chapter 3 — Now Assist for Creator
- Chapter 4 — Agentic AI: Otto, Agent Studio, Build Agent
- Chapter 5 — Action Fabric & MCP
- Chapter 6 — Governance & Platform Impact (this chapter)