Framework

AI Governance Framework

Consulting deliverable template | Version 1.0 | Tap Innovations LLC

✦ Framework Origin
This framework is based on the operational governance model used by Tap Innovations LLC to run the APEX platform in production. It is not theoretical — it governs a live, multi-tenant AI system serving AWS partners today. It is adapted per engagement to the customer's organizational context and regulatory requirements.

For a technical reference implementation of these controls, see the APEX Trust Layer. For an example of how these governance policies operate in production, see the APEX Governance Document.

Fields marked [CUSTOMIZE] are completed during the engagement with the customer's own roles, retention periods, models, and regulatory obligations.

Executive Summary
Pillar 1 — Data Protection & Privacy
Pillar 2 — Model & Output Governance
Pillar 3 — Access Control & Accountability
Pillar 4 — Monitoring & Incident Response
Risk Assessment Matrix
Roles & Responsibilities
Regulatory Alignment Checklist
Implementation Roadmap
Document Control

Executive Summary

The adopting organization uses this AI Governance Framework to ensure responsible, secure, and compliant use of artificial intelligence across the business. The framework establishes the policies, controls, roles, and review processes that govern how AI systems are deployed, monitored, and improved.

Pillar 1 — Data Protection & Privacy

Principle

Know what data touches AI systems, protect it appropriately, and be explicit about what is and isn't allowed.

Data Classification

Before any data is used as input to an AI system, it must be classified according to the following table:

Classification	Description	AI Input Allowed?	Examples
Public	Information intended for public consumption	Yes	Marketing materials, public documentation
Internal	Business information not intended for public release	Yes, with access controls	Internal reports, meeting notes, project plans
Confidential	Sensitive business data requiring protection	Yes, with HITL review on outputs	Customer data, financial projections, deal details
Restricted	Highly sensitive data with regulatory or legal constraints	No — prohibited as AI input	PII subject to HIPAA/GDPR, payment card data, credentials

Adjust classifications to match the organization's existing data classification policy. Add industry-specific categories as needed.

Retention and Deletion

AI conversation data: retention period
AI-generated documents: retention period
Audit trail (metadata): retention period
All retention periods must comply with applicable regulations — HIPAA, SOX, GDPR, etc.

Encryption Requirements

All data at rest must be encrypted (AES-256 or KMS-managed keys at minimum)
All data in transit must use TLS 1.2 or higher
Encryption keys must be managed through a dedicated key management service — not embedded in application code or configuration files

Monday Morning

Before feeding data to an AI system, check the classification table. If it's in the Restricted column, stop. If it's Confidential, the output requires human review before it leaves the building.

APEX proof point: See Trust Layer §3–5 for a reference implementation — per-tenant KMS keys, zero conversation content logging, data classification enforced at the infrastructure level.

Pillar 2 — Model & Output Governance

Principle

Know which AI models are in use, validate what goes in, and review what comes out before it reaches customers.

Approved AI Models and Services

Only explicitly authorized AI models and services may be used:

Model/Service	Provider	Approved Use Cases	Owner
model	provider	use cases	owner
model	provider	use cases	owner

Any AI model or service not on this list is prohibited. This includes free-tier AI tools, browser extensions with AI features, and personal accounts on AI platforms. Shadow AI — unauthorized use of AI tools — is a governance violation.

Input Validation

All AI systems must implement input validation before processing user requests:

Prompt injection detection (obfuscation, encoding attacks, directive injection)
Data classification enforcement (Restricted data must be rejected before reaching the model)
Input length and format validation

Human Review Requirements

Output Type	Review Required?	Reviewer
Internal-use documents	No	N/A
Customer-facing documents	Yes — before delivery	role/title
Financial or legal outputs	Yes — before delivery	role/title + Legal
Code generated by AI	Yes — standard code review	Engineering lead
Automated decisions affecting customers	Yes — before execution	role/title

Guardrails

AI systems must have scope boundaries that define what the AI is and isn't allowed to do:

Topics the AI should refuse to engage with: defined per engagement
Actions the AI should never take autonomously: defined per engagement
Output formats that require human review: defined per engagement

Monday Morning

AI-generated customer-facing content goes through the review queue before it leaves the building. No exceptions. If it touches a customer, a human approved it.

APEX proof point: See Trust Layer §7 and §9 — prompt injection detection, guardrail refusal handling, and mandatory HITL review on all customer-facing outputs with self-approval prevention.

Pillar 3 — Access Control & Accountability

Principle

Every AI action traces back to a person. If you can't point to who approved it, it didn't get approved.

Role-Based Access

AI system access is granted based on role, not by default:

Role	AI System Access	Can Approve Outputs?
role	Full access (admin)	Yes
role	Create and submit	No — submits for review
role	Review and approve	Yes
role	Read-only	No

Map to the organization's existing role structure. Every role should have clear AI access boundaries.

Separation of Duties

The person who creates AI-generated content cannot approve it for external use
The person who configures AI system guardrails cannot be the sole person who monitors them
Administrative access to AI systems requires multi-factor authentication

Audit Trail Requirements

Event	What Is Logged	What Is NOT Logged
User request	User ID, timestamp, session ID	Message content
AI response	Token count, model used, latency	Response content
Review action	Reviewer ID, decision, timestamp, comments	N/A
Configuration change	Who changed what, when, previous value	N/A

Audit logs must be retained for retention period and must be immutable (append-only, no deletion or modification).

Adjust logging requirements to match the organization's compliance obligations. Some regulations require content logging — if so, specify which data categories and retention periods.

Authentication

SSO/federation required for all AI system access — no local accounts
Multi-factor authentication required for administrative access
Session timeout: duration

Monday Morning

If you can't point to who approved it, it didn't get approved. Every AI output that reaches a customer has a name attached to the approval.

APEX proof point: See Trust Layer §6 and Governance §4 — 9 RBAC roles enforced server-side, SCIM 2.0 automated provisioning, self-approval prevention on all workflows.

Pillar 4 — Monitoring, Incident Response & Continuous Improvement

Principle

Watch the systems, respond to failures, learn from them, and get better. Not annually — continuously.

What Gets Monitored

Metric	Threshold	Action
AI error rate	threshold	Alert + investigate
Response latency	threshold	Alert + capacity review
Token consumption	threshold	Cost review
Authentication failures	threshold	Security investigation
Guardrail triggers	Any increase in rate	Review guardrail effectiveness
User-reported issues	All	Triage within hours

AI-Specific Incident Types

Standard incident response procedures apply, plus these AI-specific scenarios:

Incident Type	Description	Response
Hallucination	AI generates factually incorrect output that reaches a customer	Recall output, notify affected customer, review guardrails
Data leakage	AI reveals data from one user/tenant to another	P0 — immediate containment, customer notification within 72 hours
Prompt injection	Attacker manipulates AI behavior through crafted input	Block input pattern, review detection rules, assess if data was exposed
Model degradation	AI quality drops significantly (new model version, drift)	Roll back to previous model version, investigate root cause

Feedback Loops

Users must have a clear, low-friction way to report AI issues:

In-app feedback mechanism (not a form — conversational)
Issues triage into the development pipeline automatically
Reporters receive acknowledgment and resolution status

Specify the feedback mechanism. APEX uses a conversational AI-powered issue reporter that creates GitHub issues automatically.

Governance Review Cadence

Review	Frequency	Participants	Deliverables
AI incident review	After every P0/P1	AI System Owner, Platform Admin	Root cause analysis, corrective actions
Governance health check	Quarterly	Executive Sponsor, AI System Owner, Data Steward	Dashboard review, policy updates, risk assessment update
Model approval review	When model changes are proposed	AI System Owner, Reviewer	Updated approved model list, test results
Annual governance audit	Annually	All RACI roles	Full framework review, regulatory alignment update

Monday Morning

Check the dashboard. If something's red, follow the runbook. If something's been yellow for more than a week, escalate.

APEX proof point: See Governance §6–7 — CloudWatch alarms, WAF metrics, structured logging, P0–P3 severity levels, and a closed-loop feedback system where user-reported issues flow directly into the development pipeline.

Risk Assessment Matrix

Classify every AI use case by risk tier. Higher risk requires more controls.

Use Case	Risk Tier	Required Controls	Approval Authority	Review Cadence
Internal knowledge search	Low	Access control, audit logging	Department manager	Annual
Internal document drafting	Low	Access control, output review	Department manager	Annual
Customer-facing chat / assistant	High	All Pillar 1–4 controls, HITL review	VP + AI System Owner	Quarterly
Document generation (internal)	Medium	Access control, output review, audit	Department manager	Semi-annual
Document generation (external)	High	All controls, HITL review, legal review	VP + Legal	Quarterly
Code assistance (internal)	Medium	Access control, code review process	Engineering lead	Semi-annual
Automated decisions affecting customers	High	All controls, HITL review, explainability	VP + Legal + AI System Owner	Quarterly

Add the organization's specific AI use cases. Every AI system in production or planned should appear in this matrix.

Roles & Responsibilities

These are not committee memberships. These are specific people with specific accountability.

Role Definitions

AI System Owner — Accountable for a specific AI deployment. Owns the risk assessment for that system, ensures all required controls are implemented and functioning, and reports status to the Executive Sponsor.
Data Steward — Classifies data, approves or denies data sources for AI use, and reviews data handling practices. Has authority to block an AI system from accessing a data source.
Reviewer — Approves AI outputs before external use. Cannot be the same person who created the output. Must understand the domain well enough to catch errors.
Platform Administrator — Manages access controls, monitors system health, handles incidents, and maintains the technical infrastructure. First responder for AI-specific incidents.
Executive Sponsor — Accountable to the board for AI governance. Reviews governance reports quarterly. Has authority to approve or deny new AI use cases and to shut down existing ones.

Each role is assigned to a named individual with title during the engagement.

RACI Matrix

Activity	AI System Owner	Data Steward	Reviewer	Platform Admin	Exec Sponsor
Data classification	C	A/R	—	I	I
Model approval	A/R	C	C	I	A
HITL output review	I	—	A/R	—	I
Incident response	R	I	I	A/R	I
Access control management	C	—	—	A/R	I
Governance review	A/R	R	R	R	A
Policy updates	R	R	C	C	A
Regulatory alignment	R	R	—	I	A

A = Accountable | R = Responsible | C = Consulted | I = Informed

Regulatory Alignment Checklist

This table maps framework controls to applicable regulatory standards. Not all standards apply to every organization — check the columns relevant to the organization's regulatory obligations.

Framework Control	NIST AI RMF	ISO/IEC 42001	EU AI Act
Data classification (Pillar 1)	Map 1.1, 1.2	A.6.2.4	Art. 10 (data governance)
Encryption at rest and in transit (Pillar 1)	Govern 1.5	A.8.4	Art. 15 (accuracy/robustness)
Model approval process (Pillar 2)	Govern 1.1	A.6.2.2	Art. 9 (risk management)
Input validation (Pillar 2)	Manage 2.2	A.8.3	Art. 15 (accuracy/robustness)
HITL review (Pillar 2)	Govern 4.1	A.6.2.6	Art. 14 (human oversight)
Role-based access (Pillar 3)	Govern 1.3	A.6.2.3	Art. 9 (risk management)
Audit trail (Pillar 3)	Measure 2.1	A.6.2.5	Art. 12 (record-keeping)
Monitoring and alerting (Pillar 4)	Measure 3.1	A.9.3	Art. 9 (risk management)
Incident response (Pillar 4)	Manage 3.1	A.8.2	Art. 62 (reporting)
Governance review cadence (Pillar 4)	Govern 5.1	A.9.1, A.9.2	Art. 9 (risk management)

A column is added for the organization's industry-specific regulations — HIPAA, SOX, PCI-DSS, FedRAMP, CMMC, etc.

Implementation Roadmap

Three phases. Each phase has specific deliverables — not vague objectives.

Phase 1 — Foundation (Month 1)

Complete data classification table (Pillar 1)
Define and publish approved AI model list (Pillar 2)
Implement role-based access controls for all AI systems (Pillar 3)
Set up basic monitoring and alerting (Pillar 4)
Assign all RACI roles with named individuals

Deliverables: Classification table signed off, model list published internally, access controls deployed, monitoring dashboard live, RACI matrix populated with names.

Phase 2 — Controls (Months 2–3)

Implement HITL review workflows for all High-risk use cases (Pillar 2)
Deploy audit trail and logging for all AI systems (Pillar 3)
Write incident response runbook for AI-specific failures (Pillar 4)
Complete risk assessment matrix for all current AI use cases
Implement user feedback mechanism for AI issues (Pillar 4)

Deliverables: Review workflow operational, audit trail capturing events, runbook published and tabletop-tested, risk matrix signed off by Executive Sponsor, feedback mechanism live.

Phase 3 — Maturity (Months 4–6)

Conduct first quarterly governance review meeting (Pillar 4)
Complete regulatory alignment checklist
Run first AI-specific incident response tabletop exercise
Document lessons learned and publish framework v1.1
Begin SOC 2 preparation (if applicable)

Deliverables: First governance review completed with documented outcomes, regulatory alignment checklist reviewed by legal, tabletop exercise report, framework v1.1 published with updates from first quarter of operation.

Timelines are adjusted based on the organization's current maturity level, team size, and urgency. Organizations with existing governance programs may compress Phase 1. Organizations starting from scratch may need to extend Phase 2.

Document Control

Field	Value
Version	1.0
Last Updated	Date
Framework Owner	Name, Title
Review Cadence	Quarterly minimum, or when significant changes to AI usage occur
Next Scheduled Review	Date

Change Log

Date	Version	Change	Author
Date	1.0	Initial framework adoption	Author

Want this framework adapted to your organization? privacy@discovertap.com
Tap Innovations LLC, Apopka, Florida, United States

AI Governance Framework

Contents

Executive Summary

Pillar 1 — Data Protection & Privacy

Data Classification

Retention and Deletion

Encryption Requirements

Monday Morning

Pillar 2 — Model & Output Governance

Approved AI Models and Services

Input Validation

Human Review Requirements

Guardrails

Monday Morning

Pillar 3 — Access Control & Accountability

Role-Based Access

Separation of Duties

Audit Trail Requirements

Authentication

Monday Morning

Pillar 4 — Monitoring, Incident Response & Continuous Improvement

What Gets Monitored

AI-Specific Incident Types

Feedback Loops

Governance Review Cadence

Monday Morning

Risk Assessment Matrix

Roles & Responsibilities

Role Definitions

RACI Matrix

Regulatory Alignment Checklist

Implementation Roadmap

Phase 1 — Foundation (Month 1)

Phase 2 — Controls (Months 2–3)

Phase 3 — Maturity (Months 4–6)

Document Control

Change Log