Jason Belnick

Enterprise AI, from proof of concept to daily use.

I get enterprise AI through security review and into work people own: a signed-off design, a named owner, measured results, and a gate that says it still works. By day I lead AI transformation at monday.com as a Senior Forward Deployed Consultant. Outside it, I work with a few teams at a time, and I run my own AI lab under the same rules.

What I do for teams.

The demo was never the hard part. These four habits get a deployment through security review and keep it in daily use.

  1. Design sign-off before the first demo

    Data flow, access scoping, retention terms, and failure modes written down before security sees a demo. The design sign-off, typically the CISO’s, then reviews a written design instead of a slide.

  2. A named owner per workflow

    One person, not a committee. When output quality drops or the workflow has to change, there is one name on it, the same as the payroll run.

  3. Measured before and after

    Minutes per ticket, error rate, rework, escalations. If the workflow was not measured before the model arrived, nobody can claim it improved.

  4. A gate that fails in CI, not in front of a customer

    A golden dataset and a judge model score the live system, and the build fails when quality drifts.

I built these habits over twelve years of enterprise rollouts at Infosys Consulting, OneTrust, and AuditBoard (now Optro). At AuditBoard, every generative AI deployment went through a design sign-off and closed only when the customer confirmed adoption.

Frontier models plan, local models run, code decides.

I run my own AI under the rules above: the criteria are written down before the work starts, results are measured, and a gate, not a model, decides what counts. Here is one job moving through my lab.

One job through the lab A frontier model plans the job and writes what it must pass: output parses, every item covered once, a judge sample agrees. Four pieces run in parallel, two on the GX10 pair with GLM 5.3 Flash at about 59 tokens a second and two on the Mac Studio with Qwen3.8 27B at 77 to 91. Code checks each result; one fails, falls back to a cloud model, and passes the same check. A frontier model judges a sample, and the job is accepted. 01 PLAN 02 RUN 03 CHECK FRONTIER Planner Claude, GPT Accept only if output parses every item covered once judge sample agrees LOCAL GX10 pair GLM 5.3 Flash 1 2 59 tok/s LOCAL Mac Studio Qwen3.8 27B 3 4 77–91 tok/s CODE Code check CLOUD Fallback cloud model FRONTIER Judge Claude, GPT Accepted
An illustrative job on the real machines.
  1. Plan

    Frontier · Claude, GPT

    Splits the job into bounded pieces and writes down what done means before anything runs.

    591 problems in the test written before a 17% decode speedup was allowed to ship; it showed no quality loss

  2. Run

    Local · GX10 pair, Mac Studio

    The pieces run in parallel on hardware I own: GLM 5.3 Flash on the GX10 pair and a Qwen3.8 27B on the Mac Studio.

    36 of 36 sealed holdout coding runs passed by the 27B on the Mac Studio: 12 tasks, 3 rounds each

  3. Check

    Code, then frontier

    Code checks each result against the criteria; failures fall back to a cloud model. A frontier model judges a sample. Nothing counts until both pass.

    24 fallbacks to a cloud model out of about 38,000 local requests, last 30 days

Lab ledger, as of

  • 1,930,220,770 tokens through models on hardware I own, prompt and generated, on record through
  • 35,549,565 of them generated

From the lab’s usage logs, each request counted once. Local runs include benchmark work.

How I decide what runs where

Start here.

Three posts for teams moving AI from proof of concept to daily use. The lab notes are in the full list. All writing

If your AI work is stuck at proof of concept, that is the job I do.

A short scoping brief on what you are rolling out and what stands in the way. It comes straight to me, I read every one myself, and the first call starts at the real problem.