Reliable Enterprise AI

What features and architecture decisions actually are

A feature is a capability you add to a system that’s already designed. It extends what the system does without fundamentally changing how it’s structured. Features can be added, modified, and removed without rippling through the entire design.

Architecture decisions are different. They define the structure of the system: how components relate to each other, what dependencies exist, what constraints propagate through. Architecture decisions are expensive to change because they’ve been built into everything downstream. You don’t swap out an architecture decision the way you swap out a feature.

Retrieval-augmented generation is an architecture decision because it determines the information flow of the entire system.

• Where does knowledge come from? How does it get there?
• What happens when retrieval fails?
• How is the boundary between the model’s internal knowledge and the retrieved context managed?
• What does the system do when those two sources conflict?

Every one of these questions has cascading implications: for how data is stored, how it’s updated, how the prompt is structured, how outputs are evaluated, how failures are detected. You can’t make these decisions component-by-component as you go. They have to be resolved as a whole.

The three architecture decisions RAG forces

When a team decides to use RAG, they’re not making one decision. They’re making at least three, and the interactions between them are what determine system behavior.

• The knowledge boundary decision. What does the system know from retrieval, and what does it know from the model’s training? This boundary is almost never explicitly defined, which means the model will resolve conflicts between retrieved context and its own priors in ways that aren’t predictable or auditable. For enterprise systems, where the retrieved information should be authoritative, this boundary needs to be explicit: the architecture needs to enforce that retrieved context takes precedence, and has to handle the case where retrieval returns nothing useful.

• The retrieval quality decision. The quality of what gets retrieved determines the quality of what gets generated. But retrieval quality isn’t a single metric, it’s a function of how documents are chunked, which embedding model is used, how queries are formulated, and how results are ranked. Each of these is an architecture decision with downstream consequences. A team that treats retrieval as a solved problem (call an API, get results, done) will discover in production that it wasn’t.

• The failure mode decision. What does the system do when retrieval returns nothing relevant? When the model contradicts the retrieved context? When a query is outside the knowledge base’s scope? These aren’t edge cases, they’re predictable failure modes that should be designed for explicitly. In most RAG implementations I’ve studied, the answer to all three is “the model generates something anyway”. That’s a design choice, and it’s often the wrong one for enterprise contexts.

Why this matters more in enterprise than in consumer

A consumer-facing RAG system that occasionally produces a wrong answer causes inconvenience:

• The user notices.
• The user tries again.
• The user learns to verify important outputs.
• The feedback loop is fast and the stakes are usually manageable.

Enterprise RAG systems operate at a different risk level:

• Outputs feed into processes.
• Decisions get made.
• Records get created. The organization acts on what the system says, at scale, without individual verification of every output. An error rate that’s acceptable in consumer contexts (wrong 5% of the time) can be catastrophic in enterprise contexts if that 5% is systematically wrong about something specific.

This changes what “good enough” means.

• Consumer. Impressive most of the time.
• Enterprise. Reliable in the ways that matter, with explicit handling of the cases where it isn’t.

The architecture has to be designed for the enterprise requirement from the start. You can’t get there by iterating from a consumer-grade implementation.

The compliance dimension is now real

This year the EU AI Act came into force. For enterprise teams building AI systems in Europe, or serving European users, the regulatory environment has changed.

For high-risk AI systems (and education, employment, and several other domains qualify), the Act requires that systems be designed for auditability: inputs and outputs must be logged, the system’s behavior must be explainable, human oversight must be operationally feasible, not just theoretically present.

These requirements map directly onto architecture decisions. Auditability requires logging at the retrieval layer, not just at the output layer. Explainability requires that retrieved sources be traceable for each output. Human oversight requires that the system surface uncertainty rather than suppressing it.

None of these properties can be retrofitted easily. They have to be designed in. Which is, again, why RAG is an architecture decision: the compliance requirements propagate through the entire system design, and you can’t satisfy them by adding a logging module to a system that wasn’t built with logging in mind.

What treating RAG as architecture actually looks like

In practice, treating RAG as an architecture decision means answering a specific set of questions before writing integration code, not during, and certainly not after:

• What is the knowledge boundary, and how is it enforced?
• What happens when retrieval returns low-confidence results, and how is “low confidence” defined and detected?
• How are retrieved sources traced through to outputs?
• How does the system behave when a query is outside its reliable scope?
• What evaluation framework will be used to measure whether retrieval quality is acceptable before and after changes?
• Who is accountable for outputs, and what do they need to be able to answer about any given output?

These questions don’t have universal answers. The right architecture depends on the use case, the knowledge base, the user population, and the regulatory environment. But they all need answers, and those answers need to be reflected in the design.

Teams that treat RAG as a feature skip these questions and discover the answers in production. Teams that treat it as an architecture decision answer them before building and discover that production is much less surprising.

The practical test

Here’s a quick diagnostic. If your team is considering or has already deployed a RAG-based system, ask these three questions and see how comfortable the answers are.

• For any output the system has produced in the last week: can you identify exactly which retrieved documents contributed to it, what similarity scores those documents received, and what the prompt looked like when it was sent to the model?

• For the last significant change to the system (new documents ingested, retrieval parameters adjusted, model updated) do you have before-and-after evaluation data that quantifies the effect on output quality?

• For the queries your users ask most frequently: do you have a documented, tested answer to what the system does when retrieval for those queries returns nothing useful?

If the honest answer to any of these is “no” or “not easily,” you have architecture gaps. They’re fixable. But they’re easier to fix before production than during it.

The technical depth of what reliable RAG architecture actually requires: chunking strategy, retrieval evaluation, confidence signaling, observability design, is something I’m going deeper on over the rest of this year. These conceptual pieces are the foundation. The engineering follows.