AI integration services connect a model to the systems your business already runs on — the CRM, the ERP, the EHR, the warehouse, the helpdesk, and the documents all of those hold. Calling a model is a few lines of code; the weeks go into permissions, data shape, failure handling, and the audit trail that proves what the system did with somebody's record. That is why an integration is priced like a software project rather than like a subscription.
What AI integration services actually connect
Most engagements connect one of four surfaces: a customer or case system, a money or stock system, a document store, or an operational database. The integration is what lets the model answer from your records instead of from the open internet, and it is the difference between a demo that impresses and a feature you can put in front of a paying customer.
- Customer and case systems. CRM, ticketing and case management: account history, recent activity, open balances. A summary or a draft reply starts from facts rather than from what the customer typed into a box.
- Money and stock systems. ERP, billing, inventory: prices, stock levels, order state, payment status. Usually read-only to begin with, because a wrong number written into a ledger costs more than a wrong number on a screen.
- Document stores. Contracts, manuals, policies, case files. This is the corpus a retrieval pipeline is built over, and the place where access control has to be enforced per user, not per model.
- Operational databases and internal APIs. The reporting tables and service endpoints that hold the numbers nobody ever built a UI for.
Those four map onto the capabilities we build at 723 Studios: LLM features and copilots, retrieval over your documents, document and media analysis, and prediction. Integration is the strand that appears in all four, which is why it is usually the largest line in the estimate.
The four integration shapes, and what each one costs you
Nearly every request fits one of four shapes. Naming the shape before you scope is what keeps the project honest, because the shapes differ mainly in how much write access the model gets — and write access is where both the risk and the work sit.
| Shape | What the model does | What it needs | How it fails |
|---|---|---|---|
| Read-only enrichment | Reads records to summarise, classify, or draft | One-way sync and a permission check on read | Stale data when the sync lags behind the source system |
| Draft and approve | Proposes an update; a person accepts or edits it | A review surface plus a record of who accepted what | A review queue nobody clears, so proposals pile up unread |
| Event-triggered automation | Acts on a webhook or a schedule with no human in the loop | Hard limits, idempotency, and a way to undo a run | One bad rule looping through the whole table before anyone notices |
| User-facing copilot | A person asks a question and gets an answer inside your app | Grounding, source citations, and per-user permission checks | A confident answer drawn from a document that user was never allowed to read |
The cheapest shape that solves the problem is the right one. A surprising share of "we need an agent" requests are read-only enrichment with a good prompt and a labelled test set, and building them that way removes most of the ongoing risk.
Why permissions are the hard part
An integration that ignores permissions is a data leak with a chat box on the front, and it is the most common defect in AI features that reach production. The rule is simple and unforgiving: the model must never see a record the requesting user could not open. That means the retrieval and tool layer filters by the same identity the application uses — not a service account with blanket access, and not a filter applied to the answer after the model has already read everything.
In practice this is where retrieval over documents gets its shape: ingestion, chunking, embeddings, hybrid search, a citation back to the source passage, and an access check that runs before the passage enters the prompt. It is also the part that has to survive re-indexing, because a document that changed permissions yesterday is still in an index built last week unless you handle it.
What an AI integration project costs
Our published ranges on the services page put an AI feature at roughly $25,000–$80,000 and 4–10 weeks on top of the application it lives inside. For an integration-heavy brief, the connecting work is usually the larger half of that: connectors, identity, retries, logging, and the evaluation that tells you whether the feature is still working a month after launch. Model calls themselves are a small and predictable part of the bill once the plumbing is right, which is why cost per request is a design decision and not a surprise.
When AI integration is the wrong project
If the answer already exists as a report, a filter, or a search box, an integration adds a cost with no new capability. That is the honest test to apply first. The other clear non-fits are worth naming out loud:
- Nobody owns the output. If no person is accountable for acting on the answer, the integration is a demo with a renewal date.
- The data lives in a spreadsheet and three mailboxes. There is no system of record to integrate with yet. Fix that first; it is a cheaper project.
- The decision is regulated. Where a rule or a regulation requires a human judgement on the record, the model can prepare the packet but must not make the call.
- The volume is too low. A task that happens twice a week is usually a checklist, not an integration.
If the surrounding application is the real gap — no place for the feature to live — the work starts at custom app development and the AI feature becomes a later phase instead of the opening act.
How to scope an integration in a week
The scoping work is small and cheap, and it is the part that prevents a rebuild in month two. Before code, get six answers written down:
- The decision being improved, stated in one sentence, with the current way it is made.
- The system of record for every field the model needs, and who owns that system.
- The access rule: which identity the model acts as, and which records are off limits.
- What wrong looks like, in examples — not a vibe, but cases you can test against.
- The acceptance test: a labelled set of real cases with expected outcomes, agreed before the build starts.
- The operating owner: the person who reads the logs, tunes the prompts, and decides when to switch the feature off.
Teams that answer those six questions buy a shorter build and a feature that keeps working. Teams that skip them buy a second integration six months later. If you want the shape of the engagement rather than the theory, the AI development page covers how a fixed-scope project, an augmentation arrangement, and a rescue all run here — and our guide to what an AI development company actually builds walks through the same work from the buying side. Once a model is answering from live records, the uptime and monitoring question moves to whoever runs the pipes, which is why integrations we build usually sit on managed IT services rather than on a laptop behind somebody's desk.
Frequently asked questions
Do we need a data warehouse before we can integrate AI?
No. A warehouse helps when you are joining many sources for analytics, but most first integrations read two or three systems directly through their own APIs. Build the warehouse when a reporting need justifies it, not as a precondition for a feature.
How long does an AI integration take?
Four to ten weeks for a first production feature, in line with the range we publish for AI work, and the variance comes almost entirely from connector and permission work rather than from the model. A read-only integration against one well-documented API is at the short end; anything writing back into an ERP is at the long end.
Can the model write back into our CRM?
Yes, and the safe version is draft-and-approve: the model proposes the field change, a named person accepts it, and the record shows both. Direct unattended writes are possible but need hard limits, idempotency, and an undo path before they go anywhere near a customer record.
What does an AI integration cost?
Published AI feature work here runs about $25,000–$80,000 and 4–10 weeks. For an integration-heavy brief, expect the connecting, identity and evaluation work to be the larger share of that number, with model calls forming a small recurring cost afterwards.
How do we know it is still working after launch?
By keeping the labelled test set and running it against every prompt or model change, and by logging what the model read for each answer. Our own framing is that evaluation means a measured accuracy number, not a vibe — if you cannot re-run the test, you cannot tell whether last month's change broke the feature.