Every AI proposal has a second spec. Find it before you sign.

In October 2026, Flareworks reviewed an AI vendor proposal sent to a Singapore service business: up to $20k to build, plus a monthly fee after that.

On paper the plan was sensible: put the company's manuals, job history, price books and parts lists into one system, let staff ask it questions, and have it assemble quotations when parts are in stock.

Then came the line about how it worked. The system would connect to Claude, ChatGPT or Gemini through a "private connector", and each user would pay the AI provider separately, on a subscription of about $20 a month.

The $20 line mattered more than the $20k one. The subscription is where the company's documents actually go.

Every AI proposal contains two specs. The first describes what the system does for people: answer questions, draft quotes, update the CRM, route requests. That is the one that sells the project. The second describes everything the first leaves out: where the data travels, what happens on the exceptions, who decides when the system is unsure, and what it costs to leave. That is the one that decides whether you are still glad you signed a year later.

"Private" is four different setups

The proposal wasn't proven insecure. The connector may well be fine. But it didn't say which kind of "private" the business was paying for, and the phrase can mean at least four things:

1. Local: a machine you own

   The documents and the model run on company hardware, such as an office computer or server. Strongest control over where data sits, but the company also owns uptime, updates and model quality.

2. Your own cloud account

   The system runs in the company's own AWS, Azure or Google Cloud account, so access, region, storage and backups stay in its hands. More flexible, more setup.

3. A dedicated environment the vendor runs

   A provider runs a separate environment for one client, often on open-source models. A reasonable balance, but the provider and its cloud host are still handling your data.

4. A vendor platform calling outside AI

   Documents go to the vendor's platform, which calls third-party models. Fastest and cheapest to start, and secure enough for plenty of businesses, but you need to understand its storage, retention and deletion terms.

None of these is automatically wrong. Using one word for all of them is. (Measured costs and speeds are in private AI measured in the cloud and on a laptop; a hands-on version of the first is in how to run your own private AI model.)

The proposal under review did not say which of these it was. It also left out:

• where the source documents, prompts, answers, search indexes, logs and backups are stored, and in which country
• how long each is kept, how to delete it, and whether the vendor can reach in for support
• which model and which plan each feature uses
• how staff would actually use it: which app, which login, how many accounts are included
• who uploads, approves, reviews and retires documents
• whether answers cite their source, and what happens when two documents disagree

The proposal did say company data was "not retained for training". That answers one question out of the six above.

This matters in Singapore for a plain legal reason. Under the Personal Data Protection Act, when another company processes personal data on your behalf, you carry the same obligations for that data as if you processed it yourself. The vendor's data flow is your responsibility.

The second spec is also your real operating rules

Privacy is only half of the second spec. The other half is the rules your business already runs on, which rarely appear in a proposal because nobody has written them down.

A Flareworks audit of a 10-person electrical and plumbing contractor showed this clearly. The visible spec was a dispatch assistant: when an urgent job comes in, suggest which technician should go, and what to move to fit it in.

The owner didn't ask what the AI could do. He asked:

• How will 10 jobs a day show up on screen?
• If two of my people disagree on who goes, who decides?
• Which AI sees my customers' data?
• Is there a grant for this?
• How much will I pay each month?

Not one question about capability. Every one about consequences.

The second question turned out to be the real spec. Two or three people could see an urgent suggestion. If they all had to agree, the job would wait. If anyone could approve, nobody would own the decision. A dispatch system has to encode one rule, and the business has to pick it:

• One duty dispatcher per shift approves; others can only comment.
• First qualified person to respond within a few minutes decides, and the decision is logged.
• Owner first, then a named fallback after a set time.
• Escalate by risk: ordinary jobs need one approver; costly or safety-sensitive changes go to the owner.

None of that is engineering. All of it decides whether the system ships. The pilot spec started with principles, not features: the assistant only suggests and a person approves; it never writes free-form messages to customers; the owner's accounts and data stay his; and if it stops working, the business carries on as normal. The pilot has not run yet, so these are plans, not results. (The AI Trust Ladder covers when a system like this can be trusted to do more.)

Exceptions are where the second spec earns its keep. In one field-service business with 100 jobs a day, 15 technicians and 250-page repair manuals, the honest version of the spec had to say what the system refuses to do. When a part isn't in inventory, it stops and flags it. It doesn't guess a price and it doesn't leave the line blank. Sourcing a part from overseas suppliers stays with the people who know how, and the proposal has to say so before anyone signs.

If the rule lives only in the owner's head, it can't be in the spec. That is why writing down one process comes before buying anything, and why the hidden 20% of a business is usually the approval decisions, not the manual.

Sometimes the second spec says where AI does not go

The owner of a 50-person home-repair and appliance group had already looked at putting AI in front of her customers, and decided against it. Her customers get automated booking confirmations, an "on my way" tracking link and a survey after the job. But the enquiry and the quote stay with a person, on purpose.

"It has to be human touch and not automated. It's deliberately slow."

That is a requirement, and a good proposal writes it down. A real person on the first call tells the customer someone is on it. A faster automated reply can't do that.

Where her business did need help was behind the counter. Technicians on site waited for answers buried in shared drives. Requests got lost across dozens of WhatsApp and Telegram groups with no clear owner. Her job software had been in place for over 10 years, and she described it as "almost impossible to pull out". A team tool had already been tried and dropped because technicians wouldn't log in. When a new dashboard came up: "Who's gonna log in daily?"

So the second spec for her business looked like this:

• Answers come from the company's own documents, with the source and the date it was last reviewed, and the system can say "I don't know" and pass the question to a person.
• Permissions are set by role. A technician sees repair procedures; client-specific pricing is restricted.
• The chat report is read-only at first, and only covers approved work groups. Personal chats and unrelated groups are excluded by design.
• Every request is labelled addressed, unclear or unaddressed. Unclear ones go to a person and are never written into the CRM automatically.
• It lives where people already work, not behind a new login.

The hard case was ordinary group-chat behaviour: several jobs posted, then one technician replying later in a single message covering all of them. A demo never shows that. The second spec has to.

Why finding it late costs more

The second spec usually costs more than the first, and you often find out after the project has started. By then the deadline is promised and the team has been told it's coming. Now you're negotiating where the data sits, with little leverage.

So before you upload manuals, customer histories, price lists or chat records, ask the vendor for two diagrams:

1. The workflow. What the AI does for people.
2. The data flow. Where information travels, who controls each step, and what happens when something goes wrong.

The first diagram sells the project. The second protects the business.

Questions to ask before you sign

A vendor who answers these easily has thought about the second spec. One who calls them technical details has left it for you to find later.