AI solutions architect: designing what others must build
An AI solutions architect draws the target system: how the components fit, what the constraints are, what should be built and in what order. The surprising part, to people entering the role, is how little of that is about models. Which model to call is usually the most reversible decision on the page, and it will be revisited twice before the system is a year old. What is hard to reverse is everything underneath: where data lives and whether it may cross a border, how a user's identity and permissions flow into a system that acts on their behalf, what is logged and retained, and what the ceiling on cost per request is. Those four decisions determine what can be built for the next several years, and an architecture that gets them right while choosing an unfashionable model will outlive one that does the reverse.
AI solutions architect, in short
Established role| In one sentence | Designs the target system: how the pieces fit, what the constraints are, what should be built and in what order. |
|---|---|
| Judged on | Whether the design survives the security review and the customer reality it was drawn against. |
| Fails when | The design is correct and unaffordable, because its cost was never priced by anyone who had to build it. |
| Most confused with | Forward deployed engineer, the pair most often used interchangeably in postings. |
Hired as a distinct position across many companies, with a recognisable scope. No compensation figures: see methodology.
The decisions that actually bind
Data residency and movement. Whether a document may be sent to a model running outside the organisation, outside the country, or outside a specific legal jurisdiction. This single constraint eliminates most of the design space in regulated industries and in several markets, and it cannot be engineered around afterwards.
Identity and permission flow. When a system retrieves on a user's behalf, it must see exactly what that user may see and nothing else. Systems that index everything and filter at the end leak, and the leak is discovered by a user reading something they should not. Getting this right at design time is cheap; retrofitting it is close to a rebuild.
Observability and retention. What gets logged, with what reasoning attached, for how long. This looks like an operational detail and becomes the only way to answer the question that eventually gets asked, which is why the system did that.
Cost per request. The constraint architects most often omit and the one that kills systems quietly. A design that makes four model calls where one would do is not a refinement at volume, it is whether the thing has a margin.
The characteristic failure: correct and unaffordable
Architecture in large organisations exists for a good reason. Without it, every project invents its own integration pattern, its own identity model and its own approach to retention, and the result is unmaintainable within three years.
That purpose pushes the role toward distance and toward conservatism, both appropriate. It also produces the failure mode: a design that is sound, defensible at a review board, and whose cost was never priced by anyone who had to build it. All integrations through the enterprise service bus is a correct standard. It is also an eleven-week queue, and the design that mandates it has silently added a quarter to every project.
The correction is not to lower standards. It is to price them. An architecture that states what its constraints cost in weeks, and offers a documented fast path for cases that cannot afford them, gets followed. One that states only the rule gets routed around, which is worse than having no standard because now the exceptions are invisible.
What makes an architect good in this field specifically
Knowing what models cannot be made to do. The most damaging specifications are the ones that assume determinism: a design that requires the same input to produce the same output, or that treats a model's confidence as a probability, has made an error that no downstream engineering repairs.
Designing for reversibility. The model layer will change. An architecture that isolates it behind an interface, keeps the evaluation set independent of the provider, and avoids embedding provider-specific behaviour into business logic costs slightly more now and saves a migration later. This is ordinary engineering judgement applied to an unusually fast-moving dependency.
And deciding what does not need a model at all. A meaningful share of requests that reach an architect are better served by a query, a rule or a report. An architect who says so is doing the most valuable thing available to the role and the least visible.
Getting out of the diagram
The single change that improves architects most is being made responsible for one integration end to end. Not supervising it: building it, against a real system, with the real access queue.
The effect is immediate and slightly embarrassing, because it exposes which parts of the standard were written without knowing what they cost. Architects who have done this produce designs with fewer mandates and more documented exceptions, which are followed more often.
The related move is to spend time with the deployment engineers executing the designs, in the customer's building rather than in a review. Most of what invalidates an architecture is not in any document: it is the service that returns four identifier formats depending on which decade the record was created in.
