AI agents for corporate travel duty of care: locating every traveler when a crisis hits, and the alert the agent never sends alone

A bomb goes off, a fault line slips, an airspace closes, a government falls, and a duty officer somewhere opens a spreadsheet and starts asking the only question that matters in the first hour: who do we have in that city, and are they alright? The industry’s own numbers say that question takes far too long to answer. Surveys of travel managers have found that a large share aren’t confident they could locate their people quickly in a crisis, and only about half believe they could account for everyone in an affected area within two hours. Two hours is a long time when the news is moving in minutes.

This is not the travel problem most AI writing is about. It isn’t booking a cheaper fare or automating an expense report. We covered the spend-and-policy side in AI agents for corporate travel and expense. This is duty of care: the legal and moral obligation an employer carries for the safety of an employee it sent on the road. It has moved from an HR courtesy to a board-level liability, and it’s a good fit for an autonomous agent. Provided you build the one gate that keeps the agent from ever telling a frightened person they’re safe when a human hasn’t confirmed it.

Why this is a build, not a product you buy

Set expectations honestly up front: Salesforce does not sell a “duty of care” feature you switch on. What it gives you is the right set of primitives (event-driven triggered agents, a real-time data layer, and a hard human-in-the-loop escalation path) and the work is assembling them into a workflow that matches a legal standard. That’s the honest framing and, usefully, it’s also the reason the pattern generalizes: it’s the cleanest example on our site of an agent that triages and drafts autonomously but is structurally forbidden from taking the consequential action alone.

The legal spine matters because it dictates the design. Duty of care isn’t vague good intentions (in the US it runs through OSHA’s general duty clause, in the UK through the Health and Safety at Work Act, across the EU through health-and-safety directives, and when a court asks whether an employer’s travel-risk program was reasonable, the benchmark it increasingly reaches for is ISO 31030:2021, Travel risk management) Guidance for organizations. Two things to state precisely, because vendors routinely blur them: ISO 31030 is a guidance standard, not a certifiable one. There is no “ISO 31030 certification,” though BSI offers a verification assessment against PAS 3001. And its Annex A effectively prescribes a documentation set: a policy, a risk register, traveler authorization records, an incident log, and post-incident reviews. That documentation requirement is not a footnote. It’s the reason every action your agent takes has to be logged as a record, which shapes the whole data model.

The data model: what the agent has to see

An agent can only act on what it can retrieve, and the hard truth of duty of care is that the agent’s reach is capped by itinerary capture, not by the agent’s intelligence. Reports consistently find that a large majority of business travelers book off-platform at least some of the time, and a trip nobody recorded is a person the agent structurally cannot locate, warn, or check on. So the first engineering problem is boring and decisive: get the itineraries in. Solve that before you build anything clever, because the smartest agent in the world is blind to the traveler who booked a hotel on their personal card.

Since there’s no native travel object model to lean on, build custom objects on the Platform. A workable shape:

Traveler, a Contact or User, with a consent flag governing whether their location may be tracked (this is not optional; more below).
Trip__c: the container: employee, purpose, date range, approval state.
TripSegment__c: the leg: flight, hotel, rail, or car, each with a location and a time window. This is the object the agent matches against, because “is this person in the danger zone right now” is a segment-level question.
Risk_Event__c: an incident from a risk-intelligence feed: type, geography, severity, source, timestamp.
Traveler_Alert__c and Incident__c, the audit log. Every check-in sent, every escalation raised, every human decision recorded, the ISO 31030 Annex A trail, as data you can produce for counsel later.

Itineraries and the risk feed come in through the Data 360 Ingestion API. TMC and GDS itinerary data on one side, a third-party risk feed (geopolitical, weather, health, civil unrest) on the other. Where a source can emit events, the Pub/Sub API carries them as platform events. The goal is a live picture: current segments joined to current risk, continuously.

A risk event arriving on the feed looks roughly like this:

{
  "eventId": "RISK-2026-08-30-0417",
  "type": "civil_unrest",
  "severity": "high",
  "geo": { "city": "Example City", "country": "XX", "radiusKm": 25 },
  "window": { "start": "2026-08-30T04:00:00Z", "active": true },
  "source": "risk-intelligence-provider",
  "guidance": "Avoid downtown; movement restrictions likely"
}

The trigger: matching risk to people, in near-real time

The heart of the system is a match: when a Risk_Event__c intersects the geography and the active time window of a TripSegment__c, someone is potentially in harm’s way and the agent should engage. The clean way to wire this is event-driven: a platform-event-triggered flow (or Apex) evaluates the intersection and invokes a triggered agent, the same “act on an event, not a prompt” pattern that underlies most back-office automation, and a sibling of Data 360-triggered flows.

One design honesty that changes the SLA math: invoking an agent from a record- or platform-event-triggered flow is asynchronous. It’s not a synchronous, sub-second response. There’s queueing and processing latency between the event landing and the agent acting. For most automations that’s invisible. For a crisis workflow where the internal target is often to account for travelers inside 30 to 60 minutes, it’s a constraint you design around and set expectations against. You use the event path precisely because it’s the closest to real time the platform offers, and you don’t pretend it’s instantaneous. Build the escalation so a human desk is engaged in parallel, not waiting downstream of a queue.

The Apex that a triggered flow can call to select the exposed population is deliberately simple and bulk-safe. Remember that an agent-invoked action runs under standard governor limits, so the query is bounded and does one job:

public with sharing class TravelerExposure {
    // Given a risk event's geo + active window, return the exposed, consented travelers.
    public static List<TripSegment__c> exposedSegments(Id riskEventId) {
        Risk_Event__c e = [
            SELECT Id, City__c, Country__c, Radius_Km__c, Window_Start__c
            FROM Risk_Event__c WHERE Id = :riskEventId
        ];
        // Segment-level match: same locale, overlapping the active window,
        // traveler has consented to location handling.
        return [
            SELECT Id, Trip__r.Traveler__c, Location_City__c, Start__c, End__c
            FROM TripSegment__c
            WHERE Location_City__c = :e.City__c
              AND Location_Country__c = :e.Country__c
              AND Start__c <= :e.Window_Start__c
              AND End__c   >= :e.Window_Start__c
              AND Trip__r.Traveler__r.Location_Consent__c = true
        ];
    }
}

Grounding: the agent may not invent a location

Everything the agent then says has to be true, and in a safety context an invented fact isn’t an embarrassing sentence. It’s a person told they’re clear of an incident they’re standing in the middle of. The discipline is the same one that keeps a booking agent from quoting a fare it made up: the agent answers only from grounded data, never from the model’s guess.

Concretely, a Data 360 retriever over the trip, segment, and risk objects is what the agent reads to answer “where is this traveler and what’s near them.” If the itinerary data isn’t there, the correct behavior is for the agent to say it can’t confirm the traveler’s location and escalate, not to reassure. “I don’t know where they are” is a safe, actionable answer. A confident guess is the failure that gets an employer into a courtroom.

The gate: what the agent does, and what it never does alone

Now the line that defines the whole build. Sort every action the agent could take into two bins, and enforce the sort in the architecture rather than trusting a prompt to hold it.

The agent owns, autonomously:

Send a consent-based check-in to exposed travelers (“Are you safe? Reply SAFE or NEED HELP”).
Collect and tally the responses, so the duty officer sees a live account of who’s confirmed safe and who’s silent.
Draft rebooking or evacuation options and a situation summary for the human desk.
Log everything to Traveler_Alert__c and Incident__c, the audit trail, written as it goes.

A human security desk must authorize, always:

Any substantive safety instruction: “stay in your hotel,” “move to the embassy,” “the airport is safe, go now.” A wrong reassurance here is catastrophic and irreversible.
Triggering an evacuation or committing spend against an emergency booking.
Closing an incident as resolved.

The mechanism is the escalation path the platform already gives you: the agent routes to a human through Omni-Channel handoff, pausing before any action that exceeds its defined authority. This is human-in-the-loop at its sharpest, not a compliance checkbox but the entire point, because the cost of a false “you’re safe” is not a refund or a rework, it’s a person who trusted a machine’s guess in the worst hour of their trip.

There’s also a regulatory reason the gate is non-negotiable, not just an ethical one. Under the EU AI Act, systems that bear on personal safety attract high-risk obligations including meaningful human oversight (Article 14), with the relevant obligations phasing in through 2026. We mapped what applies in the EU AI Act and your Agentforce deployment. A duty-of-care agent that autonomously issued safety directions wouldn’t just be reckless; it would likely be on the wrong side of the oversight requirement. The human gate is how you’re compliant and safe at once.

One more thing that isn’t optional and is easy to wave away until legal stops the project: location tracking of employees is a consent and privacy matter, not a technical convenience. GDPR, works-council agreements in parts of Europe, and general employment law mean the agent must respect an opt-in. That’s why the Location_Consent__c flag sits in the query above, a traveler who hasn’t consented is not silently tracked; they’re handled through a consent-respecting fallback (a broadcast the agent can send without pinpointing them, say). Build consent in from the first object, because retrofitting it after you’ve designed around always-on tracking is a rebuild.

The takeaway

Duty of care is where an autonomous agent earns its place and meets its hardest limit in the same workflow. The agent is good at the part humans are slow at: watching a risk feed around the clock, matching an incident to the exact segments in its blast radius, blasting out check-ins, and tallying who’s safe, compressing that agonizing first-hour “who’s there?” from a spreadsheet scramble into a live count. And it is genuinely, deliberately barred from the part humans must own: the reassurance, the evacuation call, the spend, the “resolved.” Build it as a triggered agent grounded on real itinerary and risk data, with a human security desk gating every safety-bearing action and every step logged for the ISO 31030 trail, and you get faster response without ever letting a probabilistic model make a life-safety decision on its own. Skip the gate, or skip the consent, or skip the itinerary capture that makes the whole thing see, and you’ve built something worse than the spreadsheet: a system that’s confidently wrong about whether your people are safe.

Understanding the basics

Can an AI agent handle corporate travel duty of care?

Partially, and that’s the point of designing it well. An agent can autonomously do the time-sensitive, high-volume work: monitor a risk-intelligence feed continuously, match incidents to the specific travelers whose itineraries put them in the affected area and time window, send consent-based check-in messages, tally who has confirmed safe, and draft options and summaries for a human desk, all logged for audit. What it must not do alone is issue substantive safety instructions (“stay put,” “go to the airport”), trigger an evacuation, commit emergency spend, or close an incident. Those are gated to a human security desk, because a wrong reassurance in a real crisis is catastrophic and, under regulations like the EU AI Act’s human-oversight requirements, likely non-compliant.

What is ISO 31030 and how does it relate to a travel-risk agent?

ISO 31030:2021 is the international guidance standard for travel risk management, and courts and auditors increasingly use it as the benchmark for whether an employer’s duty-of-care program was reasonable. It’s guidance, not a certifiable standard. There’s no “ISO 31030 certification,” though BSI offers a verification assessment against PAS 3001. For an agent build, the load-bearing part is its documentation expectation (Annex A): a policy, a risk register, traveler authorization records, an incident log, and post-incident reviews. That’s why a well-designed agent writes every check-in, escalation, and human decision to audit objects as it works, the audit trail is a requirement, not a nice-to-have.

Why can’t the agent just tell travelers what to do in an emergency?

Because the cost of being wrong is a person’s safety, and it’s irreversible. An agent that told someone to “stay in your hotel” or “the airport is clear, go now” based on incomplete or stale data could send them toward the danger. Two things forbid it: the practical fact that safety directions must come from a human who has verified the situation, and the regulatory fact that safety-bearing AI systems carry meaningful-human-oversight obligations under the EU AI Act. So the agent triages, drafts, locates, and communicates check-ins, and a human security desk authorizes any instruction that bears on a traveler’s physical safety.

Where does Salesforce fit if there’s no native duty-of-care product?

Salesforce provides the building blocks, not a packaged product. You model trips, segments, risk events, and an incident log as custom objects; ingest itineraries and a risk feed into Data 360 through the Ingestion API (and platform events via Pub/Sub); trigger an Agentforce agent when a risk event intersects an active trip segment; ground the agent on that data with a Data 360 retriever so it never invents a location; and gate every safety-bearing action to a human through Omni-Channel escalation. It’s an assembly of existing primitives (triggered agents, real-time data, human-in-the-loop handoff) into a workflow that meets a legal standard.

Building traveler-safety or crisis-response automation on Salesforce and trying to get the human gate, the consent model, and the audit trail right the first time? Talk to us: the hard part of a duty-of-care agent isn’t the automation, it’s the line where the agent stops and a human decides, and drawing that line correctly is the work that keeps the whole thing safe and compliant.