Solution
AI systems grounded in enterprise data and built to be operated
We design and build AI systems that answer from your documents and records, act inside the products your people already use, and can be measured, audited and corrected once they are live.
The problem space
Most organisations can produce a convincing AI demonstration in a few days. A language model, a handful of documents and a chat interface are enough to show an answer that looks right. The distance between that demonstration and a system people rely on is where the engineering lies: retrieval that finds the correct passage in a corpus of several million, permissions that follow the user into every query, answers that cite their sources, and a way to know whether last week's change made things better or worse.
The systems in this category share a shape. Knowledge assistants answer questions from internal content. Document intelligence extracts structured data from contracts, invoices, claims and reports. Copilots sit inside an existing product and draft, summarise or propose the next step. Decision support assembles evidence for a person who remains accountable for the outcome. In each case the model is one component among many, and usually not the one that determines whether the system works.
We treat an AI system as a software system with a probabilistic component. That means versioned prompts and indexes, automated evaluation in the delivery pipeline, tracing of every model call, explicit cost and latency budgets, and controls over what data reaches which model. It also means saying early when a deterministic rule, a search index or a database query would solve the problem more cheaply and more reliably than a model.
Why it is hard
Engineering challenges
Retrieval quality sets the ceiling
A model cannot answer correctly from a passage it was never shown. Naive fixed-size chunking splits tables and clauses in half, pure vector search misses exact identifiers such as part numbers and policy codes, and stale indexes return superseded documents. Most poor answers trace back to retrieval, not to the model.
Access control must survive retrieval
An assistant that indexes everything and filters nothing will show a junior analyst the board papers. Permissions held in the source systems have to be carried into the index and enforced at query time, and they have to stay correct when a document is reclassified or a person changes role.
Quality that nobody can measure
Without an evaluation set, every prompt change is a guess and every regression is discovered by a user. Teams end up arguing from anecdotes. A system needs a curated set of questions with expected evidence and answers, scored automatically on each change.
Fabricated and unsupported answers
Models produce fluent text whether or not the retrieved context supports it. The failure is dangerous precisely because it reads well. Answers need citations that resolve to real passages, a check that the claims are supported by them, and a defined behaviour when the evidence is insufficient.
Prompt injection and data leakage
Any document, email or web page the system reads can contain instructions aimed at the model. If the same model can also call tools, an injected instruction becomes an action. Retrieved content has to be treated as untrusted input, and tool permissions have to be scoped to the user, not the model.
Cost and latency at real volume
A prompt that costs little in a pilot becomes a material line item at tens of thousands of requests a day, and a chain of four sequential model calls will not meet an interactive latency budget. Model routing, caching, context trimming and streaming have to be designed in, not added after the invoice arrives.
How we build it
Architecture
A production AI system separates ingestion, retrieval, orchestration, guardrails and evaluation so that each can be changed and measured independently. The model sits behind a gateway and is treated as replaceable.
- 01
Ingestion and indexing pipeline
Connectors pull content from document stores, wikis, ticketing systems and databases, then parse, clean and chunk it along structural boundaries such as headings, clauses and table rows. Each chunk carries its source, version, effective date and access-control metadata. The pipeline is incremental, so an edited or deleted document is reflected in the index without a full rebuild.
- 02
Hybrid retrieval and reranking
Queries run against both a vector index and a keyword index, because semantic search finds paraphrases and lexical search finds exact terms. A reranking model orders the combined candidates before a small, relevant set is passed to the generator. Permission filters are applied inside the query, not after it, so restricted content never enters the context window.
- 03
Orchestration layer
A service assembles the prompt, calls the model, invokes tools and manages conversation state. Prompts are versioned artefacts held in source control and released like code. Where a task needs several steps, the flow is modelled as an explicit graph with bounded iterations, so behaviour can be traced and a runaway loop cannot occur.
- 04
Model gateway
All model calls pass through one gateway that handles routing, retries, timeouts, rate limits, caching and cost attribution. It allows a small model to handle classification and extraction while a larger one handles reasoning, and it lets a provider or model version be changed in one place. It is also where data-residency and redaction rules are enforced.
- 05
Guardrails and policy enforcement
Inputs are screened for injection patterns and sensitive data, and outputs are checked for schema validity, unsupported claims and policy violations before they reach the user. Tool calls run with the calling user's permissions and high-impact actions require confirmation. These checks are deterministic code wherever possible, because a second model is not a reliable guard for the first.
- 06
Evaluation harness
A maintained dataset of representative questions, expected sources and reference answers is scored on every change to prompts, retrieval settings or models. Metrics cover retrieval recall, groundedness, answer correctness and refusal behaviour. The harness runs in the delivery pipeline and blocks a release that regresses beyond an agreed threshold.
- 07
Observability and feedback
Every request produces a trace covering the query, retrieved chunks, prompt version, model, token counts, latency and outcome. User feedback and sampled human review are attached to those traces and fed back into the evaluation set. This is what makes it possible to explain a specific answer weeks later.
Ingestion
- 01
Sources
Documents, databases, internal APIs
- 02
Parse and chunk
Extract text, keep structure
- 03
Embed
Batch embeddings, versioned model
- 04
Index
Vector and keyword indexes with ACLs
Query
- 01
Question
Authenticated user and their scope
- 02
Retrieve
Hybrid vector and keyword search
- 03
Rerank
Keep only the strongest passages
- 04
Generate
Grounded answer with citations
- 05
Evaluate and log
Trace, score and capture feedback
What an engagement delivers
- Use-case assessment with a recommendation on where AI is and is not the right tool
- Ingestion pipeline and index with source-level access control
- Retrieval and orchestration services behind a documented API
- Evaluation dataset and automated scoring in the delivery pipeline
- Guardrail, redaction and tool-permission policies
- Tracing, cost and quality dashboards
- Operating runbook covering model upgrades, index rebuilds and incident handling
Before you start
Decisions to make early
- Retrieval, fine-tuning or both
- Use retrieval when the answer depends on facts that change or must be cited, which covers most enterprise knowledge. Consider fine-tuning when you need a consistent format, tone or specialised classification that prompting cannot hold, and you have labelled examples to train on. The two are complementary: a fine-tuned model still needs retrieval to know what is true today.
- Hosted model API or self-hosted models
- Hosted APIs give the strongest models with no infrastructure to run, and suit most workloads where the provider's data-handling terms are acceptable. Self-hosting open-weight models makes sense when data cannot leave your environment, when volume is high enough to justify GPU capacity, or when latency needs tight control. It brings real operating cost: capacity planning, model serving and upgrades become your responsibility.
- How much autonomy to give the system
- Start with the system proposing and a person approving. Move individual actions to automatic execution only when they are reversible, low in impact and backed by evaluation evidence. Actions that move money, change customer records or send external communications should keep a human approval step until the error rate is understood and accepted by the people accountable.
- Build a platform or a single application
- If one use case is in view, build that application well and keep the gateway, evaluation and tracing as separable components. A shared platform is justified once a second and third use case would otherwise duplicate ingestion, access control and governance. Building the platform first tends to produce infrastructure without a user.
FAQ
Common questions
Can the system be limited to our own data?
Yes. The system is designed to answer from retrieved content and to say when that content does not contain an answer. Answers carry citations to the source passages, and a groundedness check flags responses that go beyond the evidence. No design removes the risk entirely, which is why evaluation and review remain part of operation.
Which models do you work with?
The architecture is model-agnostic. The gateway isolates the application from any one provider, so the choice between commercial APIs and open-weight models is made per task on quality, cost, latency and data-handling requirements, and can be revisited as models change.
How do you handle sensitive or regulated data?
Data classification is applied at ingestion, access control is enforced at retrieval, and redaction rules run before content is sent to a model. Deployment can be arranged so that data stays within a chosen cloud region or private environment. We design systems to support your compliance obligations; the obligations themselves are defined by you and your advisers.
What happens when the model provider releases a new version?
The new version is run against the evaluation dataset before any traffic reaches it. If scores hold, it is released gradually behind the gateway; if they regress, prompts or retrieval settings are adjusted first. The prior version stays pinned until the comparison is complete.
Have a system that needs to work in production?
Tell us what you are building. An engineer will read it and reply within two working days.