AI Legal & Compliance

Why This Matters

AI regulation is no longer theoretical. The EU AI Act became enforceable in 2024. Courts across multiple jurisdictions are actively ruling on AI copyright cases. Data protection authorities are investigating AI companies for GDPR violations. Companies that build AI products without understanding the legal landscape are not just taking risks with their business. They are taking risks with their users.

For AI product managers and engineers, legal compliance is not the exclusive domain of the legal team. You make compliance-affecting decisions every day: what data you use to fine-tune a model, whether a feature makes automated decisions that affect users, how long you retain conversation logs, and what you put in your vendor contracts. Understanding the legal landscape empowers you to make better decisions, catch problems early, and know when to escalate to counsel.

Everyday Analogy

Think of AI legal compliance like building safety codes for a new type of structure. When reinforced concrete was invented, buildings codes did not yet exist for it. Engineers who used it recklessly caused disasters. Those who understood the material's properties, and why safety codes were evolving around it, built structures that stood. Regulatory frameworks for AI are being written right now, partly in response to real harms. Understanding why the rules exist helps you apply them intelligently rather than treating them as bureaucratic obstacles.

The Regulatory Landscape

EU AI Act

The EU AI Act, which entered into force in August 2024, is the world's first comprehensive horizontal AI regulation. It applies to any AI system placed on the EU market or used within the EU, including systems developed elsewhere that serve EU users.

The Act classifies AI systems into four risk tiers:

What this means for your product: Most consumer AI features (chatbots, writing assistants, recommendation engines) fall in the Limited or Minimal tier. If you are building AI that affects employment decisions, credit access, healthcare, or critical infrastructure, you are likely in the High-risk tier and face significant compliance obligations.

General-purpose AI models (like large language models offered as APIs) have their own obligations under the Act, including transparency requirements and copyright compliance for training data. Model providers bear these obligations, but product builders using APIs inherit some responsibilities depending on how they deploy the models.

Timeline: Prohibitions on unacceptable risk AI were enforceable from February 2025. Obligations for high-risk AI and GPAI models apply from August 2025 onward. Fines can reach €30 million or 6% of global annual turnover for the most serious violations.

GDPR for AI

The General Data Protection Regulation applies whenever an AI system processes personal data about EU residents, which includes almost any AI feature that personalises responses, stores conversation history, or uses user data to fine-tune models.

Lawful Basis for Training Data

Training a model on data requires a lawful basis under GDPR Article 6. Common bases include:

• Consent: Users explicitly agree to their data being used for training. Must be freely given, specific, informed, and withdrawable.
• Legitimate interests: The data controller has a legitimate interest that is not overridden by users' rights. Requires a legitimate interests assessment (LIA).
• Contract: Processing is necessary to perform a contract with the user.

Scraping publicly available data for training is not automatically lawful. Data published publicly was not necessarily published with consent to be used as AI training data. Several regulators have issued guidance and enforcement actions on this point.

Right to Explanation and Automated Decision-Making

GDPR Article 22 gives individuals the right not to be subject to solely automated decisions that have a significant effect on them, including decisions about credit, employment, or access to services. Where automated decisions are unavoidable (e.g., in credit scoring), organisations must:

• Inform the user that automated decision-making is occurring
• Provide meaningful information about the logic involved
• Give the user the right to request human review
• Give the user the right to contest the decision

AI product implication: If your AI feature makes or heavily influences a consequential decision about a user, you need a mechanism for human review and challenge, not just a disclaimer in your privacy policy.

Data Subject Rights

GDPR gives users several rights that must be honoured for AI systems:

Honouring erasure requests is technically complex for AI systems. If a user's data was used in fine-tuning, removing that influence may require retraining, which is expensive and sometimes impractical. Consult your legal team on how your vendor's fine-tuning agreements handle deletion obligations.

US AI Regulation

The United States has taken a sector-specific rather than horizontal approach to AI regulation, though this landscape is evolving rapidly.

Federal Executive Orders and Guidance: Executive orders on AI have set expectations around safety testing, watermarking of AI-generated content, and AI use in federal agencies. These do not directly bind private sector AI products but signal enforcement priorities.

State-level laws:

• Colorado AI Act: Requires developers and deployers of high-risk AI systems to use reasonable care to protect consumers from algorithmic discrimination. Applies from 2026.
• Illinois AI Video Interview Act: Requires employers using AI to analyse job interview videos to notify candidates and obtain consent.
• California proposals: Multiple bills have advanced through the California legislature targeting AI safety, transparency, and discrimination.

Sector-specific rules:

• HIPAA: Any AI feature that processes protected health information (PHI) must comply with HIPAA's privacy and security rules. This includes clinical decision support AI, patient-facing chatbots, and AI used in healthcare administration.
• FCRA and ECOA: AI used in credit decisions must comply with the Fair Credit Reporting Act and Equal Credit Opportunity Act, including adverse action notices and non-discrimination requirements.
• Financial services: The SEC, CFTC, and banking regulators have issued guidance on AI use in trading, advisory services, and risk management.

UK AI Regulation

Post-Brexit, the UK adopted a principles-based, sector-specific approach rather than a single AI Act. The UK government has asked existing sector regulators (the FCA for financial services, the ICO for data protection, the CMA for competition) to apply their existing frameworks to AI within their domains.

The UK AI Safety Institute has focused on frontier model evaluation. For most product builders, UK compliance primarily means applying existing data protection law (UK GDPR, which mirrors EU GDPR) and sector-specific guidance.

Intellectual Property Issues

Training Data Copyright

AI models are trained on large datasets that frequently include copyrighted material: books, articles, code repositories, images, websites. Whether this constitutes copyright infringement is being actively litigated in multiple jurisdictions.

Key legal questions include:

• Does training on copyrighted data constitute reproduction or a transformative use?
• Is the resulting model a derivative work?
• Are the outputs of the model infringing if they closely resemble training data?

Practical guidance: When choosing a model provider or building your own training pipeline, ask:

• What is the provenance of the training data?
• Does the provider offer contractual indemnification for copyright claims arising from model outputs?
• Does the provider operate an opt-out registry for copyright holders?

Several major model providers now offer copyright indemnification for outputs generated through their commercial APIs, subject to usage policy compliance.

AI-Generated Output Ownership

The US Copyright Office has ruled that AI-generated content with no human authorship is not eligible for copyright protection. If a human makes sufficiently creative choices in the prompting and selection of AI outputs, some protection may attach to the result, but the extent is unclear and varies by jurisdiction.

Practical implication: If your product generates content that users need to own and protect (marketing materials, creative writing, code), be transparent with users about the copyright status of AI-generated outputs. Do not assert copyright ownership over outputs that may not be protectable.

Code Generation and Licensing Risk

LLMs trained on code repositories may reproduce code snippets that carry open-source licenses (GPL, MIT, Apache). Reproducing GPL-licensed code in a proprietary product without complying with the GPL's requirements creates legal exposure.

Practical guidance:

• Use code generation models that were trained on permissively licensed code or that have licensing filters
• If building on a foundation model's code generation, check whether the provider offers IP indemnification for code outputs
• Implement a code scanning step in your CI/CD pipeline to detect potential license violations in AI-generated code before it ships

Data Privacy for AI Products

User Data in Prompts and Context

Every time a user interacts with your AI feature, their input becomes part of a prompt. That prompt may contain sensitive personal information: names, medical conditions, financial details, relationship problems, confidential business information.

Best practices:

• Minimise what you log. Log what you need for debugging and quality evaluation, not everything. Avoid logging full prompt content unless necessary.
• Separate personal data from model improvement data. If you fine-tune on conversation logs, implement a process to de-identify or redact personal information before it enters the training pipeline.
• Inform users clearly. Your privacy policy and in-product disclosures should explain clearly what conversation data is retained, for how long, and how it may be used.

Data Retention and Deletion

Define retention periods for every category of AI-related data you collect: conversation logs, model inputs, model outputs, evaluation data, fine-tuning datasets, embeddings derived from user data.

Retention should be:

• As long as necessary for the stated purpose
• No longer than the user expects
• Governed by a documented retention schedule

Implement automated deletion pipelines so that data is deleted when its retention period expires. Do not rely on manual processes for this.

Consent for AI Features

When you introduce a new AI feature that processes personal data in a new way, assess whether existing user consent (or legitimate interest documentation) covers the new processing. If it does not, you need to obtain fresh consent or conduct a new legitimate interests assessment before launching the feature.

Be particularly careful with:

• Using conversation history to personalise responses (profiling)
• Using user data to improve or fine-tune your models
• Sharing conversation data with third-party AI providers

Data Residency Requirements

Many enterprise customers and some regulations require that data remain within a specific geographic region. If you use a third-party LLM API, check where inference happens and where conversation logs are stored. Some providers offer data residency guarantees as a premium feature.

Liability and Risk

Vendor Contracts

Your relationship with your AI model provider is governed by a contract that has significant legal implications. Review these clauses carefully:

AI Errors and Harm

LLMs hallucinate. They produce plausible-sounding but incorrect information with confidence. If your product presents AI output as authoritative (in healthcare, legal, financial, or safety contexts), you face potential liability when that output causes harm.

Mitigation strategies:

• Add appropriate disclaimers for high-stakes domains ("This is not medical/legal/financial advice")
• Implement human review for high-stakes AI outputs
• Build explicit uncertainty signalling into your UX ("I'm not certain about this — please verify")
• Maintain clear audit trails of what the AI produced versus what a human reviewed and approved
• Carry appropriate professional liability insurance if your product operates in regulated domains

Model Cards and AI Documentation

Model cards are structured documents that describe a model's intended use cases, limitations, evaluation results, and ethical considerations. Many regulators and enterprise customers are beginning to require them.

Even if not legally required for your product today, maintaining internal model cards for any custom or fine-tuned models you deploy is good practice: it forces clarity about what the model is for, where it was tested, and where it may fail.

Compliance Frameworks for AI Teams

Privacy by Design

Privacy by design means building data protection into your product from the start, not bolting it on afterward. For AI features, this means:

• Considering data minimisation before you decide what to log
• Designing data flows that separate personal data from model training data
• Building deletion capabilities into your architecture before you need them
• Involving privacy review in the feature design process, not just the launch checklist

AI Impact Assessments

An AI impact assessment (AIA) is a structured evaluation of a proposed AI feature's potential risks to individuals and groups. It mirrors the Data Protection Impact Assessment (DPIA) required under GDPR for high-risk data processing.

A practical AIA template for an AI product team includes:

1. Feature description: What does the AI feature do? What decisions does it make or influence?
2. Data flows: What personal data is processed? Where does it come from? Where does it go?
3. Risk identification: Who could be harmed? How? Under what circumstances?
4. Vulnerable groups: Does the feature interact with children, people with health conditions, or other protected groups?
5. Bias assessment: Has the model been evaluated for demographic performance disparities?
6. Mitigation measures: What controls reduce identified risks?
7. Residual risk: What risks remain after mitigations? Are they acceptable?
8. Review schedule: When will the assessment be reviewed?

Run an AIA for every new AI feature before launch, not as a bureaucratic gate, but as a genuine thinking exercise that surfaces problems early when they are cheap to fix.

Audit Trails for AI Decisions

For any AI feature that influences significant decisions, maintain an audit trail that records: the inputs to the model, the version of the model and prompt used, the output produced, whether a human reviewed the output, and the final decision made. This record is essential for investigating complaints, responding to regulator inquiries, and improving your system over time.

Model Documentation and Lineage Tracking

Track the provenance of every model you deploy: where the training data came from, what fine-tuning was applied, what evaluation was performed, when the model was deployed, and what version is currently serving production traffic. This lineage record is essential for incident response: if a model produces harmful outputs, you need to know exactly what you deployed and when.

Practical Compliance Checklist for AI Features

Use this checklist before launching any AI feature:

Data and Privacy

• Identified all personal data processed by the feature
• Confirmed lawful basis for all processing activities
• Updated privacy policy and in-product disclosures
• Confirmed data retention periods are defined and automated deletion is in place
• Verified vendor DPA is in place with the model provider
• Checked data residency requirements for enterprise customers

Risk and Governance

• Completed AI impact assessment
• Classified the feature under EU AI Act risk tiers
• Evaluated bias and performance across demographic groups
• Defined human oversight mechanisms for high-stakes outputs
• Added appropriate disclaimers for regulated domains

Intellectual Property

• Confirmed training data provenance with model provider
• Checked whether provider offers IP indemnification
• Implemented code scanning if the feature generates code

Operations

• Audit trail implemented for significant AI decisions
• Model version and prompt version documented and version-controlled
• Incident response plan updated to include AI-specific scenarios

When to Involve Legal Counsel

You do not need a lawyer for every AI decision, but you do need one for these situations:

• Drafting or reviewing vendor contracts and DPAs with model providers
• Assessing whether a feature triggers GDPR Article 22 (automated decision-making)
• Evaluating IP risk in training data or model outputs
• Responding to data subject requests that may require model retraining
• Expanding into a new regulated sector (healthcare, financial services, education)
• Receiving a regulatory inquiry or complaint about an AI feature
• Launching in the EU if you have not previously done an EU AI Act classification
• Any feature involving biometric data, health data, or financial data

Early, proactive legal review is far cheaper than reactive legal work after a problem occurs.

Try It Yourself

1. Map one AI feature against the four legal surfaces in this lesson: data protection (whose data enters prompts?), IP (who owns outputs?), disclosure (do users know it's AI?), and sector rules. One sentence each. That's the memo a lawyer wants to start from.
2. Read one real AI provider's data-processing terms (any major API's DPA page) and answer: is your prompt data used for training? Retained how long? Processed where? Three answers every buyer should know before shipping.

Key Takeaways

• The EU AI Act classifies AI by risk tier: most consumer AI features are Limited or Minimal, but employment, credit, and healthcare AI face significant High-risk obligations.
• GDPR applies to almost any AI feature that processes personal data. Automated decision-making (Article 22) and data subject rights are the highest-stakes areas for AI product teams.
• Training data copyright, AI output ownership, and code generation licensing are active legal battlegrounds; choose providers with clear IP indemnification policies.
• Build privacy into your AI features from the start through data minimisation, consent management, and automated deletion pipelines.
• AI impact assessments and audit trails are not just compliance overhead: they make your product better by forcing you to think clearly about risk.
• Involve legal counsel proactively for contracts, regulated sectors, and novel features. It is always cheaper than reactive intervention.

Continue to AI-057: Prompt Versioning & Management →