AI Solution Architect

Arne Kellmann

Arne Kellmann is an AI solution architect: the person who decides how an AI feature is actually built — what the model is allowed to do, where its context comes from, how the system fails safely, and what it costs to run once real users depend on it.

He works remotely with teams anywhere, in English or German, and brings 15+ years of software development and architecture to the design work.

Summary

Arne Kellmann designs and builds the system around an AI model — retrieval, evaluation, guardrails and cost control — for teams whose prototype already works but is not yet ready for real users, a compliance review or a monthly bill. Engagements are remote and begin with a written architecture assessment that you keep whether or not a build follows. He works worldwide, in English or German, with 15+ years of software architecture behind the AI work.

Start a conversationWhat this involves

Last updated:

Discipline
AI solution architecture
Experience
15+ years in software architecture
Availability
Remote, worldwide
Languages
English, German

Key points

  • The work is production, not prototypes. Turning an AI idea into a system that survives real users: architecture, data flow, evaluation and guardrails — not a demo that impresses in a meeting.

  • The usual starting point is a prototype that already works. Teams typically arrive with something promising that cannot yet be trusted, measured, priced or signed off.

  • Engagements are remote and scoped up front. Work starts with a written architecture assessment, so the plan and its risks are on paper before anyone commits to a build.

  • The background is software architecture, not model research. 15+ years designing and shipping software systems, now applied to the systems built around models.

§ 01 / 07

What does an AI solution architect do?

An AI solution architect designs the system around the model, not the model itself. Foundation models are bought, not built — so the engineering that decides whether a product works sits in retrieval, context design, evaluation, failure handling, cost control, and integration with the systems a company already runs.

Choosing the model is the small decision. The architecture around it is where an AI product is won or lost — and it is ordinary, demanding software engineering.

The governance requirements come from the EU AI Act, the risk controls of the NIST AI Risk Management Framework, and the attack surface in the OWASP Top 10 for LLM Applications.

Diagram: an AI model at the centre, surrounded by the five layers an AI solution architect designs — context and retrieval, evaluation, guardrails and failure modes, cost and latency, and governance.

  • System design. Which parts of the problem go to a model, which stay in deterministic code, and exactly where the boundary sits.

  • Context and retrieval. Where the model's information comes from, how it is kept current, and who is permitted to see what.

  • Evaluation. A test suite for non-deterministic output, so a prompt or model change can be shipped on evidence instead of a hunch.

  • Guardrails and failure modes. What the system does on a wrong answer, a prompt injection, a provider outage or a rate limit — decided in advance, not during the incident.

  • Cost and latency. Token spend and response time treated as design constraints with a budget, not as a surprise on the first invoice at scale.

  • Governance. The documentation, logging and human-oversight controls that a compliance review will actually ask for.

§ 02 / 07

How does an engagement work?

Every engagement runs in the same four stages, so you can stop after any one of them and still hold something useful.

  1. 01

    Discovery call

    We establish what you are trying to ship, what already exists, and whether a model is the right tool for it. If the answer is no, you get told that on the call.

  2. 02

    Architecture assessment

    A written document: the proposed architecture, the risks in it, an evaluation plan, and a cost model per request. This is a deliverable you own, whether or not the build follows.

  3. 03

    Build

    Implementation as lead architect alongside your engineers — designing the system, writing the load-bearing parts, and reviewing the rest.

  4. 04

    Handover

    Documentation, runbooks and the evaluation suite, handed to your team. The goal of the engagement is that it ends and the system keeps running.

§ 03 / 07

When should you bring in an AI solution architect?

Bring one in when the obstacle has stopped being the model and started being the system around it. The table below maps the situations that come up most often.

Where you are nowWhat that calls for
A prototype works for you but not for real usersRight time. The gap is architecture and error handling, not a better prompt.
Output looks good, but nobody can say whether it improvedRight time. You need an evaluation harness before you change anything else.
Legal, security or procurement has blocked the launchRight time. The fix is documented controls and oversight, and it is design work.
Nobody can tell you the inference cost per userRight time. Cost per request has to be modelled before you scale, not after.
The team ships well but has never run a model in productionRight time — as enablement. The aim is that your team owns it afterwards.
You are still deciding whether AI applies to the problem at allNot yet. A short call is cheaper than an engagement, and often ends in "not this".

§ 04 / 07

What can you engage me for?

Four shapes of engagement, from a single written assessment to sustained architectural ownership.

EngagementWhat you get
Architecture assessmentA written review of a planned or existing AI system: design, risks, evaluation strategy and per-request cost model.
System buildHands-on design and implementation of the system around the model, working as lead architect with your engineering team.
Advisory retainerRecurring architectural review for a team already building — design decisions, code review and a second opinion on the hard calls.
Team enablementGetting an experienced engineering team productive with AI systems: evaluation practice, guardrail patterns and production operations.

Scope, timeline and rate are agreed per engagement. The discovery call is free.

§ 05 / 07

Which technologies does this work involve?

Choices are made per project against its constraints, but the layers below are the ones every AI system has to answer for.

LayerWhat gets decided
ModelsHosted frontier models and open-weight alternatives, chosen against latency, cost, data residency and how badly a wrong answer hurts.
ApplicationTypeScript and Python services, with the boundary between model calls and deterministic logic drawn explicitly.
RuntimeEdge runtimes, containers or serverless — selected for where the data is allowed to live and how fast a response has to arrive.
ContextRelational stores, vector search and document pipelines, plus the access control that decides which user can retrieve which document.
OperationsEvaluation suites in CI, tracing on every model call, spend alerting, and a rollback path for a bad prompt.

§ 06 / 07

How is this website built?

This page is the smallest honest sample of the work — so here are its actual numbers rather than a claim about somebody else’s project.

Framework
Astro 7, server-rendered
Runtime
Cloudflare Workers, rendered at the edge
JavaScript shipped
1.1 KB gzipped, inlined
Separate JS requests
0
Third-party scripts
One — bot protection on the form
Cookies set
None
Analytics or tracking
None

No cookie banner appears because there is nothing to consent to. Fonts are self-hosted, so no font CDN sees your IP address. The contact form loads its bot-protection script only when you scroll to it.

Built with Astro on Cloudflare Workers. The site also describes itself to AI answer engines via llms.txt.

§ 07 / 07

How do you get in touch?

Describe what you are building and where it is stuck. A reply usually follows within two working days, in English or German.

Prefer email?
contact@arnekellmann.de

Sources referenced on this page