---
title: "AI architecture review: what to examine before launch"
description: "Published Arne Kellmann website information and agent integration guidance."
canonical: https://arnekellmann.de/ai-architecture-review
last-updated: 2026-09-26
---

# AI architecture review: what to examine before launch

A practical review of data access, model boundaries, failure handling and operating costs. What to bring, what a written assessment covers, and when it helps.

## Start with the decision the system must support

A convincing demo answers a narrow question: can the model produce a useful result? A production review asks what happens when the input changes, a source is missing or the provider stops responding. Start with one real user journey and trace its data, decisions and side effects.

An architecture assessment is useful when a working prototype needs a route to production, or when an existing system has unclear failure modes. If the underlying task can be handled reliably with ordinary code, establish that before adding a model.

## Bring evidence, not a polished presentation

The useful inputs are small enough to inspect and concrete enough to challenge. Remove credentials and personal data from examples before sharing them.

- A diagram of the request path, including retrieval, model calls and external actions.
- Representative inputs and outputs, plus examples that currently fail.
- The data sources, access rules and retention requirements.
- Expected request volume, response-time target and the current provider bill or cost assumptions.

## Four results of a written assessment

Arne Kellmann’s existing architecture assessment covers system design, risks, an evaluation strategy and a per-request cost model. The scope and timeline are agreed for the engagement.

| Result | The question it should answer |
| --- | --- |
| System design | Which decisions belong in code, which need a model, and where does human approval happen? |
| Risk review | What happens on unauthorized retrieval, prompt injection, invalid output or provider failure? |
| Evaluation strategy | Which examples and failure cases decide whether a change may ship? |
| Cost model | What does a completed user task cost, including retries and fallback? |

## Use the review to choose the next step

A review should leave the team with specific decisions and a testable next step. That may mean building, reducing the scope, gathering missing evidence or removing an unnecessary model call. It is an engineering assessment, not a legal certification or a promise that every failure can be prevented.

- [How I tested prompt injection in my own AI factory](/blog/i-attacked-my-own-ai-factory)
- [Evaluation: compare behavior before changing models](/ai-evaluation)