Enterprise AI — Frequently Asked Questions

These are the questions that come up most often in a first conversation. The answers are as direct as we can make them, including the cases where our advice is not to do it.

What does enterprise AI transformation cost

There is no list price, but there is a knowable order of magnitude. A project focused on a single use case — equipment-maintenance knowledge base, store inspection analysis — typically runs from the low hundreds of thousands of RMB to the low millions from diagnosis through go-live. Projects spanning several departments with ERP or MES integration cost more.

The number worth calculating is not the quote. Work out how many people the process occupies and how many hours a week each spends, multiply by loaded cost, and you have the annual opportunity cost. If the project pays for itself against that within one to two years, it is usually worth doing.

We do not recommend starting with a large budget for a company-wide transformation. Prove one use case, get real numbers, then decide whether to expand.

How long before we see results

The usual rhythm for a single use case: two weeks of diagnosis, four weeks to a working prototype, then build-out and adoption support. A first usable release is typically live within six weeks — but "results" depend on usage, and real business-metric movement usually appears in months two to four, because the early time goes into getting the front line to actually use it.

Anything promising results in two weeks is describing a demo, not a business outcome.

Where should we start

With a use case that is repetitive, has historical data, and has a clear owner. All three matter: repetition creates the savings, history gives the model something to work from, and an owner makes adoption happen.

Good first candidates: internal knowledge Q&A (turning what senior staff and old documents know into something searchable), report consolidation (multi-site or multi-line data), and first-draft generation (bids, contracts, weekly reports). We advise against starting with customer-facing support — it has the least room for error.

Why do most enterprise AI projects end up unused

Almost never for technical reasons. The three common causes: the old process still works and the new tool adds a step; answers are occasionally wrong, so people stop trusting it after two attempts; and nobody ever declared that the task now belongs to the system, so old and new run in parallel until everyone reverts.

All three are adoption problems, not model-capability problems. Which is why whether someone keeps watching, fixing the process and repairing the data after launch matters far more than which model you picked.

Should we build custom or buy SaaS

Buy when requirements are still moving, when your process resembles the industry norm, or when the target is a highly standardised domain like finance or HR — the maturity of established products there reflects years of accumulation.

Build when your core process differs materially from the norm, when you need to connect several existing systems whose APIs are closed, when data sensitivity requires on-premise deployment, or when per-seat cost at your headcount already exceeds building.

The plain test: if using the product would require changing a business process, and that process is where your advantage lives, build.

Our data is sensitive — can this run on-premise

Yes. Both the knowledge base and the agent platform can be deployed on your own servers or in your own cloud account, with no data leaving the network. Models can be self-hosted open weights, or an enterprise API under a no-retention agreement. The cost difference is significant, so most clients tier it: core data on-premise, general data through an API.

Worth noting: on-premise deployment solves data egress, not internal permissions. Who can ask about what still has to be designed per department and role.

What is the difference between a knowledge base and an AI agent

A knowledge base answers questions. It pulls scattered material together so staff can ask and get a sourced answer. It is passive — it responds when asked.

An agent gets things done. It runs a predefined sequence automatically: a ticket arrives, it classifies it, checks stock, drafts a reply and routes it to the right owner. It is active, triggered by events.

Most companies do the knowledge base first. It shows value quickly, carries less risk, and tidies up the data foundation along the way — which makes the agent work much smoother afterwards.

Our processes are not even digitised yet — can we still do AI

We would advise against it. If core processes still live on paper and in chat groups, there is no data for AI to work from, and whatever gets built has to be fed by manual entry — which nobody maintains for long.

The right order is to digitise first, even with a simple form-based system that turns key actions into structured records. After roughly six months of accumulated data, AI becomes both cheaper and more effective. When we see this during diagnosis we say so rather than pushing for the sale.

Will this mean layoffs

In the projects we have delivered, the usual outcome is the same people handling more volume, not fewer people. The reason is practical: what AI currently does well is repetitive information handling, and in most companies that work is already backlogged — the staff are not idle, the queue is not clearing.

To be honest about the exception: if a role consists entirely of copying numbers from system A into system B, that role will change. The responsible approach is planning those people's transitions in advance rather than after go-live.

What do you need from us

Above all, one business owner with the authority to change the process. AI projects driven purely from IT have a visibly lower success rate, because what has to change is a business action, not an architecture.

Second, data access. Diagnosis requires looking at real data in existing systems, and this routinely stalls on approvals — worth arranging early.

On time: during diagnosis, two or three people per business line for one to two hours each. During adoption support, front-line staff to trial and give feedback.

How do we tell whether an AI vendor is any good

Signals you can check in the first meeting:

• Do they ask about your business? Leading with model architecture and never asking how your process runs usually predicts poor delivery.
• Will they say "we do not recommend this"? A vendor who accepts every requirement is usually billing by the hour.
• Do their case studies contain numbers and failures? Cases with only successes and no mistakes usually mean nothing was finished.
• Do they stay after launch? A contract with acceptance testing but no adoption clause generally means they disappear on delivery.
• Who owns the output? Whether code, documentation and deployment scripts are handed over in full, or the system stays in their hands.

How are you different from a large software firm

We are small, so what we can offer is being on site. Before and after launch our people are with the client weekly, reworking the process alongside shift leads. Large firms normally coordinate that remotely through a project manager, which rarely achieves the same thing.

Conversely, if you need a several-hundred-person-month systems integration, or a supplier with nationwide on-site coverage, we are not the right fit and we will tell you to find a larger team.

Which industries do you work in

Delivered projects cluster in manufacturing, retail chains, professional services, food processing, pharmaceuticals and home care. The team has thirteen years of enterprise systems experience including SAP-grade implementations, so production, supply chain and finance processes are familiar ground.

Industry itself is not the constraint — data foundation and process maturity are. A small company with clean processes is usually easier to get results for than a large one with messy ones.

You are in Shanghai — can you serve companies elsewhere

Yes, depending on the project type. Consulting and training work remotely with occasional travel. Adoption support requires being on site for months, so for projects outside the Yangtze River Delta we assess the on-site cost before committing — and decline if we cannot do it properly, rather than promising and underdelivering.

We are based in Shanghai, so projects in the Yangtze River Delta get the fastest response at the lowest support cost.

How much data do we need

Quality and structure matter more than volume. A knowledge base can produce usable results from a few hundred well-organised documents. Conversely, hundreds of thousands of historical records whose field meanings nobody can explain may yield nothing.

During diagnosis we run a data survey first: what exists, what condition it is in, whether it can be extracted, whether permissions block it. Plenty of proposals die at "cannot be extracted", so we check before quoting rather than after signing.

What if the answers are wrong

Start by accepting that accuracy is not a number fixed on launch day; it is raised through continuous adjustment. We log every question that returned nothing useful, then go back to fix data, tune retrieval and adjust prompts, as a standing loop.

Two product-side measures reduce the risk meanwhile: every answer carries its source so users can check the original, and high-stakes cases — contract clauses, financial figures — are designed to suggest rather than conclude, keeping a human confirmation step.

Is there a risk in staff pasting company material into public AI tools

Yes, and this is the first AI incident most companies experience. Not a model error — client lists, contract terms and financial data pasted into a public chat tool.

The workable response is tiering rather than a blanket ban: state clearly what must never leave, what may be used once redacted, and which compliant internal tools are provided as alternatives. Sending a prohibition email without providing an alternative usually just moves the behaviour onto personal phones.

What is the difference between training and adoption support

Training explains how the tool works. One or two days; the output is "they know how".

Adoption support is staying until it is genuinely used. Typically three months, involving process changes, system adjustments and dealing with resistance; the output is "they are using it".

Training without adoption support is the most common failure mode we see — the session goes well, nobody changes the process afterwards, and within two weeks everything is as it was.

Can we buy only the consulting and implement elsewhere

Yes. The consulting deliverables — a ranked use-case list and ROI worksheet — stand alone and work with any implementation partner. Some clients have taken the list, done the easiest item themselves, and come back for the rest only after it worked.

Equally, the system does not have to be ours for us to provide adoption support; we spend a week diagnosing actual usage before deciding whether to take it on.

Who maintains it after the project ends

Code, documentation and deployment scripts are handed over in full, and your IT team can take it straight on. We can also maintain it annually, but that is an option, not a condition.

We do not do the arrangement where the system lives with us and you have to keep coming back — and we are happy to have that written into the contract.

How do we measure whether the project succeeded

At launch, three numbers: share of the target group using it daily, uses per person, and the proportion of questions that returned nothing useful. Those surface problems earlier than accuracy does.

At three months, business metrics: time taken by a given process, backlog in a given category. Our own definition of success is that you can remove us, operations continue, and nobody wants to go back.

How do we start

Email info@aipartner.cn or call +86 135 0449 5774 and book thirty minutes. The call is free, and its purpose is to judge whether there is anything here worth doing — if the answer is not yet, we will say so and tell you what to fix first.

No preparation needed. Describing the business problem that bothers you most is enough.