Every operations team I speak with is being asked the same question: where can AI take work off our plate? It’s the right question. The wrong answer is to give an AI agent write access to production systems and hope it behaves.
Security teams already know why. Any system that can change live infrastructure is part of your attack surface. An agent that can reassign who gets paged, add a user, or acknowledge an alert can also cause an outage, hide a problem, or grant access to someone who shouldn’t have it. It doesn’t need to be malicious to do damage. It only needs to be confidently wrong at 3 a.m.
When we built Ada AI Assistant at AlertOps, we started from that risk. Ada does real work inside our incident management platform. She can create a group, add someone to it, acknowledge an alert, build a shift, schedule an out-of-office with cover, or set up a new user account. That is exactly why we decided Ada had to earn three things first. I’d hold any AI agent to the same standard, including ours.
1. It works from live data, not a copy
Operations data goes stale fast. Schedules change, overrides get added, people go on leave. An agent answering from last night’s sync gives you an answer that looks right and isn’t. If it names the wrong person as covering a critical service, the alert goes to someone who isn’t watching.
Copied data is also a security problem. A cache sitting outside your permission model is one more place sensitive information can leak from.
Ada reads live data at the moment someone asks. Nothing is cached overnight. Before Ada proposes anything, she checks it against the real schedule: who is actually available, who already belongs to a group, and what the current rotation says. If a name in a request doesn’t match anyone active, Ada flags it and offers the real options instead of guessing.
Ada also works inside the access controls a team already has. She is not a way around them. If a role can’t see a schedule today, asking Ada won’t change that. Least privilege has to apply to an AI agent as strictly as it applies to people.
2. It shows you the change before it makes it
There’s a big difference between an agent that recommends and an agent that acts. Most of the risk sits in that gap.
Ada does the tedious part. She takes requests the way people actually write them, typos and all, and works out what is being asked and who it affects. Then she stops. Ada puts the change in front of a person, with the who, the when, and what it replaces spelled out, and waits for a decision.
Approve it, and it applies. Turn it down, and it cancels cleanly. No half-built group, and no stray override left in the schedule to cause trouble next week.
This isn’t about distrusting AI. It’s the same principle behind change approval and two-person rules in any well-run security program. An AI agent proposing a shift swap or a new user account should be treated no differently from an engineer proposing a firewall change. We sum it up simply: Ada proposes. She never decides.
Two more details matter. When a request is missing something, like which team or which alert, Ada asks rather than filling the gap herself. And when a question falls outside what she is built to handle, Ada says so plainly. A plausible guess is more dangerous than an honest question, because nobody thinks to check it.
3. It leaves a record with a name on it
When something goes wrong in operations, the first question is “who changed this?” If the answer is “the AI did,” you have a governance problem.
Every change Ada proposes happens inside the AlertOps platform, so the change and the person who approved it stay visible to the team. It doesn’t live in someone’s head or an untracked side conversation.
That trail is what makes AI-assisted operations auditable. It keeps accountability with the people who approved each change. For organizations in regulated industries, it’s what turns an AI feature into something a compliance team can sign off on.
Why we built Ada this way
Infrastructure is growing faster than the teams responsible for it. Cloud environments scale by the week, and AI is speeding up how quickly new services come online.
Much of what slows teams down during an incident isn’t the hard technical work. It’s the small tasks that land at the worst time: moving coverage when someone’s flight is delayed, adding a backup to a rotation, setting up a new team member. Each one is quick, but it pulls attention from whoever is already stretched thinnest. Ada can put that change together in seconds, so the engineer stays on the incident and a person still makes the call.
We named Ada after Ada Lovelace, who in 1843 described a machine that could do more than calculate. That felt right. Ada doesn’t just answer questions. She does useful work, within limits a security team can trust.
If you’re evaluating AI for your operations stack, ask every vendor, including us, three questions:
- Where does the data come from?
- Who approves the change?
- Where is the record?
If the answers are vague, the agent hasn’t earned access to your live systems yet.
_____
About the author
Kamalesh Srikanth is VP of Product and Customer Operations at AlertOps, an enterprise incident management and alerting platform. His work centers on how operations teams detect, route, and resolve critical incidents at scale, with a focus on reducing alert noise and shortening time to resolution. He helps companies build incident response practices that keep mission-critical infrastructure running and their on-call teams sane.
Join our LinkedIn group Information Security Community!
