The demo worked. Production is a different conversation.
An AI PoC proves the idea is possible. It does not prove the system will perform against the client's data, permissions, volume or security review. This is the list of what is usually missing, written so you can use it as a checklist even if you never call us.
If the project belongs to a client of yours, see how we work with consultanciesWhat is almost always missing
- 01
There is no way to know whether it answers well
Without automated evaluations, quality gets judged by trying things by hand and remembering. Every change of prompt, model or data is a gamble. You need test cases with expected answers, run on every change, and a threshold below which nothing ships.
- 02
Nobody can explain a specific answer
When the client asks why the agent said something, you have to be able to reconstruct it: what was retrieved, under whose permissions, which prompt was sent, which model version replied. Without that trace there is no audit and no way to fix the cause.
- 03
The PoC's permissions are not the client's
A prototype usually reads the whole corpus. In production two different users have to see different things, and the filtering has to happen at retrieval, not in the prompt. This is where most projects stall in the security review.
- 04
There is no ceiling on spend or latency
Cost per task and response time go unmeasured until somebody pays for them or suffers them. You need limits, alerts and an explicit decision about what degrades when those limits are hit.
- 05
There is no way back
If the deployment is not reproducible and there is no rollback, every change is irreversible in practice. Infrastructure as code on Azure, separate environments and a tested way back.
- 06
It gets things wrong on its own, with no net
Wherever a mistake costs money or reputation, a person approves the decision. Deciding where that line sits is a business call, not a technical one, and it is best made before the system opens up.
Take it and use it even if you never call us: the printed version lists all six points with room to note which ones you already have covered.
What your client will ask before letting us in.
When the project belongs to an end client, someone on their security team is going to review this. We have it in writing before we start, so you can show it instead of improvising it.
-
Minimum access and agreed environments
We work with exactly the permissions our piece needs, in the environments we agree on. No shared credentials and no open access "to move faster".
-
The client's permissions are enforced at retrieval
Two different users see different things, and the filtering happens when data is retrieved, not by trusting the prompt. This is where most projects stall in the security review.
-
Every answer can be reconstructed
What was retrieved, under which permissions, what prompt was sent and which model version answered. Without that trace there is no audit and no way to fix the cause.
-
Which data AI tools touch, in writing
If third-party models are involved, we define up front which data can be used, where and within what limits, in a format you can hand to your client’s security team.
-
Guardrails and human control where it costs money
Cost and latency limits with alerts, and an explicit boundary: where the agent decides alone and where a person approves. That boundary is a business decision and it is made before the system opens.
-
Confidentiality and non-circumvention, signed
An NDA before you tell us the detail if you need one, and non-circumvention in writing: we sell nothing to your client on our own account, during the project or after it.
-
The code is yours from day one
It lives in the repositories you choose, not ours. At the end there are runbooks, the evaluation report and handover sessions: you do not depend on us to operate what we delivered.
If your client requires a specific approval or a particular official partner, tell us on the first call: better to know then than halfway through the project.
How we approach it
We do not start from scratch. We review what exists, say what we keep and what we rewrite, and close scope by milestones with acceptance criteria written before we start. If the underlying approach will not hold, we say so before signing, not halfway through.
Tell us what is built, on what data, and when it has to be in production. In 30 minutes you get back a risk map and a clear opinion on what is missing.
Three deliveries, and what reached productionShall we talk about your project?
In 30 minutes we review what you want to build or what you already have running, the data, the integrations and what it still needs to remain reliable once users arrive. Whether the project is yours or a client’s, the call is the same.
Free 30-minute review, no commitment. We sign an NDA beforehand if you need it. We reply the next business day.