SmartLink
AI & automation

Enterprise AI assistant development in Pakistan

Enterprise AI assistant development in Pakistan is mostly sold as a chat window, and the chat window is the least interesting part of it. SmartLink Services builds assistants from Karachi that answer from your own policies, contracts, manuals and ERP data, cite the source of every answer, refuse when the answer is not in the source, and show each user only what their existing permissions already allow. Below is the commercial detail. What such an assistant costs at market rates, how long one takes to build and evaluate, and the condition that decides the outcome more than any model choice does, which is whether anybody owns the documents.

Discuss this service
Grounding
Your documents & data
Access
User permissions enforced
Citations
Answer links to source
Overview

An assistant is a retrieval problem with a language model attached.

The demonstration is always convincing. Somebody asks a question, the assistant answers from a company document, and the room decides this should be everywhere by next quarter. What the demonstration does not show is the assistant answering from a policy that was superseded eighteen months ago, or surfacing a salary band to a person who should not see it, or inventing a clause in a contract because retrieval returned nothing useful and the model filled the gap.

Those three failures are the actual project. Retrieval quality decides whether the right passage reaches the model. Permissions decide whether a user can reach a document at all, and they have to be enforced when the search runs rather than described in a prompt. Grounding and refusal decide what happens when the answer genuinely is not in the sources, because an assistant that guesses politely is considerably more dangerous than one that says it does not know.

We build with citations on every answer so a person can check the source, permission filtering applied at query time against the user's own entitlements, and an evaluation set of real questions with known answers that is run before rollout and again after every change. None of this is exotic. It is the difference between a demonstration and something you can put in front of staff who will believe what it tells them.

Scope

What AI assistants over enterprise data covers

Everything below is agreed in writing before any ai solutions work starts, so both sides know what is in and what is not.

What the work covers

  • Source inventory and content preparation
  • Retrieval pipeline build with chunking and indexing
  • Permission-aware retrieval per user role
  • Answer citation so every response links to its source
  • Evaluation set and quality scoring before rollout
  • Usage logging, feedback capture and iteration

What you get at handover

  • Deployed assistant with access controls
  • Evaluation results against a question set
  • Citation and source-linking behaviour
  • Usage and feedback dashboard
  • Content update procedure

Typically involves

Vector database SSO integration
Discuss this service
01

Permissions enforced at retrieval

The most serious failure an enterprise assistant can produce is showing somebody a document they were not entitled to see. It happens easily. A single index is built over a shared drive, the drive contains folders with restricted access, and the index has no notion of who may read what. Instructing the model not to reveal restricted content is not a control. It is a request, and it fails against a determined question or an unusual phrasing.

The workable design attaches access metadata to every chunk at ingestion and filters at query time using the identity of the person asking. The user's session carries their group memberships from the directory, the search is constrained to what they may read, and the model only ever sees permitted material. Permission changes have to propagate, so a revocation is reflected in the index rather than waiting for a weekly rebuild, and deleted documents are removed rather than merely hidden.

Testing this deserves the same adversarial approach we apply to portals. A restricted account asks questions designed to surface material it should not see, including indirect ones asking for a summary rather than a document. That test belongs in the regression suite, because a later change to the ingestion pipeline can reintroduce the flaw silently. We also treat ingested content as untrusted, since instructions hidden inside a document are a recognised injection route.

  • Access metadata attached to each chunk at ingestion, derived from the source system
  • Retrieval filtered by the asking user's own entitlements before the model sees anything
  • Permission changes and deletions propagated to the index rather than waiting on a rebuild
  • Adversarial tests from a restricted account kept in the regression suite
  • Ingested content treated as untrusted, given that documents can carry injected instructions
02

Retrieval quality and the document estate

Answer quality is mostly retrieval quality. If the relevant paragraph does not reach the model, no amount of prompt refinement will produce a correct answer, and the model will produce a fluent one anyway. Chunking matters more than people expect: a policy split mid clause loses the condition attached to it, and a table flattened into running text loses the relationship between column and value. Documents worth answering from usually need structure aware processing rather than a generic splitter.

The harder problem is editorial. Most document estates contain several versions of the same policy, undated drafts, a superseded procedure that reads more authoritatively than the current one, and content that contradicts itself between departments. An assistant will retrieve whichever passage matches best, and match quality has nothing to do with which document is current. Metadata for effective date, owner and status has to exist, and where it does not, somebody has to create it.

That is the point at which we tell clients the honest thing: this is a content governance problem before it is an artificial intelligence problem. Curating a defined corpus with owners and dates gives a far better assistant than indexing everything and hoping relevance sorts it out. We would rather scope a smaller, governed source set that answers a real set of questions well than index a shared drive and produce something confidently wrong.

  • Structure aware chunking, so clauses, conditions and tables survive ingestion intact
  • Effective date, owner and status held as metadata and used to prefer current content
  • Superseded and draft material excluded or clearly marked rather than indexed alongside current
  • A curated corpus with named owners in preference to indexing everything available
  • Hybrid keyword and semantic retrieval where exact terms, codes or references carry meaning
01

What an enterprise AI assistant costs in Pakistan

The price follows the sources rather than the conversation. An assistant answering from forty published policy documents and an assistant answering across a shared drive, a document management system and live ERP data with permissions enforced per user are separated by an order of magnitude in effort, and both are described in a brochure as an AI assistant.

Rates are the comparable measure and they are public here. Junior work is quoted at PKR 500 to 1,000 an hour, full stack development at PKR 3,500 to 8,000, with senior specialists at the top of that band. Where the engagement is scoped as a project, custom web application pricing at PKR 200,000 to 1,000,000 and upwards is the nearest published comparator, and it holds because the retrieval pipeline, the permission enforcement, the citation behaviour and the interface are all ordinary software.

Four items move the figure. Source count and format come first: clean documents in one repository are one job, while scanned circulars from 2014 across three shared drives are another. Permission enforcement is second and it is the line most often missing from a cheap quotation, because filtering at retrieval by the user's own entitlements is real engineering and the alternative is an assistant that quotes a salary band to the wrong person. Evaluation is third. A question set with agreed correct answers has to exist before anybody can say the thing works, and building it is funded work. The interface is fourth, whether that is a web application, an existing chat platform or a messaging channel your dealers already use.

Running cost is metered and it grows with adoption, which is a good problem arriving as an invoice. Index storage, model consumption per question and re-evaluation after each provider version change all continue. We scope a pilot on one source set and one audience, publish the evaluation results, and quote a build afterwards. A real figure follows discovery.

  • Source count, format and location established before anything is priced
  • Permission aware retrieval costed explicitly rather than assumed into the build
  • An evaluation question set with agreed answers funded as project work
  • Custom web application pricing at PKR 200,000 to 1,000,000 and upwards as the comparator
  • Metered consumption, index storage and re-evaluation budgeted as running cost
02

How long an assistant takes to build

Reported timelines give six to twelve weeks for a focused single scope go live, and an assistant over one curated source set for one audience fits inside that. Three to six months is realistic once several repositories, permission enforcement per user and a live ERP source are involved.

Content preparation is the first real item. Documents have to be found, deduplicated and dated, and somebody has to decide which of the four versions of the leave policy is current. That question is not technical and we cannot answer it for you, which is why we ask for the owner of each source in week one rather than week five.

Building the evaluation set is the second. Thirty to a hundred real questions with agreed correct answers, written by people who actually field those questions today, is what turns an impression into a measurement. It also produces the most useful early finding in these projects, which is the number of questions your own staff cannot answer consistently either.

Identity integration is the third and it has a queue of its own. Connecting to your directory so retrieval respects the permissions a user already holds means working with whoever administers that directory, and their change window belongs to them rather than to the project. We treat it as a dated dependency, and we do not launch an assistant to a wide audience before it is in place.

Then evaluation, run and reported before rollout rather than after the first complaint. Where the answers are wrong the fix is usually in the content rather than in the prompt, which sends the work back to the source owner and adds a week that was always going to be spent somewhere.

  • Six to twelve weeks reported for one curated source set and one audience
  • Three to six months once several repositories, per user permissions or ERP data are in scope
  • An owner named for every source, since currency of a document is a business decision
  • An evaluation set of real questions with agreed answers built before rollout
  • Directory integration treated as a dated dependency rather than a final step
03

When the document estate has no owner

This is the condition that decides these projects and it is almost never in the brief. An assistant answers from what it is given, so the honest question is not which model to use but who decides what is true. Where four versions of a policy sit across a shared drive, a document management system, somebody's mailbox and a printed copy on a noticeboard, the assistant will find all four and answer confidently from whichever it retrieves. That is not a model failure. It is an accurate reflection of an estate nobody owns.

The pattern is easy to recognise once you look. Documents with no effective date and no review date. Two departments maintaining the same procedure separately and neither aware of the other. A folder called final, beside a folder called final revised. Contracts stored by whoever negotiated them. In this state a search tool is already unreliable, and adding a language model on top makes the unreliability sound authoritative, which is worse than the original problem rather than better.

So the sequence we recommend is narrow rather than ambitious. Pick one source set with a genuine owner, usually human resources policies or a product manual set, because somebody there can say which document is current and will keep saying it. Publish the assistant to that audience with citations visible, so every answer can be checked against the document it came from in one click. Add a feedback route and read it weekly. Then extend to the next source set only when it too has an owner willing to be named.

Where no source set has an owner, we say so plainly and decline to widen the scope. The right work in that situation is content ownership rather than retrieval engineering: a register of documents, an owner and a review date recorded against each one, and the duplicates retired for good. It is unglamorous, it costs less than the assistant, and every search tool you already run improves the day it is finished. We would rather write that recommendation than deliver an assistant that quotes a policy withdrawn in 2021.

  • One source set with a named owner chosen for the first release
  • Citations shown on every answer so a person can check the source in one click
  • Effective dates and review dates treated as a requirement rather than a nicety
  • Feedback captured and read weekly, with content corrected rather than prompts tuned
  • Content ownership recommended ahead of retrieval work where no source has an owner
How we deliver

Delivering AI assistants over enterprise data

One process, a cost in hours today, and a target that can be measured afterwards. These six steps add something the other practices do not need: an evaluation set built before anybody writes a prompt.

  1. 01

    Discover

    Volume, consistency, how an answer would be checked, and what a wrong one costs. We also give a capable person the same documents as a control, because if they cannot produce the answer, no model will.

  2. 02

    Blueprint

    A few hundred real cases with agreed correct answers, assembled with the people who do the work now. Where two experienced reviewers disagree, that is an undocumented rule, and it gets settled here.

  3. 03

    Build

    Extraction, validation against the purchase order or master record, confidence thresholds and the exception queue are built together. Retrieval is filtered by the asking user's existing permissions, never after the answer is generated.

  4. 04

    Test

    The evaluation set is run and scored against the human baseline, per document type, so you can see where accuracy holds and where it does not. Thresholds are set from that, not from a default.

  5. 05

    Go live

    Live on one process, with cost budgets and alerts already configured, exception owners named, and a written route back to the manual process that the people who would use it have rehearsed.

  6. 06

    Run

    Re-run the evaluation set on a schedule and after any model or prompt change, because a supplier redesigning an invoice can degrade accuracy quietly. Below the agreed threshold, the automation pauses.

Working together

What we will not build

We will not build an assistant over a document estate that nobody owns and nobody dates. The result reads well and misleads, and it will be trusted precisely because it reads well. Where that is the situation, the useful first engagement is curating a defined corpus with owners, effective dates and a retirement process, which is a content project rather than a technical one and delivers value on its own terms.

Nor will we put an assistant in the position of deciding something about a person. Entitlements, employment matters, credit and legal positions need a human decision with a human accountable for it, and the assistant's proper role there is to find the relevant policy and the relevant precedent, then hand the question to somebody who can answer it.

Credentials

Accreditations behind AI solutions

AI work reads from systems that already exist, so most of what follows is about the data platform underneath and the terms under which data moves.

Oracle

Partner

The data an assistant or forecast reads usually sits in Oracle. We build the extract views, document the schema, and use AI Vector Search in 23ai where retrieval belongs next to the data.

Microsoft

Partner

Azure hosts the processing where residency requires it, Power BI carries forecast output to the people who act on it, and SQL Server is often the source the model reads history from.

Google

Partner

Document AI handles the first pass on scanned and photographed invoices where layout varies, and Google Cloud gives a stated processing region when a document set cannot leave a jurisdiction.

FBR digital invoicing

Compliant integrations

Supplier invoices read automatically still have to reconcile to what was reported. Extracted sales tax values are checked against the purchase order and the return, with mismatches routed to a person.

HIPAA

Compliant practices

Clinical and claims documents are processed under a business associate agreement, with identifiers redacted where the task does not need them and provider terms that exclude training on your content.

Client words

What AI solutions clients say

Comments from people who run ai solutions systems day to day.

  • The handover was the part I judged them on. Configuration decisions documented with the reasoning, our administrators trained properly, and a checklist we actually worked through. We run it ourselves now, and calling them is a choice rather than a necessity.
    Head of Shared Services Multi site manufacturing group
  • What sold us was that they argued with our brief. We asked for a reporting layer and they came back saying the reporting was fine, the batch data underneath it was not, and fixing that first would cost less. That turned out to be right. Our first mock recall after go live took an afternoon instead of the better part of a week.
    Finance Director Food manufacturing group, Karachi
  • We had been through one failed implementation already, so we were sceptical of the whole category. The difference here was the migration work. Two full rehearsal loads before the real one, with a reconciliation pack we could check ourselves. Nobody had ever handed us evidence like that and asked us to sign it.
    Head of IT Wholesale distribution business
Questions

Questions about AI assistants over enterprise data

Price follows the sources rather than the chat window. Rates are the comparison: full stack development here is quoted at PKR 3,500 to 8,000 an hour, and custom web application pricing of PKR 200,000 to 1,000,000 and upwards is the nearest project comparator, since retrieval, permissions and citation are ordinary software. Model consumption is metered on top. We price a pilot first.

Reported timelines give six to twelve weeks for one curated source set and one audience, and three to six months once several repositories, per user permissions or live ERP data are involved. Preparing the content and agreeing which version of each document is current usually takes longer than the engineering, and neither of those is a technical decision.

It means the model is not answering from memory. Your documents are indexed, the relevant passages are retrieved for each question, and the model is asked to answer from those passages and cite them. If nothing relevant is found it should say so rather than improvise. That is why the quality of the answer depends far more on the document estate than on which model is used.

A chatbot usually follows scripted paths written in advance and is good at a known set of questions, which is why it works well on a WhatsApp channel for order status. An assistant answers from source material it retrieves, handles questions nobody scripted, and must be able to refuse. The second is more useful and more dangerous, which is why citation and permissions matter.

Yes, and it has to be enforced at retrieval rather than in the wording of the answer. The assistant searches only what that user is already entitled to open, using your directory rather than a separate list somebody maintains by hand. An assistant that filters after retrieval is one prompt away from disclosing something, and we will not build it that way.

Yes, through a read interface with the same permission rules, so an assistant can quote a policy and an order status in the same reply. Live data is treated differently from documents: it is fetched at the moment of asking rather than indexed, and the answer says when the figure was read, because a stale number presented confidently is worse than no number.

More in AI solutions

More AI solutions services

AI & automation

AI document processing

Invoices, purchase orders, delivery notes and forms read automatically into your ERP.

Open service page → AI & automation

Forecasting & analytics models

Demand, inventory and cash forecasting models built on your transaction history.

Open service page → AI & automation

Process automation

Rule-based and AI-assisted automation of the approvals and reconciliations that eat staff time.

Open service page → AI & automation

AI integration & governance

AI capability connected into existing applications, with cost, access and audit control.

Open service page →

Answers your staff can check?

Tell us what you run today and where ai assistants over enterprise data is causing you trouble. The first conversation is a consultation rather than a pitch.

Book a consultation All ai solutions