A vendor security page that says "SOC 2 compliant" tells you almost nothing. The report behind it, the scope it covers, and whether they will sign a BAA tell you everything. Most procurement failures in regulated AI support trace back to confusing the badge for the evidence.
SOC 2 and HIPAA are the two compliance frameworks most likely to gate an AI customer support purchase at a fintech, healthtech, or any company touching sensitive personal data. SOC 2 is an audited attestation about how a vendor handles security and availability. HIPAA is a US law that governs protected health information and requires a signed Business Associate Agreement before a vendor can lawfully process it. Neither is a checkbox. Both are evidence trails you have to read, and an AI support vendor that resolves tickets end-to-end touches more of your sensitive data, in more places, than a passive chatbot ever did.
"SOC 2 compliant" is not a credential. The artifact that matters is a current SOC 2 Type II report, with a scope and date you have actually checked.
HIPAA has no certification. A vendor is HIPAA-ready if it will sign a Business Associate Agreement (BAA) and can describe how it limits use and disclosure of protected health information.
An AI agent that takes actions (lookups, updates, refunds, dispute filing) reads and writes more sensitive data than a deflection bot, so data isolation, sub-processor disclosure, and no-train terms matter more, not less.
The single highest-leverage question for an LLM-based vendor: do your model providers train on our data, and is that contractually prohibited in writing?
Compliance features support your obligations. They do not transfer them. You remain the accountable party to your regulator regardless of what a vendor's badge says.
Last updated: June 2026
This guide is buyer-education, not a sales pitch. It explains what SOC 2 Type II and HIPAA actually mean for an AI customer support vendor, what documents and contract terms to request, the red flags that should slow a deal down, and where Lorikeet sits honestly against each requirement. If you are a compliance lead being asked to approve an AI agent that will read account data, health records, or payment information and act on it, this is the checklist that should sit in front of the demo.
What SOC 2 Type II Actually Means
SOC 2 is a reporting framework from the American Institute of Certified Public Accountants (AICPA). An independent auditor evaluates a vendor against the Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. Security is mandatory; the other four are included only if the vendor chose to scope them in. The output is a report, not a certificate. There is no "SOC 2 certified" status, and any vendor that uses that phrase is describing something that does not exist.
The distinction that matters most is Type I versus Type II. A Type I report describes whether controls are designed appropriately at a single point in time. A Type II report tests whether those controls actually operated effectively over a period, usually six or twelve months. Type I tells you the vendor wrote down good intentions on one day. Type II tells you they did the thing, repeatedly, for months, and an auditor checked. For an AI support vendor processing your customers' data continuously, Type II is the floor. Type I is a starting point a young company is allowed to be at, but you should know which one you are looking at.
SOC 2 Type II: An independent auditor's report attesting that a vendor's security controls operated effectively over a defined period (typically 6 to 12 months), evaluated against the AICPA Trust Services Criteria. It is an attestation, not a certification.
Trust Services Criteria: The five categories a SOC 2 audit can cover: security (always), availability, processing integrity, confidentiality, and privacy. The scope tells you which ones the vendor chose to be tested against.
What to verify on SOC 2
Ask for the report, not the logo. Vendors share SOC 2 Type II reports under NDA. If a vendor will only send you a one-page summary or a badge from a compliance-automation tool, you have not seen the evidence. The full report includes the auditor's opinion, the control list, the test results, and any exceptions.
Check the report date and period. A SOC 2 Type II report covers a specific window. If the period ended more than a year ago, ask for the current one or a bridge letter covering the gap. Compliance posture drifts; a 2024 report is not evidence about 2026 operations.
Read the scope. A report scoped only to security is normal and fine. But if your use case depends on confidentiality or privacy controls, confirm those criteria were in scope. The scope section also names which systems and products the audit covered. A SOC 2 covering the marketing website is not a SOC 2 covering the AI platform.
Read the exceptions. Almost every Type II report contains some exceptions or deviations. Their presence is normal. What matters is severity and the vendor's documented remediation. A report with zero exceptions is either a very mature program or a very narrow scope; either way, ask why.
Confirm sub-service organizations. Most SOC 2 reports are "carve-out", meaning they exclude the vendor's own cloud and infrastructure providers and rely on those providers' separate reports. Check which sub-service organizations are carved out and that they hold their own attestations.
What HIPAA and a BAA Actually Mean
HIPAA is the US Health Insurance Portability and Accountability Act. If your company is a covered entity (a health plan, clearinghouse, or healthcare provider) or you handle protected health information (PHI) on behalf of one, HIPAA governs how that data can be used and disclosed. There is no such thing as "HIPAA certified". No government body and no auditor issues a HIPAA certificate. A vendor that claims to be "HIPAA certified" is, at best, using shorthand for something else and, at worst, does not understand the law they are asking you to trust them with.
The mechanism that actually makes a vendor usable for PHI is the Business Associate Agreement. A BAA is a contract in which the vendor (the business associate) agrees to the obligations HIPAA places on anyone processing PHI for a covered entity: limit use and disclosure to what the contract permits, apply safeguards, report breaches, and flow the same obligations down to its own subcontractors. Without a signed BAA, you cannot lawfully send PHI to the vendor, no matter how good their security is. With one, the vendor is contractually on the hook for the HIPAA obligations that apply to the data you share.
Business Associate Agreement (BAA): A contract required by HIPAA between a covered entity (or another business associate) and a vendor that processes protected health information on its behalf. It binds the vendor to HIPAA's use, disclosure, safeguard, and breach-notification requirements.
Protected Health Information (PHI): Individually identifiable health information held or transmitted by a covered entity or business associate, in any form. For an AI support agent, this can appear in ticket text, transcripts, account records, and the data the agent reads from connected systems.
What to verify on HIPAA
Will they sign a BAA, and at what plan tier? Some vendors only offer a BAA on enterprise contracts, or charge extra. Confirm the BAA is available for your deal, in writing, before you scope PHI workflows.
Read the BAA terms, not just the fact one exists. A BAA should specify permitted uses, breach-notification timelines, the vendor's safeguards, and subcontractor flow-down. Some vendor BAAs quietly broaden permitted uses (for example, "to improve our services") in ways that conflict with how you want PHI handled.
Check sub-processor coverage for PHI. An AI support vendor relies on model providers and infrastructure. The BAA, or the vendor's representations, must confirm those downstream parties are themselves covered by BAAs where PHI flows to them. If the vendor sends PHI to an LLM provider that will not sign a BAA, the chain is broken.
Ask how PHI is minimized and redacted. The strongest posture is not sending PHI to a model at all when it is not needed. Ask whether the vendor can redact PII and PHI before it reaches the model and whether you control that configuration.
Why AI Customer Support Raises the Stakes
A traditional support chatbot reads a knowledge base and returns text. Its exposure to your sensitive data is shallow. An agentic AI support platform is different in kind. To resolve a ticket end-to-end, it reads the customer record, calls into your systems (CRM, payments, core banking, health records), takes actions, and produces a log of everything it did. That means it touches more PII and PHI, in more systems, on every ticket. The same capability that makes it useful is what makes the compliance review heavier.
Three properties of AI support specifically deserve scrutiny that a static tool never required.
Data isolation between tenants
Multi-tenant AI platforms serve many customers from shared infrastructure. The question is how strictly your data, your prompts, your knowledge base, and your transcripts are isolated from every other tenant. Ask whether your configuration and data run in a logically or physically separated instance, how access is scoped internally, and whether any of your content can influence another customer's agent. "We use row-level security" is an answer; "trust us, it's separated" is not.
Sub-processors and the model layer
Every AI support vendor depends on a chain of sub-processors: cloud hosting, and critically, the large language model providers (OpenAI, Anthropic, Google, and others) that power the agent. Each link is a place your data travels. You are entitled to a current sub-processor list, notification when it changes, and confirmation that data-handling and no-train terms flow down to the model layer. A vendor that cannot tell you which model providers see your data is a vendor that cannot tell you where your data is.
No-train terms
This is the question most specific to AI and most often skipped. Will the vendor, or its model providers, train on your data? For regulated buyers the answer needs to be a contractual no, in writing, that flows down to the LLM providers. The major model providers offer enterprise terms that contractually exclude API data from training, but it is the support vendor's responsibility to have those terms in place and to represent them to you. Ask to see the clause. "We don't train on your data" in a sales call is not the same as a no-train term in the contract and a back-to-back agreement with the model provider.
The Red Flags
None of these are automatically disqualifying. Each is a signal that the conversation needs to go deeper before your compliance team signs.
"SOC 2 certified" or "HIPAA certified." Neither term is real. It usually means marketing wrote the security page and nobody in compliance reviewed it. Ask for the actual report and BAA.
A badge but no report under NDA. If the vendor will show you a logo but not the SOC 2 Type II report, you have not seen evidence of anything.
A Type I report presented as if it were Type II. Type I is a point-in-time design review. If the vendor is vague about which they have, assume Type I until the report says otherwise.
An expired or stale report and no bridge letter. A report period that ended over a year ago, with no current report or gap coverage, means you are evaluating last year's controls.
"We don't train on your data" with nothing in the contract. Verbal assurance is not a no-train term. Get it in writing, flowed down to the model providers.
No sub-processor list, or refusal to name the model providers. If they will not tell you which LLMs process your data, they cannot account for where your data goes.
A BAA only on the top plan, framed as an upsell. HIPAA obligations do not scale with your contract size. If PHI is in scope, the BAA needs to be available for your deal.
Compliance language that promises outcomes. A vendor that says its product will "ensure compliance" or "make you HIPAA compliant" misunderstands the relationship. The vendor supports your obligations; it cannot assume them.
How Lorikeet Meets These Requirements
Lorikeet is an AI customer support platform built for complex and regulated companies, with roughly four in five customers being US financial institutions and fintechs, alongside healthtech, insurance, and gaming. Because the buyer is usually a regulated business whose compliance team is the toughest stakeholder in procurement, the security posture is built for that review rather than retrofitted for it. Here is where Lorikeet sits against each requirement above, honestly.
SOC 2. Lorikeet maintains SOC 2 and shares its report with prospects under NDA so your team can read the scope, period, and any exceptions rather than taking a badge on faith. Lorikeet has passed security reviews including those of major US banks, which are among the most demanding examinations a vendor faces.
HIPAA and BAA. Lorikeet is BAA-ready for healthcare and healthtech workflows. The framing is deliberate: Lorikeet signs a BAA and supports your HIPAA obligations for the PHI you share. It does not claim to make you HIPAA compliant, because no vendor can.
Data isolation. Lorikeet is built for instance isolation so that one customer's data, configuration, and knowledge are separated from another's, which is the property regulated buyers test hardest.
No-train terms. Lorikeet holds contractual no-train agreements with its model providers (OpenAI, Anthropic, Google), so your data is not used to train the underlying models. Lorikeet dynamically routes between these providers by task, and the no-train terms flow down across them.
Data handling. The platform supports PII redaction, role-based access control (RBAC), and data residency in the US, Australia, and the UK, and is GDPR-aligned for buyers with European data subjects.
Provable behavior. Beyond the paperwork, Lorikeet's defence-in-depth model (pre-launch adversarial simulations, inbound message checks, outbound guardrails, and 100% post-facto QA through its Coach agent) gives compliance teams a way to test what the agent will do before go-live, with audit trails after. Controls on paper and behavior in production are different things; Lorikeet is built so you can check both.
An honest limitation. Lorikeet is not the right fit for every buyer. If you are a small team handling only low-sensitivity, generic support questions and you want a drop-in chatbot at the lowest possible per-ticket price, a lighter tool will serve you better and the depth of Lorikeet's compliance posture is overhead you do not need. Lorikeet earns its keep when the data is sensitive, the workflows are regulated, and your compliance team is the stakeholder who has to sign. Specific SOC 2 report dates, scope, and BAA terms are shared during procurement under NDA rather than published, so the verification still requires the conversation this guide is telling you to have.
A Verification Checklist
Bring this to the vendor evaluation. The goal is to replace assurances with artifacts.
Request the SOC 2 Type II report under NDA. Confirm it is Type II, not Type I.
Check the report period and that it is current, or get a bridge letter.
Read the scope: which Trust Services Criteria, and which product or system.
Read the exceptions and the documented remediation.
Confirm whether the vendor will sign a BAA, on your plan, before scoping PHI.
Read the BAA's permitted-use and breach-notification terms.
Get the current sub-processor list, including model providers.
Get the no-train term in writing, flowed down to the LLM layer.
Ask how tenant data is isolated and how internal access is scoped.
Ask whether PII and PHI can be redacted before reaching the model.
Confirm data residency matches your regulatory requirements.
Conclusion
SOC 2 and HIPAA are not badges to collect; they are evidence trails to read. For an AI customer support vendor, that evidence is heavier than it was for the chatbot generation, because an agent that resolves tickets end-to-end touches more of your sensitive data in more systems. The verification work is straightforward once you know to ask for artifacts instead of assurances: the actual SOC 2 Type II report with its scope and date, a signed BAA with terms you have read, a sub-processor list that names the model layer, and a contractual no-train term that flows down to it. A vendor's compliance posture supports your obligations. It never transfers them, and the moment a vendor's marketing implies otherwise is the moment to slow down and read the report.
