AI tourism is slowing merchant adoption, but workflow AI still matters

At a glance

What this is: This is an analysis of why enterprise AI adoption in merchant operations is staying shallow, with the key finding that “AI tourism” is producing pilots more than production change.

Why it matters: It matters to IAM practitioners because customer-facing AI, refund automation, and decisioning workflows all depend on identity, access, and governance controls that determine who or what can act, approve, or override.

By the numbers:

• McKinsey analysis shows AI-powered next best experience capability can enhance customer satisfaction by 15 to 20 percent, increase revenue by 5 to 8 percent, and reduce the cost to serve by 20 to 30 percent.
• When 100 to 200 basis points of fraud can hide in refund claims alone, merchants must treat refund workflows as a control surface, not just a service process.

👉 Read Riskified's analysis of AI tourism, merchant AI adoption, and refund risk

Context

AI adoption in merchant operations often fails at the workflow layer, not the model layer. A stronger model or cheaper token cost does not automatically produce safe automation if the business process still depends on human review, identity checks, and exception handling. In this article’s framing, the real issue is whether conversational AI agents can be trusted to act inside customer-facing processes without weakening fraud controls or service quality.

The identity angle is real even though the article is not about IAM directly. When an AI system is allowed to answer, resolve, or override customer requests, teams have to decide how request identity is verified, how actions are authorised, and what level of privilege the system receives. That makes AI governance and identity governance intersect in the same operational workflow.

Key questions

Q: How should security teams govern AI systems that handle customer service actions?

A: Start by separating informational interactions from transactional ones. AI can safely answer low-risk questions, but any action that changes money, account state, or delivery details needs explicit policy, identity verification, and an audit trail. The question is not whether the model can respond, but whether it should be authorised to act.

Q: Why do customer-facing AI agents create fraud risk in refund workflows?

A: Because refund workflows combine natural-language interaction with value transfer. If the system trusts the request content without checking who is asking and whether the account behaviour fits the claim, fraud can hide inside normal service traffic. That makes identity signals and fraud controls part of the same decision path.

Q: What do organisations get wrong about AI automation in merchant operations?

A: They often treat AI as a prompt layer instead of a process layer. A clever chatbot does not create durable value unless the underlying workflow is redesigned, the authority boundaries are explicit, and exception handling is built in. Without that, teams end up with pilots, not production control.

Q: Who should approve high-stakes actions taken by customer-facing AI systems?

A: High-stakes actions should either require human approval or a tightly constrained policy path with strong verification. If the AI can refund, override, or change account details on its own, the organisation has effectively given it transactional privilege. Accountability should remain with the business owner of the workflow.

Technical breakdown

Why AI tourism produces demos but not durable automation

AI tourism describes a pattern where organisations create pilots, proof of concepts, and prompt experiments without redesigning the process around them. The model may be capable, but the surrounding workflow is still built for human approvals, fragmented data, and exception handling. That means the AI remains a layer of assistance rather than a system that can safely absorb work end to end. In merchant environments, this gap is especially visible where customer requests have financial impact, fraud exposure, or brand risk. Practical implication: evaluate whether the workflow has been redesigned for machine participation, not just augmented with a chatbot.

Practical implication: measure production workflow replacement, not demo volume, before treating AI as operationally adopted.

Identity-aware decisioning in refund and service workflows

Identity-aware decisioning means the system does not only inspect the request content, but also the context around who is asking, how the account behaves, and whether the transaction looks consistent with past activity. In customer operations, this matters because a refund request, address change, or order status question can be legitimate service or a fraud attempt. AI agents that sit in front of these flows need policy boundaries, escalation conditions, and assurance that the request identity is trustworthy enough for the action being taken. Practical implication: pair AI service automation with identity signals and step-up controls for higher-risk requests.

Practical implication: require stronger verification before any AI system can execute high-value customer changes.

Guardrails define whether conversational AI is assistive or authoritative

A conversational agent can safely answer low-stakes questions while still being unfit to complete high-stakes actions. The technical boundary is not language quality, it is delegated authority. If the system can change shipping details, issue refunds, or close disputes, then it is operating as a decisioning layer, not a front-end helper. That shifts the governance requirement from content moderation to action control, auditability, and bounded privilege. Practical implication: define which intents are informational, which are transactional, and which require human approval before deployment.

Practical implication: classify intents by risk and restrict autonomous action to the lowest-risk cases only.

Threat narrative

Attacker objective: The attacker seeks to convert routine service automation into a fraud channel that approves illegitimate refunds or account changes.

1. Entry occurs through customer-facing AI workflows that accept natural-language requests without strong identity verification or fraud context.
2. Escalation happens when the system is permitted to take transactional actions, such as refunds or address changes, based on incomplete trust signals.
3. Impact follows when fraudulent requests blend into service traffic, allowing abuse to hide inside routine claims and erode margin and trust.

NHI Mgmt Group analysis

AI adoption is stalled less by model capability than by governance debt. The article’s core point is that better models and lower token costs do not solve the organisational problem of unsafe process design. Merchant teams are discovering that without workflow redesign, AI remains a pilot artefact rather than a control-bearing system. The governance lesson is that adoption stalls when automation is bolted onto human processes instead of embedded into them.

Identity-aware decisioning is becoming a necessary control layer for customer-facing AI. Refunds, order changes, and other service actions are not just language understanding problems. They are decisions about who is asking, what they are entitled to do, and whether the requested action is consistent with the account and transaction history. That makes identity verification, fraud signals, and action policy part of the same operating model. Practitioners should treat AI service flows as identity-governed transactions, not conversational convenience.

High-stakes AI should be measured by delegated authority, not prompt fluency. The article rightly separates low-stakes from high-stakes interactions, and that distinction is the right governance boundary. A system can answer questions well and still be unsafe to execute refunds or change delivery details. The field needs clearer language for what an AI system is authorised to do, because the real risk is not bad wording but bad action. Practitioners should define action tiers before expanding autonomy.

Refund claims reveal a fraud surface that looks operational but behaves like access control. When merchants allow automated handling of value-bearing requests, they are effectively granting transactional privilege. That privilege needs policy, verification, and audit just like any other sensitive entitlement. This is where IAM thinking becomes useful outside the identity team: access to customer outcomes should be controlled with the same seriousness as access to systems. Practitioners should map service automations to privilege boundaries.

What this signals

AI governance is converging with identity governance faster than many merchant teams expect. Once an AI system can resolve, refund, or override customer requests, it enters the same control territory as privileged business access. That means the programme question is no longer only model accuracy, but who can delegate action, how that delegation is constrained, and how it is audited. Teams already working through NIST Cybersecurity Framework 2.0 can map these flows to access control and recovery responsibilities.

Action authority will become the new boundary for customer-facing automation. The sharpest governance question is not whether an AI assistant can converse well, but whether it can safely execute a value-bearing action without human intervention. That pushes practitioners toward explicit policy tiers, stronger verification for sensitive intents, and tighter linkage between identity signals and workflow decisions. For identity teams, this is the same logic that underpins privileged access control, just applied to AI-mediated customer outcomes.

For practitioners

• Classify customer intents by risk tier Separate informational requests, low-risk service actions, and high-impact account or refund changes before enabling automation. Require human approval or step-up verification for any intent that can move money, change delivery state, or alter account control.
• Bind AI actions to identity and fraud signals Use account age, device context, prior dispute history, and transaction anomalies as part of the authorisation decision. The AI should not act on the text of the request alone when the outcome has financial impact.
• Limit delegated privilege for customer-facing agents Define the exact actions an AI system can perform and revoke any permission that exceeds its current business function. Treat refunds, shipping changes, and dispute closures as privileged operations with explicit policy boundaries.
• Instrument audit trails for every autonomous decision Log the request identity, confidence, policy path, and final action for each AI-mediated customer transaction. This creates the evidence needed for fraud investigation, model review, and accountability when automation behaves unexpectedly.

Key takeaways

• Merchant AI adoption is slowing where organisations confuse demos with operational change.
• High-stakes customer interactions require identity-aware decisioning, not just better prompts.
• AI automation becomes governable when teams define delegated authority, verification, and audit boundaries.

Key terms

• AI Tourism: A pattern where organisations experiment with AI through demos, prompts, and pilots without redesigning the underlying process for production use. The result is visible activity but limited operational change, because the system remains dependent on human workflows and does not absorb meaningful business work.
• Identity-Aware Decisioning: A control approach that evaluates both the request and the requester before allowing an action. In customer operations, it combines identity, behaviour, and transaction context so the system can distinguish legitimate service from fraudulent or out-of-policy requests.
• Delegated Authority: The specific set of actions a system is allowed to perform on behalf of a human or business process. For AI systems, delegated authority must be explicit, limited, and auditable so that automation does not silently inherit privileges beyond its intended role.
• Transactional Privilege: The ability to carry out business actions that change value, account state, or customer outcomes. When granted to AI systems, transactional privilege should be treated like elevated access, with policy boundaries, verification, and logging comparable to other sensitive privileges.

What's in the full article

Riskified's full analysis covers the operational detail this post intentionally leaves for the source:

• McKinsey-linked business impact estimates for AI-powered next best experience in customer operations
• The identity clustering and identity-based decisioning angle behind refund claims abuse
• The full merchant context around why CEOs are reluctant to loosen guardrails for conversational AI agents
• The difference between low-stakes and high-stakes customer interactions in live merchant workflows

👉 Riskified's full article adds the CEO Forum context and the fraud-control implications behind workflow AI

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity security. It gives practitioners a practical foundation for connecting identity controls to broader automation and access decisions.