Many organizations now have an AI policy, and it is important not to stop there! As far fewer organizations can answer a more consequential question: How does that AI policy change an actual decision about an AI system before it goes live, and what happens when the system changes afterward?

A statement that AI should be fair, transparent, secure, and accountable is a starting point. It does not tell a product owner which assessment to complete, a governance board what evidence to examine, or an operations team when to suspend a system. Those decisions require an operating model. The aim is to make responsible AI visible in the way an organization acquires, designs, deploys, monitors, and retires AI.

Three frameworks with distinct jobs

I use three complementary frameworks to build that operating model. The NIST AI Risk Management Framework (AI RMF) supplies the risk logic through its Govern, Map, Measure, and Manage functions. It helps teams understand an AI use case in context, identify potential impacts, test controls, and decide how to treat remaining risk. These functions are continuous and mutually reinforcing; they are not a one-time checklist.

The ISO/IEC 42001 AIMS supplies the management system discipline. An Artificial Intelligence Management System (AIMS) defines its scope, leadership, objectives, processes, resources, performance reviews, audits, and corrective actions. This is what makes governance repeatable across business units and over time. The standard can support formal management system certification, but a certificate by itself cannot replace sound decisions about individual systems.

The IEEE CertifAIEd Assessor Framework adds a deeper ethical assessment lens at the system level. Its principal areas are transparency, accountability, algorithmic bias, and privacy. The questions become concrete: Can users recognize when AI is involved? Who can override a harmful result? Were relevant groups tested for unequal outcomes? Can the organization demonstrate that personal information is handled as promised? An internal assessment can use this evidence-oriented approach, while formal IEEE product certification requires the authorized IEEE process.

The three frameworks should feed a single governance lifecycle. Running separate NIST, ISO, and IEEE review tracks for the same system would create duplication and leave owners unclear about the final decision. One intake record, one risk assessment, one evidence set, and explicit decision rights make the architecture usable.

Start with ownership and an AI inventory

The first operational question is not which model is most advanced. It is which AI systems the organization is using, who owns them, what they do, and whom they can affect. A useful AI inventory includes the business purpose, product owner, model and provider, data classes, connected systems and tools, deployment status, risk tier, approval status, and next review date. Procurement records and access logs can help expose unregistered use.

The board or executive leadership should set risk appetite and review material exposure. An AIMS owner maintains the management system. An AI Governance Board decides significant releases, conditions, and exceptions. The business and product owners remain accountable for the system and its outcomes. Legal, privacy, security, data, and risk specialists review within their mandates, while independent assurance challenges the evidence without owning the deployment decision.

These roles need a charter with clear authority. If two groups both believe they have the final word, decisions stall. If neither does, risk is silently accepted. Every material approval needs a named decision maker, a residual risk owner, and a record of conditions and dissent.

Put evidence at each lifecycle gate

A practical lifecycle begins with intake and risk classification. It then moves through impact assessment and control design, validation, release approval, monitoring and change review, and retirement. The rigor should reflect potential harm. An internal summarization aid and a system influencing benefits, employment, health, safety, or public services should not receive identical scrutiny.

At intake, document the intended purpose, users, affected people, data, vendor, and decisions or actions the AI may influence. At assessment, examine foreseeable failure and misuse, as well as benefits. At validation, test against criteria set in advance. At release, record the decision, any limits on use, the owner who accepts residual risk, monitoring thresholds, and the shutdown or rollback path. Reassess when the model, data, prompt, tools, provider, operating context, or consequences change.

Agentic AI raises the stakes for operational control

An AI agent may call tools, update records, trigger transactions, and act across several systems. Governance must therefore cover its authority and actions, not just its model output. Register the agent and its connected tools. Limit credentials and permissions. Require human confirmation for material or irreversible actions. Log action chains, test unsafe tool combinations and prompt injection, and provide a reliable way to stop or roll back the workflow.

An agent’s autonomy should be bounded by an accountable human owner and an approved purpose. A material change to its tools, goals, or permissions is a governance event, even if the underlying model has not changed.

Operate the system after approval

Approval is a controlled beginning, not the finish line. Product owners should monitor performance, incidents, complaints, overrides, drift, access failures, and changes in use. The governance board should review high-risk systems and overdue actions regularly. Leadership should examine portfolio exposure, control effectiveness, resources, and unresolved issues. Internal audit should test whether the management system works in practice, and findings should lead to corrective action.

I would avoid declaring success from a policy completion rate alone. Better indicators include inventory coverage reconciled to actual use, timely reassessments, passing control tests, serious findings by age, and outcomes for affected groups. Report severe exceptions separately; an attractive aggregate score can conceal one unacceptable system.

The standard of proof

AI models/agents have gone rogue! As we have seen recently, many AI models/agents have been involved in goal hijacking, excessive autonomy, prompt injection, unauthorized tool use, cascading failures, sensitive-data exposure, and actions outside intended boundaries. Implementing and executing an AI governance plan and architecture reduces the probability and potential impact of undesirable behavior by establishing authorization boundaries, accountability, monitoring, testing, escalation, and control mechanisms. Before a model is trained and tested, it is essential that the sandbox used to run the models is secure and isolated from other unnecessary systems.

Incorporating AI governance (which includes data and model governance) into the model and agent design is an essential step in reducing the likelihood and impact of AI failures and harms.  An organization should be able to show what AI it uses, why it was approved, who is accountable, which risks were accepted, which controls were tested, and what it will do when conditions change. That is the practical meaning of AI governance and why I incorporate three complementary frameworks. NIST helps structure risk decisions, ISO/IEC 42001 makes the process sustainable, and IEEE CertifAIEd sharpens the ethical evidence for individual systems. Together they move AI policy from aspiration into accountable operation.

I look forward to your comments on this import AI subject!