That creates a gap.
Traditional controls assume relatively stable requirements, deterministic behavior, controlled releases, and predictable test results. AI systems behave differently. They depend on data, prompts, models, context, feedback, usage patterns, and post-deployment monitoring.
That does not mean legacy controls are useless.
It means they are insufficient.
The Governance Gap
AI risk often appears in places traditional controls do not fully reach.
A model may perform well in testing but degrade in production. A prompt may produce different outputs based on context. A dataset may contain bias, privacy issues, or outdated assumptions. A user may apply an AI output outside its intended purpose. A third-party model may change without the organization fully understanding the impact.
Point-in-time approval cannot manage these risks alone.
AI governance must cover the lifecycle.
What Needs To Change
The control model must move from approval to continuous evidence.
Intake should identify the AI use case, purpose, risk tier, data sources, user group, decision impact, and regulatory exposure. Design should define guardrails, human oversight, testing requirements, and logging. Deployment should require release evidence. Operations should monitor performance, drift, incidents, user feedback, and exceptions.
This is a different control rhythm.
It does not remove governance. It makes governance operational.
Combining Frameworks
Several frameworks can help.
COBIT can support governance objectives, decision rights, and control accountability. NIST AI RMF can help structure risk identification, measurement, management, and governance. ISO/IEC 42001 can support management system discipline.
But frameworks do not govern AI by being named.
They must be translated into controls that teams can apply.
The organization needs intake criteria, risk tiers, control requirements, approval paths, monitoring measures, incident processes, and evidence records.
Threat Modeling and Impact Assessment
AI-specific threat modeling should happen early.
Teams should examine how the system could produce harmful, biased, insecure, inaccurate, or unauthorized outputs. They should consider data poisoning, prompt injection, model misuse, privacy leakage, hallucination, overreliance, and security exposure.
An AI impact assessment should clarify who may be affected, what decisions are influenced, what data is used, and what human review is required.
This gives leaders a better basis for approving or rejecting the use case.
Pipeline Controls
Controls should be embedded where work happens.
Dataset records, model records, prompt libraries, test results, approval logs, release artifacts, monitoring dashboards, and incident records should not be manually recreated for assurance. They should be produced as part of delivery and operations.
This is especially important for MLOps and LLMOps environments.
Evidence should travel with the model or AI service.
Operating Model
AI governance needs clear roles.
Business owners own the use case and outcome. Data owners approve data use. Technology teams build and run the system. Risk and compliance set requirements and review high-risk uses. Security tests exposure. Legal assesses obligations. Internal audit tests the control model.
Without this role clarity, AI governance becomes a committee problem.
Everyone is interested. No one is accountable.
The Closing Test
The question is not whether the organization has an AI policy.
The question is whether AI risk is controlled across intake, design, deployment, use, monitoring, and retirement.
Legacy controls can provide a foundation.
They cannot be the whole answer.