The Future of Infrastructure and Operations: Six Strategic Priorities for Enterprise Success in 2026
Infrastructure and Operations now supports customer-facing services, software delivery, data platforms, cybersecurity, AI workloads, cost management, and business continuity. The 2026 priority is not to adopt every new platform. It is to operate a smaller number of well-governed capabilities that make important services reliable, secure, measurable, and economically sustainable.
Scope: This article discusses enterprise architecture, cloud, observability, artificial intelligence, automation, cybersecurity, sustainability, and technology operations. It is not legal, privacy, cybersecurity, regulatory, financial, environmental-reporting, procurement, engineering, or other professional advice. Requirements depend on the organization, workload, industry, data, threat model, service obligations, and jurisdictions involved.
The original 2025 article identified observability, MLOps, cybersecurity, automation, sustainability, and hybrid cloud as important trends. Those themes remain relevant, but the 2026 operating environment is more demanding.
Enterprises are no longer deciding only whether to use cloud or AI. They must decide which workloads belong where, how AI output will be evaluated, how telemetry will be governed, who owns internal platforms, how software and model supply chains will be secured, and whether technology cost and energy use are producing measurable value.
The six priorities below are therefore framed as operating capabilities—not predictions or mandatory technology purchases.
Quick Answer: What Should I&O Leaders Prioritize in 2026?
- Build observability around user-facing services and service-level objectives
- Operate AI through governed MLOps, LLMOps, and agent lifecycle controls
- Design cyber resilience across identity, software supply chains, cloud, AI, backup, and recovery
- Treat platform engineering and automation as internal products with measurable users and guardrails
- Manage technology value, AI cost, energy, carbon, and capacity together
- Place workloads deliberately across public cloud, private cloud, data centres, sovereign environments, and the edge
The strongest 2026 infrastructure strategy begins with critical services, operating risks, and measurable outcomes. Architecture follows those requirements.
What Changed From 2025 to 2026
The original article relied on several broad forecasts and adoption statistics that were either unsupported or no longer useful. These included a prediction that nearly 70% of enterprises would gain a competitive advantage from holistic observability and a forecast that 75% of enterprises would standardize automation by 2027.
The 2026 update removes those claims and focuses on observable changes:
- AI workloads now affect infrastructure, application operations, cybersecurity, data, finance, procurement, and energy planning.
- Organizations need operational controls for prompts, retrieval, evaluations, agents, tools, model versions, and AI cost—not only model deployment.
- Observability increasingly includes application, business, security, AI, and cost telemetry, which creates data-volume and governance problems.
- Platform engineering is being measured as a product capability rather than simply a collection of DevOps tools.
- Kubernetes is widely used among cloud-native survey respondents, including for AI, but it remains an operating commitment rather than a universal requirement.
- AI-driven data-centre demand has made power availability, cooling, carbon intensity, water, capacity, and geographic placement strategic constraints.
- Canadian policy in 2026 places greater attention on secure and sovereign AI compute infrastructure.
- Cybersecurity guidance increasingly addresses AI systems, AI-assisted threats, edge deployments, supply-chain integrity, and secure-by-design procurement.
The strategic shift
In 2025, many organizations asked which technologies to adopt. In 2026, the more useful questions are:
- Which business service depends on this capability?
- Which failure are we reducing?
- Who owns the platform in production?
- How will value, reliability, security, and cost be measured?
- Which data and decisions must remain under specific jurisdictional or organizational control?
- What is the fallback when an AI, cloud, network, vendor, or automation dependency fails?
I&O is strategic when it changes the reliability, security, speed, cost, and adaptability of an important business service—not when it deploys the largest toolset.
Priority 1: Observability Becomes Service-Centred Operational Intelligence
OpenTelemetry defines observability as understanding the internal state of a system through outputs such as traces, metrics, and logs. Instrumentation is required before those signals can be collected and analyzed.
In 2026, the stronger operating model connects technical telemetry to:
- User journeys
- Business transactions
- Service-level indicators and objectives
- Change and deployment records
- Security events
- AI requests and model behaviour
- Cloud and AI cost
- Customer support and incident impact
Monitoring and observability are related but different
Monitoring checks known conditions: CPU saturation, failed jobs, error rate, queue length, or service availability. Observability helps engineers investigate unexpected conditions by connecting high-quality telemetry across the system.
Start with service-level objectives
An SLO communicates an expected level of service using one or more service-level indicators. Examples include:
- Successful checkout rate
- Order-processing latency
- API availability
- Data-pipeline freshness
- Booking completion
- Model-response correctness under an approved evaluation
- Time to restore an essential service
An infrastructure dashboard becomes useful to the business when it shows which customer or operational outcome is at risk.
Use common telemetry semantics
OpenTelemetry semantic conventions provide common names for traces, metrics, logs, profiles, resources, protocols, and operations. Consistent naming improves portability and correlation across services and vendors.
Govern telemetry volume and sensitivity
More telemetry is not automatically better. Logs and traces may contain personal data, secrets, prompts, customer content, security information, or commercially sensitive records.
Define:
- Required signals
- Sampling
- Cardinality limits
- Redaction
- Access
- Retention
- Regional storage
- Cost ownership
- Export and vendor portability
Do not automate incidents directly from every alert
Automated remediation can restart a safe stateless service, scale capacity within an approved range, or open an incident. Higher-risk actions should require validation, change controls, and human authority.
| Layer | Examples | Operating question |
|---|---|---|
| Infrastructure | Compute, storage, network, cluster, database, edge, and device telemetry | Is the underlying capacity healthy and available? |
| Application | Requests, dependencies, errors, traces, queues, and jobs | Where is the service failing or slowing? |
| User and business | Transactions, completion, abandonment, revenue, or service outcomes | Which users and outcomes are affected? |
| AI | Model version, prompt, retrieval, tools, latency, evaluation, and cost | Is the AI system useful, safe, and within its operating boundary? |
| Security | Identity, configuration, vulnerability, threat, and incident evidence | Does the event indicate misuse, compromise, or control failure? |
| Financial | Cloud, licence, AI, network, storage, and telemetry cost | Is the service producing value at an acceptable unit cost? |
The objective is not a single dashboard. It is a traceable path from service impact to technical cause, accountable decision, and verified recovery.
Priority 2: MLOps Expands Into Production AI Operations
MLOps remains important for data pipelines, feature preparation, model training, validation, deployment, monitoring, and retraining. Generative AI and agents add new components:
- Foundation models and versions
- Prompts and system instructions
- Retrieval indexes and source documents
- Embedding models
- Tools and permissions
- Agent workflows
- Safety and policy controls
- Human approvals
- Evaluation sets
- Token, GPU, and provider cost
AI is an operating system, not one model endpoint
A production AI service may fail because:
- Source data changed
- A model version changed
- A retrieval index is stale
- A prompt regression occurred
- A tool call used the wrong record
- An identity or permission check failed
- Latency or rate limits increased
- A provider became unavailable
- Cost per successful task rose
- Users changed how they interact with the system
Use the complete AI lifecycle
- Define purpose, users, business outcome, and prohibited uses
- Identify data, model, provider, and tool dependencies
- Establish governance and risk ownership
- Build representative evaluation sets
- Test quality, safety, security, cost, and latency
- Release through controlled environments
- Monitor production behaviour and outcomes
- Investigate incidents and user corrections
- Re-evaluate after model, data, prompt, tool, or policy changes
- Rollback or retire when required
Automated retraining is not always appropriate
The original article presented automated retraining as a normal requirement. Retraining may introduce new bias, data quality problems, model drift, compliance exposure, or regression.
Use defined triggers, validated data, approval, testing, staged release, and rollback. Some models should be updated periodically or only after an approved change.
AgentOps needs tool-level controls
An agent that can create tickets, modify data, send messages, deploy code, or operate infrastructure requires:
- External authorization
- Least privilege
- Allowlisted actions
- Argument validation
- Approval for material actions
- State and idempotency controls
- Audit records
- Timeouts and maximum steps
- Fallback and kill switch
Measure value at the task level
FinOps Foundation’s 2026 survey reports that 98% of its respondents now manage AI spending. This is a survey of FinOps practitioners—not all enterprises—but it reflects the movement of AI cost into formal technology-value management.
Useful AI unit measures include:
- Cost per successful task
- Cost per qualified output
- Tokens per accepted response
- GPU utilization
- Human review time
- Escalation rate
- Correction rate
- Value or capacity created
Do not operate AI as a special innovation environment forever. Apply software engineering, model governance, security, financial controls, and production accountability.
Priority 3: Cybersecurity Becomes Cyber Resilience
Cybersecurity is not a separate tool layer added after architecture. It affects identity, cloud configuration, networks, endpoints, code, models, data, backups, vendors, and incident recovery.
Zero trust is an architecture and operating approach
CISA’s Zero Trust Maturity Model organizes progress across identity, devices, networks, applications and workloads, and data, with visibility, analytics, automation, orchestration, and governance across those pillars.
CISA released new zero-trust modernization guidance in June 2026 for federal agencies transitioning from older perimeter-based approaches. Enterprises can use the underlying principles without assuming that one product creates zero trust.
Assume software and model supply-chain risk
Infrastructure depends on:
- Open-source packages
- Container images
- CI/CD systems
- Infrastructure modules
- Cloud services
- Models and model files
- Datasets
- Prompt and agent frameworks
- Third-party APIs
NIST’s draft Secure Software Development Framework Version 1.2 updates secure development recommendations. SLSA provides levels for increasing confidence in build provenance and protection against software-artifact tampering.
AI creates three security domains
- Security of AI systems
- AI used by defenders
- AI used or exploited by attackers
The Canadian Centre for Cyber Security released its Top 10 AI Security Actions in May 2026. The guidance is organized around securing AI systems, using AI securely, and preparing for AI-enabled cyber threats.
Edge AI expands the attack surface
Canadian Cyber Centre guidance issued in July 2026 addresses AI deployed at the network edge, where devices may operate with constrained resources, intermittent connectivity, physical exposure, local data, and remote update dependencies.
Resilience requires recovery evidence
Controls should include:
- Asset and dependency inventory
- Identity and privileged-access management
- Secure configuration
- Patch and vulnerability management
- Software and model provenance
- Network and tenant segmentation
- Immutable or protected backups
- Recovery objectives
- Incident runbooks
- Exercises and restoration tests
- Vendor continuity and exit
Combine security and operational telemetry carefully
Cross-domain correlation can accelerate investigation, but security records require strict access, retention, integrity, and separation. Do not expose sensitive detection logic or incident details in broad business dashboards.
The goal is not to prevent every incident. It is to reduce exposure, detect meaningful events, contain impact, preserve essential services, and recover through tested processes.
Priority 4: Platform Engineering and Policy-Driven Automation
Cross-functional automation remains valuable, but the 2026 emphasis is less about one enterprise automation platform and more about creating safe, reusable paths for teams to deliver and operate services.
Platform engineering treats the internal platform as a product
A platform may provide:
- Approved application templates
- Self-service environments
- CI/CD pipelines
- Infrastructure as code
- Identity and secret management
- Observability defaults
- Security controls
- Data and AI services
- Cost and ownership tags
- Documentation and support
The user is the developer, data team, analyst, operations team, or product team consuming the platform.
Golden paths must remain optional where requirements differ
A golden path should make the safe common case easier. It should not force every workload into one runtime or prevent justified exceptions.
Measure platform outcomes
DORA’s 2026 platform-engineering guidance recommends balancing:
- Software delivery performance
- Developer satisfaction
- Adoption and retention
- Task success
DORA also cautions that platforms can reduce throughput or change stability when poorly implemented. Adoption alone is not proof of value.
Use automation layers deliberately
| Automation layer | Examples | Primary control |
|---|---|---|
| Provisioning | Infrastructure as code, accounts, networks, clusters, databases, and environments | Approved modules, review, state protection, and policy checks |
| Delivery | Build, test, package, sign, deploy, and rollback | Protected pipelines, provenance, approvals, and environment gates |
| Configuration | GitOps, configuration management, secrets, and policy | Version control, drift detection, least privilege, and reconciliation |
| Operations | Scaling, restart, ticketing, remediation, and incident coordination | Safe action boundary, rate limit, validation, and human escalation |
| Business workflow | Approvals, onboarding, reporting, and cross-system handoffs | Authoritative records, decision rights, audit, and exception handling |
| AI-assisted operations | Incident summary, query generation, diagnosis support, and runbook recommendation | Evaluation, source evidence, tool limits, approval, and audit |
AIOps should assist before it autonomously changes production
Google described its internal use of agentic AI in SRE in May 2026 as a way to reduce repetitive operational work and improve decision quality, while requiring continuous evaluation, auditing, and security support.
For most enterprises, a practical progression is:
- Summarize alerts and incidents
- Retrieve relevant runbooks and changes
- Suggest diagnostic queries
- Recommend bounded actions
- Execute low-risk actions with approval
- Automate only proven, reversible remediation
Automation creates value when it reduces repeated work and variation while preserving ownership, evidence, rollback, and exception handling.
Priority 5: FinOps and Sustainable Operations Converge
Technology cost and environmental impact are both consequences of architecture, workload demand, utilization, location, hardware, software efficiency, and operating practice.
FinOps expands beyond public cloud
The FinOps Framework now addresses technology-value management across scopes such as public cloud, SaaS, licensing, AI, data centres, and private cloud.
The 2026 State of FinOps survey reports that AI cost management is the leading skill gap among its respondents and that 98% now manage AI spend. These results describe participating FinOps practitioners and should not be generalized to every enterprise.
AI introduces volatile unit economics
Cost may depend on:
- Tokens
- Context length
- Model
- GPU type and availability
- Batch size
- Training and fine-tuning
- Retrieval and vector storage
- Tool calls
- Retries
- Human review
- Provider pricing changes
Data-centre energy demand is an infrastructure constraint
The International Energy Agency reported in April 2026 that global data-centre electricity demand grew 17% in 2025, while electricity use by AI-focused data centres grew faster. Its base case projects global data-centre electricity consumption to more than double by 2030.
These figures do not mean every enterprise should build its own data centre or abandon AI. They reinforce the need to measure demand, capacity, location, utilization, and value.
Measure before claiming sustainability
The Software Carbon Intensity specification, standardized as ISO/IEC 21031:2024, provides a methodology for calculating a rate of software carbon emissions using energy, carbon intensity, embodied emissions, and a functional unit.
Useful measures may include:
- Energy per transaction
- Carbon per successful AI task
- Compute utilization
- Idle capacity
- Storage growth
- Data transfer
- Hardware lifecycle
- Application-specific SCI score
- Cost per business outcome
Optimize in the correct order
- Remove unused resources and data
- Right-size and schedule workloads
- Improve software, query, model, and prompt efficiency
- Increase hardware and accelerator utilization
- Select suitable regions, providers, and infrastructure
- Extend hardware life where safe and practical
- Measure actual outcome and rebound effects
Do not trade reliability or compliance for a lower metric
Moving a workload to a lower-cost or lower-carbon location may increase latency, violate data requirements, reduce resilience, or create operational complexity.
Illustrative technology-value equation
Net technology value = verified business and service value − cloud − AI − licences − network − data centre − labour − support − risk − energy and environmental costFinOps should not minimize the bill at any cost. It should make technology value, unit economics, utilization, and trade-offs visible to engineering, finance, product, and leadership.
Priority 6: Hybrid, Distributed, Edge, and Sovereign Infrastructure
Hybrid architecture can combine public cloud, private cloud, colocation, owned data centres, SaaS, edge devices, and sovereign or sector-specific environments.
It may be required because of:
- Existing systems
- Latency
- Connectivity
- Data location or sovereignty
- Security or isolation
- Hardware or accelerator needs
- Operational technology
- Cost
- Vendor concentration
- Business continuity
Hybrid does not automatically create resilience
Running in several environments can increase:
- Identity complexity
- Network dependencies
- Configuration drift
- Observability gaps
- Security exposure
- Data synchronization problems
- Skills requirements
- Cost
- Recovery complexity
Kubernetes is an option, not the strategy
CNCF’s 2025 Annual Cloud Native Survey, published in January 2026, reports that 82% of container-using respondents ran Kubernetes in production and that Kubernetes was commonly used among respondents hosting generative AI.
This demonstrates maturity within the cloud-native survey population. It does not mean every workload belongs on Kubernetes.
Kubernetes may fit when the organization needs:
- Container orchestration at meaningful scale
- Portable deployment patterns
- Advanced scheduling
- Service discovery and automation
- A strong internal platform capability
Managed services, serverless platforms, virtual machines, SaaS, bare metal, or simpler container services may be better for other workloads.
Production Kubernetes is an operating commitment
Official Kubernetes guidance states that production-quality clusters require planning for resilience. Enterprises must decide which control-plane, upgrade, network, storage, security, observability, backup, and lifecycle responsibilities they will manage or delegate.
Edge architecture needs local failure design
Edge workloads may need:
- Local processing
- Store-and-forward
- Offline operation
- Remote update
- Physical protection
- Constrained compute and energy
- Local privacy or data controls
- Fleet management
- Safe degraded operation
Canadian sovereign compute became more concrete in 2026
The Government of Canada launched a new national AI strategy in June 2026 and has been advancing programs and proposals for secure, resilient, sustainable, Canadian-governed AI compute infrastructure.
Sovereignty is not only the country in which a server is located. Evaluate:
- Data location
- Legal jurisdiction
- Ownership and control
- Administrative access
- Encryption and key control
- Subprocessors
- Model and data portability
- Supply-chain dependencies
- Continuity and exit
Use a workload-placement matrix
| Criterion | Questions |
|---|---|
| Business criticality | What happens when the workload is unavailable or degraded? |
| Data | What sensitivity, location, retention, ownership, and transfer requirements apply? |
| Latency and connectivity | Does the service require local response or continuous network access? |
| Compute | Does it require GPU, accelerator, specialized hardware, burst capacity, or predictable reservation? |
| Reliability | Which failure domains, recovery objectives, and dependencies are acceptable? |
| Security | Which isolation, identity, monitoring, patch, and administrative controls are required? |
| Operations | Does the organization have the skills and support capacity to run the environment? |
| Economics | What is the full cost at expected demand, including people, network, licences, and exit? |
| Sustainability | What energy, carbon, hardware, and utilization trade-offs are material? |
| Portability | Is portability required, and what is its real technical and operating cost? |
Place each workload where it can meet its service, risk, data, cost, and operating requirements. “Cloud first,” “on-premises first,” and “Kubernetes everywhere” are not workload assessments.
How the Six Priorities Connect
The priorities should not be implemented as six independent programs.
Observability + Cybersecurity
Shared telemetry can improve detection and incident investigation, but access, retention, integrity, and sensitive-data boundaries must be governed.
AI Operations + FinOps
Model quality, latency, token use, GPU utilization, human review, and cost per successful task should be evaluated together.
Platform Engineering + Security
Golden paths can make secure defaults, provenance, identity, logging, policy, and recovery easier for product teams to adopt.
Hybrid Architecture + Observability
Consistent instrumentation and service identity are necessary to understand transactions across clouds, data centres, SaaS, and edge systems.
Sustainability + Architecture
Software efficiency, hardware utilization, workload timing, region, and service design affect cost and environmental impact.
Automation + Resilience
Infrastructure, deployment, policy, and recovery automation can reduce variation, but only when actions are tested, reversible, and observable.
Use one service portfolio
For every critical service, record:
- Business owner
- Technical owner
- Users and value
- Architecture and dependencies
- Data classification
- SLOs
- Security and recovery requirements
- Cost and unit economics
- AI components
- Vendors
- Lifecycle status
The service portfolio is the bridge between infrastructure decisions and business priorities. Without it, teams optimize platforms while customer and operational dependencies remain unclear.
A Practical I&O Operating Architecture
Business services, owners, users, criticality, SLOs, dependencies, cost, risk, and lifecycle.
Public cloud, private cloud, SaaS, data centre, edge, sovereign environment, network, and integration decisions.
Workforce, workload, machine, service, privilege, federation, secrets, keys, and lifecycle.
Source, build, test, provenance, artifacts, deployment, infrastructure as code, policy, and rollback.
Sources, contracts, quality, lineage, access, storage, movement, retention, recovery, and governance.
Models, prompts, retrieval, tools, evaluations, approvals, deployment, monitoring, cost, and retirement.
Telemetry standards, instrumentation, SLOs, traces, metrics, logs, profiles, cost, and service impact.
Threat model, zero trust, configuration, vulnerabilities, supply chain, detection, backup, response, and recovery.
Provisioning, delivery, policy, operations, workflow, AI assistance, approvals, exception, and rollback.
Allocation, forecasting, unit cost, utilization, energy, carbon, capacity, optimization, and value.
Service desk, incident, problem, change, capacity, maintenance, release, vendor, support, and runbooks.
Standards, exceptions, risk, audit, metrics, reviews, experiments, technical debt, and retirement.
The architecture should not require one vendor or one deployment model. Define interfaces, ownership, data contracts, controls, and exit requirements that remain meaningful when products change.
A Twelve-Stage Infrastructure and Operations Roadmap
Identify services, workloads, data, AI, environments, vendors, dependencies, owners, cost, and lifecycle status.
Assess business criticality, data sensitivity, recovery needs, regulatory exposure, threat, latency, and sovereignty.
Measure availability, incidents, recovery, change performance, cost, utilization, security gaps, energy, and user impact.
Select the service with the strongest combination of business value, operational pain, risk, and feasible improvement.
Define target service, architecture, placement, SLOs, security, data, cost, automation, support, and fallback.
Create approved modules, telemetry semantics, pipelines, policies, identity patterns, tags, runbooks, and documentation.
Use architecture spikes, failure tests, security tests, cost models, AI evaluations, and representative workloads.
Release a bounded production service with named owners, support, observability, cost controls, fallback, and stop criteria.
Address capacity, recovery, supply chain, privacy, security, automation limits, vendor continuity, and operational debt.
Turn proven patterns into supported platform capabilities, self-service paths, documentation, training, and service levels.
Monitor SLOs, incidents, changes, security, cost, energy, AI quality, platform adoption, vendors, and user outcomes.
Consolidate duplicate tools, remove unused telemetry and resources, reduce exceptions, repay debt, and retire obsolete services.
Production Readiness Gates
| Gate | Evidence required |
|---|---|
| Business service | Named owner, users, critical outcome, service boundary, baseline, SLO, and consequence of failure |
| Architecture | Components, dependencies, data flows, placement, failure domains, limits, and documented decisions |
| Capacity and performance | Demand model, load tests, scaling, quotas, latency, accelerator capacity, and degradation behaviour |
| Reliability | SLOs, error budget, redundancy, backup, recovery objectives, restoration tests, and fallback |
| Observability | Instrumentation, common semantics, service identity, alerts, dashboards, runbooks, privacy, and telemetry cost |
| Cybersecurity | Threat model, identity, least privilege, configuration, vulnerability, supply chain, detection, response, and recovery |
| Data | Classification, authority, quality, lineage, residency, access, retention, recovery, and deletion |
| AI | Purpose, model, provider, prompts, retrieval, tools, evaluations, approvals, monitoring, cost, and rollback |
| Automation | Action boundary, approval, idempotency, validation, rate limit, audit, rollback, exception, and kill switch |
| Cost and sustainability | Allocation, forecast, unit economics, utilization, energy, carbon method, capacity, and optimization owner |
| Operations | Support model, on-call, incident, problem, change, maintenance, vendor escalation, documentation, and training |
| Exit and lifecycle | Versioning, deprecation, export, migration, contract exit, data return, replacement, and retirement plan |
A workload is not production-ready because it deployed successfully. It is ready when the organization can operate, secure, measure, recover, fund, and eventually change or retire it.
Measure Enterprise Outcomes, Not Infrastructure Activity
| Category | Useful measures |
|---|---|
| Service reliability | SLO attainment, successful transactions, user impact, availability, latency, and degraded operation |
| Incident and recovery | Detection, acknowledgement, containment, recovery, restoration success, repeat incident, and customer impact |
| Software delivery | Change lead time, deployment frequency, failed deployment recovery time, change failure percentage, and deployment rework |
| Platform | Adoption, retention, task success, developer satisfaction, support, exceptions, and time to a compliant environment |
| Observability | Coverage, trace completeness, alert usefulness, false alerts, diagnosis time, query success, and telemetry cost |
| Security | Identity coverage, configuration compliance, vulnerability exposure, provenance, detection, containment, exercise, and recovery |
| AI operations | Evaluation quality, accepted output, correction, escalation, tool accuracy, latency, drift, incident, and rollback |
| Financial | Cost by service, unit cost, budget variance, forecast accuracy, commitment use, waste, and value realized |
| Capacity | CPU, memory, GPU, storage, network, queue, reservation, utilization, headroom, and constraint |
| Sustainability | Energy, carbon intensity, embodied impact where measured, idle capacity, hardware life, and functional-unit output |
| Hybrid and edge | Connectivity, synchronization, local availability, fleet health, update success, regional failure, and data movement |
| Business | Revenue protected or enabled, service capacity, processing time, customer outcome, risk reduction, and continuity |
DORA’s current five software delivery metrics
DORA’s 2026 guidance uses:
- Change lead time
- Deployment frequency
- Failed deployment recovery time
- Change failure percentage
- Deployment rework rate
These metrics should be used with service reliability, user outcomes, security, cost, and team health. Increasing deployment frequency while degrading service or exhausting teams is not operational success.
Illustrative I&O value formula
Net I&O value = verified business value enabled + downtime and risk avoided + delivery and operational capacity recovered − infrastructure − cloud − AI − software − labour − security − energy − transition − support − incident costCommon Risks and Recommended Controls
| Risk | Example | Recommended control |
|---|---|---|
| Tool-first strategy | The enterprise buys observability, AI, automation, and platform products without a service problem | Service portfolio, baseline, outcome, owner, architecture decision, and exit criteria |
| Telemetry overload | Logs and traces create high cost while incidents remain difficult to diagnose | Telemetry standards, SLO-driven instrumentation, sampling, cardinality limits, retention, and cost allocation |
| Observability data leak | Prompts, secrets, customer information, or tokens enter logs and traces | Data classification, redaction, secure instrumentation, access, retention, and testing |
| Uncontrolled AI change | A provider or prompt change causes a production regression | Version pinning where available, evaluations, canary release, monitoring, approval, and rollback |
| Agent overreach | An AI system changes infrastructure or data beyond its authority | External authorization, least privilege, allowlisted tools, argument validation, approval, and audit |
| Automation cascade | One false signal triggers repeated scaling, restart, or deployment actions | Rate limits, state checks, circuit breakers, action budgets, human escalation, and kill switch |
| Platform lock-in | The internal platform becomes mandatory but cannot support legitimate workload needs | Platform product management, exception process, interfaces, adoption metrics, and migration paths |
| Kubernetes everywhere | Simple workloads inherit cluster cost, complexity, and support burden | Workload-placement matrix, managed alternatives, total-cost comparison, and skill assessment |
| False hybrid resilience | Several clouds share the same identity, network, DNS, provider, or operational failure | Dependency mapping, failure-domain analysis, isolated recovery, tests, and realistic RTO and RPO |
| Software supply-chain compromise | A dependency, model, image, build system, or artifact is replaced or tampered with | Inventory, provenance, signed artifacts, protected builds, dependency policy, scanning, and verification |
| FinOps becomes cost cutting | Teams reduce redundancy, telemetry, or capacity and create service risk | Unit economics, SLO guardrails, business value, risk review, and accountable trade-offs |
| Unsupported sustainability claim | The enterprise claims lower emissions from moving to cloud without measuring workload output | Defined methodology, functional unit, energy and carbon data, boundaries, assumptions, and qualified reporting |
| Sovereignty assumption | Data is hosted in Canada but administrative control or legal exposure remains unclear | Jurisdiction, ownership, access, keys, subprocessors, contracts, portability, and exit review |
| Vendor concentration | One provider controls cloud, identity, observability, AI, and recovery | Criticality review, contractual protections, exports, independent backup, fallback, and concentration scenarios |
| Metrics gaming | Teams improve deployment or cost metrics while user outcomes deteriorate | Balanced scorecard, service outcomes, guardrails, independent review, and metric definitions |
| No operating owner | A pilot becomes critical without on-call, support, budget, or lifecycle responsibility | Named service owner, support model, funding, runbooks, maintenance, and retirement plan before scale |
Choosing the First 2026 I&O Initiative
Do not begin with a multi-year infrastructure transformation when one service has an urgent, measurable failure.
Strong starting points
- A critical service with repeated incidents and weak diagnosis
- An AI pilot entering production without evaluation, cost, or rollback controls
- A manual environment-provisioning process that causes delay and configuration drift
- A cloud or AI cost area without service allocation or unit economics
- A recovery process that has not been tested
- A high-risk software supply chain without provenance or protected builds
- An edge or hybrid service with unclear failure and synchronization behaviour
- A platform with low adoption and high support burden
Use a seven-part selection test
- Business importance: The service supports a meaningful customer, operational, revenue, compliance, or continuity outcome.
- Measurable baseline: Current reliability, cost, time, risk, or workload can be measured.
- Named owner: Someone can make decisions and operate the result.
- Bounded scope: The service, environment, user group, or capability can be piloted safely.
- Available evidence: Architecture, logs, incidents, cost, users, and dependencies can be examined.
- Reversible change: The organization can rollback or fall back.
- Expansion path: A successful pattern can be reused without forcing every workload into it.
The best first project is usually a production service with visible pain, an accountable owner, and a result that can be verified within the existing operating environment.
FAQs About Infrastructure and Operations in 2026
Is observability different from monitoring?
Monitoring checks known conditions and thresholds. Observability uses well-structured telemetry to investigate both known and unexpected system behaviour. A mature operating model uses both and ties them to service-level objectives and user impact.
Does every AI system need MLOps?
Every production AI system needs lifecycle ownership, versioning, evaluation, monitoring, security, cost controls, change management, and fallback. Traditional MLOps pipelines are more relevant to trained predictive models; managed generative models also require prompt, retrieval, tool, provider, and agent controls.
Should enterprises use autonomous AI for incident response?
Begin with summarization, evidence retrieval, diagnosis support, and recommended actions. Automate only actions that are narrow, validated, reversible, rate-limited, observable, and appropriate to execute without approval.
Is zero trust a product?
No. Zero trust is an architecture and operating approach that continuously evaluates access to resources using identity, device, network, application, workload, data, policy, and telemetry. Products can support the approach but cannot create it alone.
Does every enterprise need a platform-engineering team?
No. A dedicated platform team is justified when several product or data teams share repeated delivery and operating needs. Smaller organizations may use managed services, standardized templates, and a part-time platform owner without building a large internal platform.
Should every container workload run on Kubernetes?
No. Kubernetes is powerful but creates operating responsibility. Compare it with managed containers, serverless services, virtual machines, SaaS, and simpler platforms using workload requirements, skills, reliability, portability, and total cost.
Does hybrid cloud improve resilience?
Only when the architecture reduces real failure dependencies and the organization can operate and test each environment. Several environments can still share identity, DNS, network, data, staffing, or provider failures.
How should a company measure AI infrastructure cost?
Measure compute, tokens, storage, data transfer, retrieval, observability, software, engineering, human review, support, and incidents. Divide full cost by a useful functional outcome such as an accepted answer, completed task, prediction, or customer transaction.
Does Canadian data residency guarantee sovereignty?
No. Residency is one factor. Review legal jurisdiction, provider ownership, administrative access, encryption-key control, subprocessors, supply chain, model and data portability, contracts, and exit rights.
When should an I&O modernization initiative stop?
Stop or reduce scope when the business service is unclear, ownership is missing, cost exceeds credible value, the platform adds more burden than it removes, required controls cannot be met, the migration increases concentration or recovery risk, or a simpler managed service meets the need.
Sources
- OpenTelemetry: Observability primer
- OpenTelemetry: What is OpenTelemetry?
- OpenTelemetry documentation
- OpenTelemetry: Semantic conventions
- OpenTelemetry Collector
- OpenTelemetry: AI agent observability and evolving standards
- NIST: Artificial Intelligence Risk Management Framework
- NIST AI Resource Center: AI RMF Playbook
- NIST: Generative Artificial Intelligence Profile
- NIST NCCoE: Cyber AI Profile
- Google Cloud Architecture Center: MLOps continuous delivery and automation pipelines
- Google Cloud: Architecting reliable GPU infrastructure
- Google Cloud Architecture Center: Reliable RAG-capable generative AI infrastructure
- Google Cloud: How Google SRE is using agentic AI
- DORA: State of AI-assisted Software Development 2025
- DORA: Platform engineering capability
- DORA: Software delivery performance metrics
- DORA: Flexible infrastructure capability
- CISA: Zero Trust Maturity Model
- CISA: Zero trust guidance
- CISA: 2026 guide for modernized zero-trust architectures
- CISA: StopRansomware Guide
- CISA and FBI: Product security bad practices and Secure by Design
- NIST: Draft Secure Software Development Framework Version 1.2
- SLSA: Supply-chain Levels for Software Artifacts specification
- OpenSSF: Software supply-chain initiatives
- Canadian Centre for Cyber Security: Top 10 AI security actions
- Canadian Centre for Cyber Security: Frontier artificial intelligence
- Canadian Centre for Cyber Security: Securely deploying AI at the network edge
- Canadian Centre for Cyber Security: 2026 Ransomware playbook
- FinOps Foundation: State of FinOps 2026
- FinOps Foundation: FinOps for AI
- FinOps Foundation: Cost estimation of AI workloads
- FinOps Foundation: FinOps Framework 2025 scopes
- International Energy Agency: Key Questions on Energy and AI
- International Energy Agency: Energy and AI executive summary
- International Energy Agency: Data centres and networks
- International Energy Agency: 2026 update on data-centre electricity demand
- Green Software Foundation: Software Carbon Intensity standard
- Software Carbon Intensity specification
- Green Software Foundation: Software Carbon Intensity for AI
- Cloud Native Computing Foundation: Annual Cloud Native Survey published in 2026
- CNCF: 2025 survey findings on Kubernetes and AI workloads
- Kubernetes: Production environment guidance
- Kubernetes: Production setup and managed responsibility choices
- Kubernetes: Concepts overview
- Google Cloud: Well-Architected Framework
- Google Cloud Architecture Center: Hybrid and multicloud deployment archetypes
- Government of Canada: National Artificial Intelligence Strategy — AI for All
- Government of Canada: Canadian Sovereign AI Compute Strategy
- Government of Canada: Enabling large-scale sovereign AI data centres
- Government of Canada: Sovereign Compute Infrastructure Program guide
Start With One Critical Service
Web Inventix AI can review your service portfolio, cloud and data-centre architecture, AI workloads, observability, security, automation, platform engineering, FinOps, sustainability measures, data sovereignty, recovery, vendors, and operating workflows. The first project should improve one measurable reliability, risk, delivery, or cost problem before the organization expands its platform estate.
Book an Infrastructure and Operations Review