Custom GPT assistants over your own knowledge, with permissions that hold
The hard part is not making an assistant answer questions about your documents. It is making sure it never answers the wrong person's question with the right document.
What is custom GPT solutions?
Custom GPT Solutions are private assistants built over an organisation's own documents and systems, with role-based access so each person receives answers only from material they are permitted to see. They suit Australian organisations whose staff lose hours hunting through intranets, shared drives and policy libraries for information that already exists somewhere.
Get a fixed written quote- Typical timeline
- 5 to 10 weeks
- What drives cost
- How much of your own material has to be prepared, how many systems it connects to, and how many staff will use it.
- Best for
- Teams repeatedly searching internal documents for known answers
- You own
- The index, the prompts, the evaluation set and the usage logs
- Built with
- Private retrieval, role-based access control, citations, evaluation sets
Your handover
Permissions are the whole game
The classic failure is quick and hard to undo. Someone points an assistant at the entire shared drive, and within a week a staff member asks an innocent question and receives a helpful summary of the remuneration spreadsheet, a legal matter, or the redundancy plan that had not been announced. The assistant did nothing wrong. It was given the documents and asked to be useful, and no amount of prompt instruction reliably prevents it.
- 01Private assistant deployed on infrastructure you control
- 02Connectors to your document systems and intranet
- 03Permissions enforced at query time and mirrored from source
- 04Document hygiene pass with authoritative versions identified
- 05Citations to the source document and section on every answer
- 06Evaluation set of real staff questions with approved answers
- Usage and unanswered question reporting
- Access and query audit logging held in Australia
- Content ownership model and update routine
More on permissions are the whole game
The fix is architectural. Permissions have to be enforced at query time against the source system, so the assistant retrieves only what that specific user could open themselves. Filtering after retrieval is not sufficient, because the material has already entered the context and can leak through a summary. We also mirror permission changes: when someone leaves a project, their access to those documents through the assistant ends at the same moment it ends everywhere else. That plumbing is unglamorous and is the majority of the engineering on these builds.
Filtering after retrieval is not sufficient, because the material has already entered the context and can leak through a summary.
Your shared drive is the project, and citations keep it honest
Assistants inherit the state of your documents. If the 2019 leave policy is still sitting in a folder called Archive that was never actually restricted, the assistant will quote it with total confidence to a new starter. Superseded procedures, three versions of the same template and drafts nobody deleted are the real accuracy problem in almost every internal deployment, and no model resolves them for you. Part of every build is a document hygiene pass: identify the authoritative version per topic, exclude the rest from the index, and give someone ownership of keeping it that way.
Citations are the counterweight
Citations are the counterweight. Every answer links to the specific document and section it came from, so a person can verify in seconds rather than trusting prose. This matters for adoption more than for accuracy. Staff extend trust to these tools slowly and withdraw it instantly, and a single confidently wrong answer circulated in a team chat can end usage across a department. Citations let people check cheaply, which is what keeps them using it. We also run an evaluation set of real staff questions with approved answers, scored on every change, so quality is measured rather than assumed.
How the engagement runs
How we build a private assistant
We start with a single team and a single body of knowledge. One department, real questions, measured outcomes, then expansion. Organisation wide launches generate a burst of curiosity and a long decline, because nobody owns the content behind them and the answers slowly rot.
- 01Pick the pilot teamThe group losing the most time to searching, with a nameable owner for the content
- 02Question inventoryWhat staff actually ask, collected from help desk tickets and a week of observation
- 03Source connectionDocument systems, intranet and any line of business data, with permissions read from the source
- 04Document hygieneAuthoritative versions identified, superseded and duplicate material excluded from the index
- 05Retrieval tuningChunking and search tested until the right passage is found for the inventory questions
- 06Access controlPermissions enforced at query time and mirrored as they change in the source systems
- 07Evaluation setReal questions with approved answers, scored automatically before every release
- 08Pilot and reviewUsage and unanswered questions monitored weekly, content gaps sent back to the owner
Two decisions on your side that keep the project moving
Roughly half of what we build is not the assistant. It is connectors, permission mapping, document cleanup and the evaluation harness. Clients expecting the work to be prompt writing are usually surprised by that split, so we set the expectation in the first conversation rather than at the first invoice.
Choose the right level
Buy the vendor assistant, configure one, or build it
Plenty of organisations should not build anything. If your content already lives in one major productivity suite and your requirements are ordinary, the assistant bundled with that platform will do a reasonable job, inherit the permissions correctly and cost you nothing to maintain. We say this early because it disqualifies a fair share of enquiries, and finding out after a build is considerably more expensive.
Option
01
Assistant bundled with your productivity suite
Suits
Content already in one ecosystem, standard permissions
The trade off
Little control over retrieval quality, residency or behaviour
02
Configured third party platform
Suits
A few systems, moderate customisation, small internal IT team
The trade off
Ongoing licence per user and your knowledge sits with another vendor
03
Custom build on your infrastructure
Suits
Knowledge across many systems, strict residency or unusual access rules
The trade off
Higher upfront effort and you own the maintenance
04
Self-hosted models
Suits
Sovereign or contractual requirements that rule out external inference
The trade off
Meaningfully weaker capability and real infrastructure cost
How we work this out during scoping
Building is justified when your knowledge is spread across systems that no single vendor covers, when you need Australian data residency the vendor cannot offer, when access rules do not map neatly onto the vendor's model, or when the assistant must take actions rather than only answer. Below is the comparison we work through, and it is worth doing before anyone commits to a platform.
Data residency and the Australian Privacy Principles
Internal knowledge bases hold employee records, client files, commercial terms and sometimes health or financial information. Under the Privacy Act 1988 you remain accountable for that material even when a third party processes it, and APP 8 treats sending it to a model hosted overseas as a cross border disclosure. APP 11 requires you to secure what you hold, which here means encryption, least privilege access, and logging of who asked what and which documents were returned.
The index, the logs and the documents stay in Australian infrastructure
So we make the data path explicit rather than implicit. The index, the logs and the documents stay in Australian infrastructure. Where inference can run in an Australian region we use it. Where a client needs capability only available offshore, we document exactly what leaves, under which contractual terms, and whether the provider excludes your inputs from training, so your privacy officer can make an informed decision instead of an assumption. Organisations in government and regulated sectors often have procurement rules that settle this question for them, and it is far cheaper to know that in week one.
When a custom GPT is the wrong fit
If your organisation has thirty staff and one shared folder, this is a search problem and better search will solve it faster. If your documents are chaotic, fix that first, because an assistant over bad content produces confident wrong answers and destroys trust in one week that takes a year to rebuild. If leadership wants it because competitors have one, the pilot will produce polite usage figures and no measurable saving.
Cost at volume deserves a mention too
Cost at volume deserves a mention too. Every question sends retrieved passages plus the conversation to the model and is billed by the token, so a well used assistant across hundreds of staff is a recurring operating cost rather than a one-off project. That is usually justified, but it should be modelled honestly before rollout rather than discovered on a bill. And if what staff actually need is to complete a task rather than find an answer, the better build is an agent with tool access or a proper internal portal, and the question of which one belongs in scoping rather than after launch.
How we scope it
Four ways to scope your Custom GPT Solutions project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Proof of value
One use case, evaluated honestly before it goes near a customer
Fixed written quote, agreed before work starts
- Private assistant deployed on infrastructure you control
- Connectors to your document systems and intranet
- Permissions enforced at query time and mirrored from source
Production build
In production, with a human approval step and an evaluation set
Fixed written quote, agreed before work starts
- Everything in Proof of value
- Document hygiene pass with authoritative versions identified
- Citations to the source document and section on every answer
- Evaluation set of real staff questions with approved answers
Embedded platform
Built into the product rather than bolted onto it
Fixed written quote, agreed before work starts
- Everything in Production build
- Usage and unanswered question reporting
- Access and query audit logging held in Australia
- Content ownership model and update routine
Custom GPT Model care
Monitoring, evaluation and retraining as the inputs drift
Rolling monthly, quoted in writing
- Evaluation set rerun as the model and the inputs change
- Cost and quality reported monthly, not assumed
- Prompt, tool and guardrail changes as the work shifts
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
How long does a custom GPT project take?
Usually 5 to 10 weeks for a pilot with one team. Connecting sources and mapping permissions takes the most time, particularly where document systems have inconsistent access rules. Document cleanup runs in parallel and depends on your team, since only people who know the content can say which version is authoritative. Expansion to further teams is faster.
What does it cost to build and to run?
The build is quoted in writing after scoping, driven by how many systems connect, how complicated your permission model is and the state of your content. Running cost is model usage billed per token plus hosting, so it scales with how much staff use it. We report cost per active user during the pilot so the rollout decision is based on real figures.
Who owns the assistant and the data behind it?
You own the index, the connectors, the prompt configuration, the evaluation set and the logs, all running in your cloud accounts. Your documents are never used to train a shared model. If you move to another partner or bring it in-house, everything is already in your environment and the handover is documentation rather than migration.
How do you stop it exposing documents people should not see?
Permissions are enforced at retrieval time against the source system, so the assistant can only ever see what that user could open directly. Access changes propagate as they happen rather than at the next reindex. We test this deliberately before launch by asking sensitive questions as low privilege users, and the results form part of the acceptance criteria.
What happens after the pilot?
We review usage, the questions that went unanswered and the answers staff corrected. Unanswered questions are usually content gaps rather than model problems, and they go back to the content owner. Expansion happens team by team, each with its own sources and its own owner. Somebody in your organisation needs to hold that responsibility ongoing, and we say so up front.
Can it answer from our systems as well as our documents?
Yes, where those systems expose an API. Common additions are a project system, a CRM or a job management tool, so staff can ask about a live record rather than a policy. That is more involved than document retrieval because permissions and freshness both matter more, and we usually add it in a second phase alongside API work rather than in the pilot.
Related services
Find out whether you should build this at all
Tell us where your knowledge lives and who is allowed to see what. We reply within one business day, and if the assistant bundled with your existing platform would do the job we will tell you that first.