← All chapters
CAPSTONE TRACK · vExpertAI Academy

AI Architect

The engineering chapters teach you to build AI systems. This track teaches you to design, scale, secure, cost-optimise and govern them — and to lead the teams that run them.

Engineer vs. architect

An AI engineer ships a working system. An AI architect owns its shape — and can defend every trade-off in it to a security reviewer, a CFO, and an executive in the same afternoon. The difference isn't more of the same skills; it's four disciplines that sit around the build: systems design at scale, security and governance, cost and leadership, and the mathematical foundations that let you judge a system rather than just wire it together.

This track assumes you've done the engineering chapters (or can). It's the capstone.

The path — 18 stages

Stages 1–13 are the shared foundation with the AI engineer path; 14–18 are what make you an architect. Work them top to bottom, but treat evaluation, security and cost as cross-cutting — you revisit them continuously, not once at the end.

Shared foundation (build it)

  • 1–4 · Fundamentals: programming & engineering craft, data & SQL, math for ML (linear algebra + statistics), classical machine learning.
  • 5–6 · Models: deep learning, then LLM internals — attention, tokenization, context, and failure modes, from the inside.
  • 7–9 · Applications: prompting & LLM frameworks, retrieval-augmented generation, agents & MCP.
  • 10–13 · Production: rapid prototyping, model serving & inference optimisation, training & fine-tuning at scale, MLOps & cloud deployment.

The architect layer (own it)

  • 14 · Evaluation & observability — evals, guardrails, tracing and drift. What separates architecture from a demo.
  • 15 · Systems architecture at scale — consensus, consistency, failure modes, SLOs, multi-tenancy, chaos engineering.
  • 16 · Security & governance — threat-modelling against the OWASP LLM Top 10, red/blue posture, and mapping controls to the NIST AI RMF, the EU AI Act, and ISO 42001.
  • 17 · Data platform & governance — lineage, quality, access control, and the data substrate the whole AI estate depends on.
  • 18 · Architecture leadership, FinOps & strategy — GPU/token economics, decision docs and ADRs, and tying the AI roadmap to business value.

The four disciplines that make the difference

If you only internalise four things beyond the engineering, make it these:

  • Systems design at scale. The engineer builds one app; the architect designs for latency SLOs, multi-tenancy, correlated failure, and horizontal scale across many. The theory under Kafka and Kubernetes — consensus, CAP/PACELC, partial failure — reasoned about before the incident, not during it.
  • Security & governance. Treating the model, its prompts, its training data and its tool-use as an attack surface and a regulated artifact. Being able to prove a system is safe, private and lawful — to a regulator or a red team — not merely assert it.
  • Economics & leadership. Reasoning quantitatively about the self-host-vs-API crossover and the total cost of a GPU cluster; turning a design into diagrams-as-code, ADRs and stakeholder decision docs that survive finance, security and executive scrutiny. An architecture that can't be explained can't be funded.
  • Foundations. Enough linear algebra to know what an embedding computes, enough statistics to tell a real benchmark improvement from noise, and enough storage/database theory to spot the bottleneck that isn't the model at all.

How you'll know it worked

The test isn't a certificate. It's whether you can take a messy business problem and produce a defensible design: a system that's affordable (you did the cost model), secure (you threat-modelled it), operable (you defined the SLOs and the evals), and buildable by a real team (you wrote the ADRs). When you can hand that to a room and answer every "why" — you're an architect.

This track is the classroom companion to the AutoNOC work: sovereign, on-prem AI for network operations is exactly the kind of system that demands architect-level thinking — because it has to be affordable, air-gapped, governed, and operable all at once.

Where to go next

If your team is ready to stop reading and start building agents that run on your own network, the fastest way in is a private team workshop — one day, working agents, on your infrastructure. Or book a 15-minute fit call and tell us your environment.