Run an AI impact assessment — structured intake, risk analysis, regulatory classification per regime in scope, policy consistency diff, and recommendation with conditions. Uses the house-style structure learned from the seed impact assessment in `~/.claude/plugins/config/claude-for-legal/ai-governan

/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). 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: List each uncertain item there with (1) what I said, (2) what I'm uncertain about, (3) why it matters to the assessment. This prevents a non lawyer reader from mistaking a flagged best guess for a checked fact. Lawyer role users get the inline [verify] treatment — they know what the tag means. Fast track vs. full assessment: ~/.claude/plugins/config/claude for legal/ai governance legal/CLAUDE.md defines what qualifies for abbreviated treatment. If ~/.claude/plugins/config/claude for legal/ai governance legal/CLAUDE.md doesn't define fast track criteria, default to full assessment and ask the user what criteria they want captured for next time. If in doubt, run the full assessment. A fast track that turns out to be wrong is worse than a thorough assessment on something low risk. Step 2: Intake Before writing anything, get answers to these. Conversational is fine — this is not a form to send them. The system What does the AI do? Describe it in plain language, not marketing copy. Which model or vendor is powering it? Fine tuned or off the shelf? Where does it sit in the workflow — is it assistive (human reviews output), augmentative (human can override but usually doesn't), or automated (no human in the loop)? What's the output — generated text, a score, a classification, a recommendation, an action? Who's affected Who does the AI's output act on — employees, customers, third parties? If the AI produces an error (false positive, false negative, hallucination), who bears the harm and what's the worst realistic case? Are any vulnerable groups disproportionately in scope — minors, job applicants, people in financial distress, patients? Inputs and data What data does the AI take in? Does it take in personal data? Whose? Was the model trained on data from this company, or is it a foundation model with no company specific training? Where does input data go — does it leave the perimeter to a third party model API? Decisions and oversight Does the AI output trigger an action automatically, or does a human decide what to do with the output? If there's human review: how often does the human actually change the AI's output? (If the answer is "rarely" — the human isn't really reviewing; they're rubber stamping.) Is there an appeals or correction process for people affected by the AI's outputs? Who is accountable for the AI system's outputs — is there a named owner? Accuracy and failure What's the known or estimated error rate? What testing has been done? What happens when the AI is wrong — is the error surfaced, logged, corrected? Has bias testing been done? Against what demographic groups? Deployment stage and scale Ask: Stage: "Is this system (a) proposed and not yet built, (b) in pilot, (c) live in production, or (d) live and scaled?" Scale: "Roughly how many individuals are affected per [month/year]? How long has it been running?" History: "Has it been assessed before? Has it produced decisions that were challenged, appealed, or reversed?" Stage changes the assessment: a proposed system gets a design review (can we build it safely?). A pilot gets a design review plus a "before you scale" gate. A live system gets a retrospective impact check (has it caused harm?) AND a go forward review. A live and scaled system gets all of the above plus a remediation plan if issues are found, because you can't just turn it off. Step 3: Regulatory classification Step 3 pre check — footprint freshness. Before iterating over the captured Regulatory footprint , compare the use case's affected population and decision type (from Step 2) against the footprint as written. The footprint was set at cold start, based on the company's operating posture at that moment. If the use case introduces an affected population (e.g., children, employees in a new state, EU data subjects) or a decision type (e.g., hiring, creditworthiness, health diagnosis, law enforcement, critical infrastructure) that the footprint does not contemplate, re derive the applicable regimes rather than iterating over the stale list. Say to the user: "The practice profile's regulatory footprint was set for [affected populations / decision types captured at cold start]. This use case affects [new population or decision type

aia-generation