Yes. The constraint is scope, not capability, and once you see where the line sits most regulated operations turn out to have a large automatable layer underneath it.
This is not legal or compliance advice. It is how I would frame the problem before taking it to the people who give you that.
The line that matters
Explaining versus advising.
Telling someone what their policy already covers, what their balance is, when their renewal falls, what documents a process needs, how long something usually takes: that is explanation. It is factual, it is in your systems, and it has one correct answer.
Telling them which product suits them, whether they should claim, whether to switch, what is right for their circumstances: that is advice. In most regulated contexts that carries obligations around suitability, disclosure and record-keeping that an automated agent should not be discharging on your behalf.
Draw that line explicitly, in writing, before anyone builds anything. Then the design question becomes simple: everything on the explanation side is in scope, everything on the advice side escalates.
What sits below the line in practice
More than people assume.
In insurance: renewal dates and terms, what a policy covers, document requests, claim status, how the claims process works, updating contact details.
In financial services: balances, transaction queries, how a product works, application status, what a fee is for.
In utilities and telecoms: billing explanations, tariff mechanics, service status, appointment logistics.
That is a large share of total contact volume in every one of those sectors, and almost none of it requires a regulated conversation. It requires accurate access to a system and a clear answer.
The four things I would design in from the start
Grounding. Never let it answer from a model's general knowledge. Ungrounded, models hallucinate in the 15 to 27% range. Retrieving from your verified content first drops that under 1.5%. In a regulated setting that is not a quality preference, it is the difference between defensible and not.
Identity verification. An agent with read access can in principle read out anything on the record. What it demands before discussing an account, and what it refuses even after, should be explicit rules rather than emergent behaviour.
Full audit trail. Every conversation retained and retrievable against the customer. Assume you will need to show exactly what was said.
Vulnerability triggers. Explicit signals that route straight to a person, with context, no attempt to help first. This is the clearest case anywhere for escalating early.
What I would keep away from it entirely
Anything involving a decision on liability or a payout. Anything where the customer is in distress. Anything that would constitute a recommendation. Anything with a statutory response obligation where an automated acknowledgement might be read as the response.
None of that is a technology limit. It is a judgment about where the risk lives, and the correct answer is usually the conservative one.
The practical order of work
Get the scope line agreed with your compliance function before the build, not at review. It is cheap to define upfront and expensive to retrofit.
Start with the narrowest, most factual queue you have. Prove the grounding and the audit trail on something low-stakes.
Then widen, slowly, with the compliance people watching the transcripts rather than reading a summary. What convinces them is not a demo. It is fifty real conversations where the agent stayed inside its lane.
