Getting started

You have decided to try private AI. Here is what actually happens next.

What to prepare, what to pilot, and how to prove it worked.

Start with the three questions → See a pilot week by week

Before you talk to anyone, answer three questions internally.

Most first conversations about AI go badly for a simple reason: nobody has decided what the project is for. These three answers turn a vague interest into something a supplier can scope, price and be held to. They take an afternoon, not a committee.

1. What problem, described as work someone does today
Write the problem as a task, with a person and a frequency attached. "Our two admin staff spend most of Monday pulling figures out of supplier invoices" is a project. "We want AI" is not. The test is whether you can name who stops doing something, and what they do instead. If the sentence needs the word AI to make sense, it is not yet a problem statement. Read the worked departmental use cases if you want examples of the right shape.
2. Whose data the work touches
List the documents the task actually reads, then say who they belong to: your own company, your customers, your patients, your staff, or a third party under a contract. This single list decides the deployment mode, on-premise, air-gapped or a private tenancy, and it decides whether your compliance lead needs to be in the room from week one. The privacy and data-residency case for keeping it local is the background reading for this answer.
3. Who owns it, with the authority to say yes
Name one person who owns the outcome and can approve two things: access to those documents, and the time of the people who will test the results. Not a committee, not "IT". A project with an interested audience but no owner is the single most common way a first AI project quietly stops, and no supplier can fix that from the outside.

If you can answer all three in writing, you are ready for a costed conversation. If you cannot, the answers are the work.

There is no penalty for arriving with an unfinished picture, and a good audit will help you sharpen it. But the projects that move fastest are the ones where someone already decided what problem is being solved, on whose data, and who is accountable for the result. Everything on the rest of this page assumes those three answers exist.

Getting your documents ready is the real work.

Hardware arrives configured and models install in an afternoon. What decides whether the answers are any good is the material the system reads. This is the part that is yours to do, and the part most people underestimate.

Document scanning and indexing workstation with organised digital file structures displayed on screen, illustrating source material preparation for a local AI system — Good answers start with **readable, current, correctly permissioned** source files.

What good source material looks like

01 / READABLE

Real text, not pictures of text

A PDF that was scanned on a photocopier is an image. The system cannot read it until it has been through optical character recognition. You can test this yourself in seconds: open the file and try to select a sentence with your cursor.

test: select textOCR if not

02 / CURRENT

One version, marked as the live one

If three versions of a policy sit in the same folder, the system will happily quote the wrong one. It has no way to know which was superseded unless the file set tells it. Retire old versions to an archive folder that is not indexed.

one live copyarchive the rest

03 / SCOPED

Permissions stated, not implied

In most organisations the only thing separating confidential files from general files is which folder they sit in and who has the network share. Write down which groups may see which sets before anything is indexed, so access rules are designed rather than inherited.

groups firstthen index

04 / SELF-CONTAINED

Documents that explain themselves

A table headed "Rates 2025" with no unit, no currency and no scope reads as ambiguous to a machine and to a new hire. Files that carry their own title, date and context produce noticeably better answers than files that rely on the reader already knowing.

title + dateunits stated

The six data problems that show up almost every time

Swipe to see all columns

Problem	How it shows up in answers	What fixing it involves	Who does it
Scans with no text layer	The document is silently invisible, so the system answers as if it does not exist	Run the files through OCR, then spot check that the extracted text is accurate on the worst-quality pages	Your team, or VYROX during setup
Duplicates and near-duplicates	Confident answers that quote a superseded version	Pick one live copy per document, move the rest to a folder that is excluded from indexing	Document owner
Out of date policies	Correct quoting of a rule that no longer applies	A dated review of what is still in force, which most organisations owe themselves anyway	Department head
Permissions baked into folder structure	Either over-sharing, or whole sets left out because nobody could agree who may see them	Map folders to access groups explicitly, before indexing, so the rules are written down	IT with the document owner
Mixed languages in one set	Uneven answer quality depending on which document was matched	Decide the answer language per use case, and keep parallel language sets clearly labelled	Subject expert
Knowledge that lives only in people	Confident answers on paperwork, gaps on how the work is actually done	Write down the handful of unwritten rules the task depends on, even roughly, and index that too	Subject expert

These are the recurring preparation issues in document-heavy environments. Which ones apply to you, and how much effort each represents, is exactly what a scoping audit exists to find out.

Preparation checklist

Work through this for the first use case only. Preparing the whole archive before starting is a well known way to never start.

The document set the first task needs is listed, and it is a set someone can actually name
Every file in that set has selectable text, or is queued for OCR
One live version of each document is identified, and superseded copies are moved out of scope
Each document set is mapped to the staff group allowed to see it, in writing
Anything containing personal data is flagged, so the deployment mode is chosen deliberately
An owner is named for keeping the set current after the pilot ends
A copy of the set exists in your normal backup routine before anything is indexed

Choosing the first use case, and scoring it honestly.

The first project is not the most valuable thing you could do with AI. It is the thing most likely to produce a clear answer quickly. Four criteria decide that, and a use case that fails any one of them makes a poor first project even when it is genuinely worth doing later.

High volume

The task happens daily or weekly, not twice a year. Volume is what turns a few minutes saved into a number anyone can see, and it gives you enough runs to judge quality rather than a handful of anecdotes.

Low risk

A wrong answer is caught by a review step that already exists. Nothing goes to a customer, a regulator or a ledger without a person in between. First projects should not be the place where you discover your review process was theoretical.

Measurable

You can state today's number before you begin: minutes per item, items per week, rework rate. If the only available measure is how people feel about it, you will not be able to justify widening.

Reversible

The old way still works. Nobody has deleted the spreadsheet, retired the template or reassigned the staff. Reversibility is what lets you run an honest pilot instead of an expensive commitment you have to defend.

Score your candidates before you pick

Give each candidate task 0, 1 or 2 on each criterion, then read the total. This is a structuring tool, not a formula: its value is that it forces a conversation about why one task beat another, and it usually surfaces a quiet disagreement about what the project is for.

Swipe to see all columns

Criterion	Score 0	Score 1	Score 2
Volume	Occasional, a few times a year	Weekly	Daily, by several people
Risk if wrong	Reaches a customer or a regulator directly	Caught late, in a periodic check	Caught immediately, by an existing review step
Measurability	Only a subjective impression is available	A number exists but nobody has recorded it	A baseline can be taken this week
Reversibility	The old process would have to be dismantled	Old process survives but degrades	Old process untouched throughout
Document readiness	Source material is scattered or mostly scans	Known set, needs cleanup	A named, current, readable set exists
Owner and expert time	No owner, no expert time committed	Owner named, expert time uncertain	Both named and diarised

Read the low scores, not the total.

A candidate scoring 10 with a zero on reversibility is a worse first project than one scoring 8 with no zeros anywhere. A single zero is a structural weakness that the rest of the score cannot compensate for, because it removes your ability to stop, to measure, or to be wrong safely. Use the total to rank, use the zeros to disqualify.

What a pilot actually looks like, week by week.

VYROX quotes 4 to 8 weeks from approval to a working deployment. The shape below is how that time is typically spent for a document-heavy first use case. Where a project lands in that range is usually decided by document readiness, not by hardware or model setup.

Server rack patch panel with structured network cabling connecting a local AI machine into existing office infrastructure — Most of a pilot is **wiring into what you already run**, not novel technology.

Week 0: baseline, before anything is installed
Record how the task runs today: time per item, items per period, how often work is redone, and what people currently do when the answer is not to hand. This week is unglamorous and it is the one people skip. Skip it and you will spend the end of the pilot arguing about whether anything improved.
Weeks 1 to 2: document preparation and access design
The document set is assembled, OCR is run where needed, duplicates are retired, and access groups are written down. In parallel the hardware is specified and ordered against the sizing work covered on models and hardware. Nothing here is exciting and everything here determines the result.
Weeks 2 to 4: build, index and first internal answers
The machine is commissioned, the model is installed, and the prepared documents are indexed. The first answers are reviewed by the subject expert alone, not by the wider team. This is deliberately a closed loop: early answers expose gaps in the document set, and fixing those is faster before real users form an opinion.
Weeks 4 to 6: real users on real work
A small group uses it inside their normal working day, with the old process still running underneath. Collect what they asked, where the answer was wrong, and what they gave up on. The wrong answers are the valuable data, so make it easy to report one without it feeling like a complaint.
Weeks 6 to 8: re-measure and decide in writing
Measure the same things you measured in week 0, with the same definitions. Then write a short decision: widen, extend the pilot with a named change, or stop. A pilot that ends without a written decision does not end, it fades, and fading is what people remember as the project having failed.

What the pilot must prove before you widen

Answers are correct often enough for this specific task, judged by the person who would otherwise do it
The people doing the work choose to use it without being told to
The time saved is visible against the week 0 baseline, using the same definitions
Nothing about access, logging or data handling surprised your compliance lead
Someone is willing to own keeping the document set current, ongoing, by name
You know which of the wrong answers were document problems and which were model limits

The first 30 days of a VYROX engagement, from the delivery side, are set out on the solutions page. This section is the view from your side of the table.

Who you need on your side, and for how long.

A private AI pilot does not need a project team. It needs four named people with modest, specific commitments. Getting these named at the start is worth more than any technical decision made later.

Swipe to see all columns

Role	What they decide or do	Realistic commitment	What happens without them
Decision owner	Approves scope, access to documents, and the widen or stop decision at the end	A few hours at the start, then a short check-in each week	The pilot has an audience but no verdict, and it fades
Subject expert	Judges whether answers are correct, and supplies the unwritten rules the task depends on	The heaviest load, concentrated in the review weeks	Nobody can tell a good answer from a plausible one
IT contact	Network placement, user accounts through your existing directory, backups of documents and the index	Concentrated around commissioning, light afterwards	The system works but is not wired into how you already run
Everyday users	Use it on real work, report wrong answers and dead ends without it feeling like a complaint	No extra time, it replaces part of existing work	You measure a demonstration instead of a workflow
Compliance lead (if personal data is involved)	Confirms the deployment mode, access rules and logging meet your obligations	Short, but must be at the start, not the end	A late objection lands after the build is done

Commitments are indicative for a single-department first use case. Larger scopes and multi-site or public sector deployments carry more governance overhead; see the government and public sector page for that context.

The constraint is almost never the technology. It is the subject expert's calendar.

The person who can tell a correct answer from a confident one is usually the busiest person in the department. If their time is not protected in advance, review slips, the document gaps stay unfixed, and the pilot reaches its end date with opinions instead of evidence. Book that time before the hardware is ordered.

Measure it properly

A baseline taken before you start is worth more than any dashboard afterwards.

You cannot reconstruct week 0 in week 8. Once people have changed how they work, nobody remembers accurately how long the old way took, and estimates drift towards whatever conclusion the estimator already holds.

Monitoring dashboard screens showing throughput, response time and usage trend charts for a local AI pilot deployment — Same measures, same definitions, **before and after**. That is the whole method.

Swipe to see all columns

What to measure	How to capture it	When to read it	Why it matters
Time per item	A one week tally by the people doing the task, not an estimate from memory	Week 0, then the final week	The headline number every widening decision rests on
Items per period	Counted from whatever system already records the work	Week 0, then the final week	Turns minutes saved into something worth a decision
Rework rate	How often output is sent back or corrected, however roughly counted	Week 0, then the final week	Catches speed bought with quality, which is not a gain
Answer acceptance	A one click good or not good on answers during the pilot	Continuously, read weekly	Shows whether quality is improving as documents are fixed
Voluntary usage	How many of the pilot group use it in a week without prompting	Weekly, ignore week one	The most honest signal that it is genuinely useful
Cloud subscriptions replaced	List the tools the pilot group stopped needing, with their monthly cost	Final week	Feeds the cost case set out on the pricing page

Ignore the first week entirely

Week one measures people learning a new tool, including the ones who forget it exists. Reading it as a result produces a pessimistic number that then has to be argued away. Say in advance that week one is excluded, so nobody is accused of moving the goalposts later.

Write the definitions down first

"Time per item" has to mean the same thing in week 0 and week 8, including whether interruptions and review time count. A definition agreed after the numbers are in is not a measurement, it is a negotiation.

Keep the wrong answers

A log of wrong answers, each tagged as a document problem or a model limit, is the most useful artefact a pilot produces. Document problems are usually fixable in days. Model limits tell you where a human review step must stay permanently.

Widening from a pilot to the wider organisation.

Widening multiplies whatever the pilot actually was. If the pilot proved its case, that is leverage. If it did not, widening turns one unresolved problem into several, in departments with less patience for it.

Network topology diagram of a central on-premise AI server connected to multiple department workstations across an office site — One proven department first, then **the next most similar one**.

Widen by similarity, not by enthusiasm
The second department should be the one whose work most resembles the first: similar document types, similar review steps, similar risk profile. Most of what you learned transfers, and the second rollout is far quicker than the first. The department that shouted loudest is often the least similar one.
Treat capacity as a separate decision from proof
A workstation build that comfortably served a pilot group will not serve four departments at once. Widening turns into a sizing question about concurrent users and response time, which is the ground covered on models and hardware. Because open models can be swapped on the same machine, this is usually a capacity decision rather than a fresh purchase decision.
Every new department brings a new document problem
Preparation effort does not scale down as neatly as the technical work does. Each new set brings its own scans, its own superseded versions and its own permission questions. Budget the same preparation attention for department two as you gave department one, and it will still be faster because you now know what you are looking for.
Access rules get harder, not easier, with scale
Two departments sharing one system is the point at which "who may see which documents" stops being obvious. Settle it as a written rule set tied to your existing directory groups before the second department is indexed, not after someone finds an answer they should not have seen.
Write down what the pilot taught you
The prompts that worked, the documents that had to be fixed, the questions the system cannot answer. This is genuinely useful internal material and it is why the second rollout is faster. The resources library covers the background reading; the department-specific knowledge is yours to keep.

Why first projects stall, and how to avoid each one.

Almost none of these are technology failures. They are planning gaps that only become visible at the end, when there is nothing to point at. Each one has a cheap preventive step taken at the start.

Swipe to see all columns

The stall	What it looks like	The cheap prevention
No named owner	Interest from several people, decisions from none, meetings that end in "let us circle back"	Name one person who can approve access and time, before anything is scoped
Interesting instead of measurable	A demo everyone enjoys attached to a task nobody counts	Score candidates and disqualify anything with a zero on measurability
Documents never prepared	Answers that are vague or wrong, blamed on the model	Do the preparation checklist for one use case, before the build
No baseline	A pilot that clearly helped, with no way to show it	Spend week 0 counting, with definitions written down
Scope grew mid-pilot	Three more departments added, end date unchanged, nothing finished	Write the scope down and treat additions as a second pilot
Boiling the ocean first	Six months of preparing every document in the company before starting	Prepare only what the first use case needs, extend later
Ended without a decision	The pilot quietly stops being used, and is remembered as a failure	Diarise the widen, extend or stop decision on day one
Compliance consulted last	A late objection about access or personal data, after the build	Bring the compliance lead in during the three questions, not at handover

Every item on that list costs less than an hour to prevent, and weeks to recover from.

That asymmetry is why this page spends more time on preparation and measurement than on technology. The technical side of a first private AI deployment is well understood and largely someone else's job. The parts that decide whether it works are decisions only your organisation can make, and they are all cheap if made early.

Questions people ask before their first project.

What should we decide internally before contacting anyone about private AI?

Three things. First, the specific problem you want solved, written as a task someone does today rather than a technology you want to buy. Second, whose data the work touches, and how sensitive it is. Third, who inside the organisation owns the outcome and can approve access to those documents and the time of the people who will test the results. If any of the three is unresolved, the conversation drifts into a technology demo instead of a scoped project.

How clean do our documents have to be before a local AI can use them?

They do not need to be perfect, but they need to be readable and current. The common blockers are scanned PDFs with no text layer, several near-identical versions of the same policy, documents whose approval status is unclear, and folders where permissions are the only thing separating confidential material from general material. Fixing those before the build is the single largest lever you have on answer quality.

What makes a good first use case for a private AI pilot?

High volume, low risk, measurable and reversible. High volume so a small time saving is visible. Low risk so a wrong answer is caught by a normal review step rather than reaching a customer or a regulator. Measurable so you can compare it against a baseline. Reversible so the old process still works if you stop. A use case that fails any one of these makes a poor first project even if it is valuable in its own right.

How long does a first private AI deployment take?

VYROX quotes 4 to 8 weeks from approval to a working deployment, depending on scope and how ready the source documents are. Data preparation, not hardware or model setup, is the part that usually decides where in that range a project lands.

What should we measure, and when?

Take a baseline before anything is installed: how long the task takes today, how often it is done, how often it is reworked, and what people currently do instead. Then measure the same things, with the same written definitions, during the pilot. Read the numbers at the end rather than in the first week, because the first week measures learning, not the tool.

Who do we need on our side, and how much of their time?

A decision owner who can approve scope and access, a subject matter expert from the team doing the work, an IT contact for network, accounts and backups, and a small group of everyday users. The subject expert carries the heaviest load because they are the one who can judge whether answers are correct. Their availability, not the technology, is usually the real constraint on pace.

What does a pilot have to prove before we widen it?

That answers are correct often enough for the task, that the people who do the work choose to use it without being told to, that the time saved is visible against the baseline, and that nothing about access, logging or data handling surprised your compliance lead. If any of those is unproven, widening multiplies a problem instead of a benefit.

Why do first AI projects usually stall?

Most commonly: no named owner, a use case chosen because it was interesting rather than measurable, source documents that were never prepared, no baseline so nobody can tell whether it helped, scope that grew mid-pilot, and a pilot that ended without a written decision about what happens next. Every one of those is a planning problem rather than a technology problem, and each is cheap to prevent at the start.

Can we start small and widen later without rebuying hardware?

Yes, that is the normal path. Most engagements start with a single workstation or a department pilot, confirm the quality bar and the cost case on real work, then move to a team server or add departments. Open models can be swapped on the same hardware, so a wider rollout is usually a capacity decision rather than a fresh purchase decision.

Do we need to prepare every document before we start?

No, and trying to is a common way to stall. Prepare only the document set the first use case actually needs. A narrow, current, well-permissioned set produces better answers than a large archive full of superseded versions, and it can be extended once the pilot has proven itself.

Your first step

Bring your three answers. We will scope the pilot.

Book a free 45-minute Local-AI Audit. We go through your first use case, what your documents need, and what the pilot would have to prove, in writing, no obligation.

Book via WhatsApp → Start with the overview

Free, 45 minutes
Use case scored with you
No obligation

No deck pitch. Just engineers sizing your build.

You have decided to try private AI. Here is what actually happens next.

Before you talk to anyone, answer three questions internally.

1. What problem, described as work someone does today

2. Whose data the work touches

3. Who owns it, with the authority to say yes

If you can answer all three in writing, you are ready for a costed conversation. If you cannot, the answers are the work.

Getting your documents ready is the real work.

What good source material looks like

Real text, not pictures of text

One version, marked as the live one

Permissions stated, not implied

Documents that explain themselves

The six data problems that show up almost every time

Preparation checklist

Choosing the first use case, and scoring it honestly.

Score your candidates before you pick

Read the low scores, not the total.

What a pilot actually looks like, week by week.

Week 0: baseline, before anything is installed

Weeks 1 to 2: document preparation and access design

Weeks 2 to 4: build, index and first internal answers

Weeks 4 to 6: real users on real work

Weeks 6 to 8: re-measure and decide in writing

What the pilot must prove before you widen

Who you need on your side, and for how long.

The constraint is almost never the technology. It is the subject expert's calendar.

A baseline taken before you start is worth more than any dashboard afterwards.

Widening from a pilot to the wider organisation.

Widen by similarity, not by enthusiasm

Treat capacity as a separate decision from proof

Every new department brings a new document problem

Access rules get harder, not easier, with scale

Write down what the pilot taught you

Why first projects stall, and how to avoid each one.

Every item on that list costs less than an hour to prevent, and weeks to recover from.

Questions people ask before their first project.

Bring your three answers. We will scope the pilot.