Skip to main content
FromNine
Menu

AI & data

Generative AI engineered for production use.

We build generative AI on your policies, circulars, SOPs and business data. Retrieval obeys existing access rights, every release passes an agreed test set, and the cost and response time of each answer are visible to the business owner.

For Indian enterprises and GCCs that run one AI platform for teams in India and for users or customers in the European Union.

Share your requirementsEnterprise knowledge
AI Engineering & GenAI: the four layersFour layers drawn one behind the other. Top: retrieval from your own sources. Second: the model gateway. Third: evaluation and guardrails. Bottom: the application your staff use. A single path leads from the sources to the application.01Retrieval from your sources02Model gateway and routing03Test sets and guardrails04Application in daily use
  1. 01Every answer names its source paragraph, and the assistant declines when no source supports it
  2. 02A reference test set, approved by your domain experts, that each release must pass before go-live
  3. 03Routing rules and budgets that show the cost and response time of each request type

01 Challenges

Why generative AI programmes stall

Choosing a model is seldom the difficulty. Programmes stall on the engineering and governance that surround it.

  1. 01

    The demo went well, but no one can prove quality

    A handful of colleagues tried a handful of questions. Without a reference test set, each prompt edit or model upgrade is taken on trust.

  2. 02

    Staff can see files they are not cleared for

    Documents were indexed without their permissions. Your CISO and data protection team halt the rollout, and they are correct to do so.

  3. 03

    Spending rises ahead of adoption

    Each query is sent to the biggest model with the longest prompt. Nobody can state what one answer costs, so the bill cannot be managed.

  4. 04

    Fluent answers that turn out to be wrong

    Search brings back passages that are close but not correct, the model fills the gaps convincingly, and staff stop trusting it after a few such errors.

02 Scope of work

Scope of the practice

  1. 01 Retrieval over your enterprise knowledge

    Retrieval engineered source by source: how each format is parsed and split, how keyword and vector search are blended, and how permissions stay attached to every passage. It underpins our enterprise knowledge assistants.

    Scope of work

    • Register of sources with owners, file formats and permission models
    • Splitting and metadata rules for each document type
    • Blended keyword and vector search, followed by re-ranking
    • Retrieval that applies the permissions of the source system

    Deliverables

    • Ingestion pipelines that pick up changed content
    • Retrieval service that cites sources and abstains when unsure
    • Retrieval quality report for each source

  2. 02 A model strategy you can change later

    A gateway sits between your applications and the models. It routes each task to a suitable model, switches to a fallback when a provider is down, and lets you change models as prices and capabilities move.

    Scope of work

    • Comparison of hosted frontier models, deployments in a cloud region you choose, and open-weight models you host
    • Routing rules based on task, data sensitivity and cost
    • Fallbacks, time limits, caching and rate controls
    • Provider data processing terms reviewed with your legal and security functions

    Deliverables

    • Gateway whose routing policy is held as configuration
    • A recorded model decision for every use case
    • Cost and response time budget for each request type

  3. 03 Testing treated as engineering work

    The process owner agrees what a good answer is; we turn that into test sets that run on every change. Automated grading by a model is checked against human reviewers before anyone relies on it.

    Scope of work

    • Reference test sets for each use case, prepared with subject experts
    • Retrieval and generation tested separately, offline
    • Adversarial testing for prompt injection and data leakage
    • Production feedback and sampled reviews fed back into testing

    Deliverables

    • Test suite run in the CI pipeline as a release gate
    • Quality criteria approved by the business owner
    • Adversarial test findings with the mitigations applied

  4. 04 Operating models in production

    Each request is traced from the question through the passages retrieved and the model call to the answer. Prompts and models are versioned in the same way as code, and budgets are enforced while the system runs.

    Scope of work

    • Traces and structured logs for every request
    • Versions for prompts, models and indexes
    • Exact and semantic caching where it is safe to do so
    • Alerts on drift and falling quality

    Deliverables

    • Dashboards covering quality, cost and response time
    • Incident procedure for failures specific to AI
    • Runbook for updating models and indexes

  5. 05 Governance built into the design

    Where your AI output is used in the EU, we design to the EU AI Act: risk class, your role as provider or deployer, logs, human oversight and documentation. In India we map the use case to the India AI Governance Guidelines and to the DPDP Act duties for any personal data in prompts or indexes. The legal conclusion remains with your advisers.

    Scope of work

    • Classification of each use case and the duties that follow from your role
    • Inventory of personal data in prompts, indexes and training sets under the DPDP Act, and GDPR inputs where EU data is involved
    • Design of logs and of human oversight
    • System and model documentation maintained alongside the code

    Deliverables

    • System documentation set
    • Design for logging and log retention
    • Oversight procedure for every use case

  6. 06 Fine-tuning and document understanding, only when tests justify it

    Fine-tuning, distillation and multimodal reading of documents close specific gaps. We turn to them when the test results show that retrieval and prompt design have reached their limit, not earlier.

    Scope of work

    • Gap analysis based on test results
    • Plan for preparing and labelling training data
    • Distillation into smaller models to cut cost or response time
    • Layout-aware reading of scanned and complex documents

    Deliverables

    • Test results before and after the change, side by side
    • Lineage of the training data
    • A decision to keep the new model, return to the previous one or retire it

03 Architecture

Reference architecture (illustrative)

The generative AI systems we engineer for enterprises usually follow one pattern: retrieval from your sources, a model gateway, guardrails before and after the model, and a testing and monitoring loop below that controls what reaches production.

Permission checks happen inside retrieval, not in the screen the user sees. When an employee cannot open a file in its source system, no passage from that file is passed to the model for that employee.

Layers shown

Sources
Repositories, wikis, ERP and CRM records, and the identity provider that holds who may read what.
Retrieval
Ingestion, the combined index, re-ranking and the permission filter.
Models
A gateway that chooses between hosted, region-bound and self-hosted models, with fallback and caching.
Application
Answers with citations, a refusal when sources are missing, and guardrails on both sides.
Operate and improve
Reference sets, release gates, traces and budgets; production traces supply the next round of test cases.
Illustrative example

  1. Sources

    • Repositories and wikis
    • ERP, CRM and core systems
    • Identity provider

  2. Retrieval

    • Ingestion and splitting
    • Keyword and vector index
    • Permission filter
    • Retrieval and re-ranking

  3. Models

    • Model gateway
    • Hosted, region-bound and self-hosted models
    • Guardrails on input and output

  4. Application

    • Application with citations

  5. Operate and improve

    • Reference sets and release gates
    • Traces, cost and response time
Retrieval, gateway and the testing loop

An illustration only; not drawn from any client system.

Read the diagram as text

The primary path leads from document repositories through ingestion, a combined keyword and vector index, retrieval with re-ranking and the model gateway into the application.

Business systems such as ERP and CRM also feed ingestion. The identity provider supplies a permission filter that limits retrieval. Guardrails check what goes into and comes out of the application. The gateway routes to hosted frontier models, deployments in a chosen cloud region and open-weight models you host.

Below sit a test suite with reference sets and release gates, and monitoring with traces and budgets for cost and response time. Traces from production feed new cases into the test suite.

04 Trade-offs and limits

Design trade-offs and limits

  • Quality is measured before it is claimed

    How we address it

    Your process owners set the quality criteria with us, and AI output is tested against them before and after every release.

    We test retrieval and generation separately, so that a failure leads straight to its cause.

    Limits and prerequisites

    A model can give a wrong answer. We therefore design review steps for doubtful cases and a refusal when the sources do not support an answer.

    Test sets depend on the experts who help write them, and we need their time in the first weeks.

  • Access rights stay attached to content

    How we address it

    Permissions are recorded when content is ingested and checked against your identity provider at the moment of each query.

    Limits and prerequisites

    If a source system stores permissions in a form we cannot read reliably, that content stays out of scope until it can be read.

    Files shared too widely in the source remain shared too widely. Search makes them easier to find, so a permissions clean-up may have to come first.

  • Cost and response time are set at design stage

    How we address it

    Each request type has a budget. We tune routing, caching and prompt size to it, and the dashboards show where spending goes.

    Limits and prerequisites

    Providers change prices and rate limits without consulting you. The gateway lets you respond, but it cannot reverse the change.

  • Providers retire and replace models

    How we address it

    We fix the model version, and any upgrade runs the complete test suite before staff see it.

    Limits and prerequisites

    A hosted model may be withdrawn with little warning. We keep a fallback option for each use case, and the business owner approves it.

05 Delivery steps

Delivery steps

We agree how quality will be tested before deciding what to build.

  1. 01

    Define the use case

    Who will use it, which decisions it informs, which sources it may read and what an incorrect answer would cost.

    OutcomeUse-case note with risk classification

  2. 02

    Write the reference set

    Real questions and expected answers gathered with your subject experts, including questions the system must decline.

    OutcomeVersioned reference test set

  3. 03

    Get retrieval right first

    Ingestion, index and permission filter are tuned until retrieval quality reaches the level agreed with the owner.

    OutcomeRetrieval quality report

  4. 04

    Release through gates

    Generation, guardrails and the gateway go into production only after the test suite passes in the CI pipeline.

    OutcomeRelease with test evidence attached

  5. 05

    Run and refine

    Traces, sampled reviews and user feedback supply the next round of test cases and the next release.

    OutcomeMonthly review of quality, cost and response time

06 Approvals

Who approves what

The system retrieves, drafts and suggests. Your staff decide what it may read, what counts as a good answer and what happens when it is unsure.

  • The business owner approves quality

    For each use case the accountable owner signs off the quality criteria and the release evidence; our team cannot release on its own.

  • Doubtful answers reach a person

    Below an agreed confidence level the system declines to answer or passes the question to a named team.

  • Permissions are set at the source

    Who may read a document is decided in its source system and your identity provider, never in the AI layer.

  • User flags improve the system

    Staff can flag an answer. A person reviews every flag, and each confirmed error becomes a new test case.

07 Technology

Technology we use

Retrieval
  • OpenSearch and Elasticsearch
  • PostgreSQL with pgvector
  • Azure AI Search
  • Cross-encoder re-rankers
Models
  • Hosted frontier models
  • Managed model services in a chosen region
  • Open-weight models served with vLLM
  • Embedding models suited to each language
Testing and operations
  • OpenTelemetry tracing
  • Test suites in the CI pipeline
  • Registries for prompts and models
  • Langfuse or a comparable tool
Application
  • Services in TypeScript and Python
  • Streaming APIs
  • Your portals and the Salesforce, SAP or Odoo screens staff already use

A product listed here reflects our engineering experience with it, not a partnership with or endorsement by its vendor.

08 Scenario

Illustrative scenario

Illustrative example

A regulatory assistant for the compliance team of an NBFC

01Starting point
The compliance team of a non-banking financial company tracks RBI master directions, circulars and its own board-approved policies. Branch and product staff send the same questions by email, and replies differ depending on who answers.
02What we would set up
Retrieval over RBI directions and internal policies with access rights from the document store, answers that show the governing paragraph and its date, and a refusal when no current source applies.
03Where an officer decides
The chief compliance officer approves the reference test set and signs off any release that changes how a direction is answered.
04How success would be measured
Share of answers citing the correct and current paragraph, refusal rate on questions outside scope, and time compliance staff spend on routine queries.

09 By industry

By industry

  • Government & Public Sector

    Assistants for officers in ministries, State departments and urban local bodies that quote the government order or circular they rely on and record what was retrieved for which user.

  • Banking & Financial Services

    Assistants over RBI master directions, SEBI circulars and internal policies, with strict entitlements and model documentation that your risk and compliance functions can examine.

  • Healthcare & Life Sciences

    Search across SOPs, validation records and product files for EU submissions, with firm boundaries: no clinical decisions, and patient data kept in approved environments.

India

Indian guidelines, EU law, one test standard

India has no AI statute. MeitY released the India AI Governance Guidelines in November 2025 as non-binding guidance, and the IndiaAI Mission includes a Safe and Trusted AI pillar. Personal data in prompts, indexes and training sets falls under the Digital Personal Data Protection Act, 2023, whose Data Fiduciary duties apply from May 2027.

Once your system’s output is used in the EU, the EU AI Act can apply even though you are established in India (Article 2(1)(c)). We plan for both in discovery: tests per language and use case, data location fixed per use case in the contract, and one set of logs and documentation that answers Indian and European questions alike.

FAQs on AI engineering

Which model should we choose?

That depends on the task, the data it touches and where processing is allowed. A typical design mixes models: a strong model for steps that need reasoning, smaller or self-hosted models for classification and extraction, and a region-bound deployment where a contract or sectoral rule fixes where data may be processed.

Because the gateway keeps the choice reversible, the recommendation can change as models and prices change.

What accuracy can we expect?

We give no accuracy figure until we have tested on your own documents. Together we set quality criteria, build a test set and report results against it before go-live and after every change.

Models do make errors, so each design states what happens next: a refusal, a review step or a handover to a named officer.

Could our data end up training another party’s model?

Not in the systems we design. We choose model services whose contract terms exclude training on your inputs, or we host the models in your own environment, and the choice is recorded for each use case with your security team.

Does the EU AI Act reach us if we are based in India?

It can. The Act covers providers outside the EU who place AI systems on the EU market, and providers and deployers whose AI output is used in the EU. We work through your use case and role with you and design logs, oversight and documentation to match, so that your legal advisers can decide. The India AI Governance Guidelines from MeitY are guidance, not law, and we use them as a design reference.

How is sensitive data protected?

FromNine is ISO/IEC 27001 certified. Access limits, where data is stored and how long it is kept are agreed and written down before development, and adversarial testing for prompt injection and data leakage is part of every release.

Where should we begin?

With a single use case that has an accountable owner, a small set of sources and a test set written with your experts. You end up with a working system and measured quality, cost and response time, which is the evidence the next budget decision needs.

Bring one use case and its most difficult questions

We will show how its quality would be tested before any discussion of what to build.

Share your requirementsEnterprise knowledge