Skip to content

Insights / Private AI

Your AI Pilot Needs a Scorecard Before It Needs More Users

Measure accepted work, review time, security boundaries, and failure handling before expanding an AI pilot. Includes a copyable scorecard.

Private AI

A clearer view of what comes next.

The pilot team likes the assistant. The demonstration was fast, and several employees say it saves time. The sponsor now has a harder question: should the organization expand it?

Usage and enthusiasm help explain adoption. They do not establish whether the work is accurate, access is appropriate, or the total effort is lower. A small scorecard can make the decision concrete before the pilot becomes a permanent service by accident.

The NIST AI Risk Management Framework provides voluntary guidance for evaluating and managing AI risk. The scorecard below is an operating tool inspired by that goal, not a certification or a NIST-required scoring method.

Define One Job and One Accepted Result

Choose a task narrow enough to evaluate. “Help procurement” is too broad. “Draft an answer to a purchasing procedure question using the current approved policy” gives reviewers something they can inspect.

Write an acceptance rule before collecting results. For that example, an accepted answer might need the correct procedure, supporting source passage, current document date, and no unsupported statement. Define what happens when the source is missing or contradictory.

Name the business reviewer, technical owner, data owner, and sponsor. Decide who can stop the pilot and who approves expansion. A team that cannot identify its acceptance owner cannot reliably count accepted work.

Compare the Same Work With and Without AI

Select representative tasks that are authorized for the pilot environment. Include ordinary cases, difficult cases, missing information, and tasks outside scope. Use an approved test set instead of uploading sensitive production records merely because they are realistic.

Measure the existing process as well as the AI-assisted process. Count preparation, document cleanup, prompting, retries, review, correction, and final handling. If a reviewer spends ten minutes repairing a two-minute draft, the generation time tells only a small part of the story.

Keep failed attempts in the denominator. Report the sample size and conditions so the sponsor knows whether the results describe five demonstrations or several weeks of normal work.

Use a Scorecard That Can Block Expansion

Measure Record Decision it supports
Accepted work Accepted tasks divided by attempted tasks Is quality adequate for this job?
Total effort Human time across the full workflow Is the team actually saving effort?
Material errors Unsupported claims, wrong actions, missing conditions Where could the output cause harm?
Access boundary Authorized and unauthorized test results Does the service enforce the intended scope?
Failure handling Missing sources, unavailable tools, recovery results Can staff operate safely when it fails?
Operating burden Support, maintenance, review, and direct costs Can the organization sustain the service?

Do not average a serious access failure into a favorable quality score. Set nonnegotiable conditions separately. For example, unauthorized retrieval should pause the affected workflow until the issue is investigated and the relevant boundary is verified again.

Copy This Pilot Decision Record

Workflow and approved users:
Allowed data and excluded data:
Business acceptance rule:
Baseline process and measurement window:
Pilot configuration and test set:
Attempts, accepted tasks, and material errors:
Total human effort, including correction:
Access and failure-path results:
Operating costs and unresolved estimates:
Known limitations and responsible owners:
Decision: stop, revise, continue bounded, or expand:
Approver, conditions, and next review date:

Keep the configuration identifiable. A changed connector, document collection, permission model, or review process can change the result. Do not combine measurements from materially different setups without explaining the difference.

The NIST Generative AI Profile adds context for risks specific to generative systems. A local scorecard should reflect the consequences of your workflow rather than copying a generic benchmark leaderboard.

Make the Next Decision Smaller

A useful pilot can end with “continue for this department with human review.” Expansion does not have to mean organization-wide autonomy. Add one new user group, document set, or action at a time, with explicit acceptance criteria for the added risk.

If results disappoint, identify the failing component. Poor source documents, permission gaps, weak retrieval, unsuitable tasks, and insufficient review capacity need different remedies. More users will not resolve an unclear task definition.

Use the AI Hub for practical planning resources and the private AI acceptance tests when converting pilot evidence into a purchase requirement.

Book an AI pilot planning conversation. Bring one workflow, its current effort, and the evidence your sponsor needs to make a decision.

Put it into practice

Illustrative planning model

A useful path to private AI

Explore step 01

Choose a workflow

What should become easier?

Start with one repeatable task and the person responsible for its outcome. Define what a useful answer would look like before choosing a model.

Z7 Weekly Intelligence

We aim for one email a week: the threats that matter, new Z7 intelligence briefs and articles, and what to do about them. Unsubscribe anytime.

By subscribing, you agree to our Terms of Use. Our Privacy Policy explains how we use your email.

Put your AI questions on the calendar.

Bring your use case, data concerns and budget questions. We will talk through what fits, what it costs and a practical next step.

Ask Zeus AI assistant