What is AI governance?

Illustrative example: Begin with one customer follow-up workflow. For a proposed follow-up task, who owns the customer result? Who can see the case and create the task? Is review required for this exact action? Where do the evidence and tool confirmation go? Who can pause the workflow? Those answers let a council test a control, rather than accept a broad promise.

Six questions for the vendor review

Where does each data path go?

Ask for a diagram of the selected deployment, including sources, models, actions, logs, telemetry, backups, and support access. Then trace one sensitive record through it. Hosting in a customer VPC does not by itself prove that all processing stays there. Nodes supports Nodes Cloud, a customer VPC, and customer-managed on-premises deployment; the chosen configuration determines the boundary. See the current security explanation.

Who can see vendor telemetry is a separate access question. Its answer alone does not establish whether an application is single tenant or multi-tenant. Inspect the actual isolation design and routes.

Can we reconstruct a decision?

Request one case with the question, dated sources, assumptions, alternatives, human judgment, permission, action confirmation, and later observation. A Decision Trace is the business record connecting those elements. It does not expose hidden model reasoning or establish that the recommendation was correct. Check whether your team can retrieve the record without a vendor assembling it after the fact.

Which actions need approval?

Ask to see a routine step covered by permission already given, an action requiring approval, and an action that must be denied. A second signer can be useful when the customer's policy calls for one; it is not a universal requirement. Earlier approval cannot expand the current identity's permissions or cover a changed plan. Approval gates show how to bind review to execution.

What happens when evidence is missing or changes?

Rename a source field in a test environment, revoke an action permission, and create two conflicting account records. The system should expose uncertainty and stop the affected action until an owner resolves it. Ask who receives the exception and how a corrected mapping is tested before it returns to service. The integration guide gives a fuller acceptance test.

How is the system evaluated and stopped?

Agree task quality, error limits, review load, cost, and business measures before expanding authority. Historical replay, sandbox tests, and live shadow evaluation answer different questions. Show the pause or revoke path and the operator who can use it. An audit log after the event cannot substitute for a working stop control.

What remains with us if the relationship ends?

Separate source records, company context, decisions, evaluated lessons, model artifacts, operational logs, and vendor software. Ask who controls each, what can be exported in a usable form, and what must be deleted under the agreement. Nodes customers retain their context graph, Decision Traces, and outcome history; Nodes retains its software IP. The ownership guide gives the detailed worksheet.

Put the controls through one case

An illustrative customer onboarding case makes the questions concrete. A document request has been sent twice, and the customer says the second request contradicts the first. The business owner wants to reduce rework without skipping a required check. The council can inspect the system against that exact responsibility rather than evaluate generic promises about automation.

Start with the records. Which source contains the current requirement? Which version was in force when the first request went out? Does the CRM refer to the same legal entity as the support case? A confident answer that ignores a disputed identity match should fail the test. The system should preserve both source records and route the conflict to the named owner. A correction to the source must reach the next answer without erasing what the first decision was based on.

Next, inspect authority. The agent may read the approved case and propose one consolidated request. It may have standing authority to create a routine task. A change to a customer agreement or a new data source may require another reviewer. Run an allowed case, a denied case, and a case where permission is revoked between proposal and execution. If the tool accepts a write through a service account with broader rights than the requesting employee, the team must explain how the product enforces the intended restriction.

Then inspect the action. Ask for the exact proposal version the person approved, the identity that executed it, the destination response, and the way a failed or uncertain write is reconciled. A system should not create a second request merely because the first API response was lost. If an action does not land, the operator needs a visible exception and a recovery procedure. A polished approval screen without that evidence is an incomplete control.

Finally, inspect the result over an agreed period. Did the customer receive one clear request? Did the required review still occur? Did time to usable onboarding or customer effort improve? These measures require a baseline and attention to other changes in the process. A task created successfully is evidence of execution. An improved onboarding result is later evidence. The council should keep those observations separate when it decides whether to expand scope.

Assign an owner after launch

Governance is ongoing work. A designated person needs to review exceptions, stale source mappings, unexpected cost, repeated declines, and changes to model or tool behavior. A council can set a review cadence and escalation threshold; the daily operator needs a way to pause the specific workflow before a council meeting. Show who can use that control and whether pending work remains visible after a pause.

Model or workflow changes deserve proportionate tests. A revised prompt might alter which evidence is selected. A connector update might change field meaning. A new action permission might change the risk of a familiar workflow. Record the version, acceptance cases, reviewer, and rollback path. The previous approval belongs to the previous operating scope and does not automatically cover a new one.

The exit plan belongs in the same operating review. A company may retain its history but depend on the licensed runtime to interpret it. Ask for a sample export with source references, dates, permissions, and later outcomes; then test whether another authorized tool can read it. That exercise reveals the practical boundary between retained company knowledge and software supplied by the vendor.

What a good review can establish

A quick demo can show how a system behaves on selected cases. The council still needs representative tests, the chosen deployment design, contractual rights, and a named operator. Approval is evidence that a person authorized an action under a policy; it is not proof that the action helped. A favorable result is evidence to evaluate, not permission to widen the next workflow.

Ask for one specific job and its exceptions, then test every control against that job. Nodes products explain which part of the job Engine, Connector, and AI FDE take on.

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.