AI assistants
Internal AI assistant development services
Providers of internal AI assistants range from those who switch on a general-purpose tool for your staff to those who build assistants connected to your documents and systems. Either way, a careful engagement starts by finding out which tasks staff actually need help with, designs and tests permissions so the assistant only shows people what they may see, supports your data protection work, runs a pilot, helps you write an acceptable use policy and trains staff. Ask how a provider handles each of these before comparing price.
This page covers stages, responsibilities, evidence to ask for, warning signs and ongoing support. LetGetGrow builds customer-facing chatbots and internal AI assistants, with the scope, data sources, cost and timeline set out in a custom quotation.
Illustrative diagram
- Discovery
- Controls
- Build
- Pilot
- Rollout
How the engagement runs
Discovery
Interviews with teams about tasks.
Output: Task shortlist
Controls
Sources, permissions, data rules.
Output: Control design
Build
Assistant connected to approved sources.
Output: Pilot version
Pilot
One team tests; permissions tested.
Output: Pilot report
Rollout
Policy, training, wider access.
Output: Live assistant
Discovery with staff
The provider should talk to the people who will use the assistant, not only managers, to understand where time goes. The resulting shortlist should say why each task was chosen and what risks it carries.
Who does what
| Task | Usually |
|---|---|
| Staff availability for interviews and pilot | Client |
| Permission design and testing | Provider, IT confirms |
| Data protection impact assessment | Client, with provider input |
| Acceptable use policy | Client approves, provider drafts if agreed |
| Training | Shared |
Warning signs
Connects to all drives at once
Restricted files may be exposed.
No permission testing
Access problems are found by staff.
No pilot
Problems reach everyone at once.
No guidance for staff
Sensitive data may be entered.
Evidence of permission testing
Ask the provider to show how it tested that staff in different roles see only what they should, including attempts to find restricted information indirectly. This is the most important test for an internal assistant.
Example: a pilot at an accountancy practice
Illustrative example — not a client case study
Situation: An accountancy practice wants an assistant for technical guidance and internal procedures.
- Discovery shows staff most need help finding internal procedures and summarising guidance notes.
- Client files are excluded; the assistant draws only on procedures and published guidance stored internally.
- A pilot with one team tests permissions and answer quality before rollout.
What this shows: The practice expanded access with confidence that client files stayed out. This example is illustrative.
What you should receive
Design
- Task shortlist with reasoning
- Source and permission design
Evidence
- Permission test results
- Pilot report
People
- Draft acceptable use policy
- Training materials
Supplier terms
Ask which AI suppliers are involved, what they do with prompts and documents, where data is stored and whether it is used to train their models. Check these terms before staff start using the assistant.
Ongoing support
Ask how sources are updated, how permission changes are handled when staff join or leave teams, and what reporting you receive on use and problems.
Ownership
Keep supplier accounts in your organisation's name where possible, and make sure configuration and source lists can be exported if you change provider.
Control design
Before building, the provider should propose which sources the assistant will use, how access will be controlled, what data staff must not enter and how outputs will be labelled. Review this design with your IT and data protection leads. It is easier to adjust controls on paper than after staff have started relying on the assistant.
Training staff
Ask what training is included: a live session, a recording, short written guidance. Good training explains what the assistant is good at, where it can be wrong, what not to enter and how to report problems. It should be short enough that busy staff actually complete it.
General tools or a connected build
For some organisations, a licensed general-purpose AI tool with good guidance meets most needs. Others need an assistant connected to internal documents. A provider should explain which suits you and why, rather than defaulting to the larger project.
What the contract should cover
Scope, control design, pilot and acceptance, data processing terms, support, how permissions are maintained and how you can export configuration if you leave.
The pilot
A pilot with one team should test permissions, answer quality and how staff actually use the assistant. Ask the provider to report what worked, what went wrong, what staff asked that the assistant could not answer and what it recommends changing before rollout. Agree in advance what would justify wider access.
Reporting on use
Ask what the provider will report after rollout: how many staff use the assistant, common questions, unanswered questions and any access issues found. Regular reports show whether the assistant is helping and where sources need improving.
Questions about internal AI assistant development services
What should an internal assistant service include?
Discovery, controls, build, pilot, policy and training.
What is the most important test?
That each person sees only what they are allowed to.
Who writes the acceptable use policy?
You approve it; the provider may draft it if agreed.
Why run a pilot?
To find problems with one team before everyone has access.
What supplier terms matter?
Use of prompts and documents, storage location and training use.
How are staff changes handled?
Agree how permissions update when people move or leave.
Request a Custom Quote
Ask about Internal AI assistant development services
Thank you — your enquiry has been sent.
We have received your message and will reply by email. If you need to add anything, email info@letgetgrow.com.