AI Governance Evidence Portfolio · Case 02

Simulated case · Saudi gas processing contextPhase 1 deployment not approved

The vendor's AI was approved to predict failures. Its access told a different story.

Ramya Amballa, AI for U&I

A vendor removes a write-capable credential, provisioned for a future phase, from its AI gateway. That should settle it. It does not. The network path behind it stays open, although nobody has shown the AI could write through it. This case shows how to reconcile what a contract permits, what the technology can do, what the evidence shows and who actually approved it, before an industrial AI deployment goes ahead.

• Vendor AI assurance
• OT trust boundaries
• Third-party risk
• Deployment decision

The situation Simulated finding

A gas processor is deploying a vendor's predictive-maintenance AI on a critical compressor train. Phase 1 is advisory only. The AI predicts failures. A reliability engineer decides what to do and raises any work request. The AI cannot.

During the pre-deployment review, a write-capable integration credential turned up on the vendor's edge gateway. It had been provisioned for a future phase. The vendor removed it. The vendor has also proposed Phase 2: autonomous optimisation.

The question put to me was simple. Can Phase 1 go ahead?

The question that actually mattered

Not whether the AI predicts well. Whether four things line up for every vendor capability: what the contract permits, what the technology can do, what the evidence shows, and who in the operator approved it.

So I built a register to reconcile those four positions, interface by interface, identity by identity, data flow by data flow. It classifies each capability. It does not score it. A capability is either authorised and verified, authorised but unverified, beyond its authority, undefined because the contract is silent, or short of evidence.

What the review found Simulated finding

The credential went. The path stayed. The firewall rule that let the gateway reach the OPC server was still in place, and its removal had not gone through OT change control. Could the AI write through it? Not establishedNobody had shown that it could, and nobody had shown that it could not. So it is recorded as unresolved reachability, not as write access.

The first retest did not pass, for a different reason. A vendor support route, authorised under the support agreement, gave six named support engineers standing access to privileged engineering workstation functions. No time limit, no per-session approval, and never approved by the operator. That is human vendor access. Not establishedNothing in the evidence shows the AI can use that route, and I did not assume it either way. A separate test is specified to check.

Diagnostics were leaving for the vendor's cloud with no defined authority. The contract said nothing about content, destination, hosting, retention or use, and there was no classification decision. That is a governance gap. Not establishedWhether the transfer meets or breaches any law is not established, and it is not mine to decide.

The Phase 2 module was already on the gateway. Or so the vendor says. Installed and disabled, by its own statement. Not establishedNeither point has been independently verified.

Two more questions stayed open. Whether software and model updates install automatically is unknown. And the contract had no subcontractor terms, though Not establishednobody has shown a subcontractor holds access.

Rules I held to

• Only a demonstrated capability is a violation. An open path is a question, not a finding of capability.
• A vendor statement is not evidence. It is recorded as attestation until verified.
• Containment is not closure. A restriction counts only when someone other than the person who applied it has verified it. Even then the finding stays open.
• A review date is not permission. Anything not contained shows "act now", not a date.
• Legitimate support is preserved. The vendor still supports the gateway. Through named accounts, enabled per session, time-limited, with an operator present.

The decision Proposed

Phase 1 deployment approval is not granted.

A temporary, restricted advisory exception may be permitted for the one verified function, the engineer-reviewed recommendations, and the authorised capabilities it depends on. Only after the containment restrictions are independently verified and the operator's risk owner formally accepts the restricted condition. Anything that cannot be contained is suspended now, not at a later date.

Phase 2 is not considered for approval. It inherits nothing from Phase 1. It goes through the operator's Management of Change process.

What I did not decide Open decision

Whether Phase 2 needs hazard review or HAZOP revalidation is for the process-safety engineers. Data classification and transfer requirements are for legal and data governance. Whether any active network test is acceptable is for OT security and operations. The package names where each decision is needed. It does not make them.

How verification stays safe

No test is designed to change the live plant. The conduit check starts with firewall deny logs, which generate no traffic. Any active connection attempt needs written approval from OT security and operations. The Phase 2 module and the update path are examined only in an isolated environment. No test writes, enables or updates anything in production.

Challenging my own work

Each layer went through QA before it was frozen. The useful catches were my own overstatements:

• An early version described the Phase 2 module as installed and disabled, as fact. It was only the vendor's word.
• The first conduit test made an active probe of a production OPC server the default method. Deny logs are now the default.
• The first decision memo gave uncontained exposures a grace period. That contradicted my own rule that uncontained means act now.
• It also said no test had been performed, which ignored the retest that one finding rests on.

What the package contains

Reference. The package cites controls from the NCA Operational Technology Cybersecurity Controls (OTCC-1:2022). Cloud, data and classification requirements are marked for legal verification and are not asserted here. Applicability is professional opinion on simulated facts.

Illustrative scenario. All organisations, findings, approvals and evidence are simulated. Case 02 of the AI Governance Evidence Portfolio by Ramya Amballa, AI for U&I. Published October 2026.