AI proof of concept
One use case, built on your own data inside your estate with agreed security controls, and a measured result with a clear recommendation on whether to scale.
Discuss a proof of conceptOne use case, on your own data
A generative AI proof of concept is only worth doing if it answers a real question: will this work on our documents, for our people, within our rules? So we build one use case, on your own data, inside your own estate.
Use cases that often suit a first LLM proof of concept in regulated organisations:
- Answering staff questions from policies, procedures and guidance.
- Finding and summarising the relevant parts of long reports or case files.
- Drafting first versions from templates, precedent and past work.
- Pulling named fields out of contracts, forms or correspondence.
These are examples of the kind of work that suits a first test, not a list of past projects.
Scope, decisions and what you receive
In scope
- One use case, on an agreed set of your documents, for a small group of named users.
- Built in your environment, defined in code, behind your identity provider, with access logged.
- Measurement against success measures agreed before the build.
Decisions required
What your organisation decides, with our advice:
- The use case, and the question the proof of concept must answer.
- The documents it may read and the people who will test it.
- The measures and thresholds, agreed before anything is built, including the result that means stop.
- What happens to the build and its data if the answer is stop: keep it, archive it or delete it.
Delivered
- A working application in your estate.
- The measured result against each agreed measure, with examples of where it went wrong.
- A recommendation to continue, change or stop, with the reasons.
- What scaling would need in compute, support and governance.
Not included: a service for the wider organisation, which needs its own operational readiness review. That is a platform build.
Scope and fee are agreed in writing before any work starts.
How the decision is made
The decision is set before the build, so the result cannot be argued into shape afterwards. Continue when the agreed measures are met and your security review has no blocking findings. Change when the measures are close and the gaps have a clear cause, such as missing documents or a poorly framed question. Stop when the measures are missed for reasons a larger build would not fix. Stopping is a useful result: it costs far less than learning the same thing after a full build.
Built with the controls you would need later
A demonstration that cannot pass your security review does not prove anything. So the scope names the security and deployment controls the pilot uses: in your environment, defined in code, behind your identity provider, with access logged. If the answer is to continue, the build can be kept and extended rather than rebuilt. Running it as a service for the wider organisation needs its own operational readiness review.
If you already have a prototype, see the ten decisions between it and an operated platform.
How we measure the result
Success measures are agreed before anything is built, so the result cannot be argued into shape afterwards.
Answer quality
Answers to a set of real questions are checked by the people who know the right answer.
Time
How long the task takes with the tool, compared with how it is done today.
Failure
Where it goes wrong, how often, and whether the errors are easy to spot.
Running it at scale
What the use case would need in compute, support and governance if it went further.
You receive the measured result and a recommendation: scale it, change it, or stop.
Choosing the right use case
Good first use cases share five traits: the task comes up often, the documents exist and someone owns them, a person can check the answer, a wrong answer is caught before it causes harm, and someone in the business wants it to work. If no use case clearly fits, start with a readiness assessment, which ranks your options by value and risk.
Where to go next
Scale it into a private AI platform
Take a proven use case to a platform that serves many.
How RAG works on your documents
The retrieval behind most document use cases.
Private AI questions answered
Accuracy, hardware, cost and UK GDPR.
Talk to us about a proof of concept.
Have a use case in mind? Tell us what it is, which documents it needs and who would judge the result.
Thank you. Your request is on its way. We will reply from info@tlgsolutions.co.uk to arrange a first discussion.
That did not send. Please email info@tlgsolutions.co.uk instead, and we will reply from there.