ai-control-audit
/ai-control-audit
⚠️ Not legal advice. Not a certification opinion. This output is a technical control audit produced by a product-organization skill as a drafting and triage aid for architecture, AI governance, and compliance review. It is NOT legal advice, NOT a certification attestation, and NOT a substitute for licensed counsel, external auditor engagement, or regulator dialogue. No attorney-client relationship is created by its production or use. Jurisdiction-specific questions, contested matters, and any decision with material legal, regulatory, safety, or commercial consequences require review by a licensed attorney in the relevant jurisdiction AND by qualified AI governance leadership. Do not rely on this output as the sole basis for any deployment, release, legal, or compliance decision.
Jurisdiction Assumed:
{jurisdiction — e.g., "U.S. federal + EU (AI Act + GDPR) + UK"}. If the system targets other jurisdictions, treat every finding as a hypothesis to verify with local counsel and in-jurisdiction AI governance reviewers.
Purpose
/ai-control-audit produces a per-release technical control audit of a specific AI system across six categories: model provenance, pre-deployment evaluation, runtime guardrails, observability, incident response, and change management. For each category the skill names the controls expected, checks whether those controls are present, and — critically — names the enforcement point for each control (CI check, deploy gate, runtime assertion, runbook, or evidence artifact). Controls without named enforcement points are explicitly flagged as gap. The skill produces a release-gate recommendation (SHIP / SHIP WITH REMEDIATION / DO NOT SHIP) with remediation priority ordered by risk.
The technical-vs-regulatory distinction is load-bearing. Technical controls are about whether the AI system is built and operated according to stated design — does it have version pinning, eval harnesses, runtime guardrails, logging pipelines, rollback triggers, change approval? Regulatory obligations are about whether the system satisfies the law in its jurisdiction — does it meet EU AI Act Article 15, GDPR Article 22, NIST AI RMF MEASURE? The two overlap through the control-to-obligation mapping maintained in the compliance-frameworks knowledge pack, but they audit different things. An AI system can implement every technical control perfectly and still have regulatory gaps (because the jurisdiction's framework imposes obligations the technical controls don't cover). Conversely, a system can be regulatorily "aligned" on paper and still fail technically (because the stated controls have no enforcement point and drift unchecked). This skill audits the technical side. Its sibling /ai-regulatory-audit (C1.2b) audits the regulatory side. The control-to-obligation mapping is the bridge.
/ai-control-audit is a drafting and triage aid, not a certification opinion. Every finding is a hypothesis grounded in specific architecture documents, deployment artifacts, and observability telemetry, for a human (AI Architect + Security Architect + Compliance Officer + General Counsel where obligations are in scope) to verify.