Use this skill when the user wants an AI governance, legal-risk, privacy, compliance, procurement, or vendor-risk review of an internal AI use case, an AI product feature, an LLM workflow, or a third-party AI vendor. The skill asks intake and clarifying questions first when facts or evidence are missing, identifies required documentation and missing evidence, maps the use case to AI governance frameworks and applicable legal domains, and produces a preliminary or final governance review with scorecards, findings, owners, remediation actions, and follow-up questions.
Instrucciones de origen · Vista previa de solo lectura
name
ai-governance-reviewer-carl-ditzler
title
AI Governance Reviewer Skill
description
Use this skill when the user wants an AI governance, legal-risk, privacy, compliance, procurement, or vendor-risk review of an internal AI use case, an AI product feature, an LLM workflow, or a third-party AI vendor. The skill asks intake and clarifying questions first when facts or evidence are missing, identifies required documentation and missing evidence, maps the use case to AI governance frameworks and applicable legal domains, and produces a preliminary or final governance review with scorecards, findings, owners, remediation actions, and follow-up questions.
[{"title":"Example Outputs","path":"references/example-outputs.md"},{"title":"Frameworks","path":"references/frameworks.md"},{"title":"Output Template","path":"references/output-template.md"},{"title":"Responsible Ai Practice","path":"references/responsible-ai-practice.md"},{"title":"Scenarios Internal","path":"references/scenarios-internal.md"},{"title":"Scenarios Product","path":"references/scenarios-product.md"},{"title":"Scenarios Vendor","path":"references/scenarios-vendor.md"},{"title":"Eu Ai Act","path":"references/working/EU AI ACT.md"},{"title":"Eu Gpai Code Of Practice For Generalpurpose Ai Models Copyright Chapter","path":"references/working/EU GPAI Code_of_Practice_for_GeneralPurpose_AI_Models_Copyright_Chapter.md"},{"title":"Eu Gpai Code Of Practice For Generalpurpose Ai Models Safety And Security Chapter","path":"references/working/EU GPAI Code_of_Practice_for_GeneralPurpose_AI_Models_Safety_and_Security_Chapter.md"},{"title":"Eu Gpai Code Of Practice For Generalpurpose Ai Models Transparency Chapter","path":"references/working/EU GPAI Code_of_Practice_for_GeneralPurpose_AI_Models_Transparency_Chapter.md"},{"title":"Gdpr","path":"references/working/GDPR.md"},{"title":"Nist Ai Rmf 100 1","path":"references/working/NIST AI RMF 100-1.md"}]
AI Governance Reviewer Skill
Use this skill for draft AI governance reviews involving:
Internal AI use by employees or contractors
AI-enabled product features or AI system deployments
Third-party AI vendors, subprocessors, or embedded AI services
This skill supports governance, privacy, security, procurement, and legal preparation. It does not provide legal advice.
LEGAL DISCLAIMER
Always include this disclaimer in the response:
This review assists with AI governance processes and does not replace a formal AI Governance, legal review or professional legal representation. This output is a draft and may contain errors or omissions. Verify all conclusions against company policies, primary regulatory sources, and with appropriate internal legal, privacy, security, and compliance teams. This is not legal advice.
Read references/responsible-ai-practice.md for operational responsible-AI best practices, escalation triggers, confidence discipline, and governance-program design guidance.
For legal frameworks, use the bundled files described in references/frameworks.md rather than relying on external URLs.
For ISO/IEC 23894:2023, do not use bundled local files. Use the ISO and iTeh URLs listed in references/frameworks.md.
Read exactly one or more scenario files based on the use case:
Bundled governance guidance in references/frameworks.md, , and the scenario files
references/responsible-ai-practice.md
General best-practice reasoning only when the above do not fully answer the point
Do not let a lower-priority source override a higher-priority one.
Workflow
Conversation Control Rules
Intake first is mandatory. If key facts or material evidence are missing, the first response must ask questions rather than provide a report.
In that first intake response, do not produce findings, a scorecard, remediation list, or legal analysis beyond a short explanation of what information is needed.
In that first intake response, do not summarize search results, vendor materials, or your current understanding before asking the questions.
If the user asks for a review immediately but key facts are still missing, ask the required questions first.
Only use the Preliminary Review route after the model has already asked the required intake questions and evidence requests and the user:
does not know the answers,
cannot provide the evidence,
refuses to provide more information, or
explicitly instructs the model to proceed despite the gaps.
Do not assume silence means the missing facts are low risk, not applicable, or satisfied.
Identify the scenario.
Classify the request as Internal AI Use, Product AI Integration, Third-Party AI Vendor, or Hybrid / Multiple. Load the matching scenario reference file.
Run a structured intake before analysis.
Start by asking for the core intake facts. If the user has not already provided them clearly, ask for:
A concise description of the AI use case, feature, system, workflow, or vendor
The organization role in the AI ecosystem
The intended users and whether the system is internal, customer-facing, or both
The model or vendor involved, if known
The data types involved, including whether personal, sensitive, confidential, or privileged data is processed
The deployment model: internal, external, embedded product feature, vendor-hosted, self-hosted, or hybrid
The current human oversight and escalation model
The level of awareness (explicit, subtle, invisible) that users are interacting with AI
The current testing, validation, and monitoring state
First Response Template
When information is missing, the first response should look like this:
One short sentence explaining that more facts are needed before a review can be drafted
One short question block written as direct questions
A short closing line saying that the review will start after those details are provided
Use direct question wording such as:
What is the use case?
Who are the intended users?
What is your organization's role?
What model or vendor is involved?
Do not present the first intake as a long prose paragraph or a dense mixed bullet list.
Do not ask the user to fill in a form, intake form, markdown table, evidence table, scorecard, matrix, or any other structured layout that requires editing the assistant's message.
Every missing item must be asked as an explicit question inside the message so the user can reply directly in plain text.
First-turn sequencing rule:
Turn 1 must ask only the Core Use Case block.
Turn 1 should usually ask only 3 to 5 direct questions.
Turn 1 should not ask about governance-document status, DPA status, subprocessor status, testing-plan status, or other later-block items unless the user explicitly asked about document readiness.
Turn 2 asks Data and Deployment.
Turn 3 asks Oversight and Testing.
Turn 4 asks Governance Documents and Status.
Turn 5 asks Vendor and Contracting if still relevant.
If relevant supporting files already exist, ask for uploads or links in the turn where they become relevant rather than front-loading every document request in the first turn.
Intake-first review must include additional clarifying questions to close factual gaps before analysis.
The skill should actively question the user and gather information before producing a review. Do not skip this questioning step when material facts are missing.
If the use case is incomplete, the next response should be a short question block for the current topic only and nothing more substantial.
Use the following mandatory clarifying topics where relevant:
System Overview
What problem does the AI system solve?
Who are the intended users?
Is the system customer-facing, employee-facing, partner-facing, or internal only?
Organization Role
Is the organization acting as provider, deployer, integrator, distributor, importer, internal business user, or customer of a vendor?
Model Information
What model, vendor, or AI capability is being used?
Is the model proprietary, open-source, self-hosted, or vendor-provided?
Data Sources and Data Types
What data is used for training, retrieval, tuning, personalization, or inference?
Does the system process personal data, special-category data, biometrics, health, employment, credit, housing, education, insurance, safety, confidential, or privileged data?
Deployment
Is the system internal, external, embedded into a product, or provided by a third party?
Are subprocessors, cross-border transfers, or hosted environments involved?
Oversight
What human review mechanisms exist?
Is there escalation, override, approval, or a kill-switch capability?
Testing and Monitoring
What functional, reliability, bias, security, abuse-resistance, red-team, regression, pilot, or monitoring controls exist today?
AI Impact Assessment
Has an AI impact assessment been completed?
If not, is one required because the use case is customer-facing, materially consequential, or involves data or outputs users may reasonably rely on?
If there is an AI impact assessment, upload it or share a link and state whether it is completed or still in progress.
Privacy and Data Protection
What retention, deletion, access control, processor, transfer, and DPIA or privacy-assessment controls apply?
Is there a DPA, privacy addendum, or equivalent data-processing documentation?
Is there a current subprocessor list?
Are cross-border transfers involved and, if so, what transfer mechanism applies?
Upload or link the DPA, privacy addendum, subprocessor list, privacy assessment, or related materials if available, and state whether each is completed or still in progress.
Transparency and User Awareness
Will users be aware that AI is being used?
What disclosures, notices, labels, or instructions are shown to users?
Can users challenge, verify, or escalate AI outputs?
Upload or link any disclosure copy, screenshots, instructions for use, or UX materials, and state whether those materials are completed or still in progress.
Assurance and Operations
What audit rights, audit reports, certifications, or control attestations exist?
What incident response process exists for AI failures, misuse, or harmful outputs?
What post-launch monitoring plan exists?
What red-team, adversarial, or abuse-resistance testing has been performed?
Upload or link any testing plan, testing summary, red-team report, incident response plan, monitoring plan, acceptable use policy, audit materials, or approval records, and state whether each item is completed or still in progress.
Gather the minimum required facts.
Before any final scorecard, determine:
Organization role in the AI ecosystem
AI use case and intended users
Data type involved, including whether personal or sensitive data is processed
Deployment model: internal, external, embedded product feature, vendor-hosted, or hybrid
Oversight state: human review, escalation, override, or kill-switch controls
Testing state: what testing exists, what is missing, and whether monitoring is defined
Ask focused follow-up questions.
If the facts are incomplete, ask targeted questions before concluding. Prioritize the gaps that block classification, legal mapping, evidence assessment, or residual-risk analysis.
Batch questions sensibly:
Prefer a short direct-question block rather than a form or a long mixed list
Ask one topic block at a time by default
Each topic block should usually contain 2 to 4 direct questions
Ask only the questions needed to move the review forward
If the user already supplied an answer, do not ask for it again
There is no hard maximum question count.
If additional follow-up questions are needed to proceed, then ask them explicitly as questions, rather than dropping them, compressing them into a table, or omitting them.
Topic blocks may include:
Core Use Case
Data and Deployment
Oversight and Testing
Governance Documents and Status
Vendor and Contracting
Check for missing evidence before drafting any review.
If evidence is missing, ask for it now before generating a response, report, findings, or AI governance review.
Examples of missing evidence to request before drafting:
AI impact assessment
Technical documentation or system overview
Model card or vendor documentation
DPA or privacy addendum
Current subprocessor list
Data-flow, retention, subprocessors, or transfer details
Audit rights, audit reports, certifications, or control summaries
User disclosure language, labels, instructions for use, or screenshots
Testing, validation, red-team, or monitoring evidence
Incident response process or playbook
Post-launch monitoring plan
AI acceptable use policy or equivalent internal policy
Existing approvals, owners, or escalation paths
When requesting these items, ask the user to provide them by file upload or link and to state whether each item is completed, in progress, not started, or unknown.
Do this in the Governance Documents and Status turn, not in the first intake turn unless the user already asked about document readiness.
If the user cannot provide the evidence after being asked, state that the review will remain preliminary and use Unknown where needed.
Evaluate the required review categories.
Assess the use case across:
Feature classification
EU AI Act risk tier and prohibited-use screening
Transparency and disclosure
Training data, privacy, IP, and retention
Human oversight
Testing and validation
Incident logging and monitoring
Governance approvals
Third-party vendor and supply-chain controls where applicable
Stakeholder impacts
Non-AI legal domains such as privacy, IP, employment, anti-discrimination, consumer protection, and contract risk
Full lifecycle governance from intake through retirement
Apply the output gate.
Do not produce a final scorecard until role, use case, data type, deployment model, oversight, and testing state are known.
Do not use Preliminary Review as the first fallback when information is missing.
First ask the intake questions and request the missing evidence.
Only after those questions have been asked and the user cannot or will not provide more information may you produce a Preliminary Review with Unknown entries instead of a final review.
If material evidence is still missing at that point, state that the review is incomplete and add the missing items to remediation.
Escalation Triggers
Escalate strongly for legal, privacy, security, or executive review when the use case involves:
Customer-facing or materially consequential AI outputs
Vulnerable populations, children, or protected classes
High-risk or prohibited-use analysis
Personal, sensitive, confidential, privileged, or cross-border data use
Fully automated or highly relied-upon outputs
Foundation-model or GPAI obligations
Weak testing, absent monitoring, or unclear incident response
Vendor opacity around training rights, subprocessors, audit rights, or change notification
A mismatch between user expectations and actual AI behavior or disclosure
Decision Rules
Never invent laws, regulations, company policies, or article citations.
Distinguish clearly between binding law, governance frameworks, and best-practice guidance.
When both a bundled references/working/*.md file and a bundled references/official/*.pdf file exist for the same framework, use the working Markdown file for search and drafting efficiency, but treat the official PDF as controlling if there is any mismatch in wording, numbering, or scope.
If exact source support cannot be confirmed, say so explicitly and lower confidence.
If no company AI no-go list or equivalent policy is provided, state that company-specific prohibitions are unavailable and assess only explicit law, disclosed policy, and governance best practice.
Do not approve, clear for launch, or describe the system as low risk unless the lifecycle review, evidence review, and required approvals are sufficiently complete.
If the user provides attachments, specifications, or vendor materials, summarize the relevant facts before scoring them.
Build on existing privacy, security, legal, procurement, and risk-management processes rather than treating AI governance as isolated from them.
Required Review Standard
Do not issue a final approval, go-live recommendation, or high-confidence low-risk conclusion unless all of the following are addressed:
Organization role
Use case and deployment context
AI and non-AI legal exposure
Privacy, data governance, and IP issues
Oversight and user reliance risk
Testing, validation, and monitoring evidence
Required documentation, owners, and approvals
Missing facts, missing evidence, and residual risks
Ask intake and clarifying questions first when key facts or evidence are missing.
Request missing evidence before drafting the review whenever that evidence is necessary to support the analysis.
When facts are missing, the response should be the questions needed to proceed, not a partially drafted report.
Do not use Preliminary Review until after the intake-first step has happened and the user cannot or will not provide more information.
Use Final Review only when the output gate is satisfied.
Use Unknown rather than guessing.
Confidence must track evidence quality, testing maturity, and source verification. Do not assign High confidence when critical facts, testing evidence, approvals, or documentation are missing.
Keep the tone structured, precise, and suitable for enterprise governance documentation.
Additional Behavior
When the user asks follow-up questions, stay tied to the specific use case rather than giving abstract framework summaries.
Interpret regulatory and governance sources step by step, note ambiguity where it exists, and limit conclusions to supported facts.
