unclouded.ai

The discovery conversation

Almost every engagement starts the same way, with a handful of questions that have nothing to do with AI:

  • What work are people doing manually?
  • What information do you already have, and where does it sit?
  • What data cannot leave your network?
  • What data can be processed elsewhere?
  • How quickly does the result actually need to be available?
  • What systems need to receive the result?
  • How much human review is appropriate given the consequences?
  • What happens when a better model becomes available?

The answers determine the architecture. Frequently they also determine that one of the three things you were considering is worth doing and the other two are not, which is a useful outcome by itself.

What we actually deliver

Engagements are shaped around what you need rather than sold as tiers, but the work tends to fall into these:

Discovery and architecture

  • Workload evaluation
  • Privacy boundary definition
  • AI architecture
  • Pipeline design
  • Model evaluation
  • Infrastructure planning
  • GPU and hardware sizing
  • Cost modelling

Implementation

  • Local model deployment
  • Processing pipelines
  • Worker development
  • Search and index build
  • Integration with existing systems
  • Data migration
  • Custom automation
  • Infrastructure setup

Ongoing

  • Software and model updates
  • Security patching
  • Monitoring
  • Job and queue management
  • Storage and backup
  • Performance tuning
  • Workflow improvements
  • Integration support

Second opinions

A specific and useful thing we get asked for: you have a vendor proposal, or an internal plan, and you would like somebody with no stake in it to look at whether the numbers make sense.

Common findings, in roughly descending order of frequency:

  • Hardware sized for real-time when the work is overnight batch
  • A per-seat SaaS price for a job that runs four times a month
  • An architecture that depends permanently on one vendor's API
  • No answer to "where does the data go" beyond "our cloud"
  • A chatbot proposed for a problem that is really a search problem
  • Nothing about what happens when the model is deprecated

Rescuing a pilot

The other common starting point: something works on one person's machine, everyone is impressed, and it has been stuck there for eight months.

Turning that into production is mostly unglamorous engineering — job queues, failure handling, storage, monitoring, access control, updates, and a normalized output format so the next model change is not another eight months.

It is also usually less work than rebuilding, because the hard question — is this useful? — has already been answered by the pilot.

What would you use AI for if your data stayed under your control?

Tell us what you are trying to accomplish. We will help work out what should run locally, what can run elsewhere, and what technology actually makes sense.