Most AI governance programs fail operationally, not philosophically.

The organization writes a policy. Everyone agrees AI needs oversight. Then a department head signs up for a new AI tool without telling anyone, and three months later it turns out the tool has been processing customer data under terms no one reviewed.

The policy was never the problem. The workflow was.

An AI governance workflow is the operational layer of governance: what actually happens when someone wants to use a new AI tool, who reviews it, how long that takes, what gets documented, and what happens when something goes wrong.

This guide covers how to design and run that workflow for a small to mid-market organization.

The four workflows every AI governance program needs

A complete AI governance program runs four distinct workflows:

Request and approval — what happens when someone wants to use a new AI tool
Onboarding — what happens after a tool is approved
Monitoring — what happens while a tool is in active use
Incident response — what happens when something goes wrong

Each is described below with step-by-step process, decision points, and responsible parties.

For the documentation these workflows produce, see AI governance documentation. For the full framework these workflows operate within, see building an AI governance framework.

Workflow 1: AI tool request and approval

This is the most important workflow to get right. Every tool your organization uses should pass through it before anyone starts using it — not after.

Step 1: Employee submits request

Any employee who wants to use an AI tool for work purposes submits a request. The request captures:

What tool they want to use
What they want to use it for
Whether it will process customer, employee, or financial data
Who else on their team would use it
Estimated cost

The request goes to the employee’s manager and to whoever owns AI governance at your organization (an AI lead, COO, or designated IT contact).

Decision point: Is this a tool the organization has already approved?

If yes → Employee uses the tool under existing terms. No further review needed.
If no → Continue to Step 2.

Step 2: Risk classification

The AI governance lead (or designated reviewer) classifies the requested use case into a risk tier:

Tier 1 (low risk): The tool assists with internal productivity, drafting, or research. Outputs are reviewed by a human before any action is taken. No customer data is processed.

Tier 2 (medium risk): The tool influences customer-facing communications, operational decisions, or financial outputs. Human review occurs, but the AI output significantly shapes the decision.

Tier 3 (high risk): The tool makes or heavily influences decisions with significant consequences — hiring, lending, legal compliance, or automated customer-facing decisions without meaningful human review.

Decision point: What is the risk tier?

Tier 1 → Go to Step 3A (simplified approval)
Tier 2 → Go to Step 3B (standard review)
Tier 3 → Go to Step 3C (full committee review)

Step 3A: Tier 1 simplified approval

For Tier 1 tools:

AI governance lead or designated approver reviews the request (target: 3 business days)
Vendor’s data handling terms are confirmed (does the tool train on inputs? where is data stored?)
If acceptable: tool is approved, added to the AI inventory, and a model card is created
Employee is notified with approved use case and any use restrictions

Step 3B: Tier 2 standard review

For Tier 2 tools:

AI governance lead assigns a named AI owner for the tool
AI owner completes a risk assessment (target: 10 business days)
Risk assessment covers: use case specifics, data handling, vendor security assessment, identified risks and mitigations
One committee member (typically IT lead or legal) reviews and signs off
If approved: tool added to inventory, model card created, monitoring cadence established
If denied or deferred: requestor notified with reason

Step 3C: Tier 3 full committee review

For Tier 3 tools:

Full AI Steering Committee is convened (target: 20 business days)
Legal and compliance review is required
Complete risk assessment is conducted, including regulatory review
Committee votes on approval
If approved: documented approval record created, tool added to inventory, model card created, quarterly monitoring established
If denied: written explanation provided; requestor may revise use case and resubmit

Approval documentation

Every approved tool receives a documented approval record that captures:

Tool name and approved use case
Risk tier
Data handling terms confirmed
Approving parties and date
Conditions or restrictions on use
Next review date

This record is retained for a minimum of three years or the duration of use plus two years, whichever is longer.

Workflow 2: Tool onboarding

Approval is not deployment. Between approval and active use, four things need to happen.

Step 1: Assign and brief the AI owner

The named AI owner is confirmed and briefed on their responsibilities:

Maintaining the model card
Conducting monitoring at the required frequency
Reporting incidents
Managing decommissioning when the tool is no longer needed

Step 2: Configure within approved parameters

IT or the AI owner configures the tool within the bounds of the approved use case:

Access permissions set to approved user groups only
Data inputs restricted to approved data types (if technically possible)
Any available data retention or opt-out settings applied

Step 3: Brief users

Every employee who will use the tool is briefed on:

The approved use case (and what is not approved)
Output review requirements (does every output need human review before acting on it?)
How to report issues or concerns
Who the AI owner is

This does not need to be a training program. A brief written summary or 15-minute team sync is sufficient for Tier 1 and Tier 2 tools. Tier 3 tools may warrant more formal training given the higher stakes.

Step 4: Start monitoring clock

The AI owner sets up their monitoring cadence per the risk tier:

Tier 1: As needed; add to annual review list
Tier 2: Monthly spot-check; semi-annual formal review
Tier 3: Weekly output review; quarterly formal review

Workflow 3: Ongoing monitoring

Monitoring is where most AI governance programs fall apart. The policy says tools will be monitored. In practice, no one does it because no one owns a specific action on a specific date.

Good monitoring workflow is calendar-driven, not intention-driven.

Monthly monitoring (Tier 2 and Tier 3)

AI owner reviews a sample of recent outputs:

Pull a sample of outputs from the past 30 days (10–20 is typically sufficient for Tier 2; more for Tier 3)
Assess quality and accuracy — are outputs within expected range?
Check for any drift or change in tool behavior
Review any user feedback or complaints since the last check
Document the review in the tool’s model card (date, sample size, findings, any concerns)

If the review surfaces concerns: AI owner escalates to the AI Steering Committee.

Semi-annual review (Tier 2) / Quarterly review (Tier 3)

AI owner conducts a more thorough review:

Full output quality assessment (larger sample)
Vendor check: any material updates to the tool, its data terms, or its security posture?
Use case check: is the tool still being used within its approved parameters?
Risk assessment check: do any identified risks require updated mitigations?
Update model card with findings
Confirm next review date

If the vendor has materially changed their data handling terms, the tool goes back through the approval workflow.

Annual review (all tiers)

All tools are reviewed annually, regardless of tier:

AI owner confirms tool is still needed and still in approved use
Vendor terms are confirmed current
Risk tier classification is confirmed or updated
Model card is refreshed
Any open issues from the past year are documented

Tools no longer in active use are marked as decommissioned in the inventory.

Workflow 4: Incident response

When an AI tool produces outputs that cause harm, violate policy, or operate outside approved parameters, the incident response workflow activates.

Step 1: Identification and initial report

Any employee who observes a potential AI incident reports it immediately to:

Their AI owner, or
Their manager, who escalates to the AI owner

The report captures:

What tool was involved
What happened (describe the output or behavior)
Who or what was affected
When it occurred

The AI owner assesses initial severity (low / medium / high) within one business day.

Step 2: Containment decision

Decision point: Does the tool need to be suspended?

For high severity incidents: suspend the tool immediately pending investigation.

For medium severity incidents: AI owner judgment call. Suspension is appropriate if:

The incident is ongoing or likely to recur
Outputs are being used in decisions that could harm customers or employees
Legal or regulatory exposure is possible

For low severity incidents: tool may continue operating while investigation proceeds.

Step 3: Notification

High severity: AI owner notifies the full AI Steering Committee immediately. Legal is brought in. If customer data is involved, legal determines whether breach notification obligations apply.

Medium severity: AI owner notifies the AI Steering Committee within 24 hours.

Low severity: AI owner documents the incident in the incident log and notifies the committee at the next scheduled check-in.

Step 4: Investigation

The AI owner, with committee support for medium and high severity incidents, investigates:

What specifically went wrong?
Was this a tool failure, a use case failure (used outside approved parameters), or a process failure (inadequate review)?
How many outputs were affected?
What decisions were made based on those outputs?

Step 5: Remediation

Based on investigation findings, one of four outcomes:

Tool continues with updated monitoring — failure was anomalous; additional monitoring is sufficient
Tool continues with use case restriction — approved use case is narrowed to reduce risk
Tool requires re-approval — material change in risk profile; tool goes back through approval workflow
Tool is decommissioned — risk cannot be adequately mitigated

Step 6: Documentation and framework update

AI owner completes the incident log entry within 10 business days, capturing:

Root cause
Scope of impact
Remediation taken
Whether similar incidents are possible with other tools
Whether the governance framework or policy needs updating

The AI Steering Committee reviews whether the incident reveals a gap in the framework itself.

Making the workflow operational

The most common reason AI governance workflows fail is that they exist as policy but not as calendar events and assigned tasks.

Build in the calendar events. Every Tier 2 and Tier 3 tool’s monthly and quarterly reviews should be on the AI owner’s calendar before the tool is deployed. The monitoring workflow should not depend on someone remembering to do it.

Assign human owners, not departments. “Legal reviews Tier 3 tools” does not work. “Sarah, VP Legal, is the legal reviewer for Tier 3 approvals and is expected to return reviews within 10 business days” works.

Treat the request form as the entry point. The request form is not bureaucracy — it is the trigger that starts the workflow. Make it easy to submit (a simple form or email template) so that employees who want to do the right thing can do so without friction.

Set a default answer for tools discovered outside the process. When you find out a team has been using an unapproved tool — and you will — have a defined process for handling it: submit a retroactive request, classify the risk, decide whether to approve it retroactively or require discontinuation. A defined process removes the awkwardness and ensures the situation is handled consistently.

Run the audit as a process check, not a compliance exercise. The annual audit should answer one question: is this governance program actually running? Are monitoring reviews happening? Is the incident log being maintained? Are requests going through the workflow? If the answer is no, the audit is where you find out before something goes wrong.

For the documents each of these workflows produces, see AI governance documentation. For a complete governance framework template including the policy, risk tier definitions, and appendices, see the AI governance framework template.

If you want help designing and embedding an AI governance workflow that your team will actually follow, Phos AI Labs works with SMBs and mid-market organizations on governance alongside full AI implementation.

AI Governance Workflow — How to Manage AI Requests, Approvals, and Audits

The four workflows every AI governance program needs