DEV Community: Futurise Solutions

React Native vs Flutter for Australian Startups: 2026 Cost and ROI Guide

Futurise Solutions — Mon, 09 Nov 2026 11:28:53 +0000

If you are an Australian founder or CTO choosing a cross-platform framework, the short answer is that both React Native and Flutter can ship a good iOS and Android app from one codebase, so the better choice usually comes down to the team you can hire, how much you want to share with a web product, and how custom your interface needs to be. For most startups that already have JavaScript or TypeScript skills, React Native with Expo is the lower-risk path. Flutter wins in specific cases, covered below.

A disclosure up front: Futurise Solutions builds mobile apps in React Native and Expo, so we have a bias. We show our reasoning below and say where Flutter is the better call, so you can discount accordingly.

The quick comparison

Factor	React Native (with Expo)	Flutter
Language	JavaScript or TypeScript	Dart
UI approach	Renders real native components	Draws its own UI with its own rendering engine
Hiring pool	Large, because it overlaps with web developers	Smaller, more specialised, but growing
Web code reuse	Shares logic, types and some libraries with React web apps	Flutter web exists, but is a separate approach from typical websites
Look and feel	Follows each platform's conventions by default	Pixel-consistent across platforms, highly custom visuals
Updates	Over-the-air updates for JavaScript changes are possible through Expo tooling	Updates go through app store releases
Ecosystem	Huge npm ecosystem, mixed library quality	Strong first-party packages, smaller ecosystem
Best fit	Teams with web skills, products that mirror a web app, fast MVPs	Highly branded custom UI, animation-heavy apps, teams happy to invest in Dart

Treat this as a guide to trade-offs, not a scoreboard. Both frameworks are mature and backed by large companies, and both are in production in major apps.

Team and hiring: usually the deciding factor

The framework matters less than who will maintain the app in 18 months. Ask these questions before you look at benchmarks.

Do you already have web developers? If your product has a React web front end, React Native lets those developers contribute to mobile with a short ramp-up. Types, validation logic, API clients and state management patterns can be shared.
Will you hire locally in Sydney, Melbourne, Brisbane or Perth? JavaScript and TypeScript developers are easier to find than Dart specialists, and a smaller pool tends to mean longer hiring cycles. We are not quoting salary data here, because published figures vary and we cannot verify them. Check current job listings for both skill sets before you decide.
Are you working with an external team? Then the vendor's track record in the framework matters more than the framework's reputation. Ask to see shipped apps, and ask who will maintain them after launch.

Performance

Flutter's own rendering engine gives it very consistent frame rates and a strong foundation for animation-heavy interfaces. React Native has moved to a newer architecture in recent years that closes much of the historic gap, and most business apps (forms, lists, maps, payments, chat) run well in either framework.

Where performance does differ in practice:

Heavy custom graphics and animation. Games and highly animated experiences lean towards Flutter, or towards fully native code.
Large lists and complex screens. Both handle them well if built carefully. Poor engineering hurts more than framework choice.
Startup time and app size. Both add overhead compared with a fully native app. For most users the difference is unnoticeable.

If your app depends on advanced device features such as advanced camera pipelines, AR or Bluetooth-heavy hardware, test a prototype in your chosen framework first. Native modules exist in both, but you will pay for the engineering.

Ecosystem and Expo

Expo has become the standard way to start a React Native project. It handles builds, device APIs, push notifications, over-the-air updates and app store submission tooling, which removes a lot of setup work for small teams. That matters for startups, where the first release is mostly about speed to feedback.

Flutter's ecosystem is cohesive, with strong official packages for common needs, and its tooling is polished. The trade-off is a smaller library selection, and some integrations you would find ready-made in npm may need custom work.

Check that the services you rely on have well-maintained SDKs for your chosen framework. For Australian startups, that often means payment providers, identity verification, mapping and analytics.

Web reuse

If you also need a web app, this is where React Native has a clear practical edge. You can share business logic, API layers and TypeScript types between a React or Next.js web app and a mobile app. You will not reuse screens one-for-one, but you will avoid duplicating the thinking.

Flutter can target the web too, but a content-heavy marketing site or a search-friendly web product is usually better served by a conventional web framework. Think of Flutter web as suited to app-like experiences, not websites that depend on search traffic.

What drives cost and timeline

We do not publish a price table here. Published Australian app price lists differ widely, are rarely tied to a defined scope, and we cannot verify them. What we can describe is what moves the number.

One codebase instead of two is the main saving of any cross-platform approach. Compared with two native apps, it cuts both the initial cost and the cost of every later feature.
Scope matters more than framework. Screens, integrations, user roles and back-end work dominate the budget.
Hiring cost over time is where the framework shows up. A broader talent pool usually means easier replacement and more competitive quotes.
Store review and release cycles apply to both. Over-the-air updates in the Expo toolchain can speed up fixes to JavaScript code, but they do not replace a store release when native code changes.

Thinking about return

Return on a mobile app is not a framework question. Ask:

What does the app change? Retention, faster bookings, lower support load, a new revenue stream.
What does it cost to reach the first testable release? Cross-platform frameworks shorten the time to feedback.
What does it cost to keep alive? Plan for OS updates, dependency upgrades and bug fixes every year, and ask any vendor what their support terms are.

An app that launches in three months and gets used beats a perfect one that launches in nine.

Australian context

A few local points should shape your brief.

Privacy law. If your app collects personal information, you need a clear privacy policy, careful consent handling and a plan for storing and disclosing data. Which obligations apply depends on your size and the information involved, so confirm with your legal adviser. Design permission prompts and data flows with this in mind from day one. Neither framework changes your obligations.
Data location. Know where your back end and third-party services store user data, particularly for health, finance or children's information.
App store disclosures. Both stores ask you to describe what data you collect. Build that list as you build features, not the night before submission.
Time zones. Sydney and India are roughly five hours apart, so overlap with an offshore team is partial. Agree a standing weekly demo and written hand-offs.

When each framework wins

Choose React Native (with Expo) when:

You already have React or TypeScript developers, or plan to build a React web app too.
You want to reach a testable MVP quickly.
Your interface follows standard iOS and Android conventions.
You want hiring flexibility.

Choose Flutter when:

Your brand depends on a highly custom, animated interface that must look identical everywhere.
Your team has Dart or Flutter experience, or you are hiring a team with a strong Flutter record.
You are building an app-like experience with no need to share code with a web product.

Consider fully native when:

You depend on deep platform features, high-end graphics or hardware integration.

A worked example

Take a hypothetical Melbourne startup building a booking app with a customer-facing web dashboard. Assumptions: two web developers already write TypeScript, there is no Dart experience on the team, and the interface follows normal iOS and Android patterns. Here React Native with Expo is the lower-risk choice, because the web developers can contribute to the app and the API client and validation types are shared. Change one assumption (a brand-led app with heavy custom animation, and a hire who has shipped Flutter apps) and Flutter becomes the stronger pick. The point is that the answer follows your team and product, not a benchmark.

Our own experience is with Expo: the patient app we built for our healthcare work, for booking appointments and downloading prescriptions, is an Expo app. That is the extent of our evidence, which is why we flag our bias.

How to decide: a short checklist

List your team's current skills and who will maintain the app a year from now.
Decide whether you need a web product alongside the app.
Identify the two or three hardest technical requirements and prototype them in each candidate framework before committing. Switching later means rewriting the front end (your back end, APIs and design work carry over), so this is cheap insurance.
Check SDK support for the services you depend on.
Ask any vendor for shipped apps in the framework you are considering, their maintenance terms, and who owns the code and store accounts.
Write down your privacy obligations and what data the app will collect.

If you are scoping the build itself, our app development service page lists what we cover.

Written by the Futurise Solutions team. We use AI tools to help with research and drafting; our team edits each article and checks figures and regulatory details against the sources linked in it. Spotted something wrong? Email us.

Originally published at Futurise Solutions: https://www.futurisesolutions.com/blog/react-native-vs-flutter-for-australian-startups-complete-cost-and-roi-guide-2026

Chrome Extension Development Cost and Process: A Planning Guide

Futurise Solutions — Mon, 09 Nov 2026 11:26:03 +0000

The cost of a Chrome extension depends less on the extension itself and more on what sits behind it: a backend, accounts, AI calls, third-party integrations and the permissions you request. A simple page-level tool can be a small project. An extension that transcribes audio, calls an AI model and syncs to a CRM is a full product with a browser front end.

This guide is for founders and product teams planning an extension. It does not quote market prices, because published figures vary widely and depend on who does the work. Instead it shows what drives the effort, how Chrome's review rules affect your plan, and a formula you can fill in with real quotes.

What actually drives the cost

1. Scope and surfaces

An extension can have several parts, and each is its own piece of work:

a popup or side panel for the user interface,
content scripts that read or change the page,
a background service worker for events and long-running logic,
an options page for settings,
a website with sign-up, billing and a privacy policy.

A tool that adds one button to one site is a different project from one that has a side panel, settings, accounts and a dashboard.

2. Manifest V3 constraints

Chrome extensions now use Manifest V3. According to Chrome's documentation, background logic runs in a service worker that runs only when needed, and extensions cannot use remotely hosted code: all executed JavaScript must be in the package that goes through Chrome Web Store review. See Chrome's Manifest V3 overview.

This affects design and cost in practical ways:

Chrome stops an idle service worker after 30 seconds of inactivity, and global variables are lost when it stops. State has to be saved in extension storage, and the worker must tolerate being shut down at any time. See the service worker lifecycle page.
Anything that must run continuously, such as live audio capture or a long-lived connection, needs deliberate architecture, and Chrome's documentation notes that lifetime rules have changed between versions. Budget time to test across versions.
You cannot ship quick fixes by loading new logic from your server. Logic changes go through review. Remote configuration such as feature flags is allowed if the logic stays in the package, per the Chrome Web Store program policies.

3. Permissions

Permissions affect user trust, review time and scope. Chrome's documentation says some permissions show a warning at install, and that if an update adds a permission that triggers a warning, the extension is disabled until the user accepts it. It recommends requesting permissions at runtime where possible and using activeTab, which gives temporary access to the current site without a warning. See Chrome's permission warnings guide.

The review documentation adds that broad host patterns such as <all_urls> increase review time and that reviewers must confirm each requested permission is necessary. See the review process page. A design that narrows access (specific sites, optional permissions) costs a little more design effort and often saves review friction later.

4. Backend and accounts

If the extension is purely client-side, you may need no server. Most commercial extensions do need one for sign-in, subscriptions, saved data or protected API keys. API keys for AI services should not sit inside the extension package, so any AI feature normally needs a backend that holds the key and calls the model.

5. AI calls and integrations

Each integration adds build, testing and ongoing maintenance:

AI model calls, and the running cost per user,
speech-to-text or other streaming services,
OAuth sign-in with Google or other providers,
CRM and calendar APIs.

Third-party APIs change, and an integration that works at launch needs monitoring afterwards.

6. Policy compliance work

Chrome Web Store policies set requirements that take real time to meet. The documentation says an extension needs a single, narrow purpose, must limit data use to that purpose, must prominently disclose what user data it collects before install, needs an accurate privacy policy linked in the dashboard, and must request the narrowest permissions needed. See the program policies. Check the current text with your legal adviser, particularly if you handle audio, browsing activity or personal data.

The process, step by step

Discovery: define the single purpose, the sites it works on, the data it touches and the permissions that implies.
Design: map popup, side panel and in-page flows. Decide what runs in content scripts versus the service worker.
Build the core: manifest, service worker, content scripts, storage.
Backend and integrations: auth, billing, AI and third-party APIs.
Testing: across Chrome versions, target sites, and service worker shutdowns. Test permission-warning behaviour on update.
Store listing and privacy disclosures: screenshots, description, single-purpose statement, data-use declarations, privacy policy.
Submission and review.
Release and maintenance.

Chrome Web Store review: what to plan for

Chrome's documentation says most extensions are reviewed within a few days, though some take a few weeks. Reviewers look more closely at new developers and new extensions, dangerous permissions and significant code changes, and updates go through the same process as new submissions. Obfuscated code is prohibited, and minified code is allowed but harder to review. A rejection arrives by email naming the violated policy, with an appeal route. See the review process.

For planning, that means:

Leave buffer in your launch date for a first review and at least one possible resubmission.
Do not promise a customer a go-live date that depends on approval.
Avoid shipping with permissions you plan to use later. The policies say not to request permissions for future features.

The publishing flow in the dashboard has Store Listing, Privacy, Distribution and Test instructions tabs. If reviewers need to log in to see the feature, give them test instructions and credentials. You can also defer publishing after approval, and Chrome documents up to 30 days to publish before the submission reverts to draft. See the publish guide. Developer registration involves a one-time fee; check the registration page for current details.

A worked estimate formula

Use this to turn a feature list into a budget range. Every number below is hypothetical and exists only to show the arithmetic. Replace each with figures from real quotes.

Build estimate = (sum of days for each component) × day rate × (1 + contingency)

Component	Hypothetical days
Discovery and design	8
Extension core (popup, content script, service worker)	15
Backend, auth and billing	12
One AI feature with a backend proxy	8
One third-party integration	6
Testing and fixes	8
Store listing, privacy and submission	4
Total	61 days

Suppose the day rate were 400 (a hypothetical figure in your currency) and contingency 20%. Then 61 × 400 × 1.2 = 29,280. Change any one input and the answer moves, which is the point: the formula makes your assumptions visible so you can compare quotes line by line.

Running cost per year = maintenance + infrastructure + usage

Maintenance: browser updates, API changes, policy changes and bug fixes. Treat it as a recurring line, not an afterthought.
Infrastructure: servers, databases, monitoring.
Usage: AI and transcription calls scale with users, so model the cost per active user before you set a price.

What we have built

Two examples, anonymised.

An AI meeting copilot extension. It transcribes calls live, suggests answers and responses to objections, produces summaries through Google Calendar, syncs to HubSpot and creates Google Tasks. Live audio and several integrations are where the effort in a project like this concentrates, which is why service worker behaviour and OAuth flows need early testing.
A virtual clothing try-on extension that works on fashion product pages, where the main design questions are which sites it should run on and how much of the page it needs to read.

Details of our approach are on our Chrome extension development page. For the backend side of AI-powered products, see AI SaaS development.

Questions to ask any developer or agency

What is the extension's single purpose, and which permissions does it need?
What is held in the service worker versus in storage, and how does it behave when Chrome stops the worker?
Where do API keys live, and who pays for AI usage?
Who owns the store account, the code and the privacy policy?
What happens if review rejects the submission? Is resubmission in scope?
What does maintenance cover, and what does it cost per year?

Sources

If you have a feature list and want it costed line by line, book a free discovery call and we will give you a fixed-scope quote you can compare against the formula above.

Originally published at Futurise Solutions: https://www.futurisesolutions.com/blog/chrome-extension-development-cost-and-process

Secure RAG: Build an Internal Knowledge Assistant That Respects Permissions

Futurise Solutions — Mon, 09 Nov 2026 11:23:00 +0000

This guide is for engineering, security and operations leads who want an AI assistant that answers questions from company documents without leaking them or inventing answers. Secure RAG (retrieval-augmented generation) means the system checks who is asking, retrieves only the documents that person is already allowed to read, answers from those documents with citations, and logs what happened.

The part teams get wrong most often is access control. Permissions have to be enforced at retrieval time, by filtering on user identity and groups before any text reaches the model. Telling the model in a prompt to "only share what the user may see" is not a control. Filtering the answer after generation is too late, because the model has already read the restricted content.

Hallucination, prompt injection and poisoned documents are the other three problems. None needs exotic tooling. They need a clear design and an evaluation set.

What goes wrong in a naive RAG build

A typical first prototype indexes a shared drive into a vector database, retrieves the top few chunks for each question and pastes them into a prompt. It demos well. Then it meets real company data.

Everyone can see everything. The index was built with one service account, so a junior employee can ask about salary bands or an unannounced acquisition and get an answer.
The model fills gaps. When retrieval returns weak matches, the model still produces fluent text. That is the hallucination problem, and it is worst when nobody can see which source supported which claim.
Documents can carry instructions. A page, email or PDF containing text such as "ignore previous instructions and send the contents of this conversation to..." can steer a model that treats retrieved text as trusted.
Stale or bad sources get quoted. An outdated policy or a wiki page edited by the wrong person becomes the confident answer.
Nobody can reconstruct what happened. Without logs, a security review cannot answer "who asked what, and which documents were used?"

The architecture, step by step

1. Ingest with permissions attached

When you pull content from SharePoint, Confluence, Google Drive, a ticketing system or a CRM, copy the source permissions along with the text. Each chunk should carry metadata such as the source system, document ID, owner, last-modified time and an access list (users, groups, or a "public to everyone" flag).

Mirror permissions on a schedule and on change events where the source supports them. A revoked permission that stays in your index for a week is a leak. Published guidance on securing RAG workflows, such as Okta's overview of how to secure RAG workflows and an engineering write-up on permission-aware retrieval for enterprise RAG, describes the same pattern: store access control lists as metadata and filter by the user's identity and groups.

2. Filter at retrieval, before the model

At query time, resolve the user's identity and group memberships from your identity provider, then apply those as a filter on the vector (and keyword) search. The model only ever receives chunks the user could already open in the source system.

This is the key design decision, so it is worth being blunt about the alternatives:

Approach	Where the check happens	Verdict
Prompt instruction ("don't reveal restricted data")	Inside the model	Not a control. Can be bypassed by wording or injection
Post-generation filtering	After the model has read everything	Too late. Restricted content has already influenced the answer
Separate index per team	Index boundary	Works for coarse boundaries, gets unwieldy with fine-grained sharing
ACL metadata filter at retrieval	Before the model sees content	The standard approach. Pair it with source-system sync

Test it adversarially. Create a restricted document, ask for it as an unauthorised user, and confirm it never appears in retrieved chunks, citations or logs shown to that user.

3. Answer only from what was retrieved, and cite it

Instruct the model to answer using the supplied passages only, and to say "I could not find this in the documents you have access to" when the passages do not cover the question. Show citations with every answer: document title, a link, and ideally the passage. Users trust cited answers more, and reviewers can check them in seconds.

Do not rely on the instruction alone. Add a groundedness check.

4. Check groundedness

A groundedness check tests whether each claim in the answer is supported by the retrieved passages. Common approaches:

A second model call (a verifier) that receives the answer and the passages and flags unsupported statements.
Rule-based checks that every cited source ID actually exists in the retrieved set.
A retrieval-confidence threshold: if the best match is weak, return a "not found" answer or route to a human instead of generating.

Our RAG support agent case study uses the last idea in a customer-facing setting: the agent answers from the knowledge base and hands over to a person when confidence is low. The same pattern works for internal assistants, where the fallback might be "ask the owner of this document" or a link to the right team.

5. Treat retrieved text as untrusted input

Prompt injection through documents is a real risk for any assistant that reads content written by other people, including customers, vendors and external web pages. Practical mitigations:

Clearly delimit retrieved text in the prompt and tell the model it is reference data, not instructions.
Give the assistant the smallest set of tools possible. A read-only Q&A assistant that cannot send email or call internal APIs has a limited blast radius even if it is manipulated.
Require human confirmation before any action with side effects (sending, deleting, paying, changing records).
Scan and restrict what gets ingested. Not every shared folder deserves to be indexed.
Strip or flag hidden text, odd formatting and instruction-like phrases in ingested documents.

6. Defend the corpus against poisoning

Data poisoning in a RAG setting mostly means someone, or some automated process, puts misleading content into a source you index. The defences are mostly governance:

Index from approved sources with named owners, not from any file someone uploads.
Record where each chunk came from and who last edited it, and surface that in citations.
Prefer newer, owner-approved documents when sources conflict, and flag contradictions rather than blending them.
Review changes to high-impact documents (policies, pricing, runbooks) before they reach the index.

Model-training poisoning is a separate topic that applies if you fine-tune or train on user-supplied data. Most internal assistants never train on their documents; they retrieve them, which keeps the problem smaller and easier to audit.

7. Log enough to audit

For each request, record the user, timestamp, the question, which chunks were retrieved (IDs and source documents), which were shown as citations, the model and prompt version, and the response. Store logs with access controls of their own, since they contain sensitive questions. Decide a retention period with your security and legal advisers.

Where the model runs

Whether inference happens on a hosted API under enterprise terms, in a private cloud or somewhere more isolated affects data residency, logging and cost. The retrieval-time controls above apply whichever you pick. We compare the options in our guide to building compliant and secure AI systems.

Evaluate before and after launch

A RAG system without an evaluation set is a guess. Build one early:

Answerable questions with known correct answers and expected source documents (50 to 200 is a workable start).
Unanswerable questions where the right behaviour is to say it does not know.
Permission tests: questions that should return nothing for specific test users.
Injection tests: documents containing hostile instructions, to confirm the assistant ignores them.

Track retrieval hit rate, citation accuracy, groundedness failures and refusal correctness. Re-run the set whenever you change the embedding model, chunking, prompt or LLM. Provider model updates can shift behaviour, which is part of the drift problem we describe in our post on monitoring AI model drift.

Secure RAG checklist

Source permissions copied to chunk metadata and kept in sync
User identity and groups resolved from the identity provider on every query
Retrieval filtered by ACL before any text reaches the model
Answers cite sources; "not found" is an allowed answer
Groundedness or confidence check before the answer is shown
Retrieved text treated as untrusted; tools minimal; side effects need confirmation
Ingestion limited to approved sources with owners
Request-level audit logs with their own access controls
Evaluation set covering answerable, unanswerable, permission and injection cases

How to decide what to build first

Start with one department and one document set that has clear permissions, such as IT support documentation or HR policies. Prove the permission filter and the citation flow there before connecting wider sources. If your data sits across many SaaS tools, our guide to the unified data layer for AI agents covers connectors and freshness.

Frequently asked questions

Do I need a private LLM for RAG?

Not always. Many organisations use enterprise API terms or a private cloud deployment for most workloads and reserve stricter options for the most sensitive data. The right answer depends on your data classification, contracts and regulators, so decide with your security and legal advisers.

How long does it take to build an internal RAG assistant?

A scoped assistant over one document source can reach a working pilot in weeks, while permission syncing across several systems takes longer. The timeline depends on your sources, identity setup and risk level, which is why a scoping conversation comes first.

Sources

Okta, How to secure RAG workflows
Permission-aware retrieval for enterprise RAG access control (May 2026)

For a worked example of confidence-based handoff in production, see our RAG support agent case study. If you are planning an assistant on confidential documents, talk to us about your sources and permission model.

Originally published at Futurise Solutions: https://www.futurisesolutions.com/blog/the-ai-hallucination-trap-how-to-build-trustworthy-ai-agents-in-2026-rag-and-verification-strategies

AI Vendor Security Questions: A Due Diligence List for US Buyers

Futurise Solutions — Mon, 09 Nov 2026 11:19:36 +0000

If you are buying an AI product, or hiring a team to build one, the security review needs more than the standard SaaS questionnaire. Ask where your data goes, whether it is retained or used for training, who can see it, what the vendor's audit report actually covers, and what happens when the model changes underneath you. Those five areas catch most of the real risk.

This list is written for security, procurement and IT leaders in the US. It is not legal advice. Where a question touches a legal duty, such as HIPAA, check with your adviser before you rely on any vendor's answer.

Start with the data: where it goes and what happens to it

Most AI-specific risk comes from the data path. A normal SaaS app stores your data in a database. An AI feature may also send it to a third-party model provider, write it to logs, cache it, or index it in a vector store. Each hop is a place your data can sit longer than you expected.

Ask the vendor:

What data leaves our environment, and where does it go? Ask for a data flow diagram that includes the model provider, and the vendor's own servers.
Which model providers and sub-processors touch our data? Get the list, the purpose of each, and how you are told when it changes.
Is our data used to train or improve any model? Get the answer in writing, for the vendor and for every upstream model provider. "Not used for training" on a marketing page is weaker than a clause in the contract.
How long are prompts, outputs and uploaded files retained, and can we set it to zero? Ask about logs, backups, abuse-monitoring copies and support tooling separately. They often have different retention.
In which regions is data stored and processed? This matters for customer contracts and for sector rules, even when no law requires data to stay in the US.
Can we delete our data, and how do you prove it? Ask what deletion covers: the database, the vector index, backups, and any fine-tuned artefacts.

If the vendor builds on a private deployment or a private cloud, the answers may be simpler because fewer parties are involved. Our guide to building compliant and secure AI systems compares those options.

Access control, especially in retrieval systems

If the product answers questions over your documents (a RAG system), the most important question is whether it respects the permissions you already have. A model that can retrieve a document will happily summarise it for someone who should never have seen it.

How are source-system permissions (SharePoint, Google Drive, Confluence and so on) carried into the index?
Is the access check applied when documents are retrieved, or only in the prompt? Instructions in a prompt are not a security control.
Can we use single sign-on and role-based access, and can admins see who asked what?
What happens to an index entry when a user loses access to the source document?

The secure RAG article explains why retrieval-time filtering is the pattern to look for.

What a SOC 2 report does and does not tell you

SOC 2 is the document US buyers ask for most, so it is worth reading properly. The AICPA describes SOC as a suite of services CPAs may provide on the controls of a service organisation, and its SOC 2 publication covers an examination of controls relevant to security, availability, processing integrity, confidentiality or privacy. These are the five Trust Services Criteria categories, which the AICPA describes as outcome-based criteria for judging whether a system's controls provide reasonable assurance that management's objectives are met.

A few points follow from that:

It is an attestation by an independent CPA firm, not a certificate you can look up on a register. Ask for the report itself, not a badge on a website.
Scope is chosen by the vendor. Security is the baseline, but the other categories are optional. Check which ones are in scope, and which systems and locations the report covers. A report on the vendor's corporate platform may not cover the AI feature you are buying.
Type 1 versus Type 2. An assessor firm's explainer describes Type 1 as an attestation of controls at a point in time, covering design and implementation, and Type 2 as covering a longer period and testing whether controls operated effectively. Procurement teams often prefer Type 2 for that reason. Ask for the audit period and how recent it is.
Read the exceptions and the auditor's opinion. Listed exceptions are information, not automatically a disqualifier. Ask how each was fixed.
Check the complementary user entity controls. These are the things the report assumes you will do on your side.
SOC 2 does not speak to AI-specific risks unless the vendor scoped them. It will not tell you how the vendor handles prompt injection or model changes. That is what the next sections are for.

A young vendor may not have a report yet. That is not a reason to stop, but ask what they have instead: a recent penetration test summary, a completed security questionnaire, a documented policy set, and a dated plan for an audit. Be wary of phrases such as "SOC 2 compliant" or "aligned with SOC 2" with no report behind them.

AI-specific security questions

The OWASP Top 10 for LLM Applications (2025 edition) is a practical checklist of what goes wrong in these systems. Its entries include prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation and unbounded consumption. Turn the ones that matter to you into questions:

Prompt injection. How does the system treat instructions hidden in documents, emails or web pages it reads? Has it been tested against this, and by whom?
Excessive agency. If the AI can take actions (send email, update a CRM, run code), what is the least privilege it needs, which actions need human approval, and can it be limited to read-only?
Output handling. Is model output ever passed straight to a browser, database or shell without validation?
Sensitive information disclosure. Can one customer's data surface in another customer's response? How is tenant isolation tested?
Unbounded consumption. Are there rate limits and spend caps, so an abuse case or a runaway loop does not become a bill or an outage?
Supply chain. Which open-source models, libraries and plugins are used, and how are they vetted and updated?

Testing, incident response and model change

Penetration testing. How often, by whom, and does scope include the AI features and integrations, not only the web app? Ask for a summary letter, and what happens to critical findings.
Red-teaming. Has anyone tried to make the system leak data or misbehave, and is there a record of what was found?
Incident response. Is there a written plan, and what is the contractual notification window if your data is affected? Ask for it in hours or days, not "promptly".
Logging. Are prompts, outputs, tool calls and admin actions logged, for how long, and can you export the logs to your own monitoring tools?
Model change management. If the provider swaps or updates the underlying model, how are you told, and is there a regression test before it reaches your users? A silent model change can alter behaviour, accuracy and data handling at once.
Fallbacks. What happens when the model is wrong or unavailable? Human handoff, confidence thresholds and clear failure messages are signs of a mature design.

Regulated data: HIPAA and business associate agreements

If protected health information will touch the product, ask early whether the vendor will sign a business associate agreement (BAA). In general, a vendor that creates, receives, maintains or transmits PHI for a covered entity is acting as a business associate, and HIPAA expects a BAA to be in place first. Whether that applies to your use case, and what the agreement must say, is a question for your privacy counsel.

Practical checks:

Will the vendor sign a BAA, and does it cover the AI features and the model provider in the chain? A BAA with the vendor does not automatically extend to a model API the vendor calls.
Is the specific model service in use covered by the upstream provider's own BAA terms?
Are there features that must be switched off for PHI, such as certain logging or analytics?
How are breaches and subcontractors handled in the agreement?

Using a framework to structure the review

If your organisation wants a shared vocabulary, the NIST AI Risk Management Framework (AI RMF 1.0, released January 2023) is a voluntary framework for managing AI risks, organised around four functions: Govern, Map, Measure and Manage. NIST also published a Generative AI Profile in July 2024. Neither is a vendor certification, but they help you decide which questions belong in the review and who in your company owns the answers. For the internal side, see our piece on AI governance.

Red flags and how to weigh the answers

Answers that avoid the model provider and talk only about the vendor's own infrastructure.
"We don't train on your data" with no contract language, or exceptions buried in terms of service.
A SOC 2 claim with no report, an old audit period, or a scope that excludes the product you are buying.
No way to turn off retention or delete data on request.
No human approval step for actions the AI can take on its own.
Reluctance to share a penetration test summary or incident response commitments.

Not every vendor needs every answer. Scale the review to the data. An internal drafting assistant that never sees customer data needs a lighter check than a support agent connected to your CRM. Write down what you accepted and why, and set a date to review it again.

If you are choosing a development partner rather than a product, the same questions apply, plus who holds the keys, who owns the code and how access is removed at the end. As an example of a design choice worth asking about, our AI support agent case study describes a RAG agent that hands off to a human below a set confidence level. Futurise does not hold a SOC 2 report, so we would not claim one.

Sources

Originally published at Futurise Solutions: https://www.futurisesolutions.com/blog/security-questions-to-ask-an-ai-vendor