How long does an in-house AI rollout take? The 8–10 week plan, who the client has to assign, and the six variables that decide whether you finish on time

This question almost always arrives around minute ten of the first meeting, right after the one about money — and it deserves a better answer than "it depends". Our earlier piece on the real cost of running an LLM on-premise answered the money half with numbers. This one answers the time half, the way a project schedule should actually be read: phase by phase with an exit criterion for each, who on the client side has to show up when, which deadlines the law has already fixed and nobody can negotiate, and which variables really decide whether you land at the start or the end of that range. We deliberately do not give one number that applies to every company — because that number, wherever it is offered, is almost certainly invented. Every technical and legal fact below was checked on 05/08/2026 and is cited in place.

Why nobody can answer "how long" on the first call

Because the time an in-house AI system takes has almost nothing to do with installing software — it depends on how fast the client makes decisions and how fast the client tidies up its documents, and no vendor knows either of those before opening the document store and looking.

This is the biggest difference between an in-house AI project and an ordinary software project. For a sales management system, scope lives in features: list the screens, estimate the effort, produce a schedule. For in-house AI, the software is only the shell; the substance is the company's own documents — procedures, contract templates, internal guidance, minutes, past quotations. With the identical package, a company whose documents sit tidily on one file server finishes noticeably earlier than a company whose documents are scattered across five places with half of them photographed on paper.

Which is why the only trustworthy figure a vendor should offer before an assessment is a range, plus the list of things that decide where in that range you land. Namtech publishes that range openly on its home page: a five-phase rollout, typically 8–10 weeks in total, depending on document volume and depth of integration. This article unpacks each phase along an axis that roadmap tables usually skip: at each phase, who the client must assign and what they must prepare — because that is where schedules slip.

The money question already has its own article: the real cost of running an LLM on-premise works through VRAM, electricity and the break-even point against renting an API. This piece is the other half of the same decision.

The 8–10 week plan: five phases and what counts as done

Five phases — assessment and design, infrastructure and model deployment, knowledge ingestion and tuning, integration and testing, go-live and handover — each with its own acceptance criterion, and the next phase does not start until the previous one meets it.

The exit criterion is what keeps a schedule from drifting. An in-house AI project falls very easily into a state of being "almost done" for weeks: the model runs, the answers look reasonable, but nobody dares declare it acceptable because nobody ever agreed what acceptable means. The only way to block that is to fix the acceptance criteria in phase 01, before a single line of configuration exists.

The table below reads the published plan along a two-sided responsibility axis. The duration column comes straight from the plan Namtech publishes; the other two columns are how we split the roles on projects we have run.

Read that table and something slightly counter-intuitive appears: of the five phases, only phase 02 sits almost entirely with the vendor. The other four all have an entry in the fourth column, and each of those is a point where the project can stop and wait. This is why an honest answer to "how long" always carries a second clause: "if your side does these things on time".

Phase 0: the work that must finish before the clock starts

Before week one there is a stretch of time that appears on no roadmap — the gap between wanting to do this and deciding to do it — and for many organisations that gap is longer than all five phases put together.

Phase 0 has three tasks, and all three are purely internal. The first is appointing a problem owner: someone with the authority to say "the scope is this, not that", and to say it in the meeting rather than after a week of consultation. In-house AI projects blow their schedules less often because the engineering is hard than because every scoping question has to climb three layers of approval.

The second is choosing a first problem narrow enough to measure. "An AI assistant for the whole company" is not a scope, it is an aspiration. "Answer questions about the procurement process and standard contract terms, for procurement and legal" is a scope — because you can build a sample question set from it and mark the answers. We unpacked starting narrow and widening later in the overview of building your own in-house AI.

The third is deciding who may see what, at diagram level, before any configuration. An internal document retrieval system without permissions becomes the fastest information leak in the organisation: salaries, contracts and HR records all live in the same document store. That diagram is not the vendor's job — it is a governance decision, and we describe the common models in per-department AI permissions.

None of these three costs money or requires technical expertise. But if you enter phase 01 without them, phase 01 expands to do them for you — and that is how an eight-week plan becomes a four-month project.

Who the client has to assign — and why one missing role slips the schedule

An in-house AI project at mid-market scale needs four roles from the client, and three of the four do not belong to the IT department.

This is where many organisations go wrong from the start: hand the whole project to IT, then act surprised when the system answers fluently and gets the business wrong. IT can stand up the infrastructure and open the login, but nobody in IT knows how many mandatory clauses a company sales contract carries, or which month's version of the spending approval procedure is current. The four roles below are the minimum.

The most demanding role, and the most consistently underestimated, is the domain expert in phase 03. Their job is not "try it out and see" but to sit and mark: this one is right, this one is wrong here, this one is right but omits a material clause. Without a marker, phase 03 has no exit criterion and the project enters the indefinite "almost done" state described above. If the organisation cannot free that person for two continuous weeks, the correct response is to stretch phase 03 and say so in the schedule, not to pretend it is still two weeks.

Documents: where projects stall longest

Of the five phases, knowledge ingestion is the only one whose duration depends almost entirely on the state your data is already in — and the only one a vendor cannot shorten on your behalf.

Documents come in four states, and the processing effort between them differs enormously. The easiest state is digitally native, structured, currently in force, and stored in one place: gathering and indexing is nearly direct. The second is digital but scattered across shared folders, mailboxes and individual cloud drives; the extra work here is gathering and de-duplicating, and de-duplication is a job only insiders can do because it requires knowing which copy is current.

The third state is documents photographed or scanned into images. This is where real time goes: the machine has to recognise characters before it can understand anything. Open-source tools handle this, including Vietnamese — Tesseract states it recognises "more than 100 languages out of the box", and the project's official training data repository ships a vie.traineddata file. But the tools' own documentation is blunt about the limits: the Marker project lists under known limitations that "Very complex layouts, with nested tables and forms, may not work". That is precisely the shape of most Vietnamese corporate paperwork: contracts with tabular annexes, minutes with signature blocks, invoices scanned crooked.

There is a licensing detail here that trips people up. The same Marker project states its code is Apache 2.0 but its model weights are not: "Our model weights use a modified AI Pubs Open Rail-M license (free for research, personal use, and startups under $5M funding/revenue)". A company above that threshold has to buy a licence — a conversation that costs time if you only discover it after the system is running. Alternatives exist: Docling is MIT-licensed and describes itself as offering "Local execution capabilities for sensitive data and air-gapped environments", which is exactly the in-house context.

The fourth state, the hardest, is knowledge that was never written down — the kind that lives in a few people's heads. No tool extracts it; someone has to interview and write it up, and that is the client's work. It is also the only item in the document phase that more budget cannot shorten.

Hardware and model: the only part you can estimate by arithmetic

Across the whole project, infrastructure and model is the one area where duration can be estimated by calculation rather than by experience — because every variable in it is a published number: the size of the weights you must download, the platform requirements of the serving stack, and the licence terms that have to clear legal.

Start with the easiest variable: downloading the model weights. This is an exact figure, not an estimate. Summing the .safetensors files in the official Hugging Face repositories gives: Mistral-7B-Instruct-v0.3 at 14.50 GB, Qwen3-32B at 65.52 GB, and Llama-3.3-70B-Instruct at 141.11 GB spread over 30 files. At the far end, DeepSeek-R1 comes to 688.59 GB across 163 files. Over a 100 Mbps link used at full capacity, downloading the 70-billion-parameter weights alone takes over three hours; the largest set on that list takes more than fifteen. This is the kind of time that adding people does not shorten, and the reason the download should start on day one of phase 02 rather than when it is first needed.

The second variable is the memory needed to run it. NVIDIA's documentation gives the formula directly: "A good heuristic formula for per-GPU weight memory is: weight_memory_per_gpu = total_parameters x bytes_per_parameter / TP" — parameters times bytes per parameter, divided across the GPUs running in parallel, where BF16 and FP16 are 2 bytes, FP8 is 1 byte and INT4 is 0.5 bytes. The same page warns that this is not the whole story: "Beyond weights, GPU memory is also needed for KV cache, activations, communication buffers, and CUDA graphs." We worked the arithmetic through in the real cost of running an LLM on-premise; the scheduling consequence here is simply that the hardware configuration has to be fixed before you can order it, and procurement lead time is a variable outside both parties' control.

The third variable rarely makes it onto a schedule but blocks at exactly the wrong moment: the platform requirements of the serving software. Two common choices demand very different infrastructure. The vLLM installation documentation requires Linux, Python 3.10–3.13 and a GPU with compute capability 7.5 or above, and states plainly that "vLLM does not support Windows natively". Ollama, by contrast, accepts substantially older hardware: "Ollama supports Nvidia GPUs with compute capability 5.0+ and driver version 550 and newer". The gap between 5.0 and 7.5 is the boundary between "use the machines you have" and "buy new ones" — and buying new ones puts your schedule in a distributor's hands. Going the packaged NVIDIA route makes the requirements more specific still: NVIDIA NIM's prerequisites page lists Ubuntu 22.04 LTS or later, CUDA SDK 12.9 or later, GPU driver 580 or later and Docker 24.0 or later.

Namtech takes a different route here — the whole platform runs on Apple Silicon installed in the client's office, in three configurations by scale — so procurement and installation are lighter than the GPU server path. But the principle is identical on any platform: model size drives configuration, configuration drives procurement time, and those two should not be scheduled back to back.

The last column is the one that gets forgotten until legal asks, at which point the project stops and waits. Open model licences are not one uniform thing. Llama 3.3 carries additional commercial terms: above 700 million monthly active users you must request a separate licence from Meta, alongside an obligation to "prominently display "Built with Llama"" on a website or in product documentation. No Vietnamese company will reach that user threshold — but the display obligation does apply, and legal needs to know before go-live rather than after.

Qwen is more complicated because the licence differs by release. Qwen3-32B ships under plain Apache-2.0, with no user threshold and no attribution requirement. But Qwen2.5-72B-Instruct uses a bespoke licence whose threshold is seven times lower than Llama's: "If you are commercially using the Materials, and your product or service has more than 100 million monthly active users, you shall request a license from us", plus an obligation to display "Built with Qwen". The smaller release is the dangerous one: Qwen2.5-3B-Instruct sits under a research licence which defines ""Non-Commercial" shall mean for research or evaluation purposes only" — meaning commercial use is not permitted. "Qwen is Apache 2.0" is a false statement, and the kind of false statement that only surfaces when legal reads carefully, typically in go-live week.

The same trap exists on the tooling side. Mistral's models fall into three groups: releases such as Mistral-7B and Mixtral-8x7B are Apache-2.0, but Mistral-Large-Instruct-2407 sits under the research licence MRL 0.1, which states "You shall only use the Mistral Models, Derivatives … and Outputs for Research Purposes" and explicitly excludes employees using it in their daily work. The short version: hand the shortlist of candidate models to legal in phase 01, not phase 04. It costs a few days early and a few weeks late.

The deadlines you cannot negotiate

This is the only item in the project whose deadline is set by law rather than agreed between the parties — and its clock starts on the first day the system processes personal data, not on go-live day.

The legal framework has changed completely in two years. The Personal Data Protection Law No. 91/2025/QH15 was passed by the 15th National Assembly on 26 June 2025, and Article 38.1 states: "Luật này có hiệu lực thi hành từ ngày 01 tháng 01 năm 2026" — this Law takes effect from 1 January 2026. On the same date, Decree 356/2025/ND-CP providing implementation detail also took effect, and it is that decree which retires the document many legal teams still treat as their handbook. Its Article 42.2 reads: "Nghị định số 13/2023/NĐ-CP ngày 17 tháng 4 năm 2023 của Chính phủ về bảo vệ dữ liệu cá nhân hết hiệu lực kể từ ngày Nghị định này có hiệu lực thi hành" — Decree 13/2023 ceases to be in force from the day this Decree takes effect. If your internal procedures still cite Decree 13, they cite a document no longer in force.

The number that matters most for an in-house AI project is 60 days. Article 21.1 of the Law requires the data controller to prepare a personal data processing impact assessment dossier and "gửi 01 bản chính cho cơ quan chuyên trách bảo vệ dữ liệu cá nhân trong thời gian 60 ngày kể từ ngày đầu tiên xử lý dữ liệu cá nhân" — send one original to the specialised personal data protection authority within 60 days of the first day of processing. Note where the count starts: the first day of processing. For an in-house AI system that falls during knowledge ingestion — roughly week five of the plan — not on launch day. Decree 356 adds the filing mechanics and forms 02a/02b, and its Article 19.5 gives the authority "thời hạn 15 ngày" to return its assessment. The dossier also has to be maintained: Article 22.1 requires it to be updated "định kỳ 06 tháng khi có sự thay đổi" — every six months when something changes.

The second deadline matters even more, because it reaches directly into the technology choice. Article 20.2 sets the same 60 days for the cross-border personal data transfer impact assessment dossier. And the Law's definition of a cross-border transfer includes "sử dụng nền tảng ở ngoài lãnh thổ … để xử lý dữ liệu cá nhân được thu thập tại Việt Nam" — using a platform outside the territory to process personal data collected in Vietnam. In other words: an AI assistant that calls out to a model service hosted abroad in order to process documents collected domestically falls squarely into this category. An incomplete dossier gets 30 days to be completed under Decree 356, with the warning that failure to do so leads the authority to "xem xét áp dụng các quy định về xử phạt vi phạm hành chính" — consider applying administrative penalties. This is precisely why many organisations keep the entire processing loop onshore; we covered that argument in AI sovereignty and in Copilot in-country and data sovereignty.

The third is 72 hours for breach notification. Article 23.1 requires a controller that detects a potentially damaging violation to notify the specialised authority "chậm nhất là 72 giờ kể từ khi phát hiện hành vi vi phạm" — no later than 72 hours after detection. That number does not affect the rollout schedule, but it dictates something inside the rollout scope: the system must keep logs detailed enough to answer, within 72 hours, who accessed what. Those logs have to be designed in, not patched on.

The second legal layer concerns AI itself. The Artificial Intelligence Law No. 134/2025/QH15, passed on 10 December 2025, states in Article 34 that it takes effect on 1 March 2026; Decree 142/2026/ND-CP implementing it took effect on 1 May 2026 — we summarised its risk classification scheme in Decree 142/2026 on AI. The scheduling-relevant part sits in Article 35 of the Law: AI systems already operating before 1 March 2026 get a transition window to comply — "18 tháng" for AI systems in healthcare, education and finance, and "12 tháng" for everything else.

One escape hatch worth knowing for smaller companies: Article 38.2 of the Personal Data Protection Law lets "doanh nghiệp nhỏ, doanh nghiệp khởi nghiệp" — small enterprises and start-ups — choose whether to apply the obligations in Articles 21 and 22 for five years from the Law's effective date, unless the company provides personal data processing services, processes sensitive personal data, or processes data on a large number of subjects. Decree 356 quantifies "large number" in Article 41: "từ 100 nghìn chủ thể dữ liệu cá nhân trở lên" — 100,000 data subjects or more on a cumulative basis. This question should be answered in phase 01, because the answer decides whether a parallel compliance track is needed at all.

Read this table next to Table 1 and it becomes clear why compliance should not be scheduled last. Start the dossier in go-live week and the 60-day clock has already been running for weeks, because the first day of processing happened back in knowledge ingestion. Start a parallel compliance track in phase 01 and most of what the dossier needs — the categories of data processed, the purpose, the retention period, who may access it — is exactly what you had to decide anyway to build the permission model. Do it once, use it twice.

Note: the above summarises deadlines written into legislation and is not legal advice. Applying them to a specific company requires a lawyer or an in-house legal function.

Acceptance and go-live: when is it actually done

An in-house AI system is done when real users log in with company accounts, ask the questions from the sample set fixed back in phase 01, and the pass rate clears the threshold both sides agreed — not when the system runs.

Those three words, "sample question set", are the entire difference between a project that ends on time and one that drags. The set has to be built in phase 01, by the domain expert, and it has to be frozen — if new questions keep arriving while you work, the finish line recedes at exactly the speed you approach it. A practical structure splits it into three groups: direct lookups whose answer is in the documents, questions requiring synthesis across several documents, and questions with no answer in the corpus at all. The third group tests whether the system will say "I don't have this information", and it is usually the sharpest divider between a usable system and a dangerous one.

The passing threshold should be a number, not a feeling, and should be set separately per group. Machine-side scoring has ready-made open-source tooling, and what makes it valuable for an in-house system is that it runs locally: DeepEval describes itself as a framework "similar to Pytest but specialized for unit testing LLM apps", with metrics that run "locally on your machine" — including four aimed specifically at document retrieval systems: answer relevancy, faithfulness, contextual recall and contextual precision. At the academic layer, EleutherAI's lm-evaluation-harness advertises "over 60 standard academic benchmarks for LLMs, with hundreds of subtasks and variants implemented". But to be blunt: those academic suites compare models against each other; they do not substitute for your own business question set. We covered scoring, building the evaluation set and reducing hallucination separately in building your own in-house AI: evaluation.

One more question tends to land at exactly this point and has a strong ability to stretch the schedule: "do we need to retrain the model on our data?" The default answer should be no, at least on the first pass. Microsoft's comparison of the two approaches recommends retrieval augmentation when content changes often, when coverage across many topics matters, and when resources are constrained — "Limited resources: Go with RAG if you don't have lots of data or compute for training, and the base model already does a good job". The same document lists the challenges of fine-tuning, among them "Maintenance and updating: You need to update fine-tuned models as your domain changes" — meaning every internal process change costs another training round. OpenAI says much the same in its accuracy optimisation guide: "many of our largest customer deployments at OpenAI were done using only prompt engineering and RAG".

A note on go-live: it is not the day the project ends but the day the most human-intensive part begins — changing habits. One training session and then silence almost always ends with staff drifting back to the old way within a few weeks. Post-go-live operations, including monitoring, document refresh and handling wrong answers, are described in building your own in-house AI: operations.

Build or buy: measured in time, not money

On the cost axis, building it yourself is almost always cheaper in cash out; on the time axis the reverse holds, and the gap sits in the work that only costs time once if you have done it before — choosing the model, building the index, handling permissions, building the evaluation set.

Before comparing, calibrate expectations with a public data point. Stanford HAI's AI Index 2026, citing a McKinsey survey run from 25 June to 29 July 2025 with 1,993 respondents across 105 nations, measured AI deployment stage against company revenue. The result: among organisations with revenue below USD 100 million, only 5% said their AI programme was "fully scaled"; among those above USD 5 billion the figure was still only 10%, while 31% were still piloting. The report notes that larger companies were the most likely to reach a scaling phase "given the resource and investment demands of integration". Put differently: money and scale do not solve this by themselves — the difficulty is carrying a system all the way, not standing up a prototype. We unpacked that bridge from pilot to production separately in from pilot to production.

Namtech publishes a whole series of do-it-yourself guides — hardware, choosing a model, serving, integration — and we do not retract a word of them. An engineering team with spare capacity and the motivation to learn can absolutely build this. The question is not "can it be done" but "how long will it take, and who does their day job meanwhile".

The most practical choice is not one or the other but a split at a milestone: hire to get from zero to a working system with an evaluation set, then take the handover and run it yourself from there. The condition for that to work is that the handover must be written — system diagram, document refresh procedure, evaluation question set, and who to call when something breaks. A vendor unwilling to hand those over is telling you something worth listening to.

Six variables that decide where in the 8–10 weeks you land

The six items below, not model size or machine specification, are what actually decide whether an in-house AI project finishes on time.

This is also the list to bring into the assessment meeting and score yourself against beforehand. For each row the question is "which state are we in" — and every answer that falls in the right-hand column is a reason the range shifts towards its far end.

The last row deserves one more emphasis. Many teams treat compliance paperwork as something to do after the system runs — when it is the only item on the list with a deadline set by law, non-negotiable, and impossible to shorten by adding people. Run it in parallel from day one and it never sits on the critical path; leave it to the end and it becomes the critical path.

The time an in-house AI rollout takes is not decided by how fast software installs, but by three things on the client side: who has authority to fix scope, what state the documents are in, and whether anyone will sit and mark each answer right or wrong — which is why the 8–10 week range only holds when all three are ready before week one begins.

Frequently asked questions

Note: this article draws on public sources, checked on 05/08/2026. The five-phase durations and the 8–10 week total are the rollout plan Namtech publishes on its own home page, not an industry standard. Tables 1, 2, 5 and 6 are Namtech recommendations and estimates drawn from delivery experience — they carry no external source and should not be read as survey data. The "download time" column in Table 3 is derived by division from the real file sizes over a 100 Mbps link used at full capacity; real-world times are always longer. The dates 1 March 2027 and 1 September 2027 in Table 4 are derived by addition from the 1 March 2026 effective date and are not dates written in the texts. Quoted passages are verbatim from Vietnamese legislation, from official documentation by NVIDIA, vLLM, Ollama, Meta, Alibaba Cloud (Qwen), Mistral AI, Microsoft and OpenAI, from the named open-source projects, and from Stanford HAI's AI Index 2026; English renderings of the Vietnamese legal text are Namtech's. The legal section summarises legislation and is not legal advice — applying it to a specific company requires a lawyer or an in-house legal function. Photographs are from Pexels under the Pexels License — lead image and share image: Tima Miroshnichenko.