Quick answer: Staying compliant when you use AI for customer support means being able to show an auditor, for any single conversation, what data the AI touched, which rules it followed, where it handed off to a human, and how you know it behaved that way. That proof rests on four controls: data handling that limits and redacts PII and PHI, deterministic guardrails that hold at runtime, pre-deployment testing with simulations, and 100% post-conversation QA backed by an audit trail. Certifications such as SOC 2, ISO 27001, HIPAA and GDPR attestations establish that the vendor runs a controlled environment, and a signed BAA and DPA make the vendor's obligations enforceable. Everything else in a compliance review is evidence that those four controls operate in production rather than on a slide. Lorikeet is built around this model: it holds SOC 2 Type 2, ISO 27001:2022, HIPAA and GDPR attestations, signs BAAs, and ships guardrails, simulations and 100% conversation review as product features.
This guide is written for the people who have to sign off: heads of support, compliance officers and security reviewers. It covers what auditors actually ask, how each control works, what the BAA and DPA need to say, and a checklist you can hand to any vendor.
What regulators actually ask about AI in customer support
Auditors and regulators rarely ask whether you use AI. They ask whether you can prove what the AI did. The questions below recur across SOC 2 and ISO 27001 audits, HIPAA risk assessments, GDPR reviews and examinations by financial-services conduct regulators. The EU AI Act adds transparency and human-oversight expectations, and its questions land in the same places.
What personal data does the AI receive, and where does it go? The auditor wants the full path: channels, source systems, model vendors that see the text, retention at each party, and whether any of it trains models.
Who can see that data? This covers tenant isolation between the vendor's customers, which vendor staff can access production data, how that access is authenticated, and how often it is reviewed.
What is the AI allowed to do, and what stops it from doing anything else? A written policy is the starting point. The auditor then wants the technical control that enforces it: the guardrails, the workflow gates and the escalation rules.
How did you know it worked before you turned it on? Pre-deployment testing evidence, including what was tested, what failed, what was fixed, and who approved go-live.
How do you know it is still working? Ongoing monitoring and quality review, including how much of the conversation volume is actually reviewed and what happens when a review finds a problem.
Show me this conversation. Given a complaint or a sampled ticket, produce the complete record: inputs, retrieved context, actions, guardrails fired, versions, output and handoff. The time it takes to produce it is itself a finding.
What happens when the AI is wrong? Escalation paths, customer remediation, complaint handling, and the feedback loop into workflows and knowledge.
Does the customer know they are talking to an AI, and can they reach a human? Disclosure and the right to a human channel are explicit expectations under the EU AI Act and implicit in most conduct rules on fair treatment.
Read together, these questions map onto four controls: data handling, runtime guardrails, pre-deployment testing and post-conversation QA with an audit trail. Certifications tell you the environment is managed. The four controls tell you the AI itself is managed. A vendor can hold every certificate and still fail the conversation-level questions; confusing platform compliance with AI compliance is the most common gap in reviews.
How do I stay compliant when using AI for customer support in financial services?
Financial-services conduct regulators care about outcomes for customers: accurate information, fair treatment, proper handling of complaints and vulnerable customers, complete records, and accountability for outsourced functions. An AI support agent is treated the same way as an outsourced contact center. You own the outcome regardless of who built the model. In practice, staying compliant comes down to five steps.
Classify every intent by risk before the AI touches it. Informational questions (how to update an address, where to find a statement) sit at the low end. Account-changing actions (card replacement, limit changes, payment reversals) sit in the middle and need identity verification and logging. Anything that resembles regulated advice, a credit decision, a hardship arrangement or a complaint sits at the top and should be either fully deterministic or routed to a human.
Keep high-risk paths deterministic. For KYC checks, disputes, refunds and hardship, use a structured workflow with fixed steps rather than an open-ended generative response. The AI can gather information and explain status; the decision logic stays in code or with a person.
Record everything at the moment it happens. Logs reconstructed after the fact do not satisfy record-keeping obligations. The trace must be captured live and retained for as long as your record-keeping rules require.
Treat the vendor as a material third party. Run the due diligence you would run on a BPO: attestations, sub-processor list, contract terms, exit and data-return provisions.
Watch conduct signals, not only cost signals. Escalation rates, complaint rates and Critical QA scores are the metrics a conduct regulator will ask about. Report them alongside resolution rate and cost per ticket.
The financial-services page covers how these steps map to specific workflows for banks, lenders and fintechs.
Control 1: Data handling and PII/PHI
Data handling is the control auditors examine first because it is the most likely to produce a reportable incident. The principles are familiar: collect the minimum, redact what you do not need, restrict who can see it, keep it only as long as required, and be transparent about every party that touches it. AI adds two new parties, the vendor and the model providers behind it, and a new use to prohibit, model training.
How is PII handled by AI customer support agents?
Follow the data through a single conversation and you will find six points where a control needs to exist.
Ingestion. The message arrives from chat, email, voice or SMS. Voice adds a transcription step, so that provider is also a sub-processor. Ask which vendors sit behind each channel.
Redaction. Before the text goes anywhere else, PII that the workflow does not need should be detected and masked. Card numbers, government identifiers and full dates of birth rarely need to reach a language model. Automated redaction should be on by default, with a configurable list of what is preserved for verified workflows.
Context retrieval. The agent pulls account details from your helpdesk, CRM or core systems. The scope of that retrieval should follow the same minimum-necessary rule as a human agent's screen: only the fields the current intent requires.
Inference. The redacted message and the retrieved context are sent to one or more model providers. This is the step that decides whether your data leaves the vendor's environment. Ask for zero-data-retention terms with every model provider, a written commitment that no customer data is used to train models, and the list of providers by name.
Response and action. Any action the agent takes (a refund, an address change, a ticket update) is written back to your systems through an integration. Those writes should be attributable to the AI, timestamped and reversible.
Storage and logs. The conversation record, the retrieved context and the trace are stored for QA and audit. Encryption in transit and at rest, tenant isolation at the database layer, a documented retention period and a defined deletion process are the minimum. Storage region is usually configurable; in-region inference is typically an enterprise arrangement rather than a default.
For PHI, the same six points apply with a stricter standard: under HIPAA's minimum-necessary principle the agent should only access the health information the request requires, and every access should be logged. The PII redaction guide goes deeper on detection patterns and configuration.
What GDPR-compliant AI customer support requires
GDPR treats the AI vendor as a processor acting on your instructions, which means the compliance burden is shared but the accountability is yours. The practical requirements are:
A lawful basis and a stated purpose. Customer support is a well-established purpose; using the same conversations to train a model is a different purpose and needs its own basis. Prohibiting training closes that gap.
A processor contract. The DPA has to bind the vendor to your instructions, list sub-processors, commit to notifying you of changes, and set out deletion or return of data at termination.
Data subject rights that reach into the AI system. If a customer requests access or erasure, the vendor's conversation logs, traces and any cached context are in scope. Ask how the vendor executes those requests and how quickly.
Transfer safeguards. Where data leaves the EU, you need a valid transfer mechanism and a clear picture of which sub-processors are outside the region. EU storage removes a large part of this question for data at rest.
Breach notification. The vendor's notification timeline must leave you enough room to meet your own obligations to the supervisory authority.
Transparency. Customers should be told they are interacting with an automated system and how to reach a person, which also meets the EU AI Act's expectation.
Control 2: Deterministic guardrails at runtime
A system prompt is an instruction. A guardrail is a control. The distinction matters to an auditor because instructions can be overridden by a determined customer or a confusing context, while a guardrail is evaluated independently of the model's generated text and wins when the two disagree. When a vendor says the agent is instructed to avoid financial advice, ask what happens if it gives some anyway. If the answer is "it should not," you do not have a control.
Runtime guardrails for regulated support fall into five groups.
Topic boundaries. Subjects the agent will not engage with at all, such as investment recommendations, medical diagnosis, legal interpretation of terms, or anything about another customer's account.
Action gates. Conditions that must be true before an action executes: identity verified through the defined method, the request within policy limits, the account not flagged. If a gate fails, the action does not happen and the conversation is routed.
Disclosure rules. Statements the agent must make at defined moments: that it is an AI, that a human is available, that a response is general information rather than advice.
Escalation triggers. Signals that end the AI's involvement and bring in a person: expressions of distress, mentions of hardship or vulnerability, complaint language, legal threats, requests that fall outside the trained scope, or repeated failed verification.
Output checks. Validation of the generated response before it is sent: no promised outcomes the workflow cannot guarantee, no rates or figures that did not come from a system of record, no PII that the redaction step removed.
Two design rules make guardrails auditable. First, log every guardrail firing as its own event with the rule, the trigger and the outcome, so you can report how often each fires and review false positives. Second, run the high-risk paths from your intent classification as structured workflows with explicit steps and branches, so a dispute or KYC review follows the same sequence every time and can be diagrammed for the auditor. Natural-language workflows suit lower-risk intents where flexibility improves resolution; choose deliberately per intent. The guardrails page describes how these rules are configured and tested in Lorikeet.
Control 3: Pre-deployment testing with simulations
You cannot audit behavior you have never observed. Before an AI agent handles a live customer, you need documented evidence of how it behaves across the situations that matter, including the ones you hope never happen. Simulations are the mechanism: scripted or generated conversations run against the agent in a test environment, scored against acceptance criteria, and stored as evidence.
A useful simulation library has four sources.
Historical tickets. Real conversations from your helpdesk, with PII removed, replayed against the agent. This tests the common paths at realistic volume and language.
Policy edge cases. Scenarios written by your compliance and support leads for the boundaries of policy: a refund request one day past the window, a customer who cannot complete verification, a hardship disclosure in the middle of a billing question.
Adversarial attempts. Prompt injection, social engineering aimed at account takeover, requests for another person's information, attempts to extract system instructions. These test that guardrails hold under pressure rather than under cooperation.
Regression cases. Every past failure that reached a customer or a QA reviewer becomes a permanent test.
Write acceptance criteria before the run, covering accuracy, policy adherence, correct escalation and data handling, with the pass threshold set by the risk tier of the intent. High-risk intents need a clean pass on every escalation and data-handling case.
The part most teams miss is that testing is not a launch event. Every change to a workflow, a knowledge article, a guardrail or the underlying model is a change to the system's behavior, and the full library should be re-run before that change reaches production. Keep the results versioned alongside the change so the auditor can see, for any date, what was tested and what passed. The simulations page covers how batches are run and compared.
Control 4: 100% post-conversation QA and audit trail
Human QA programs sample, and the auditor knows it. AI-handled support makes it feasible to review every conversation, and once that is possible it becomes the expectation. This control has two halves: the review itself, and the record that makes the review and any later investigation possible.
What 100% QA reviews
Policy adherence. Did the agent follow the workflow for this intent and stay inside the topic boundaries.
Accuracy. Were the facts stated consistent with the system of record and the knowledge base.
Escalation correctness. Was a handoff required, and if so did it happen at the right point.
Data handling. Was any unnecessary PII or PHI accessed or disclosed.
Customer outcome. Was the issue resolved, and was the customer treated in line with your fairness standards.
Scores need to be actionable. A three-level scale (good, warning, critical) is enough: warnings feed a weekly pattern review, criticals go to a human within a defined window. Apply the same scoring to human and AI agents so the auditor sees one quality standard rather than two. The quality assurance page shows how scoring and review queues are organized.
What the audit trail must contain
For every conversation, the trail should let a reviewer reconstruct the interaction without asking an engineer. The minimum set is:
The customer's inputs on every channel, with redaction applied and the redaction events recorded.
The context retrieved from each connected system, and which fields were read.
Each tool or integration call, with parameters and results.
Every guardrail evaluated, whether it fired, and what it did.
The workflow version, knowledge version and model version in effect at the time.
The generated response and any output-check changes.
The handoff, if any, including the reason and the receiving agent.
The QA score and any reviewer notes.
Retention should match your longest record-keeping obligation rather than the vendor's default. Then run a quarterly drill: pick a conversation at random and time how long it takes to produce the full record. Hours is the standard. Weeks means the trail exists on paper only.
Does the vendor sign a BAA and a DPA?
Certifications describe the vendor's environment. Contracts make the vendor's obligations enforceable. Two documents matter most.
The Business Associate Agreement
If the AI agent will see protected health information, the vendor is a business associate under HIPAA and must sign a BAA before any PHI flows. A vendor that will not sign one is out of scope for healthtech support, whatever else it offers. When you review the BAA, check that it covers:
Permitted uses and disclosures limited to providing the service, with model training explicitly excluded.
Flow-down to sub-processors, including the model providers, so that the same obligations bind everyone who sees PHI.
Safeguards consistent with the minimum-necessary principle and with the security controls described in the vendor's attestations.
Breach notification timelines that leave you room to meet your own.
Return or destruction of PHI at termination.
The Data Processing Agreement
The DPA is the equivalent instrument for personal data generally, and it is required for GDPR whether or not health data is involved. Review it for processing on documented instructions only, a current sub-processor list with a change-notification commitment, a valid mechanism for international transfers, assistance with data subject requests, audit rights, and deletion at the end of the contract.
Where these documents sit commercially
Many vendors gate the BAA and DPA behind higher pricing tiers or custom enterprise contracts. That is a legitimate choice, and it should be visible on the public pricing page rather than discovered during procurement. Ask early which plan includes a standard-form DPA and BAA, whether custom terms are available and at what tier, and whether the vendor publishes a trust center. Lorikeet's pricing page and trust page answer all three.
A compliance checklist for evaluating AI support vendors
Use the table below as the evidence request for any vendor evaluation. A vendor that can supply every artifact within a week is ready for a regulated deployment. A vendor that offers a call instead of a document for more than two or three rows is not.
Requirement | Why it matters | Evidence to ask for |
|---|---|---|
Independent security attestations (SOC 2 Type 2, ISO 27001) | Shows controls operated over a period, verified by a third party, and that an information security management system exists | Current SOC 2 Type 2 report under NDA, ISO 27001 certificate with scope statement and expiry date |
HIPAA Business Associate Agreement | Without it, PHI cannot lawfully flow to the vendor | Standard-form BAA, the plan tier it is included in, and confirmation of flow-down to model providers |
GDPR Data Processing Agreement and sub-processor list | Binds the vendor as a processor and gives you visibility of every party handling personal data | DPA, published sub-processor list, change-notification commitment, transfer mechanism |
No training on customer data and zero-data-retention with model providers | Prevents a secondary purpose you have no lawful basis for and limits how long third parties hold your data | Contract clause prohibiting training, written zero-data-retention terms with each model provider |
PII redaction and PHI minimum-necessary access | Reduces what reaches the model and what a breach could expose | Redaction demonstration, configuration documentation, access-scope rules per workflow |
Encryption and tenant isolation | Protects data in transit and at rest and prevents cross-customer access | Architecture summary naming protocols and ciphers, description of database-level isolation |
Data residency options | Determines which jurisdiction your data sits in and whether transfer rules apply | List of available storage regions, and a clear statement of whether inference is in-region and at what tier |
Vendor staff access controls | Insider access is the most common route to a reportable incident | SSO and MFA policy for staff, access-review cadence, production-access logging |
Independent penetration testing | Validates the controls against an adversary rather than a checklist | Most recent third-party pen test summary and remediation status |
Runtime guardrails and escalation | The technical control that enforces your policy during live conversations | Guardrail configuration for a sample intent, escalation rule set, guardrail-firing logs |
Pre-deployment simulation testing | Proves behavior was observed before customers were exposed to it | Simulation library structure, a batch result with pass criteria, evidence of re-runs on change |
100% conversation QA and complete audit trail | Shows the system is monitored in production and any conversation can be reconstructed on demand | QA scoring rubric, review coverage figure, one full conversation trace exported for a sample ticket |
The final row separates a compliant environment from a compliant AI agent: if the vendor cannot export a complete trace for one conversation during the evaluation, assume it cannot do so during an investigation either.
How Lorikeet implements the four controls
Lorikeet is an AI customer support platform whose concierge resolves tickets end to end across chat, email, voice and SMS, built for financial services, healthtech and other regulated categories. Below is how the platform maps onto the four controls and the contractual requirements above, drawn from the public trust center and product pages.
Attestations and contracts
Lorikeet (legal entity Operator Technologies AI Pty Ltd) holds SOC 2 Type 2 and ISO 27001:2022, is HIPAA compliant and signs BAAs, and holds an independent GDPR attestation. Controls are monitored continuously through Vanta and refreshed annually. Reports are available under NDA through the public trust center at trust.lorikeetcx.ai, which also lists sub-processors: Google Cloud, OpenAI, Anthropic, Baseten and others. The Start and Scale plans both include a standard-form DPA with a HIPAA BAA. Signature plans add a custom Data Processing Agreement or Business Associate Agreement and custom data residency. The Start plan is $2,100 per month, billed annually. There are no per-seat charges on any plan. Details are on the pricing page.
Control 1: Data handling
Lorikeet runs on Google Cloud in a private VPC, with US West as the primary region and AU and EU storage available. Data is encrypted with TLS 1.3 in transit and AES-256 at rest, and tenant isolation is enforced with Postgres row-level security. Staff access uses Google SSO with hardware-key MFA. Lorikeet never trains on customer data and holds zero-data-retention agreements with all model vendors. PII is automatically redacted and PHI access follows the minimum-necessary principle. Card data is tokenized; Lorikeet does not store card numbers, so PCI scope stays with your payment processor. Third-party penetration testing is carried out and summarized in the trust center. In-region inference is available as an Enterprise arrangement rather than a default.
Control 2: Runtime guardrails
Lorikeet supports natural-language workflows for flexible intents and deterministic structured workflows for paths that need to run the same way every time. Runtime guardrails escalate sensitive or off-policy moments to humans, which is how the action gates, disclosure rules and escalation triggers described above are implemented. Configuration is described on the guardrails page.
Control 3: Simulations
Pre-deployment simulations let teams run scenario batches against the agent before launch and before changes, with results that can be compared across runs. The simulations page covers the workflow.
Control 4: 100% QA and audit trail
Coach reviews 100% of conversations, whether handled by a human or by the AI, and assigns a Ticket Quality Score of Good, Warning or Critical. This sits within four layers of quality control, and it is backed commercially by the Quality Guarantee, which refunds the AI portion of any badly scored interaction. Integrations with Zendesk, Intercom, HubSpot, Front and Salesforce keep the conversation record and the actions taken visible in the systems your team already audits. See the quality assurance page.
What this looks like in regulated deployments
Summ, a tax platform, saw 97% faster resolutions during tax time. Flex, a rent-payment platform, reported 2x CSAT, 4x rent-week volume and a 50% shorter median resolution; Lindsay Boland, CX AI Product Lead at Flex, said: "We tested AI solutions head-to-head and Lorikeet was a winner in every metric." Breeze had 40% of complex volume resolved independently within 30 days, with workflows covering KYC reviews and transaction status questions, the high-risk paths this guide recommends keeping deterministic. If you want to walk through the controls against your own regulatory requirements, book a demo and bring your security questionnaire.
