Aia Generation

/aia-generation

1. Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. Confirm impact assessment house style is populated.
2. Determine risk track (fast or full) from governance tier and use case characteristics, using the framework below.
3. Run intake — conversational, not a form.
4. Regulatory classification for each regime in the footprint — research tier, prohibited-practice exposure, and applicable obligations; cite primary sources.
5. Write assessment in house style (from seed doc, or default if none captured).
6. Policy diff against ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md AI policy commitments.
7. Output: assessment doc + conditions list + handoff flags (privacy PIA, vendor review if needed).

/ai-governance-legal:aia-generation "AI résumé screening for HR"

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /ai-governance-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

An AI impact assessment is a documented decision, not a form. It answers: what does this AI system do, how does it reach its outputs, who's affected if it's wrong, what's the oversight, and is it okay to deploy. This skill structures that conversation and writes the output in this team's format — the one learned from the seed impact assessment during cold-start.

An AI impact assessment is not the same as a PIA. A PIA asks whether personal data is handled lawfully. An AIA asks whether the AI system is designed and deployed responsibly. They often need to happen in parallel; they're not substitutes.

Load house style

Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → ## Impact assessment house style. That has:

• What triggers an impact assessment at this company
• The structure template extracted from the seed assessment
• Typical depth
• Who signs off

If the seed structure is in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md, use it. The point is that this assessment looks like the other assessments this team produces.

Jurisdictional scope. This assessment applies the regulatory regimes listed in ## Regulatory footprint in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. AI legal rules, risk classifications, and deployment obligations vary materially by jurisdiction and are moving fast. If this system is (or will be) deployed outside that footprint, or if a choice-of-law question is in play, this analysis may not apply as written — re-run or expand the footprint.

Step 0: Is an impact assessment needed?

Check the trigger criteria in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md.

Also check these regardless:

• Does this AI make or materially influence a decision affecting a person (employment, credit, access, pricing, content moderation)?
• Does this AI process personal data about individuals?
• Is this a customer-facing AI system rather than purely internal?
• Does this AI use a third-party model where the company is the deployer?
• Is the use case in the elevated or high governance tier per ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md?

If none of the above and the house trigger isn't met:

"Doesn't look like this needs a full impact assessment. Here's a one-paragraph record for the file explaining why — in case anyone asks later."

Step 1: Risk track

Before intake, determine which track to run. The tier definitions and the fast-track criteria come from ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md (## Use case registry and ## Governance tiers), not from any hardcoded regime-specific framework.

Research the applicable risk classification framework for each regime in the user's regulatory footprint. Many regimes distinguish by risk tier, affected population, and decision consequentiality — research the specific criteria. Note that most regimes treat employee data as personal data and employee monitoring as consequential; don't assume internal-only systems are out of scope.

No silent supplement. If a research query to the configured legal research tool (Westlaw, EUR-Lex, regulator sites, or firm platform) returns few or no results for a regime's risk tiers or triggers, report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [regime / topic]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged [web search — verify] and should be checked against the issuing authority before relying, or (4) flag as unverified and stop. Which would you like?" A lawyer decides whether to accept lower-confidence sources. Source attribution tiering. Tag every citation in the AIA — regulatory text, delegated acts, guidance, standards — with its source. For model-knowledge citations, use one of three tiers rather than a single blanket "verify" tag: - [settled] — stable, well-known statutory and regulatory references unlikely to have changed (e.g., GDPR Art. 22 as a concept, the existence of Regulation (EU) 2024/1689 as the EU AI Act). Still verify before certifying, but lower priority. - [verify] — model-knowledge citations that are real but should be verified: specific delegated / implementing acts, regulator guidance, NYC DCWP rules, Colorado AI Act provisions, harmonized standards, effective dates, EEOC guidance, and anything post-2023. - [verify-pinpoint] — pinpoint citations (specific EU AI Act article numbers, annex references, Colorado AI Act subsections, NYC LL 144 rule sections, sub-paragraph letters) carry the highest fabrication risk and should ALWAYS be verified against a primary source. EU AI Act article numbers in particular shifted during consolidation; every pinpoint cite to the Act should be verified against the Official Journal text. Tool-retrieved citations keep their source tag ([Westlaw], [EUR-Lex], [regulator site], or the MCP tool name); web-search citations remain [web search — verify]; user-supplied citations remain [user provided]. The tiering surfaces the real verification work — a reader who verifies everything verifies nothing. Never strip or collapse the tags. For non-lawyer users, uncertain dates go in a confirm-list, not inline. A [verify] tag on "effective February 1, 2026" reads as "effective February 1, 2026" to a CISO who doesn't know what [verify] means. Read ## Who's using this in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. If Role is Non-lawyer and a date, deadline, phase-in, threshold, or effective-date assertion is uncertain (would carry [verify] or [verify-pinpoint] if inline), replace the inline assertion with "effective date: confirm with counsel" (or "threshold: confirm with counsel", etc.) and collect all uncertain assertions in a final AIA section titled: > Things I'm not certain about — ask your attorney to confirm before relying on this: