AI Compliance in Practice: EU AI Act, SOC 2, and HIPAA

Your legal team forwarded you a question from a prospective enterprise customer: "What's your EU AI Act compliance posture?" You had never heard of Annex III. You had two weeks until the sales call and a codebase that logged nothing but HTTP status codes. The compliance bill arrived before any regulator did.

This is the story of almost every engineering team that ships an LLM product into a regulated context without mapping the obligations first. The EU AI Act's prohibited-practice bans have applied since February 2025 and its GPAI provider obligations since August 2025; the high-risk obligations most enterprise products care about land on August 2, 2026 — weeks away, if you're reading this at publication. HIPAA has had teeth since 1996. SOC 2 auditors started asking pointed questions about model providers around 2025. None of these frameworks are optional, and none of them disappear if you ignore them long enough.

This article is a practical engineering guide to what each framework actually requires of you — not a legal opinion, but the concrete artifacts, controls, and architecture decisions that the legal requirements translate into.

The EU AI Act: risk tiers are the first engineering decision

The EU AI Act is structured as a tiered risk framework, not a blanket set of requirements for all AI. Understanding where your system sits determines how much work you have. The four tiers, from bottom to top:

Minimal risk covers things like spam filters, AI in video games, and recommendation engines with no consequential output. No specific obligations beyond basic transparency.

Limited risk covers systems that interact directly with humans — chatbots, deepfake generation tools. The primary obligation is transparency: you must disclose to users that they are interacting with an AI, and synthetic media must be labeled. Emotion recognition does not belong in this tier despite carrying the same transparency duty: it is prohibited outright in workplaces and education (Article 5) and high-risk under Annex III almost everywhere else.

High risk (Annex III) is where most enterprise builders run into the Act. Annex III lists the domains where AI systems face substantial obligations:

• Employment: automated CV screening, performance monitoring, workforce allocation
• Education: admissions, exam scoring, student assessment
• Essential services: credit scoring, insurance underwriting, emergency dispatch
• Law enforcement and migration decisions
• Administration of justice
• Critical infrastructure management

Medical devices are the notable absence: AI in an MDR-regulated device becomes high-risk through a different door — Article 6(1) and Annex I, which cover AI safety components of products under existing EU harmonisation legislation. That route means a notified-body conformity assessment under the sectoral law (the MDR, not the AI Act's self-assessment path) and a later applicability date, 2027. If you build clinical AI, plan against that track, not Annex III.

The test is not whether your product uses LLMs. The test is whether the AI system has a significant bearing on consequential decisions about people in one of these domains. A general-purpose chatbot that happens to be deployed at an HR company is not automatically high-risk — one that generates shortlisted candidate rankings that a manager acts on directly is much more likely to be.

Prohibited systems are banned outright: real-time biometric surveillance in public spaces (with narrow law-enforcement exceptions), social scoring systems, subliminal manipulation, and AI that exploits vulnerabilities of specific groups. These are not compliance challenges — they are systems you should not build.

flowchart LR
    TIER["EU AI Act\nRisk Tier"] --> MIN["Minimal risk\nNo specific obligations"]
    TIER --> LIM["Limited risk\nTransparency notice\nSynthetic media labels"]
    TIER --> HIGH["High risk (Annex III)\nConformity assessment\nTechnical file\nHuman oversight\nArt. 15 robustness\nEU database registration"]
    TIER --> PRO["Prohibited\nDo not build"]

    style MIN fill:#15803d,color:#fff
    style LIM fill:#0e7490,color:#fff
    style HIGH fill:#00e5ff,color:#0a0a0f
    style PRO fill:#ff2e88,color:#fff

What high-risk actually requires

For a high-risk AI system, the Act requires:

A conformity assessment. Most high-risk systems can do a self-assessment against the Act's requirements, documented in a technical file. Some categories (biometric identification, certain safety components) require a notified third-party body. Self-assessment still requires genuine internal review — not a signature on a template.

A technical file. This is the engineering artifact the Act is most specific about. It must contain: a description of the system's purpose and design, the training data and data governance methodology, information about the system's capabilities and limitations, accuracy metrics and performance on foreseeable use cases, and crucially — documentation of adversarial testing under Article 15.

Article 15 robustness. This is the clause that makes adversarial testing a legal requirement. Article 15(5) requires high-risk systems to be "resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities" — prompt injection and adversarial manipulation squarely included. Your technical file needs to show what testing you did, against which attack taxonomy, with what outcomes. NIST AI 600-1's GenAI Profile (which covers over 200 LLM-specific risk actions including prompt injection and training data integrity) and MITRE ATLAS are the two most commonly accepted frameworks for structuring this evidence. See red-teaming LLMs for the methodology.

Human oversight mechanisms. High-risk systems must be designed to allow human intervention and override. For LLM applications this means building explicit escalation paths, confidence thresholds that trigger human review, and audit trails sufficient for a person to reconstruct what the system did and why.

EU database registration. Before deploying in the EU, high-risk systems must be registered in the publicly accessible EU AI Act database. Registration requires your company name, system name, purpose, risk category, conformity assessment method, and contact details for the responsible provider.

Provider or deployer? The question that halves the article

Everything above assumes you are the provider — the entity that develops the system and places it on the EU market under its own name. Most teams building on a vendor model are actually deployers: they use an AI system under their own authority but didn't put it on the market. The distinction decides which obligations are yours.

Deployers of high-risk systems get a lighter but real list under Article 26: assign human oversight to people with the competence and authority to act on it, ensure input data is relevant to the system's intended purpose, monitor operation and suspend use if something looks wrong, keep the automatically generated logs for at least six months, and inform affected workers before using the system on them. Deployers that are public bodies, or private entities providing public services, also owe a fundamental-rights impact assessment under Article 27 before first use.

The trap is Article 25: a deployer becomes a provider — with the full conformity-assessment stack — by putting its name or trademark on a high-risk system, substantially modifying one, or changing a system's intended purpose in a way that makes it high-risk. White-labeling a vendor's screening tool as "YourCo Talent AI" is the canonical example. Fine-tuning a vendor model for an Annex III purpose can qualify as substantial modification; a system prompt tweak generally does not, but nobody should want to litigate that boundary. Decide which role you are in writing, before build, and re-check it whenever you rebrand or retrain.

GPAI models and the systemic risk tier

If your application is built on a general-purpose AI model trained above 10^25 FLOPs — which includes the frontier models from OpenAI, Anthropic, and Google — that model is subject to Chapter V obligations. These obligations fall on the model provider, not on you as the downstream application builder. But they matter to you because they determine how much transparency and cooperation you can get from the provider.

Providers of GPAI models with systemic risk must:

• Conduct and document adversarial testing of the model (state-of-the-art model evaluation), keeping the methodology and results in the technical documentation
• Report serious incidents to the EU AI Office within defined timelines
• Maintain technical documentation accessible to the EU AI Office on request

In practice: when you select a frontier model provider for a high-risk application, verify that they are meeting their GPAI Chapter V obligations. A provider who cannot demonstrate compliance is a supply chain risk for your own conformity assessment.

HIPAA: the BAA is non-negotiable

The Health Insurance Portability and Accountability Act requires that any company that handles Protected Health Information on behalf of a covered entity must sign a Business Associate Agreement. This is not a preference or a best-practice — it is a statutory requirement, and there is no technical workaround. A model that processes PHI without a BAA is a HIPAA violation regardless of how well the data is encrypted in transit.

What counts as PHI in LLM context. PHI is any individually identifiable health information — not just medical records. A prompt like "My patient John Smith, DOB 1974-03-12, presented with chest pain at 14:00 on June 3rd" contains PHI. A RAG chunk pulled from a patient chart is PHI. An LLM-generated clinical note is PHI. Aggregated, de-identified data is not PHI if it meets the Safe Harbor or Expert Determination de-identification standards — but most LLM applications in healthcare are working with identifiable patient-level data.

Who offers BAAs as of mid-2026.

Provider	BAA available	Notes
Microsoft Azure OpenAI Service	Yes	Covered under Azure's general HIPAA BAA for enterprise customers
Google Cloud Vertex AI	Yes	Covered under Google Cloud's BAA; Gemini API on Vertex, not the consumer API
Anthropic (direct API)	Yes	Claude API BAA available for enterprise agreements
OpenAI (direct API)	Yes, case-by-case	Available for eligible API customers, typically tied to zero-data-retention endpoints — not a standard click-through
Self-hosted open-weight models	N/A	You are the covered entity and the BA; BAA not required

This table will drift — verify with legal before selecting a provider for any PHI-touching use case. The mechanism is stable: if you're not self-hosting, you need a BAA.

Minimum-necessary standard. Even with a BAA, HIPAA requires that disclosures of PHI are limited to the minimum necessary for the purpose. For LLM applications this means your prompt construction logic should not include PHI fields that the model does not need to complete the task. A model answering "Is this treatment plan appropriate?" does not need the patient's home address. Build redaction or field-selection logic at the prompt assembly layer — not as a post-hoc filter on the output.

Access control and audit. The HIPAA Security Rule requires audit controls: hardware, software, and procedural mechanisms that record and examine activity in systems containing ePHI. For an LLM system this means logging every inference request that touched PHI, with user identity, timestamp, system prompt version, and a representation of the input and output sufficient to reconstruct the interaction. Storing raw PHI in logs requires the same protection level as any other ePHI store.

sequenceDiagram
    participant App as Application
    participant Redact as Redaction Layer
    participant LLM as LLM API (BAA-covered)
    participant Log as HIPAA Audit Log

    App->>Redact: Prompt with PHI fields
    Redact->>Redact: Apply minimum-necessary filter\nStrip non-essential PHI fields
    Redact->>LLM: Filtered prompt
    LLM-->>Redact: Response
    Redact->>Log: input_hash, output_hash, user_id,\nprompt_version, model_version, timestamp
    Redact-->>App: Response
    Note over Log: Log stored with same ePHI controls\nas patient record systems

Risk analysis update. HIPAA requires covered entities and business associates to conduct regular risk analyses of their ePHI environments. When you deploy an LLM system that touches PHI, that system and its data flows must appear in your risk analysis. Common gaps auditors find: the model provider is not in the risk analysis, the embedding service is not in scope, the vector database holding patient-derived chunks is treated as generic storage rather than an ePHI store. Each of these is a finding.

SOC 2: treating model providers as sub-processors

SOC 2 Type II audits are structured around five Trust Service Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. The criteria predate LLMs, so there are no LLM-specific controls — but the criteria apply to LLM systems in exactly the same way they apply to any other software.

The area where most LLM teams are caught off-guard is vendor management. The Security criterion (CC9.2) requires organizations to assess the risk of vendor relationships including "subservice organizations" — third parties whose services affect the TSC. Your LLM provider is a sub-processor. Your embedding model provider is a sub-processor. Your vector database is a sub-processor. If any of them process or store data that falls under your SOC 2 scope, auditors will ask:

• Do you have a vendor risk questionnaire on file for this provider?
• Do they have their own SOC 2 report you can review?
• Do you have contractual clauses covering data retention, incident notification, and acceptable use?
• Are you monitoring their security practices on an ongoing basis?

In practice:

• OpenAI, Anthropic, Azure OpenAI, and Google Vertex AI all have SOC 2 Type II reports available under NDA.
• Pinecone, Qdrant, and Weaviate all carry SOC 2 reports.
• Fine-tuning providers and smaller embedding API providers vary — if they do not have a SOC 2 report, you need to compensate with a more thorough questionnaire and contractual controls.

Processing Integrity. This criterion asks whether the system processes data completely, accurately, validly, and in a timely manner. For an LLM system this is genuinely hard — models hallucinate, outputs vary across identical prompts with non-zero temperature, and "complete and accurate" is a different concept than for a deterministic database query. Your SOC 2 approach here is to define what completeness and accuracy mean for your specific use case, put automated checks against those definitions in your deployment pipeline, and show auditors that output anomalies trigger alerts and remediation procedures. See hallucination mitigation and output validation for the technical approach.

Change management for prompts. Auditors scrutinize change management for anything that affects system behavior in scope. A system prompt is a configuration artifact that affects your LLM system's behavior in material ways — changing it without a change management process is a control gap. Treat prompt versions like code: versioned, reviewed, deployed through a documented process, and capable of being rolled back. The prompt versioning and CI/CD article covers the implementation.

{ "type": "eval-pipeline", "title": "Compliance evidence gates in the eval pipeline" }

Building the audit trail

All three frameworks require some form of audit trail that lets you reconstruct what happened after the fact. The HTTP access log from your reverse proxy does not satisfy this. What you need:

import hashlib
import json
from datetime import datetime, timezone
from dataclasses import dataclass, asdict
from typing import Optional

@dataclass
class LLMInferenceAuditRecord:
    timestamp: str               # ISO 8601 UTC
    request_id: str              # UUID, correlates to application trace
    user_id: str                 # authenticated identity
    session_id: Optional[str]
    model_id: str                # exact model version, e.g. "claude-sonnet-4-6"
    prompt_version: str          # git SHA or semantic version of system prompt
    input_hash: str              # SHA-256 of the full prompt (system + messages)
    output_hash: str             # SHA-256 of the model response
    input_token_count: int
    output_token_count: int
    latency_ms: int
    compliance_context: list[str]  # ["HIPAA", "EU_HIGH_RISK"] — drives retention policy

def build_audit_record(
    request_id: str,
    user_id: str,
    model_id: str,
    prompt_version: str,
    messages: list[dict],
    response_text: str,
    input_tokens: int,
    output_tokens: int,
    latency_ms: int,
    compliance_contexts: list[str],
    session_id: Optional[str] = None,
) -> LLMInferenceAuditRecord:
    input_payload = json.dumps(messages, sort_keys=True).encode()
    output_payload = response_text.encode()

    return LLMInferenceAuditRecord(
        timestamp=datetime.now(timezone.utc).isoformat(),
        request_id=request_id,
        user_id=user_id,
        session_id=session_id,
        model_id=model_id,
        prompt_version=prompt_version,
        input_hash=hashlib.sha256(input_payload).hexdigest(),
        output_hash=hashlib.sha256(output_payload).hexdigest(),
        input_token_count=input_tokens,
        output_token_count=output_tokens,
        latency_ms=latency_ms,
        compliance_context=compliance_contexts,
    )

The raw prompt content is not in the audit record — that is stored separately with appropriate access controls and retention policies (HIPAA ePHI controls for health data, 6-year retention minimum; EU GDPR data minimization principles for EU user data). The hash lets you link the audit record to the full interaction for investigation purposes without storing sensitive content in the log infrastructure.

Retention. Different frameworks drive different retention windows. HIPAA Security Rule requires six years from creation or last effective date. EU AI Act technical documentation for high-risk systems must be kept for ten years from market placement. SOC 2 doesn't specify, but auditors will ask if your retention policy is documented and enforced. Design the retention policy before you instrument the logging — changing it retroactively means either re-keying storage or documenting an acceptable exception.

What breaks when compliance is treated as a checkbox

The most expensive compliance failures follow a predictable pattern: the team treats the framework as a one-time certification rather than an ongoing operational state.

Drift between the technical file and the deployed system. The EU AI Act technical file describes the system as it existed at conformity assessment time. Every material change — a different model, a new system prompt, a new retrieval source — may require a file update and possibly a re-assessment. Teams that iterate fast on their prompts and models can quickly create a gap between what the file says and what the system does. Make technical file updates part of your deployment checklist for material changes, not an annual review.

The provider changes something you're not watching. Your BAA-covered model provider updates their model with no public announcement of version change. Your system prompt now interacts with subtly different behavior. Your HIPAA compliance depends on a consistent interpretation of minimum-necessary — has that changed? Your SOC 2 Processing Integrity controls depend on the system behaving consistently — does that still hold? Subscribe to your provider's changelog, pin model versions in production, and treat model version upgrades as change-managed deployments, not library patches.

PHI leaks into non-BAA infrastructure. A developer integrates a monitoring tool without checking whether it's in BAA scope. A vector database migration lands data on infrastructure without HIPAA controls. A logging pipeline sends request bodies to an observability vendor who has no BAA. These are the most common HIPAA findings in AI systems — not intentional violations but absent controls at integration points. The minimum-necessary principle applies to your own infrastructure, not just to what you send to the model.

Article 15 testing that doesn't survive "the attacker moves second". Research published in October 2025 showed that adaptive attacks bypassed all 12 published guardrail defenses with over 90% success rates. Static red-team coverage from the time of initial deployment is not sufficient. Article 15 compliance is not a one-time test; it requires ongoing adversarial testing with updated attack strategies as the threat evolves. Build red-team testing into your CI cadence — see red-teaming LLMs — and document the cadence in your technical file.

Audit logs that can't answer the question. An incident occurs. A user claims the system produced harmful output. Legal asks: "What exactly did the system say, what was in its context, and what model version was running?" If your audit trail is only HTTP status codes and timestamps, you cannot answer. If you can answer with hashes but not reconstruct the actual content, you can prove integrity but not content. Design the trail to answer the specific questions these frameworks require.

The compliance architecture in one view

flowchart TD
    USER[User request] --> GW["AI Gateway\nAuth, rate limiting,\nprompt version tag"]
    GW --> REDACT["Redaction / minimum-necessary\n(PHI-context only)"]
    REDACT --> LLM["LLM API\n(BAA-covered for PHI,\nmodel version pinned)"]
    LLM --> OUT["Output validation\nHallucination check\nPII scan on output"]
    OUT --> AUDITLOG["Structured audit log\ninput_hash, output_hash,\nmodel_id, prompt_version,\nuser_id, compliance_context"]
    OUT --> USER

    AUDITLOG --> RETAIN["Retention policy\nHIPAA: 6yr\nEU AI Act: 10yr"]
    GW --> VENDOR["Vendor management\nSOC 2 reports, BAAs,\nquestionnaires on file"]

    style LLM fill:#00e5ff,color:#0a0a0f
    style AUDITLOG fill:#0e7490,color:#fff
    style RETAIN fill:#15803d,color:#fff

Notice that the compliance controls layer around the LLM call rather than inside it. The redaction, audit logging, output validation, and vendor management artifacts are all application-layer concerns. The LLM itself is one component; the compliance posture is built in the surrounding architecture.

Worked compliance cost estimate

Scenario: B2B SaaS product in the HR sector (resume screening, Annex III)
deployed in the EU, processing no PHI, targeting SOC 2 Type II.
-----------------------------------------------------------------------
EU AI Act high-risk obligations:
  Technical file preparation              8 engineer-days (first time)
  Conformity self-assessment              5 engineer-days + 2 legal-days
  Article 15 red-team initial engagement  10 engineer-days
  Article 15 CI cadence (ongoing)         2 engineer-days/quarter
  EU database registration                0.5 days
  Human oversight UI (escalation path)    3 engineer-days

SOC 2 Type II:
  Model provider vendor questionnaire     0.5 days × 2 providers = 1 day
  Prompt change management process        2 engineer-days (design + docs)
  Audit trail instrumentation             3 engineer-days
  Output anomaly alerting                 2 engineer-days
  Annual evidence collection              2 days/year

Total first-year investment:              ~35 engineer-days
Ongoing annual cost:                      ~10–15 engineer-days/year
AI Act fine exposure at the 3% tier:      up to EUR 15M or 3% of global
                                          turnover, whichever is HIGHER —
                                          eight figures of downside
Break-even on compliance investment:      Day 1

This is not a precise project plan — it assumes a team that has built compliance-adjacent systems before, has legal support, and does not discover mid-audit that their data model was never designed for audit-trail access patterns. First-time teams should double the estimates.

Jurisdiction and applicability

The EU AI Act applies when the AI system is placed on the market or put into service in the EU — it is not limited to EU-based providers. A San Francisco startup shipping an Annex III system to German enterprise customers is in scope. Similarly, a system trained and deployed entirely outside the EU but accessible to EU users may fall under the Act depending on the use case.

HIPAA applies to covered entities (healthcare providers, health insurers, health data clearinghouses) and their business associates anywhere they handle ePHI on behalf of US-based covered entities. An EU company building software for US hospitals is a business associate.

SOC 2 is a US framework administered by the AICPA, but enterprise customers globally often require it as a baseline security assurance. It has no geographic boundaries — it follows the customer's requirements.

When all three apply simultaneously: build the audit infrastructure for the most demanding standard (EU AI Act's 10-year retention, HIPAA's minimum-necessary and access control requirements) and let the less demanding requirements be satisfied as a subset. Build once for the intersection, not three separate systems.

The decision in practice

The engineering question is always the same: is the compliance work proportional to the risk tier? For minimal-risk systems (most internal tools, productivity aids, content generation with no consequential outputs), the overhead is a transparency notice and sensible logging — a day's work. For limited-risk systems, add disclosure mechanisms for user-facing interactions. For high-risk Annex III systems, the conformity assessment and technical file are genuine multi-week investments that need to be planned from the start of the project, not discovered six weeks before launch.

The input and output guardrails article covers the technical controls that feed into your Article 15 robustness evidence. The PII handling and privacy controls article has the PHI redaction patterns in detail. The OWASP LLM Top 10 maps to both Article 15 and NIST AI 600-1 requirements, making it a useful starting framework for your adversarial testing scope.

One last observation: the companies that handle compliance well do not treat it as a constraint on engineering velocity. They treat it as an architecture constraint that forces them to build systems that are actually observable, testable, and auditable — properties that make incident response faster regardless of what the regulation says. The audit trail that satisfies a HIPAA auditor is the same trail that helps you debug a production incident at 2am. Building it is the work either way.