This article is educational and reflects publicly available regulatory text as of May 2026. It is not legal advice. Specific situations require qualified counsel.

The premise most organizations get wrong

Across mid-market healthcare, financial services, insurance, legal, and education organizations, a pattern recurs: an analyst, associate, or clinician opens a browser, pastes a customer record (or a clinical note, or a deal-room document, or an IEP draft, or a privileged communication) into ChatGPT, Claude, or Gemini, and asks for a summary, a draft, or an analysis. The output comes back in seconds. The work that would have taken an hour is done in two minutes. The next day, the same person does it again.

Internally, this is treated as a productivity story. Externally — in the regulatory frameworks that govern these industries — this same action is, in most cases, a compliance violation. Not a gray area. Not an emerging risk. A violation of statutes and rules that already exist, have already been enforced, and carry already-defined penalties.

Most organizations do not understand the scope of the problem because the violations are invisible at the moment they happen. There is no alarm. There is no error message. The browser does not refuse the paste. The provider does not return "compliance violation detected." The work simply gets done, faster than before, and the regulatory exposure accumulates in silence.

This article walks through the specific frameworks involved, what they actually require, what "sending data to a provider" actually means under each, and what the compliant path forward looks like. The goal is not to discourage AI adoption. The goal is to make the boundary visible.

What "sending data to a provider" actually means

The first source of confusion is technical. When an employee pastes a document into ChatGPT, Claude, or Gemini and clicks send, several things happen:

  1. The data leaves the organization’s network over an encrypted TLS connection to the provider’s servers.
  2. The data is received and processed by the provider’s infrastructure. The provider’s systems read the raw content, tokenize it, and feed it to the model.
  3. The data may be retained for varying periods depending on the provider’s terms of service, the account tier in use, and any opt-outs configured. Default retention windows commonly range from zero to thirty days for consumer-tier accounts.
  4. The data may be used to improve the provider’s services — including, on certain tiers, contributing to future model training — absent an explicit opt-out or a contractual prohibition.
  5. The data is, at the moment of transmission, outside the legal and operational control of the originating organization.

This is the action that most regulatory frameworks were not designed to anticipate, but that most of them clearly govern once the analysis is applied. Encryption in transit (the TLS layer) does not change the regulatory analysis. The provider can read the content. That capability is the trigger.

HIPAA: the healthcare framework most clearly violated

Under HIPAA, any organization classified as a Covered Entity (most healthcare providers, health plans, and clearinghouses) or a Business Associate is prohibited from disclosing Protected Health Information (PHI) to third parties unless one of several conditions is satisfied. The relevant standards are codified at 45 CFR §§ 164.502, 164.504, and 164.514.

PHI includes any information that:

  • Identifies an individual (or could reasonably be used to identify them), and
  • Relates to the individual’s past, present, or future physical or mental health, healthcare provision, or healthcare payment.

The HIPAA Safe Harbor de-identification standard (164.514(b)(2)) lists eighteen specific identifiers that, if removed, render the data not-PHI: names, geographic subdivisions smaller than state, dates more granular than year, telephone numbers, fax numbers, email addresses, SSNs, medical record numbers, health plan beneficiary numbers, account numbers, certificate numbers, vehicle identifiers, device identifiers, URLs, IP addresses, biometric identifiers, full-face photos, and "any other unique identifying number, characteristic, or code."

When an employee pastes a clinical note, a discharge summary, a referral letter, or a prior-authorization request into a third-party AI tool, the document almost always contains several of these identifiers. The action is a disclosure of PHI to a third party. To be permitted, that disclosure requires one of:

  • The third party is a Business Associate with a signed Business Associate Agreement (BAA) under 45 CFR 164.504(e);
  • The data has been de-identified to the Safe Harbor or Expert Determination standard before transmission;
  • The patient has provided written authorization under 164.508; or
  • An exception applies (e.g., public-health reporting under 164.512).

The standard consumer tiers of ChatGPT, Claude, and Gemini do not satisfy any of these conditions. The data was identifiable. The provider is not under BAA. The patient did not authorize. No exception applies. The disclosure is, on the plain reading of the rule, prohibited.

Penalties under HITECH’s tiered structure (45 USC 1320d-5) range from $137 per violation for unknowing violations to $2.13 million per identical violation per year for willful neglect that is not corrected. Each PHI record disclosed is a separate violation.

Some providers offer BAA-eligible enterprise tiers (Anthropic for Claude Enterprise, Microsoft Azure for OpenAI’s GPT under specific HIPAA-eligible services, Google for Vertex AI under specific configurations). Eligibility for a BAA is not the same as having a signed BAA. A signed BAA, on the correct service tier, with the correct configuration, is the load-bearing requirement.

SEC Reg S-P and SEC Rule 17a-4: the financial-services framework

For broker-dealers, registered investment advisers, and other SEC- or FINRA-regulated entities, two frameworks come into play when sensitive client data or material non-public information is transmitted to a third-party AI provider.

SEC Regulation S-P (17 CFR § 248) requires covered financial institutions to adopt written policies and procedures reasonably designed to safeguard customer records and information. Transmission of customer records to a third-party provider without contractual safeguards covering the provider’s handling and retention is generally inconsistent with this safeguarding obligation. The November 2024 amendments to Reg S-P added explicit incident-response and customer-notification requirements that further raise the bar.

FINRA Rule 17a-4 (and the parallel SEC Rule 17a-4) require broker-dealers to preserve specified books and records in non-rewriteable, non-erasable format (or in an "electronic records system" satisfying the audit-trail-alternative requirements added in 2022 under SEC Release No. 34-96034). When an analyst pastes draft research, trading rationale, or client communications into a third-party AI tool and an output is generated, the question becomes: is that interaction a record that must be preserved under 17a-4? If yes, the obligation extends not just to the firm’s record but to the provider’s handling of any retained content.

Beyond the records framework, material non-public information (MNPI) triggers additional concerns. The transmission of MNPI to a party outside the wall — including an AI provider not under appropriate confidentiality terms — potentially constitutes a tipping event under federal securities law, exposes the firm to insider-trading liability if the provider’s systems are subsequently compromised, and breaks the firm’s information-barrier regime.

Enforcement in this area is active. The SEC’s Division of Examinations announced AI-related governance and risk practices as a 2025 examination priority, with a particular focus on disclosure accuracy and adviser representations about AI use.

ABA Model Rules: the legal-profession framework

Lawyers operating under the American Bar Association Model Rules of Professional Conduct (adopted in some form by every US jurisdiction) face several rules directly implicated by AI use on client matters:

Model Rule 1.1 (Competence) requires lawyers to understand the benefits and risks of technology they use. ABA Formal Opinion 512 (July 2024) explicitly addressed generative AI, noting that competent use requires understanding the tool’s confidentiality posture and risks of data exposure.

Model Rule 1.6 (Confidentiality) prohibits revealing information relating to representation of a client absent informed consent or another permitted exception. Transmitting client-confidential information — which includes more than just attorney-client privileged content — to a third-party AI provider whose terms permit retention or training-use without explicit client consent is, on a straightforward reading, a Rule 1.6 issue.

Model Rule 5.3 (Responsibilities Regarding Non-Lawyer Assistance) extends to AI services used by the lawyer or firm. The lawyer must make reasonable efforts to ensure the non-lawyer’s conduct is compatible with the lawyer’s professional obligations.

The privilege analysis adds a further layer. Voluntary disclosure of privileged communications to a third party generally constitutes a waiver of the privilege. Post-Heppner enterprise discipline in major firms — after United States v. Heppner (S.D.N.Y. 2026) held that querying a consumer AI chatbot can waive attorney-client privilege — has been to treat AI tools without appropriate confidentiality terms as third parties for this purpose. The privileged communications, mental impressions, and work product that travel into the provider’s context window become potentially discoverable.

GDPR Article 32: the European framework that reaches US operators

Any US-based organization processing personal data of individuals in the EU or UK falls under GDPR’s extraterritorial reach. Article 32 (Security of Processing) requires the data controller to implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk — including, where appropriate, encryption and pseudonymization.

Sending personal data of EU residents to a US-based AI provider triggers additional Schrems II analysis. The 2020 Schrems II decision invalidated the EU-US Privacy Shield and requires data controllers transferring personal data to the US to assess whether US surveillance law provides essentially equivalent protections to EU law — and to implement supplementary measures where it does not. Without Standard Contractual Clauses (SCCs), a Data Processing Agreement covering the AI processing, and supplementary measures sufficient to satisfy the Schrems II analysis, the transfer is potentially unlawful.

The penalty regime is well known: up to €20 million or 4% of global annual turnover, whichever is greater, for the most serious violations.

FERPA and the FTC COPPA Rule update: the education framework

Educational institutions receiving federal funding are subject to the Family Educational Rights and Privacy Act (FERPA), codified at 20 USC § 1232g. FERPA generally prohibits the disclosure of personally identifiable information from education records to third parties without parental consent (or student consent, if the student is 18 or older).

The "school official" exception (34 CFR § 99.31(a)(1)) permits disclosure to a contracted third party performing a service the school would otherwise provide, provided the third party is under direct control of the school with respect to the use and maintenance of the information and is subject to FERPA’s re-disclosure requirements. A consumer-tier AI provider that retains data per its standard terms is generally not under direct school control in the manner this exception requires.

For students under 13, the FTC’s updated Children’s Online Privacy Protection (COPPA) Rule — finalized in early 2025 with effective dates per Federal Register publication — introduced new dimensions to the consent analysis: separate verifiable parental consent for AI training use, separate consent for targeted advertising, separate consent for third-party disclosure, and stricter data-retention limits. The update specifically addressed AI processing of children’s personal information as a category requiring distinct consent treatment.

An IEP draft, an accommodation discussion, a behavioral incident report, or a parent communication that includes student-identifiable information transmitted to a consumer-tier AI provider falls outside the FERPA school-official exception, falls outside any COPPA consent the parents have likely provided, and creates compliance exposure that may not surface until a state Department of Education audit or a parent complaint.

NAIC AI Model Bulletin: the insurance framework

For insurance carriers, the NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers (adopted December 2023, with state-by-state implementation 2024 onward) establishes governance expectations for AI use across underwriting, claims handling, fraud detection, and customer service.

The bulletin emphasizes accountability, transparency, and consumer fairness. Carriers are expected to maintain documentation of AI system design, training data, validation processes, and ongoing monitoring — documentation that becomes difficult to maintain when the AI processing happens inside a third-party provider whose internal operations are opaque to the carrier.

State Departments of Insurance have begun including AI governance in market-conduct examinations. Several states (Colorado, Connecticut, New York) have enacted AI-specific insurance regulations layered on top of the NAIC framework, each adding their own documentation and reporting requirements.

Claimant identifiers, claim narratives, medical records associated with claims, and adjuster mental impressions all fall within scope. When any of these are transmitted to a third-party AI tool without appropriate contractual structures and audit-trail preservation, the carrier’s compliance posture under the NAIC bulletin and state-specific implementations is undermined.

EU AI Act: the framework reaching every operator with EU exposure

The EU AI Act entered into force August 1, 2024, with phased application dates extending through 2027. The Article 50 transparency obligations take effect August 2, 2026, covering general-purpose AI obligations, disclosure to natural persons interacting with AI systems, and deepfake labeling. The high-risk-system obligations (Annex III) take effect on the later phases, with full enforcement of the documentation, risk-management, and human-oversight requirements.

For US operators serving EU customers or processing EU personal data through AI systems, the Act’s extraterritorial reach is direct. Article 9 requires risk management throughout the AI system lifecycle. Article 10 governs data and data-governance practices, including training-data quality. Article 12 mandates record-keeping. Article 13 requires transparency to deployers. Article 14 requires effective human oversight. Article 15 addresses accuracy, robustness, and cybersecurity.

Where US-based AI providers fall within scope of these requirements, the operator deploying the AI takes on overlapping obligations. Transmitting EU-resident personal data through a US provider without the contractual, documentary, and operational structures the EU AI Act anticipates is, again, not an emerging risk but a near-term compliance exposure with a defined penalty regime (up to €35 million or 7% of global annual turnover for prohibited-practice violations).

The honest summary

Across these frameworks, the same pattern emerges. The statutes and rules predate the modern generative-AI era, but the legal analysis applies cleanly to the activity that happens when a regulated organization’s employee transmits sensitive data to a third-party AI provider.

  • For healthcare data: HIPAA generally requires a BAA, de-identification, or patient authorization. None of these are satisfied by default consumer-tier AI provider use.
  • For financial-services data: Reg S-P safeguarding and 17a-4 books-and-records obligations require contractual and operational controls that consumer-tier AI use does not provide.
  • For client-confidential and privileged content: ABA Rule 1.6 confidentiality, Rule 5.3 non-lawyer assistance supervision, and the voluntary-disclosure waiver analysis all create exposure.
  • For EU/UK personal data: GDPR Article 32 security-of-processing and Schrems II transfer-impact analysis apply.
  • For student data: FERPA disclosure rules and the FTC COPPA Rule update apply.
  • For insurance data: NAIC governance expectations and state-specific implementations apply.
  • For any operator with EU exposure: the EU AI Act’s phased obligations apply.

The cumulative analysis is straightforward. Sending sensitive data to a consumer-tier or improperly-contracted AI provider is, in most regulated mid-market contexts, a compliance violation. The violation is real even when the data is encrypted in transit, even when the provider has a good privacy policy, even when the employee acted in good faith, even when no harm results.

The frameworks do not ask whether the action felt safe. They ask whether the boundary was respected.

The path forward

The honest path forward is not "stop using AI." The honest path forward is to architect the use so that the boundary is respected by structure, not by hope. Three components are non-negotiable:

First, the data boundary must be enforced before transmission. The sensitive entities — patient identifiers, MNPI, claimant records, privileged content, student PII — must be transformed or removed before the request leaves the organization’s controlled environment. Encryption in transit does not satisfy the legal analysis. The provider must not receive the raw entities.

Second, the evidence trail must be cryptographically verifiable, not narrated. Compliance officers and external auditors should be able to verify, against signed receipts, that the boundary held for each request. Self-attested logs from the AI execution layer are not sufficient. The auditor needs to verify without trusting the platform.

Third, the architecture must be provider-agnostic. When the AI provider landscape shifts — new entrants, new pricing, new geopolitical posture — the workflow must survive the switch without losing the compliance posture. Workflows written against a single provider’s SDK become compliance liabilities the day the provider changes terms.

These three components are what VeilEngine is built around. Boundary protection before transmission, recorded in a signed receipt. Receipt-based evidence verifiable offline. Provider abstraction across Claude, GPT, Gemini, and on-premise models. The architecture treats the compliance frameworks as load-bearing constraints, not as a finishing layer.

For organizations whose compliance officers have correctly blocked the AI workflows their operations and revenue teams want to run, this is the structural resolution. The workflows can run. The boundary holds. The audit trail exists. The provider remains interchangeable.

For organizations whose compliance officers have not yet noticed the AI workflows quietly happening across their employee population, this article is the early warning. The compliance exposure is real. The frameworks are not waiting for AI-specific updates — they apply now, in their current form, to the activity already happening.

The frameworks do not ask whether the action felt safe. They ask whether the boundary was respected.

If your organization has questions specific to its situation

Every situation is specific. The frameworks summarized above interact differently depending on the industry, the data classification, the contractual structures already in place, the geographic scope of operations, and the specific AI use cases under consideration.

The Vertical Edge AI engagement model begins with a discovery conversation focused on the specific workflows currently blocked, the compliance posture that needs to be satisfied, and the practical path to running the workflows compliantly. The conversation produces a structured assessment of fit, scope, and the controls required.

Request a consultation→ Read about VeilEngine

Educational content reflecting publicly available regulatory text as of May 2026. Frameworks evolve and enforcement positions shift; readers should consult qualified counsel before acting on specific compliance questions. The analysis represents Vertical Edge AI’s reading of the applicable rules and is not a substitute for engagement-specific legal advice.