Who should own AI inside an SME? Use a federated model: one executive sponsor owns direction and risk, each workflow has a business owner, a technical steward owns the system, a risk reviewer challenges consequential decisions, and trained users operate it. A small monthly governance forum coordinates these roles; it should not become a large central AI department.
The operating model is the missing layer
Buying an AI tool does not decide which workflow deserves investment, who may connect it to company data, what quality is acceptable, who handles exceptions or whether the result created business value. Those are operating-model decisions. Without them, AI remains a collection of personal subscriptions and disconnected pilots.
The 2026 OECD D4SME survey describes rapid SME uptake but uneven strategic, targeted and secure integration. It also highlights familiar constraints: time, maintenance cost and skills. OpenAI's current enterprise research similarly points to workflow design, governance, ownership, literacy and quality as the conditions behind sustained adoption. An SME cannot copy a multinational's committee structure, but it still needs those functions.
The right design is deliberately small. Centralise policy, portfolio visibility and reusable foundations. Distribute workflow ownership to the people who understand the work. Add independent review when consequence requires it. That is a federated model: common rules and evidence, local accountability.
My SME AI Operating Loop
I use a six-stage loop to keep strategy connected to daily operations: Frame → Select → Deliver → Assure → Operate → Learn. Every proposed system has to move through the same visible loop, but the depth of evidence changes with risk.
- Frame: name the workflow, business owner, users, current baseline, desired outcome and non-negotiable constraints.
- Select: compare the opportunity with the rest of the portfolio using value, feasibility, evidence readiness and consequence.
- Deliver: redesign the workflow, define data and tool contracts, build the smallest controlled release and preserve a human path.
- Assure: test representative cases, permissions, failure recovery, security, escalation, cost and business acceptance.
- Operate: assign service ownership, monitor accepted outcomes and exceptions, support users and maintain dependencies.
- Learn: review evidence monthly, correct the workflow, scale what works and retire what no longer earns its place.
This is not a waterfall. A production incident may send the system back to Deliver; a changed law or process may send it back to Frame. The loop creates an accountable route for change instead of letting silent prompt and permission changes accumulate.
Five roles, not a large AI department
| Role | Primary responsibility | Decisions and evidence owned |
|---|---|---|
| Executive sponsor | Sets direction, risk tolerance and investment boundaries | Portfolio priorities, stop/scale decisions, unresolved high-impact risks |
| Business owner | Owns the workflow, baseline, outcome and affected people | Problem definition, acceptance criteria, process change and realised value |
| Technical steward | Owns architecture, data contracts, access and operational reliability | Integration design, technical controls, release and recovery evidence |
| Risk reviewer | Provides independent challenge proportionate to consequence | Required controls, exceptions, residual-risk recommendation and review record |
| Workflow users | Use, verify and improve the changed process | Feedback, correction, escalation and adherence to approved use |
One person may hold more than one role in a small company, but a consequential decision should not collapse into one unchecked identity. The developer who built an agent should not be the only person defining success, accepting residual risk and declaring business value. Separate perspectives even when headcount is limited.
Executive sponsor
The sponsor turns AI from an IT experiment into a business portfolio. They set the outcomes that matter, the organisation's tolerance for consequence and the amount of attention and money available. They remove cross-functional blockers and make explicit stop, hold or scale decisions. They do not approve every prompt or become the default product manager.
Business owner
The business owner is accountable for the changed workflow, not merely the AI output. They define the baseline, acceptance criteria, exception ownership and effect on customers or employees. If nobody from the function will own the post-launch process, the proposal is not ready for selection.
Technical steward
The technical steward protects the architecture and production path: identity, data sources, integrations, permissions, evaluations, logs, release, recovery and vendor dependencies. This may be an internal technologist or an accountable partner, but responsibility must be named and evidence must remain accessible to the SME.
Risk reviewer
The risk reviewer challenges assumptions and confirms controls in proportion to impact. Depending on the workflow, this perspective may come from security, privacy, finance, HR, legal or an operational control owner. The reviewer advises; executive and business owners remain accountable for the decision.
Workflow users
Users supply operating reality. They need training on delegation, verification, data handling, escalation and correction. Their feedback should enter a managed queue, not disappear into private chats. A workflow that passes a test set but fails under real workload, timing or customer pressure has not succeeded.
A lightweight RACI for AI work
A RACI distinguishes who is Responsible, Accountable, Consulted and Informed. Keep one accountable owner per row. The table below is a starting pattern, not a universal allocation; regulated or high-impact work may need stronger independence.
| Activity | Business owner | Executive sponsor | Technical steward | Risk reviewer |
|---|---|---|---|---|
| Define workflow outcome and baseline | A/R | C | C | C |
| Prioritise the portfolio | R | A | C | C |
| Design data, tools and controls | A | C | R | C |
| Evaluate representative cases | A | C | R | C |
| Approve production release | R | A | C | C |
| Run, monitor and improve | A | I | R | C |
Download the SME AI operating-model RACI and monthly governance cadence.
One intake path for every AI idea
Do not let proposals begin as vendor demos. Use one short intake record for employee ideas, department requests, vendor products and technical experiments. Capture the problem, affected workflow, current baseline, users, data, systems, desired outcome, consequence of error, business owner and first decision requested.
The intake should be easy enough to complete in 20 minutes. Its purpose is not to justify a purchase; it makes competing needs comparable. Record rejected and deferred ideas too, with reasons, so the same proposal does not repeatedly restart without new evidence.
Prioritise a portfolio, not a queue of excitement
Score each idea across four dimensions:
- Outcome value: capacity, cycle time, quality, revenue protection, risk reduction or customer experience.
- Workflow fit: repeatability, stable inputs, clear rules, available exception owner and manageable change.
- Evidence readiness: baseline, representative examples, authoritative data and measurable acceptance criteria.
- Consequence: financial, legal, safety, employment, privacy, customer and reputational impact if wrong.
High value does not cancel high consequence. It changes the delivery path: stronger evaluation, tighter permission, more human review and a narrower first release. Weak evidence should lead to a baseline study, not optimistic scoring.
Limit work in progress. One SME can learn more from two owned pilots than ten stalled proofs of concept. Reserve capacity for operating existing systems; maintenance, evaluation and incident handling compete with new development.
Use evidence gates through delivery
The operating forum should ask for progressively stronger evidence:
- Discovery gate: the problem, baseline, owner and users are real; AI is not presumed to be the answer.
- Design gate: responsibilities, data, tools, permissions, exceptions, human oversight and measures are explicit.
- Pilot gate: representative cases, acceptance thresholds, budget, support and stop conditions are approved.
- Production gate: evaluation, security, recovery, monitoring, training and service ownership have evidence.
- Scale gate: accepted outcomes and operating cost justify a larger scope; severe failure remains controlled.
NIST's AI RMF supports this lifecycle view: governance should define roles and accountability; mapping establishes context and business value; measurement evaluates performance and risk; management prioritises action. An SME can use those functions without pretending that a five-row checklist is full risk management.
Govern by consequence
A weekly internal summariser and an agent that changes customer credit should not face the same process. Create three practical tiers:
- Tier 1 — assistive: reversible drafts with a knowledgeable user reviewing before use.
- Tier 2 — operational: bounded actions in business systems with tested validation, permission and exception paths.
- Tier 3 — consequential: decisions or actions affecting money, rights, safety, employment, sensitive data or material customer outcomes.
As the tier rises, require more independent review, evaluation coverage, approval control, monitoring and executive visibility. A change in tool access, user population, data sensitivity or action authority can move a system into a higher tier even when the model is unchanged.
Fund outcomes and operating ownership
Separate discovery money from production commitment. A small discovery budget can establish the baseline, map the workflow and test feasibility. A pilot budget should include integration, representative evaluation, user time and control design. Production funding must also cover monitoring, review, support, vendor changes, retraining, incidents and eventual retirement.
Give the business owner a benefit target and the technical steward an operating-cost envelope. Do not count model tokens as the business case. Measure accepted outcomes after human correction, downstream completion and exception handling.
A monthly governance cadence that fits an SME
Run a 60-minute monthly forum with the sponsor, business owners, technical steward and relevant risk reviewer. Send a one-page portfolio before the meeting. Use the time for decisions, not demonstrations.
- 10 minutes — operating health: severe incidents, failed controls, unresolved exceptions and material vendor changes.
- 15 minutes — outcome evidence: accepted completion, quality, cycle time, cost and user impact against baseline.
- 15 minutes — portfolio decisions: approve, hold, stop or scale proposals using the same prioritisation logic.
- 10 minutes — risk and change: permission, data, policy, regulation, workflow and population changes.
- 10 minutes — actions: one owner and date for each decision; update the portfolio and system register.
High-impact incidents should not wait for the monthly meeting. Define immediate escalation and stop authority. The cadence is for portfolio control and learning, not emergency response.
Report a small set of decision metrics
Executives need a portfolio view; business owners need workflow evidence; technical stewards need reliability detail. Use a short scorecard:
- active ideas, discoveries, pilots and production workflows by risk tier;
- named owner coverage and overdue review actions;
- accepted outcome rate and performance against baseline;
- exception, correction and human-review burden;
- operating cost per accepted outcome;
- severe incidents, permission violations and unresolved control failures;
- user adoption, training completion and material feedback themes;
- systems to scale, hold, remediate or retire.
A green project status with no outcome evidence is not green. Likewise, strong adoption does not excuse uncontrolled data use. Report value, operation and risk together.
What not to build
- A central team that owns every workflow: it becomes a bottleneck and separates delivery from domain accountability.
- A committee that only says no: governance should create safe routes to useful work and faster decisions.
- An innovation lab without production ownership: demos accumulate while integration, evaluation and support remain unfunded.
- A champion network without controls: enthusiasm is valuable, but champions need approved tools, escalation and technical support.
- A vendor-led roadmap: technology categories should follow workflow priorities, not define them.
A 30-day setup sequence
- Week 1: name the sponsor and technical steward; inventory current AI tools, workflows and owners.
- Week 2: adopt the intake, four-dimension prioritisation and three consequence tiers; choose one business owner.
- Week 3: apply the RACI and evidence gates to one active workflow; close obvious permission and ownership gaps.
- Week 4: run the first monthly forum, make explicit stop/hold/scale decisions and publish the one-page scorecard internally.
The outcome is not an AI department. It is a repeatable management system: ideas enter one door, decisions use common evidence, delivery has accountable owners, production remains observable and learning changes the portfolio. That is enough structure for an SME to move faster without losing control.
Primary sources
- OpenAI — How enterprises are scaling AI
- OpenAI — From assistance to execution
- OECD — Empowering SMEs in the age of AI
- NIST — AI Risk Management Framework Core
Continue the implementation path
- The minimum viable AI governance pack
- My AI automation delivery framework
- The AI-enabled company of 2027
Make AI an owned operating capability
Design your SME AI operating model
I help leadership teams turn scattered AI experiments into a governed portfolio with named owners, delivery gates, operating evidence and measurable outcomes.
Design an AI operating model