Working definition
AI assistance belongs inside an operational control path.
In GAEZLA, AI-assisted infrastructure operations means using a configured model to help with a specific operational task while the product continues to define what context is available, which tools may be used, what record is retained, and how any external change is authorized.
It does not describe a general-purpose autonomous operator. The model does not receive one universal connection to the estate, and a useful answer does not automatically become permission to change a system.
Implemented workflows
Where configured models can assist today.
These product surfaces use AI differently. Their inputs, failure behavior, retained records, and paths to action are not interchangeable.
Investigation
Work from a target-bound case.
A configured model can use the typed read capabilities available for the resolved target, test hypotheses, and help produce an operator summary. Evidence, findings, hypotheses, chronology, and transcript remain attached to the case.
Alert qualification
Make uncertainty visible.
Guarded inference can help qualify a normalized signal. The retained decision includes its outcome, confidence, model state, reasons, and evidence. Unavailable or low-confidence qualification falls toward operator review rather than silent suppression.
Adapter drafting
Draft a shape, then preview it.
AI assistance can propose a custom graph-adapter shape. A dry-run preview remains non-persistent, while adapter mutations use a separate durable proposal with permission, evidence, approval, and optional step-up checks.
Control path
A model participates; the workflow stays in charge.
- 01
Choose the workflow and model policy
The operator configures the relevant provider or model policy for a named product workflow. A valid provider connection does not grant operational tool authority.
- 02
Resolve the working scope
The workflow identifies the case target, alert source, or adapter draft before model assistance is applied to the available context.
- 03
Use the workflow’s bounded capabilities
Investigation can use target-aware typed reads. Alert qualification works from normalized source events. Adapter drafting produces a shape that can be previewed.
- 04
Retain a reviewable outcome
Cases keep evidence and summaries, alert decisions keep confidence and reasons, and adapter previews remain separate from persistence.
- 05
Use a separate path for change
An eligible investigation mutation becomes an evidence-backed proposal with approval and policy-required step-up. Other workflows apply their own named controls.
Authority boundaries
Configuration, reasoning, reads, and changes are separate.
| Layer | What it establishes | What it does not establish |
|---|---|---|
| Provider and model policy | Which configured model path a named workflow can use. | Permission to read or change every connected system. |
| Workflow context | The target, event, configuration, and retained record relevant to the task. | A guarantee that every possible source was queried. |
| Typed read capability | A permitted current-state query through a configured connection. | A general mutation path or proof that the model’s conclusion is correct. |
| Action proposal | A durable request with evidence, scope, risk, safeguards, and rollback. | Approval or execution merely because the model proposed it. |
Investigation example
A question can end with evidence—not an automatic fix.
An operator can open a case for a failing service, resolve the target, and use the available read capabilities to collect current facts. The case can retain the evidence, hypotheses, investigation steps, findings, and summary even when no supported change is justified.
Question
What is failing?
The case begins with an explicit service, host, user, repository, environment, or other supported target.
Evidence
What can be checked?
Available sources depend on the resolved target, configured connections, tenant permissions, and integration policy.
Next step
What is actually supported?
The operator can retain the conclusion, continue investigating, or review an eligible evidence-backed proposal on its own path.
Boundaries
What AI-assisted infrastructure operations does not promise.
Not an autonomous infrastructure operator
Model assistance occurs inside named workflows with explicit source, tool, record, and action boundaries.
Not universal visibility
A workflow only sees the sources and capabilities available for its configured target, connection, permissions, and policy.
Not guaranteed root cause
An investigation can retain useful evidence and uncertainty without guaranteeing that it found the cause or safest remediation.
Not automatic execution
A model response is not change authority. Eligible investigation mutations use a separate proposal and approval path.
Not one universal AI lifecycle
Cases, alert decisions, adapter drafts, proposals, managed jobs, and their results remain distinct product records.
Evaluation checklist
Questions to ask about AI in infrastructure operations.
- Which exact workflow invokes the model, and who configures its model policy?
- How is the target or source resolved before context is gathered?
- Which reads are available, and which permissions and connections constrain them?
- What happens when inference is unavailable, invalid, or low confidence?
- Which evidence, reasoning, confidence, and output remain reviewable?
- Where does model assistance end and external change authority begin?
- What record owns approval, execution, failure, rollback, and retry?