How to add AI to an existing SaaS product: first scope

How to add AI to an existing SaaS product starts with one user task, not a new model or a rewrite. Identify the inputs, enforce the user's permissions, keep a named reviewer in control and define what would stop the rollout. Test a bounded integration if those boundaries are clear. Use discovery if access, quality or the investment case is still uncertain; scope modernisation only around a specific constraint.

For a founder, Head of Product or CTO commissioning the work, the first deliverable should be a decision-ready brief. Here is how to make it concrete.

The decision is a workflow, not a model or a rewrite

Replace “add an AI assistant” with a sentence describing the change in the live product: “When a support agent opens a ticket, suggest the relevant approved guidance and a draft reply for that agent to review.”

That sentence identifies an entry point, an output and a person who stays responsible. It also excludes sending replies, changing accounts and making refunds. Each of those would be another scope with different permissions and failure consequences.

Ask the engineering team to map the smallest boundary that can contain the feature: existing interface → authenticated backend → authorised retrieval → draft → review. Keep account access and business rules in application code, outside the model's discretion. Treat the integration as something you can turn off while the original task still works.

A rewrite proposal needs a separate explanation: which constraint prevents this bounded change, what narrower repair was considered and why it is insufficient. “The product needs AI” is not that explanation.

Choose the first user task and the non-AI alternative

Pick a task where the team can show both a useful answer and a costly wrong answer. Before buying development, compare three options against the same examples:

• Improve the current process. If staff cannot find an approved policy because it has no owner or useful title, fix the source and navigation first.
• Use rules or an existing feature. If routing follows a stable mapping of ticket category to team, use that mapping. If your current support platform offers a feature that meets the access, review and operational requirements, test it before commissioning custom work.
• Add a bounded AI step. Consider retrieval and drafting when the task needs interpretation of varied language and approved material, and a reviewer can judge the result.

Record the current time spent searching, writing and correcting, including escalations. Compare the proposed feature with that whole task, not just how fast text appears. A draft that takes longer to verify has not passed the business test.

For the broader buy-versus-build decision, see our guide to custom AI solutions. Here the narrower question is where an AI-assisted step belongs in software you already operate.

Check sources, access and actions in the existing product

For every proposed source, name its owner, permitted users, update mechanism and deletion path. An approved knowledge article and a private customer ticket are not interchangeable inputs.

Authorisation belongs before generation. Retrieve only material the authenticated user is entitled to access. Microsoft's document-level access guidance describes query-time permission filtering and notes that indexed permission changes depend on synchronisation. Ask how your design handles revoked access, stale permission metadata and cached drafts—not only the initial import.

Source text is not an instruction. A customer ticket or retrieved document can contain instructions intended to redirect the model. OWASP's prompt-injection guidance explains that retrieval-augmented generation does not fully remove this risk. Keep untrusted material separate, limit privileges and validate actions in code. Do not give a drafting feature a credential that can send messages or modify accounts.

Decide what leaves your systems. List the fields sent to the model provider, where prompts and outputs are logged, their retention and who can inspect them. Have your security and privacy owners agree these boundaries before using real customer records. A read-only feature still requires a data-handling decision.

A worked commissioning brief for support triage

Consider a hypothetical multi-tenant SaaS whose support agents manually read tickets, search an approved knowledge base and draft replies. This is a proposed example, not a customer result.

• Owner and user: the Head of Product commissions the feature; the support lead judges reply quality; an agent works within an assigned customer workspace.
• Current task and alternative: search, draft and review manually. Trial better knowledge-base search and response templates alongside AI drafting.
• First release: a “Prepare draft” action on an open ticket returns a suggested category, supporting source links and an editable reply. No automatic send.
• Allowed sources: current approved help articles for that customer's product version, plus the ticket already visible to the agent. Exclude other tenants' tickets and internal commercial notes.
• Permission rule: the backend derives workspace and user scope from the authenticated session. The model cannot choose a tenant or widen access. Source links undergo the same access checks as ordinary links in the product.
• Actions and review: the AI path reads and drafts only. The agent can reject, edit or escalate; sending stays in the existing reviewed process. Missing or contradictory evidence returns an escalation rather than a guessed policy.
• Acceptance evidence: the support lead reviews representative tickets, expected sources and acceptable responses. Compare total handling time, correction effort and escalation quality with the manual and template alternatives.
• Stop rule: disable the pilot on an observed cross-tenant disclosure, an unauthorised action or a reply that follows malicious source instructions. Investigate before re-enabling; passing a test suite is not a promise of zero future incidents.
• Operations: agree a per-task cost ceiling and latency limit before the pilot. On timeout or unavailable sources, retain manual handling. Name the person who can disable drafting and the engineer who owns recovery.

Notice what is absent: a chosen model, a promised saving and a rebuild deadline. Those decisions follow evidence from this scope.

Acceptance and rollout: what has to pass

Prepare test cases before implementation. Include routine questions, ambiguous requests, no relevant source, contradictory guidance, outdated articles, removed access, another tenant's record, malicious instructions and provider failure. Give each case an expected source set, acceptable outcome and forbidden outcome.

Judge retrieval and the final reply separately. Did the system retrieve permitted, relevant material? Did the draft interpret it correctly and address the question? Microsoft's RAG evaluation guidance distinguishes groundedness, completeness, relevance and correctness. A cited reply can still reach the wrong conclusion. Responses are nondeterministic, so repeat important cases rather than approving one successful demo.

Set thresholds with the product owner: maximum correction effort, acceptable handling time, cost per completed task and which errors block release outright. Do not replace these with a model's self-reported confidence. Keep safety blockers separate from averages; faster ordinary replies do not cancel out an access-control failure.

Roll out in steps:

1. Offline evaluation: review outputs on approved test material, with no customer-facing action.
2. Restricted staff pilot: enable drafting for a named group; every reply remains reviewed. Track rejections and edits as well as usage.
3. Limited release: expand only after agreed quality and operational gates pass. Keep the manual path and a tested disable switch.

Hand over the source-refresh process, test set, configuration versions, cost monitoring, incident owner and recovery runbook. Re-run the relevant tests when sources, permissions, retrieval settings or the model change.

Integrate, discover, modernise or stop

Use the evidence to choose the next engagement:

• Integrate when the task, authorised inputs, review point and acceptance gates are known, and the existing product exposes a workable boundary.
• Run discovery first when source access, output quality or the business case could change the investment decision. Request a source map, tested feasibility assumptions and a recommendation to proceed, narrow or stop. Our AI discovery sprint is the commissioning path for that uncertainty.
• Scope targeted modernisation when a specific missing permission boundary, unusable interface or unowned component prevents the integration. Separate that repair from the AI feature so its cost and completion criteria are visible.
• Stop or choose the simpler alternative when rules, templates or an existing feature meet the need, the review burden outweighs the benefit, or the necessary data cannot be authorised.

What to send an engineering partner

Copy these headings into a brief and fill the gaps before asking for a delivery estimate:

• Owner, user and task: who decides, who uses it, and what changes in their current screen?
• Baseline and alternative: how is the task completed today, and what simpler improvement will you compare?
• Sources and permissions: approved systems, tenant boundaries, freshness, revocation and provider data handling.
• Reads, writes and review: allowed actions, forbidden actions, reviewer and escalation path.
• Tests and gates: representative examples, expected evidence, owner-chosen thresholds and release blockers.
• Operating limits: cost ceiling, latency, fallback, disable switch, monitoring and handover owner.

Awakast integrates retrieval, orchestration and human review into existing products, with evaluation and an operational handover path. Bring the task and its boundaries; the integration design should follow them. Discuss your first AI-workflow integration.