The requirements document is free now. Judgement is not.

A few weeks ago I saw a proposal go from intro call to sendable draft in a single afternoon. The client was a loan servicer working on behalf of high street and challenger banks, and the scope was not small: an AI-driven dashboard they intend to sell on to those banks, letting them look at their own portfolio data, analyse how past customers behaved and predict how current ones will. Two years ago the same document would have taken three weeks, two workshops and a Business Analyst who knew the client's data better than the client did.

Nobody in the room thought the afternoon was a problem. I think it is, and the reason sits in what has happened to two roles that used to stand between the sale and the build.

The Business Analyst has moved from producing the specification to validating it

The classic BA's product was the requirements document. Take business language, translate it into something a developer can build against, get it signed off. That was the job, and it was a good one.

That artefact is now close to free. A model drafts process maps, user stories and acceptance criteria from a workshop transcript in minutes. This is essentially what our scoping brief does today, and the output is not worse than what a competent BA produced by hand. In some ways it is more complete, because the model does not get bored on page eleven.

What has not become free is judgement. Is the requirement actually true, or is it what the sponsor said in a workshop while their team stayed quiet? Can the client's data support it, or does the CRM have three definitions of "customer" and nobody has checked? Is the outcome measurable, and by whom?

So the work has shifted. Upstream into data readiness, which is where most AI pilots quietly fail before a line of code is written. Downstream into evaluation design, which is where the surviving ones go to die.

The second part deserves more attention than it gets. An AI system is probabilistic, so "the feature works" stops being a binary test. Someone has to define the acceptable error rate. Someone has to enumerate the edge cases and decide what happens on each one. Someone has to design the escalation path to a human, and write down what "good enough" means to a compliance officer in a bank rather than to a product owner who wants the demo to look smooth.

That is a new competence. It is closer to test design and measurement than to elicitation, and it is the discipline that decides whether a PoC converts to production or dies in a stakeholder's spreadsheet six months later. Most BAs I have worked with were not hired for it and have not been trained for it. The good ones are teaching themselves.

The Solution Architect has moved from choosing the stack to constraining the problem and owning the economics

A reference architecture used to be a three-to-five-year commitment. You picked the platform, the integration layer, the data model, and you lived with the choice through several release cycles.

Today the model layer changes under the design every few months. Most of the integration plumbing is commodity. The architectural decision that used to take a quarter of evaluation is now a configuration flag, and it will be a different flag by the next renewal.

So where is the leverage? Three places, in my experience.

Deciding what should not use a model at all. A surprising amount of what gets pitched as AI is a lookup, a rule or a well-indexed search. The architect who says "this part is deterministic, keep it that way" saves the client money and saves the delivery team an evaluation problem they did not need.

Designing so the provider can be swapped without a rewrite. This sounds obvious and is rarely done properly, because it costs time in week two that nobody wants to spend.

Owning the non-functional layer that regulated clients actually buy. Data residency, auditability, guardrails, fallback behaviour, and the evaluation harness itself. In banking and insurance, this is not the appendix to the proposal. It is the proposal. The feature is the easy part.

The commercial half of the role matters more than it used to. Inference cost, latency and evaluation effort are per-transaction. They do not sit in a capex line that gets amortised; they land directly in the delivery margin, every month, for the life of the contract. Architectural choices made in week two set the P&L for the engagement, and the person making them needs to know the price of the thing they are designing.

The two roles are converging, and the convergence has a risk

In practice, what I see emerging is a single solution owner who can scope, prototype and price in the same week. One person, or a very tight pair, who talks to the client, drafts the brief, builds enough to know it works, and puts a number on it.

That is a real gain. The handoffs between sales, analysis and architecture were where most scope errors were introduced, and removing two of them removes a lot of drift.

But here is the part I want to be candid about. When a sendable proposal can be produced from one intro call, the rigour that the slow scoping process used to enforce by default now has to be imposed deliberately. Three weeks and two workshops were inefficient, but they had a side effect: someone had time to notice the data was not there, or the sponsor's requirement did not survive contact with the operations team.

If that rigour is not rebuilt on purpose, sold scope and buildable scope drift apart quietly. It does not show up in sales, where the deal looks clean. It surfaces as a margin problem three months later, in delivery, when the evaluation criteria were never defined and the client's idea of "working" turns out to be different from the one in the statement of work.

What we do about it

I will keep this short, because it is less interesting than the diagnosis and most of it is unglamorous.

The evaluation specification is part of the proposal, not a delivery deliverable. Error rate, edge cases, escalation path, and who signs off on "good enough". If we cannot write it before we sell, we are not ready to sell.

Data readiness is checked before the number goes on the page. Not a full audit, but enough to know whether the thing the client described exists in their systems in a usable form.

The cost model is built in the same week as the architecture. Per-transaction, with a range, and with the assumption written next to it.

None of this is new thinking. It is the old scoping discipline, done in days instead of weeks, by fewer people, on purpose rather than by accident. The tools made the document free. They did not make the judgement free, and the organisations that confuse the two will find out in the delivery numbers, not in the pipeline.

Which of the two roles do you think is further along in making the shift?