eu-ai-act-readiness

# EU AI Act Readiness

Produce operational triage, not a legal opinion. The AI Act changes through amendments, delegated/implementing acts, guidance, standards, and national enforcement practice; verify the law and dates at the start of every assessment.

## Inputs

Collect or state:

- Assessment date, target EU/EEA countries, organization locations, customer/user locations, and where system outputs are used.
- Each AI system/model's purpose, intended use, use-case screen, reasonably foreseeable misuse, lifecycle status, exact system/model versions, launch/change dates, material modifications, and affected people.
- Organization role(s) for each system: provider, deployer, importer, distributor, product manufacturer, authorised representative, or GPAI model provider.
- Model/vendor chain, branding, fine-tuning or substantial modifications, integrations, data sources, and contract allocation.
- Jurisdictions, decision domain, degree of automation, human-oversight design/authority, outputs, transparency interface, monitoring, incidents, complaint/appeal paths, and explicit reassessment triggers.
- Existing risk, quality, privacy, security, accessibility, procurement, recordkeeping, and AI-literacy evidence.

Use the blank [AI system inventory template](assets/ai-system-inventory-template.csv) when no reliable inventory exists.

## Output contract

Return:

1. Assessment date, last-verified legal-source date, jurisdictions, official sources, assumptions, and limitations.
2. An inventory with jurisdiction, system/model version, preliminary EU nexus, operator role, use-case screen, foreseeable misuse, material modifications, automation/oversight, risk-status hypothesis, classification basis/confidence, and reassessment triggers.
3. A gap register mapping provision/topic, applicable milestone, current evidence, gap, priority, owner, target date, and verification method.
4. Separate sections for prohibited-practice escalation, Article 50 transparency, high-risk systems, GPAI models, and broadly applicable governance such as AI literacy.
5. A 30/60/90-day implementation plan plus questions requiring qualified EU counsel or a competent authority.

Use `preliminary`, `potential`, or `counsel review required`; do not label an organization “compliant,” provide a definitive legal classification, or promise regulator acceptance.

## Workflow

### 1. Verify law, jurisdiction, and date

Open [current-law-and-sources.md](references/current-law-and-sources.md), then check the linked EUR-Lex legislation and European Commission/AI Act Service Desk pages for changes since `2026-08-09`. Read Regulation (EU) 2024/1689 together with Regulation (EU) 2026/1744 and any later amendments or consolidated text.

Record the access date and governing language/version. Confirm whether later delegated acts, implementing acts, Commission guidelines, harmonised standards, common specifications, codes, court decisions, or national rules affect the issue. If current official sources cannot be checked, mark the legal timeline stale and stop before making a deadline or classification conclusion.

Determine the relevant EU nexus and role under Articles 2 and 3. Consider EU market placement, EU-based deployment, and outputs used in the EU, as well as exclusions and sector-specific law. Territorial scope and exemptions are legal questions; route uncertainty to counsel.

### 2. Build and structurally check the inventory

Create one record per materially distinct system/model/use. Run the bundled completeness checker from this skill directory:

```bash
python3 scripts/check_ai_inventory.py assets/ai-system-inventory-template.csv --as-of 2026-08-09 --pretty
python3 scripts/check_ai_inventory.py /path/to/populated-inventory.csv --as-of YYYY-MM-DD --pretty
python3 scripts/check_ai_inventory.py /path/to/populated-inventory.csv --as-of YYYY-MM-DD --output /path/to/check.json --pretty
```

The checker uses standard-library heuristics, emits no legal classification, and labels its output `structural/completeness screening only—not semantic fact verification or legal verification`. It reports system IDs, missing fields, invalid controlled-vocabulary values, date issues, age/event status, and keyword-derived signals; it does not copy other source row values. With `--output`, it refuses inventory aliases and non-regular destinations, then atomically creates or replaces the report via a sibling temporary file. Use its controlled values for `article_50_status` and `counsel_status`; manually verify every source fact and signal. Include shadow AI, pilots, employee tools, vendor features, embedded models, legacy systems, and retired systems with continuing effects.

The default 365-day staleness flag is an administrative prompt, not a statutory deadline. Reassess sooner whenever a recorded trigger occurs, including a new use, system/model version, vendor, geography, role, material modification, incident, or legal update. A recent assessment can therefore still be due immediately.

### 3. Screen urgent exclusions and prohibited practices

First confirm whether the item is an AI system or GPAI model within the Act's definitions. Screen intended use and foreseeable operation against Article 5, including amendments. If a potential prohibited practice appears, stop routine scoring, preserve evidence, recommend a pause on deployment/expansion, and escalate to qualified counsel and the accountable owner. Do not pause or alter a live system unless the agent has explicit authority to do so. Do not attempt to redesign or conceal the use to evade scope.

Separately identify employment, education, biometrics, critical infrastructure, essential services, law enforcement, migration/border, justice, elections, health/safety, minors, and vulnerable-person contexts. These are escalation signals, not automatic classifications.

### 4. Determine role and preliminary risk path

For each system, document the facts supporting:

- Out of scope or an exclusion, with th