AI & Data
Generative AI that cites its sources
LLM applications, retrieval pipelines and agents, wired into the systems you already run. Built so every answer traces to a document, every agent action leaves a log, and every model change is tested before users see it.
What We Build
Six building blocks. Most systems use three.
The use case picks the blocks. A support copilot and a claims agent share almost nothing but the model.
Generative AI Model Design
Choosing and shaping the model for the job: hosted or open-weight, large or small, general or tuned on your material.
RAG Architecture & Knowledge Pipelines
Ingestion, chunking, embeddings and permission-aware retrieval, so the model answers from your documents and shows which passage it used.
LLM Fine-Tuning & Optimisation
LoRA, QLoRA and preference tuning for format, tone and specialist phrasing - the problems retrieval can't fix.
Agentic AI & Workflow Automation
Agents that call your tools to move work along: triage, drafting, record updates, approvals. Irreversible steps wait for a person.
Enterprise Integration & API Layer
One API layer between the model and your CRM, ERP, HRIS or data warehouse. You decide what the model can read and what it can change.
AI Audit, Governance & Compliance
Bias checks, reasoning traces, content filters and review queues, each mapped to the obligation it serves under your regulatory regime.
HOW IT RUNS
Four phases, four artefacts
Each phase is named for what it leaves behind. Nothing moves forward until that artefact holds up.
Use cases, risks and the scoring plan
We start with the decision, not the model. What should the system produce? Who reads it? What happens when it's wrong? Which data may it see?
Candidate use cases are ranked by value and risk, and each gets a scoring method and pass threshold before anything is built.
DELIVERABLES
- Ranked use-case shortlist
- Data-access and permission map
- Model options: hosted, open-weight or both
- Architecture choice: RAG, fine-tuning or a mix
- Evaluation plan with a pass threshold
- Risk register for the chosen use case
OUR METHODOLOGY
Why human review sits inside the architecture
A generative system is only as trustworthy as its oversight. The review layer is designed alongside retrieval and prompts, not added after launch.
The goal isn't to check everything. It's to send the right outputs to the right person, and to learn from every correction they make.
Confidence Thresholds
Low-confidence answers go to a reviewer instead of a user. The threshold comes from evaluation data, not a guess.
Escalation for the Hard Cases
Sensitive topics, ambiguous requests and regulatory grey areas route to named experts, with the retrieved context they need to decide.
Corrections Become Test Cases
Every fix a reviewer makes joins the golden set, so the same mistake is caught before the next release instead of after it.
A Trail an Auditor Can Follow
Inputs, retrieved passages, outputs and reviewer decisions are logged together, so any answer can be reconstructed later.
Governance
Governance designed in, not bolted on
A system that can't be explained, audited or switched off has no business near enterprise data. Governance controls are part of the architecture from the first sprint.
The regulations you operate under are a design input. Each control is mapped to the obligation it serves, so your compliance team reviews evidence rather than assurances.
Built on open interfaces. Models, vector stores and orchestration are separable layers, so one can change without rebuilding the rest.
Thresholding
Low-certainty answers are held back, not shown
Traceability
Each retrieved answer links to the passage it came from
Bias Auditing
Outputs sampled and tested for demographic, language and context bias
Explainability
A record of how each output was produced, kept for review
Toxicity Filtering
Moderation tuned to your audience and the topics you rule out
Compliance Monitoring
Each control mapped to its obligation, with evidence kept on file
Technology Stack
The foundation models we build with
No model wins every task. The choice turns on reasoning depth, context length, data sensitivity, latency and cost per call, and it gets revisited when a better option ships.
GPT family | OpenAI
Hard reasoning, long-form drafting and tool use
Azure OpenAI · Hosted APIClaude | Anthropic
Long documents and careful, instruction-heavy work
AWS Bedrock · Hosted APILlama | Meta (open weights)
Sites where data can't leave the building
Private VPC · On-prem GPU · No external APIGemini | Google
Mixed input: text, images, scanned documents and video
Google Cloud Vertex AI · Hosted APIChosen per task. The evaluation results pick the model, not a vendor relationship.
Fine-Tuning & Training
PyTorch
HuggingFaceLoRAQLoRADPOPEFTRAG & Orchestration
LangChainLlamaIndexpgvectorQdrantWeaviatePineconeEvaluation & Operations
Kubernetes
DockerWhere It Breaks
Three ways generative AI fails in production.
Each is a design problem. Each is cheaper to solve before launch than after.
Answers Without Evidence
Without retrieval and refusal rules, a model fills gaps with plausible fiction. In finance, health or law, that is a legal exposure.
Instructions Hidden in Documents
Retrieved text can carry instructions of its own. Without injection testing, a poisoned document can steer the model or leak what it can see.
Costs That Outrun Value
Long prompts, large models and agent loops multiply the cost of every request. A budget per request belongs in the design, not the invoice.
Why Us
How we keep generative AI honest
Four habits that separate a system you can run from a demo you can show.
01
Scored Before It's Shown
Every build is measured against a golden set your experts approved. The demo comes after the numbers, never instead of them.
02
Retrieval and Generation Measured Apart
When an answer is wrong, we can tell whether the system found the wrong passage or misread the right one. The fix goes where the fault is.
03
Model Swaps Tested Like Code
Vendors update models on their own schedule. A regression suite runs before any version change reaches your users.
04
We Build Our Own
Nujtech builds an LLM-centric product of its own, alongside client systems. The same evaluation discipline runs through both.
Vertical Focus
Where a grounded answer matters most
Regulated sectors, where an invented answer is a liability and an output may need its citation.
Clinical and operational systems for healthcare
Clinical documentation, claims and connected patient data, with a clinician approving anything that affects care.
Banking, insurance and risk systems
Fraud, KYC, underwriting and claims models that risk and compliance teams can review, explain and sign off.
Engineering for automotive
Connected-vehicle data, telematics and dealer analytics, built around functional-safety and cybersecurity requirements.
Plant-floor systems for manufacturing
Predictive maintenance, vision inspection and forecasting that connect plant data to the business.
Data and AI for agriculture
Crop, sensor and imagery analytics designed for patchy connectivity and one growing season a year.
Retail operations and customer data
Demand forecasting, personalisation and unified customer data, tuned to the trading calendar.
FAQs
Common Questions
Use-case selection, corpus preparation, model choice, retrieval and prompt design, integration with your systems, guardrails, evaluation, and the monitoring that keeps it working. Picking a model API is the smallest part of the job.
Generative AI produces content: answers, drafts, summaries, code. Agentic AI acts on it, calling tools, updating records and moving a task through several steps. Agents need tighter controls, because their mistakes change things instead of just saying them.
Retrieval-augmented generation fetches relevant passages from your own sources before the model writes, so answers stay current and can cite where they came from. Use it when knowledge changes or must be traceable. Fine-tune when the problem is format, tone or specialist phrasing.
It depends on corpus quality, integration depth and how strict the evaluation bar is, so there is no honest number before the use-case sprint. The sprint ends with a phased plan that states what each phase delivers and what has to be true before it starts.
Running cost follows model size, prompt length, request volume and how often agents loop. Cost per request is budgeted during design and tracked on a dashboard after launch, so spend is visible before it becomes a surprise.
Yes. Open-weight models can run in your private cloud or on your own GPUs, including air-gapped sites, so prompts and documents stay inside your perimeter. Hosted APIs are an option chosen per use case, not a default.
When the answer is a lookup, a rule or a form. If a search index or a decision table does the job, it will be cheaper, faster and easier to audit. The use-case sprint is where that gets said out loud.
Pick one decision.
Measure before you build.
Tell us which decision a model should support and what a wrong answer costs. The first conversation covers your data and how the result will be judged. If an off-the-shelf model already passes, that is the answer you get.
Have a project in mind?
Bring the problem. The first call is about specifics, not slides.