The AI iceberg: how to see, unify and govern what runs below the surface 

Making AI visible is only the beginning. Organisations need a shared foundation that gives teams the freedom to work effectively, with clear ownership, practical controls and evidence of what happens. 

An organisation’s AI policy can describe what is approved while revealing very little about what people actually use. Below the surface, AI enters through everyday tools, individual accounts and workflows built to solve immediate problems. 

That is the AI iceberg. The approved tools and documented programmes are visible. The assistant embedded in a SaaS application, the personal account used to meet a deadline and the agent a team built last quarter can be much harder to see. 

For leaders, the challenge is to make that activity visible, connect it to a shared foundation and give teams a governed way of working that is useful enough to adopt. 

What sits below the surface

Some of that activity begins with a reasonable intention. Someone needs to summarise a document, find an answer or remove a repetitive task. If the approved route is difficult to use, people have an incentive to find another one. 

As AI moves from answering questions to taking actions, the consequences become more significant. An assistant drafting a response and an agent sending it to a customer need different controls. The organisation needs to know which is happening, who owns the decision and when a person must intervene. 

In the UK, the Information Commissioner’s Office’s call for evidence on agentic AI, open until 20 November 2026, brings these questions into focus. It asks how data protection law applies to the capabilities and risks of systems that can act with increasing autonomy. 

For business leaders, the practical question is already here: can we explain what our AI is doing, and show that it operates within the boundaries we have agreed? 

Visibility needs somewhere to lead

Discovering AI activity is necessary. But an inventory alone does not resolve fragmentation. 

If every team builds its own permissions, integrations, approval processes and monitoring, the organisation still has separate AI initiatives that become harder to manage as they grow. Each new use case risks repeating work already done elsewhere. 

Unifying means establishing a shared foundation for access, organisational knowledge, model use and oversight. Teams can still need different tools and experiences. A complaints handler, a marketing team and an operations manager are unlikely to work in the same way. 

The leadership decision is what should be shared and what should remain flexible. Controls and integrations should be reusable where appropriate. The experience should fit the task. Model and deployment choices should reflect the requirements of the workload. 

That gives visibility a purpose: bringing useful AI activity into an environment the organisation can support, measure and govern. 

Start with a workflow and build from there

A complete map of the business should not become a prerequisite for governing the AI already in use. 

Start with a workflow that matters. Identify the tools, models, agents and integrations involved, the information they access and the actions they can take. Use existing documentation and system records, then ask the people doing the work to check the picture. 

Those conversations matter. A process diagram may miss the shared spreadsheet, the informal approval or the workaround that keeps a service running. 

Set boundaries for discovery itself, including what information may be collected and who may access it. Then define the controls appropriate to the workflow. Expand the inventory as you learn, and keep it current as tools and responsibilities change. 

Four questions make this practical. Four questions make this practical. Together, they connect visibility to accountability, controls and evidence within each workflow. 

Know. What AI is involved, what information does it use and what can it do? Record gaps in visibility as well as what is known. Discovering an external tool does not mean its activity is already under your control. 

Own. Who is accountable for the use case and its outcomes? Someone needs responsibility for reviewing performance, resolving problems and deciding when the workflow should change. 

Control. What may the AI read or do, and when is human approval required? Put those boundaries into the running workflow, with a clear route for exceptions and escalation. 

Prove. What evidence is needed to review an action or investigate a problem? Keep appropriate records of the tools involved, relevant versions, approvals and outcomes, with access and retention rules suited to the information they contain. 

The next workflow should build on that foundation, while being assessed for its own risks and requirements. 

Adoption is part of governance

I believe adoption starts with showing people what improves in their working day. 

If we ask teams to change how they work, we need to explain the benefit and demonstrate it in a real workflow. That might mean less time searching for information, fewer repeated steps or a clearer route to getting a useful idea approved. 

A mandate alone cannot do that work. People need to understand the boundaries, have the training to work within them and see that their feedback leads to improvements. 

The experience matters too. A complaints team may need a case view with supporting evidence and approval steps. Another team may need an assistant for searching internal guidance. Both should be able to work within consistent controls without being forced through an interface that makes their task harder. 

This is where I see an important connection between adoption and governance. When the governed route helps people do their jobs, there is a stronger reason to use it. Leaders can then measure where it works, understand where it creates friction and improve it. 

What a shared foundation should enable

At Jeen, our approach brings employee AI, agents, workflows and governance onto a shared foundation, with flexibility over models and deployment environments. 

That flexibility should extend to the applications themselves. Teams should be able to build an entire application around their needs, with the interface, knowledge and workflows their work requires. Instead of adapting the way they work to a one-size-fits-all tool, they can shape the tool around the task, while keeping the organisation’s permissions and oversight in place. 

For leaders evaluating any platform, I would ask what happens when the second team starts using it. Can it reuse the integrations, knowledge and controls already established? Can it get an experience suited to its work? Can the organisation adapt its model or infrastructure choices as requirements change? 

These questions connect architecture to the cost and effort of scaling. They also make governance a practical part of deployment, rather than a separate exercise repeated for every project. 

One workflow in practice

Consider a customer complaint at a UK bank. 

First, identify the AI involved: perhaps a tool summarising correspondence, an assistant drafting replies and an agent routing incoming messages. Give each use an owner and establish accountability for the overall process. 

Then agree the boundaries. The routing agent might acknowledge receipt and assign a case, while an offer of redress requires approval from an authorised person. Staff need access to the information supporting a draft and a clear way to correct or escalate it. 

Keep the records needed to review how the complaint was handled. Alongside that evidence, measure whether the workflow improves the service: resolution time, rework, response quality and appropriate escalation. 

A faster process is useful only if its outcomes remain acceptable. The pilot should help the organisation assess both. 

Bring the next workflow onto stronger foundations

The iceberg becomes manageable as organisations build a clearer picture of their AI and give teams a workable route into governed use. 

Start with one workflow that matters. Give it an owner, agree the boundaries and involve the people who will use it. Measure whether it improves the work, then reuse what you have learned and built in the next workflow. 

That is how governed AI becomes something an organisation can grow with.