AI Development & Deployment Governance Framework

Minimum required content:

• • Detailed system description (what it does, how it works)
• • Use case and decision-making role (advisory vs. fully automated)
• • Data sources and training data description
• • Reasonably foreseeable risks of harm (bias, errors, misuse)
• • Risk mitigation measures implemented
• • Affected demographic groups and disparate impact analysis
• • Human oversight mechanisms

Template: Colorado requires this for high-risk AI by 2026. EU AI Act Article 27 requires similar.

Required testing:

• • Disparate impact analysis by race, gender, age (if data available)
• • Selection rate ratios or impact ratios (NYC: must publish)
• • Confusion matrix metrics (false positive/negative rates by group)
• • Statistical significance testing
• • Audit date, methodology, sample size documented

Frequency:

• • NYC Local Law 144: Annual audit for hiring tools
• • EU AI Act: Audit before deployment + when substantial modifications made
• • Best practice: Annually or when performance degrades

NYC requires publishing summary statistics. EU requires audit trail documentation.

EU AI Act Annex IV requirements:

• • System architecture and design specs
• • Training data description (sources, labeling, preprocessing)
• • Training methodology and hyperparameters
• • Model performance metrics (accuracy, precision, recall)
• • Validation and testing results
• • Known limitations and failure modes
• • Cybersecurity measures
• • Change log and version control

Retention:

EU: 10 years after system placed on market. US: Varies by sector (often 3-7 years).

Model card sections (based on Mitchell et al. framework):

• • Model details (version, type, authors, license)
• • Intended use (primary use cases, out-of-scope uses)
• • Factors (relevant groups, environmental conditions)
• • Metrics (performance measures used)
• • Training data (size, composition, preprocessing)
• • Evaluation data (test set description, demographics if relevant)
• • Quantitative analyses (performance by subgroup)
• • Ethical considerations (fairness, privacy, security)
• • Caveats and recommendations (known limitations)

Template available at modelcards.withgoogle.com. Not legally required but considered best practice.

Acceptable oversight models:

• • Human-in-the-loop: Human approves each decision before execution
• • Human-on-the-loop: Human monitors system and can intervene
• • Human-in-command: Human can override or shut down system

Documentation required:

• • Which oversight model is used and why
• • Who has oversight authority (roles, training requirements)
• • Intervention triggers and escalation procedures
• • Interface design for human reviewers

What to log:

• • Input data for each decision (or representative sample)
• • Model output and confidence scores
• • Timestamp and system version used
• • User or system that invoked the model
• • Human override events (if applicable)
• • Errors, exceptions, and edge cases

Retention and access:

• • Logs retained per regulation (typically 3-10 years)
• • Accessible to auditors and regulators on request
• • Protected from tampering (append-only, cryptographic signing)

Required disclosures:

• • Clear notice that AI is making or assisting with decisions
• • Purpose and general logic of the AI system
• • Right to contest or request human review (where applicable)
• • Contact for questions or complaints

Example (NYC hiring tool):

"This employer uses an automated employment decision tool (AEDT) to assist in hiring decisions. The tool analyzes resume keywords and scores candidates based on relevance to the job description. An independent bias audit was conducted on [date]. You have the right to request an alternative selection process or accommodation. For questions, contact [email]."

Monitoring plan must include:

• • Performance metrics tracked (accuracy, error rates)
• • Drift detection (data drift, concept drift monitoring)
• • Bias metrics tracked over time (same as initial audit)
• • Incident reporting procedures (what triggers investigation)
• • Review cadence (monthly, quarterly, or trigger-based)
• • Responsible team and escalation path

Trigger for re-audit:

• • Statistically significant performance degradation
• • User complaints exceed threshold
• • Substantial modification to model or data
• • Annual review (per NYC Law 144 or internal policy)