Language models are easy to demo and hard to put behind a business process.
The demo takes an afternoon. The work is everything after it: retrieval that respects who is asking, evaluation that runs before release, a record of what the model saw, and a cost line that does not surprise you in month four.
- typical first engagement
- 6–10 weeks
- starts with
- Use-case triage
- we deploy into
- Your cloud account
Most AI projects stall in the same three places.
The pilot answers well on the twelve questions someone thought to test, then meets a real user and quotes a document they were never allowed to open. Nobody wrote down what "good" meant, so there is no way to tell whether a change made it better or worse. And the running cost was estimated from the demo, which used a fraction of the traffic.
None of these are model problems. They are systems problems, and they are the ones we take on. We are not interested in whether a model can write a summary — it can. We are interested in whether the summary is safe to show the person who requested it, and whether you can prove it a year from now.
What the practice covers
Engagements usually combine three or four of these. We would rather do fewer of them properly than list all six on a slide.
Retrieval systems (RAG)
Your documents indexed with the access controls they arrived with. A query carries the caller's identity end to end, so an answer can never quote a record its reader could not open on their own. Retention rules apply to the embeddings, not just the source files.
Evaluation harnesses
A test set built from your real questions and your real wrong answers, scored automatically on every change. This is the piece almost everyone skips, and it is the reason most teams cannot say whether last week's prompt change helped.
Process automation
Classification, extraction, and routing for the work that currently moves through a shared mailbox. We instrument the manual path first — if we cannot measure how long it takes today, we cannot tell you whether we improved it.
Predictive analytics
Forecasting and risk scoring validated against your own failure history, not a benchmark. If the historical data will not support a useful model, we say so in week two rather than building one that looks convincing and is not.
AI governance
Model inventory, approved-use policy, an audit trail linking every output to its inputs and prompt version, and the documentation an examiner or insurer will ask for. Written to survive the person who set it up leaving.
Model routing and cost control
Per-feature spend limits, fallback between providers, and caching where the same question gets asked forty times a day. Provider choice stays a configuration decision rather than an architectural one.
How an AI engagement runs
The order matters. Evaluation is built before the thing being evaluated, because retrofitting it never happens.
Use-case triage
We rank candidate use cases by what a wrong answer actually costs and how well the ground truth is documented. Most lists come back with two viable candidates and several that need a data fix first. You get the ranking either way.
Evaluation before build
We assemble a scored test set with your subject-matter experts — including the questions that should return "I don't know". This becomes the release gate for everything that follows.
Pilot with a named group
A real user group, real data, and a feedback path that lands in the eval set. Access controls are wired from the first day, not added before launch.
Release and monitor
Rollout behind a flag, with drift, latency, and spend on the same dashboards as the rest of your infrastructure. Regressions page a person.
Cutting a referral backlog without touching the clinical record
Drawn from engagements the founders ran at previous employers, before CloudMind existed. It is not a CloudMind client reference, and we will not present it as one.
Inbound referrals arrived as faxed PDFs and unstructured email. Three coordinators triaged roughly 400 a week by hand, and the backlog grew every month the team was short-staffed.
What we did
- Extraction over the referral documents, scoped to a service account with read-only access and no write path into the EHR
- A scored test set of 600 historical referrals, including the ambiguous ones the coordinators disagreed on
- Confidence thresholds tuned so anything uncertain routes to a human rather than guessing
- Full audit trail linking each triage decision to the source document and prompt version
The number that mattered wasn't the accuracy rate. It was that the coordinators trusted the queue enough to stop double-checking it.
- Referrals auto-triaged
- 72%Referrals auto-triaged
- Backlog, down from 11
- 3.5 daysBacklog, down from 11
- PHI written to a third party
- 0PHI written to a third party
[PLACEHOLDER STAT] Figures are illustrative. Replace with real numbers from the founder’s prior engagement, cleared by that employer and with a contactable reference — or remove the section until one exists.
What people ask before they sign.
If your question is not here, ask it directly — we would rather answer it now than in month three.
Will our data be used to train someone else's model?
No. We deploy into your cloud account under enterprise agreements with zero-retention terms, and we confirm those terms in writing before any data moves. If a provider cannot offer them for your use case, we tell you and pick a different one.
Can we run this without sending data to a third-party provider at all?
Yes, with a trade-off we will be direct about. Open-weight models running in your own environment are meaningfully behind the frontier providers on hard reasoning, and you take on the GPU cost and the operational burden. For extraction, classification, and routing, that gap often does not matter. For open-ended reasoning over messy documents, it usually does.
How do you stop it inventing things?
Three ways, in order of how much they help. Retrieval means answers are grounded in your documents rather than the model's memory. The evaluation set includes questions that should return "I don't know", and we score refusals as correct. And confidence thresholds route uncertain cases to a person. None of these gets you to zero — the design assumption is that a wrong answer will occur, so the question is what it costs when it does.
What does this cost to run once it is live?
It depends on traffic and how much context each request carries, and any number we gave you here would be fiction. What we commit to is that you will have a per-feature spend estimate before the build starts, spend limits enforced in code, and a monthly figure you can attribute to individual features rather than one line labelled "AI".
What happens if the model provider changes their pricing or API?
Provider choice sits behind a routing layer, so switching is a configuration change and a re-run of the evaluation set rather than a rebuild. We do not promise the switch is free — output quality shifts between models, which is exactly what the eval set is there to measure.
Do we need a data warehouse before we start?
Usually not for document-based use cases. For predictive work, yes — and if the historical data is not there, the honest answer is that the first project is a data project, not an AI one. We would rather say that in week two than bill you for a model that cannot work.
Start with a ai consulting assessment.
Two weeks, fixed fee, no commitment to a build. You end up with a written account of what you run today and a costed plan — yours to keep even if you take it elsewhere.