Your AI Vendor Can Read Every Prompt You Send. That's a Compliance Violation.

Every time your organization sends a prompt to an AI vendor, you are transmitting plaintext data to infrastructure you do not own, do not audit, and do not control. The vendor's employees can access it. The vendor's logging infrastructure captures it. The vendor's training pipelines may ingest it. The vendor's subprocessors may store copies of it. This is not a hypothetical concern. It is the architectural reality of every major large language model API operating today.

If you are using OpenAI, Anthropic, Google, Cohere, Mistral, or any other hosted AI provider, your prompts leave your perimeter as plaintext HTTP payloads. They are decrypted at the vendor's edge. They are held in memory during inference. They are logged for abuse monitoring, safety filtering, and in many cases, model improvement. The TLS connection that protects your data in transit terminates at the vendor's load balancer. After that, your data is naked.

For most consumer applications, this is an acceptable tradeoff. For regulated enterprises, it is a compliance violation waiting to be discovered by an auditor, an attorney general, or a breach notification.

The Anatomy of an AI API Call

Understanding why this is a compliance problem requires understanding what happens when your application sends a request to an AI API. The sequence is straightforward and damning.

Your application constructs a JSON payload containing the prompt. That prompt often includes context: customer names, medical records, financial data, legal documents, internal strategy memos, source code, employee information. The payload is encrypted with TLS and sent to the vendor's endpoint. The vendor's load balancer terminates TLS. The plaintext payload is routed to an inference server. The model processes the plaintext input. The response is generated in plaintext. Both the input and output are logged. The response is encrypted with TLS and returned to your application.

At no point during inference does the vendor's system operate on encrypted data. The model cannot process ciphertext. It requires plaintext tokens to perform matrix multiplications, attention calculations, and activation functions. This is not a configuration problem. It is a mathematical constraint of how neural networks operate on standard infrastructure.

HIPAA: Sending PHI to an AI API Without a BAA Is a Violation

The Health Insurance Portability and Accountability Act requires that any entity handling protected health information sign a Business Associate Agreement with every subprocessor that accesses PHI. If your healthcare application sends patient data to an AI API, that vendor is a business associate. If there is no BAA in place, you are in violation of 45 CFR 164.502(e) and 164.504(e).

Some vendors now offer BAAs for enterprise customers. OpenAI offers one for ChatGPT Enterprise and the API. Anthropic offers one for certain tiers. But signing a BAA does not solve the underlying architectural problem. The BAA is a contractual control. It establishes legal liability. It does not change the fact that the vendor processes your PHI in plaintext.

When a vendor processes PHI in plaintext, every element of that vendor's infrastructure becomes a potential breach surface. Their logging systems. Their monitoring dashboards. Their inference servers. Their employee access controls. Their subprocessors' subprocessors. A breach at any point in that chain triggers your notification obligations under the HITECH Act. You are responsible for notifying affected individuals within 60 days. The OCR can impose penalties up to $2.07 million per violation category per calendar year.

The BAA shifts some liability to the vendor, but it does not eliminate your obligations as the covered entity or business associate. You chose to send PHI to a third party's plaintext processing pipeline. That decision is yours. The consequences are yours.

The BAA Does Not Encrypt Your Data

This point requires emphasis because it is consistently misunderstood. A BAA is a legal document. It obligates the vendor to implement safeguards, report breaches, and limit use of PHI. It does not encrypt your data during processing. It does not prevent vendor employees from accessing your data through legitimate internal tools. It does not prevent a nation-state actor who compromises the vendor's infrastructure from reading your PHI in plaintext.

A BAA is a promise. Encryption is mathematics. Compliance frameworks exist because promises are insufficient. But even the compliance frameworks have not yet caught up to the reality that AI inference requires plaintext processing at the vendor.

GDPR: Schrems II and the US AI Vendor Problem

The General Data Protection Regulation imposes strict requirements on the transfer of personal data outside the European Economic Area. The Schrems II decision invalidated the EU-US Privacy Shield in July 2020. While the EU-US Data Privacy Framework was adopted in July 2023, its long-term stability remains uncertain, and many data protection authorities continue to scrutinize US transfers.

When a European organization sends personal data to a US-based AI vendor, that transfer must rely on an approved mechanism: Standard Contractual Clauses, Binding Corporate Rules, or the Data Privacy Framework certification. But Schrems II established that the transfer mechanism must be accompanied by a supplementary measures assessment. The organization must evaluate whether US surveillance laws, particularly FISA Section 702 and Executive Order 12333, undermine the protections of the transfer mechanism.

US AI vendors are electronic communications service providers. They are subject to FISA 702 surveillance orders. The US government can compel them to produce data, including AI prompts and responses, without notifying the data subject. No amount of contractual language in a DPA overcomes a lawful US government surveillance order.

The EDPB's recommendations on supplementary measures explicitly identify encryption where the data controller holds the keys as an effective supplementary measure. But standard AI API usage does not meet this standard. The vendor holds the keys. The vendor decrypts the data. The vendor processes it in plaintext. The encryption that protects the data in transit is the vendor's encryption, not yours.

If you are a European organization sending personal data to a US AI vendor's plaintext processing pipeline, your Schrems II supplementary measures assessment should conclude that the transfer lacks adequate protection. If your assessment concludes otherwise, your DPO should explain how plaintext processing at a FISA 702-subject entity constitutes an effective supplementary measure.

SOC 2: Subprocessor Controls and Trust Services Criteria

SOC 2 Type II reports evaluate an organization's controls against the Trust Services Criteria. The Common Criteria require that the organization identify and manage risks from subprocessors and third-party service providers. CC9.2 specifically addresses risk from vendor and business partner relationships.

When your organization sends customer data to an AI vendor, that vendor is a subprocessor. Your SOC 2 obligations require that you evaluate the vendor's controls, establish contractual protections, and monitor the vendor's compliance. Most organizations using AI APIs have not updated their subprocessor inventories to include AI vendors. They have not conducted vendor risk assessments specific to AI inference. They have not established monitoring controls for data sent to AI endpoints.

Your SOC 2 auditor will eventually ask: "What customer data is sent to AI vendors?" If the answer is "we don't know" or "everything in the prompt," your CC9.2 controls are deficient. If the auditor further asks "what controls ensure that the AI vendor does not retain, log, or use customer data beyond the scope of the service?" and you point to the vendor's terms of service, that is not a control. That is a hope.

Banking and Financial Services: OCC and FFIEC Requirements

The Office of the Comptroller of the Currency and the Federal Financial Institutions Examination Council have issued extensive guidance on third-party risk management. OCC Bulletin 2023-17 establishes requirements for bank oversight of third-party relationships, including technology service providers. The FFIEC IT Examination Handbook addresses outsourcing technology services.

Banks and financial institutions using AI APIs are establishing third-party relationships with technology service providers. The OCC requires that banks conduct due diligence on third-party providers, establish contractual protections, and maintain ongoing monitoring. For critical activities, which AI-assisted decision-making increasingly represents, the requirements are heightened.

Sending customer financial data, transaction records, loan applications, or internal risk assessments to an AI vendor's plaintext processing pipeline raises immediate questions under the OCC framework. Has the bank conducted due diligence on the AI vendor's data handling practices? Has the bank assessed the vendor's information security program? Has the bank established contractual provisions addressing data confidentiality, integrity, and availability? Does the bank monitor the vendor's performance and compliance?

For most banks experimenting with AI, the answer to these questions is either "no" or "partially." The speed at which AI adoption has occurred has outpaced the third-party risk management programs at most financial institutions. The examiners have not yet focused on AI vendor oversight with the intensity they apply to core banking system providers. That will change. When it does, the question will not be "do you use AI?" It will be "what customer data did you send to the AI vendor, and what controls prevented the vendor from accessing it?"

The Contractual Promise Problem

Across all of these regulatory frameworks, organizations rely on contractual controls to manage AI vendor risk. BAAs for HIPAA. DPAs with SCCs for GDPR. Vendor agreements with confidentiality clauses for SOC 2 and banking. These contracts serve a purpose. They establish legal liability. They define obligations. They provide a basis for enforcement.

But contractual controls have a fundamental limitation: they do not change the technical architecture. A contract that says "the vendor will not access customer data" does not prevent the vendor's inference servers from processing customer data in plaintext. A contract that says "the vendor will delete data after processing" does not prevent the data from being captured in a log, a cache, a memory dump, or a backup before deletion occurs.

Contracts are enforced after the fact. They are remedial, not preventive. They shift liability but do not eliminate risk. They are necessary but insufficient. Every compliance framework recognizes this, which is why they require technical controls in addition to contractual ones. The problem is that for AI inference, the obvious technical control, encryption, has historically been incompatible with computation.

The Architectural Solution: Encrypt Before the API Call

Fully Homomorphic Encryption changes this equation. FHE enables computation on encrypted data without decryption. The mathematical operations that neural networks require, matrix multiplications, additions, activation approximations, can be performed directly on ciphertext. The vendor receives encrypted input, processes encrypted data, and returns encrypted output. At no point does the vendor access plaintext.

This is not a theoretical capability. H33 operates FHE-encrypted AI inference at production scale. Every operation completes in 38 microseconds. The vendor never sees the prompt. The vendor never sees the response. The vendor never stores plaintext. There is no plaintext gap between "encrypted at rest" and "encrypted in transit." The data is encrypted continuously, including during computation.

For GDPR, FHE satisfies the EDPB's supplementary measures requirement. The data controller holds the decryption keys. The data processor, the AI vendor, processes only ciphertext. A FISA 702 order compelling the vendor to produce data yields ciphertext. The encryption is the data controller's encryption, not the vendor's. This is the exact scenario the EDPB identified as an effective supplementary measure.

For SOC 2, FHE provides a demonstrable technical control. The auditor's question "what controls prevent the vendor from accessing customer data?" has a concrete answer: the data is encrypted with keys the vendor does not possess, and the computation occurs on ciphertext. This is not a contractual promise. It is a mathematical guarantee.

For banking, FHE addresses the OCC's data confidentiality requirements at the architectural level. Customer data never exists in plaintext at the vendor. The third-party risk is fundamentally reduced because the third party never has access to the underlying data.

H33-74: Attestation for Every Inference

Encryption alone is necessary but not sufficient for full compliance. Organizations also need proof that the encryption was applied, that the correct computation was performed, and that the result was not tampered with. H33-74 provides this attestation layer.

Every inference processed through H33 generates a 74-byte attestation that cryptographically binds the encrypted input, the computation performed, and the encrypted output. This attestation is post-quantum secured, meaning it remains valid even against future quantum computing attacks. Three independent cryptographic families underpin the attestation: lattice-based, hash-based, and structured-lattice signatures. An attacker would need to break all three simultaneously to forge an attestation.

The Audit Trail That Regulators Want

Regulators do not just want to know that you encrypted data. They want to know when, how, and whether the encryption was applied consistently. H33-74 attestations create an immutable audit trail. Every inference has a corresponding attestation. Every attestation is independently verifiable. The chain of attestations proves that encryption was applied to every operation, not just the ones you chose to demonstrate during the audit.

This audit trail addresses a gap that exists in every current AI deployment. Today, if an auditor asks "was customer data encrypted during AI processing on March 15th?" the honest answer for most organizations is "we don't know, but our contract says the vendor handles security." With H33, the answer is a cryptographic proof for every individual operation on that date.

The Cost of Inaction

Organizations that continue sending plaintext data to AI vendors are accumulating compliance debt. Every prompt containing PHI, personal data, customer financial information, or internal confidential data creates a potential violation. The regulatory landscape is tightening, not loosening. The EU AI Act imposes additional requirements on AI system providers and deployers. State-level privacy laws in the US are expanding. The OCC is increasing scrutiny of bank AI adoption.

The question is not whether regulators will examine your AI data handling practices. The question is when. And when they do, the distinction between "we had a contract with the vendor" and "we encrypted the data so the vendor never saw it" will determine whether you face an enforcement action or a clean audit.

The technology exists today. FHE at 38 microseconds per operation is not a research project. It is production infrastructure. H33-74 attestation is not a roadmap item. It is deployed. The only barrier is the decision to implement it.

Every day you wait, you send more plaintext to vendors you do not control, accumulating risk that compounds with every API call. Compliance is not a destination. It is a continuous obligation. And that obligation now extends to every AI inference your organization performs.