How to get hired as an AI solutions architect in 2026-27

What an AI solutions architect actually does, and which of the four jobs the posting means

The job is not drawing. Diagrams are the artefact, decisions are the product. An AI solutions architect is the person who writes down, in a form a security reviewer and a finance partner can both argue with, how a specific AI workload will run inside a specific organisation: which data it touches, under whose permissions, through which model, at what measured quality, at what cost per thousand requests, degrading how, owned afterwards by whom. Everything that makes AI projects die in month seven lives in that sentence, and almost none of it is model selection.

In practice the role exists because two groups keep talking past each other. Engineers can build a convincing prototype in days, and with a coding assistant often in one. Enterprises still cannot deploy it, because the prototype reads a folder of documents with no regard for who is allowed to see them, has no measurement beyond a product manager's impression, has an unmodelled cost that scales with context length, calls a model version that will be retired, and nobody has agreed who gets paged at 2am. The architect's value is closing that gap before the money is spent, and the ability to say no to a design is a bigger part of the job than the ability to propose one.

It is worth being precise about the neighbours, because interviewers test the boundary. An AI engineer builds and owns the running system. A machine learning engineer trains, tunes and serves models. An MLOps or platform engineer owns the pipelines and the infrastructure. A data architect owns the model of the data itself. An enterprise architect owns the portfolio and the standards across many systems. An AI solutions architect sits across a workload end to end, usually several workloads at once, and is accountable for the parts nobody else wants: the permission model in the retrieval path, the evaluation set, the cost envelope, the exit plan, and the hand-off.

Before you tailor anything, work out which of the four employers the posting comes from. It changes the interview, the resume, the metric you will be judged on, and whether you will write code. The signals are in the text: consumption, workloads, customers and partners mean vendor field. Engagement, client, statement of work, utilisation and practice mean consultancy. Standards, governance, reference architecture, centre of excellence and stakeholders mean in-house. Deployment, onboarding, implementation and a named product mean software vendor.

• Vendor field role (cloud providers, model providers, data platforms, GPU vendors). Pre-sales and early post-sales. You run discovery workshops, design the customer's first production workload, unblock proofs of concept, write the reference architecture the account team reuses, and push product feedback back inside. Measured on workloads landed and consumption influenced, usually with a variable component in the package. Deeply customer-facing, moderately hands-on, and political in a way people from in-house roles underestimate.
• Consultancy or systems integrator. Billable delivery architecture. You scope, estimate and phase the work, own the technical shape of a programme, carry the design through a build team, and defend it in the client's architecture review board. Measured on utilisation, on estimate accuracy, and on whether the engagement extends. Writing a credible phased plan with a cost and a staffing shape is as important as the architecture itself.
• Enterprise in-house, architecture or AI platform group. You set the patterns other teams build against: the model gateway, the approved retrieval pattern, the evaluation standard, the data classification rules, the build-versus-buy calls, the vendor selection. Measured on adoption of your patterns and on workloads that reach production without a security exception. Less travel, more committee, and the political work is the work.
• Software vendor implementation or forward-deployed team. One product, many customers, deep integration. You adapt a product to a customer's data and processes, and you are the escalation path when it does not fit. Measured on time to value and on retention. More hands-on code than the other three, and the pattern library you accumulate becomes your leverage.
• Two adjacent titles that are not this job, though a posting may blur them. Forward Deployed Engineer is usually a build role with a customer attached, scored on shipping code. AI Product Manager owns the problem and the roadmap, not the system shape. If a posting asks for both the architecture and a quota, read the on-target earnings split carefully, because that is a sales job with an architect's title.
• The deliverables that recur in every variant: a reference architecture document, an architecture decision record set, a cost model, an evaluation plan, a risk register entry, a security and data-handling review submission, a phased rollout plan, and a hand-off runbook. If you have never produced one of those, produce it on your own time before you interview, because every round asks you to show one.
• What the job is not: a prompt engineering job, a research job, or a slide job. A candidate who cannot open a terminal gets found out in the deep dive round, and a candidate who only wants to code gets found out in the customer round.

Coming from cloud or enterprise architecture: what transfers, and the gaps that decide the loop

Most of this role transfers directly from cloud architecture, and the people who assume they are starting over waste months. Identity and authorization, network topology and private connectivity, data residency and sovereignty, tenancy models, storage tiering, queueing and backpressure, observability, disaster recovery with a stated recovery point and recovery time, cost allocation and showback, change management, the discipline of writing a decision down with its rejected alternatives: all of it is the same, and all of it is scarce among people who arrived from the model side. Say so plainly in the interview rather than apologising for not having trained a model.

Four gaps decide the loop, and they are the things a cloud architect has genuinely never had to do. The first is evaluation. Every system you designed before was deterministic enough that acceptance testing meant pass or fail. Here the same input can produce a different output, quality is a distribution, and the only honest answer to does it work is a labelled set of cases, a scoring method, a baseline number and a threshold agreed with whoever signs off. An architect who has no answer to how will we know it is good enough is rejected in the whiteboard round, by every employer type.

The second gap is unit economics and capacity. You are used to instances, cores and gigabytes. The currency here is tokens, and the dominant cost driver in most retrieval systems is not the clever part, it is the length of the context assembled on every single call. You need to be able to do the arithmetic out loud: tokens in plus tokens out, times calls per day, times the contracted rate per million, before adding the index, the embedding passes, the re-ranking and the human review time. If the workload is self-hosted you need the memory arithmetic too: parameters times bytes per parameter at your chosen precision, plus the key-value cache, which grows with sequence length and concurrency and is what actually decides how many requests fit on a GPU.

The third gap is the authority model. The moment the system calls tools rather than just writing text, the design question stops being what does the model say and becomes what is this thing allowed to do, with whose credentials, and what cannot be undone. That is an authorization problem, which is good news for a cloud architect, but it has a twist: the model takes instructions from text the organisation does not control, so you cannot rely on it refusing. Authority has to sit outside the model, in scoped credentials, server-side limits, idempotency, and human confirmation on irreversible actions.

The fourth gap produces the worst incidents: retrieval is an access-control problem before it is a relevance problem. An index built by crawling a document store flattens permissions by default, and the first demo where an assistant cheerfully summarises a document the asker was never entitled to read ends the programme. Permission-aware retrieval, meaning filters applied at query time from the caller's identity rather than scrubbed afterwards, is something interviewers specifically listen for.

Timelines, honestly. From a working cloud solutions architect job, 8 to 16 weeks of deliberate effort on those four things, done as one real artefact rather than as reading, is enough to interview well. From enterprise architecture with no recent hands-on work, 4 to 8 months, because the deep dive round will find out and because you need something you built and measured yourself. From data engineering or machine learning, the technology is not the problem: book yourself into stakeholder-facing situations and get used to being interrupted by someone who does not care how it works.

• Gap one closed looks like: an evaluation set of 100 to 300 labelled cases for one real task, a scoring method you can defend (exact match where the answer is checkable, a rubric scored by a model with human spot checks and a measured agreement rate where it is not, task completion for anything agentic, citation correctness for anything grounded), a baseline number, a threshold, and a note on which hard cases you deliberately left in because they are the ones that hurt.
• Gap two closed looks like: a one-page cost model with its assumptions written on it, cost per thousand requests, the sensitivity to context length, and the cheaper variant you would move to if volume tripled. Include the human cost. A review step at two minutes a case is often the largest line in the whole model and candidates almost never mention it.
• Gap three closed looks like: a tool authority table. For each tool, which credential it runs under, whether the action is reversible, what the server-side cap is, whether confirmation is required, and what is logged. This single table answers four interview questions at once.
• Gap four closed looks like: being able to say how permissions get into the index and out of the query, what happens when a document's access list changes after indexing, and how you prove tenancy isolation in a test rather than asserting it.
• What transfers and should be said out loud: identity federation, private connectivity and egress control, data residency, tenancy, disaster recovery with numbers, cost allocation, and the ability to write a decision record. Vendors and consultancies hire architects partly because AI-native candidates cannot do these and the projects stall on them.
• The cheapest way to generate all four artefacts at once: pick a workload you know from your current employer, real constraints, no confidential detail, and write it up as if you were handing it to a build team. One document, 6 to 12 pages, with numbers. It becomes your portfolio, your whiteboard rehearsal and your resume evidence simultaneously.
• Do not try to close the gaps by collecting certifications. The deep dive round asks what you measured, and a badge has no answer.

How hiring works, stage by stage, and how it differs by employer

There is no licence, no board exam and no portfolio review panel. What gates this role is a loop of four to seven conversations, one of which is a live design exercise, and a strong preference for people the hiring team has already watched work. Internal movement and referral through a partner relationship fill a large share of these seats, which means the highest-return action for most people is not applying harder, it is getting visible to the AI programme at the employer or partner they already touch.

The shape below is the vendor loop, which is the most structured and the most commonly asked about. Consultancies compress it and add scoping. Enterprises stretch it and add a written exercise and a committee. Software vendors add a hands-on element because you will be in the code.

Timelines vary, but the usual shapes are: vendor loops 3 to 8 weeks from first screen to offer, longer when a cross-organisation reviewer has to be scheduled; consultancies fastest at 2 to 4 weeks, because a billable seat is open now; enterprises 4 to 10 weeks, often going quiet in the middle, which is usually budget approval rather than rejection.

One structural note worth knowing before you negotiate: in vendor field organisations the architect is often paired with an account executive and sits inside a sales organisation's planning cycle. That affects the questions you get asked (how do you handle a customer who wants something our product does not do), the metric on your scorecard, and the fact that part of your pay moves with someone else's number. None of that is a reason to avoid the job, but walking in without knowing it reads as naive.

• Recruiter screen, 20 to 30 minutes. Keyword and logistics matching: cloud platforms, industry, travel tolerance, location, compensation, work authorisation. Ask three things here and the rest of your preparation gets cheaper: which of the four employer variants this is, whether the loop includes a presentation or whiteboard round and whether it is prepared in advance or live, and what the scorecard metric is.
• Hiring manager, 45 to 60 minutes. The real filter. Expect: walk me through an architecture you owned end to end, including what it cost and what you got wrong; a time you told a customer or an executive no; how you decide build versus buy; what you think is overhyped right now. That last one is a genuine signal check, and the answer that works is specific and not cynical.
• Reference architecture or whiteboard round, 45 to 75 minutes. Live, scenario-based, scored against a rubric. This round decides more offers than the rest of the loop combined and is covered in detail in the next section.
• Prepared presentation, 30 to 60 minutes, common at vendors and consultancies. You are given a scenario or asked to bring your own, and you present to a panel playing a customer. Scored on structure, on whether you asked anything, on handling interruption, and on time discipline. Build it to 12 slides and rehearse to 20 minutes, because they will eat half your slot with questions and that is the test.
• Technical deep dive, 45 to 60 minutes. Cloud and data fundamentals plus AI mechanics. Candidates from the AI side lose here on identity, networking and data; candidates from the architecture side lose on tokens, retrieval behaviour and evaluation.
• Objection handling or customer simulation, 30 to 45 minutes, vendor and consultancy. Someone plays a sceptical head of risk, a burned CIO or a procurement lead. You are watched for whether you answer the objection actually raised, whether you concede anything, and whether you can say I do not know, I will find out and come back on Thursday without flinching.
• Written exercise, common in-house and at some software vendors. A two to five page design or decision document, usually with a 48 hour to one week window. Write it like a real internal document: context, constraints, options considered, recommendation, risks, cost, what you would measure. Reviewers read for structure and honesty about trade-offs, not for length.
• Behavioural or values round, 45 to 60 minutes. At Amazon this is explicit Leadership Principles with a dedicated bar-raising interviewer and demands specific first-person stories with data. Elsewhere it is softer but still real. Prepare six stories with numbers in them: a design you killed, a disagreement you lost, a disagreement you won, a failure you owned, a thing you learned fast under pressure, a customer you turned around.
• Cross-functional panel. A sales counterpart at a vendor, a delivery lead at a consultancy, a security or risk partner in-house. They are checking whether you are easy to work with under deadline pressure and whether you will create a problem for them later.
• References and background. Normal, but note that vendor field roles sometimes check customer-facing reputation informally through the partner ecosystem before an offer. That cuts both ways, and it is why doing a visibly good job on a partner engagement is high-leverage in this field.

The reference architecture whiteboard round, worked end to end

Here is a scenario of the kind actually used. A mid-size property insurer wants its claims adjusters to receive, for each new claim, a drafted summary of the claim file and a coverage assessment that cites the specific policy clause it relies on. The inputs are policy documents as PDFs, adjuster notes and claim history inside a claims system of record, loss photographs, and a policy master on a mainframe that nobody is allowed to change. Peak volume is 12,000 claims a day across roughly 1,800 adjusters. The data cannot leave the country. The regulator expects decisions to be explainable and the business expects this to cut 20 minutes off each claim. You have 50 minutes and a whiteboard.

Spend the first eight to ten minutes asking, and say that is what you are doing so it does not look like stalling. The questions below are not padding: each one changes the drawing. Then draw in a fixed order, and say the order out loud, because a repeatable process is most of what is being scored. Data sources first, then permissions, then ingestion and indexing, then retrieval, then prompt assembly, then the model call, then output handling and citation, then the human step, then logging and evaluation, then the feedback loop. The model box goes on the board fifth or sixth, not first. Interviewers notice.

Mark the trust boundary explicitly. In this system the adjuster notes and the claim correspondence contain text written by claimants and third parties, which means an attacker can contribute to the prompt. Say that out loud, say that you therefore will not let the model hold any authority to act on the claims system, and that drafting is advisory with a human commit step. If a later phase automates anything, say which actions could ever be automated (set a status flag, request a document) and which never could without a second control (issue a payment, deny a claim).

Then do the numbers. Out loud, with assumptions stated as assumptions. Suppose the assembled context runs around 8,000 tokens per draft, because the policy excerpts dominate, and the output is around 700 tokens. At 12,000 drafts a day that is roughly 96 million input tokens and 8.4 million output tokens a day, so multiply each by your contracted rate per million and add them. Now say the three things that follow: input dominates, so the single biggest cost lever is retrieving three clauses instead of thirty and caching the stable part of the prompt; the per-request cost is small but the daily number is a real budget line finance will ask about; and the human review minute is probably the most expensive item in the system, so the business case rests on the time saved per claim rather than on the token price. Do not invent a vendor price in the room. Say you would price it against the contracted rate and show the formula.

Non-functionals, in roughly the order they decide the round. Residency: a region-pinned model endpoint and a region-pinned index, with a written answer on where inference logs go, how long they are kept, and what the provider is contractually allowed to do with the content. Permissions: adjusters see claims in their book of business, so retrieval filters by identity at query time, and the index carries the access metadata rather than relying on a post-filter. Latency: adjusters work a queue, so a 9 second draft is annoying but survivable while a 90 second one is abandoned; state a target such as p95 under 10 seconds, and say you would stream the draft so perceived latency is the first token, not the last. Availability and degradation: if the model endpoint is unavailable the queue must not stop, so the fallback is no draft rather than a blocked workflow, and that needs to be designed, not discovered. Auditability: store the retrieved clause identifiers, the prompt version, the model version and the adjuster's edit, because the explainability requirement is satisfied by the citation trail and the human decision, not by any claim about model interpretability.

Evaluation is where most candidates stop talking, and it is the part the hiring manager cares about most. Say it concretely. Take a few hundred closed claims with known outcomes, have two experienced adjusters label the correct coverage position and the clauses that support it, and score three things separately: is the cited clause the right clause, is the summary free of statements the file does not support, and does the recommended position match the adjuster's. Report them as three numbers, not one. Set the go-live threshold with the business before the build, keep a holdout, and name the online metrics you would watch afterwards: edit distance between the draft and the submitted summary, override rate, time per claim, and complaint volume. Then say who owns the eval set, because an eval set with no owner is dead within two quarters.

Close in the last three minutes with three sentences that separate experienced architects from everyone else. One residual risk you are accepting, with its compensating control (the model will occasionally cite a clause that is real but not the governing one, so the citation renders as a link to the clause text inline and the adjuster must open it to commit). One thing you would not build (no automated claim decisions in phase one, no fine-tuned model until retrieval quality is measured, no custom vector store if the existing data platform already provides one). And the operating answer: who runs this, who gets paged, what the rollback is, and what happens when the model version you built against is retired.

• The ten questions to ask before drawing: who is the user and what decision does the output support; what is the volume, average and peak; what latency will the user tolerate; what are the systems of record and can we read them cleanly or only through a nightly extract; who is allowed to see what, and does the source system model that; what does good look like and who signs off on it; what does being wrong cost, and is it recoverable; is there a human in the loop in phase one and does that change in phase two; what is the budget shape and the date; who operates this after I leave.
• The drawing order, stated out loud: sources, permission metadata, ingestion and chunking, index, retrieval with filters, re-rank, prompt assembly with its version, model call, output parsing and citation, human step, logging, evaluation harness, feedback loop. Label every arrow with what crosses it. Put the trust boundary on the board as a line, not as a comment.
• The five numbers you must produce unprompted: requests per day and at peak; tokens in and out per request; cost per thousand requests with the assumptions visible; a p95 latency target; and the quality threshold at which this is allowed to go live.
• What a good interviewer is scoring, on a rubric: did the candidate clarify before designing; did they design the data path or just the model; did they handle permissions and residency without being prompted; did they produce numbers with units; did they propose a measurement; did they name a residual risk; did they scope a phase one; did they say what they would not build; did they answer who operates it; could a build team start from this drawing on Monday.
• The three ways candidates fail this round. One, boxes with no numbers: a beautiful diagram with no volume, latency, cost or quality figure reads as a slide, not an architecture. Two, the greenfield answer: designing the system you wish the customer had, ignoring the mainframe, the nightly batch, the system of record that cannot be written to, and the long-standing data quality problem that is the actual project. Three, hand-waving quality: the words a human will check it, with no measurement, no threshold and no owner.
• Two smaller failures that still cost offers: taking the whole slot and never getting to operations, and refusing to commit to a recommendation. You are allowed to be wrong in this round. You are not allowed to be vague. State a choice, then state the condition under which you would reverse it.
• If the interviewer pushes an obviously bad idea, treat it as the test it is. Steelman it in one sentence, name the specific condition under which it fails, offer the cheaper experiment that would settle it. Agreeing to be agreeable is scored as a fail in the same way as being combative.
• Practise this out loud, on a timer, against five scenarios in different industries: a regulated financial workflow, a clinical or life sciences document task, a contact centre assist, an internal knowledge assistant over a messy intranet, and an agentic back-office process that touches a system of record. Three rehearsals each. The process is what is being hired, and it has to be fluent.

The other rounds: deep dive, cost and sizing, and the customer in the room

The deep dive is a breadth test with two spikes, and which spike you fail is predictable from your background. People from the architecture side lose on AI mechanics, usually on retrieval behaviour, context cost and evaluation. People from the model side lose on identity, private networking, tenancy and operations. Prepare the half you did not come from, and prepare it to the level of explaining a trade-off rather than reciting a definition.

The questions that recur are mechanism questions, not trivia. Why does chunk size change answer quality, and in which direction for a long legal clause. What does a re-ranker buy you and what does it cost in latency. Now that long context windows are cheap enough to abuse, when does stuffing the whole document set in beat retrieval, and when does it just pay for the same tokens on every call. When is fine-tuning the right answer rather than retrieval, and what does it not fix. What changes when you move from a hosted endpoint to self-hosted weights, in money, in operations and in risk. What breaks when you upgrade the model under a prompt that was tuned to the old one. How do you keep a multi-vendor posture without reducing everything to the lowest common denominator. Each of those has a real answer with a trade-off in it, and a candidate with production scars gives it in thirty seconds.

The customer simulation is a separate skill and people with strong technical rounds fail it. The failure is almost always the same: answering the objection you prepared instead of the one that was raised, and defending instead of conceding. The move that works is to restate the objection in the stakeholder's own terms, concede the part that is true, narrow the claim to what you can actually support, and attach a next step with a date and an owner. If you do not know, say you do not know and name when you will come back. Senior people in the room have heard confident nonsense before and they are listening for whether you do it.

The behavioural round is scored on specificity. The architect stories that land are about decisions with consequences: a design you killed after a measurement contradicted you, an estimate you got wrong and what you changed in how you estimate, a time you were overruled and what happened, a customer who had already failed once with a different vendor and what you did differently. Numbers in the story are what separate a real anecdote from a rehearsed one.

• Cloud and data ground the deep dive assumes: identity federation and token exchange, least privilege and credential scoping, private connectivity and egress control, data residency, multi-tenancy isolation patterns, object storage and index lifecycle, streaming versus batch ingestion, container orchestration and GPU scheduling if self-hosted, observability with traces across service boundaries, disaster recovery with a stated recovery point and recovery time, and cost allocation and showback.
• AI mechanics the deep dive assumes: tokenisation and why the context window is a budget; embeddings, chunking strategies and why metadata beats cleverness; hybrid retrieval with keyword and vector, and re-ranking; context caching and what invalidates it; structured output and schema enforcement; tool calling and the agent loop; the Model Context Protocol and what a connector exposes; prompt and model versioning; evaluation harnesses, labelled sets, rubric scoring with a human agreement check, and holdouts; fine-tuning, parameter-efficient tuning and distillation and what each is actually for; quantisation and the quality trade-off; key-value cache, batching and what sets throughput on a GPU; provisioned capacity versus on-demand.
• Data handling and procurement questions you will be asked by someone who is not technical: does the provider train on our data and where is that written down, what is the log retention and can it be set to zero, which region does inference run in, who at the provider can see a prompt, what happens to the data if we leave, and is there a subprocessor list. Architects who cannot answer these stall deals, and in-house architects who cannot answer them stall their own programme.
• The sizing question, asked at vendors and GPU-heavy shops: given a model of N parameters, what hardware do you need to serve it. The expected shape is weights (parameters times bytes per parameter at your chosen precision), plus the key-value cache which scales with context length and concurrency, plus headroom, and then the conclusion that concurrency and context length, not the parameter count alone, decide how many requests fit. Then the real answer: do not self-host unless residency, unit cost at sustained volume, a latency floor or a data policy forces it, and say which of those four is your trigger.
• Build versus buy, asked everywhere. The honest 2026 answer is that a lot of what people hand-built in 2023 and 2024 is now a feature of a platform the customer already pays for, so the architect's job is to check that first and to reserve custom build for the part that is genuinely specific to the business. Name your test out loud: build where the differentiation is, buy where the capability is commodity, and never build an undifferentiated component you will have to staff for five years.
• Objections to rehearse, with a real answer for each: we tried this and it hallucinated; our legal and risk team will never approve it; why not just use what is already in the tools we license; the proof of concept worked in two weeks, why is production six months; what happens when the provider changes the model under us; how do we know this is not just a more expensive way to do what we do now; can you guarantee it will not be wrong.
• The one answer you must never give: a promise that the system will not be wrong. The correct form is that you will measure how often and in which direction it is wrong, bound what a wrong answer can cause, make the wrongness visible to the person who can catch it, and review the numbers on a schedule.
• Questions to ask them, which also function as signals: what does success look like for this role in twelve months; how many of the proofs of concept this team ran last year are in production now, and what stopped the rest; who owns the evaluation standard; what is the split between base and variable pay and what drives the variable; how often does an architecture here get overridden by a vendor relationship.

Certifications: the few that move a decision, and the many that do not

Certifications matter unevenly across the four employers, and getting this wrong wastes months. At cloud vendors and especially inside their partner ecosystem they are structural: partner competency tiers are counted in certified individuals, so consultancies and systems integrators need badges on the bench, often ask for them explicitly, will pay for them, and sometimes make one a condition of passing probation. At software vendors they matter if the vendor has its own credential. In-house they are close to irrelevant beyond getting past an automated screen, where a recruiter is matching the requisition text.

The order of weight is consistent. A professional or expert tier cloud architect credential on the platform the employer uses or sells is the only one that reliably changes a screening decision, because it is the baseline the role is built on. The AI credential from the same vendor is a useful second, mostly as evidence you took that platform's AI services seriously. A data platform credential matters when the shop is built on that platform. Everything else is a tiebreaker at best.

Names, codes and prices in this area change more often than in any other part of cloud certification, and credentials get renamed, split or retired between one hiring cycle and the next. Check the issuer's own page for the current name, exam code, prerequisites and price before you book, and do not put a retired credential on a resume as though it were current. If a credential has an expiry, show the year.

Two pieces of sequencing advice. First, if you are employed somewhere that will pay for a certification and give you study time, take it there rather than paying yourself. Second, if you are choosing between one more certification and one written reference architecture with a cost model and an evaluation plan, write the document. In the rounds that decide the offer the badge has nothing to say, and the document answers four questions.

• Real weight, and usually the first filter: the professional or expert tier cloud architect credential. AWS Certified Solutions Architect Professional, Google Cloud Professional Cloud Architect, Microsoft Certified Azure Solutions Architect Expert. Pick the platform of the employer you are targeting, not the one you find easiest.
• Real but secondary weight: the vendor AI credentials. Google Cloud Professional Machine Learning Engineer, Microsoft Certified Azure AI Engineer Associate (exam AI-102), and the current AWS machine learning credential, whose name and tier have changed recently enough that you should confirm the live exam on the AWS certification site before studying. There are also shorter foundational AI credentials from the major clouds, which are reasonable screen-passers and nothing more.
• Weight inside specific shops: Databricks generative AI and machine learning credentials where the lakehouse is the platform; Snowflake credentials in Snowflake shops; NVIDIA's infrastructure and inference credentials where GPUs are owned rather than rented; a Kubernetes administrator credential if self-hosted serving is in scope.
• Conditional, not general: TOGAF reads as a positive in classic enterprise architecture functions and as noise in vendor field organisations. CISSP helps only if you genuinely cover security review. An ISO/IEC 42001 lead implementer or auditor course is worth it only for governance-heavy roles in regulated sectors, and a governance credential cannot substitute for a technical one.
• Low or no weight: certificates from issuers a hiring manager cannot name, prompt engineering certificates, course-completion lists, and any programme whose selling point is the word architect in the title. More than three certifications on a resume starts to read as a substitute for delivery.
• What substitutes for certification when you have no badge: a public reference architecture writeup, a talk at a meetup or a cloud user group with slides online, a measured evaluation harness in a public repository, a case study you are allowed to describe. Hiring managers trade all of these against a badge happily. Automated screeners do not, which is the only real argument for the badge.
• If you are mid-career and unbadged on the platform you are targeting, the cheapest credible path is the associate tier credential now (a few weeks of evenings) plus one written artefact, then the professional tier once you are inside and someone else is paying.

The resume and the portfolio: what belongs, what gets ignored

An architect resume is read for decisions and numbers. A tool inventory is read as a tool inventory. The bullet that works has four parts: the decision you made, the constraint that forced it, the alternative you rejected and why, and the measured outcome with a unit attached. Three bullets of that shape beat fifteen lines of responsibilities, and most candidates for this role submit fifteen lines of responsibilities.

Tailor to the employer variant, because the readers want different proof. A vendor hiring manager wants evidence of customer-facing work at volume: how many customers you worked across, how many workloads reached production, the workshops you ran, how many proofs of concept converted, the size of the environments. A consultancy wants engagement shape: scope, duration, the team size you carried technically, estimate accuracy, whether the client extended. An in-house panel wants adoption: which pattern you set, how many teams built on it, what it removed, how many security exceptions you avoided. The same project can be written three ways and should be.

Lead the document with a four line summary that names the variant you are applying to, the platforms you are deep in, the industries you know, and one number. Then the evidence. Then a short technologies block a screener can match against the requisition, kept to names actually in use rather than every model released this year. Certifications get one line each with the year.

Two specific things that get ignored and one that actively hurts. Ignored: a list of every model and framework you have touched, and verbs like spearheaded and drove with nothing measured after them. Also ignored: a screenshot of a diagram with no numbers on it, which reviewers skip because it says nothing a hundred other diagrams do not. Actively harmful: claiming production experience you do not have in a field small enough that the deep dive round will find out in four minutes. Say prototype when it was a prototype and name what you learned from it. That reads as senior.

• The bullet shape, with your own measured numbers in place of the placeholders: chose a hosted model endpoint over self-hosted weights for a document workload at N requests per day because residency was satisfiable in region and the volume did not clear the break-even against a GPU reservation; cut p95 latency from X to Y by streaming and by reducing retrieved context from 30 passages to 4 after an evaluation over an N-case labelled set showed no quality loss; cost per thousand drafts fell by Z percent.
• Name the artefacts you produced, because they are the deliverables of the job: reference architecture, architecture decision records, cost model, evaluation plan and labelled set, security and data-handling review submission, phased rollout plan, hand-off runbook. A resume that names these reads as someone who has architected rather than advised.
• Numbers that mean something in this role: requests or documents per day, concurrent users, p95 latency, cost per thousand requests and the direction you moved it, tokens per month, index size in documents and in storage, GPUs reserved, evaluation set size and the score you held the line at, workloads taken to production and how many were still running a year later, teams adopting a pattern, review or override rate for a human-in-the-loop step.
• For the vendor variant, include the commercial surface without pretending to be a salesperson: number of accounts supported, industries, technical win contribution, workshops delivered, proofs of concept run and how many converted, partner enablement sessions. If your variable pay was tied to consumption, describe the workload volume rather than quoting someone else's revenue number.
• Portfolio, in order of return: one written reference architecture for a real workload, public and numbered; a talk with slides online; an evaluation harness in a public repository with a short README explaining the task and the scoring; a short decision record library showing rejected options; a retrospective describing something that broke in production and what it cost. Two of these is a complete portfolio for this role.
• Keep one private version of your best architecture with the confidential detail removed and a one page summary on the front. You will be asked to walk through something you owned in almost every loop, and having the document open while you talk is a visible advantage.
• Length: two pages at any level, three only if you have a long consulting engagement list, and in that case compress the older engagements to one line each.

Where the jobs are, what to search, and a twelve-week plan

These roles concentrate in four pools, and the one most candidates ignore is the largest. First, cloud, model and data platform vendors, hiring field and specialist architects. Second, the partner ecosystem: global systems integrators, regional consultancies and boutique AI delivery shops, which collectively hire more of these people than the vendors do and which fill seats faster because the seat is billable now. Third, enterprises in regulated and data-heavy sectors standing up internal AI platforms: financial services, insurance, healthcare and payers, pharmaceuticals, energy and utilities, telecoms, logistics, and public sector. Fourth, software vendors with an implementation or forward-deployed function.

Search the title variants rather than the single title, and search the vendor spelling. Specialist Solutions Architect with an AI qualifier, GenAI Architect, AI Platform Architect, Enterprise AI Architect, AI Delivery Architect, Principal Architect with AI in the body text. Also search the pattern language rather than the title: postings asking for retrieval augmented generation, a model gateway, an evaluation harness, agentic workflows or responsible AI review are the same job under a different name. Cloud partner directories are a good way to find the regional consultancies you have never heard of, and those are frequently the fastest hires.

If you are already inside a company with a cloud or platform team, the internal route beats the external one by a distance. The AI programme in most large organisations is understaffed on exactly the skill you have and is being asked for architecture decisions it cannot make. Volunteer for the unglamorous part: the evaluation standard, the cost model, the permission model in retrieval. Those three documents make you the obvious internal candidate within a quarter, and they are the portfolio if you later go outside.

Twelve weeks is enough from a working architecture job. The plan below assumes evenings and one weekend day, and it is built so that every week produces an artefact rather than a reading list.

• Weeks 1 to 2. Pick one real workload you understand. Write the context, constraints and the three options you would consider, in two pages. Pick the employer variant you are targeting and rewrite your resume summary for it. Decide which cloud platform you are going deep on and check the current name of its architect and AI credentials on the issuer's page.
• Weeks 3 to 4. Build the thing small. A retrieval path over a document set you have rights to, with permission filtering applied at query time from the caller's identity, running on the platform you chose. Keep it ugly. The point is that you can speak from having done it, and that you know which step is slow.
• Weeks 5 to 6. Evaluation. Create a labelled set of at least 100 cases for one task, define the scoring, run a baseline, and record where it fails. Write down the threshold you would require for production and why. This is the single highest-value fortnight in the plan.
• Weeks 7 to 8. Money and capacity. Build the cost model for your workload with the assumptions visible, including the human review minute. Do the sizing arithmetic for a self-hosted alternative and write the break-even condition. Write the exit plan for the day the model version you are using is retired.
• Weeks 9 to 10. Turn it into the artefact. One reference architecture document, 6 to 12 pages, with the diagram, the numbers, the evaluation plan, the risk register entry, the phased rollout and the hand-off. Publish it or put it where you can share it. Then rehearse the whiteboard round against five scenarios on a timer, out loud, three times each.
• Weeks 11 to 12. Go outbound properly. Apply to the partner ecosystem as well as the vendors. Message the architects already doing the job at three target employers with a specific question about your document rather than a request for a referral. Prepare the six behavioural stories with numbers. Book a certification exam only if it is the screening filter for your target list.
• Ongoing, cheap, and disproportionately effective: present your architecture at a local cloud or AI user group. The room contains hiring managers from exactly the four pools above, and standing in front of a sceptical audience with a cost model is the closest thing to the interview you will get.
• A note on timing within the market: hiring for this title has shifted from exploratory to operational, which means employers increasingly ask what you have taken to production rather than what you have prototyped. That favours candidates with boring evidence, and it is why the evaluation set and the cost model matter more than the demo.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• AI solutions architect
• GenAI architect
• generative AI architect
• AI specialist solutions architect
• AI platform architect
• enterprise AI architect
• AI delivery architect
• applied AI architect
• forward deployed architect
• field CTO
• solutions architect
• cloud solutions architect
• solution architecture
• enterprise architecture
• reference architecture
• architecture decision record
• ADR
• technical pre-sales
• pre-sales architect
• customer-facing architect
• discovery workshop
• proof of concept
• pilot to production
• build versus buy
• vendor selection
• total cost of ownership
• AWS
• Amazon Bedrock
• Amazon SageMaker
• Microsoft Azure
• Azure AI Foundry
• Azure OpenAI Service
• Google Cloud
• Vertex AI
• Databricks
• Snowflake
• NVIDIA
• Kubernetes
• retrieval augmented generation
• RAG
• vector database
• vector search
• hybrid search
• re-ranking
• chunking strategy
• embeddings
• permission-aware retrieval
• document-level access control
• multi-tenancy
• tenancy isolation
• model gateway
• LLM gateway
• prompt engineering
• context engineering
• prompt versioning
• structured output
• function calling
• tool calling
• agentic workflow
• agentic AI
• multi-agent orchestration
• Model Context Protocol
• MCP
• fine-tuning
• parameter-efficient fine-tuning
• LoRA
• distillation
• quantization
• inference optimization
• KV cache
• context caching
• provisioned throughput
• token economics
• GPU sizing
• GPU capacity planning
• vLLM
• latency budget
• p95 latency
• evaluation harness
• LLM evaluation
• offline evaluation
• online evaluation
• golden dataset
• labeled dataset
• LLM-as-a-judge
• human in the loop
• hallucination mitigation
• citation accuracy
• guardrails
• prompt injection
• red teaming
• AI security
• data residency
• data sovereignty
• data classification
• identity federation
• least privilege
• private connectivity
• egress control
• observability
• FinOps
• cost allocation
• disaster recovery
• MLOps
• LLMOps
• model lifecycle management
• model deprecation
• AI governance
• responsible AI
• EU AI Act
• NIST AI Risk Management Framework
• ISO/IEC 42001
• model risk management
• HIPAA
• AWS Certified Solutions Architect Professional
• Google Professional Cloud Architect
• Azure Solutions Architect Expert
• Google Professional Machine Learning Engineer
• Azure AI Engineer Associate
• AI-102
• Databricks Generative AI Engineer
• TOGAF
• stakeholder management
• executive communication
• whiteboard interview
• objection handling
• phased rollout
• runbook
• systems integrator
• financial services
• insurance
• healthcare
• public sector

Mistakes that cost people this job

Questions people ask