According to IBM's 2025 Cost of a Data Breach Report, organizations took an average of 241 days to identify and contain a security incident — the lowest figure in nine years, and still nearly eight months before a company understands what actually happened. The same report includes a specific finding about AI: among organizations that experienced an AI-related incident, 97% admitted they lacked proper access controls at the moment the problem occurred.
The pattern behind that number is always the same. When AI use happens through personal tools, outside the systems a company actually manages, there is nothing left to reconstruct afterward: no record of who asked for what, with what information, under whose authorization. The investigation doesn't become difficult — it simply has no material to start from.
For anyone deciding on technology, that gap tends to go unnoticed day to day. It only shows up on the day someone asks what happened, and the answer is "we don't know."
When the incident hits, the question never changes
Every incident investigation opens with the same questions: what happened, when, and under whose order. Legal asks to assess exposure. Insurance asks to decide on coverage. A regulator asks to decide whether there was negligence. Without an answer, a company isn't just poorly informed — it is exposed on three fronts at once.
IBM's report, built from data on 600 organizations that suffered AI-related incidents, shows that this exposure is today the rule, not the exception: 63% of those organizations had no AI governance policy in place at all. Without a policy, the record that a formal policy usually requires rarely exists either — and the effect shows up directly in the bill: heavy use of AI outside company control (what the market calls shadow AI) added, on average, US$670,000 to the cost of each incident.
NIST's forensic techniques guide (SP 800-86), a US reference for security incident investigation, is direct about why: the ability to investigate depends on decisions made before the incident — which systems log events, at what level of detail, and for how long. An environment without that groundwork isn't "harder to investigate." In practice, it has no investigative capacity at all, because the evidence that would support reconstructing the facts never existed.
That's the point that usually gets lost in the conversation about AI use at work: the risk isn't only the sensitive data that might leak into a conversation with a personal assistant. It's the absence of any trail that would later let someone say, with confidence, what happened and why.
Why the common safeguard solves nothing
The most common corporate response is an acceptable-use policy: a document stating what can and can't be done with AI. It matters, but it solves less than it seems to — because a policy doesn't generate a record. It states an intention; it doesn't produce a queryable fact afterward.
In August 2024, security agencies from nine countries — led by Australia's Signals Directorate together with the US CISA, FBI, and NSA, plus the UK, Canada, New Zealand, Japan, South Korea, and Singapore — published a joint guidance on event logging. The document's opening line sums up the point well: event logging "supports the continued delivery of operations and improves the security and resilience of critical systems by enabling network visibility." Nine national security agencies agreeing to jointly publish guidance on this specific topic is a strong signal of how critical it's considered — and not only for large governments: the principle holds for any system processing sensitive information, including corporate AI use.
The problem is that most AI tools used inside companies today weren't designed with that standard in mind. A personal-account assistant doesn't tell the employer what action was taken, on which document, or whether anyone approved it before it went forward. The policy exists on paper; the record exists nowhere.
What has to be in place
An AI environment ready to be investigated is defined by verifiable mechanisms, not a statement of intent.
Corporate identity, not a personal account. Access to AI comes from the same directory that controls access to email and internal systems. That means every action is tied to a real person inside the company, not to an account no one else can see.
Access by each person's role. When what each person and each agent can do is defined by role, the list of suspects in an incident starts out smaller — and more precise.
Recorded human approval before sensitive actions. Critical documents may require two-step review and approval, with the person writing separated from the person approving, and the decision recorded at the moment it's made — not reconstructed from memory weeks later.
A detailed audit trail by system area. Creating an agent, approving a document, changing a permission, executing a sensitive action: every one of those events gets recorded with who, when, and what. That's exactly the material missing in the 97% of AI incidents without adequate access controls that IBM cites.
That's how Skyller was designed: identity coming from the company directory, recorded approval, and an audit trail as the default from day one of use, not as an add-on configured later.
From minutes-long reconstruction to audit confidence
The most obvious benefit of a complete record shows up at the worst possible moment — in the middle of an incident, when the security team needs to know, fast, how far the problem reaches. With an audit trail, that reconstruction takes minutes: search by person, by document, or by time window and see exactly what happened.
But the benefit goes beyond the day of the crisis. An external audit, a security certification, or a larger client's contractual requirement usually asks for evidence of control, not just the existence of a policy. A company that can show corporate identity, role-based permission, and a complete approval history goes through that process with concrete evidence in hand — instead of explaining, after the fact, why the record for that specific period doesn't exist.
There's also a less-discussed effect: when a team knows the AI environment is auditable, usage tends to become more responsible on its own, without needing a ban to get there. An audit trail isn't about distrusting the people who work there — it's about making sure that, if something ever needs explaining, the explanation exists.
That same record also simplifies decisions about new tools. Instead of approving an AI system "on trust" and hoping nothing goes wrong, the IT team gets an objective evaluation criterion: does the system record identity, action, and approval in a queryable way, or doesn't it? The question is simple, and the answer quickly separates what's ready for corporate use from what's still a personal tool.
Three questions to bring to the next meeting
Before assuming the company is covered on this front, it's worth honestly answering three questions with IT and legal:
- If we had to prove today who approved a document AI used three months ago, could we? If the answer depends on asking the people involved, the company doesn't have an audit trail — it has memory.
- Can someone outside the IT team query that history without asking for technical help? A record only the engineering team knows how to open doesn't serve an investigation run by legal or an outside auditor.
- How long would it take to reconstruct what happened in an AI-related incident, today? If the answer is measured in weeks, the company is at the same starting point as the organizations IBM measured — 241 days to understand their own incident.
