AI integration for SaaS: add AI without a rebuild

01Why the usual advice does not get you to production

Most guidance here is a list of feature ideas or a security checklist. Neither shows how AI attaches to a product with years of business logic, a permission model nobody wants to touch, and customers who cannot be disrupted.

The model is not the bottleneck. The product around it is. Your mature product already holds the workflows, integrations, definitions and permissions an AI capability needs, which is exactly why a rebuild is the wrong move. The job is to let AI use what you have, through the same doors your application code already uses, and to change nothing else.

02Which parts of our architecture should AI never touch?

Start by drawing a line around the system of record. Everything inside that line keeps working exactly as it does today, and the AI layer reaches it only through interfaces you already trust.

Two rules follow. The model never writes to the database directly; it calls an endpoint, and the endpoint applies your rules. And authorization is decided by your backend, not by the model's output: if the normal UI would refuse a request for that user, the AI request is refused too.

03How do we pick the first AI feature worth shipping?

The first feature should remove real manual work and prove AI can run safely inside your product. Pick a workflow that meets four tests:

• People do it often and by hand today, such as copying data between documents and forms, answering the same questions, or chasing follow-ups.
• The data it needs already lives in the product or arrives through an existing upload or integration.
• A person sees the output before it changes anything that matters.
• Success can be measured as a cost per successful task, not as a demo that looks good once.

It also helps to place each candidate on a capability ladder. Our co-founder and CTO, Rana Umar Majeed, describes five steps in why AI agents fail in production: read, recommend, prepare, modify and execute. Each step up needs more policy, more approval, idempotent actions and a fuller audit trail. A first feature should sit at read, recommend or prepare.

04Where should the AI integration sit relative to our core application?

The AI service sits between your existing user interface and your existing backend, as a separately deployed layer. It depends on the core product; the core product does not depend on it.

The dependency runs one way, so you can switch the AI layer off and the product behaves exactly as before. The model gateway lets you run on the cloud and model you already use, and change providers later without touching the core.

Split the work into narrow agents, each with a small job and a few tools. One agent that does everything is hard to test and hard to trust.

05How do we reuse our existing APIs, auth and data model?

APIs become a tool registry. List the endpoints the first workflow actually needs, then wrap each one as a tool with a plain description, typed inputs, and a declared level: read, prepare or write. Leave everything else out. The OWASP Top 10 for LLM Applications lists excessive agency as LLM06 in its 2025 edition. Its guidance is to give an agent only the tools it needs and keep each tool's functions to the minimum. It also warns against open-ended tools, such as running a shell command or fetching a URL, in favor of narrow, purpose-specific ones. A generic "run this query" tool undoes every other control you have.

Auth is inherited, not reinvented. The AI service calls your APIs with the signed-in user's identity, or a token derived from it, so every call passes through the permission checks you already run. The tenant identifier comes from the session, never from the model. The same OWASP guidance says actions taken for a user should run on downstream systems in that user's context with the minimum privileges necessary. It also says authorization belongs in those systems rather than in the model's judgment. A shared admin key for "the AI" is the most dangerous shortcut.

The data model keeps its meaning. Your product already defines what a cohort, a deal, a booking or an at-risk account means for each customer. Give those definitions to the AI as context. Where a feature needs to search unstructured content, such as documents, transcripts or help articles, build a retrieval index as a derived copy. Key it by tenant, filter it by the same permissions, and rebuild it from the system of record.

Content is data, not instructions. OWASP's 2025 entry on prompt injection (LLM01) describes indirect injection as content from outside sources, such as websites or files, that changes the model's behavior once the model reads it. Its guidance includes separating and clearly marking untrusted content and using deterministic code to validate the model's output. Treat everything the model reads as untrusted, validate its output before it reaches application logic, and never let document text widen what a tool may do.

06The retrofit sequence, step by step

This is the order we follow on a mature codebase. Each step is small, and none changes the core.

1. 01

   Map the system of record

   the data model, the integrations, the permission model and where audit events are written today.

2. 02

   Choose one workflow and define what a correct result looks like. Collect a few dozen real cases, de-identified, as the first evaluation set.

3. 03

   Inventory the existing APIs that workflow touches and select the smallest tool set that can complete it. Add a thin, versioned endpoint only where a needed function has no API.

4. 04

   Stand up the AI service as a separate deployment, with identity passthrough, tenant scoping, a model gateway and an AI audit log from day one.

5. 05

   Build the feature at the read, recommend or prepare level, with a person approving anything that would change a record or reach a customer.

6. 06

   Run the evaluation set in staging on synthetic or de-identified data, and fix failures before any customer sees the feature.

7. 07

   Release behind a per-tenant feature flag

   internal users first, then a small group of willing customers, then wider.

8. 08

   Measure cost per successful task, approval and edit rates, and how often the fallback path is used. Only then pick the next capability.

07How do we roll it out without risking current customers?

Feature flags per tenant. Every AI surface ships dark and is switched on tenant by tenant. If a customer's security team has not approved AI yet, their experience does not change at all.

A fallback path for every feature. When the model times out, a tool call fails, or the answer falls outside what the feature is allowed to give, the user lands back in the existing manual flow. Nothing is lost.

Evaluations that run on every release. Keep the evaluation set in your repository and rerun it on every code change and every model change.

Human approval for consequential actions. Updating records, sending messages and publishing content should need explicit confirmation. The AI drafts; a person decides.

Monitoring and limits. Watch for repeated tool calls, unusual data access and rapid loops, and rate limit the AI layer.

The same engineering discipline as any other change. Deliver the work as pull requests your team reviews and merges. The AI layer is still a web application. The OWASP Application Security Verification Standard, a framework of security requirements for designing, developing and testing modern web applications and web services, remains a sound yardstick for it, as for the rest of the product.

The same approach works for agents: see how to add AI agents to an existing SaaS product without rebuilding it.

08What we see in production

Each of the three examples below kept an existing product as the system of record. Clients stay unnamed.

A regulated investment platform. Issuers copied deal data by hand from decks, memos and financials into long forms. We kept the existing core application and its database as the system of record and built AI as services around it, so document, onboarding and compliance workflows could change without replacing the regulated application. Each step of the workflow got its own agent with a narrow job.

A field operations platform for a service business. Several roles coordinate schedules, assignments and issues at the same time. Existing tools needed app installs and heavy onboarding, did not work across the languages the teams speak, and the assistant covered only part of the job cycle. We kept the assistant inside the client's existing product and exposed its backend APIs as a tightly defined tool registry, so the model can act only through real endpoints. The result is an operations layer with role-aware assistance, support for several languages and mobile task coordination.

A communications platform for healthcare practices. Practices lose bookings through missed calls, slow responses and follow-up that never happens. The platform needed to turn those conversations into follow-up and bookings inside the product. We embedded engineers in the client's team, a way of working now often called forward deployed engineering. For the first new integration, they began by mapping the existing data model and processing pipeline, then tested two integration options side by side with real test data before choosing. The AI connects to the practice systems the platform already supports and runs inside the customer's cloud.

The pattern repeats elsewhere. On a cloud file-management product, reliability and regression coverage came first, then AI ingestion, retrieval and team chat workflows. On a multi-tenant fulfillment platform, only the blocking legacy storefront layer was replaced. On a clinical documentation product, the AI drafts notes and the clinician approves them before release. What we leave alone matters as much as what we build.

Frequently asked questions