Passing an evaluation supports a decision to launch. Governed operation keeps that decision accountable as workflows, permissions, evidence and conditions change.
By Renee Cannon, Founder of eunoiaAI
September 28, 2026
![[Hero Alt Text]](https://cdn.prod.website-files.com/6a5e755fad03f8f3b4db484b/6ab30f17f1dcb286d5b090b6_From%20evaluation%20to%20Operations_eunoiaai_ChatGPT%20Image%20Sep%2022%2C%202026%2C%2007_27_13%20PM.png)
A successful evaluation supports a decision to proceed. It does not remove the need to decide whether continued operation remains appropriate.
For an AI agent, that distinction matters because the approved system is more than a model. Its role depends on the work it performs, the information it uses, the tools it can call, the authority it has, and the people expected to supervise it.
At eunoiaAI, our position is that production governance should preserve the connection between those operating conditions and the decision to use the system. When that connection weakens, a passing score from an earlier release cannot repair it.
Evaluation produces evidence about performance, limitations and failure modes. Authorization is the organization's decision to permit a defined use, with specified controls and acknowledged uncertainty. Operation is the continuing work of maintaining those conditions and responding when they change.
These responsibilities inform one another. They should not be collapsed into a single "passed" status.
An organization can reasonably conclude that an agent is useful for preparing a recommendation but not authorized to execute it. It can also conclude that an agent previously approved for a narrow workflow needs new review before use expands to another team or population.
NIST's Generative AI Profile cautions that laboratory and benchmark testing may not adequately represent real-world conditions. The practical implication is to state what the evidence supports, not treat it as approval for every use the software makes possible.
A clear evaluation basis should identify the work being assessed, what acceptable results mean, the limitations of the evidence, and who can judge its adequacy. This is an operating agreement about evidence, not a universal certification of the agent.
Consider an illustrative workflow in which an agent prepares supplier-onboarding recommendations for procurement staff. It checks required information against an approved policy and flags exceptions for review. It cannot create an approved supplier or change payment details.
The initial evaluation covers that role. Later, another department begins using the same agent for a different class of suppliers. Someone also proposes enabling the connector's account-update function to reduce manual work.
Neither change necessarily means the original system was poorly built. Both raise a new question: does the earlier evidence support the proposed use and authority?
A broader supplier population may introduce unfamiliar documents or requirements. Write access changes what a mistake can do. The organization should examine those differences before allowing an informal expansion to become the new operating model.
That is why production teams need an accessible account of the approved use, current configuration, relevant dependencies and decision owners. It should be possible to establish what changed without reconstructing the project from old messages.
Not every change deserves the same response. A presentation edit and a new action permission have different implications. Review should be proportionate to the affected behavior and consequences, while changes to purpose or authority should return to the people authorized to approve them.
The useful principle is simple: a technical change should not silently become a new business authorization.
A statement in a prompt is not equivalent to an enforced restriction on what the connected system will accept.
OWASP's guidance on excessive agency recommends limiting available functions and privileges, requiring human approval for high-impact actions, and enforcing authorization in downstream systems rather than relying on the language model to decide what is permitted.
In the supplier example, "do not change payment details" should not be the only barrier between a recommendation task and a payment-record change. The relevant connector and account permissions should reflect the approved role.
Those controls also need to survive maintenance. A replacement integration, a new service account or a convenience setting should not expand authority without review. Testing should examine the actual action boundary, including attempts that should be rejected, not only whether the agent describes that boundary correctly.
The question is not simply whether the agent intends to follow the rules. It is whether the surrounding system enforces the authority the organization granted.
A production evaluation should ask whether the workflow is achieving its intended result, not merely whether the model returns plausible text.
For the illustrative supplier workflow, useful evidence might include whether recommendations use current requirements, whether exceptions reach an appropriate reviewer, and whether completed handoffs leave the correct downstream state. Speed alone would not answer those questions.
The organization should also distinguish different kinds of failure. A correctable draft error, a missed exception and an unauthorized record change should not disappear into one average success rate. Their consequences differ, so the decision about acceptable performance should distinguish them.
NIST's Measure guidance calls for monitoring production behavior and comparing production measures with pre-deployment results. It also addresses feedback and human overrides as inputs to evaluation.
Our practical recommendation is to examine where effort goes after the agent produces its output. If employees quietly repair its work, the apparent productivity gain may be incomplete. If every ambiguous case reaches one specialist, the workflow may have created a new capacity constraint.
These are questions to investigate, not proof that the agent lacks value. A narrowly bounded assistant may still be worthwhile. The point is to judge the arrangement that actually operates, including the human work it requires.
Collecting an event and deciding what to do about it are separate activities. A dashboard becomes useful when the organization has assigned responsibility for interpreting its signals and taking action.
In the supplier example, an increase in rejected recommendations might reflect a changed policy, unfamiliar inputs, a retrieval problem or an unrealistic evaluation standard. Automatically changing the prompt would choose a remedy before establishing the cause.
A proportionate response begins by determining what the signal means and what exposure exists while the issue is investigated. That may justify a targeted review, restricted use or temporary suspension of a particular action. It need not mean stopping every function of the system.
Human review deserves the same operational discipline. NIST's Govern guidance connects oversight to documented responsibilities and sufficient resources. A named reviewer needs the information, competence, time and authority to make the assigned decision.
For a workflow that depends on approval before an action, an unanswered escalation cannot simply count as consent. The organization should specify how pending work is handled and who takes over when the primary reviewer cannot respond.
After an intervention, someone should verify the result. An alert that was acknowledged is not evidence that the underlying issue was resolved.
Scheduled reviews are useful. They are not a substitute for responding when a material assumption changes between reviews.
A different model, revised prompt, new retrieval source, modified business rule or changed tool permission may affect behavior. So may a change in the users, workload or human review capacity. A release process focused only on application code would not necessarily capture all of those events.
Our recommendation is to connect change review to the reason the system was approved. Ask which evidence remains applicable, which assumptions no longer hold, and what must be checked before the affected use continues.
This is where regression testing and renewed authorization do different work. Regression testing can help assess whether established behavior has been preserved. Renewed authorization addresses whether the organization accepts a changed use, control arrangement or consequence. One does not automatically substitute for the other.
The response should remain proportionate. Not every maintenance change needs a committee. But new authority should not be granted merely because the interface still works, and a vendor's general release assurances should not replace evaluation of the organization's own workflow.
Stopping further actions, restoring a previous configuration and repairing an external consequence are different tasks.
Rolling back an agent does not itself withdraw a message it already sent or establish whether a downstream record was changed. Recovery should first establish the state of the work, then determine what can be corrected, by whom, and with what authorization. An uncertain action should not simply be repeated because the first attempt returned an error.
NIST's Manage guidance includes post-deployment response, recovery, change management and decommissioning. These are continuing operating responsibilities, not evidence that every system must remain deployed.
A workable plan should account for the work that remains after an agent stops: pending cases, people waiting for an answer, connected accounts and information that must be retained or disposed of appropriately.
Evidence should support that work without becoming an uncontrolled copy of sensitive business data. Record enough to establish relevant inputs, versions, approvals, actions and outcomes; apply access, minimization and retention rules to those records. An event log can help establish what happened. It is not, by itself, a complete explanation of why a model produced a particular result.
Retirement is also a legitimate operating decision. A workflow may change enough that the agent is no longer useful, or the cost of maintaining adequate controls may exceed its benefit. Continuing because a system once passed its tests is not a sufficient value case.
The people who built a system, the people who operate it and the people who accept its use may have different responsibilities. Those assignments should be explicit. Engaging a technology or governance provider should not leave the organization assuming that someone else owns every post-launch decision.
Nor should "more autonomy" become the default measure of progress. A stable recommendation workflow may be the right endpoint. Narrower access, a revised human handoff, a repaired data source, a pause or retirement may each be a sound outcome when supported by the evidence.
The aim is not to reopen every decision every morning. It is to know which decisions must be reopened when the work changes.
A passing evaluation supports the decision to begin. Governed operation keeps the decision to continue accountable.
This article presents eunoiaAI's professional perspective on operating governance. The supplier-onboarding example is illustrative, not a client case study. The sources below support the technical and risk-management principles; they do not certify a particular implementation or determine its legal obligations.
Sources accessed September 22, 2026.
Listen to this Insight An AI-generated audio discussion based on eunoiaAI's original analysis on Spotify.
An AI Fit Conversation can clarify whether eunoiaAI is a fit for the questions around your AI-enabled workflow, the likely paid path and an appropriate next step.
A demo proves that an agent can complete a prepared task. A business system must keep working when the data, users, tools, and circumstances are not prepared.
The most dangerous agent failure may not be a dramatic error. It may be work that quietly stops, routes incorrectly, duplicates an action, or leaves nobody responsible.
An agent's task tells you what it does. Its decision rights tell you how much authority the business has actually handed over.