You're Already Accountable for AI You Can't See

    :          ~        .       
  INVISIBLE AI / VISIBLE RISK   
     ~   ~ ~   |   :            
  +--------+~: |                
  |   ~  ~ |  :|  +---------+   
  +--------+------|--+      |   
~~   ~ ~~| :      |  |      |   
 ~+--------+      | actor   |   
  |~     | |PERMIT|evidence |   
  +--------+ACCOUN|Apolicy  |:  
   ::    |        |  |      |   
  +--------+------|-scope   |: ~
  |browser |   |  +---------+  ~
  +--------+   |             ~~ 
               |            ~~~ 
                        :~~~  ~ 

The uncomfortable part of shadow AI is not that employees are experimenting faster than IT can approve tools. That has been true for every useful software category.

The uncomfortable part is that accountability has already moved.

An IBM global survey of CIOs and CTOs found that roughly two-thirds are being held accountable for AI systems they do not fully control. Only a small minority said they were fully prepared for AI agent scale. That is the executive problem in one sentence: the board expects an answer, the business expects autonomy, and the technical owner is left explaining systems that may have been bought, embedded, or used outside the normal path.

When something goes wrong, nobody asks whether the AI was convenient.

They ask who approved it.

Accountability moved faster than visibility

Most enterprise AI programs now have two realities.

The first is the official reality: approved vendors, procurement reviews, policy documents, steering committees, architecture diagrams, and model evaluations.

The second is the operating reality: personal AI accounts, department-level pilots, browser extensions, agents wired into workflow tools, product features calling model APIs, and employees moving data into whatever system helps them finish the work.

That split is not just messy. It breaks the accountability chain.

If a regulator, customer, insurer, or board member asks what happened, a CISO or CIO needs more than a list of approved tools. They need to show:

1. which AI system acted
2. who or what gave it authority
3. what data and workflow were in scope
4. which policy version applied before the action
5. what record proves the answer was not reconstructed afterward

That is a proof problem, not a communications problem.

Shadow AI is now breach context

Verizon's 2026 DBIR brought shadow AI into the mainstream breach conversation. Coverage of the report highlighted that nearly half of employees use AI at work, that most of those workers use personal accounts, and that shadow AI has become a major source of non-malicious data leakage.

IBM and Ponemon's 2025 Cost of a Data Breach research points in the same direction from the cost side. IBM reports that AI is outpacing security and governance, that 97% of organizations reporting an AI-related security incident lacked proper AI access controls, and that 63% lacked AI governance policies to manage AI or prevent shadow AI proliferation. ITPro's coverage of the same report noted that high shadow-AI exposure added USD 670,000 to average breach cost.

The exact numbers will change. The shape of the risk will not.

AI systems are moving from advice to action. They read customer data, summarize records, draft regulated communications, call tools, update tickets, route workflows, and increasingly act on behalf of users. That means the evidence standard changes. A spreadsheet of tools is not enough. A policy acknowledgement is not enough. A dashboard that tells you what happened after the fact is not enough.

The accountable person needs proof at the boundary where authority is granted.

Policies do not create evidence

Policies matter. Training matters. Approved-vendor lists matter. DLP and network monitoring matter.

But none of those, by themselves, prove that a specific AI action was authorized before it ran.

This is where many AI governance programs quietly fail. They focus on whether the organization has a policy for AI use. The harder question is whether the system can produce a record showing that the policy was applied to this request, by this actor, against this resource, under this budget and risk context, before execution.

That distinction is the Keel touch.

Keel treats the decision as the artifact. Before a governed AI action runs, the application asks for a permit. The permit records who asked, what action was requested, which policy and budget state applied, what constraints were attached, and what decision was made. Later execution and closeout can attach to the same governed path, so the organization has something stronger than "trust our logs."

Not a promise that every unsanctioned browser tab has vanished.

Not a claim that no bad output can happen.

A narrower, more durable claim: for the AI actions routed through the governed path, you can show what was allowed, why it was allowed or denied, and what evidence survived after the fact.

The question to bring to the board

The useful board question is not "Do we have an AI policy?"

It is:

For the AI systems acting on behalf of the business, can we prove who gave them authority before they acted?

If the answer depends on screenshots, provider dashboards, and a team reconstructing events after an incident, the accountability gap is still open.

The organizations that close it will not be the ones with the longest policy document. They will be the ones that make authority explicit before execution and make the record verifiable afterward.

Decide before. Prove after. That is how accountability starts to match the systems already running.