AI integration consulting
I do not build AI products from scratch. I add large-language-model capability to the system you already run — your CRM, your ERP, your document archive — and I build it so you can say exactly where your data goes.
What does AI integration actually mean?
AI integration means connecting a large language model to an existing business system, to its data and to its authorisation rules. The model is not bolted on as a separate product; it becomes a component of the system. In practice the work has three layers: a data access layer, an orchestration layer where the model is called, and a control layer where the output is verified.
Wiring an LLM to an API call takes a few hours. The rest of the project is answering these questions: which data reaches the model, what source the answer is grounded in, what the user is allowed to see, where a wrong answer lands, and what the monthly cost ceiling is.
What kinds of work do I take?
Five kinds: an AI readiness assessment, retrieval-augmented document search, agent workflows, Model Context Protocol server development, and on-premise model deployment. Each is a separate engagement. I do not sell a bundle of all five, because the right order depends on the state of your data, not on a package.
| Type of work | What it solves | Typical duration | Prerequisite |
|---|---|---|---|
| Readiness assessment | Which processes suit AI, which do not, and in what order | 1–2 weeks | None |
| Retrieval-augmented search (RAG) | Natural-language search over contracts, policies, quotes and procedures, with cited sources | 4–8 weeks | Documents reachable in one place |
| Agent workflows | Automation that uses several systems in sequence: fetch, decide, write back, notify | 6–12 weeks | API or database access to the target systems |
| MCP server development | Exposing your internal systems to Claude, ChatGPT and similar tools over a standard protocol | 3–6 weeks | A clear authorisation model |
| On-premise model deployment | A model running on your own hardware, with no content leaving the company | 3–8 weeks | Suitable GPU or unified-memory hardware |
Does our data have to leave the company?
No. With an on-premise deployment the model runs on your hardware and no content reaches a hosted provider. The cost is capability: open-weight local models match hosted models on some tasks and fall clearly behind on others. Which task falls on which side should be decided by measurement, not by assumption.
I measured it on my own hardware. On an Apple M5 Max with 48 GB of unified memory I benchmarked open-weight models on real coding tasks across a series of more than nine rounds. The clearest finding: local models are usable for generating new code and clearly unreliable for making targeted edits inside an existing file. The full measurement is here.
| Criterion | Hosted model | On-premise model |
|---|---|---|
| Does data leave the company | Yes, it goes to the provider | No |
| Data-residency posture | Cross-border transfer, with the obligations that follow | Processing stays inside the company boundary |
| Task quality | Stronger on complex reasoning | Adequate for generation, weak on surgical editing |
| Cost structure | Per use, grows linearly with volume | Hardware up front, then flat |
| Latency | Network round trip plus provider queue | Local, no round trip |
| Provider risk | Pricing and model retirement come from outside | The weights stay with you |
In most projects the right answer is both: sensitive steps on a local model, non-sensitive steps that need hard reasoning on a hosted one. I build that split behind a provider-agnostic interface layer, so changing provider does not mean changing the application.
What happens in the first two weeks?
The first two weeks are for measuring, not building. We map the existing data model, authorisation rules and integration points, sort candidate processes into “suits AI” and “does not”, and pick one as a pilot. The output of those two weeks is a document, not code.
- Data map. Where each dataset lives, who can reach it, which fields are personal data.
- Process screening. Candidates are scored on volume, error tolerance and verifiability. Low error tolerance plus unverifiable output means the process is dropped.
- Pilot selection. One measurable process. The success criterion is written before the work starts.
- Architecture decision. Local or hosted, which step on which side, and what the cost ceiling is.
- Scope document. All of the above in one place, including what is out of scope.
What do I work with?
On the model side: Anthropic Claude, OpenAI GPT and open-weight Qwen models, with an MLX-based service for local inference on Apple Silicon. On the application side: Node.js/Express and Angular. On the protocol side: Model Context Protocol. Tool choice follows the project; I have no vendor allegiance.
- Models
- Claude · GPT · Qwen (open-weight)
- Local inference
- Apple Silicon · MLX · 48 GB unified memory
- Protocol
- Model Context Protocol (MCP)
- Application
- Node.js · Express · Angular
- Data
- MySQL · SQLite · Redis · vector index
- Delivery
- Docker Compose · GitHub Actions · nginx
AI integration: frequently asked questions
How long does an AI integration project take?
A typical AI integration project takes 4 to 12 weeks. Retrieval-augmented search over internal documents takes 4–8 weeks; agent workflows spanning several systems take 6–12. Duration is driven by how clearly data access and authorisation rules are defined, not by model choice. When those rules are unclear, the timeline stretches.
We have strict data-residency requirements. Is AI still possible?
Yes, with an on-premise deployment where no content reaches a hosted provider. The trade-off is capability, and it should be quantified rather than assumed. I keep a current benchmark of what open-weight models can do on constrained hardware and use it to decide which steps can stay local and which cannot.
We have no technical team. Can this still work?
It can, but one decision-maker has to stay in the loop. They do not need to be technical; someone who knows the business is enough. I do the deployment, write the operations document and train your people at handover. Without a technical team, a monthly retainer for maintenance is advisable: an unmaintained AI workflow degrades quietly within a few months.
Will we have to change our existing software?
Usually not. The integration generally sits alongside the existing system and reads through its API or database. If changes are required they are written into the scope document and priced separately. Adding capability next to a working system without breaking it is the genuinely hard part of this work.
Can our own team maintain it afterwards?
Yes, and the handover is designed for that. The code stays in your repository, an operations document is written, and deployment scripts are delivered. If there is no team to take it over, say so at the start — the architecture will then be built with fewer moving parts.
Last updated: