How to Monitor AI Systems After Approval

AI approval is not the finish line.

It is the start of ongoing governance.

A use case may be approved for a limited pilot.
Then it expands to more users.
Then it connects to new data.
Then the vendor updates the model.
Then outputs become customer-facing.
Then users rely on the AI more than expected.
Then monitoring is skipped.
Then an issue appears.
Then the dashboard still says approved.

That is not AI governance.

That is point-in-time approval.

AI systems need monitoring after approval because AI risk changes over time.

Data changes.
Users change.
Models change.
Vendors change.
Outputs change.
Business reliance changes.
Performance changes.
Bias can emerge.
Drift can occur.
Cyber risks can appear.
Privacy exposure can grow.
Human oversight can weaken.
Approval conditions can be missed.
Risk acceptances can expire.

A strong AI monitoring process helps teams answer:

• Is the AI system still being used as approved?
• Is the data still within approved scope?
• Is the vendor still operating under approved terms?
• Are prompts and outputs retained as expected?
• Is performance still acceptable?
• Are errors, drift, bias, or hallucinations increasing?
• Is human oversight actually happening?
• Are complaints, incidents, or issues appearing?
• Are monitoring thresholds being breached?
• Is reassessment required?
• Should the AI use case continue, change, pause, or retire?

AI governance should not stop when approval is granted.

It should continue through monitoring, issue remediation, validation, reassessment, and reporting.

That is how AI governance becomes an operating model.

What is AI monitoring?

AI monitoring is the ongoing process of tracking whether an approved AI system continues to operate within its intended purpose, risk tier, approved scope, performance expectations, data-use limits, control requirements, human oversight model, vendor terms, monitoring thresholds, and risk appetite.

AI monitoring may include:

• usage monitoring
• performance monitoring
• accuracy monitoring
• drift monitoring
• bias or fairness monitoring
• hallucination or error monitoring
• human oversight monitoring
• override monitoring
• complaint monitoring
• incident monitoring
• vendor change monitoring
• data-use monitoring
• prompt and output monitoring
• cyber monitoring
• privacy monitoring
• approval-condition tracking
• issue remediation tracking
• risk acceptance monitoring
• reassessment tracking

Monitoring should be risk-based.

A low-risk internal productivity use case may need only periodic owner attestation and policy compliance review.

A high-risk AI use case that affects customers, employees, regulated decisions, sensitive data, or critical processes may need formal metrics, thresholds, evidence, issue triggers, and executive reporting.

The purpose is not to monitor everything equally.

The purpose is to monitor what matters.

Why monitoring matters after approval

Approval decisions are made based on facts at a point in time.

But AI systems are dynamic.

An approved use case can become risky when:

• the data changes
• new sensitive data is added
• the use case expands
• the audience changes
• the output becomes customer-facing
• a model version changes
• the vendor changes terms
• monitoring is not performed
• human reviewers stop reviewing carefully
• accuracy declines
• bias emerges
• drift appears
• incidents occur
• users bypass approved restrictions
• approval conditions remain incomplete
• risk acceptance expires

NIST's AI RMF Core is organized around Govern, Map, Measure, and Manage, which is a useful lifecycle model because organizations must continue measuring and managing AI risk after mapping and approving the use case.   ISO/IEC 42001's emphasis on maintaining and continually improving an AI management system also reinforces that AI governance is not a one-time approval event.  

Monitoring turns AI governance from a gate into a lifecycle.

The AI Monitoring Model

A practical AI monitoring model has 12 components:

1. Approved scope
2. Monitoring owner
3. Risk-tier-based monitoring plan
4. Metrics and thresholds
5. Data and input monitoring
6. Output and performance monitoring
7. Human oversight monitoring
8. Vendor and model-provider monitoring
9. Privacy, cyber, and compliance monitoring
10. Issue and incident triggers
11. Reassessment and change triggers
12. Dashboard and executive reporting

Each component should connect to the AI use case record.

Monitoring should not live separately from the AI inventory.

1. Confirm the Approved Scope

Before monitoring can begin, the approved scope must be clear.

The AI record should show:

• approved purpose
• approved users
• approved data
• approved systems
• approved vendors
• approved model provider
• approved output type
• approved decision role
• approved deployment environment
• approved monitoring plan
• approved human oversight
• approved restrictions
• approval conditions
• reassessment triggers

Monitoring compares actual use against approved use.

If the approved scope is vague, monitoring will be weak.

Weak approval:

Approved for customer support.

Better approval:

Approved for customer support agents to draft responses using customer support ticket context. Human review required before sending. Vendor may not use prompts or outputs for training. Use is limited to English-language support tickets during the pilot. No regulated or highly sensitive customer data may be entered. Monitoring required for response accuracy, override rate, customer complaints, and policy violations.

The better approval can be monitored.

Approved scope checklist

If the approved scope is unclear, monitoring should start by cleaning the approval record.

2. Assign a Monitoring Owner

Every monitored AI use case needs an owner.

The monitoring owner may be:

• business owner
• AI use-case owner
• model owner
• system owner
• product owner
• risk owner
• compliance owner
• AI governance team
• data science team
• vendor owner
• control owner

For higher-risk use cases, monitoring may involve multiple owners.

Example:

The monitoring owner does not need to perform every check.

But someone must be accountable for making sure monitoring happens.

A common failure is approving AI with monitoring required but no monitoring owner assigned.

Monitoring ownership checklist

Monitoring fails when it is everyone's responsibility and no one's job.

3. Build a Risk-Tier-Based Monitoring Plan

Monitoring should be proportional to risk tier.

A low-risk use case should not be overburdened.

A high-risk use case should not rely on annual attestation only.

Monitoring should include:

• frequency
• owner
• metrics
• thresholds
• evidence
• issue triggers
• escalation rules
• reassessment triggers
• dashboard view

The EU AI Act's high-risk provisions include post-market monitoring obligations for providers of high-risk AI systems; the official AI Act service desk describes a requirement to establish and document a post-market monitoring system proportionate to the nature of the AI technologies and risks of the high-risk AI system.   Even when a use case is not legally subject to those obligations, the principle is practical: monitoring depth should match risk.

Monitoring plan checklist

4. Define Metrics and Thresholds

Monitoring should not be vague.

"Monitor the AI system" is not enough.

Define metrics and thresholds.

Possible metrics include:

• usage volume
• user adoption
• output accuracy
• error rate
• hallucination rate
• override rate
• human edit rate
• complaint rate
• incident count
• policy violation count
• response latency
• drift indicator
• bias or fairness metric
• model performance metric
• vendor service issue
• data-use exception
• sensitive-data entry
• approval condition status
• unresolved issue count
• monitoring completion rate

Thresholds define when action is needed.

Examples:

• output error rate exceeds 5%
• human override rate exceeds 20%
• complaints increase month over month
• monitoring not completed by due date
• vendor changes model provider
• new sensitive data is added
• customer-facing use expands
• data-use term changes
• monitoring exception is unresolved after 10 business days
• incident occurs
• approval condition is overdue

A threshold should trigger something.

That something may be:

• issue creation
• escalation
• reassessment
• risk acceptance
• approval suspension
• monitoring increase
• model rollback
• vendor review
• executive decision

Metrics without thresholds create reporting.

Metrics with thresholds create governance.

Metrics and threshold checklist

5. Monitor Data and Inputs

AI risk often changes when data changes.

Monitor whether the AI system is still using approved data.

Ask:

• Is the data still within approved scope?
• Has sensitive data been added?
• Has personal data been added?
• Has confidential business data been added?
• Are users entering prohibited data?
• Are prompts being stored?
• Are outputs being stored?
• Are logs retaining data longer than approved?
• Is data being used for model training or improvement?
• Is retrieval data changing?
• Are new data sources connected?
• Is data quality changing?

Data monitoring may include:

• prompt review
• input sampling
• data source review
• data inventory update
• DLP alerts
• sensitive data detection
• user policy violations
• retention checks
• vendor data-use confirmations
• model training-use attestations

This is especially important for generative AI because users can introduce sensitive data through prompts.

It is also important for retrieval-augmented systems because connected knowledge sources can expand quietly.

Data monitoring checklist

6. Monitor Outputs and Performance

AI outputs need monitoring because output quality can degrade or behave differently in real use.

Output monitoring may include:

• accuracy
• completeness
• consistency
• relevance
• harmful content
• hallucination
• bias
• discriminatory outcomes
• unsafe recommendations
• policy violations
• tone or brand issues
• legal or compliance issues
• customer complaint themes
• override rate
• human edit rate

Performance monitoring depends on the use case.

For a support assistant, monitor output accuracy, customer complaints, human edits, and policy violations.

For a fraud model, monitor false positives, false negatives, override rates, and customer impact.

For an HR analytics tool, monitor fairness, explainability, human review, and employment-decision impact.

For a code assistant, monitor insecure code suggestions, policy violations, and developer feedback.

Output monitoring should be tied to the approved purpose.

Do not monitor abstract model performance only.

Monitor whether the AI is performing safely and acceptably in the business process.

Output and performance checklist

7. Monitor Human Oversight

Human oversight is often promised during approval.

Monitoring proves whether it is actually happening.

Monitor:

• whether human review occurs
• who performs review
• whether reviewers are trained
• whether review criteria are used
• whether overrides are possible
• whether overrides are logged
• whether humans over-rely on AI
• whether review quality is sampled
• whether escalation occurs
• whether human review is bypassed

Weak oversight:

A human reviews the output.

Strong oversight:

Trained agents review AI-drafted customer responses before sending. Edits, overrides, and rejected outputs are logged. A monthly sample is reviewed for accuracy, policy compliance, and customer impact. Override rates above threshold trigger issue review.

Human oversight should be a control.

Controls need evidence.

Human oversight monitoring checklist

If human oversight cannot be evidenced, it should not be relied on as a risk control.

8. Monitor Vendor and Model-Provider Changes

AI vendors and model providers can change quickly.

Monitor:

• vendor terms
• model provider changes
• subprocessors
• data-use terms
• training restrictions
• prompt and output retention
• security evidence
• privacy evidence
• service levels
• incident notices
• model updates
• API changes
• data location
• audit or assurance evidence
• renewal dates
• contract exceptions

Vendor changes can affect approved AI use.

Example:

A vendor originally prohibited training on customer prompts.
Then it updates terms.
The AI use case may need reassessment.

Example:

A vendor changes model provider.
Cyber, privacy, legal, and AI governance may need review.

Example:

A vendor adds new AI features to an approved platform.
The existing approval may not cover the new feature.

Vendor monitoring should connect to third-party risk and contract workflows.

Vendor monitoring checklist

9. Monitor Privacy, Cyber, and Compliance Conditions

AI approvals often include conditions from privacy, cyber, legal, vendor risk, or compliance teams.

Monitor whether those conditions are complete.

Examples:

• DPIA mitigation completed
• vendor DPA updated
• cyber review completed
• access control implemented
• monitoring enabled
• disclosure added
• human oversight training completed
• sensitive data excluded
• customer-facing use restricted
• model output review completed
• risk acceptance approved
• retention terms documented

Approval conditions should not be left in notes.

They should become tracked actions or issues.

If a condition is overdue, dashboard status should change.

If a condition is material, expansion should be blocked until completion.

Approval condition checklist

10. Create Issue and Incident Triggers

Monitoring should create action when something goes wrong.

Issue triggers may include:

• monitoring not performed
• monitoring threshold breached
• human oversight not evidenced
• output accuracy below threshold
• hallucination rate above threshold
• bias metric outside threshold
• customer complaints increase
• prohibited data detected
• unapproved data source added
• vendor terms change
• prompt retention unknown
• approval condition overdue
• risk acceptance expired
• model version changed without review
• AI incident reported
• use case expands without reassessment

AI incidents may include:

• harmful output
• discriminatory output
• unsafe recommendation
• privacy exposure
• data leakage
• cyber misuse
• unauthorized use
• customer harm
• employee harm
• regulatory concern
• vendor AI incident
• model failure

Every issue or incident should link to:

• AI use case
• risk tier
• data
• vendor
• system
• control
• evidence
• owner
• remediation
• validation
• dashboard

Monitoring without issue triggers is just observation.

Monitoring with issue triggers is governance.

Issue trigger checklist

11. Define Reassessment and Change Triggers

AI use cases should be reassessed when risk changes.

Common reassessment triggers:

• new data category added
• sensitive data added
• new vendor or model provider
• contract terms change
• model version changes
• output becomes customer-facing
• new user group added
• business process changes
• decision impact increases
• use expands from pilot to production
• geography changes
• regulation changes
• monitoring threshold breached
• incident occurs
• approval condition missed
• risk acceptance expires
• control fails
• human oversight changes
• system integration changes

Reassessment should update:

• risk tier
• required reviews
• controls
• evidence
• approval status
• monitoring plan
• dashboard status

An AI system that was low risk last quarter may not remain low risk after expansion.

Reassessment checklist

12. Build AI Monitoring Dashboards

AI monitoring should appear in dashboards.

Dashboard views should include:

SmartSuite's AI Governance page describes dashboards and monitoring cycles linked to AI inventories, risks, controls, evidence, remediation, and executive visibility.   That is the right operating model: monitoring should update the risk view automatically or through governed source records.

AI Monitoring by Risk Tier

Low-risk AI monitoring

Examples:

• internal drafting assistant
• public content summarizer
• simple productivity support

Monitoring may include:

• annual owner attestation
• policy compliance confirmation
• data-use restriction reminder
• issue trigger if scope changes
• lightweight usage review

Evidence:

• owner attestation
• approved-use record
• no sensitive data confirmation
• issue log, if any

Moderate-risk AI monitoring

Examples:

• AI drafting customer support responses with human review
• AI summarizing internal customer feedback
• AI-assisted contract review
• AI classification of support tickets

Monitoring may include:

• usage review
• output quality sampling
• human edit or override tracking
• complaint review
• data-scope review
• vendor evidence refresh
• approval condition review

Evidence:

• monitoring report
• output sample review
• human oversight evidence
• vendor evidence
• issue records

High-risk AI monitoring

Examples:

• AI influencing employment, financial, health, customer eligibility, fraud, or regulated decisions
• AI using sensitive data
• customer-facing AI with meaningful impact
• AI embedded in critical processes

Monitoring may include:

• formal performance metrics
• accuracy thresholds
• bias or fairness metrics
• drift indicators
• human oversight evidence
• complaint review
• incident triggers
• privacy and cyber monitoring
• vendor change monitoring
• periodic reassessment
• executive reporting

Evidence:

• monitoring results
• threshold reports
• issue and remediation evidence
• validation evidence
• risk acceptance
• dashboard status

Critical AI monitoring

Examples:

• AI outside appetite but temporarily accepted
• AI use with board or executive visibility
• AI use with material residual risk
• AI use requiring formal risk acceptance

Monitoring may include:

• executive review
• committee reporting
• formal risk acceptance monitoring
• required validation
• periodic independent review
• enhanced issue escalation
• board visibility where appropriate

Evidence:

• executive decision record
• risk acceptance record
• monitoring report
• validation evidence
• action log
• board or committee materials, where relevant

AI Monitoring Evidence

Monitoring evidence should be retained.

Evidence may include:

• monitoring plan
• monitoring owner
• metric definitions
• threshold definitions
• monitoring schedule
• monitoring results
• performance report
• output review
• human oversight evidence
• override logs
• complaints
• incidents
• issue records
• remediation evidence
• validation evidence
• vendor change notice
• model version change
• data-scope change
• reassessment record
• risk acceptance review
• approval condition closure evidence

Monitoring evidence should show:

• what was monitored
• when it was monitored
• who reviewed it
• what result was found
• whether thresholds were breached
• what action was taken
• whether issues were created
• whether remediation was validated

Monitoring evidence should link to the AI use case record.

A dashboard metric without evidence is not enough.

AI Monitoring Checklist

Use this checklist after approval.

If several answers are no, post-approval governance is incomplete.

Common AI Monitoring Mistakes

Mistake 1: Treating approval as permanent

Approval should be conditional on continued operation within approved scope.

Mistake 2: Monitoring only technical performance

AI monitoring should also include data use, human oversight, vendor changes, privacy, cyber, issues, and business impact.

Mistake 3: Not defining thresholds

Metrics without thresholds do not drive action.

Mistake 4: Not linking monitoring to issues

Monitoring exceptions should create issues when action is required.

Mistake 5: Not monitoring vendor changes

Vendor terms, model providers, subprocessors, and retention practices can change.

Mistake 6: Not monitoring human oversight

Human oversight is only a control if it actually happens and is evidenced.

Mistake 7: Not reassessing after scope changes

New data, users, outputs, or decision impact can change the risk tier.

Mistake 8: Not dashboarding monitoring gaps

Monitoring overdue or inactive should be visible to AI governance leaders and executives.

30-Day AI Monitoring Implementation Plan

Days 1–5: Identify monitored use cases

Start with:

• high-risk AI
• AI using sensitive data
• customer-facing AI
• employee-impacting AI
• vendor AI tools
• AI approved with conditions
• AI with open issues
• AI with risk acceptance

Days 6–10: Define monitoring plans

For each use case, define:

• owner
• metrics
• thresholds
• cadence
• evidence
• issue triggers
• escalation

Days 11–15: Connect monitoring to source records

Link monitoring to:

• AI inventory
• data inventory
• vendor record
• contract
• risk tier
• controls
• evidence
• issues
• dashboard

Days 16–20: Pilot monitoring

Run monitoring for:

• one low-risk use case
• one moderate-risk vendor use case
• one high-risk sensitive-data use case
• one approved-with-conditions use case

Days 21–25: Create issue and reassessment triggers

Define what happens when:

• threshold breached
• monitoring missed
• data scope changes
• vendor terms change
• incident occurs
• approval condition overdue
• risk acceptance expires

Days 26–30: Launch AI monitoring dashboard

Show:

• monitoring due
• monitoring overdue
• threshold breaches
• open issues
• conditions overdue
• reassessments due
• risk acceptances
• decisions needed

This creates a practical AI monitoring foundation in one month.

Example: Monitoring a Customer Support AI Assistant

Use case:

AI drafts customer support responses for agents.

Approved scope:

• internal agent assistance
• human review before sending
• customer support tickets only
• no sensitive data beyond approved support context
• vendor may not train on prompts or outputs
• pilot limited to one support queue

Monitoring metrics:

• AI response accuracy
• human edit rate
• human override rate
• customer complaints
• policy violations
• prohibited data entry
• prompt/output retention confirmation
• vendor change notices
• support queue expansion

Thresholds:

• accuracy below agreed level
• customer complaints above threshold
• human override rate unusually high
• prohibited data detected
• vendor terms change
• pilot expands without review

Issue triggers:

• human review bypass
• prompt retention unclear
• customer complaint trend
• unapproved data use
• approval condition overdue

Dashboard:

• monitoring status
• issues
• approval conditions
• pilot expansion readiness
• decision needed

This is how monitoring keeps a moderate-risk AI use case controlled.

Example: Monitoring an AI Hiring Tool

Use case:

AI ranks applicants for interview priority.

Approved scope:

• screening support only
• human recruiter review required
• no automatic rejection
• applicant data only
• vendor evidence required
• fairness and performance monitoring required
• legal and HR review required

Monitoring metrics:

• ranking accuracy
• fairness metrics
• recruiter override rate
• applicant complaints
• model drift
• data input changes
• vendor model changes
• human review evidence
• adverse-impact indicators
• issue trends

Thresholds:

• fairness metric outside threshold
• override rate above threshold
• model version changed without review
• human review not evidenced
• applicant complaint received
• data source changes
• vendor evidence expires

Escalation:

• legal
• HR
• AI governance committee
• executive owner
• risk acceptance if continued use requested

This is a high-risk AI use case.

Monitoring should be formal and evidenced.

Example: Monitoring an AI Code Assistant

Use case:

AI coding assistant used by engineering team.

Approved scope:

• approved enterprise tool
• company source code allowed only under approved vendor terms
• no secrets or customer data in prompts
• vendor cannot train on company code
• use limited to approved repositories
• developer guidance required

Monitoring metrics:

• usage by team
• prohibited data entry
• secrets detected in prompts
• insecure code suggestions flagged
• vendor term changes
• repository scope changes
• developer policy attestations
• security issue trends

Issue triggers:

• credentials entered
• customer data entered
• vendor terms change
• insecure code pattern repeated
• unapproved repository connected

Monitoring does not need to be heavy-handed.

It needs to match the risk.

How Connected GRC Improves AI Monitoring

Connected GRC improves AI monitoring by linking:

• AI inventory
• approved scope
• risk tier
• monitoring plan
• data inventory
• vendors
• contracts
• privacy reviews
• cyber reviews
• controls
• evidence
• monitoring results
• issues
• remediation
• validation
• risk acceptance
• reassessment
• dashboards
• decisions

In a disconnected model, monitoring results live in a model dashboard, vendor report, spreadsheet, or team meeting.

In a connected model, monitoring results update AI risk, evidence, issues, remediation, reassessment, and executive reporting.

That is the difference between technical monitoring and governance monitoring.

A Practical Test for Your AI Monitoring Process

Pick one approved AI use case.

Ask whether your GRC model can show:

• approved scope
• risk tier
• monitoring owner
• monitoring plan
• metrics
• thresholds
• monitoring cadence
• latest monitoring evidence
• data-scope changes
• vendor changes
• model changes
• human oversight evidence
• output quality results
• incidents
• issues
• remediation
• validation
• risk acceptance
• reassessment triggers
• dashboard status
• decisions needed

If answering those questions requires AI platform logs, spreadsheets, vendor files, privacy notes, cyber tickets, legal emails, and meetings, AI monitoring is not connected enough.

That is common.

It is also the opportunity.

Final Thought

AI governance does not end at approval.

Approval says the AI use case may proceed under defined conditions.

Monitoring proves whether those conditions remain true.

The AI is still being used as approved.
The data is still within scope.
The vendor terms still support the use.
Human oversight still operates.
Outputs remain acceptable.
Performance remains within threshold.
Issues are remediated.
Changes trigger reassessment.
Residual risk is governed.
Dashboards show the truth.

That is post-approval AI governance.

Connected GRC makes it possible because monitoring does not sit in isolation.

It connects to the AI inventory, risk tier, data, vendor, contract, controls, evidence, issues, remediation, validation, risk acceptance, reassessment, dashboards, and decisions.

That is how to monitor AI systems after approval.

Not as a technical afterthought.

As a governance workflow.