ENT.01
AI Readiness Assessment
A structured assessment of whether your data, systems and processes can support the AI you want to build.
Open pageFor Enterprise · 5 pages
Enterprise AI that actually ships.
Most enterprise AI never leaves the pilot. Not because the model was wrong, but because nobody owned integration, security review, evaluation or the change in how people work. That gap is the job.
Introduction transcript. Client: Our pilot works. Why can’t we ship it? Qubi: There’s a little gap. Let’s build across it. Qubi: Integration, security review, evaluation, and your team’s way of working. Client: So we need more than a clever model? Qubi: We need a system somebody can own and operate. Qubi: Let’s make the next step a real one.
At a glance
Built to get through procurement.
- 01 Where it stalls
- Enterprise AI stalls on integration, security review and evaluation that nobody owns. The model is rarely the reason.
- 02 Security review
- Designed in from day one: the deployment target, approved models, logging and the data path are decided before any prompt is written.
- 03 Where it runs
- Deployed into a client VPC on AWS, Azure or GCP, or on open-weight models on your own hardware where no data may leave the perimeter.
- 04 Who owns it
- You do. Code goes into your repositories, infrastructure is defined as code in your accounts, and any fine-tuned weights are yours.
WHERE ENTERPRISE AI STALLS
Three places it stops.
-
01 · The pilot
The pilot has no route to production
A demo built against a CSV export cannot reach the system of record. Nobody scoped the integration, the permissions model or the failure path — so the pilot succeeds and then stops.
-
02 · The review
Security review arrives too late
The architecture is chosen, then infosec asks where data flows, which sub-processors are involved and how prompt injection is handled. The answers require a rebuild.
-
03 · The evaluation
Nobody can say whether it works
Without an evaluation set agreed up front, “is it good enough” becomes a matter of opinion, and the loudest sceptic in the steering committee decides.
HOW WE APPROACH IT
Design for the security review on day one.
The constraints that kill enterprise AI projects are known in advance: where data may live, which models are approved, what has to be logged, who signs off on an automated decision. Treating them as an afterthought almost always means rework; treating them as the initial design input is close to free.
So we start from the deployment target and work backwards. If inference has to run in your VPC, that decides the model options before any prompt is written. If decisions get audited, the trace format is designed before the agent is. If your data cannot leave the EU, that is settled in week one rather than discovered in month four.
The result is usually a less exotic system than a greenfield demo — and one that reaches production, which is the only comparison that matters.
- If inference runs in your VPC
- That decides the model options before any prompt is written.
- If decisions get audited
- The trace format is designed before the agent is.
- If data cannot leave the EU
- That is settled in week one, not discovered in month four.
Three phases
Discovery, pilot, production — each ends in something you can check.
01 · Phase 01 · Discovery
Systems, data, constraints
The systems, the data, the constraints, and the decision the AI is meant to support. Ends with a written architecture and an evaluation plan you can circulate internally.
Systems and data mapped, not assumed
The decision the AI supports, written down
A written architecture and an evaluation plan
02 · Phase 02 · Pilot
A narrow slice, against real systems
A narrow slice built against real systems and real data — not a sandbox. Measured against the evaluation set agreed in discovery.
Built against real systems, not a sandbox
Measured against the agreed evaluation set
Access provisioning planned as the critical path
03 · Phase 03 · Production
Monitored, gated, handed over
Monitoring, regression gates, runbooks and handover. Either your team owns it or we support it under a defined arrangement — decided explicitly, not by default.
Monitoring and regression gates in CI
Runbooks and a documented handover
Support under a defined arrangement, or none
WHAT A SECURITY REVIEW RECEIVES
What a security review receives.
Each row is a part of the answer to the vendor-review question below, with its status today.
-
Architecture document
Data flows, storage and retention.
Included -
Sub-processor list
The list for any third-party model provider involved.
Included -
Prompt-injection approach
Our approach to prompt injection, tool permissioning and secrets handling.
Included -
Security questionnaire responses
Completed responses to your questionnaire. Where a control is not yet in place, we say so explicitly rather than answering aspirationally.
Gaps stated, not hidden -
Data processing agreement
We can sign a DPA.
Available on request
Drawn from the answer to “What do you provide for our vendor security review?” below.
WHAT WE BUILD FOR ENTERPRISE
What we build for enterprise.
01
Retrieval over internal knowledge
Search and question-answering across policies, contracts, tickets and documentation, with permissions honoured per user and every answer traceable.
Retrieval systems
-
02
Agents inside existing systems
Agents that act in your CRM, ticketing and ERP through scoped, audited tool access rather than screen-scraping or a parallel database.
Autonomous employees → -
03
Regulated decisioning
Decision support where the reasoning has to be reconstructable months later, with immutable traces and mandatory human review above a materiality threshold.
Fintech risk agents → -
04
Legacy integration
Reaching the data inside systems that cannot be replaced, without a migration programme that outlives the AI project.
Legacy modernisation →
- Building software since
- 2006
- Based in
- Barcelona
- Model stance
- Agnostic
- Code ownership
- Yours
Facts about how we work, not measured client outcomes.
Questions
What enterprise buyers ask first.
Can you deploy inside our own cloud environment?
Yes. We deploy into a client VPC on AWS, Azure or GCP, and we can run entirely on open-weight models on your own hardware where no data may leave the perimeter at all. The trade-off is real — self-hosted open models are behind frontier APIs on the hardest reasoning tasks — so we scope which parts of a system genuinely require that constraint rather than applying it uniformly.
What do you provide for our vendor security review?
An architecture document covering data flows, storage and retention; the sub-processor list for any third-party model provider involved; our approach to prompt injection, tool permissioning and secrets handling; and completed responses to your security questionnaire. We can sign a DPA. Where a control is not yet in place we say so explicitly rather than answering aspirationally.
How do you handle model providers as sub-processors?
Any external model provider is a sub-processor and gets named as one. We configure zero-retention endpoints where the provider offers them, keep the provider list explicit in the architecture document, and design so a provider can be swapped without rewriting the system — which matters both for procurement and for the day a model gets deprecated.
Who owns the code and the models?
You do. Code is delivered into your repositories, infrastructure is defined as code in your accounts, and any fine-tuned weights are yours. We do not retain a runtime dependency on us; if you want your team to take over at the end of an engagement, that is a supported outcome we plan for rather than a threat.
How long does an enterprise engagement take?
Discovery is typically two to four weeks. A pilot against real systems is usually six to ten weeks depending on how many integrations are in scope and how long access provisioning takes — which is genuinely often the critical path. Production hardening adds four to eight weeks. Anyone quoting you a firm figure before seeing your systems is guessing.
FOR ENTERPRISE — ALL PAGES
Every enterprise page.
-
-
ENT.02
From AI Pilot to Production
Why most enterprise AI pilots never ship, and the specific gaps that stop them.
Open page -
ENT.03
Enterprise AI Governance
Policy, oversight and controls for AI systems that make or influence decisions.
Open page -
ENT.04
Procurement & Security Review
What we provide for vendor security questionnaires, DPAs and architecture review.
Open page
Hire your first
AI employee.
Tell us the job you would hand over if you trusted a machine with it. In one 30-minute call we will tell you whether it should, what it would take — and if it should not, we will say so.
Pick the job — the form arrives ready for it
