Who decides whether the marketing team can start using an AI image generator? Or whether finance can connect an AI tool to the accounting system? At most mid-size organizations I assess, the honest answer is “nobody,” or “IT, by default.” Requests arrive by email, someone in IT makes a judgment call without the legal or business context, and the decision is either a reflexive no or an unrecorded yes.
The other common pattern is the opposite. Someone proposes a formal AI governance committee modeled on a large enterprise: a dozen members, a long charter, quarterly meetings. It meets twice, the agendas get thinner, and by the third quarter it has quietly stopped. What actually works at mid-size scale sits between those two: a small cross-functional council that meets for thirty minutes a month, with a clear intake process and a fast track for low-risk requests.
Why “IT by default” doesn’t work
IT can judge whether a tool is secure and whether it will work with your systems. It isn’t well placed to judge legal exposure, the effect on employees, or whether the business value justifies the risk. When IT decides alone, one of two things happens: IT says no to protect itself, becoming the department of no, or IT says yes without seeing risks outside its expertise. Neither is IT’s fault. It’s a structural gap.
Here’s how the assessment asks the question, and the 0 to 4 ladder I score it against:
G2. Who decides which AI tools and projects get approved?
- Nobody; it happens ad hoc
- IT, by default
- An informal group, when issues come up
- A cross-functional group (IT, security, legal, business)
- A cross-functional AI council with a defined intake, review, and approval process
Level 2 is reactive: a group convenes when something goes wrong. Level 3 is proactive but can be slow. Level 4 adds the process that makes decisions consistent and fast, and that’s the part that makes a council stick rather than fade.
Designing a council that lasts
Members: five or six people
- Executive sponsor, or a delegate, as chair.
- IT lead, for feasibility and operations.
- Security, for data protection and vendor risk.
- Legal or compliance, for contracts and regulations.
- HR, for employee impact and anything touching decisions about people.
- One or two business representatives, rotating, often your AI champions or current business owners.
More than six and the meeting stops fitting in thirty minutes. Fewer than five and you lose a perspective you’ll need.
Cadence: thirty minutes, monthly, plus a fast track
Monthly is enough for most mid-size organizations, as long as low-risk requests don’t have to wait for the meeting. The fast track (below) handles those in days.
A standing agenda
- Five minutes: anything urgent from the intake queue.
- Ten minutes: tool and use-case decisions that need the full council.
- Five minutes: status of pilots and the use-case register.
- Five minutes: incidents, near misses, and new risks.
- Five minutes: changes to the policy, the approved tools list, or the inventory.
The asset: an intake form, a triage rule, and a one-page charter
The intake form
Every request for a new AI tool, feature, or use case comes through one form. Keep it to nine fields:
- Requester and department.
- Tool or use case, in one sentence.
- Business purpose and expected benefit.
- Highest data tier involved, using the tiers in your AI acceptable use policy.
- Number of users.
- Vendor, with answers to the AI questions from your vendor security review.
- Any integrations or access to company systems.
- Cost.
- Urgency and reason.
The triage rule
- Low risk: an already approved tool, or a new tool used only with public information, with no integrations. IT approves within five business days and reports it to the council.
- Medium risk: a new tool for internal information, or a read-only integration. Security reviews it, and the council approves asynchronously by email or chat within ten business days.
- High risk: regulated or confidential data, write access to company systems, customer-facing automation, or any use that affects decisions about people. Full council review at the next meeting, or a special session if it’s urgent.
Most requests turn out to be low or medium risk. The triage rule is what keeps the council’s thirty minutes for the decisions that deserve them.
The one-page charter
- Purpose: “To approve AI tools and uses, balancing value and risk, quickly and consistently.”
- Members and chair.
- Decision rights: what the council decides, what it delegates to IT and security, and what it escalates to leadership.
- Cadence and service levels: monthly meeting, fast-track timelines.
- Records: every decision logged.
The first three meetings
Meeting one: approve the charter and the triage rule, and agree who runs the intake form. If you don’t yet have a published acceptable use policy, approving version 1 is the best possible first decision.
Meeting two: review every AI tool already in use that anyone knows about. Most will be quick approvals with conditions; a few will need follow-up. This is the start of your inventory.
Meeting three: review the use-case register and agree which one or two items become pilots, each with a business owner. From here the standing agenda takes over.
Keep a decision log
Log every decision: date, request, decision, conditions, rationale, and a review date if the approval is conditional. It takes a minute per decision and pays off repeatedly. It keeps decisions consistent over time, it answers “why did we allow this?” months later, and auditors and customer security questionnaires increasingly ask for exactly this kind of record. The log also feeds straight into your AI inventory.
A decision rule for the council itself
If the council is slower than shadow AI, shadow AI wins. Track how long requests take from intake to decision. If low-risk requests take more than a week, people will stop asking. The council’s credibility depends on saying yes quickly to reasonable requests, so that its occasional no carries weight.
What moving up one level looks like
From 0 or 1 to 2: agree who gets called when an AI question comes up, even informally. From 2 to 3: turn that group into a standing cross-functional council with a monthly meeting. From 3 to 4: add the intake form, the triage rule, and the decision log. Each step takes weeks, not quarters, because none of it requires new technology; it requires a calendar invitation and a short document.
Mistakes I see at this stage
Too many members. Every additional person makes the meeting longer and decisions slower. Consult people outside the council when needed instead of adding them.
No decision rights. A council that can only recommend becomes a discussion group. Give it authority to approve.
No fast track. Routing every request to a monthly meeting guarantees a backlog and workarounds.
No business voice. A council made up of IT, security, and legal leans toward no. Business representatives keep the value side of the conversation alive.
Treating the council as a review of IT. It’s a shared decision forum, not an oversight board for the IT department.
For how the council fits into the broader operating model, including ownership, policy, and reporting, see AI governance for mid-size IT.
Where does your team actually stand?
AI decision-making is one of 24 questions in the AI Readiness assessment, which covers six dimensions: data, security, infrastructure, skills, use cases, and governance. The free version is 10 questions and gives you a score in a few minutes.
Get your free AI Readiness Score →
Want to see what the full assessment covers first? Flip through a complete 38-page sample report.
Related guides
- Turn Your Painful-Process List Into an AI Use-Case Register
- Publish Your AI Acceptable-Use Policy This Month (3-Tier Template)
- Two Questions to Add to Every Vendor Security Review This Year
- Build Your AI Inventory in Two Weeks (Auditors Will Ask)
- AI Governance for Mid-Size IT: The Lightweight Operating Model
Frequently asked questions
Who should be on an AI council at a mid-size company?
Five or six people: the executive sponsor or a delegate as chair, the IT lead, security, legal or compliance, HR, and one or two rotating business representatives. More than six and the meeting stops fitting in thirty minutes.
How often should an AI council meet?
Thirty minutes a month is enough for most mid-size organizations, as long as low-risk requests don't have to wait for the meeting. A triage rule lets IT approve low-risk requests within days and handles medium-risk ones asynchronously.
What is an AI intake triage rule?
A rule that sorts requests by risk. Low risk, such as an approved tool or public information only, is approved by IT and reported. Medium risk gets a security review and asynchronous approval. High risk, such as regulated data, write access, or decisions about people, goes to the full council.
Why keep an AI decision log?
It keeps decisions consistent over time, answers why something was allowed months later, and gives auditors and customer security questionnaires the record they increasingly ask for. It also feeds directly into your AI inventory.
