Enterprise technology has never produced more information about itself. Applications generate logs. Infrastructure produces metrics. Cloud platforms track activity. Security tools record events. AI systems create another layer of telemetry on top. The problem is that collecting more information hasn't necessarily made the enterprise easier to see.
In some cases, the opposite is happening. Dynatrace's 2026 State of Log Management research found that AI workloads had driven a 93 per cent increase in log and telemetry volume over the previous year. Yet 71 per cent of the 450 technology leaders surveyed still struggled to collect and correlate AI health metrics across different sources.
At the same time, the environment producing all of that data is expanding. Cloud services, SaaS applications, automated workflows, AI agents and third-party platforms increasingly sit alongside infrastructure the organisation owns directly. Different teams manage different pieces, while individual systems depend on services that may sit several steps outside the organisation itself.
This is creating an enterprise visibility problem that goes much further than monitoring. Organisations are becoming responsible for technology environments they can't always see as a coherent whole. And that creates a difficult governance question. How do you govern an environment when the boundaries of your responsibility extend further than your effective visibility?
More Data Hasn't Solved The Visibility Problem
More monitoring used to seem like a fairly obvious answer to limited visibility. If you couldn't see enough, you collected more data. Modern systems have complicated that equation. The average organisation in Dynatrace's log management research now uses seven different tools to manage logs and telemetry.
Faced with the cost and sheer volume of all that information, half of respondents said their organisations excluded data from their logging systems, with an average of 86 per cent left out. So enterprises can simultaneously have too much telemetry and not enough useful visibility. The issue is partly fragmentation.
One platform sees application performance. Another records network behaviour. A security tool sees identity activity. A cloud console knows about resources in its own environment. An AI monitoring system may track model performance somewhere else. Each source can be accurate without giving anybody the complete picture.
This becomes harder as the number of sources grows. In Dynatrace's August 2026 research, nearly half of surveyed site reliability engineers said having too many data sources and metrics made it harder to define and manage effective service-level objectives. Only 40 per cent of platform engineers said observability was embedded across every deployment stage.
The visibility crisis, then, isn't simply about whether data exists. It's about whether organisations can connect enough of that data to establish what is happening across the environment they actually need to manage. That environment is also getting bigger.
The Enterprise Technology Estate Is Becoming Harder To See
There was a time when the boundaries of enterprise technology were easier to draw. They weren't necessarily simple, but organisations generally had a clearer sense of what counted as their infrastructure and who was responsible for running it. Those boundaries have become much less tidy.
Enterprise systems now stretch across on-premises infrastructure, multiple clouds, SaaS platforms, APIs, managed services, automated workflows and third-party technology. AI adds models, agents and embedded capabilities that may enter the organisation through dedicated projects, vendor products or individual business teams.
Flexera's 2026 State of ITAM Report shows how difficult it has become to maintain IT asset visibility across that wider estate. Only 36 per cent of the 512 organisations surveyed reported complete visibility across their IT environments, down from 43 per cent the year before. For AI software specifically, the figure was just 31 per cent.
Knowing what exists is still the first problem. It just isn't the last one anymore.
Asset visibility is only the beginning
You can't manage technology you don't know you're running. That basic principle hasn't changed. What has changed is the range of things an enterprise now needs to discover. A traditional IT asset inventory may account for servers, endpoints and installed software while missing SaaS applications, cloud resources or AI tools adopted outside conventional IT processes.
AI agents make the discovery problem particularly visible. Cloud Security Alliance research published in April 2026 found that 82 per cent of surveyed organisations had discovered previously unknown AI agents operating in their environments during the previous year. The important point isn't that every unknown agent is dangerous.
It's that an organisation can have mature monitoring around the systems it knows about while still having technology operating beyond that picture. Once an asset has been identified, another question follows almost immediately. What does it depend on?
Dependencies extend beyond organisational boundaries
A modern application rarely operates alone. It may depend on a cloud platform, identity provider, external API, data service, AI model and several internal systems before a user sees an outcome. Some of those dependencies are visible to the organisation directly. Others are buried inside services supplied by somebody else.
IBM's June 2026 research makes the scale of that problem unusually clear. Among 1,000 senior executives surveyed, 91 per cent said they didn't fully understand their organisation's AI dependencies across vendors, models and infrastructure. That leaves organisations with two different maps to maintain. One shows what technology they use.
The other shows what that technology relies on. Neither map is especially useful if it stops at the organisational boundary. A business may not operate the infrastructure underneath a SaaS service or control the model behind an AI product. It can still depend on both.
Visibility therefore has to extend far enough through those relationships for leaders to understand where operational responsibility meets external dependency. Then there is the question of who is actually responsible for each part of that environment.
Ownership is becoming part of the visibility problem
Technology ownership is becoming distributed almost as quickly as the technology itself. Cloud teams manage some services. Security teams manage others. Platform engineers handle shared infrastructure. Business units buy SaaS tools. Data teams run pipelines. Developers add integrations.
External providers own technology that several of those systems depend on. That can create environments where everyone has responsibility for something, but nobody has a complete view of everything.
Cloud Security Alliance research published in August 2026 found responsibility for hybrid and multi-cloud security policies spread across security operations, network operations, cloud architects and DevOps teams. Sixty-seven per cent of respondents used three or more security management consoles every day.
This is where technology ownership becomes part of visibility itself. Knowing that a system exists isn't enough if nobody can establish who can change it, who monitors it, who approves its connections or who is expected to respond when something goes wrong. And as more of those systems begin taking action automatically, the information organisations need changes again.
Automation Changes What Organisations Need To See
A database can be available or unavailable. An application can be slow. A server can run out of capacity. Those are familiar things to monitor. Automation introduces a different question because the system isn't simply sitting there waiting to be used. It may be carrying out work. An orchestration platform can trigger processes across several systems.
An AI agent can call tools, retrieve information and perform actions on behalf of a person or another application. Visibility therefore has to follow activity, not just infrastructure. Broadcom's 2026 orchestration research gives us an idea of how incomplete that picture can already be.
Eighty-nine per cent of the 501 enterprise respondents reported audit issues related to orchestration, while only 54 per cent said they had proper audit trails for complex automation and orchestration processes. AI agents are entering an environment where automated work was already becoming difficult to follow.
Activity needs to be visible as well as infrastructure
Knowing that an agent, workflow or automation exists tells you very little about what it's doing right now. An automated process may connect to several applications, move data between them and trigger another workflow without any human interaction. An agent may decide which tool to use based on its current task.
For operations teams, runtime visibility therefore has to include interactions as well as components.
- What did the system call?
- What information did it use?
- What action followed?
This isn't the same problem as reconstructing a complete historical record after something has gone wrong. It is much more immediate. Teams need enough context while automated systems are operating to recognise when behaviour has moved outside what was expected. But seeing an action is only part of the picture. Organisations also need to know what the system is allowed to do.
Authority creates another visibility requirement
Two AI agents could behave in exactly the same way while carrying very different levels of risk. One might be able to retrieve a document. Another could change a customer record, approve a transaction or trigger activity in another system. That difference comes from authority.
As agentic AI and automation become more capable, system visibility increasingly needs to include permissions, boundaries and delegated authority alongside behaviour. Leaders need to know not only what an automated system is doing, but what actions the organisation has made possible in the first place. This brings the visibility problem out of the monitoring console and into governance.
Fragmented Visibility Becomes A Governance Problem
Governance depends on information. A leader can't make a meaningful decision about a system without knowing enough about what the organisation is responsible for, how that system connects to others, what it is doing and who owns the outcome. This is where the visibility crisis starts becoming an enterprise problem rather than an operational inconvenience.
IBM's 2026 research of 2,000 C-level technology executives found that 70 per cent said business teams were deploying technology faster than IT could track it. At the same time, 77 per cent said AI adoption was already outpacing their organisation's governance capabilities. Those two findings belong together.
If technology expands faster than an organisation can establish where it is being used, how it connects and what it can do, technology governance will always be trying to catch up.
Responsibility can extend beyond control
This creates an uncomfortable position for technology leaders. Two-thirds of the CIOs and CTOs in IBM's study said they were being held accountable for AI systems they didn't fully control. That mismatch is becoming more common across enterprise technology. A CIO can be accountable for service continuity without controlling every cloud provider underneath it.
A CISO can be responsible for security while business units introduce new SaaS and AI tools. An infrastructure leader may depend on platforms operated entirely by another company. Organisations don't need complete technical control over every dependency. That isn't realistic.
They do, however, need enough visibility to understand where control ends, where dependency begins and who remains responsible for the consequences.
Local visibility doesn't create an enterprise view
This is why giving every team a better dashboard won't necessarily solve the problem. The network team can have excellent network visibility. The cloud team can understand its environment perfectly. The security team can know exactly what its tools are reporting.
None of those views automatically explains what happens when one business service stretches across all three. That fragmentation has practical consequences. In CSA's August research, 65 per cent of organisations had experienced at least one business-critical application outage caused by a misconfigured security policy during the previous 12 months.
Responsibility for those policies was spread across several different teams. The enterprise view has to connect those local views around the systems and outcomes the organisation is actually trying to govern. Which raises a more useful question than whether an organisation has enough dashboards. What would enough visibility actually look like?
Governability Requires More Than A Dashboard
Perfect visibility is probably the wrong target. Modern enterprises change too quickly, depend on too many external services and contain too many moving parts for any organisation to maintain a flawless real-time picture of everything. The more practical goal is governability.
An environment is governable when the organisation can establish enough about its systems, relationships, behaviour and ownership to make responsible decisions about them. That creates a much more useful way for technology leaders to test whether their current visibility is actually doing the job.
Can we identify what we're responsible for?
Start with the boundary. Can the organisation identify the systems, services, software, AI applications and automated capabilities operating within its area of responsibility? This doesn't require one magical inventory containing every technical detail.
It does require enough asset visibility to recognise when new technology enters the environment and determine whether somebody needs to manage it. If the first time a team discovers a system is during an incident, an audit or a cost review, discovery is happening too late.
Can we see how those systems connect?
An inventory gives you components. Governance also needs relationships.
- Which applications rely on the identity provider?
- Which workflows depend on an external API?
- Which business service uses a particular AI model?
- What stops working if a provider becomes unavailable?
Good dependency mapping helps organisations understand where a technical problem can become an operational one. The aim isn't to document every possible connection forever. It is to make the dependencies behind important systems visible enough that leaders aren't discovering them for the first time when something breaks.
Can we see what automated systems can do?
Automation adds behaviour and authority to the picture. Teams need to know which systems can initiate actions, which resources they can access and where their permissions allow them to change something consequential.
That becomes especially important for AI agent visibility because agents can make choices about how to complete a task rather than following one fixed sequence every time. The useful question isn't simply whether an agent is running. It is whether the organisation can see enough of its activity and authority to recognise when intervention may be needed.
Can responsibility be traced across the environment?
Finally, technical visibility needs an organisational counterpart.
- Who owns the system?
- Who owns the data moving through it?
- Who approves changes?
- Who is responsible for an external dependency?
- Who has the authority to stop an automated workflow?
Those questions sound administrative until nobody can answer one during a real problem. Clear system ownership connects the technical picture to the people expected to act on it. Without that connection, organisations can know a great deal about what their technology is doing while still being unsure who is responsible for deciding what happens next.
Taken together, these questions change visibility from something organisations buy into something they design for.
Visibility Needs To Become A Property Of Governed Systems
For years, visibility has often been treated as something added around technology. Build the application. Deploy the infrastructure. Connect the service. Then instrument it so the operations team can monitor what happens. That order becomes less convincing as systems grow more interconnected and more capable of acting independently.
If organisations need to know an AI agent's permissions, understand a service's external dependencies or trace ownership across an automated workflow, those requirements are much easier to establish while the system is being designed than after it has become operational. Visibility by design doesn't mean recording everything forever.
It means deciding what the organisation will need to know before it accepts responsibility for the system. The observability industry is beginning to move in this direction too. In May 2026, the Cloud Native Computing Foundation graduated OpenTelemetry, the vendor-neutral framework for collecting metrics, logs and traces, reflecting its maturity and widespread production adoption.
Standardised telemetry can't solve the entire visibility problem. It can make information easier to collect and move between systems without tying every source to one proprietary monitoring platform. That becomes increasingly useful as observability strategy moves beyond asking whether a service is healthy.
The harder task is connecting technical information to system relationships, automated behaviour, ownership and the decisions leaders are expected to make. Visibility then becomes part of how a system remains governable throughout its life, not simply something operators look at after deployment.
Final Thoughts: You Can't Govern What You Can't See
The strange thing about the modern visibility crisis is that it is happening while enterprise technology becomes more observable. Organisations can collect extraordinary amounts of information about what their systems are doing. What they're struggling to maintain is a coherent view across the expanding technology estate those systems now form.
That distinction becomes more important as cloud services, AI, automation and external platforms take on larger roles in enterprise operations. Knowing whether individual components are working doesn't automatically tell leaders what exists, what depends on what, what an automated system can do or who owns the result.
Visibility isn't the same as understanding a system. It doesn't prove what happened after the fact, and it doesn't give an organisation control over every dependency. But it increasingly sits underneath all of those things. The practical goal therefore isn't perfect system visibility. It is enough visibility to govern the technology the organisation has chosen to depend on.
As those dependencies continue to spread across AI, infrastructure, security, data and automation, that question is only going to become harder to separate from the wider conversation about enterprise governance. EM360Tech will keep following how those systems evolve, and what technology leaders need to know to remain accountable for increasingly capable environments they may never be able to see completely.
Comments ( 0 )