Use when a new or modified AI/ML use case needs to be documented and triaged so legal, compliance, and governance teams can assess risk and route it to the right specialists.
When to use
A product, engineering, or business team is proposing a new AI or ML feature, product, or workflow and needs legal sign-off or triage.
An existing AI use case is being materially changed (new model, new data, new affected population, new market).
Legal or compliance has received a question like "is this AI thing okay?" and needs a structured starting point.
A governance or AI review committee requires a standardized intake record before approving a use case.
A vendor is proposing an AI-enabled product or service and the organization must assess it before contracting.
Required inputs
Use case description: A plain-language description of what the AI system does and why, provided by the requester.
AI system or model details: The specific model(s), provider(s), or platform(s) involved (e.g., OpenAI GPT-4o via API, AWS SageMaker custom model, Microsoft Copilot).
Input data description: What data goes into the model — sources, types, whether it includes personal data, and any sensitivity classifications.
Output description: What the system produces and how outputs are used or acted upon.
Affected persons: Who is impacted by the system's outputs (employees, consumers, job applicants, patients, students, etc.).
Deployment markets: Countries and states or regions where the use case will operate.
If any required input is missing, stop and request it from the requester. Do not fabricate or assume facts about the system, data, or affected individuals.
Use when reviewing the terms of service, API agreement, or usage policies of an AI vendor or AI-enabled service to produce a structured risk summary and prioritized redline points for attorney review.
When to use
A team wants to adopt a new AI API, AI platform, or AI-enabled SaaS product and needs the legal terms reviewed.
An existing AI vendor agreement is up for renewal or the vendor has pushed updated terms.
A user asks "what are we giving up by signing this?" or "does this vendor own what we generate?"
Legal has received a vendor-side paper AI agreement and needs a structured risk review.
A vendor's acceptable use policy or model card terms need review before integration.
Required inputs
Vendor agreement text: The full text of the terms of service, API agreement, data processing agreement, and/or acceptable use policy — uploaded or pasted. Identify which document(s) are provided.
Client's intended use: A plain-language description of what the organization plans to do with the vendor's AI system (e.g., generate customer-facing marketing copy, process employee HR queries, analyze legal documents).
Client's role: Whether the organization is an API consumer, enterprise licensee, reseller, or end user.
Data the client will input: The types of data the client will send to the vendor's system — including whether it includes personal data, confidential business information, or privileged material.
Privileged or work-product material: Whether the client intends to input or has historically input material protected by attorney-client privilege or attorney work-product doctrine (drafts of legal memos, analyses for counsel, litigation strategy, etc.). If yes, note the matter context and the governing privilege jurisdiction.
Optional: the practice group's practice-profiles/ai-governance.md if it has been populated and is loaded alongside this skill. If present, the skill uses its Standard Positions and Escalation Thresholds tables to benchmark the output and to gate escalation. If absent, the skill proceeds without practice-profile benchmarking and asks the user to supply standing positions inline if needed.
If the vendor agreement text is not provided, stop and request it. Do not fabricate, paraphrase, or assume contract terms.
Use when reviewing a draft internal employee AI-use policy — or drafting review criteria when no policy exists — to identify gaps, inconsistencies, and priority issues for attorney and HR review.
When to use
An organization has a draft AI-use policy for employees and wants it reviewed before publication.
Legal, HR, or compliance has been asked "do we have what we need in our AI policy?" or "what should our AI policy cover?"
An existing AI policy needs to be updated because new AI tools have been adopted or applicable law has changed.
An incident (data leak, confidentiality breach via AI tool, IP dispute) has prompted a policy review.
A user asks "what should employees be allowed to do with AI tools?" or "how do we handle employees using generative AI tools for work?"
Required inputs
Policy text (if one exists): The full text of the current or draft employee AI-use policy, uploaded or pasted.
Organization context: A brief description of the organization's industry, approximate size, and the types of AI tools employees are currently using or are likely to use.
Jurisdictions: The countries and states or provinces where employees are located — employment law is jurisdiction-specific and the review will flag where jurisdiction-specific legal input is needed.
Optional: the practice group's practice-profiles/ai-governance.md if it has been populated and is loaded alongside this skill. If present, the skill uses its Standard Positions and Escalation Thresholds tables to benchmark the output and to gate escalation. If absent, the skill proceeds without practice-profile benchmarking and asks the user to supply standing positions inline if needed.
If no policy text is provided, the skill will produce a gap analysis based on the topics a policy should address. Note clearly that this is a gap analysis and not a policy review.
If the organization context and jurisdictions are not provided, stop and request them. Employment law varies materially by jurisdiction and industry; do not assume.
Use when triaging the legal and governance risk of a specific AI model or AI system before or during deployment, to produce a structured risk register and recommended controls for attorney and governance review.
When to use
Engineering, product, or legal teams need to assess a specific model before integration or deployment.
A governance committee requires a pre-deployment risk assessment for an AI model.
A model is being upgraded, retrained, or replaced and a delta risk assessment is needed.
An audit, incident, or regulatory inquiry requires documentation of what risk assessment was performed before deployment.
A user asks "what are the risks of using this model?" or "what do we need to have in place before we deploy this?"
Required inputs
Model identification: Name, version, provider or source (vendor API, open-source repository, internally trained), and a link to model documentation or model card if available.
Intended use description: How the organization plans to use the model — inputs, outputs, and the decision or action outputs will inform or automate.
Affected individuals: Who will be impacted by the model's outputs (employees, consumers, patients, job applicants, etc.) and the estimated population size or scope.
Deployment context: The application, product, or system the model will be embedded in, and whether outputs will be directly user-facing.
Available technical documentation: Model card, data sheet, evaluation reports, accuracy benchmarks, bias evaluation results — whatever is available. Note what is not available.
If the model identification and intended use are not provided, stop and request them. Do not fabricate technical facts, benchmark results, or model characteristics. If documentation is not available, flag the gap explicitly.