AI Architect

Role: AI Architect

Reports to: Chief AI Officer (line management)

Location in structure: AI/Data architecture area — embedded within the delivery area it serves, line-managing centrally to the Chief AI Officer

Experience: Senior — 6+ years in software, data, or platform engineering/architecture, with meaningful hands-on time on production AI systems, not just pilots

Direct reports: None. Influence comes from judgement and presence in the right conversations, not headcount.

Why this role exists

AI decisions at Citation now cut across Product, Engineering, Security, Infrastructure, and the Business simultaneously — model selection, data architecture, cost, and risk are no longer separable concerns. Without a dedicated architectural owner, each initiative makes these calls independently: patterns diverge, risk goes unspotted until it's expensive, and nobody owns the AI-specific decisions that don't belong wholly to any one function.

This isn't a hypothetical gap. Much of this work is already happening informally inside Citation's AI delivery — reviewing partner Statements of Work, governing what goes through Code Factory, acting as the practical architectural voice on live builds. This role formalises that into a mandate with the standing and scope it needs.

How this role sits in the architecture function

The AI Architect is Citation's dedicated architect for the AI/Data area, sitting alongside the architects covering Human Resources, Business Systems, Health & Safety, eLearning, Verification, Certification, and Atlas Platform: embedded in the delivery area it serves day to day, but line-managing centrally to the Chief AI Officer so its calls hold across the business, not just the team it happens to sit nearest to.

The architecture hub owns target-state and standards across the whole architecture function; this role owns the AI-specific application of it, escalating decisions with consequences beyond AI/Data to the Architecture Review Board rather than deciding them alone.

What good looks like

The clearest sign this role is working: AI initiatives at Citation start well and stay on track architecturally. In practice that means:

• Established patterns are the default starting point for new builds, not something teams discover after the fact
• Design questions are resolved before Engineering starts building, not during or after
• Third-party Statements of Work are assessed architecturally before they're signed
• Model and hosting choices are made against a documented decision framework, not habit or vendor pressure
• Token spend and cost-per-outcome are tracked and explainable, not a surprise on the invoice
• Security is involved in every significant initiative from the start, not introduced at the end
• Leadership has a current, accurate view of AI architectural risk and direction, with no significant surprises

Responsibilities

Architectural standards and patterns

Own the design patterns Citation builds its AI systems to: retrieval and grounding approaches for systems that need Citation's own knowledge rather than a model's general training, agent orchestration patterns and tool-calling conventions for multi-step and multi-agent work, prompt construction and guardrail design, and the routing logic that decides which model handles which step. Keep these current as the landscape moves, and write decisions down in a form Engineering and Product can actually build against — architecture decision records, not a slide deck. Align standards to Citation's five-layer AI platform architecture.

Model selection: open-weight vs. closed, and why

Hold a documented, evidence-based framework for choosing between closed frontier models accessed through a provider's API (Anthropic, OpenAI, Google) and open-weight models run on Citation's own infrastructure (Llama, Mistral, Qwen and similar) — and apply it per workload, not as a single blanket choice. The framework should weigh:

• Task complexity — complex reasoning and long‑horizon agentic work generally favour frontier closed models; simpler classification, extraction, and templated generation are often better served by smaller open-weight models at a fraction of the cost
• Volume and cost at scale — at high token volumes, self‑hosting open-weight models can cross into materially cheaper territory; this role owns the analysis of where that break‑even sits for Citation's actual workloads, not a generic industry number
• Data sensitivity and residency — for HR, employment, and compliance data, self‑hosting open-weight models remove a class of third‑party data‑sharing risk that closed providers (even with strong contractual terms) don't fully eliminate
• Fine‑tuning and customisation — where an open-weight model fine‑tuned on Citation's own data would outperform a general‑purpose model at lower running cost, that's a build case this role should be able to make with evidence, not intuition
• Latency, licensing, and total cost of ownership — including the practical overhead of running and maintaining your own models, not just the sticker price of tokens

Tokenomics — cost as an architectural input, not an afterthought

Understand and actively manage the unit economics of every AI solution recommended, including:

• Modelling likely token cost at design time, before a system is built, so the business knows what it's signing up for
• Specifying model routing (cheaper models for simpler steps, frontier models reserved for what actually needs them), prompt and context engineering for efficiency, and caching where appropriate
• Recognising that agentic and multi‑agent patterns can multiply token consumption several‑fold over a single well‑scoped call, and that orchestration‑pattern choice is itself a cost decision
• Setting up the observability to track cost‑per‑outcome and cache performance over time, not just the total spend line

Data architecture and readiness

Assess whether the data behind any AI initiative is structured, accessible, and reliable enough to support the intended behaviour — across Citation's Salesforce, Atlas, Snowflake, and integration layers — and flag readiness issues before they become delivery blockers.

Design authority and governance

Hold the approval path for new AI architectural patterns and material departures from existing standards. Attend initiative design conversations early enough to shape them, not just review them, and sign off on the AI design elements of partner Statements of Work.

Proof of concept and technical validation

Define scope and success criteria for AI spikes and proofs of concept before they start, validate vendor and partner capability claims before they're embedded in a committed design, and make sure proof‑of‑concept outputs are evaluated against real delivery constraints — not vendor demo conditions.

Third‑party delivery oversight

Act as the internal architectural counterpart to Citation's delivery partners, the way any enterprise architecture function holds its critical vendors to a defined standard: review proposals and Statements of Work before commitments are made, run design reviews during delivery, and give partners a well‑defined target with technical challenge where their decisions need scrutiny.

Production quality, observability, and cost

Set the standard for how AI systems are monitored and evaluated once live — offline and online evaluation, drift detection, guardrails — and own the response framework for AI incidents in production, alongside the cost governance described above.

Security and compliance

Bring Security in as