The model is the part you can swap. What takes engineering is the retrieval underneath it, the evaluation set that catches a silent regression, and the containment that stops untrusted text from becoming an instruction.
What you are actually buying
Generative AI development builds systems on large language models that are grounded in your data, evaluated against a fixed test set and defended against prompt injection. Model-agnostic deployment keeps you free to switch providers without rewriting the application.
The demo works. Then somebody asks one of these four questions and the project stops for six months.
Nobody wrote down what correct looks like, so quality is assessed by whoever last tried it. Without a fixed evaluation set the system has no definition of working, and every change becomes a matter of opinion. This is the question that kills the most prototypes, and it is answerable in a week.
Any system that reads text it did not write is reading input from someone who may want it to misbehave. You cannot instruct your way out of this, and a security team that hears you try will correctly refuse to sign off. Containment is architectural, and it is covered under AI governance and security.
Under the DPDP Act 2023 and the DPDP Rules 2025 this becomes a documented answer rather than a shrug. Deciding which fields may reach a hosted model, which get redacted and which require a model inside your own network is an architecture decision, so it has to come before the architecture.
Prototypes get wired directly to one provider's SDK, with its quirks spread through the codebase. A year later a better or cheaper option exists and moving is a rewrite. One internal interface with providers behind it costs a day at the start and saves a quarter later.
Ordered by how much time they take, which is roughly the inverse of how much they get discussed.
Most answer quality problems get blamed on the model and are caused by retrieval. A table split across two chunks becomes unanswerable. A heading detached from its clause loses the condition that made it true. We chunk with structure preserved, run hybrid keyword and semantic search so exact identifiers match literally, and rerank when the top results are close together.
The same layer powers our RAG chatbot work, where you can see it traced end to end.
We write the test cases before the system, because doing so forces the scope conversation that would otherwise happen after launch. Fifty to two hundred real cases with expected outcomes, including the ones the system must refuse. It runs in CI from the first commit.
Every model call goes through an internal abstraction. Switching provider, or routing cheap steps to a small model and hard steps to a large one, becomes configuration rather than surgery.
Cost scales with context sent, not with users. We measure tokens per request from day one and cap budgets in the orchestrator, so a badly behaved change shows up as an alert rather than an invoice.
Open-weight models served with vLLM inside your own VPC, for the data categories that genuinely cannot leave. Provisioned by our cloud team.
Select a scenario to compare how a naively built system behaves against one with the controls in place. The point of each pair is that the fix is structural rather than a better instruction.
Naive system
A supplier uploads a document containing text addressed to the assistant rather than to a reader. Retrieval pulls that passage in alongside legitimate content, and because everything arrives in one undifferentiated block, the model treats the embedded direction as part of its task.
Contained system
Retrieved passages are delivered in a clearly demarcated channel the system is built to treat as reference material only. Ingestion flags documents whose text is addressed at a system rather than a reader, and the assistant has no tool that could act on such a direction anyway.
We describe these at the level of controls rather than payloads. The pattern to take away is that every fix above lives outside the model: separate the reading component from the acting component, keep tool permissions minimal, filter what comes out, and put a person in front of anything consequential.
Five steps, deliberately front-loaded with the two nobody wants to do first. Same delivery shape as the rest of the AI and automation practice.
Fifty to two hundred real cases with expected outcomes, including cases the system must refuse. This is not a testing formality; writing it forces the scope conversation that would otherwise surface three days before launch when it is expensive.
Which fields may reach a hosted model, which get redacted or tokenised first, and which categories require a model running inside your own network. This determines the architecture, so it cannot be decided afterwards without rebuilding.
Structure-preserving chunking, hybrid search, reranking on close calls, and measurement of retrieval quality independently from answer quality. If the right passage is not being found, no prompt will rescue the answer.
Separate the component that reads untrusted content from the component that can act. Minimum tool permissions, output filtering before rendering, and a human gate on anything consequential. Reviewed by the same people who run our VAPT engagements.
Token cost per request, latency percentiles, refusal rate and evaluation scores on a dashboard. The suite runs on every prompt, index or model change. Then 100% of code, prompts, retrieval configuration and the evaluation set is assigned to you.
Three inputs decide almost every enterprise LLM deployment. Set them and the recommendation updates, along with the trade-offs you would be accepting.
How sensitive is the data being sent?
What is the workload pattern?
How hard is the reasoning?
Recommended shape
Standard provider endpoints with retention disabled. Fastest to build, best capability, and the right default when the data does not carry residency obligations. Keep the provider behind an internal interface so the choice stays reversible.
Trade-offs to plan for
Six stages. Select one to see what it does and the specific way it tends to go wrong.
Documents arrive as PDFs, Word files, wiki pages and scans. Each is converted to text with its structure intact, and the source, version and effective date are recorded as metadata so retrieval can prefer current material.
Goes wrong when
Superseded versions are ingested alongside current ones. Retrieval has no way to know which is authoritative unless you tell it. Scans need proper extraction first.
Four categories of case. The second and third are the ones almost nobody writes, and they are the ones that catch real regressions.
Four applications with verifiable output, which is the test. Profiles are anonymised.
A professional services firm indexed years of past proposals. New tenders are decomposed into requirements, each matched to the closest previously approved response, and drafted with a reference back to the source document. A partner still owns what is submitted.
Consulting providersInternal assistants over product terms and operating procedures, configured to quote verbatim rather than summarise on anything with regulatory weight. The refusal behaviour matters more than the fluency, and the evaluation set is weighted accordingly.
Banking and insuranceSpecifications, test reports and supplier certificates condensed into a comparable structured summary. Output goes into a form with typed fields rather than free prose, which makes it checkable and makes disagreement between documents visible.
Manufacturing engagementsDrafting at volume where tone and claim accuracy both matter. This is one of the few places fine-tuning genuinely earns its cost, because the requirement is consistent form rather than current facts. Often scoped with marketing automation.
Digital transformationFour approaches routinely proposed for the same problem. The deciding question is usually how often the underlying facts change.
| Criterion | Prompting only | RAG | Fine-tuning | Custom trained model |
|---|---|---|---|---|
| Teaches the system | Instructions | Facts, at question time | Form and style | A narrow task |
| Updating it | Edit text | Edit the document, reindex | Retrain | Retrain and revalidate |
| Can it cite a source? | No | Yes, from the pipeline | No | No |
| Setup effort | Hours | Weeks | Weeks plus a labelled dataset | Months, with data science |
| Use when | The task is generic | Answers must reflect your current content | Output shape must be consistent | The task is narrow, stable and high volume |
The fourth column is not generative AI at all, and for a well-defined prediction task it is often the better and cheaper answer. That work sits under machine learning and predictive analytics, and we will tell you when you are in that column.
This page is the engineering layer under several others in the AI and automation practice.
The most common application of everything on this page, with the grounding traced end to end.
When the system needs to act rather than answer, and containment stops being optional.
The control set an auditor asks for, mapped to ISO 27001, the DPDP Act and EU AI Act tiers.
For narrow prediction tasks where a classical model beats a language model on cost and accuracy.
A readiness assessment before committing, including whether your content is good enough to ground anything.
Where generative drafting meets a CRM, and claim accuracy becomes a compliance question.
GPU capacity and private model hosting are provisioned by our cloud architecture team. To discuss a specific system, describe what it has to do or read the help centre.
The ten that come up in almost every first conversation.
That is enough to tell you whether your content can ground a system, and what it would take to prove it. We reply in under 3 minutes.
