The question nobody has answered
Who in your business actually owns AI?
There's rarely a clear answer. IT says it's a business decision. Leadership says IT owns the tools. HR hasn't been asked. And out in customer service, people are already using ChatGPT to answer customers — without anyone formally deciding that's okay.
This isn't a hypothetical. It's the most common situation we come across.
The fix is rarely a new hire or a new system. It's a structure that already exists elsewhere in your business: a cross-functional committee with defined roles, that meets on a regular cadence and actually has a mandate to decide things.
Having a plan is no longer optional
From 3 August 2026, the AI literacy requirement in the EU AI Act (Article 4) becomes enforceable. It applies to every business using AI systems — not just the ones building them, and not just high-risk systems. You need to ensure that employees who use or are affected by AI have a sufficient understanding to use it responsibly.
The law doesn't say how to do this. There's no pass/fail test, no prescribed structure. But it does say you need to be able to document that you've done something — and "we sent out an email about ChatGPT last year" doesn't hold up.
An AI committee is the most practical way we've seen businesses actually pull this off.
The model: one AI owner per department
The structure we recommend is simple to describe, though it takes some real work to set up properly.
Each department — sales, customer service, HR, finance, operations — designates one person as that department's AI owner. Not necessarily the most technical person. The one who actually knows how the department works, where the time sinks are, and where the boundaries should sit.
These representatives form the committee. It should have a fixed core — typically someone from IT/security, someone from HR or legal, and someone from leadership with real decision-making authority — plus the department representatives, who join as needed rather than at every single meeting. That's the same principle Mastercard uses in its AI Council: a fixed core team (privacy, data, security) plus relevant business leaders pulled in case by case, when the matter actually concerns them.
There's no fixed answer for how many people should sit on the committee — it depends on how many departments you have. But the structure solves something concrete: without it, either IT decides everything (and misses what's actually useful for customer service), or everyone decides for themselves (and nobody knows what's actually happening).
How often should the committee meet?
Here's something we want to be honest about: neither NIST's AI Risk Management Framework nor ISO 42001 — the international certification standard for AI management systems — prescribes a fixed meeting cadence. And when we look at how real companies actually do this, it happens less often than you'd expect. Weekly meetings are rare in practice; monthly or quarterly is the norm.
Our recommendation is a two-tier model:
- The core group meets monthly. Policy, new tools under review, and issues escalated from departments.
- Department representatives report on an ongoing basis — not in scheduled meetings, but whenever something actually happens: a new use case, a concern raised by an employee, a tool someone has started using without approval.
The reason we don't recommend weekly meetings for the full committee is simple: too tight a meeting cadence without real substance to discuss is exactly the kind of governance that quietly disappears after three months because nobody can be bothered anymore. We've seen it repeatedly. A committee that meets too rarely loses control. One that meets too often without substance loses buy-in. Both end the same way: it stops functioning.
What the committee actually decides
Three concrete areas of responsibility, not a vague "AI strategy":
1. What can be automated — and what shouldn't be. This isn't just a technical question. It's a question of how much autonomy you're comfortable handing over, and who takes responsibility when it goes wrong. The committee sets the boundaries; the department knows the consequences.
2. How to ensure affected employees are involved — not just informed after the fact. EU AI Act Article 26(7) is specific here: before deploying a high-risk AI system in the workplace, you must inform both workers' representatives and the affected workers — in advance, not after the fact. And notice what the law actually classifies as high-risk in this context (Annex III): AI used for CV screening and candidate evaluation, and AI used to allocate tasks or monitor and evaluate employee performance. For most businesses, that's not a theoretical category — it's exactly the kind of tool many have already adopted for recruitment and performance tracking.
In Norway, this sits on top of Arbeidsmiljøloven § 4-2, which already requires necessary training when introducing new systems, and Chapter 9, which triggers a duty to discuss control measures with employee representatives before they're implemented — something an AI system that monitors or evaluates employees will often qualify as.
3. How to ensure AI works as well for customer service as it does for leadership. This might be the most overlooked point. A PwC and Manufacturing Institute analysis found that 45% of companies with failed AI initiatives pointed to frontline leaders not being involved in the design. 54% said they had low confidence that frontline leaders were ready to lead AI change in their own area. The pattern is a familiar one: tools get chosen and tested by people who work with reports and analysis, and work brilliantly for them — but never get adapted to the workday of the people answering the phone. A customer service representative on the committee isn't symbolic. It's the only way you actually find out whether the tool works where it's used most.
Invest in AI literacy — not just for the committee
The committee can't do its job without genuinely understanding what it's evaluating. That means structured training — not a one-hour "intro to ChatGPT," but real understanding of what kind of data different tools send outside the business, which decisions AI can and shouldn't make alone, and how to evaluate a new tool a department wants to adopt.
And because each representative sits in their own department, you get a secondary effect worth just as much: every department gets its own AI resource person. Not a central IT department everyone has to wait on, but someone sitting where the work actually happens, who can answer questions the same day. That's what turns the Article 4 literacy requirement into something real, instead of a one-off email nobody remembers six months later.
What the committee doesn't solve on its own
We should be honest about the weaknesses too. Two things commonly go wrong:
Governance theater. A committee that produces guidelines nobody follows is worse than no committee at all — it creates a false sense of "we've got this handled" while the reality is a policy sitting in a forgotten SharePoint folder.
Decision bottleneck. If the committee insists on approving every single AI use, it becomes the problem itself. Not everything needs committee review. Set a simple threshold: low-risk tools (writing assistance, internal research) can be approved locally by the department representative. High-risk use (customer data, employee evaluation, automated decisions) should always go to the core group.
A committee that works is one that actually has the mandate to say no — and a clear enough process that "yes" doesn't take three weeks.
What IT Buddy does
We help businesses set up exactly this structure — not a generic template, but a committee shaped around how you're actually organized. And we don't stop at the report. Mapping without training gives you a committee that knows where the boundaries should be, but not why — and that's exactly where most AI initiatives stall.
Our workshops are built specifically to give department representatives that understanding: what kind of data different tools actually send outside the business, which decisions AI can and shouldn't make alone, and how to evaluate a new tool their department wants to adopt in practice. That's the difference between a committee that exists on paper and one that can actually answer when someone asks.
Concretely, we're with you from mapping through to the committee functioning in practice:
- Mini governance report mapping where AI is already being used in your business today, often without leadership knowing
- RBAC setup defining who has access to what — a prerequisite for the committee to be able to set real boundaries
- DPIA-light for the high-risk use cases that Article 26 and Annex III actually cover
- Workshop-based AI literacy training for department representatives, tailored to their committee role — not a generic "AI for everyone" session, but the training that makes them capable of actually making the decisions the committee exists to make
AI doesn't start with technology. It starts with structure.
Get in touch for a free AI Ready assessment →
Read also: What Is AI Governance – and Why Is It Your Responsibility as a Leader? · AI in Recruitment: What You Can Automate, What the Law Requires, and Where Responsibility Lies