Details
Why avoiding formal AI automation does not eliminate production risk—and how leaders can create a governed path toward trusted, evidence-based operations.
Production teams may already be using AI to investigate incidents, even when organizations have not formally deployed AI automation. This creates a governance gap in the environment where errors can have the greatest business impact. NeuBird AI Field CTO Francois Martel explains how leaders can close that gap through evidence-based investigations, controlled access, human approval, operational guardrails, and an earned-autonomy model that expands AI’s role only as trust is established.
Production teams may already use general-purpose AI tools to interpret alerts, troubleshoot failures, or recommend actions. When that activity happens through individual chat sessions, organizations may have no consistent approval process, audit trail, or record of the context behind a recommendation.
The absence of formally deployed automation can therefore indicate an absence of governance rather than an absence of AI-related risk.
AI-assisted development typically operates within established controls such as code review, testing, version history, and approval workflows. In production operations, where a mistake can affect revenue and customer trust, AI usage may be less visible and less structured.
This is the “Production Inversion”: governance decreases as the potential blast radius increases.
Operational information is often distributed across logs, traces, alerts, tickets, dashboards, and separate monitoring tools. Engineers must manually correlate information across these silos while contending with both missing alerts and excessive alert volume.
An operations-focused AI agent can help assemble this fragmented context, investigate relationships, and provide evidence-backed findings.
The session does not advocate giving AI unrestricted control over production. Instead, it presents an “earned autonomy” model.
AI can begin by gathering information and identifying probable causes. Once teams have evaluated its accuracy, it can advance to recommending actions with human approval. Only trusted, well-defined interventions should eventually become candidates for automatic execution.
An investigation should show more than a conclusion. Engineers need to see the underlying data, the relationships between affected components, the reasoning that led to the finding, and the proposed remediation.
In the demonstration, NeuBird traced an order-service latency problem to an Oracle-related failure and presented supporting evidence and a remediation plan.
Reactive investigations begin after an alert or incident. Proactive investigations can evaluate system health, capacity, recent pull requests, open tickets, and operational risks before an issue becomes a page.
The leadership metric introduced in the abstract is the share of degradations detected and resolved before they page anyone—not only how quickly teams recover after failure.
Informal AI use can create invisible operational risk
Practical implication: Determine where engineers are already using AI during production investigations and bring that activity into an approved, accountable workflow.
Production AI needs controlled access to operational context
Practical implication: Connect AI only to the data sources and tools required for its role, with clear ownership over the data path.
Trust should develop through observable performance
Practical implication: Begin with read-only investigations and evaluate the accuracy, supporting evidence, and operational value of the results before expanding access.
State-changing actions require guardrails
Practical implication: Pair every write-enabled tool with explicit rules defining when it may be used, what prerequisites must be satisfied, and when human approval is required.
Investigation reasoning should be auditable
Practical implication: Preserve the evidence and reasoning behind recommendations—not merely the action ultimately taken.
Operations should measure prevention
Practical implication: Track how many degradations are detected and resolved before they trigger an alert, page, or customer-facing incident.
Repeated investigations should build organizational knowledge
Practical implication: Preserve useful operational context so that previous investigations improve future analysis instead of forcing engineers to start from scratch.
Q: What is the Production Inversion?
A: The Production Inversion describes a mismatch between risk and governance. AI may be heavily controlled during software development but used through informal, less auditable workflows in production, where the consequences of a poor recommendation can be greater.
Q: Does avoiding AI automation remove production risk?
A: No. Engineers may already be using AI to analyze production problems or generate recommendations. Without a governed platform, that activity may occur without consistent controls, approval paths, or records.
Q: What does “earned autonomy” mean?
A: Earned autonomy is a gradual adoption model. AI begins with information gathering and read-only investigation, advances to actions requiring human approval, and receives limited automatic authority only after it has demonstrated accuracy within a defined use case.
Q: How can AI help with fragmented production data?
A: An operations AI agent can investigate information across logs, traces, alerts, tickets, dependencies, and enterprise knowledge. This can reduce the manual work required to correlate signals stored in separate systems.
Q: How does NeuBird support evidence-based investigations?
A: The demonstration shows an automatically triggered investigation that identifies a probable cause, links the conclusion to supporting data, explains the failure mechanism, and produces a remediation plan.
Q: What happens when an automated action violates a guardrail?
A: In the example, an Ansible remediation was blocked because the system could not open the required Jira ticket. The guardrail prevented the remediation from proceeding without a required prerequisite.
Q: What is the difference between reactive and proactive investigations?
A: Reactive investigations begin in response to an alert or incident. Proactive investigations run on a schedule or defined trigger to assess system health, capacity, recent code changes, and other risks before an incident occurs.
Q: What production metric should leaders request?
A: In addition to mean time to resolution, leaders should ask what share of degradations are detected and resolved before they page an engineer or affect customers. This measures prevention rather than recovery alone.
Q: What controls should a governed production AI path include?
A: The abstract identifies four requirements: operation within the organization’s controlled environment, human approval for state-changing actions, an audit record that preserves reasoning as well as outcomes, and durable context that improves future investigations.
Francois Martel: Welcome to this 10-Minute Take. My name is Francois Martel, and I’m Field CTO at NeuBird AI.
Today, we’re going to talk about the Production Inversion and what CTOs get wrong about AI in production.
AI in production is something that people hesitate to adopt. They feel that giving automation to AI is dangerous.
Of course, we’re not advocating that you allow AI to control everything in production automatically. However, so much is happening in production that its complexity has outpaced human understanding.
AI automation can deliver the information needed to address some of the fundamental problems people face in production: the correlation tax, silent outages, and the alert-suppression penalty.
The typical production environment is highly reactive. You ingest information into multiple silos rather than one unified system. Your team must work across those silos.
You might have agents within each silo accelerating its individual processes, but you also need something that can look across all your production context.
You have silent outages, meaning alerts are missing, while simultaneously having too many alerts. Something has to change.
This is where AI in production can reduce your risk rather than increase it. It reduces risk by addressing fundamental limitations in current approaches.
Dashboards show you what is broken. They give you information that helps you find the root cause and fix it. AI, however, can look for incidents before they happen and help prevent them from occurring in the first place.
The future of production should be a world in which AI can support the entire process—from alert or incident detection and prevention through automation.
Automation is the part people typically fear, but it should come last. First, AI needs to earn the organization’s trust.
We call this process “earned autonomy.” Initially, AI helps humans identify problems and their root causes. Eventually, it can perform more of the automation.
You begin with information. You then move to human-in-the-loop intervention. For selected interventions, automation may eventually happen automatically after the AI has earned sufficient trust.
Let me explain how we build that trust.
First, we have a production operations agent connected to your tools and data. It works within your workflows.
We are SOC 2 compliant. We offer a SaaS solution, but you can also deploy it within your environment. The model is never trained on your data, the full data path remains under your control, and the operations agent fits into your workflow and works with your existing data sources.
That is very important.
Second, we have a foundation of data enrichment that allows us to achieve high accuracy. That is the first step toward earning trust in production and eventually enabling greater autonomy.
At the bottom of this diagram, you can see the data connections. We create enriched semantic information about your dependencies, how your logs and traces are organized, your alerts, and your enterprise knowledge.
The agent performing the work can be triggered through Slack, Microsoft Teams, our user interface, or AI agents deployed on employee desktops.
The resulting investigations have access to a much richer dataset. They can also improve over time as additional investigations are completed.
I’ll give you a short preview of what that looks like so you can see how we build trust.
Here, we see the result of an investigation that was automatically triggered by an alert.
The signal context was an order-service latency issue. If I open the report, you can see that the system completed the investigation in five minutes and estimated that it saved approximately two hours of people’s time.
The investigation identified Oracle as the cause of the failure.
We support every conclusion with evidence. That is how we earn trust.
You can see where the data came from. In this case, code was executed to retrieve the data. You can then see the mechanism that connected the database failure to the latency issue.
This allows you to understand why the problem is happening and ultimately reach a remediation plan that explains exactly what to do.
This evidence-based approach produces an action plan within five minutes. The Level 1 team can route that plan directly to the database team, avoiding a 2 a.m. call involving teams from networking, cloud engineering, platform engineering, application engineering, and databases.
Very quickly, we have identified a cause and developed a plan of action.
From there, you can evolve the system as you gain more trust in the AI. As you see that it is accurate and that it helps reduce root-cause analysis time, you can begin giving it tools that support automation.
In this example, an Ansible automated remediation was blocked because the system could not open a Jira ticket, which was one of my guardrails.
This demonstrates that we always deploy automation with guardrails.
We have a way to explain to the AI the exact rules governing how and when it should use an automation.
Most tools will be read-only by default. When you grant write access, you should pair that access with a guardrail describing exactly what the tool is permitted to do.
Investigations like the one we just reviewed are reactive because they are triggered by an incident.
You can also create what we call agent tasks, which perform proactive investigations.
An agent task could, for example, run a health check every morning and then provide a report.
In this example, I have a health-check report showing health ratings for my major data sources. It also lists my open tickets and organizes identified items according to high, medium, and low risk.
With proactive investigations, we can help identify issues before they occur.
Investigations can perform capacity-planning checks, health checks, and risk assessments on recent pull requests. You then receive an action plan explaining how to address the risks the system identified.
Thank you for your attention today.
If you’re interested in learning more, visit NeuBird.ai. There, you can learn more about our solution and request a demonstration to explore how NeuBird can help you use AI to run production safely.
Presenters:
Francois Martel
Field CTO
Join Now for More Content & Events
For event and sponsorship inquiries, please email: [email protected]
