What Belongs in a Custom AI Layer on Platform Models

“We already pay for Microsoft 365. Won’t Copilot just do this next year?”

It is the right question to put first, and part of the answer is yes. Summarize the thread, draft the reply, search the shared drive — a platform vendor builds those because every customer wants them, and waiting is the correct call. What never arrives is the work that depends on your own data model or your own regulator. That gap is what a custom AI layer on platform models is for.

The model itself is rented, and should be. Providers keep shipping stronger ones, and they are close enough for most business tasks.

Should you wait for the platform to ship the feature?

Write down the feature, then every system it has to read to be correct.

A platform assistant with access to your document store can summarize a contract. It cannot tell you that the renewal clause contradicts a pricing exception your sales director approved by email and logged as a note against the account in your CRM. The join between those two records lives in one person’s memory, and no product update closes it.

Procurement friction runs the other way. Native platform AI is already inside the contract and already through the security review, on an invoice somebody signs off without a meeting. A separate AI vendor means a new contract, a new data-processing agreement, billing isolation and another name against a renewal. Each of those is a reason for a busy sponsor to defer. So the layer worth funding sits on the platform you already bought, calling models you already have terms for.

If a competitor could buy the same capability next Tuesday, wait for it and spend the budget elsewhere. If the feature only makes sense given how your own systems fit together, nobody else is going to build it for you.

What a custom AI layer on platform models actually contains

Start with retrieval over your own material — an index with permissions attached to each document, so it cannot answer past them, and current versions only. A model answering from a policy you retired last year is worse than one that says it doesn’t know, and the correction usually arrives from a customer.

The write path is the expensive half. Once the system is expected to raise the credit note or reschedule the delivery, it needs an action layer with its own permissions, separate from the model’s, plus a log of what it did on whose behalf. Reads are reversible. Writes leave a customer holding the consequence, which is why the two belong in different scopes and usually in different releases.

Some rules have to be deterministic. Discount ceilings, eligibility, refund limits, anything an auditor will ask about later — those go in code, and the model calls that code like any other caller.

You also need an evaluation set: real cases with known-good answers. When the provider ships a new model, that set is the only thing that tells you whether your product improved or one category of question quietly broke.

Last, the audit trail — which model version ran, which documents it retrieved, what it output, who approved the result.

That is the AI-integrated software part of the build, and it is the part that sits on your side of the boundary.

What a first version costs

Our cost guide for AI chatbots is written around support deflection, but the build underneath is the same shape as this one: retrieval, read-only lookups into one system of record, handoff, evaluation set. The tier that matches is Tier Two — ₹5L – ₹7L ($5.7k – $8k), six to nine weeks. It stops before writing to your systems, deliberately; that path carries different consequences when it goes wrong and belongs in its own scope.

Treat that as an indicative range for a scoping conversation. The binding figure comes out of a paid discovery against a written scope, and what moves it is the state of your documents and how many systems the feature has to read.

Look at what the money is buying: integration and evaluation work. The model calls are metered usage on a cloud invoice you probably already receive. When a vendor quotes a large number for “an AI build”, ask which of those two they are charging for.

What you give up by building on a platform’s native AI

Coupling. This is the part to price before you sign. A feature that takes its identity, its document storage and its model call from one company has three dependencies on one roadmap and one price list. When they reprice, that lands on your margin.

We take that trade on identity and storage. Both are commodities you already run, and reimplementing them to stay portable costs more than the independence buys. The model call is where we refuse it — fastest-moving component in the stack, and the one most likely to be undercut by a competitor’s next release. Keep it behind one interface of your own: a single function your application calls, with provider-specific adapters behind it. Prompts and evaluation sets live in your repository, versioned like any other source file.

Do that and the corpus and the test cases stay portable. Switching providers becomes a config change and a re-run of the evaluation set. If you are still weighing whether any of this should be custom at all, the build-versus-buy trade-offs are the better place to start.

How to decide what to build and what to rent

• Name the decision the feature is meant to improve, and who currently makes it on instinct.
• List every system it has to read to be correct. If more than one of them is yours, no platform vendor is going to close that gap.
• Check who will demand proof the answer was right. If an auditor or a regulator is in that sentence, fund the audit trail before the interface.
• Decide who owns the write path, and what the rollback looks like the first time it acts wrongly.
• Confirm you can assemble real cases with known-good answers before you commission anything.