By Karl Lehnert, Director, DevProStudio
Shared AI apps often begin with one person’s clever prompt. They add a few files, connect a tool and demonstrate it at a team meeting. Everyone wants access by Friday.
That is the dangerous moment. A personal workflow can rely on its creator’s judgement, memory and permissions. A shared AI app cannot. As soon as colleagues use it for real work, the prototype acquires users, records, failure modes, support expectations and a bill. It has become a software product, even if it still looks like chat.
Current product coverage is following this shift from personal agents to shared applications. For an Australian SME, the question is not whether sharing is possible. It is what must change before the workflow is dependable enough to share.
Shared AI apps start with a transaction, not chat
A prompt is an instruction. A workflow is a sequence. A business product is a controlled service with an owner and an expected outcome.
Our position at DevProStudio is deliberately unfashionable: the chat interface is usually the least important part. Start with a transaction such as “draft a response from the approved policy library and send it for review”. “Ask our documents anything” is not a transaction; it is an open-ended demo.
This is the line we use to challenge a build: if the team cannot name the transaction, approver and failure state, it is too early to choose a model. That decision also exposes where AI is unnecessary. Conventional code should handle calculations, validation, record updates and approval states where predictable behaviour matters.
Seven product changes that matter
1. Use application identity
A prototype often runs under its builder’s account, silently lending that person’s access to everyone. A shared app needs its own service identity, least-privilege permissions and user-level authorisation before retrieval and before any write action.
2. Treat content as untrusted
Retrieved documents and user text must not rewrite system instructions. Constrain tools, validate parameters and require explicit approval for consequential actions. The OWASP Top 10 for LLM Applications is a useful threat-model baseline for prompt injection, sensitive-information disclosure and excessive agency.
3. Store business state
Chat history is not a system of record. Store the request, source references, model and prompt version, approval status and accepted output. Work should survive a closed browser, changed model or staff handover.
4. Name the human decision
“Human in the loop” is too vague. Name the role, what that person checks and which evidence they see. A reviewer must be able to reject a draft without triggering downstream action.
5. Test outcomes
Fluent prose can be wrong. Build a small evaluation set from representative, de-identified jobs. Score required facts, prohibited content, citations and escalation behaviour whenever the model, prompt, tools or sources change. NIST’s AI Risk Management Framework offers a useful govern-map-measure-manage structure without requiring enterprise theatre.
6. Put hard limits around operation
Cap input size, retrieval depth, tool calls, run time and retries. Queue expensive work. Categorise failures plainly: source missing, permission denied, model unavailable, validation failed or reviewer rejected.
7. Assign an owner
Someone must approve sources, review failures, manage access and decide when the app is no longer worth running. Without an owner, a shared AI app becomes shadow IT with a friendly interface.
A worked implementation pattern
This is a transparent hypothetical, not a claimed client result. Consider a 12-person service business processing 30 emailed job packs a week. It wants each pack converted into a structured draft.
The weak design sends every attachment to a general chatbot under one employee’s account. The stronger design authenticates intake, validates required fields with code and stores the original. Retrieval selects only sources that user may access. The model drafts with citations but cannot send or overwrite anything. A named reviewer accepts, edits or rejects it; only then does deterministic code update the business system.
A pilot might use 20 de-identified historical packs for evaluation and cap live use at 30 a week until quality and review effort are measured. There is no invented productivity percentage. The evidence is the measured acceptance rate, review time, failure categories and cost from that pilot.
This is the product-engineering layer behind DevProStudio’s public work in custom AI agents and workflow automation. It is also distinct from narrower patterns such as production coding-agent controls and AI-assisted delivery checks.
Cost per accepted transaction
Do not budget from token price alone. Count discovery and build hours, model and integration usage, human review, support, evaluation and change costs. Compare options with:
transactions × automated run cost + review hours × loaded staff rate + support allowance
For the 30-pack example, assume 120 monthly transactions, an internal allowance of A$0.50 per run, 10 review minutes at a loaded A$60 an hour, and four support hours at A$150 an hour. The planning total is A$1,860: A$60 usage, A$1,200 review and A$600 support. These are illustrative assumptions, not market rates or a DevProStudio quote. Replace them with observed usage, current OpenAI API pricing or Anthropic pricing, and your own labour rates.
The arithmetic reveals the operator lesson: review can cost far more than tokens. A “cheap” model that doubles checking time is expensive. Start capped, then budget from accepted transactions rather than demo traffic.
Australian privacy and security
Map what personal information enters the app, why it is needed, where it travels and who can retrieve it. The OAIC’s Australian Privacy Principles guidelines are the primary reference. APP 11 requires reasonable security steps and addresses destruction or de-identification when information is no longer needed.
Do not treat the A$3 million turnover threshold as a blanket exemption. Coverage depends on the organisation and its activities; confirm your position. For covered organisations, the Notifiable Data Breaches scheme requires notification when a personal-information breach is likely to cause serious harm.
Australia’s privacy framework is changing. The Privacy and Other Legislation Amendment Act 2024 introduced reforms in stages, so check current OAIC guidance at deployment rather than relying on a static checklist. In the product itself, minimise inputs, define retention, control exports, review subprocessors and log sensitive-record access. “Enterprise” branding is not a data-flow assessment.
Five questions before sharing
- Can we name the transaction and owner in one sentence?
- Does each user see only permitted sources and actions?
- Can a reviewer inspect evidence and stop a bad outcome?
- Can we rerun evaluations after every material change?
- Can we calculate cost per accepted transaction and cap usage?
If any answer is no, keep the workflow in controlled pilot mode. More users will amplify the missing control.
FAQ
What is a shared AI app?
A shared AI app is a multi-user business application using AI inside a defined workflow, with identity, permissions, durable records, testing, limits and an accountable owner.
When should a personal AI workflow become a custom app?
Build one when several people repeat the workflow, business data or system actions are involved, and outputs need review or audit. Keep occasional low-risk experiments personal.
How do you control hallucinations?
Constrain the task, retrieve approved sources, require citations, validate structured fields and route uncertain or consequential outputs to a named reviewer. Retest after material changes.
How much does a shared AI app cost to run?
Calculate model and infrastructure usage, service fees, review time, support, evaluation and change costs. Compare alternatives by cost per accepted transaction with explicit caps.
Build dependable shared AI apps
The winning move is not sharing the prompt sooner. It is turning one useful transaction into software your team can permission, test, stop and afford. If your prototype is ready for that step, talk to DevProStudio about the architecture and evaluation plan.