Skip to content

Optimization and adoption

Once your AI spend is attributed, the same graph powers two more decisions: where can we spend less without losing quality? and which teams have genuinely adopted AI, and which need enablement? The Optimization surface turns attributed spend into reviewable savings recommendations. The Adoption surface reads consumption as cohort-level adoption intelligence — always privacy-safe, never surveillance. This page covers both.

Optimization

Optimization (Optimize → Optimization) is a queue of recommendations — specific, evidence-backed opportunities to reduce AI cost without degrading the workload that depends on it. Each recommendation is a reviewable object you act on deliberately; Venturi never changes your systems on its own.

Recommendations are advisory by default

Venturi is read-only on your environment. An optimization recommendation is a proposal — it never reaches into your AI configuration to apply a change. A recommendation only takes effect when a human accepts it and enacts it in their own systems. This is the same fail-safe posture as the rest of the platform: read deeply, write nothing.

What a recommendation contains

Each recommendation names the opportunity, the spend it touches, the estimated savings, and — crucially — the evidence that the change is quality-equivalent for the specific workload. Every recommendation includes:

  • Expected savings or risk reduction;
  • The affected team, service, and model;
  • The supporting evidence and its confidence;
  • Operational risk notes;
  • Any approval and rollback requirements.

You can open the evidence drawer behind any recommendation to see exactly which invocations it's based on and why the proposed change is safe.

Typical recommendation classes:

Recommendation What it finds
Model right-sizing A workload running on an over-provisioned model where a cheaper one is verified equivalent on that workload.
Price-reversal avoidance Cases where a "cheaper" reasoning model actually costs more because it expands its thinking tokens — surfaced because Venturi costs on the served model with measured tokens, never the requested model or a list price.
Idle / redundant usage Spend that delivers little value and can be retired.
Provider / tier mix Opportunities to shift workloads across providers or model tiers.
Commitment opportunities Where a usage commitment would lower effective cost.

Reviewing and accepting a recommendation

Recommendations move through a clear lifecycle, with collaboration at each step:

graph LR
  A[Recommended] --> B{Review}
  B -->|Accept| C[Accepted]
  C --> D[Applied · by you, in your systems]
  B -->|Dismiss| E[Dismissed · reason recorded]
  D --> F[Reverted · optional]
  • Comment and assign on a recommendation like any workflow object — route it to the team that owns the workload.
  • Accept a recommendation to mark it for enactment; dismiss it with a reason code if it isn't right. High-impact recommendations can require a second approver by configurable threshold.
  • Apply the change in your own systems, then mark it applied. You can revert at any time.

Every decision — accept, dismiss, apply, revert — writes a governance trail so finance and engineering can reconstruct the basis later.

Verified savings

When a recommendation feeds a savings-share commercial agreement, the savings are only ever counted once they are verified and realized against a frozen, usage-normalized counterfactual baseline — so organic growth is never billed as savings, and a recommendation you accepted but didn't realize is never charged for. See the billing basis in governance & exports and the full model in optimization & governance.

Adoption

Adoption (Optimize → Adoption) reads the same attribution graph as adoption intelligence: which parts of your organization have genuinely embedded AI, and which lag. It's the second projection of the graph — no second product, no new data collection — and it answers the question a CTO, CHRO, or program sponsor brings to a board: is our AI investment actually taking hold, and where are the enablement gaps?

Cohort-only, always

Adoption is reported at the cohort level — by team, function, role, or tenure — never as individual surveillance.

Privacy is built in, not bolted on

  • Minimum cohort size is k = 5. Any cohort smaller than five is suppressed and rolled into its parent unit — never errored, never shown. Differencing across overlapping cohorts to reconstruct an individual is blocked.
  • Individual-level views are never a UI toggle. They are off by default and, where ever permitted at all, require written legal sign-off and a data-processing amendment. They are hard-disabled in the EU regardless of any setting.
  • Venturi never acts against a person. It never notifies, blocks, or enforces against a resolved individual. Employees whose usage is attributed have full data-subject rights and are not platform users.

This cohort-only posture is what keeps adoption intelligence out of profiling — and it is non-negotiable. See data privacy & retention and data-subject rights.

What you can see and do

  • Adoption depth by cohort — how deeply each team, function, or tenure band has adopted AI, with the same honest signal-type basis everywhere: whether a figure is direct, inferred, or estimated.
  • Real underuse vs. visibility limits — the surface distinguishes a team that genuinely isn't using AI from a team Venturi simply can't see yet, so you act on reality, not on a coverage gap.
  • Enablement gaps — the cohorts where adoption lags, so enablement budget can follow traction instead of guesswork.
  • Board-ready reporting — save an adoption view and schedule it as a report; it renders for each recipient under their own access, with cohorts suppressed and EU rows respected.

Read the basis before you act

An adoption figure marked inferred or estimated is a directional signal, not a hard count. The surface always names the basis so a leader presenting to the board distinguishes a measured fact from a modelled estimate — and never mistakes a visibility limit for genuine underuse.

Alerts and budgets

Both surfaces feed Alerts (Optimize → Alerts): you can alert on a budget threshold, a spend anomaly, a new high-value optimization opportunity, or an adoption shift. Budgets and the policies behind these alerts are configured in governance & exports.

Next steps