Luis Ibarra is the Chief Technology Officer at PingWind Inc.
I recently read an argument that AI governance belongs in the boardroom rather than the IT department. The intention is right. Boards must own accountability for AI risk. But that framing treats governance like something you can move from one organizational box to another, and it doesn’t hold up in practice.
In my experience, shifting responsibility doesn’t fix a broken interface. It often adds friction between the people building the technology and the people responsible for governing it. I’ve sat in enough of those conversations to know the frustration is real on both sides.
The visibility problem that argument describes is genuine. Nobody serious thinks executive leaders should hand accountability to IT and walk away. Most boards don’t have what they need to govern AI effectively. But telling a board to pay closer attention doesn’t build the infrastructure that gives them something useful to pay attention to. That’s not an accountability gap. It’s an interface failure.
The Gap Is Not A Lack Of Accountability
Boards and technical teams shouldn’t do the same job. A director does not need to review every architectural choice. A developer should not spend the week preparing executive updates. Each role has a different duty, a different time horizon and a different relationship to risk. Trying to erase those differences produces performative oversight, not better decisions.
The National Institute of Standards and Technology makes a related point in its AI Risk Management Framework. Governance is a cross-cutting function, meant to inform mapping, measurement and management of risk across the system life cycle. That’s a stronger model than treating governance as a meeting held after the work is done.
Here’s the hard truth: When understanding only arrives in the form of a periodic briefing or a quarterly slide deck, every decision-maker in the organization is governing the past.
Moving the responsibility box doesn’t solve that problem. A board can’t govern what it can’t see in time. Nor can an IT organization carry enterprise accountability by itself. The failure is an interface failure: The organization hasn’t designed a reliable way for the work, the risk and the decision to meet, while a decision can still change the outcome.
The Work Should Create Its Own Context
The answer isn’t to turn executives into engineers. It’s to give them current, decision-ready context at the altitude their responsibilities require. In the model I’ve been developing, that context is produced from the work itself rather than assembled afterward for a meeting. As the work changes, the organization should be able to see what changed, why it changed, what is blocked, what new risk has appeared and where a decision is pending.
Call it living context. It’s not a dashboard full of activity counts, and it’s not another polished status report. It’s a continuously refreshed explanation of the state of the work. A leader who sees a pending decision with its rationale and risk can engage. A leader who sees only that a project is green cannot.
This is where many governance programs get bogged down. They collect documentation after the fact, then mistake the record for situational awareness. Documentation matters. ISO/IEC 42001 is explicit that an AI management system should establish, implement, maintain and continually improve organizational processes for responsible AI. ISO’s overview of the standard describes it as a framework for managing risks and opportunities across an organization. But a defensible record and a current operating picture serve different purposes.
One helps leaders govern a live decision. The other helps an organization show, later, what it built, decided and controlled. Both are necessary. Neither should be created by asking people to reconstruct reality from memory at the end of the quarter.
Put Judgment Where It Earns Its Keep
Continuous context doesn’t mean continuous executive involvement. Most changes should stay with the people closest to the work, inside clear architectural and risk guardrails. The point is to identify the moments that need broader judgment and make those moments short, specific and consequential.
I call those moments judgment gates. The question isn’t, “What did everyone do this week?” It’s, “Does this prototype meet the intent, and do we proceed, redirect or refactor?” That’s a useful conversation because it has an object, a decision and an accountable outcome.
For leaders, the first move isn’t to form another standing committee. Ask where your organization currently gets its understanding of AI work. If the answer is a manually assembled update, find the workstream where the lag is most dangerous and redesign the interface there. Define the guardrails. Create a simple feed of changes, risks and pending decisions. Then establish a clear trigger for when human judgment must enter the loop.
I learned in the Coast Guard that situational awareness isn’t the same as receiving more information. It means having the right information before the decision window closes. AI governance has the same requirement. Leaders don’t need to see every line of code, and builders don’t need an executive meeting for every change. Organizations don’t need everyone to see the business the same way. They need everyone to see the same business.
The board’s job and the builder’s job are different. What they share is the consequence of getting AI governance wrong.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?