Own the harness: local AI in the ERP year

A medium-sized company moving from SAP into Microsoft has a rare opening.

For 12 months, the business is already on the table. Finance codes are being mapped. Supplier records are being cleaned. Approval routes are being argued about. Permissions are being rebuilt. Reports are being challenged. People are being asked, often for the first time in years, why the work happens the way it does.

That is exactly when the AI decision should be made.

Not the easy decision: which model should we buy?

The harder and better one: will we rent the process, or own the harness?

The model is not the asset. The harness is.

Models are replaceable. The data is not.

What a harness actually is

A harness is the rig around the model.

It is the bit that turns a clever model into a business tool. It gives the model a job, feeds it the right context, sets the limits, lets it use approved tools, checks the answer, records what happened, and knows when to hand back to a person.

Without a harness, a model is a clever stranger with a keyboard.

It can write. It can guess. It can sound confident. It can be useful in bursts. But it does not know your business unless you build the route between the model and the business.

A better picture is a private workshop with an engine test rig inside it.

The AI model is the engine. You can swap it. One engine today, another tomorrow.

The harness is the rig around it: the controls, gauges, adapters, safety rules, tools, memory and test procedures that let you run the engine properly.

Buying AI without that rig is like buying a racing engine and leaving it on the pallet. Impressive, expensive, and not much use to the person trying to get home.

Context is the material you put in front of the engine so it knows what job it is doing. In a business, context might be:

• documents,
• past chat history,
• customer records,
• code files,
• company policies,
• the current task,
• tool outputs,
• user preferences.

The model itself does not automatically know those things. The harness gathers the right context, packages it up, sends it to the model, then manages the answer.

So the simple map is this:

• Model: the engine.
• Harness: the workshop rig that controls and tests the engine.
• Context: the maps, instructions, parts and job sheet placed in front of it.
• Tools: the machines in the workshop the engine can operate through the harness.
• Logs: the workshop records of what happened.
• Guardrails: the safety barriers and rules.

A good harness answers seven plain questions every time AI is used:

• What is the job?
• Which data is allowed?
• Which person is asking?
• What are they allowed to see?
• Which tools can the AI use?
• How is the answer checked?
• Where is the decision logged?

That is why the harness matters more than the model. A model gives you raw ability. A harness gives you controlled work.

This is the part companies need to own.

If you rent the model, fine. Sometimes that is the right choice. But if you rent the harness, you rent the way work moves through the company.

That is a very different dependency.

A local AI harness means the workshop is in your building, not someone else’s factory.

This is the same idea I wrote about in Harnesses: the pub operating system hiding in plain sight. A model is clever. The harness is what gives it a job, a limit and a memory.

Why the SAP-to-Microsoft year is the moment

An ERP migration is painful because it exposes the truth.

SAP has probably become more than a system. It is the memory of the company. Some of that memory is clean. Some of it is custom code, old fields, half-owned reports, local workarounds, supplier oddities, finance habits and things people stopped questioning years ago.

When a company moves into the Microsoft estate, usually Microsoft 365, Dynamics 365, Power Platform, Fabric, Teams, SharePoint and Purview in some mix, that memory has to be unpacked.

That is the useful pain.

The ugly conversations are the valuable ones. A field nobody owns is not a migration detail. It is a management fact that has finally become visible.

Do not stop at mapping SAP fields into Microsoft fields. Map the decisions.

• Who owns this record?
• Which source wins when two systems disagree?
• Which approvals are real, and which are theatre?
• Which reports are still used?
• Which old process exists only because SAP made it hard to do anything else?
• Which data should a site manager see?
• Which data should finance see?
• Which data should nobody see without approval?

Those are AI questions as much as ERP questions.

Because the AI will inherit the answers.

How open is Microsoft 365 to this?

The Microsoft answer is more open than people think, but it needs saying carefully.

You cannot assume that Microsoft 365 Copilot lets you replace its core model with any local model you like. That is not the point.

The useful opening is around the edges, where the real work happens.

Microsoft supports custom engine agents for Microsoft 365, where a business can decide how an agent runs and which model it calls. Microsoft also supports Copilot connectors, including connectors that add outside content to Microsoft Graph, the map Microsoft 365 uses to find information. Other connectors can fetch content at the moment it is needed through Model Context Protocol, or MCP. In Copilot Studio, Microsoft documents bringing your own model for prompts through Azure AI Foundry.

That matters because the Microsoft estate is where the work already happens: Teams, SharePoint, Outlook, Power Platform, Dynamics, Fabric and the login and permissions system around them.

So the strategy is not “replace Microsoft”. It is “build your harness so it can work with Microsoft, beside Microsoft and, where sensible, inside Microsoft.”

Use Microsoft 365 for login, permissions, documents, messages and work routes. Use your harness to decide which data is gathered, which model is called, what gets logged, what action is allowed and when a person must approve it.

That is a much healthier position than waiting for one vendor to decide how every AI job in the company should work.

The person entering the data is part of the harness

Most businesses talk about AI as if it starts when someone asks a chatbot a question.

It starts much earlier.

It starts when a supplier is created. When a cost centre is chosen. When a purchase order is raised. When a contract is saved. When a complaint is logged. When a property defect is categorised. When someone changes a product name because the old one looked untidy in a spreadsheet.

Every one of those moments becomes part of the answer later.

So the people creating and viewing the data need better tools, not another layer of warnings.

A good AI-ready process does not ask people to be perfect. It gives them rails:

• pick from approved values where possible,
• show the source of the fact,
• flag missing ownership,
• warn when a record conflicts with another record,
• keep sensitive fields out of casual view,
• make the next correct action obvious.

That is what I mean by honest data.

Not pretty data. Honest data.

Honest data says, “we do not know who owns this supplier record.” It says, “this policy is out of date.” It says, “this invoice code is being guessed.” It says, “this person can see too much.” It says, “this answer came from the old process note, not the signed policy.”

That kind of honesty is the foundation for useful AI.

Local AI is made for the middle

Local AI is often talked about as if it belongs only to banks, defence, government and giant tech firms.

That misses the useful middle.

A medium-sized company has the thing small companies often lack: enough repeated work to make the investment pay.

If ten people use AI twice a week, renting everything is often fine. If 800, 1,500 or 4,000 people could use it every day, the maths changes. The same questions come up again and again. The same documents are searched. The same approvals are chased. The same invoice oddities are checked. The same HR and finance questions are asked in slightly different words.

That is where local AI starts to make sense.

Local does not have to mean a science project in a cupboard. It means the company owns the route: the data, the permissions, the search and evidence trail, the checks, the logs, the tools people use and, where the work is sensitive or repeated all day, the hardware that runs the model.

The hardware case is not magic. It is simple use.

Buy private AI capacity for repeatable internal work, then use it across many seats. The more steady the demand, the faster the cost per answer falls. Keep the expensive frontier models for work that truly needs them. Do not spend premium money summarising the same policy for the thousandth time.

That gives the business practical advantages:

• Data security: sensitive files can stay on company machines or private servers.
• Privacy: prompts, files and outputs do not automatically go to an outside AI company.
• Control: the business decides which model runs, what context it gets and what it can do.
• Record of work: the business can log what was sent, what came back and which source was used.
• Freedom to switch: a better model can be swapped in without rebuilding the whole process.
• Cost control: steady internal demand is not priced like casual public AI use.
• Continuity: some work can continue even when an outside service is down.
• Rules: confidential, regulated or client-owned data can stay under tighter control.

The model is becoming the swappable part

This is the bit people keep missing.

The model market is moving too fast for model choice to be the moat.

I made the same point in Cheap AI is a trap if your data is trapped: the cleverness gets cheaper, but your context is still yours.

The Stanford AI Index 2025 reported that the inference cost for a system performing at GPT-3.5 level fell over 280-fold between November 2022 and October 2024. It also reported hardware costs falling by 30% annually and energy efficiency improving by 40% each year.

The Stanford 2026 technical performance report says top model performance is converging, with several companies clustered close together. It also says the open model gap reopened in 2025, with the top closed model ahead of the top open model by 3.3% as of March 2026.

That is not a reason to ignore local models. It is a reason to avoid building your whole process around one model.

Microsoft is already pushing small language models through Phi, including models designed to run locally, at the edge or on devices. Mistral gives self-deployment guidance for running models on your own infrastructure.

The pattern is clear enough.

What is premium today becomes normal tomorrow. What needs a large cloud model today may run locally next year. Not always. Not for every task. But often enough that the strategy should be obvious.

The gap between the best cloud model and the best local model is starting to feel like months, not generations.

If a flagship model arrives in the autumn, whatever name the market gives it, it is now reasonable to imagine a free or low-cost local model being good enough for many ordinary business processes by Christmas. Not all of them. Not the hardest ones. But enough of them to change the buying logic.

Most internal work does not need the absolute best model on earth. It needs a good enough model, properly briefed, with the right data, the right permissions, the right tools and the right checks.

There is a simple bit of business sense here. A Ferrari engine is a poor investment if most of the job is moving boxes round a yard. You need the fast car for the few journeys where speed really matters. The rest of the time, the yard needs better roads, clearer signs and a gate that opens only for the right people.

That is the harness argument again.

Own the harness. Swap the model.

What should run locally

Do not make this religious. Cloud AI is useful. Frontier models are useful. The point is not to pretend otherwise.

The point is to choose.

Local AI is a strong fit for work that happens:

• many times a day,
• in much the same shape,
• sensitive,
• tied to internal records,
• dependent on permissions,
• expensive when every answer is rented,
• risky when pasted into public tools.

In a SAP-to-Microsoft migration, that might include:

• supplier lookup and onboarding checks,
• invoice coding support,
• finance policy search,
• chart-of-accounts guidance,
• purchase order exception checks,
• HR policy answers,
• IT service desk triage,
• property defect routing,
• contract summarisation,
• migration data quality checks,
• Teams-based answers from approved internal documents.

The best cloud model still has a place. Use it for harder reasoning, specialist drafting, unusual research, or tasks where the value of the answer beats the cost and risk.

But make that a choice, not the default.

Save the true frontier models for the work where they earn the premium: security weak spots, system design, big architecture decisions and changes to the harness itself. In other words, use the expensive engine when you are redesigning the workshop, not when you are checking the same invoice rule for the 600th time.

The ERP year should build the harness in parallel

The worst time to start the AI harness is after go-live.

By then the process arguments are over. The budget is tired. The project team is leaving. The business wants calm. Everyone is tempted to bolt AI on top and call it phase two.

That is backwards.

Build the harness while the migration is happening.

The first version should be read-only.

Let it search approved documents, compare records, summarise policy, flag missing fields, explain the process, prepare drafts and show its evidence.

Then add controlled action.

Create a ticket. Draft a supplier email. Prepare an approval pack. Route an exception. Open a task. Suggest a journal explanation.

Do not give AI the steering wheel on day one. Give it a dashboard, a seatbelt and a driving test.

Guardrails are not decoration

Guardrails are part of the product.

People should not be left to paste sensitive company data into whichever AI tool they found that week. That is not adoption. That is leakage with a friendly box.

The right answer is not to ban AI. People will use it anyway. The answer is to give them tools that are safer, closer to the work and more useful than the public ones.

In a Microsoft estate, login and permissions matter. Microsoft says Microsoft 365 Copilot and Copilot Chat inherit existing controls, including sensitivity labels, retention policies and audit controls where Microsoft 365 has been set up for them.

That is good news, but it has an edge.

Bad permissions become AI risk at speed.

If half the business can read a folder today, AI may make that mistake much easier to notice tomorrow. If nobody owns document tidiness, AI will find the old file as happily as the current one. If a policy has no status, AI will not know it is stale unless the harness tells it.

So guardrails need to be built into the work:

• answer from approved sources,
• show evidence,
• respect role and permission,
• refuse restricted content,
• separate draft from decision,
• log the question and the source,
• push risky work to a human.

That is not bureaucracy. It is how you keep the tool useful.

The data work is the efficiency work

There is a dangerous fantasy in AI: that a clever model will compensate for messy data.

It will not.

It will just make the mess easier to ask questions of.

Gartner predicts that through 2026, organisations will abandon 60% of AI projects that are not supported by AI-ready data. Cloudera and Harvard Business Review Analytic Services reported that only 7% of enterprises say their data is completely ready for AI.

That sounds like a data problem. It is also a management problem.

Efficiency is bigger than faster search. It is fewer wrong handoffs. Fewer duplicated checks. Fewer approvals done twice because nobody trusts the first one. Fewer reports arguing with each other. Fewer people asking finance the same question because the answer is buried in a PDF nobody can find.

Clean data saves time before AI arrives.

AI makes the saving visible.

Own the harness, own the future

The businesses that win here will not be the ones that guessed the perfect model in 2026.

They will be the ones that used a messy ERP year to make the business readable.

Readable to people. Readable to systems. Readable to AI.

That means clean records, honest ownership, clear permissions, known sources, usable tools, visible checks and a harness that can swap models as the market changes.

Rent the model when it makes sense.

Renting the process is different.

If AI becomes the layer between your people and your systems, you should own as much of that layer as you can. Especially the data. Especially the guardrails. Especially the tools your people use to create and change the truth of the business.

Own the harness, and the model becomes a commodity.

What leaders should do next

• Add AI readiness to the SAP-to-Microsoft plan now, while processes and permissions are still being rebuilt.
• Define the harness before picking the model: job, context, permissions, tools, checks, logs and human approval.
• Choose three repeated internal jobs for local AI first, then prove the cost, speed and risk case before widening it.
• Audit the data behind those jobs: owner, source, freshness, permission, evidence and what a human must approve.