Why ungoverned AI in February 2026 is a different problem from ungoverned AI in February 2025, where the real exposure sits and what a CIO needs to understand.
Why ungoverned AI in February 2026 is a different problem from ungoverned AI in February 2025, where the real exposure sits and what a CIO needs to understand.
Brian Painting, Cofounder, Cattlegrid.uk
For chief information officers and technology leaders responsible for AI strategy, data architecture, and enterprise risk in UK organisations.
The conversation about AI governance has not kept pace with the thing it is supposed to govern.
When shadow AI first became a boardroom topic, the threat model was relatively legible: an employee copies a client document into ChatGPT, sensitive data leaves the building, you have a potential data protection incident. Discrete. Human-initiated. Traceable, at least in principle, to an individual decision.
That threat model is now the easy part.
The AI deployment landscape that most CIOs are actually managing in 2026 is considerably more complex and the risk is not a static point across it. It has a topology. The exposure increases, sometimes dramatically, as you move up the stack from simple tool use toward integrated systems, and from integrated systems toward autonomous agentic workflows. Understanding where your organisation sits on that stack, and what the governance implications are at each level, is the CIO’s problem in a way it is not quite anyone else’s.
This is an attempt to map that stack honestly.
Level One: The Prompt-Response Interaction
The risk you’re already thinking about ..
At the base of the stack sits the interaction that most governance discussions are still primarily addressing: a person opens a browser tab, types or pastes content into an AI tool, and receives a response. ChatGPT. Claude. Gemini. Copilot used outside its sanctioned configuration.
The risk here is real. 71% of UK employees are using unapproved AI tools; more than half do so weekly. 83% of organisations have no controls managing the data those tools consume.
But the risk at Level One has a characteristic that makes it, relatively speaking, governable: there is a human in the loop. A person made a decision to submit that data. The act is discrete. It can, in principle, be intercepted at the API boundary. The data transfer event has a shape you can instrument around.
The governance conversation is right to start here. It cannot stop here.
Level Two: API-Integrated AI
When the tool has been given the keys
The risk profile changes materially when an AI tool moves from responding to human prompts to having programmatic access to your systems.
This is already the operational reality for a significant number of UK enterprises. AI tools are integrated into CRM platforms, email environments, document management systems, and financial reporting workflows. They have been granted access via API keys issued during an enthusiastic proof-of-concept that quietly became production to data repositories that contain the organisation’s most sensitive commercial and personal information.
The critical distinction from Level One is that data is no longer flowing because a person chose to send it. It is flowing because a configuration decision, made at some earlier point, authorised that flow. The human decision is buried in the past. The ongoing data transfers are automated. Nobody is watching them happen, and in most cases, nobody is logging what moves.
The governance question at Level Two is not just “what data did an employee submit today?” It is “what data is this integration touching continuously, and under what terms does the AI provider retain, process, or use what it receives?”
Consumer AI terms of service typically include provisions around data retention and model improvement that are inconsistent with standard client confidentiality commitments. Your legal team has almost certainly not reviewed the specific terms governing each AI integration your development teams have enabled. In most organisations, nobody has a complete list of those integrations.
The audit trail at Level Two is frequently blank. Which is precisely the wrong answer when an ICO investigator asks what data processing was authorised and by whom.
Level Three: Agentic AI — Single Agents with Persistent Memory
The context accumulation problem
Move up the stack to agentic deployments; the AI systems that everyone is talking about. They act autonomously over time, rather than responding to discrete prompts and here the risk characteristics change again.
The defining feature of agentic AI is persistence. The agent accumulates context across sessions. It builds, and retains a working model of your organisation: your clients, your pricing, your internal relationships, your strategic priorities, your operational patterns.
That model is not a static snapshot. It updates and grows. It becomes, over time, an increasingly complete institutional memory held in a system you do not control and whose data practices you cannot independently audit.
Where does that accumulated context sit? On whose infrastructure? Under what terms of service? What happens to it if the provider is acquired, changes its terms, or experiences a breach? These are not hypothetical governance questions. They are questions with operational answers that most organisations cannot answer.
The single-agent case is at least bounded. There is still a recognisable system to instrument around. The data flows in and out through identifiable channels. The governance challenge is significant, but it has a shape.
That shape becomes considerably harder to define at the next level.
Level Four: Multi-Agent Orchestration
Where data lineage goes to die
Multi-agent architectures in which multiple AI agents interact, pass context between each other, and collectively complete complex tasks represent the current frontier of enterprise AI deployment. They seem to have sprung up overnight. They are also, from a data governance perspective, a genuinely serious problem that most organisations have not reckoned with.
The fundamental issue is the handoff. When Agent A passes its context window to Agent B, there is no human review point in that transfer. The data in that context which may include everything Agent A was given access to, plus everything it retrieved, inferred, or generated plus potentially framing information about the context of that data moves to Agent B’s processing environment. That environment may sit on different infrastructure, in a different jurisdiction, under different terms of service. Agent B enriches the context further and passes it to Agent C. By the time the orchestration chain has completed its run, you have no reliable audit trail of what data was where, in what form, under whose governance terms, at any point in the process.
This is not an edge case. Multi-agent frameworks; LangChain, AutoGen, CrewAI, Microsoft’s Semantic Kernel, and others are in active enterprise deployment, frequently built by internal development teams who are focused on capability, not data lineage. The security review process typically examines functional behaviour. It rarely examines what happens to the data that moves through the system, or where that data ends up when the orchestration run completes.
The context accumulation problem that applies to individual agents is amplified in multi-agent systems by the retrieval patterns these architectures typically employ. Each agent in the chain may have access to retrieval-augmented generation systems; email archives, file stores or code repositories to name but three. Queries that begin as specific and bounded become, through retrieval and agent reasoning, sweeps through institutional knowledge. The data that ends up in the context window of Agent C may bear almost no resemblance, in scope or sensitivity, to the query that initiated the workflow.
Ask yourself do you know which multi-agent deployments are currently running in your organisation? Do you know what data stores they have access to? Do you know what their retrieval patterns look like, and where the output of each agent’s reasoning is stored or transmitted?
If the answer to any of those questions is uncertain, the gap you are describing is not a theoretical governance risk. It is an active data protection exposure.
The Jurisdiction Question: USA, PRC, and Why They Are Not the Same Problem
The risk of reaching for the newest and most capable tools
The pace of AI capability development creates a specific CIO problem that deserves its own treatment: the temptation or the organisational pressure to adopt whatever model is currently most capable, regardless of where it is built or who governs it. To adopt the shiny thing that the CFO has been playing with in his spare time.
This is not an argument for technological parochialism. It is an argument for understanding what you are actually accepting when you choose a model, and for whom.
US providers: the CLOUD Act baseline
The US CLOUD Act grants US federal agencies access to data held by US-domiciled companies and their subsidiaries, regardless of where that data physically sits. GDPR-compliant EU data centres operated by AWS, Azure, or Google remain, in principle, subject to CLOUD Act requests. This is a known, documented, and legally contested risk. It has case law. It has regulatory guidance. It operates within a framework that is at least negotiable in its terms and partially addressable through architecture decisions including, relevant here, choosing technology providers who are not subject to US jurisdiction.
The CLOUD Act risk is real. It is also the kind of risk that informed enterprise legal and compliance teams can assess, model, and to some extent mitigate.
PRC providers: a categorically different exposure
Chinese AI providers — Kimi, built by Moonshot AI, is a current example — operate under a legal framework that is not analogous to the US position, and should not be assessed as if it were.
The People’s Republic of China’s National Security Law, Data Security Law, and Cybersecurity Law collectively create broad obligations for Chinese companies to cooperate with state security organs, with no requirement for judicial authorisation, no meaningful independent oversight, and no legal mechanism through which a foreign organisation can verify what happens to data it submits. There is no adequacy decision between the PRC and the UK or EU. There is no Standard Contractual Clause mechanism that provides meaningful legal protection.
This is not a geopolitical opinion. It is a legal and architectural fact with direct data governance implications. For any UK enterprise handling client data, commercially sensitive information, or anything that touches regulated sectors financial services, legal, defence supply chain, healthcare the use of PRC-domiciled AI services for non-public information is a governance failure of a different order of magnitude from using an unsanctioned US consumer tool.
The point is sharpened considerably for agentic deployments. A PRC AI agent with persistent memory and retrieval access to your document environment is not a tool your employee is using. It is a system with continuous, programmatic access to your institutional knowledge, operating under a legal framework that explicitly subordinates commercial confidentiality to state security interests.
The newest and most capable is not always the appropriate choice. Understanding where capability sits relative to jurisdiction is part of the CIO’s current job in a way it was not three years ago.
The Classification Problem Nobody Has Solved
Who decides what the agent is allowed to see and has anyone actually decided?
There is a question underneath all of this that most organisations have not answered cleanly, and whose absence undermines every other governance measure you might put in place.
What is this agent being used on, and who classified that data as appropriate for it?
Data classification is a foundational governance requirement under UK GDPR, ISO 27001, and the EU AI Act. It is also, as anyone reading this will know, frequently incomplete, frustratingly hard to pin down and inconsistently applied,
It is almost never extended systematically to AI interactions.
When an integrated AI tool retrieves documents from your file store, it is not retrieving documents that have been reviewed for AI appropriateness. It is retrieving documents that are accessible to whatever credentials it was issued. When an agentic workflow sweeps your email archive, it is not working from a curated dataset. It is working from the totality of what it can reach.
The data classification questions that matter for a CIO reviewing AI deployments are specific:
Who determined that this data was appropriate for submission to this AI provider under these terms of service? Not the developer who built the integration. It is the governance owner; the named individual with accountability for that data category.
Has that determination been reviewed since the deployment was built? AI providers change their terms. Capabilities change. The context in which data is being used changes. A determination made twelve months ago during a proof-of-concept may not be valid for the production agentic system that evolved from it.
Does the classification apply to the output of AI processing, not just the input? When an agent synthesises client information, commercial data, and internal strategy into a summary or a recommendation, that output may carry sensitivity that is not captured by the classification of any individual input document. Who owns the output, and who classifies it?
Who has visibility of what non-public information is being submitted by employees, by integrations, by agents to external AI services? In most organisations, the honest answer is: nobody, in aggregate, with any completeness.
This is the governance gap that creates liability, not just in the event of a breach, but in the ordinary course of regulatory enquiry. The EU AI Act requires organisations to demonstrate AI governance systems, conduct risk assessments, and maintain transparency mechanisms. Demonstrating those things requires knowing what your AI systems are doing with data and who made the decisions that authorise what they do.
What This Means in Practice
A CIO reading this in February 2026 is most likely managing a position somewhere between Levels Two and Four, with Level Four deployments that may not have full executive visibility. The agentic wave has arrived faster than most governance frameworks anticipated, and the multi-agent orchestration pattern is being deployed by development teams who are focused, quite reasonably, on what the technology can do.
The practical implications are not complicated, even if the implementation is not easy.
You need visibility before you can govern. An audit of actual AI tool usage including unsanctioned tools, API integrations built outside formal procurement, and agentic deployments built by internal teams is the prerequisite for everything else.
Until you know the shape of your actual AI landscape, your governance programme is working from a map that does not match the terrain.
You need a control at the boundary where sensitive data crosses into AI systems. The API boundary is the most instrumentable point in the stack. Governing it does not solve the classification problem, but it provides the audit trail without which the classification question cannot be answered retrospectively.
You need the classification question answered with named accountability. Someone has to own the determination of what data is appropriate for which AI systems under which terms. That person’s name needs to be on a document that will still be legible when a regulator asks who made the decision.
ISO 27001 and ISO 42001 certification provides the policy framework, the risk assessment process, the accountability structures, the audit evidence. The certification pathway takes nine to twelve months. The EU AI Act enforcement clock is already running.
CattleGrid operates at the API boundary described above, providing real-time interception, data classification enforcement, and audit trail generation across the major cloud AI platforms and direct APIs. It is built on European infrastructure, outside US CLOUD Act jurisdiction. It is not the complete answer.The complete answer requires the ISO programme and the executive commitment that entails. It is the protection you deploy whilst the complete answer is being built.
CattleGrid is accepting a limited number of UK enterprises into its founding access programme, prioritising financial services and professional services organisations of 50 or more employees.
To arrange a technical briefing or discuss your specific AI deployment landscape: hello@cattlegrid.uk | cattlegrid.uk/early-access
CattleGrid Ltd is registered in England and Wales. Company Number: 17020793. This document is provided for informational purposes and does not constitute legal or regulatory advice. Statistics cited are drawn from primary sources including IBM Cost of Data Breach Report 2025, Microsoft/Censuswide UK Shadow AI Survey 2025, BlackFog/Sapio Research 2025, Zscaler AI Security Report 2026, and DSIT AI Adoption Research January 2026. Full source list at cattlegrid.uk/whitepaper-sources.
