Can you run AI without a data team?

The question usually comes from a COO or a finance director who has read about AI projects run by teams of data scientists and engineers, then looked at their own organisation chart. They have an IT team of three who are already behind on the ticket queue, and nobody with data in their job title. If nobody inside understands the system, who keeps it working once the people who built it have gone?

Our view is that a company your size can run AI well without a data team, as long as four other things are in place. You probably have most of them already.

What a data team used to be for

Until recently, putting AI to work meant training a model on your own data. That took people who could clean the data, choose the method, train and tune the model, and retrain it when things changed. That was the data team's job, and it's why AI looked like something only very large companies could afford.

Most of what a company wants from AI today runs on models that have already been trained. Reading an invoice in any layout, sorting an email by what it's asking and drafting a reply from approved answers all work without a model trained on your data. They need the model connected to your systems, given your rules, and checked against your real cases. That's integration and process work, and it's done by people who know your systems and your process.

What the work needs instead

Four things keep an AI system useful once it's running, and each of them needs a named person.

• An owner for the process. One person who knows how the work should be done, decides what counts as an exception and reads the numbers each week. It's usually whoever runs the process today: the finance controller for invoices, the head of customer service for tickets. It takes some of their time every week, and more in the first month.
• Access to the systems. The system has to read from and write to your ERP, CRM, ticketing tool or shared inbox, through an account of its own with only the permissions it needs. Your IT team sets this up once, the same way they would for any new tool.
• A review routine. A fixed slot each week when the owner looks at a sample of what the system did, the exceptions it passed on and the measure. It's the same habit as checking a new starter's work, and it catches drift before customers do.
• Someone to call. When a supplier changes their invoice layout or an update breaks a connection, someone has to notice and fix it. That can be a partner on a support arrangement or, later, someone on your own staff trained to do it.

Buy, partner or hire

With those four in view, deciding who does what gets simpler.

Buy the model and the tools

A company your size has no reason to build its own AI model. Pay for access to one, through a service with clear terms on where your data goes and whether it's used for training. If a ready-made product already handles your process and connects to your systems, buy that too. AI security without a security team covers what to ask about your data.

Bring in a partner for the build and the upkeep

Connecting the model to your systems, designing what happens to exceptions and testing against your own history is specialist work that comes in bursts. A partner who has done it before can do it without pulling your IT team off their queue. After launch, the same partner can be the someone to call: watching the system, fixing what changes and reporting on the measure. Before you choose one, ask who owns the system afterwards and get the answer in writing.

Hire when there's steady work

Hire once there's enough steady work to fill a role. That point usually comes after a few systems are running and someone in operations or IT is already spending real time on them. Often the right person already works for you: someone who knows the ERP and the business, wants the job, and can learn it alongside the partner.

What operating it means after launch

Launch is the start of the longest part of a system's life. A system that reads supplier invoices will meet new layouts, new suppliers, a change in the ERP and a change of staff in finance, often within its first year. Operating it means someone deals with each of those as it happens.

In practice it comes down to a short list of routines:

• Watching the runs: volumes, failures and how many cases went to a person, with an alert when any of them jumps.
• Sampling the output: a handful of routine cases each week, checked by the process owner.
• Fixing what changes: a new layout, a renamed field, a connection that stopped working.
• Reporting the measure each month against the reading taken before launch.
• Keeping the documentation current, so the system never depends on one person's memory.

Each routine needs a named person at both ends: the owner inside your company, and whoever you call.

A worked example

Take a hypothetical wholesaler of six hundred people. Orders arrive as emails and PDF attachments in a shared inbox, and three people in customer service type them into the ERP. There's no data team. IT is two people who look after the laptops, the network and the ERP.

The head of customer service owns the process. IT creates an account for the system in the ERP and the inbox, with access to orders and nothing else. A partner builds the system, tests it against a few months of past orders, and sets up the routine. Orders that read cleanly go straight in. Anything unclear goes to one of the three people, with the email and the draft order side by side. Every Monday the head of customer service checks ten orders the system entered and looks at the exception count.

When a large customer changes its order form, the exception count jumps. The partner sees the alert, and the fix goes in before a backlog builds. Nobody in the company has data in their job title, and the system still has an owner, a weekly check and someone looking after it.

What to do this week

1. Pick the process you'd start with and name the person who owns it today.
2. Ask IT what it would take to give a new system its own account in the systems that process uses.
3. Choose the weekly slot for the review and who will do it.
4. Write down who you'd call if it broke, and what you'd expect them to do.

If all four have answers, you're ready. Operating the system after launch is the part we'd take on with you: watching the runs, fixing what changes and reporting on the measure each month.

Get the next article when it's published.