By Mark Lemmons, CTO, Topia
There are two futures for AI in global mobility. In one, every platform has a chat window and nothing underneath it has changed. In the other, AI is wired into the engines that actually run mobility: tax, policy, rates, compliance. The work itself changes.
In recent months, the most consistent thing I hear from senior mobility leaders who see Topia's AI is that it feels more operational than what they've encountered elsewhere. What they're sensing is which future the platform was built for: is it enabling agentic workflows (AI that takes actions across a process, not just answers questions) or is it a glorified help system?
The gap is real. The mobility technology market, and enterprise SaaS in general, is quickly filling with AI features, most of them chatbot interfaces layered onto legacy platforms. Vendors call it AI transformation. Sophisticated buyers are starting to notice it isn't.
This post is about the difference, and how to test for it in the room.
Two kinds of AI, one very different outcome
The first kind is chatbot-first AI: a user asks a question, the system generates a response, and it looks impressive in a demo. But the AI is typically reasoning against unstructured documents or a generic language model with no access to the data structures underneath the platform. The mobility context, policy rules, and jurisdiction-specific calculations are decorative. There is no clear line between what the system can calculate reliably and what the AI is merely guessing at.
Ask a chatbot-first system to assess pre-travel risk for a trip to Germany. It will return text about German tax thresholds and immigration rules, text that may even be accurate this time. But it is not specific to this employee, this trip length, this origin country, this compensation structure, or this employer's policy. It is a summary. It cannot be acted on with confidence.
The second kind is AI-native architecture on top of deterministic tooling: software that gives the same, verifiable answer every time it gets the same inputs, the way a calculator does. The mechanical difference fits in one sentence: the AI doesn't do the math; it decides which engine to call, and the engine does the math. Policy documents are not PDFs a chatbot summarizes on request. They are parsed into structured, machine-readable configurations an AI agent can reason against in real time. Pre-travel risk assessments are outputs of an engine that knows the specific tax authority rules and immigration requirements for this specific case. Cost simulations are calculated against structured rate tables and compensation data, not ranges pulled from historical averages.
Archimedes said, "Give me a place to stand, and a large enough lever, and I will move the world." In mobility, structured data is the place to stand and AI is the lever. A bolt-on chatbot offers neither: there is nothing solid underneath it, and nothing for it to push against.
Everyone knows AI can make mistakes. What matters is whether the architecture catches, contains, and can explain them, or quietly passes them into a payroll instruction. In a compliance-heavy, multi-jurisdictional domain like mobility, that is the difference between an AI you can trust and one you cannot.
What it actually takes to build AI for mobility
Building AI that works in global mobility is genuinely hard, not because of the AI, but because of what it must reason against. Mobility is structured complexity: tax authorities in 120-plus jurisdictions actively comparing notes, policy interpretation varying by case type and seniority, every decision carrying financial and compliance consequences downstream.
Here is what we had to build.
Structured policy data as a foundation. AI-generated text alone cannot be the source of truth in a high-compliance, finance and HR domain. Policies need to be validated, parsed, and connected into structured benefit configurations that the system can apply the same way, every time. That is the substrate everything else runs on.
Tax and immigration engines the AI can actually reason against. Generative AI without a reliable, domain-specific calculation engine is a liability in any context, and a disaster for mobility teams. The AI needs to call a real tax engine, not recall training data from the open internet.
Field-level audit trails. Every output an AI produces in the HR or finance arena needs to be explainable and traceable. Mobility teams operate under audit scrutiny, and "the AI recommended it" is not an acceptable answer to a tax authority. Here is what a journaled decision looks like in practice:
Housing allowance set to €3,400/month, derived from Policy v12 §4.2 (Long-Term Assignment, Band 3); Frankfurt rate table, March 2026 release; calculation run #18241; approved by [initials], 14:32 UTC.
No chatbot bolted onto a legacy platform can produce that line, not because the model isn't smart enough, but because the data it would need to cite doesn't exist underneath it.
Agentic workflows, with humans in charge. A mobility case involves dozens of decisions across stakeholders and timelines. A chatbot handles one exchange at a time; an agent manages the workflow: monitoring triggers, routing tasks, escalating exceptions across the full case lifecycle. Critically, agents propose and monitor; people approve. Every consequential action, including a payroll instruction, a benefit commitment, or a compliance filing, passes through a human approval gate. Autonomy without accountability is not a feature; it is a liability.
This is the work most vendors adding AI features to legacy platforms have not done. The chatbot is the easy part. The infrastructure underneath is where the real work lives.
Three tests to run in the demo
77% of mobility teams are currently piloting AI (The AI Inflection Point Report). The question is not whether AI will change how mobility functions operate. It is whether the AI your team is piloting can be trusted. Questions are easy for vendors: ask where their AI reasons, against what data, with what audit trail, and every demo script has an answer ready.
Tests are harder. Three to run live, in the room:
- Run the same cost estimate twice. Same employee, same destination, same parameters. If the numbers differ, even slightly, the system is generating, not calculating. A number that changes on refresh is not one you can put in front of a CFO.
- Pick any field in the output and ask where it came from. A real system shows you the policy clause, the rate table version, and the calculation. A chatbot shows you a prompt.
- Change one policy parameter and re-run. If updating the policy means re-uploading a PDF and hoping the summary changes, the policy was never structured data to begin with.
A chatbot-first system fails these tests in the room, in front of your team. No slide deck survives them. The difference between AI that saves someone five minutes and AI that changes how a function operates is exactly the infrastructure these tests expose.
Where this goes next
The next two years in global mobility will separate the retrofitted platforms from the purpose-built, and the leaders from the left behind. The shift from chatbots to agents is already underway: agents that manage multi-step compliance workflows, surface exceptions before they become problems, and operate across the full case lifecycle are in production today. The shift from AI features to AI infrastructure will follow.
Platforms that built AI on top of legacy architectures face a compounding problem: the foundation limits what the AI can do. Platforms that built the foundation first will extend their advantage as the technology matures.
Two futures. We built Horizon for the second one, not because it was the faster path to market, but because it was the only path to AI in mobility that leaders can trust.
Frequently Asked Questions
- What's the difference between chatbot-first AI and agentic AI in global mobility?
- Chatbot-first AI generates text responses against unstructured documents or a generic language model with no access to the data structures underneath the platform. Agentic AI is wired into deterministic tax, policy, rate, and compliance engines: the AI doesn't do the math, it decides which engine to call, and the engine does the math. The result is the same verifiable answer every time, with a full audit trail.
- Why is structured policy data important for AI in mobility?
- Generative AI alone cannot be the source of truth in a high-compliance HR and finance domain. Policies need to be parsed and validated into structured benefit configurations the system applies the same way every time. Without that substrate, the AI is summarizing PDFs rather than reasoning against the actual rules that govern a case.
- How can mobility leaders test whether a vendor's AI is real or a chatbot?
- Run three tests live in the demo: (1) Run the same cost estimate twice with identical inputs — different numbers mean the system is generating, not calculating. (2) Pick any field in the output and ask where it came from — a real system shows the policy clause, rate table version, and calculation. (3) Change one policy parameter and re-run — if updating policy requires re-uploading a PDF, the policy was never structured data.
- What is permanent establishment risk and how does AI infrastructure help manage it?
- Permanent establishment (PE) risk arises when an employee in a foreign country is deemed to create a taxable presence for their employer there. Managing it requires reasoning against jurisdiction-specific tax rules, employee activities, and policy context. An AI calling a real tax engine can surface PE exposure before approval; a chatbot summarizing training data cannot.
- What does a field-level audit trail look like in mobility AI?
- Every AI-influenced output in HR or finance needs to be explainable and traceable. A journaled decision reads like: 'Housing allowance set to €3,400/month, derived from Policy v12 §4.2 (Long-Term Assignment, Band 3); Frankfurt rate table, March 2026 release; calculation run #18241; approved by [initials], 14:32 UTC.' That citation chain requires structured policy data, versioned rate tables, and human approval gates — none of which a bolt-on chatbot can produce.
