Most AI conversations in midstream go smoothly until the AI gets near integrity. The moment a model touches leak detection, in-line inspection data, or anything that feeds an integrity decision, a different set of rules applies. Integrity Management Program obligations kick in. API 1173 pipeline safety management expects documented process. A regulator may eventually ask why the system recommended what it did. For a generic AI vendor, this is where the conversation stalls.
For an operator, it's where the real requirements start, and those requirements are a design brief, not a barrier.
Why integrity changes the AI question
Outside the integrity world, a model can be judged on accuracy and convenience. Inside it, the questions are different. Can an integrity engineer explain the recommendation to PHMSA. Does a qualified person stay in the loop on consequential calls. Does the deployment fit the safety management system already in place. Is the decision trail auditable months later.
These aren't reasons to avoid AI in integrity work. They are the conditions it has to satisfy. A vendor who treats them as friction loses at the first audit. A vendor who treats them as the spec ships something that lasts.
Human-in-the-loop as a design principle
The durable pattern in integrity is straightforward. AI does the analysis it's genuinely good at, reading across inspection history, telemetry, and maintenance records faster than any person could, and a qualified engineer makes the call. That isn't a limitation bolted on to satisfy a committee. It's the design that lets the system be useful and accountable at the same time.
Built this way, the engineer stays responsible, the work gets faster and better documented, and the regulator gets an explainable trail. Built the other way, with the AI making silent calls, the first surprise becomes an incident and a finding.
Building AI you can explain to a regulator
Explainability isn't a feature you add at the end. It's a property of how the system is built. A model whose reasoning can be inspected, whose inputs are traceable, and whose recommendations carry their supporting evidence is one an integrity engineer can defend. A black box that produces a number is not, no matter how accurate it tests.
The difference between AI that ships in integrity and AI that stalls is usually whether explainability and documentation were designed in from the first day or hoped for later.
What the evidence looks like
This isn't theoretical. Kaysee, Cortland's reliability platform, runs in operator environments on rotating-equipment health with the human in the loop and the governance documented. It's a concrete example of the pattern: production AI that reads from the systems of record, surfaces analysis to the person who owns the decision, and leaves a trail. The same discipline that makes it work on a compressor station is what integrity work demands.
Governance isn't the thing standing between a pipeline operator and useful AI. Designed in from the start, it's the thing that lets the AI stay in the integrity program instead of getting pulled at the first review.