Who is responsible for governing AI agents when they dispatch field service technicians and make autonomous decisions?

The short answer is that the enterprise deploying the AI agent carries primary accountability, even when the agent operates across vendor platforms, dispatches third-party contractors, or makes diagnostic decisions on its own. When an AI agent assigns the wrong technician to a gas leak emergency, orders a part that never arrives, or misdiagnoses an HVAC compressor and schedules a repeat visit, the customer does not blame the model provider. They blame the service organization whose name is on the truck. That reality, more than any regulation, is why AI agent governance for field service has become a board-level topic in 2026.

The Governance Gap That Field Service Exposed

Also worth reading: What Is the Best AI Software for Field Technicians in 2026? · How Do Field Technicians Troubleshoot Equipment Offline in 2026? · How Should Field Technicians Harden AI Edge Devices in 2026?

In early 2026, SailPoint's Field CTO publicly mapped what the industry now calls the AI agent governance gap: organizations adopted agentic AI faster than they built the controls to manage it. ServiceNow, Salesforce, and Synthflow have each published postmortems describing how agentic customer and field operations ran into operational problems — agents escalating incorrectly, duplicating work orders, or acting on stale data. In field service specifically, the stakes are physical. An agent that hallucinates a diagnostic step can send a human into a hazardous situation, damage equipment under warranty, or void a service-level agreement worth hundreds of thousands of dollars per contract.

The core problem is that agents do not respect system boundaries. A single work order lifecycle may touch a CRM, a scheduling engine, an inventory system, an ERP, and a contractor portal. The publication 'Who Governs AI Agents When Workflows Cross Platforms?' from erp.today crystallized the question most CIOs were already asking: when Salesforce's Agentforce books the appointment, Dynamics 365 dispatches the technician, and a third-party routing engine optimizes the route, which platform owns the audit trail? The honest answer in most deployments today is nobody, and that is the gap governance programs exist to close.

Regulators are moving in parallel. The EU AI Act established a legal framework that classifies AI systems by risk tier, and Singapore published its Model AI Governance Framework for Agentic AI, extending existing guidelines to agent-specific risks such as autonomous tool use, multi-step decision chains, and agent-to-agent interactions. Field service organizations operating internationally cannot assume these frameworks will stay advisory. The direction of travel is clear: deployable autonomy requires demonstrable control.

Why Accountability Defaulted to the Deployer

Legal accountability under the EU AI Act and similar emerging frameworks follows the deployer role, not the model developer. OpenAI, Anthropic, Google, and the large enterprise software vendors provide the reasoning capability, but the deployer decides what the agent is permitted to do in production. When Salesforce states in its AI governance guidance that trust and ethics responsibility sits with the organization configuring the system, it is restating the legal position, not deflecting blame. Microsoft's 2026 announcement that governance capabilities are now generally available for Dynamics 365 Customer Service reinforces the same point: the platform gives you the tools, but someone inside your organization has to use them.

The deployer-centric model makes practical sense in field service because only the deployer understands the consequences of agent error. A software vendor cannot know that a missed boiler inspection at a commercial site creates regulatory liability under local safety codes, or that dispatching an uncertified contractor to electrical work voids insurance. Those are operator judgments. Governance frameworks therefore place the burden on the service organization to define what the agent may decide autonomously, what requires human sign-off, and what evidence must be retained to prove the agent behaved correctly.

There is also a contractual dimension. Field service organizations typically operate under SLA and SLA-penalty regimes negotiated years before agentic AI existed. Most of those contracts contain no language about machine-made dispatch decisions. Until contracts are renegotiated, the deployer absorbs the liability for agent mistakes because nothing shifts it to anyone else. Vendors' terms of service almost universally disclaim consequential damages, which is exactly the category into which a failed field intervention falls.

What AI Agent Governance Actually Looks Like in Field Service

Effective governance for a dispatch and diagnostics agent rests on four layers. The first is identity and access: every agent gets its own service identity, scoped credentials, and explicit permissions, so it can be authenticated, logged, and revoked independently of human users. SailPoint and other identity vendors have pushed this as the first control because agents that share human credentials are effectively unauditable. In a field service context this means the agent can read the work order queue and write dispatch decisions, but cannot, for example, modify pricing contracts or customer payment records.

The second layer is decision boundaries. Governance requires an explicit, written definition of which decisions the agent may make alone — for instance, assigning routine maintenance jobs under 2 hours with no hazardous-materials flag — and which require human confirmation, such as emergency calls, jobs exceeding a dollar threshold on parts, or any intervention involving gas, high voltage, or confined spaces. Mature deployments express these as machine-readable policies evaluated at decision time, not as documentation nobody reads. The threshold should be reviewed quarterly; most organizations start conservative, with 100% human review, and relax controls as measured accuracy improves.

The third layer is observability. Every agent decision — what it considered, which data it used, what it rejected, and why — must be logged in a format a human auditor can reconstruct. This matters most when agents orchestrate across platforms: the dispatch agent's decision needs to be traceable even when the actual technician assignment happened inside a vendor's system. Fourth is escalation and kill-switch: a defined human owner, a monitoring threshold (for example, complaint rate above 2% of agent-handled jobs triggers review), and the ability to halt the agent and revert to manual dispatch within minutes, not days.

Comparing the Governance Approaches of Major Platforms

Most field service organizations do not build governance from scratch; they inherit whatever their platform provides. The large vendors have converged on the same architecture — policy engines, audit logs, human-in-the-loop checkpoints — but with meaningfully different maturity and scope.

Salesforce's approach, documented in its public AI governance guidance, is the most explicitly trust-and-ethics oriented, with guardrails enforced in the Einstein Trust Layer before data reaches the model. Microsoft's 2026 governance release for Dynamics 365 Customer Service focuses on administrative control and visibility for service operations, which maps well onto dispatch supervision. ServiceNow benefits from its process-governance heritage: its workflows were already auditable, so agents inherit that structure. Smaller platforms, including no-code agent builders like Creatio's 10x release with its enterprise governance layer and Synthflow's voice agents, offer lighter-weight controls that can be adequate for small deployments but rarely satisfy enterprise audit requirements without additional tooling. The critical evaluation question for any platform is not whether it has a governance dashboard, but whether an external auditor can reconstruct a specific agent decision end-to-end, including cross-platform steps.

Practical Steps to Put Governance in Place

Start with an agent inventory. Most organizations discover they have more agents than they thought — a scheduling assistant embedded in the FSM product, a diagnostics recommender in the parts system, a voice agent answering customer calls. List each one, its owner, the decisions it makes, and the data it touches. A governance program that does not know what it governs is theater. This inventory should be completed within 30 days and treated as living documentation.

Second, assign a named human owner per agent. Not a committee — a person who answers for the agent's behavior the way a service manager answers for a technician. Third, define decision tiers in writing: autonomous, recommended-with-approval, and human-only. For a typical field service operation, a reasonable starting split is autonomous for routine scheduling and parts lookups, approval-required for anything involving safety flags, third-party contractors, or costs above roughly $500, and human-only for emergency dispatch and warranty judgment calls. Fourth, implement the logging and kill-switch mechanisms before expanding agent autonomy, not after the first incident. Fifth, run a 60-to-90-day supervised pilot on a low-risk slice — say, non-emergency commercial maintenance in one region — and measure agent decisions against human baselines for accuracy, SLA compliance, and first-time-fix rate before widening scope.

Finally, close the contractual loop. Renegotiate customer SLAs to acknowledge automated dispatch, and review vendor terms to understand exactly what liability they accept for model failures. McKinsey's field service research on scaling generative AI from pilot to profit consistently identifies governance and trust as the gating factor: the organizations that scaled were the ones that solved measurement and control first, not the ones that deployed fastest.

Common Mistakes That Create Real Risk

The most expensive mistake is treating governance as a documentation exercise. A 40-page policy that no runtime system enforces will not stop an agent from dispatching an uncertified contractor, and it will not help in litigation. Policies must be encoded as the runtime constraints the agent actually checks. The second mistake is shared identity: letting agents operate under human logins destroys auditability and makes it impossible to answer the question 'what did the agent do' separately from 'what did people do.'

A third mistake is over-trusting benchmark performance. An agent that achieves 95% accuracy on historical work-order data may perform far worse on edge cases — concurrent emergencies, incomplete customer records, new equipment models. Field service error distributions have fat tails, and the 5% is where the dangerous outcomes live. Fourth, organizations frequently forget the contractor layer. Agentic dispatch increasingly routes work to third-party technicians, and the deployer remains accountable for whether that contractor was qualified, vetted, and correctly instructed. Finally, many teams under-invest in post-deployment monitoring, assuming the agent that behaved well in the pilot will behave well forever. Models drift, integrations change, and customer data changes shape. Quarterly reviews with defined metrics — first-time-fix rate, repeat-visit rate, escalation rate, complaint rate — are the minimum viable monitoring posture.

When to Act, and What It Costs

Act now if you already have agents touching dispatch, scheduling, or customer communication in production. The regulatory trajectory — EU AI Act enforcement, Singapore's agentic framework, and similar work in other jurisdictions — plus the contractual exposure from legacy SLAs means the cost of governance rises with every month of uncontrolled operation. If you are still in evaluation, build governance requirements into vendor selection: ask each vendor the cross-platform audit question and score the answers.

On cost, governance is mostly an operating expense rather than a capital one. Platform-native governance features for organizations already on Microsoft, Salesforce, or ServiceNow are typically bundled in enterprise tiers, with incremental costs concentrated in implementation services — realistic budgets run from roughly $50,000 for a single-agent setup with one platform to $500,000 or more for multi-platform, multi-region deployments with independent audit support. Dedicated AI governance tooling for identity and policy enforcement adds per-agent or per-seat subscription costs, commonly in the range of a few dollars to tens of dollars per identity per month depending on scale. Set against the cost of a single serious field incident — a safety event, a forfeited enterprise SLA, or a regulatory penalty — the governance spend is modest. The timing consideration is asymmetrical: governance added before an incident is a compliance line item; governance added after one is a remediation project conducted under regulatory and customer scrutiny.

The Bottom Line

AI agent governance in field service is not a barrier to automation; it is the precondition for autonomy you can defend. The deployer owns accountability, the platform provides the control surfaces, and the governance program — identity, decision tiers, observability, escalation — converts that accountability from a liability into a manageable engineering discipline. Organizations that encode their operational judgment into enforceable agent policies will expand autonomy safely. Those that treat governance as paperwork will discover, at the worst possible moment, that no one was actually in charge of the machine that sent the truck.