Before I ask what your AI should do, I ask what data it touches
The first question on every build is not what the system does. It is what it is allowed to see — and that answer sets the architecture and the price before anyone writes a line of code.
Most AI projects start with a feature list. Someone has seen a demo, they can picture the thing, and the conversation opens with what it should do. Draft the report. Answer the email. Summarise the call.
I start somewhere else, and it makes the first meeting slower and every subsequent one faster. Before asking what a system should do, I ask what data it touches, and where that data must never go.
That is not caution for its own sake. It is the question that decides the architecture, and it decides the price. Settle it late and you rebuild.
Why the feature list is the wrong starting point
A feature is a description of behaviour. It tells you nothing about exposure.
“Draft the monthly report” sounds like one thing. But a monthly report assembled from a management accounts pack is a different system from one assembled from a folder that also contains signed facility agreements and counterparty correspondence. Same feature. Completely different build.
If you scope from the feature, you find that out in week six, when someone asks where the source documents live and the honest answer turns out to involve a shared drive nobody has audited since 2023.
Green, amber, red
The instrument is not complicated. Everything the business holds gets sorted into three tiers, and each tier carries a handling rule, a tooling constraint, and a paperwork requirement.
Green is material you would be relaxed about publishing. Public filings, marketing copy, published research. Public model tiers are fine. No restriction worth writing down.
Amber is commercially confidential but not regulated. Internal reporting, pricing models, draft strategy. This needs a contracted tenancy with retention disabled and logging on, and it needs the vendor terms actually read rather than assumed.
Red is regulated, special-category, or contractually fenced. Personal data, health, payment credentials, anything your own client contracts say cannot reach a third-party processor. Red does not leave the boundary. If a workflow needs red-tier data, either the processing happens inside infrastructure you control, or a human moves the minimum necessary across the gate and the system never sees the rest.
The value is not the taxonomy. Anyone can write three tiers on a whiteboard. The value is doing it before design, because the tier of the most sensitive item in scope sets the architecture for the whole build.
What it changes
One red-tier item can move a build from a hosted automation platform to something running inside your own tenancy. That is not a small variation. It changes the stack, the cost, the timeline, and who can maintain it afterwards.
Which is exactly why it belongs before the quote. A number produced without that answer is a guess, and the person who absorbs the difference is whoever discovers it last.
I have seen the other order. A business running entirely out of a messaging app, client identity documents and payment details sitting in plain text on one phone. The obvious build was a workflow tool that read the chat history. It would have worked. It would also have copied regulated data into a third-party automation log, and the first person to notice would have been an auditor.
We designed the gate first. Then the workflow, on top of a boundary that already held.
The uncomfortable part
Doing this properly means telling people things they did not want to hear on the first call.
Sometimes the honest answer is that the data cannot support the thing they have imagined, or that it can but not at the price they had in mind, or that the process should be fixed before it is automated. That conversation is easier in week one than in week six, and it is a large part of what a client is actually buying.
Wiring is easy. Wiring is how you build a compliance breach with a nice interface.
What to do with this
If you are about to scope an AI build, run the classification first, on the actual documents rather than on a description of them. Ask three questions of every source the system would touch:
- What is the most sensitive item in here, not the typical one?
- Which third parties would see it, including logging and error handling?
- What do our own client contracts say about that?
If those three answers are comfortable, the feature list is a reasonable place to go next. If any of them is uncomfortable, you have just saved yourself a rebuild.