{
  "schema_version": 1,
  "skill_name": "legal-strategy",
  "evals": [
    {"id":"jurisdictional-triage","prompt":"Assess an EU and US launch of an AI profiling feature.","expected_output":"A facts-versus-assumptions risk memo identifies jurisdictional triggers, uncertainty, interim controls, and questions for licensed counsel; it does not give legal advice.","assertions":["Separates known facts from assumptions","Identifies jurisdiction and regulatory triggers","Rates uncertainty and proposes reversible interim controls","Escalates interpretation and launch approval to licensed counsel","Explicitly states the output is not legal advice"]},
    {"id":"contract-risk-review","prompt":"Review a SaaS contract with broad indemnity, uncapped liability, and a DPA.","expected_output":"A bounded issue list ties each clause to exposure, negotiation questions, fallback positions, owner, and counsel escalation.","assertions":["Identifies indemnity and liability-cap exposure","Separates clause text from assumptions","Provides negotiation questions and fallback positions","Routes technical privacy controls to the appropriate owner","Requires counsel review before acceptance"]},
    {"id":"privacy-dpia","prompt":"Design a DPIA intake for a product collecting behavioral data across borders.","expected_output":"A DPIA workflow captures purpose, data subjects, necessity, risks, mitigations, transfers, approvals, and review triggers.","assertions":["Captures purpose, data categories, and affected people","Addresses necessity, proportionality, and cross-border transfers","Defines mitigations and accountable owners","Includes approval and change-review triggers","Avoids claiming that a template determines compliance"]},
    {"id":"ip-portfolio","prompt":"Choose between patent, trademark, trade-secret, and open-source controls for a new feature.","expected_output":"A decision record compares protectability, disclosure, jurisdictions, cost, timing, and business value, with counsel questions and evidence.","assertions":["Compares patent, trademark, trade-secret, and open-source paths","States disclosure, jurisdiction, cost, and timing assumptions","Links the choice to business value and reversibility","Records evidence and unresolved questions","Escalates filing and legal conclusions to counsel"]},
    {"id":"employment-escalation","prompt":"We plan a contractor conversion and a reduction in force across two countries.","expected_output":"A triage memo identifies facts and deadlines, flags employment-law and employee-relations risks, and routes all jurisdiction-specific action to counsel.","assertions":["Distinguishes classification and termination questions","Requests country-specific facts and deadlines","Identifies employee-relations and documentation risks","Requires qualified local counsel before action","Does not present legal advice as a decision"]}
  ]
}

# Contract Risk Assessment

## Key Contract Provisions

### Indemnification

The indemnification clause determines who bears the cost of a third-party claim arising from the contract.

| Type | What it covers | Who bears risk |
|------|----------------|----------------|
| **Mutual indemnification** | Each party indemnifies for claims arising from their own breach/negligence | Balanced |
| **One-way indemnification** | Only one party indemnifies the other | Unbalanced — typically favors the provider |
| **IP indemnification** | Claims that the product infringes third-party IP | Provider bears infringement risk |
| **Data breach indemnification** | Claims from a security incident involving customer data | Party responsible for the breach |

**Negotiation tips:**
- Push for mutual indemnification whenever possible
- IP indemnification should be capped at the same amount as general liability
- Exclude claims arising from customer's modifications, misuse, or combination with third-party products
- Ensure coverage for settlement amounts, not just judgment

### Liability Caps

| Term | Typical range | Strategy |
|------|---------------|----------|
| **Liability cap** | 1x to 12x monthly or annual fees | Customer: push for multiple of fees. Provider: push for single digit multiple |
| **Uncapped exceptions** | IP infringement, breach of confidentiality, death/injury, fraud | Never cap these |
| **Mutual vs one-sided** | Some caps apply only to one party | Push for mutual caps with same exceptions |

### The Liability Cap Tiers

| Tier | Multiplier | Context |
|------|------------|---------|
| Enterprise deal, strong negotiating position | 12x annual fees | Customer-side enterprise procurement |
| Mid-market | 6x annual fees | Balanced negotiation |
| SMB / standard terms | 1x-3x annual fees | Provider's standard terms |
| Uncapped | N/A | Only for IP, confidentiality, fraud |

### Force Majeure

| Element | Description | Key issue |
|---------|-------------|-----------|
| **Events** | Acts of god, war, terrorism, pandemic, government action, labor strike | Is pandemic explicitly included? (Post-COVID: yes) |
| **Effect** | Performance becomes impossible, illegal, or impracticable | "Impossible" is narrower than "impracticable" |
| **Duration** | How long until termination rights arise | 30-90 days is typical |
| **Obligation** | Notice requirement, mitigation duty | Must notify within X days of triggering event |
| **Exclusions** | What is NOT force majeure | Economic hardship, market changes, supplier failure (unless force majeure) |

**Post-COVID update:** Force majeure clauses are now reviewed carefully. Ensure pandemics are explicitly included (many pre-2020 contracts excluded them). Some contracts now have a separate "business continuity" or "pandemic" clause.

### Limitation of Liability

The limitation of liability clause excludes certain types of damages:

| Excluded damages | Typical scope | Negotiation strategy |
|-----------------|---------------|---------------------|
| **Consequential damages** | Indirect, incidental, special, punitive | Never exclude damages for breach of confidentiality, IP infringement, or data breach |
| **Lost profits** | Revenue the customer expected to generate | Exclude for everyone — too speculative |
| **Lost data** | Cost of recreating or recovering data | Provider should exclude; customer should carve out if provider destroys customer data |

### Data Protection / Privacy Addendum

Must include:

1. **Data Processing Agreement (DPA)** — Required under GDPR Art. 28
2. **Data Security Schedule** — Specific security measures, encryption standards, breach notification timeline
3. **Data Transfer Mechanism** — SCCs or adequacy decision for cross-border transfers
4. **Data Retention and Deletion** — Timeframes for deletion after contract termination
5. **Sub-processor List** — Approved sub-processors, change notification, objection rights
6. **Audit Rights** — Customer's right to audit provider's security practices

## Contract Lifecycle

### Pre-Signature Checklist

- [ ] Scope of work clearly defined (SOW or exhibit)
- [ ] Pricing and payment terms unambiguous
- [ ] Term, renewal, and termination provisions clear
- [ ] Liability cap (mutual, with appropriate exceptions)
- [ ] Indemnification scope matches risk allocation
- [ ] DPA/data protection addendum attached (if processing personal data)
- [ ] Governing law and dispute resolution specified
- [ ] Confidentiality obligations mutual
- [ ] IP ownership: each party retains its pre-existing IP; deliverables IP assigned to customer
- [ ] SLA (if applicable) with service credits

### Post-Signature Management

| Phase | Action | Owner |
|-------|--------|-------|
| **Day 1** | File signed contract in repository, assign to contract manager, set renewal reminder | Legal ops |
| **Ongoing** | Track obligations (reporting, compliance, renewal deadlines) | Contract manager |
| **At renewal** | Review performance against SLA, negotiate improvements, update terms | Legal + Business |
| **At termination** | Confirm data deletion, final payment, close-out obligations | Legal ops |

## Contract Risk Scoring

| Risk level | Characteristics | Review requirement |
|------------|----------------|--------------------|
| **Low** | Standard terms on provider's paper, minimal data processing, low value | Fast-track, no redlines |
| **Medium** | Custom terms, moderate data processing, some redlines expected | Counsel review, key terms only |
| **High** | Customer's paper, aggressive redlines, high-value, significant data processing | Full counsel review, exec approval |
| **Critical** | Uncapped liability, one-way indemnification, unusual data handling | External counsel, board approval |

# Data Privacy Framework

## Privacy-by-Design (PbD)

The seven foundational principles, as articulated by Dr. Ann Cavoukian and codified in GDPR Article 25:

### 1. Proactive Not Reactive; Preventative Not Remedial

| Traditional approach | PbD approach |
|---------------------|--------------|
| Respond to breaches after they happen | Anticipate and prevent privacy-invasive events |
| Privacy is a compliance checkbox | Privacy is a design requirement |
| Privacy reviewed at launch | Privacy considered from the first spec |

### 2. Privacy as the Default Setting

Data is automatically protected without the user having to take action:

- **Data minimization**: Collect the minimum data needed
- **Purpose limitation**: Process data only for specified purposes
- **Limited accessibility**: Only authorized personnel can access
- **Limited retention**: Automatically delete data when no longer needed
- **Privacy-preserving defaults**: Opt-in, not opt-out

### 3. Privacy Embedded into Design

Privacy is not bolted on after the fact — it's an integral part of the system:

- Architecture diagrams include data flows and privacy controls
- User stories include privacy acceptance criteria
- Code reviews check for privacy compliance
- Testing includes privacy scenarios

### 4. Full Functionality — Positive-Sum, Not Zero-Sum

Reject the false tradeoff between privacy and functionality. Design for both:

- **Privacy + Security** — Encryption is both a privacy and security measure
- **Privacy + Analytics** — Differential privacy allows aggregate analytics without individual identification
- **Privacy + Personalization** — On-device processing enables personalization without data collection

### 5. End-to-End Security

Privacy depends on security. Full lifecycle protection:

| Stage | Security measure |
|-------|------------------|
| **In transit** | TLS 1.3, mutual TLS, VPN |
| **At rest** | Encryption (AES-256), key rotation, HSM |
| **In use** | Confidential computing, differential privacy |
| **Processing** | Access controls, audit logging, anomaly detection |
| **Deletion** | Cryptographic erasure, secure wipe verification |

### 6. Visibility and Transparency

All stakeholders operate with the knowledge that the system is privacy-assuring:

- **Privacy notice** — Clear, specific, accessible
- **Data flow map** — Where data goes, who touches it, how it's protected
- **Processing records** — Article 30 RoPA (Record of Processing Activities)
- **Incident reporting** — Breach notification process
- **Audit trail** — Log of who accessed what and when

### 7. Respect for User Privacy

User-centric design — keep the individual's interests paramount:

- **Granular consent** — Separate consents for separate purposes
- **Easy exercise of rights** — Access, rectification, erasure, portability
- **Usable privacy controls** — Settings are easy to find and understand
- **User education** — Clear explanations of data practices

## Data Protection Impact Assessment (DPIA)

### When a DPIA is Required (GDPR Art. 35)

A DPIA is mandatory when processing is likely to result in high risk to individuals' rights and freedoms, specifically:

1. Systematic and extensive profiling with significant effects
2. Large-scale processing of special categories of data (health, biometric, genetic)
3. Systematic monitoring of a publicly accessible area on a large scale (CCTV)
4. Other high-risk processing as identified by the supervisory authority

### DPIA Process

```
Step 1: Identify need ──────────────────────────────┐
    │                                                │
    v                                                │
Step 2: Describe processing                         │
    │  (nature, scope, context, purposes)            │
    v                                                │
Step 3: Assess necessity & proportionality           │
    │  (is this the least privacy-invasive way?)      │
    v                                                │
Step 4: Identify and assess risks ───────────────────┤
    │  (likelihood × severity for each risk)          │
    v                                                │
Step 5: Identify mitigations ────────────────────────┤
    │  (reduce risk to acceptable level)              │
    v                                                │
Step 6: Document, sign off, integrate                │
    │  (record decision, obtain approval, implement)  │
    v                                                │
Step 7: Review                                        │
    (periodic review — update if processing changes) │
```

### DPIA Risk Matrix

| Likelihood \ Severity | Low | Medium | High |
|-----------------------|-----|--------|------|
| **High** | Medium risk | High risk | Critical |
| **Medium** | Low risk | Medium risk | High risk |
| **Low** | Low risk | Low risk | Medium risk |

**Response by risk level:**
- **Critical** — Processing cannot proceed as described. Redesign or abandon.
- **High** — Implement additional mitigations. Consult DPO/supervisory authority if mitigations cannot reduce to acceptable level.
- **Medium** — Mitigate; standard controls are sufficient.
- **Low** — Document and proceed.

## Data Mapping (Record of Processing Activities — RoPA)

### Required Under GDPR Article 30

| Field | Description |
|-------|-------------|
| **Controller/Processor** | Name and contact details of each |
| **Purposes of processing** | Why this data is processed |
| **Categories of data subjects** | Whose data (employees, customers, website visitors) |
| **Categories of personal data** | What data (name, email, health data, location) |
| **Categories of recipients** | Who receives it (processors, third parties, authorities) |
| **Transfers to third countries** | Any cross-border data flows and safeguard mechanism |
| **Retention periods** | How long data is kept |
| **Technical/organizational measures** | Security measures applied |

### Data Mapping Methodology

1. **Inventory data collection points** — Every system, form, API, integration, and manual process
2. **Map data flows** — From collection through processing, storage, sharing, to deletion
3. **Identify data elements** — What specific personal data is involved
4. **Classify by sensitivity** — Regular vs special category vs sensitive
5. **Assess legal basis** — What lawful basis applies to each processing purpose
6. **Document retention** — How long each data element is retained
7. **Review periodically** — Annual or on significant process change

## Breach Response

### The 72-Hour Notification Clock (GDPR Art. 33)

```
Breach detected
    │
    v
T+0 hours: Contain and assess
    ├── Isolate affected systems
    ├── Preserve evidence / logs
    ├── Determine scope (what data, who is affected)
    └── Assign breach response lead
    │
    v
T+24 hours: Notify internal stakeholders
    ├── Legal counsel
    ├── Security team
    ├── DPO
    ├── Comms / PR
    └── Executive team
    │
    v
T+48 hours: File (if required) – draft notification
    ├── Likelihood of risk to individuals?
    ├── Categories and approximate number of data subjects
    ├── Categories and approximate number of records
    ├── Likely consequences of the breach
    └── Measures taken or proposed to address the breach
    │
    v
T+72 hours: Submit notification to supervisory authority
    ├── Notify affected individuals (if high risk)
    └── Begin post-mortem
```

**Not required to notify if:**
- Data was encrypted (and key was not compromised)
- Breach is unlikely to result in risk to rights and freedoms
- Affected data was pseudonymized and cannot be re-associated

### Breach Notification Contents (GDPR Art. 33(3))

1. Description of the nature of the breach
2. Categories and approximate number of data subjects concerned
3. Categories and approximate number of personal data records concerned
4. Name and contact details of the DPO or other contact point
5. Likely consequences of the breach
6. Measures taken or proposed to address the breach

## Vendor Privacy Assessment

### Pre-Engagement Checklist

- [ ] Does vendor process personal data on our behalf?
- [ ] Is a DPA/Data Processing Agreement in place?
- [ ] Does vendor have ISO 27001, SOC 2 Type II certification?
- [ ] Is vendor's sub-processor list current and acceptable?
- [ ] What is vendor's breach notification timeline? (GDPR requires 72h — the same requirement flows down)
- [ ] Where is data physically stored? (Jurisdiction matters for transfers)
- [ ] Does vendor have a published data retention and deletion policy?
- [ ] Is vendor's liability cap sufficient for the data risk?
- [ ] What audit rights do we have?
- [ ] Does the contract survive a change-of-control at the vendor?

# Legal Strategy Decision Workflow

This is a structured issue-spotting and escalation method, not legal advice. A licensed lawyer or qualified local counsel must review jurisdiction-specific conclusions before reliance or action.

## Repeatable Method

1. **Frame inputs:** jurisdictions, entities, data/users, product behavior, contract text, dates, business objective, and known facts versus assumptions.
2. **Issue-spot:** identify applicable regimes, rights/obligations, trigger facts, conflicts, uncertainty, and potential harm. Cite primary sources or counsel questions; do not state an unverified conclusion as law.
3. **Triage:** classify impact and urgency (low/medium/high/critical), identify a reversible interim control, and escalate high-impact, novel, regulated, cross-border, dispute, employment, or filing matters to counsel.
4. **Validate:** counsel confirms interpretation, owner, deadline, control, and evidence. Revisit when jurisdiction, product, vendor, or law changes.
5. **Package evidence:** produce a dated jurisdictional risk/escalation memo with sources, assumptions, open questions, counsel disposition, and review date. Use `artifact-pyramids` for the evidence index.

## Worked Example

A startup plans EU and US rollout of an AI feature that profiles business users. The memo separates known processing facts from assumptions, flags GDPR/AI Act and state privacy questions, rates the cross-border and automated-decision uncertainty high, and pauses launch of profiling until privacy counsel validates lawful basis, notices, transfer controls, and any required assessment. It routes security controls to security owners and records counsel's written disposition; it does not claim that the memo itself determines compliance.

## Reusable Artifact

```text
Jurisdictional risk and escalation memo
Matter / business decision / owner / date / review date
Jurisdictions and facts (known vs assumed):
Potential regimes and trigger facts:
Risk, uncertainty, urgency, reversible interim control:
Questions for licensed counsel:
Counsel disposition / conditions / deadline:
Evidence, decision log, and next review:
```

## Routing Matrix

| Need | Route to | Handoff in / out |
|---|---|---|
| Strategic trade-off | [strategy-frameworks](../../strategy-frameworks/SKILL.md) | Legal constraints in; strategic options out |
| Cost, reserve, or unit economics | [financial-modeling](../../financial-modeling/SKILL.md) | Exposure assumptions in; modeled scenarios out |
| Technical controls or architecture | [technology-radar](../../technology-radar/SKILL.md) | Legal requirement in; feasible controls out |
| Remediation sequencing | [implementation-planning](../../implementation-planning/SKILL.md) | Counsel-approved work in; delivery sequence out |
| Evidence dossier | [artifact-pyramids](../../artifact-pyramids/SKILL.md) | Memo and sources in; durable index out |

Do not invent a Phase 2 legal specialty skill. Escalate to licensed counsel for legal interpretation, filings, advice, or jurisdiction-specific action.

# IP Strategy — Patents, Trademarks, Trade Secrets, and Open Source Licensing

## Patent Strategy

### Types of Patents

| Type | Duration | Subject matter | Example |
|------|----------|----------------|---------|
| **Utility patent** | 20 years from filing | Processes, machines, articles of manufacture, compositions of matter | Software algorithm, hardware device |
| **Design patent** | 15 years (US) | Ornamental design of a functional item | Icon design, product shape |
| **Provisional patent** | 12 months (placeholder) | Establishes priority date, doesn't become a patent automatically | "Patent pending" status |

### Patent Filing Strategy

| Strategy | When to use | Example |
|----------|-------------|---------|
| **Defensive filing** | Core technology you want to protect | Foundational algorithm |
| **Offensive filing** | Blocking competitors in key areas | Patent thicket around a technology domain |
| **Landscape filling** | Identify gaps in competitor portfolios and file there | Adjacent use cases competitors haven't claimed |
| **Standard-essential** | Technology required by an industry standard | 5G, Wi-Fi, video codecs |

### The Patent Process

```
Disclosure → Prior art search → Drafting → Filing → Examination → Grant/Maintenance
                                                                         ↓
                                                                Patent pools / licensing / enforcement
```

**Key decision:** Trade secret vs patent. Patents require public disclosure; trade secrets can last indefinitely. If the technology can be reverse-engineered with moderate effort, patent. If the secret can be kept (Coca-Cola formula, Google PageRank algorithm), consider trade secret.

## Trademark Strategy

### Trademark Types

| Type | Examples | Protection |
|------|----------|------------|
| **Word mark** | "Google," "Apple" | The word itself, in any stylization |
| **Design mark** | Nike swoosh, Apple logo | The visual design |
| **Sound mark** | Intel jingle, MGM lion roar | Sonic brand identity |
| **Trade dress** | Coca-Cola bottle shape, Tiffany blue | Product appearance or packaging |

### Trademark Clearance

Before adopting a mark, conduct:

1. **Screening search** — Internal database, general web search
2. **Full availability search** — USPTO / EUIPO trademark database
3. **Common law search** — Business registries, domain names, social media handles
4. **International search** — Madrid Protocol if filing in multiple jurisdictions

**Risk levels:**
| Finding | Risk | Action |
|---------|------|--------|
| No conflicting marks | Low | Proceed |
| Conflicting mark in different class/geography | Medium | File with careful monitoring |
| Direct conflict with active mark in same class | High | Abandon or acquire |

## Trade Secret Management

### Legal Requirements (US — DTSA / State Law)

A trade secret must:
1. Have **independent economic value** from not being generally known
2. Be subject to **reasonable measures** to maintain secrecy

### Reasonable Secrecy Measures

| Measure | Implementation |
|---------|----------------|
| **Access controls** | Need-to-know basis, role-based permissions, physical locks |
| **NDAs** | Employee, contractor, and partner non-disclosure agreements |
| **Exit procedures** | Return of materials, reminder of ongoing obligations, access revocation |
| **Labeling** | Clearly mark "CONFIDENTIAL — Trade Secret" on documents |
| **Training** | Annual training on trade secret handling |
| **Segmentation** | Compartmentalize — no one person knows the whole secret |
| **Audit trails** | Log access to trade secret repositories |

### Litigation Risks

- **Inevitable disclosure doctrine** — Former employee's new role inevitably requires disclosing trade secrets (injunction available in some jurisdictions)
- **Reverse engineering** — Legal unless prohibited by contract; cannot protect against it with trade secret law alone

## Open Source Licensing

### License Categories

| Category | Examples | Requirements | Commercial implications |
|----------|----------|-------------|------------------------|
| **Permissive** | MIT, Apache 2.0, BSD | Attribution only | Can use in proprietary products |
| **Weak copyleft** | LGPL, MPL, EPL | Modifications to the library itself must be open-sourced | Can link from proprietary code |
| **Strong copyleft** | GPL 2.0/3.0, AGPL | Derivative works must be open-sourced under same license | Usually incompatible with proprietary products |
| **Network copyleft** | AGPL | Software accessed over a network must be distributed with source | Affects SaaS companies |

### Strategic Decisions

| Decision | Consideration |
|----------|--------------|
| **Why open source?** | Community adoption, talent attraction, commoditize complement, standards setting |
| **License choice** | Permissive for maximum adoption; copyleft to prevent proprietary forks |
| **CLA (Contributor License Agreement)** | Required for corporate projects to relicense later |
| **Dual licensing** | Open source (GPL) + commercial license for proprietary users (Qt, MySQL model) |
| **Trademark policy** | Prevent confusion: who can use the project name/logo |

### Open Source Compliance

| Process | Description |
|---------|-------------|
| **SBOM generation** | Software Bill of Materials — list every dependency and its license |
| **License scanning** | Automated tools (FOSSA, Black Duck, Snyk) to detect license obligations |
| **Policy creation** | Approved licenses list, obligation matrix, approval workflow for exceptions |
| **Distribution compliance** | Include license notices, provide source code on request (GPL) |
| **Audit readiness** | Maintain a compliance artifact: notices file, source code archive, obligation log |

## IP Portfolio Management

### The IP Lifecycle

```
Creation → Protection → Maintenance → Monetization
                                      ↓
                                 Licensing / Sale / Enforcement
```

### IP Budget Allocation

| % of Budget | Category | Activity |
|-------------|----------|----------|
| 40-50% | **Defensive core** | Patent filing for core technology, trademark registration |
| 20-30% | **Offensive/IP landscape** | Competitive blocking, freedom-to-operate analysis |
| 15-20% | **Maintenance** | Renewal fees, trademark renewal, portfolio pruning |
| 10-15% | **Enforcement** | Cease-and-desist, licensing negotiations, litigation |

# Regulatory Analysis — GDPR, CCPA, AI Act

## General Data Protection Regulation (GDPR)

### Scope & Applicability

| Aspect | Detail |
|--------|--------|
| **Enforcement** | May 25, 2018 |
| **Territorial scope** | EU establishment; OR targeting/monitoring data subjects in the EU (Article 3) |
| **Material scope** | Personal data processed wholly or partly by automated means (Article 2) |
| **Penalties** | Up to €20M or 4% of global annual turnover, whichever is higher |

### Key Principles (Article 5)

1. **Lawfulness, fairness, transparency** — Must have a lawful basis; be clear about how data is used
2. **Purpose limitation** — Collect for specified, explicit, legitimate purposes; don't repurpose
3. **Data minimization** — Collect only what's necessary for the stated purpose
4. **Accuracy** — Keep data accurate and up to date; rectify inaccuracies
5. **Storage limitation** — Keep only as long as necessary for the purpose
6. **Integrity and confidentiality** — Appropriate security measures
7. **Accountability** — Must be able to demonstrate compliance with all principles

### Lawful Bases for Processing (Article 6)

| Basis | Description | Best for |
|-------|-------------|----------|
| **Consent** | Freely given, specific, informed, unambiguous | Marketing, non-essential cookies |
| **Contract** | Necessary to fulfill a contract with the data subject | Order processing, account management |
| **Legal obligation** | Required by law | Tax reporting, fraud prevention |
| **Vital interests** | Necessary to protect someone's life | Emergency medical data |
| **Public interest** | Official authority or public task | Government services |
| **Legitimate interests** | Balanced against data subject's rights | Analytics, security (not public authorities) |

### Data Subject Rights

| Right | Description | Response timeline |
|-------|-------------|------------------|
| **Right to be informed** | Privacy notice at collection point | At time of collection |
| **Right of access** | Copy of personal data and processing info | 1 month (extendable to 2) |
| **Right to rectification** | Correct inaccurate data | 1 month |
| **Right to erasure** ("Right to be forgotten") | Delete personal data | 1 month (with exceptions) |
| **Right to restrict processing** | Limit how data is used | 1 month |
| **Right to data portability** | Receive data in machine-readable format | 1 month |
| **Right to object** | Object to processing (including profiling/marketing) | Without undue delay |
| **Rights related to automated decision-making** | Not be subject to solely automated decisions with legal effects | N/A |

## California Consumer Privacy Act (CCPA / CPRA)

### Scope

Applies to for-profit businesses that:
- Gross annual revenue >$25M; OR
- Buy, sell, or share personal data of 100,000+ California residents/year; OR
- Derive 50%+ of revenue from selling/sharing personal data

### Consumer Rights

- **Right to know** — Categories and specific pieces of personal data collected, sources, purpose, third parties
- **Right to delete** — Subject to exceptions (complete transaction, security, legal compliance)
- **Right to opt out** — Of sale or sharing of personal data (includes cross-context behavioral advertising)
- **Right to correct** — Inaccurate personal data
- **Right to limit** — Use of sensitive personal data
- **Right to non-discrimination** — No retaliation for exercising rights

## EU AI Act

### Risk Categories

| Category | Examples | Requirements |
|----------|----------|--------------|
| **Unacceptable risk** (banned) | Social scoring, real-time biometric surveillance, manipulative AI | Prohibited entirely |
| **High risk** | Critical infrastructure, education, employment, law enforcement, migration, justice | Conformity assessment, risk management, human oversight, transparency, accuracy, cybersecurity |
| **Limited risk** | Chatbots, AI-generated content | Transparency obligations (disclose AI interaction) |
| **Minimal risk** | AI-enabled video games, spam filters | No additional obligations (voluntary codes of conduct) |

### High-Risk System Requirements

1. **Risk management system** — Continuous, iterative process throughout lifecycle
2. **Data governance** — Training, validation, and testing data must be relevant, representative, and free from biases
3. **Technical documentation** — Design specifications, development methodology, accuracy/robustness benchmarks
4. **Record-keeping** — Automatic logging of events during operation
5. **Transparency** — Clear disclosure to users
6. **Human oversight** — Appropriate for the risk level
7. **Accuracy, robustness, cybersecurity** — Appropriate levels of each

### Penalties

| Violation | Penalty |
|-----------|---------|
| Unacceptable risk practices | €35M or 7% of global annual turnover |
| Non-compliance with high-risk obligations | €15M or 3% of global annual turnover |
| Providing incorrect information | €7.5M or 1% of global annual turnover |

## Sector-Specific Regulations

### Healthcare (US — HIPAA)

- Protected Health Information (PHI) — 18 identifiers
- Privacy Rule — Use/disclosure limits
- Security Rule — Administrative, physical, technical safeguards
- Breach Notification Rule — 60-day notification requirement

### Financial Services (US — SOX, GLBA)

- **SOX** — Internal controls over financial reporting, records retention (7 years), CEO/CFO certification
- **GLBA** — Financial Privacy Rule, Safeguards Rule, Pretexting Protection
- **PCI DSS** — Payment card data security (not law, but contractual requirement)

### Children's Privacy

- **COPPA (US)** — Under 13: verifiable parental consent, privacy policy, data minimization
- **GDPR Art. 8** — Under 16 (varies by member state down to 13): parental consent

## Cross-Border Data Transfers

| Mechanism | GDPR | Notes |
|-----------|------|-------|
| Adequacy decision | EU deems country's protections adequate | UK, Japan, South Korea, others |
| Standard Contractual Clauses (SCCs) | EU Commission-approved contracts | Most common mechanism |
| Binding Corporate Rules (BCRs) | Multi-national group policies | Complex to implement |
| Derogations | Specific situations (consent, contract necessity) | Limited use — not a long-term solution |