A data organisation can spend years getting business intelligence right: a clean warehouse, sensible reporting, permissions that make sense for the analysts reading the output, and still be unprepared for the moment AI agents start acting on that same data. That is a pattern we keep finding, and it is worth naming on its own: BI and AI are not the same problem, even when the data underneath both is identical.
We were brought into this piece of work through an internal audit function, not a security team, and that itself is a signal. The concern was not a specific breach; it was that nobody could say with confidence what the organisation's growing population of internal AI agents could actually reach, or who was accountable when one of them got something wrong.
The client is a global software platform provider whose data function had been built, reasonably, around business intelligence: a central warehouse, a small data team, and a reporting layer serving the rest of the business. That architecture assumes a human analyst is the one reading the output. It stops holding once agents are the ones querying, deciding and triggering actions across system boundaries the original design never anticipated.
The findings followed a pattern we now recognise from more than one engagement of this kind. Definitions of the same entity varied across business units. Access permissions were managed system by system, with no automatic propagation into the warehouse: a manual process, and an error-prone one. There was no consistent criterion for what counted as a ‘critical system’. Sensitivity tagging existed only at the table level, never at the field level, which meant a table could be flagged as sensitive while the one column that actually mattered sat unmarked next to nine that did not.
Most significant of all: there was no inventory of the AI agents themselves, no register of what each one could reach, and in more than one case only the person who built an agent could say with certainty what it actually did. When ownership is unclear, the question of who is accountable if an agent leaks data or acts incorrectly, whether the CISO, the developer, or the business owner who requested it, has no answer prepared in advance.
We ran the engagement across three lenses at once rather than handing over three separate opinions that did not connect: governance and controls, security, and AI operations. That combination is unusual, and it mattered here: a governance gap that looks abstract on its own becomes concrete the moment you can show exactly which agent, touching which table, makes it real.
The output was not a compliance checklist. It was a repeatable findings pattern the client's leadership could act on, framed as an operational and value risk rather than an abstract security finding, plus a prioritised path to close the specific gaps, starting with an inventory of agents, their data reach, and named ownership for each one.
The findings reached the client's audit committee, which is the outcome that matters most for an engagement like this: the gap stopped being invisible. Turning that visibility into a funded programme of work is, at the time of writing, still a decision in progress on the client's side, which is itself a common and honest outcome for a diagnostic of this kind, not a failure of it.
The pattern is not specific to one company. Any organisation whose data governance was built for business intelligence, and is now watching AI agents operate across the same data, is looking at the same blind spots. That is why we scope the first engagement of this kind as a diagnostic with a pre-priced pilot already built in, not a report that gets filed away while the agents keep multiplying.