AI Governance Framework for Regulated Cloud Infrastructure

Owning AI: visibility, autonomy and accountability

AI tools have moved from novelty to daily practice faster than most policies have. For technical leaders and engineering teams, that gap is where the risk lives: individual contributors adopting tools faster than the organisation has decided what is acceptable.

This is the framework we use at Pipe Ten, ISO 27001 certified, shared in the hope it saves you some working-out. It comes down to three questions: What data can the tool see? How much can it do on its own? & Who owns the result?

Underneath all three sit the same two things: visibility and ownership. You cannot own an outcome you could not see being made, and most of what follows is about keeping both. But before any of that, it is worth looking at the person holding the keyboard, because that is where most AI risk actually lives.

A note on terms, since “AI” now gets applied to everything from spam filters to chatbots. This article is about generative AI: the language-model tools you converse with, and the agents built on them. Classical machine learning, the kind that has quietly filtered spam and scored anomalies for years, is a different technology with a different and well-understood risk profile. Every risk below, from confidently wrong answers to prompt injection, is specific to the generative kind.

Know your own weaknesses first

AI will happily agree with you. If you go to it to confirm a theory, it usually will, whether the theory is right or not. Reach your own conclusion first, then ask the AI to challenge it.

Attention fades. You will not review fifty files of generated code as carefully as ten lines you wrote yourself. Review generated work in small pieces, or have the AI walk you through it.

AI only knows what you give it. Hand it incomplete data and it will reason confidently from what it has, producing a plausible answer to the wrong question. The most dangerous gaps are the ones that do not announce themselves: the cause that lives outside the logs, the context nobody thought to share. Before asking, check whether your data can actually answer the question.

Approval fatigue is a team problem, not just a personal one. When agent steps are reviewed dozens of times in a session, attention degrades across the whole team. The person who was genuinely reviewing step three is rubber-stamping step forty. That is a process design problem and it needs a process answer: smaller scopes, shorter sessions, rotation of the review responsibility.

What data can the tool see?

The risk of sharing data depends on the specific tool and the controls around it, not on AI as a category.

Unapproved tools (consumer accounts, free tools, anything your organisation has not assessed) should see public information only. There is no contract, retention is unknown, and your inputs may be used for training.

Approved tools (contracted enterprise services with a data processing agreement and no training on your inputs) can take data according to its classification, kept to the minimum needed. UK GDPR still applies to personal data.

Self-hosted models running on your own infrastructure can take anything, treated as any other internal system. You inherit the hosting security, and the autonomy risks below still apply.

One rule holds everywhere: secrets and credentials go into no AI tool, ever. Prompt histories are stored, logged and copied around like any other text. If a secret reaches an AI tool, rotate it.

For organisations under FCA oversight or ISO 27001 certification, the approved tools list is not optional good practice. It is an information asset control that an auditor will ask to see.

If your organisation has not yet decided which tools are approved, that one piece of work reduces more risk than anything else in this article.

How much can it do on its own?

Five modes, in increasing order of autonomy:

• AI advises, you act. Risk is mainly what data you share.
• You run AI-generated output. Risk is whether you understand what you are executing.
• An agent works on systems, you approve each step. Risk is the quality of your attention. Approval fatigue is real: a hundred approvals in, this quietly becomes mode five.
• An agent reads on its own. Risk is what it can reach, and prompt injection: content the agent reads can contain instructions aimed at the agent.
• An agent makes changes on its own. Risk is blast radius. Oversight is after the fact.

Sessions drift between modes. You ask for an explanation, get a suggested fix, and run it. The risk follows what you do, not what you asked for.

Six principles

1. Never execute output you cannot explain.
2. Test generated changes outside production first.
3. Give agents the minimum access the task needs.
4. Log everything an agent does. No audit trail, no access.
5. A human reviews anything before it reaches a customer, the public, or production.
6. Treat everything an agent reads as untrusted. Assume prompt injection will be attempted, even on self-hosted models.

Where we draw the lines

Applied to our own estate, the framework produces a few hard no’s: agents writing to production without a human in the loop, any AI involvement with secrets, and anything that could alter or suppress backups or logs.

Read is a different question to write: agents reading production telemetry, logs or configuration can be appropriate with tight scope and full audit, and that asymmetry is deliberate, since the blast radius of observation is bounded in a way action is not.

Environment matters the same way: development is open at almost every level of autonomy with the principles applied, which is exactly where generated changes should prove themselves first. The best-suited uses we have found are vulnerability scan triage, ticketing and documentation, where AI performs well short of fully unsupervised. Everything between is a named owner applying the six principles.

The lines your organisation draws will be different, but the process of drawing them is the same: name the hard no’s explicitly, document who made the decision, and treat AI governance as an information security control rather than a usage policy. For ISO 27001 certified or FCA-regulated organisations, that documentation is not optional.

Own the output

AI is an aid, not an author. “The AI generated it” shifts responsibility nowhere useful. If you executed it, reviewed it or deployed it, you own it. And if a task carries a risk you are not comfortable owning, escalate rather than proceed and blame the tool.

For engineering teams, that means generated code reviewed before it merges, not after. A pull request from an AI agent carries the same scrutiny as a pull request from a junior engineer on their first week.

Closing thought

None of this argues for caution over adoption. We use AI extensively, including agentic tooling on our own systems; this framework is what lets us move quickly without moving carelessly.

AI reasons from what is generally true, and real environments contain deliberate exceptions made for reasons that exist in no dataset, so the people who hold those reasons stay essential to telling a genuine improvement from a fight with a good decision.

Ownership is one of our company values, and AI is where it earns its keep: the tooling changes, the accountability does not. The organisations that get the most from AI will be the ones who can say, for any task, what the tool can see, what it can do, and who owns the result.

Key takeaways

• Most AI risk sits with the person at the keyboard, not the model itself: check your own assumptions and review generated work in small pieces
• Data risk depends on the tool’s contract and controls, not on whether it’s “AI”: classify by unapproved, approved, or self-hosted, and never put secrets or credentials into any AI tool
• Autonomy runs across five modes, from advice to unsupervised change, and sessions drift between them without anyone deciding to move
• Six principles anchor safe use: explainability, testing outside production, minimum access, full logging, human review before anything customer-facing, and treating agent input as untrusted
• Read and write carry different risk profiles: tightly scoped, audited read access can be appropriate where unsupervised write access to production is not
• Responsibility for AI-assisted work sits with whoever executed, reviewed, or deployed it, not with the tool

If you’re setting AI governance for a regulated engineering environment and want to talk about where the infrastructure and compliance obligations sit, feel free to get in touch.