The default way to rank AI support agents is by resolution rate: which one closes the most tickets without a human. For a regulated business, that is the wrong first question. A fintech, healthtech, or insurance team is not graded on how many tickets an agent resolved. It is graded on whether every action the agent took can be explained, justified, and reproduced months later when a regulator, an auditor, or a customer's lawyer asks for the record. An agent that resolves 70% of contacts but cannot show why it issued a refund, what data it read, or which policy it followed has not reduced cost. It has added risk that lands on the compliance team's desk.

So the better question is: which AI agents resolve customer issues without creating regulatory exposure? That reframe changes what you evaluate. Certifications matter, but a SOC 2 report or a signed HIPAA business associate agreement is the floor, not the differentiator. The architecture underneath, how the agent decides, what it logs, and what stops it before it sends a non-compliant message, is what determines whether you can defend its behavior. This guide compares eight AI agents on auditability and compliance, gives you a cert matrix and a list of questions to ask each vendor, and explains why the audit story is an architecture story.

Why auditability is the real buying criterion in regulated CX

In a regulated industry, an AI support agent is a system that takes consequential actions on customer accounts: moving money, changing coverage, accessing protected health information, processing disputes. Each of those actions is subject to rules. HIPAA governs how protected health information is accessed and disclosed. GDPR governs lawful basis, data residency, and the right to erasure. Financial regulators expect that any automated decision affecting a customer can be reconstructed and explained. The common thread is accountability: you must be able to show, after the fact, exactly what happened and why.

That is what an audit trail is for. A genuine audit trail is not a transcript of what the agent said. It is a per-conversation record of what the agent knew, which sources it read, which rules it applied, what it decided, and which actions it took in your backend systems, with timestamps and attribution. Without that, a regulator's request becomes a forensic reconstruction across logs that were never designed to be read together. With it, the request is a lookup.

Two failure modes matter most. The first is the black-box resolution: the agent closed the ticket, but no one can say how, because the decision happened inside a model with no recorded reasoning. The second is the unconstrained action: the agent did something the policy forbids, because nothing deterministic sat between the model's output and the customer. Most AI agents on the market today were built to maximize the first metric, resolution, and treat the audit trail and the safety layer as features bolted on afterward. For regulated teams, that ordering is backwards.

Quick comparison: 8 AI agents on auditability and compliance

The table is a starting point. The rows that matter most, audit-trail depth and architecture, are the hardest to verify from a marketing page, which is why the vendor-question checklist later in this guide focuses there. Note one row immediately: Decagon does not hold HIPAA at the time of writing. If you handle protected health information, that is a disqualifier, not a detail.

How these eight were selected

This list is built for teams in regulated industries that need their AI agent to take real actions, not just answer questions. The selection criteria were: the platform is positioned for or actively used in customer service for regulated verticals; it publishes or confirms at least SOC 2; it operates across the channels regulated teams actually use (chat, email, and increasingly voice); and it has a defensible position on at least one of the two things that drive regulatory exposure, the audit trail and the safety layer.

We deliberately included vendors with different architectures, from AI-native specialists to enterprise contact-center platforms to AI layered onto a legacy helpdesk, because architecture is the variable that most affects compliance. We excluded pure ticketing systems and copilot-only tools that surface suggestions to a human but never act, since they shift the audit burden back onto agents rather than removing it. Certifications were taken from vendor documentation and public references; where a vendor's HIPAA posture is "confirm with sales," we say so rather than asserting a cert the vendor has not published.

What a full audit trail actually requires

"Full audit trail" is a phrase every vendor will claim. To evaluate it honestly, define what it has to contain. A regulated-grade audit trail for an AI agent should let you answer, for any single conversation, the following without leaving the record:

• Decision rationale. Why did the agent take the action it took? Not just the output, but the reasoning that led there, captured as the conversation happened rather than reconstructed afterward.

• Source attribution. Which knowledge articles, policies, or records did the agent read to reach its answer? Grounding the response in a retrieved, citable source is the difference between an auditable answer and a hallucination you cannot defend.

• Action log. What did the agent write to your backend systems, when, and with what parameters? A refund, a policy change, a data access, each needs a timestamped entry tied to the conversation.

• Guardrail record. What checks ran before the message went out, and did anything get blocked or corrected? An audit trail that only records what happened, and not what was prevented, hides the most important compliance signal.

• Reproducibility. Can you replay the decision and understand it later, after models have been updated and knowledge has changed? Point-in-time capture matters because the system will not be identical in six months.

• Exportability. Can you get the record out, in a form an auditor or regulator can consume, without a custom data-engineering project?

Two architectural choices determine whether a vendor can deliver this. The first is whether the agent records its reasoning per conversation rather than logging only inputs and outputs. The second is whether there is a deterministic, non-AI layer that sits between the model and the customer, checking every outbound message against your rules. A model checking its own work is not a control. A separate, rule-based gate that can block or correct a message is. For a deeper treatment of why that gate matters, see our explainer on how AI guardrails work and the companion piece on what AI guardrails are for customer service.

The 8 AI agents with audit trails, compared

1. Lorikeet

Lorikeet is an AI concierge platform built for digital-native scale-ups in regulated industries, fintech, healthtech, and insurance, where every action has to be precise, policy-safe, and auditable. It resolves customer issues end to end across voice, chat, and email by reading and writing in backend systems (payment platforms, CRMs, internal databases) to complete multi-step workflows such as refunds, policy changes, and dispute handling, following the same standard operating procedures a human agent would. It layers on top of the existing helpdesk (Zendesk, Intercom, Front, HubSpot) rather than replacing it, so it does not become a new system of record you have to re-certify.

On auditability, Lorikeet's design starts from the compliance question rather than retrofitting it. Every conversation produces a per-conversation reasoning trace: timestamps, the sources the agent read, the decision rationale, and the actions it took, captured as the conversation happens and exportable. That trace is the audit record, not a transcript you have to interpret. Crucially, the reasoning is grounded in retrieved sources rather than generated freely, which is what makes an answer defensible rather than a liability.

The second pillar is a separate, deterministic guardrail layer. This is not the model checking itself. It is a non-AI, rule-based layer that inspects inbound messages and checks every outbound message before it reaches a customer, blocking or correcting anything that violates your policies. Because the layer is deterministic, its behavior is itself auditable and reproducible: you can state the rule, point to where it fired, and show what it prevented. Across Lorikeet's production deployments this layer has demonstrated a high rate of self-correction, catching and fixing issues before they reach the customer rather than after.

The third pillar is configurable determinism, what Lorikeet describes as three speeds of control. For a given task you choose how much AI judgment applies: fully agentic for open-ended help, natural-language workflows for guided processes, or deterministic if-then decision trees for the steps where there is exactly one correct path and no room for model discretion. A regulated team can make a refund-eligibility check or a data-disclosure step fully deterministic while letting the agent reason freely on low-risk questions. That per-task control is the practical heart of the audit story: you decide where judgment is allowed, and the record shows the rule that governed each step.

Lorikeet's compliance posture is SOC 2, HIPAA, and GDPR, with full auditability and Australian data residency available, and it is built specifically for regulated industries. (It is not PCI compliant, so payment-card-data workflows that require PCI scope should be handled accordingly.) The combination of a per-conversation reasoning trace, a deterministic guardrail layer, and configurable determinism is what places auditability at the architecture level rather than treating it as a reporting add-on. For a fuller treatment of the auditability thesis, see auditable AI support in 2026, and for the fintech-specific view, AI customer support for fintech. Teams weighing Lorikeet against AI-native specialists can also read Lorikeet vs Decagon and Lorikeet vs Sierra AI.

2. Fin (Intercom)

Fin is Intercom's AI agent, and it carries a broad certification set: SOC 2, ISO 27001, ISO 42001, HIPAA, and GDPR. For teams already standardized on Intercom, that breadth plus the native fit is the appeal. Fin performs well on the easier end of the ticket spectrum, answering knowledge-based questions inside the Intercom environment.

The auditability questions for regulated teams are about depth and retention. Fin's records live as conversation logs within Intercom; the practical question to put to the vendor is how long those logs are retained and whether the retention window meets your regulatory obligations, which can be longer than a default support-tool window. The deeper architectural point is that Fin was designed primarily as an answer engine layered onto a helpdesk; where it acts on complex tickets, ask exactly how the decision and the action are recorded, and whether there is a deterministic check between the model and the customer. For more on where Fin's design hits limits in regulated contexts, see Intercom Fin's limitations in regulated industries.

3. Salesforce Agentforce

Agentforce is Salesforce's agent layer, and its strongest case is for enterprises already standardized on Salesforce. It carries SOC 2 and HIPAA, and it inherits the Salesforce platform's mature audit and access-control tooling, which is a real advantage if your system of record and your compliance processes already live there.

The trade-off is that Agentforce's auditability is platform-bound: the record is as good as Salesforce's logging, and the agent's reasoning visibility depends on how the platform surfaces it. For regulated teams the questions to ask are whether the agent's decision rationale (not just the data it touched) is captured per conversation, whether there is a deterministic guardrail between the model and the customer, and how the agent behaves when it has to act across systems that are not Salesforce. For organizations not already committed to the Salesforce ecosystem, the platform gravity can outweigh the convenience.

4. Kore.ai

Kore.ai is an enterprise conversational-AI platform with a strong security and deployment story: SOC 2, ISO 27001, GDPR, and an on-premises deployment option that appeals to organizations with strict data-control requirements. For large enterprises that want to keep data inside their own environment, the on-prem option is a differentiator few competitors match.

On HIPAA specifically, regulated healthcare teams should confirm the current business-associate-agreement posture directly with Kore.ai rather than assuming it. On auditability, the platform offers enterprise-grade conversation logging; the evaluation questions are the same as for any enterprise platform: does the log capture decision rationale and source attribution per conversation, and is there a deterministic layer that checks outbound messages rather than relying on model confidence. The platform's enterprise heft can also mean a longer configuration cycle, which matters if you need to move quickly.

5. Decagon

Decagon is an AI-native support agent that has built a reputation on resolution performance for consumer brands. For regulated teams, the headline fact is the disqualifier: Decagon holds SOC 2 only and does not have HIPAA at the time of writing. If you handle protected health information, that ends the evaluation for healthcare workflows regardless of how well the agent performs elsewhere.

Beyond the HIPAA gap, the auditability questions concern action depth and the safety layer. Decagon's integrations are often read-oriented by default, with action-taking treated as a paid extension, which affects how much of a workflow it actually executes and therefore how much there is to audit on the action side. As with any agent, ask how the decision is recorded per conversation and whether a deterministic check sits between the model and the customer. Teams comparing the two directly can read Lorikeet vs Decagon.

6. Ada

Ada is an established AI-native customer-service platform with a solid compliance set: SOC 2, HIPAA, GDPR, and the AIUC-1 standard. It scales deflection well across channels and languages, which suits high-volume consumer support, and the HIPAA coverage means it can be considered for healthcare contexts where Decagon cannot.

For regulated action-taking, the questions are about depth rather than certification. Ada's strength is in answering and deflecting at scale; where it executes multi-step actions, ask how the decision rationale is captured per conversation, whether the audit record ties actions to the reasoning that produced them, and whether a deterministic guardrail layer (as opposed to model self-checking) governs outbound messages. Its per-conversation commercial model is also worth understanding, since pricing structure can interact with how aggressively an agent is tuned to resolve versus escalate.

7. Cognigy

Cognigy is an enterprise conversational-AI platform with particular strength in voice and contact-center automation, carrying SOC 2, ISO 27001, and GDPR. For organizations whose regulated workload is heavily voice-based, Cognigy's contact-center depth is a genuine fit, and the European compliance posture is well suited to GDPR-bound operations.

HIPAA should be confirmed with the vendor for healthcare use. On auditability, Cognigy provides enterprise conversation logging across its channels; the evaluation focus for a regulated buyer is whether voice interactions in particular produce the same depth of decision-and-source record as text, since voice audit trails are often thinner in practice, and whether a deterministic layer checks responses before they reach the customer in real-time voice contexts where there is little time to correct after the fact.

8. Boost.ai

Boost.ai is a European conversational-AI platform with a strong presence in enterprise and public-sector deployments, where data protection and predictable behavior are non-negotiable. Its GDPR alignment and enterprise governance posture make it a natural consideration for European-regulated organizations, and its emphasis on controlled, predictable conversation design fits buyers who want tight bounds on agent behavior.

HIPAA posture should be confirmed directly for healthcare contexts. The auditability questions mirror the other enterprise platforms: confirm that the conversation logs capture decision rationale and source attribution rather than only the dialogue, and confirm whether a deterministic guardrail layer governs outbound messages independently of the model. Boost.ai's controlled-design philosophy can be an advantage for auditability, provided the record makes the governing rules and their firing visible per conversation.

How to choose: the questions to ask each vendor

Certifications tell you a vendor cleared a bar. They do not tell you whether the agent's behavior is auditable in the way your regulators expect. The way to find that out is to ask the same set of architecture-level questions of every vendor and compare the answers. Treat vague or "confirm with sales" answers on the core questions as a signal in itself.

• What exactly is in the audit trail for a single conversation? Ask them to walk you through one record. You are looking for decision rationale, source attribution, and a timestamped action log, not just the message transcript.

• Is the agent's reasoning captured as it happens, or reconstructed? Point-in-time capture is defensible; after-the-fact reconstruction is not. Ask whether you can see why the agent acted, not just what it did.

• Is there a deterministic layer between the model and the customer? Ask whether a separate, non-AI, rule-based gate checks every outbound message, and whether that gate's behavior is itself logged. A model reviewing its own output is not a control.

• Can I make specific steps deterministic? For the steps where there is one correct path (eligibility checks, data disclosure, money movement), ask whether you can remove model discretion entirely and have the record show the rule that governed it.

• How long are audit records retained, and can I export them? Confirm the retention window meets your regulatory obligations and that you can get the record out in an auditor-readable form without a data project.

• How are answers grounded? Ask whether responses are retrieved from approved sources and cited, or generated freely. Ungrounded generation is a hallucination risk, and a hallucination in a regulated context is a compliance event.

• What is your HIPAA business-associate-agreement posture, in writing? If you handle protected health information, get this confirmed in writing, not as a sales assurance. Remember that one vendor on this list (Decagon) does not hold HIPAA.

• Where does data reside, and can you meet my residency requirement? For GDPR and other residency rules, confirm where data is stored and processed.

Compliance and audit-trail matrix

The matrix below summarizes the publicly stated or vendor-confirmed posture for each platform. "Confirm via sales" means the vendor has not published the cert and you should get it in writing for your use case. Always verify against the vendor's current documentation, since compliance posture changes.

Two patterns stand out. First, most platforms cluster on certifications, so certs alone will not separate them; the audit-trail and architecture columns are where the differences live, and those are the columns hardest to verify without the vendor walking you through a real record. Second, the one clear cert-level disqualifier for healthcare is Decagon's lack of HIPAA. Everything else on this matrix is a question of depth, and depth is what the vendor-question checklist above is designed to surface.

Why Lorikeet wins on auditability

Lorikeet treats the audit trail as the consequence of how the system is built rather than as a report generated after the fact. Three capability pillars carry that.

A per-conversation reasoning trace. Every conversation records not only what the agent said and did, but why: the sources it read, the rules it applied, the decision it reached, and the actions it took in backend systems, with timestamps and source attribution, captured as the conversation happens and exportable. That makes "show me why the agent did this" a lookup rather than a reconstruction, which is exactly what a regulator, auditor, or customer dispute requires.

A separate deterministic guardrail layer. A non-AI, rule-based layer inspects inbound messages and checks every outbound message before it reaches the customer, blocking or correcting anything that breaks policy. Because the layer is deterministic, its behavior is reproducible and auditable in its own right: you can state the rule, show where it fired, and show what it prevented. A model that checks itself cannot give you that. Across Lorikeet's production deployments this layer has shown a high rate of catching and self-correcting issues before they reach the customer.

Configurable determinism. Three speeds of control, fully agentic, natural-language workflows, and deterministic if-then decision trees, let a regulated team decide per task how much model judgment is allowed. The high-risk steps (eligibility, disclosure, money movement) can be made fully deterministic with no model discretion, while low-risk questions stay flexible. The audit record then shows the governing rule for each step, so the level of control is visible, not assumed.

Underpinning all three is a compliance posture of SOC 2, HIPAA, and GDPR with full auditability, built for regulated industries, and data residency options including Australia. The result is that auditability is a property of the architecture: the reasoning trace makes decisions explainable, the deterministic guardrail layer makes safety provable, and configurable determinism makes the level of control a choice you can document. For regulated teams, that is the difference between an agent you can deploy and one your compliance team will not sign off on.

If your team operates in fintech, healthtech, or insurance and needs an AI agent whose every decision and action can be explained and defended, book a Lorikeet demo to see the reasoning trace, the deterministic guardrail layer, and configurable determinism on your own workflows.