Skip to content
Mark Bregenzer

Workshop, extension

Current Architecture Workshop: AI in the product

Understanding the architecture when models are part of your product

This extension of the Current Architecture Workshop is for products in which AI does not just help with development but is part of the product itself. Then the architecture also includes how the models behave. And that cannot be drawn, only measured.

Illustration: a wall of sketches on measurement, providers, autonomy, and obligations of an AI feature, connected by a closed loop.AIin the product

Why this extension

As soon as a model is part of your product, its behavior becomes your product’s behavior. That behavior can be neither fully predicted nor fully specified. It changes when a provider updates a model, when a prompt is adjusted, or when the data shifts, without anyone touching a line of code.

Classic architecture diagrams show structure. For AI features, that is not enough. Structure can be drawn, behavior has to be measured. Alongside the architecture diagram comes the question: how do you know an AI feature does what it should, and how do you notice when it slips?

On top of that come questions classic architecture never had to ask. Which models and providers does your product depend on, and is there a tested way out? How much may a model decide on its own, and who is accountable? And which obligations follow, for example on labeling, logging, and data protection?

Four interlocking views on every AI feature in the product: measure, supply, limit, obligate.

What happens in the workshop

The extension builds on the Current Architecture Workshop. Its views remain, but their focus shifts. The model becomes an actor in the use cases, and failure cases such as wrong answers, refusals, or a model change become scenarios in their own right.

Four new views are added: behavior and evaluation, model and provider, autonomy and accountability, compliance and risk. Your teams look at them per AI feature and as a whole, not as four separate forms. Measurements justify how much a model may decide. Risk and obligations follow from that, and the obligations determine which providers are an option.

As in the Current Architecture Workshop, gaps are nothing to be ashamed of. Where nobody can show evidence, for example maintained test cases for an AI feature, that is the most important finding.

Questions the workshop answers

  • Which AI features does your product have, and how do you know they do what they should?
  • How do you notice declining quality before your customers do?
  • Which models, versions, and providers do you depend on, and is the way out tested?
  • What does a request cost, and who sees the bill?
  • How much may the model decide on its own, where do people step in, and how can a feature be switched off?
  • Do your users know that AI is involved?
  • Which personal data ends up in prompts and logs, and how long does it stay there?
  • For a specific answer, can you show which model, which prompt, and which sources produced it?

What you take away

As in the Current Architecture Workshop, your teams produce everything themselves. It stays with you, and you decide what to do with it.

  • For each AI feature, an overview of how good behavior is measured: test cases, metrics, thresholds, and owners, plus the places where nothing is measured yet
  • The supply chain of your AI features: models, versions, providers, fallbacks, and budgets
  • For each AI feature, a defined autonomy level with approval points, a kill switch, and follow-up review
  • A checklist on risk, labeling, logging, and data protection, with the open questions for your data protection and legal leads
  • A memo on what your AI features do that nobody ever intended, as a basis for new test cases
  • The open gaps, as concrete next steps
How much a model may decide on its own is set per AI feature, with approval points, a kill switch, and follow-up review.

AI belongs to the product, not to a separate team

The obvious move is to set up a dedicated AI team that owns the model layer. That creates exactly the handoffs that already slow you down. Prompts, test cases, and AI tooling are part of the product. The teams building features need to be able to change them, and a prompt change is a product change.

Who it is for

Product development organizations whose product contains AI features or soon will.

Because behavior is part of the product, product owners and UX belong in the room alongside the development teams, plus someone with a data protection perspective. The workshop is not legal advice. It shows which questions need answers and translates obligations into architecture.

Prerequisite

The extension requires a shared understanding of the architecture. It usually follows directly after the Current Architecture Workshop. If that understanding already exists, for example from an earlier workshop, the extension can also be booked on its own.

Background

The extension is new. It applies the approach of the Current Architecture Workshop to products in which models help make decisions. The review questions on risk and obligations follow the EU AI Act and the General Data Protection Regulation.

Details

Length
About one hour per AI feature, usually up to one additional day
Format
In person
Languages
German or English
Participants
Up to 30, from one product, including product owners, UX, and data protection
Prerequisites
A shared understanding of the architecture, usually from the Current Architecture Workshop
What you provide
Access to metrics, logs, and documentation on models and providers, where available
Price
On request, depending on group size and length