AI · Web Development · Digital Transformation

A Practical AI Architecture for an Existing Website

Adding AI to a working website does not require rebuilding the entire product around a model. In many cases, the better approach is to keep the existing application in control and introduce AI as a bounded service with clear inputs, validation, permissions, fallbacks, and measurement.

Published August 17, 2026 · Panos Khan

Start with the job, not the model

The first architectural decision is not which model to use. It is what the feature is supposed to accomplish for a user. Examples include summarising a document, extracting structured information, helping a user search a knowledge base, generating a first draft, or classifying incoming requests.

A narrowly defined job makes it easier to choose the right interface, establish acceptance criteria, and decide where a human needs to remain in control. It also prevents a common failure mode: adding a general chatbot where a small, purpose-built workflow would be more useful.

Keep the website as the system of control

A useful baseline architecture looks like this:

Browser: collects the user's request and presents the result.
Application layer: authenticates the request, checks permissions, validates inputs, and decides which AI operation is allowed.
AI service: receives only the information needed for the specific task.
Validation layer: checks the returned result before it is shown or used by another system.
Observability: records useful operational signals so failures and regressions can be investigated.

The important point is the boundary: the model can generate or classify information, but application code should remain responsible for authorization and consequential actions.

Do not put secrets in the browser

If an AI provider requires a private API credential, that credential should not be embedded in client-side JavaScript. A public website can expose every value shipped to the browser. Put provider credentials behind a server-side boundary or use an architecture that does not require a private secret in the client.

This is a basic web-development rule, but it becomes easy to overlook when a team prototypes an AI feature directly in a page. A prototype can prove the interaction without becoming the production security architecture.

Make the AI operation narrow and explicit

Define the operation as a contract. Specify the input fields, expected output shape, allowed length, error states, and what the application will do with the result.

Structured output can help the application validate a response before using it. For example, an extraction feature might require a fixed set of fields and reject a result that does not conform. Validation should happen in application code rather than assuming that a model will always follow instructions.

Treat external content as data, not authority

If the feature uses uploaded files, retrieved web pages, emails, documents, or tool results, treat that material as untrusted input. Content can contain instructions that conflict with the application's intended behavior.

OWASP's Top 10 for LLM Applications 2025 highlights prompt injection and related risks as part of the security landscape for LLM applications. The practical response is architectural: separate data from control decisions, limit tool permissions, validate sensitive operations, and avoid giving the model authority that the product does not actually need.

Use least privilege for tools and actions

An AI feature that only drafts text needs very different permissions from an agent that can modify records or call external services. Give each operation the smallest set of capabilities required for its job.

For consequential actions, add an explicit application-level confirmation step. The user should be able to see what is about to happen and stop it before the action is committed. This is especially important when an AI workflow can affect data, money, accounts, publishing, or other durable state.

Plan for failure before launch

AI services can return errors, time out, produce malformed output, or provide an answer that does not satisfy the application's acceptance criteria. Your website should have a defined response for each category.

Validation failure → ask for another attempt or return a controlled error.
Provider timeout → retry within a bounded policy or offer a fallback.
Unavailable dependency → keep the rest of the site usable where possible.
Low-confidence or unsuitable result → request review instead of silently accepting it.

Failure handling is part of the feature, not an optional polish step. A useful AI system is one that remains understandable when the model is unavailable or wrong.

Control cost and resource usage

AI usage should have explicit limits. Depending on the workflow, that can include maximum input size, output size, request frequency, retries, tool calls, and execution time.

OWASP's 2025 guidance expanded the discussion of denial-of-service concerns into Unbounded Consumption, including resource-management and unexpected-cost risks. See the OWASP Top 10 for LLM Applications 2025 for the underlying security guidance. The engineering lesson is simple: define resource boundaries before the feature reaches real traffic.

Measure the complete user outcome

Model quality is only one part of product quality. Measure what matters to the workflow: successful task completion, useful corrections, error rates, latency, adoption, and other product-specific outcomes.

NIST's AI Risk Management Framework treats AI risk management as an ongoing process of governing, mapping, measuring, and managing risk. That mindset fits web products well: release the feature, observe real behavior, evaluate it against its intended job, and improve it as conditions change.

Where this fits in the Panos Khan ecosystem

This architecture is intentionally compatible with a normal web platform rather than requiring an isolated AI application. The Panos Khan Documentation provides a place for implementation and architecture notes, while Research can hold deeper frameworks and methodology. The Labs area is a natural place for experiments before an idea becomes a production surface, and the AI Blog collects practical AI and web-development guidance.

A compact production checklist

Define one user job and its acceptance criteria.
Keep authentication and authorization in application code.
Keep private provider credentials out of browser code.
Validate model outputs before using them.
Treat retrieved and user-supplied content as untrusted data.
Limit tools, permissions, retries, and resource usage.
Design fallbacks for model and dependency failures.
Measure the real user outcome and review the feature after changes.

The goal is a better website, not a more complicated website

The strongest AI integrations often look less dramatic than the prototypes that inspired them. They solve one problem, fit into an existing workflow, expose only the capabilities they need, and give users a clear path when the system cannot help.

That is a useful standard for digital transformation: introduce new capability without giving up the engineering discipline that made the existing product reliable.