We're past the point where people just use ChatGPT or Copilot. Teams are now building small automations around them.
Nothing huge on its own. Someone connects one to a spreadsheet. Someone else has one reading documents. Another team has something tied into Slack or email that drafts replies, updates records or moves work to the next step.
Each one makes sense when it's built. It saves an hour a week, fixes an annoying handoff, or fills a gap no tool covered.
The part worth thinking about is what happens 6 to 12 months later.
It Starts Small
Most AI automations inside a company don't start as projects. They start as a shortcut:
A marketing manager builds a flow that summarizes campaign results from a spreadsheet and posts them to Slack.
A sales rep sets up an assistant that drafts follow-up emails from call notes and updates the CRM.
An operations lead connects a document reader to a shared drive so it can answer questions about internal processes.
A finance analyst automates part of a monthly report by pulling numbers from three systems.
None of these go through a formal review. They don't need to. They're small, useful and built by the people closest to the work.
Multiply that across every team, and within a year a company can have dozens of these running quietly in the background.
Shadow IT, Again, But Different
This pattern has a name. Years ago it was called shadow IT: teams buying their own software without IT knowing. The industry is now calling the new version shadow AI.
The difference is important. Most shadow IT tools stored data somewhere. Many AI automations do things. They send messages, update records, move files, change statuses and trigger the next step in a process.
That means they don't just sit beside a workflow. They become part of it.
The 6 – 12 Month Problem
When an automation is new, everyone knows what it does. Six months later, the questions start:
Who owns it? The person who built it may have changed roles or left the company.
What is it connected to? Which spreadsheet, inbox, channel, CRM field or shared folder does it read from or write to?
Why was it built? What problem was it solving, and does that problem still exist?
What depends on it? Which reports, handoffs or decisions quietly rely on it running every day?
What changed when it was added? Did a step disappear? Did a person stop doing a check because the automation "handles it"?
Most teams can't answer these for automations built by other teams. Often they can't answer them for their own.
Why This Is an Operations Problem, Not Just an IT Problem
Shadow AI is usually discussed as a security or data governance issue. That matters, and it belongs with your IT and security teams.
But there is a second problem that gets less attention: the organization stops being able to see how its own work flows.
When a process includes a mix of people, tools and automations nobody fully tracks, a few things happen:
Processes change without anyone deciding to change them. Automation quietly replaces a step, and the documented process no longer matches reality.
Problems become hard to trace. A metric moves and nobody connects it to the automation that started behaving differently.
Handoffs become invisible. Work passes from a person to an automation to another team, and the middle step is nowhere on the process map.
Knowledge leaves with people. When the builder moves on, the "why" behind the automation goes with them.
This is the same kind of fragmentation companies already struggle with across their tools. AI automations just make it happen faster, and in more places at once.
Signs It's Already Happening
You may already have a shadow AI visibility problem if:
Nobody can list every AI automation running across the company.
A report or workflow broke and it took days to find which automation caused it.
Different teams built separate automations to solve the same problem.
Your process documentation doesn't mention automations people rely on every day.
When someone leaves, their team discovers things "just stopped happening."
How to Keep Visibility Without Stopping Experimentation
Banning these automations rarely works, and it throws away real productivity gains. A better approach is to make them visible:
Keep a simple inventory. For each automation: what it does, which systems it touches, and who built it.
Give every automation an owner. Not just the builder. Someone responsible for it if the builder moves on.
Record the "why". One or two sentences on the problem it solves. This is the part people forget first.
Map it into the process. If an automation is a step in a workflow, it should appear in how that workflow is described.
Review regularly. Every quarter, check what is still used, what overlaps and what nobody owns anymore.
Bring in IT and security early for anything that reads sensitive data or sends things outside the company.
None of this needs to be heavy. The goal is that six months from now, someone can still answer "what is this, who owns it, and why does it exist?"
Where Aitora Fits
Aitora is an organizational intelligence layer. It is being built to show how work actually moves across an organization: between people, systems and processes, including the automations that now sit between them.
Aitora is not a security or data governance product. Its focus is operational visibility: seeing which steps in a workflow are handled by people, which by tools, where handoffs happen and what changed when something started slowing down. As more work runs through small automations, that connected view matters more, not less.
Want to see how work really flows across your teams? Get a free workflow diagnostic.
FAQ
What is shadow AI? Shadow AI is the use of AI tools and AI-powered automations inside a company without central visibility or approval. It often starts with individual teams building small automations around tools like ChatGPT or Copilot.
Is shadow AI the same as shadow IT? It's closely related. Shadow IT usually meant unapproved software or storage. Shadow AI includes automations that can take actions, such as sending messages or updating records, which makes them part of how work actually gets done.
Why does shadow AI matter for operations teams? Because automations quietly change processes. Over time, the documented way work flows stops matching reality, and problems become harder to trace back to their cause.
How do you track AI automations across teams? Start with a shared inventory that lists what each automation does, which systems it connects to, who owns it and why it was built. Review it regularly.
Should companies ban employee-built AI automations? Usually not. Bans tend to push the activity further out of sight. Making automations visible and owned keeps the productivity benefits while reducing the risk of things breaking silently.
Who should own AI automations in a company? Each automation should have a named business owner, usually in the team that relies on it, with IT and security involved for anything touching sensitive data or external systems.
