Skip to main content
Duspat

Service

AI Adoption Services

Working AI is not adopted AI. We design the controls, the enablement and the measurement that turn a deployed capability into a used one.

Who it is for

  • An organisation with AI deployed, technically correct, and usage that has gone flat
  • A leader who has to defend an AI business case at the next budget round
  • A team whose rollout is blocked by a risk or governance question nobody has written down

Problems we solve

What tends to be going wrong.

Deployed, but the work did not change
The tool is live and the process around it is identical. People do the job the way they always did, then paste the result into the assistant afterwards.
Nobody owns quality
No owner for the prompts, the evaluation, or the answer to "is this getting better or worse?" Quality drifts, trust erodes, and usage quietly stops.
The pilot cannot cross into production
A successful pilot with no security review, no support model, no cost ceiling and no owner. It is not blocked by technology; it is blocked by the absence of a plan.

How we help

What Duspat delivers.

01
Use-case discovery and prioritisation
A triaged register scored on value, feasibility and readiness — so effort goes where it pays, and the seductive-but-doomed ideas are named early.
02
AI operating model and responsible practice
Who owns prompts, evaluation, escalation and cost. Acceptable-use boundaries, human oversight, and a control model your risk function will actually sign.
03
Team enablement and change management
Role-based enablement for engineering, analytics and operations — built around how the work is really done, not a generic training deck.
04
Pilot-to-production planning
The unglamorous path from a working pilot to a supported service: security review, support model, cost ceiling, rollback and a named owner.

Typical deliverables

Things you can hold, review and hand to a team.

An adoption assessment and roadmap, then enablement and pilot-to-production support alongside your teams.

  • Use-case register, triaged and prioritised by value and readiness
  • AI operating model — ownership of prompts, evaluation, escalation and cost
  • Acceptable-use boundaries and responsible AI practices
  • Governance and risk control set, agreed with risk and legal
  • Role-based enablement programmes for engineering, analytics and operations
  • Pilot-to-production plan, including the support and cost model
  • Adoption measurement framework tied to the business case that funded the work

Technology fit

What we build this on.

We are independent: no reseller agreements and no partner quotas. If your estate points a different way, we will say so.

AI
  • Claude
  • Amazon Bedrock
  • RAG & embeddings
Enablement
  • Python
  • SQL
  • Databricks
  • PySpark
  • DBT
  • Airflow
Measurement
  • Power BI
  • Apache Superset
  • Looker Studio

Governance & production readiness

Designed in, not added later.

Adoption stalls on unanswered governance questions far more often than on technical ones. Writing the control model down is usually the fastest way to unblock a rollout.

How we run an engagement

  • Which decisions AI is permitted to touch, and which it is not
  • Human oversight and escalation, with named accountable owners
  • Data handling, retention and confidentiality boundaries for AI use
  • Evaluation and quality ownership, so drift is detected rather than discovered
  • Adoption and cost measured against the original business case

Example outcomes

Evidence, not testimonials.

Anonymised and sector-level. Client names are withheld by design — the constraint and the architecture are the parts that carry any information.

  • Multi-sector

    Engineering standards that outlast the engagement

    The constraint. Delivery teams shipping inconsistently, with standards that existed as documents nobody followed.

    Reusable CI/CD workflows, Terraform modules, pre-commit checks and semantic versioning, delivered alongside hands-on mentoring — so the practice stayed with the team after we left.

    • Terraform
    • GitLab CI
    • GitHub Actions
    • Pre-commit
    • SemVer
  • Life sciences

    A governed RAG system for sensitive research data

    The constraint. Retrieval over sensitive research material, where the model must never surface content the user is not entitled to see.

    The control model was designed before the model was chosen: entitlement-aware retrieval, IAM boundaries and audit logging built in from the first commit. The result was a proof of concept that could credibly become production, rather than a demonstration that quietly stalled at the security review.

    • Amazon Bedrock
    • pgvector
    • Lambda
    • API Gateway
    • IAM
    • CloudWatch

Questions

Common questions about ai adoption.

Why do AI projects fail to get adopted?

Usually because the tool was deployed without changing how the work is done. People carry on as before and paste the result in afterwards. The second most common cause is an unanswered governance question that nobody wrote down, which quietly blocks rollout while everyone assumes somebody else is resolving it.

How do you measure AI adoption and value?

Against the business case that funded the work, not against usage counts. Logins prove nothing. We instrument the decisions the AI touches, the time or error rate it changes, and the cost it incurs — so the case can be defended, or honestly withdrawn, at the next budget round.

What does an AI governance or control model contain?

Which decisions AI is permitted to touch and which it is not; acceptable-use boundaries; human oversight and escalation with named owners; data handling and retention rules; evaluation and quality ownership; and audit logging. It is usually a short document, and writing it is usually what unblocks the rollout.

How do you train a team to use AI safely?

With role-based enablement built around your actual systems and data, rather than a generic course. Engineers, analysts and operations staff need different things, and the useful content is nearly always about where the tool is unreliable — not about how to write a better prompt.

Get an honest view of your AI adoption blockers.

A first call is technical, not a sales call. Bring a problem, an architecture, or a stalled initiative.

30 minutes, no pitch deck.