SMEs Don't Need a Data Team to Get AI Working

OECD surveys from 2024 and 2025 show SME AI adoption rising fast, concentrated almost entirely in off-the-shelf generative tools for marketing copy, document drafting, and routine correspondence. Broad adoption, shallow results. The firms that converted experimentation into measurable productivity gains were not the ones that hired data scientists. They were the ones that put a single business employee in charge of the workflow and held that person accountable for the output.

That observation is worth sitting with. Because the default assumption among SME leaders is that AI value requires technical depth, and the data does not support it.

The bottleneck is not where you think it is

When SME AI projects fail, the post-mortems point to absent ownership, unclear success metrics, and unstructured vendor relationships. Not missing data scientists. Academic readiness frameworks for SMEs identify strategy and workflow capability as the primary readiness variable. Data science headcount does not appear in the top predictors of early success. What appears instead: a defined internal owner, a structured vendor relationship, and a measurement baseline set before deployment begins.

This is uncomfortable if you have been budgeting for a technical hire. The research suggests you are solving the wrong problem.

Recruiting a specialist takes months. Onboarding adds more. By the time a new data scientist understands your workflows well enough to configure anything useful, a business-side employee with vendor support and a clear brief could have completed a 60-day deployment and produced a number worth reporting to your board.

What 60 days actually requires

Buy a mature SaaS tool. Not a platform requiring custom model training. Not an API integration project. A tool built for your use case, sold to firms like yours, with a vendor support team whose job is configuration. HubSpot's AI content features, Xero's automated reconciliation, Intercom's AI agent for customer support — these are the tier of tool this plan targets. Mature, documented, vendor-operated at the infrastructure level.

Appoint one person internally as the champion. This person does not need to understand transformer architecture. They need to understand the workflow the tool touches better than anyone else in the firm. Their job is to own the vendor relationship, set the measurement baseline on day one, verify outputs weekly, and report results at day 30 and day 60. One person. One workflow. No committee.

Work the vendor hard in weeks one and two. The configuration work belongs to them. Your champion's role in that phase is to supply the business context the vendor cannot infer: what a good output looks like, what the edge cases are, what compliance constraints apply to your specific operation. The vendor handles the technical setup. Your champion handles the brief.

From week three onward, the champion reviews outputs against the baseline. Not impressionistically. Against a number. If you deployed an AI drafting tool for customer proposals, the baseline is the time your team previously spent per proposal and the conversion rate on those proposals. Day 60, you compare. If neither number moved, the tool is not working and you stop or reconfigure. If one moved, you have a result worth scaling.

The governance gap is real, but it sits one tier above where this plan operates

The academic literature on AI barriers in SMEs makes a specific argument worth taking seriously. When AI outputs feed decisions or trigger automated actions, a non-technical reviewer cannot detect the failures that matter most. A document tool that silently passes customer data to a vendor's training pipeline produces no error message. A routing model with a bias in its training data returns a plausible-looking output. A business champion reviewing for quality sees a completed task, not a corrupted process.

This is a real risk. The research that raises it is sourced and specific, not theoretical hand-wringing.

The rebuttal is not that the risk is overstated. The rebuttal is that the risk applies to a different tier of use case. Custom-trained models, automated decision pipelines, integrations touching sensitive data at scale — these require technical oversight. The 60-day plan does not touch them. Mature SaaS tools in the content generation and document drafting tier operate under vendor contractual accountability for data handling and security architecture. Your champion is not doing model governance. The vendor is. That division of labour is what the practitioner literature on build-versus-buy decisions recommends for firms at this stage.

The governance argument is a scope boundary, not a refutation. It tells you where the operational ownership model stops working: when you move from routine-task SaaS into decision-support automation. The 60-day plan does not go there. If you eventually want to go there, the research describes a middle path where early value arises without specialists, then technical literacy becomes necessary as use cases scale. That is a later problem.

Why operational ownership beats technical expertise at this stage

The firms that got measurable results from early AI deployment shared a structural pattern: one internal owner accountable for outcomes, a vendor handling configuration, and a measurement baseline set before the tool went live. Survey and case study evidence links this structure to early success regardless of whether a specialist was present.

The specialist hire solves a configuration problem. The champion solves an accountability problem. Configuration, for mature SaaS tools, is the vendor's job. Accountability is yours, and you cannot outsource it.

I find the McKinsey-style "AI readiness assessment" approach genuinely counterproductive here, the kind of six-week diagnostic that produces a slide deck about your organisation's AI maturity and delays actual deployment by a quarter. Skip it. The 60-day plan produces a number. The readiness assessment produces a framework. One of those is useful.

Appoint the champion this week. Set the baseline before the tool goes live. On day 60, you will have a result or a clear reason to stop. Either outcome is more useful than another month of evaluating whether you are ready.