10 AI Compliance Requirements You Can't Ignore

EU AI Act Risk Classification

The EU AI Act categorizes AI systems into four risk levels: unacceptable, high, limited, and minimal. High-risk systems — including those used in credit scoring, hiring, law enforcement, and medical devices — face the strictest requirements: risk management systems, technical documentation, conformity assessments, CE marking, post-market monitoring, and incident reporting. You need to determine your system's risk tier before you ship, implement appropriate safeguards, and prepare for conformity assessments as enforcement ramps up through 2027.

Classification is not always obvious. A "draft assistant" that never auto-sends might be limited risk; the same model wired to auto-approve loan applications is high-risk. Document your classification rationale in writing — regulators will ask why you chose a tier, not just what tier you chose. If your system could reasonably be reclassified upward, build to the higher standard.

Implementation: Maintain an AI system inventory with risk tier, intended purpose, affected population, and geographic scope. For each high-risk system, assign an owner for conformity documentation. Run an annual reclassification review when features, data sources, or deployment regions change. See our 2027 compliance prep guide for the full EU AI Act timeline.

• Map each system to Annex III high-risk categories (employment, credit, education, critical infrastructure)
• Document why systems are not high-risk when you claim a lower tier — absence of evidence is not evidence of absence
• Build human oversight and logging to high-risk standards even on borderline systems — reclassification is cheaper than retrofitting

GDPR Data Processing for AI

Training and inference on personal data triggers GDPR obligations. You need a lawful basis for processing (consent, legitimate interest, or contract — choose carefully and document it), data minimization practices, purpose limitation, and the ability to honor data subject requests including deletion, access, and portability. For models trained on personal data, the right to erasure creates real technical challenges — you cannot simply delete a row from a training set without retraining or using machine unlearning techniques.

GDPR also governs automated decision-making. Article 22 gives individuals the right not to be subject to decisions based solely on automated processing when those decisions produce legal or similarly significant effects. That intersects directly with requirements #6 (explainability) and #7 (human oversight). Your privacy policy and DPIA must describe AI processing explicitly — vague "we use AI to improve services" language fails scrutiny.

Implementation: Complete a Data Protection Impact Assessment (DPIA) for any AI system processing personal data at scale. Log lawful basis per processing activity. For RAG pipelines, ensure retrieved documents respect retention limits. When users request deletion, trace their data through training sets, fine-tuning corpora, logs, and review queues. Our consent and privacy guide covers human-in-the-loop specifics.

SOC 2 for AI Systems

SOC 2 compliance is increasingly expected by enterprise customers — and auditors are adding AI-specific questions to Type II examinations. For AI systems, this means documenting model access controls, logging who can modify models and prompts, tracking data lineage from ingestion through review to delivery, and maintaining audit trails for automated decisions. SOC 2 auditors will ask how you ensure model integrity, prevent unauthorized prompt injection in production configs, and detect when a model version changes behavior without approval.

The Trust Services Criteria map cleanly to AI risks if you translate them. Security: who can access model endpoints and training data? Availability: what happens when your review queue backs up? Processing integrity: can you prove the output a customer received matches what your pipeline generated? Confidentiality: is PII masked before it reaches third-party model APIs? Build these controls into your pipeline architecture, not your audit prep spreadsheet.

Implementation: Version-control prompts and model configurations with approval workflows. Restrict production model changes to named approvers. Log every inference request with model version, prompt hash, and reviewer identity. Run quarterly access reviews on who can modify AI pipeline settings. Attach SOC 2 evidence to your audit trail design from day one.

HIPAA for Health AI

Any AI system processing protected health information (PHI) must comply with HIPAA's Privacy and Security Rules. This includes business associate agreements (BAAs) with every AI vendor that touches PHI — OpenAI, Anthropic, and cloud providers included — encryption of PHI at rest and in transit, role-based access controls, minimum necessary data policies, and audit logging of PHI access. Health AI systems that make clinical recommendations may also face FDA oversight as Software as a Medical Device (SaMD), adding validation and adverse event reporting on top of HIPAA.

The most common failure mode: a clinical summarization tool that sends full patient records to an API without a BAA, or a support bot that logs PHI in plaintext application logs. De-identification is not a free pass — re-identification risk assessments matter when combining datasets. Human reviewers handling PHI need training, access logging, and workflows that prevent PHI from leaking into non-HIPAA systems.

Implementation: Inventory every AI touchpoint that processes PHI. Confirm BAAs with all subprocessors. Use PHI-minimized prompts — send only the fields required for the task. Encrypt logs, restrict reviewer access by role, and retain audit trails for six years. Route clinical outputs through qualified human reviewers before they reach care teams. See handling AI errors in regulated industries for escalation patterns.

Bias Auditing Requirements

New York City Local Law 144 requires annual bias audits for automated employment decision tools — with public disclosure of summary results. Colorado's AI Act mandates impact assessments for high-risk systems, including bias analysis. Illinois, Maryland, California, and other states are introducing similar legislation. Even where not legally required, bias auditing is becoming a de facto standard for responsible AI deployment and a standard line item on enterprise security questionnaires.

Bias audits are not one-time events. They must cover the deployed system as it exists today — model version, prompt, training data slice, and decision thresholds. An audit of last year's model does not satisfy regulators when you've shipped three prompt updates since. Define protected attributes relevant to your jurisdiction and use case, measure disparate impact across them, and document mitigation steps when thresholds are exceeded.

Implementation: Schedule annual third-party bias audits for employment and credit systems. Maintain internal quarterly checks on smaller feature changes. Log demographic proxies only where legally permissible and necessary — consult counsel on what you can measure in your jurisdiction. Publish required disclosures (NYC LL 144) and keep full audit reports available for regulatory request. Pair statistical audits with human review sampling on edge cases automation misses.

Explainability Requirements

GDPR Article 22 and the EU AI Act both push toward meaningful transparency for AI-driven decisions. Regulators increasingly expect explanations of why a particular output was produced — not model internals, but decision rationale a affected individual can understand. This does not mean your model needs to be fully interpretable; it means you need a system for generating explanations tied to the specific input and output.

Explainability fails when teams confuse it with logging. Storing the prompt and response is not an explanation. A useful explanation answers: what factors influenced this decision, what data was considered, what alternatives were evaluated, and what a person can do if they disagree. For LLM systems, template-based explanations ("this recommendation was based on your stated income and employment history") often satisfy requirements better than post-hoc rationalization from the model itself.

Implementation: Require structured explanation fields in high-risk outputs. Separate "model reasoning" (internal) from "user-facing explanation" (regulatory). Test explanations with non-technical reviewers — if they cannot understand them, regulators will not either. Log explanation version alongside model version so you can reproduce what was communicated. Combine with human review so explanations are validated before delivery on Tier 1 decisions.

Human Oversight Mandates

The EU AI Act explicitly requires human oversight for high-risk systems. This means more than a human in the loop — you need documented processes for when and how humans intervene, override decisions, escalate edge cases, and audit system behavior. Oversight must be meaningful: reviewers need authority to block outputs, sufficient context to make informed judgments, and training on the system's limitations. Teams that treat human review as a checkbox rather than a genuine safeguard will struggle during audits.

Regulators distinguish between oversight and rubber-stamping. If reviewers approve 99.8% of outputs in under three seconds each, that is not oversight — it is theater. Measure override rates, time-on-task, escalation frequency, and disagreement between reviewers. Healthy oversight systems show non-trivial override rates and variable review times that correlate with case complexity.

Implementation: Define oversight levels by risk tier: full review before delivery on Tier 1, sampled review on Tier 2, exception-based on Tier 3. Give reviewers explicit authority to reject, edit, or escalate — and log every action. Train reviewers on regulatory context, not just UI mechanics. Run calibration sessions monthly. Our human-in-the-loop best practices cover workflow design in depth.

Record-Keeping and Audit Trails

Regulators want to see what your AI system decided, when, why, and who approved it. You need immutable logs of model inputs, outputs, confidence scores, prompt versions, model versions, reviewer actions, override decisions, and delivery timestamps. These records must be retained for the period specified by applicable regulations — typically three to seven years for financial and health data, longer in some jurisdictions. Building this after the fact is painful and expensive; build it from day one.

Audit trails must be queryable by non-engineers. Compliance teams need to pull every decision involving a specific user, every output from a specific model version, or every override during a date range — without writing SQL. Export to CSV for regulatory submission. Tamper-evidence matters in regulated industries: hash chaining or append-only storage demonstrates logs were not retroactively edited.

Implementation: Log at the pipeline level, not the application log level. Capture: request_id, model_version, prompt_hash, input_hash (not raw PII), output_hash, reviewer_id, verdict, timestamp. Define retention per regulation and automate archival. Run a quarterly mock audit: pick a random output and reconstruct the full decision chain within one hour. See our technical guide on building AI audit trails.

Incident Reporting

The EU AI Act requires notification to authorities when a high-risk AI system causes or contributes to a serious incident. The FDA has adverse event reporting for AI-enabled medical devices. NIST's AI RMF encourages voluntary incident reporting. You need a process for detecting, classifying, documenting, and reporting AI failures — not just internal post-mortems closed in a Slack thread. Incidents include: discriminatory outcomes at scale, safety-critical wrong answers, data breaches via AI pipelines, and model behavior changes that bypass controls.

Incident response for AI differs from traditional software. A bad deploy might affect millions of decisions before you detect it. Define severity tiers: a single wrong product recommendation is internal; a systematic credit scoring error affecting a protected class is regulatory. Assign an incident commander, a communications owner, and a regulatory liaison before you need them.

Implementation: Write an AI incident runbook with severity definitions, notification timelines, and authority contacts. Monitor for anomaly spikes in override rates, error reports, and bias metrics. Preserve forensic evidence immediately — logs, model versions, prompt snapshots. Report within regulatory deadlines (EU AI Act serious incidents have specific timeframes). Conduct blameless post-mortems with compliance and engineering jointly.

Third-Party Model Governance

If you use APIs from OpenAI, Anthropic, Google, or open-source models, you are still responsible for compliance. Your vendor's terms do not transfer liability to them. Document which models you use, their versions, how they are configured (temperature, system prompts, safety settings), what data you send, and what safeguards you have implemented downstream. Model providers change terms, capabilities, and behavior through silent updates — your governance process must detect and respond to drift.

Third-party governance also covers subprocessors. Enterprise customers and regulators will ask for your vendor list, their certifications (SOC 2, ISO 27001), data residency guarantees, and whether they train on your data. Maintain a model registry: provider, model ID, version, approval date, approved use cases, and restricted data types. Block unaudited model swaps in production via configuration controls.

Implementation: Require security review before adding a new model provider. Pin model versions in production configs; treat version bumps as change requests requiring re-validation. Monitor provider changelogs and run regression suites after announced updates. Store vendor DPAs and BAAs alongside your model registry. Run our pipeline compliance audit framework quarterly to catch shadow model usage.

Start With What Applies to You

Not every requirement applies to every system, but most teams are subject to more than they realize. Start by mapping your AI systems to the regulations that apply based on your industry, geography, and data types. Then build a compliance checklist with owners, deadlines, and evidence requirements. Prioritize high-risk systems first — they carry the highest fines and the shortest regulatory timelines.

The cost of non-compliance — fines up to €35 million or 7% of global turnover under the EU AI Act, HIPAA civil penalties, SOC 2 deal loss, and reputational damage — far exceeds the cost of building compliant systems from the start. Compliance is also a sales accelerant: enterprise buyers increasingly require evidence of AI governance before procurement.

Compliance is not a legal department deliverable — it is a pipeline property. If your logs, oversight workflows, and vendor registry cannot answer a regulator's question in an hour, you are not compliant on paper or in practice. Build evidence into every output, not into a folder you assemble before the audit.

Your compliance readiness checklist

Before your next launch or enterprise security review, confirm:

• Every AI system has a documented risk classification and owner
• DPIAs and lawful basis documentation exist for personal data processing
• Model versions, prompts, and reviewer actions are logged with tamper-evident storage
• Human oversight is meaningful — reviewers can block, override, and escalate with authority
• Bias audits are scheduled and cover the currently deployed system
• User-facing explanations exist for high-risk automated decisions
• Third-party models are inventoried with DPAs, BAAs, and version pinning
• An incident runbook defines severity, notification timelines, and regulatory contacts

Teams that run this checklist quarterly — not just before audits — treat compliance as continuous posture, not annual theater. Pair it with the mock audit steps in our pipeline compliance audit and the documentation standards in our 2027 team prep guide.