Somewhere in most application design discussions at the moment, someone asks: "Where is the AI?" It is not usually a bad question. It is just asked too early — before anyone has established what the application actually needs to do.

Starting with AI is starting with the technology rather than the problem. The more useful question is: what part of this problem requires interpretation, and what part requires certainty? The answer to that question points toward the architecture. The technology choice follows from it.

Most enterprise applications contain both kinds of work. Understanding the distinction is what makes the architectural decision manageable.

Three choices — and where each one fits

There is a tendency in current discussions to treat AI as a binary choice — either the application uses AI, or it is behind. That framing misses how enterprise applications actually work. In practice, there are three meaningful architecture directions.

Normal non-AI application. Use when the rules are clear, the inputs are structured, and the result must be exact. A normal application produces the same output from the same input, every time. It can be audited, tested and debugged in a straightforward way. Payroll, tax calculation, payment processing, inventory reservation, identity provisioning, access rights updates — these belong here. They require deterministic accuracy, not interpretation. AI usually does not improve the core calculation or transaction. It may still assist with explanation, document handling or anomaly detection around it, but the authoritative function should remain deterministic.

AI application. Use when the application's main value depends on understanding language, reading documents, recognising images, detecting patterns or generating content. Speech transcription, document summarisation, image inspection, semantic search — these are tasks where conventional rules struggle because the input is inherently variable. AI is not an add-on here. It is the mechanism by which the application works at all. Without it, the value proposition disappears.

Hybrid application. Use when the application needs interpretation and certainty in the same process. This is likely to be the most common pattern for complex enterprise applications, because most real business processes involve both kinds of work.

The pattern is straightforward: AI handles the interpretation, rules or humans handle the authority. AI reads a document; rules validate the result. AI recommends an action; a human approves it. AI explains a transaction; the normal system records it. AI classifies an incoming ticket; the ITSM workflow controls priority and assignment.

Hybrid does not mean every application should use AI. It means that when both kinds of work are present, the architecture should separate them cleanly rather than blending them into something that is neither reliable nor interpretable.

Three architecture choices Three columns. Left: rules, calculations, transactions — Normal Application. Centre: Hybrid Application showing AI recommends, rules or humans approve, core system records. Right: language, documents, prediction — AI Application. NORMAL APPLICATION HYBRID APPLICATION AI APPLICATION Rules & exact calculations Structured inputs Transactions & records Exact, auditable output Payroll · Tax Payments Inventory Access rights Authority remains with rules Language & documents Images & unstructured input Patterns & predictions Content generation Transcription Summarisation Image inspection Semantic search Value depends on interpretation Certainty needed in one part Interpretation needed in another AI recommends interprets · summarises classifies Rules or humans approve validates · authorises decides Core system records system of record deterministic
Three architecture directions — the choice depends on what the application actually needs to do, not on the technology itself.

Three questions before the design begins

Rather than applying a large scoring model, three questions tend to clarify the architecture quickly. They are not a checklist to complete. They are a way of thinking through the decision before committing to it.

Is the task based on rules or interpretation?
Clear rules and exact calculations point to non-AI. Language, documents, patterns and ambiguity point toward AI.

What happens when the answer is wrong?
Low-impact suggestions may be handled by AI. Financial, legal, security or safety decisions require deterministic controls or human approval.

Can the application continue when AI is unavailable?
If yes, AI can be an assisting capability. If no, AI is part of the core and requires stronger operational investment. For most enterprise applications, design a fallback.

These questions do not produce a final answer on their own. They produce the right conversation — one that begins with the problem rather than the technology.

What changes at the infrastructure layer

A normal application mostly needs ordinary compute, storage, databases and monitoring. These are well-understood and cost-predictable. AI may introduce model APIs, vector search, variable token-based costs and the need for stronger monitoring of output quality — not just uptime. None of these should be introduced before the business use case is proven. AI infrastructure costs are real, variable and easy to underestimate from a prototype.

In a hybrid application, isolate AI services from the core so that the core can continue to operate when AI is unavailable. This is a design decision, not a post-deployment patch.

Where the backend must remain certain

Payments, tax, pricing, access rights and ledger updates should remain deterministic regardless of what AI recommends. These functions need to produce the same result every time and must be fully auditable. AI can classify, extract, summarise, recommend and predict around these functions — but it should not independently execute them.

The principle that matters here is simple: separate intelligence from authority. AI may suggest what to do. Deterministic services or humans should decide and act.

Keep AI integration visible and controlled

Application teams should avoid unmanaged direct connections to multiple model providers. When every component calls an external AI service independently, authentication, data filtering, logging and cost controls become inconsistent — and often invisible.

The appropriate pattern depends on scale. A small application may use a single controlled backend AI service. A larger enterprise may route AI calls through a shared gateway. In both cases, the same principles apply: keep authentication, data filtering, logging, cost controls and fallback behaviour visible and controlled. The goal is not to build a large AI platform. It is to avoid the point where AI usage in an application cannot be understood or managed.

A chatbot is not always the better interface

A chatbot is not automatically better than a form. For structured, repeatable input — a date, a policy number, a product code — a well-designed form is faster and more reliable than a conversational interface. Chat and natural language work well for exploration, explanation and genuinely unstructured questions.

More importantly: the interface should make clear what is a confirmed fact from the system, what is an AI suggestion, and what is a completed action. If the user cannot tell these apart, the interface is carrying the risk of the AI — silently.

The service desk makes the boundary clear

The service desk is a useful illustration because it contains both kinds of work in a single process.

The normal version. The user selects a category from a list, enters a description, and submits a ticket. Rules assign the ticket to the right queue based on category, department and priority. The ITSM platform records everything. The process is predictable, auditable and does not require AI to function reliably.

The AI-only version. AI reads the ticket, interprets the problem, assigns a category, sets a priority and attempts remediation — perhaps automatically. This is where the approach becomes risky. AI classification is probabilistic. An incorrectly classified ticket routes to the wrong team. An incorrect priority creates the wrong response window. An automated remediation on a misdiagnosed problem creates a worse problem. When AI has unrestricted authority over these decisions, errors compound without a natural stopping point.

The hybrid version. The user describes the problem in their own words. AI reads the description and suggests a category and a summary. Monitoring tools and the CMDB supply confirmed facts about the affected system. Rules validate the priority based on those facts, not just the AI interpretation. AI recommends a knowledge article or a resolution path. Low-risk, well-understood actions — like a password reset — may be automated. High-risk actions require engineer approval. The ITSM platform remains the system of record throughout.

This version is not more complex than the AI-only version. It is more honest about what AI is good at and what it should not be trusted to do alone. The value of AI in this workflow is real — free-text intake, faster classification, better knowledge retrieval — but it sits alongside the deterministic system, not above it.

Two simpler examples — payments and contracts

Payment execution. Payment processing requires exact validation, authorisation, ledger posting and settlement. These have to be deterministic. The same instruction, processed twice, should produce exactly the same outcome — and there must be a full audit trail. AI may support fraud signal detection or generate a plain-language explanation for the customer, but it should not independently execute or alter a payment. The payment engine is the authority. AI, where present, is an observer that may raise a flag.

Contract search. Reading a large contract to find a specific clause, understand a term or compare language across versions is genuinely time-consuming for humans and genuinely tractable for AI. AI is well-suited to surfacing relevant sections, summarising language and flagging differences. The original contract remains authoritative. Legal review remains necessary for decisions that carry obligation. AI improves the research without replacing the judgement.

A comparison worth keeping

Question Normal application AI application Hybrid application
Clear rules and exact output needed? Best fit Usually unnecessary Useful around selected steps
Language, documents or ambiguity? Limited Strong fit Often the safest fit
High cost of an incorrect output? Strong fit Requires strong controls Usually preferred
Must work when AI is unavailable? Naturally Requires special design Core can continue
AI is the product itself? No Yes Sometimes

This is a directional guide, not a universal score. The final choice depends on the specific capability and risk.

Five principles that matter

These are the decisions that matter most when choosing an architecture that includes AI.

Start with the problem, not the technology. Ask what the application needs to do before asking which technologies it should use. The nature of the problem — certain or interpretive — points toward the architecture. The technology follows.

Keep the transactional core deterministic. Payments, tax, ledgers, access control and regulatory calculations need to produce the same result every time. These should not be delegated to probabilistic systems, regardless of how capable those systems appear in a demonstration.

Separate intelligence from authority. AI may interpret, summarise, classify and recommend. Deterministic services or humans should approve, execute and record. This boundary is the most important structural decision in any hybrid application. Keeping it clear makes the application safer to operate and easier to audit.

Design for graceful degradation. If the AI component is unavailable, what happens? In a well-designed hybrid application, the core process continues in a reduced mode. If the answer is that the application stops entirely, AI has become a single point of failure that requires the same reliability investment as the core system.

Measure business value before scaling. A prototype that works in a demonstration is not proof that AI will deliver measurable value in production at scale. Define what success looks like before building — accuracy, throughput, cost reduction, user outcomes — and measure against those targets in the live environment.

What this means in practice

Not every application needs AI. Some need certainty. Some need interpretation. Many need both — but they need a clear boundary between them.

The pressure to add AI to every application is real, and it is mostly driven by visibility rather than value. The organisations that will use AI well are the ones that treat it as an architectural capability to be applied where it creates measurable improvement — not a feature to be added to prove awareness of current technology.

The architect's role is not to add AI or block it. It is to decide where intelligence creates value without weakening control, clarity or reliability — and to make that decision clearly enough that it can be held to when the pressure to change it arrives.

Before the design begins