—·
If auditability stops at the model layer, governance becomes theater. Intel’s Optical Compute Interconnect (OCI) shows why telemetry & controls must span chips, optical interconnect, cluster scheduling, and deployment gates.
A governance team can run risk assessments, sign off on model cards, and still fail an audit if the organization cannot prove—at incident time—what actually changed across the AI stack. The uncomfortable truth is that “AI governance” often behaves like a policy binder: it organizes documentation, but it doesn’t generate regulator-grade proof.
The infrastructure layer makes this gap obvious. Intel’s Optical Compute Interconnect (OCI) chiplet demonstration is engineered for high-speed AI data-center communication, supporting up to 4 terabits per second (Tbps) bidirectional data transfer in its first implementation. (Intel press release) That kind of architectural acceleration can reduce latency and increase throughput—while simultaneously making “what happened” harder to reconstruct—because failures (or policy-relevant deviations) can originate in optics, in node-level orchestration, or in the handoff between scheduling and deployment.
So the governance question becomes structural: can the organization produce an audit evidence pipeline that ties incident accountability to telemetry & controls end-to-end? If the evidence breaks at the optical interconnect boundary—or at the cluster scheduler boundary—the enterprise risk function is left with narratives instead of proof.
Optical Compute Interconnect (OCI) is not merely a faster cable. It is a new control surface across physical and logical layers: chiplets, optical I/O, datacenter networking behavior, and (crucially) the software that decides where workloads run. Intel’s framing is explicit that OCI is integrated with an Intel CPU platform and uses “live data” in its demonstration, meaning governance-relevant state spans compute and interconnect behavior, not just ML artifacts. (Intel press release)
That “spans compute and interconnect” is where most evidence pipelines break—not because logs are absent, but because they are non-correlatable. In practice, governance teams can collect rich telemetry from application servers and model servers while still failing audits, because the evidence they need at incident time is the cross-layer join:
This matters because modern AI operations are already a chain of gates: hardware readiness → cluster scheduling → data/model stage selection → deployment approval → runtime enforcement. Governance strategies that treat these gates as independent often fail at the seam—not in the existence of telemetry, but in whether telemetry can be proven to answer one question: which exact workload and exact artifact were approved under the exact boundary conditions that prevailed at admission time?
NIST’s AI Risk Management Framework (AI RMF 1.0) emphasizes that trustworthy AI requires embedding risk management considerations into design, development, use, and evaluation—rather than treating trust as a post-hoc statement. (NIST AI RMF 1.0 landing page) When the stack introduces new “fast paths” (like high-bandwidth optical interconnect), the auditability requirement expands from “did we monitor?” to “did we monitor with the same evidence keys the controls used at the time decisions were made?” Control verification becomes a question of correlation design: are identifiers consistent across chip/platform telemetry, scheduling events, and deployment gate approvals, and is retention long enough to survive incident triage?
A practical governance strategy reframes audit evidence as a production artifact. Instead of asking, “Do we have documentation?” teams ask, “Can we produce machine-checkable evidence for every material control at incident time?”
This is where standards language becomes actionable. For instance, ISO/IEC 42001:2023 (AI Management System) treats monitoring/measurement and internal audit as parts of a continuous system, requiring documented evidence of results. (ISO/IEC 42001 text (download)) If your evidence is not continuously generated and linked to decisions, it will degrade—especially when infrastructure evolves.
Below is the end-to-end shape that governance teams can build. (The goal is not to “log everything”; the goal is to generate evidence that supports control verification.)
OpenTelemetry’s GenAI semantic conventions are part of how organizations standardize telemetry shape. The OpenTelemetry project publishes specifications for generative AI semantic conventions (including events and spans) to help standardize AI workflow telemetry so it can be analyzed consistently across systems. (OpenTelemetry GenAI semantic conventions docs)
Most governance incidents are not “model-only” events. They are lifecycle events. A bad deployment, a corrupted artifact, a misconfigured runtime, or a policy-relevant anomaly often emerges from the orchestration layer: the scheduler placed workloads differently, admission checks were bypassed, or a rollout gate accepted an artifact that did not meet required conditions.
NIST’s AI RMF 1.0 provides a governance structure (functions including mapping, measuring, managing, and governance processes) meant to improve risk handling across the lifecycle. (NIST AI RMF 1.0 landing page) But the framework still requires implementation choices: how do you measure and monitor in a way that creates evidence?
To make accountability verifiable, teams should implement “control receipts” that accompany scheduling and deployment actions—receipts that can be automatically checked, not merely stored.
At a minimum, a control receipt should contain four fields that support re-verification:
admission_decision_id, deployment_approval_id) generated at the point of decision.job_id, model_artifact_hash, runtime_config_hash, and if applicable a cluster_version / firmware_version identifier).This turns accountability into a reproducible query: “Given the deployment approval ID for model artifact X at time T, show the interconnect health class and scheduler admission constraints that were in effect when the gate approved.” If the receipts can’t be joined automatically, the organization is effectively asking auditors to perform a best-effort investigation, not a control verification.
ISO/IEC 42001’s system logic—continuous monitoring and internal audits with documented evidence—supports this engineering approach: evidence must exist when you need it, not when an auditor asks later. (ISO/IEC 42001 download)
In the UK, regulators describe governance in terms of audit trails and access logging, which is a strong indicator that evidence pipelines must exist in the real world—not only in internal compliance artifacts. The Information Commissioner’s Office (ICO) publishes guidance on “governance and accountability in AI,” including establishing comprehensive audit trails to log and monitor access to datasets. (ICO: Governance and accountability in AI)
The ICO also notes that guidance can be updated due to legal change (it explicitly flags the “Data (Use and Access) Act” coming into law on 19 June 2025 and states the guidance is under review). (ICO guidance page) For governance teams, that is a practical lesson: if evidence pipelines do not cover how data and decisions were governed at the operational layers, legal change will scramble the audit story.
So, the governance strategy has to be resilient to change. That means designing evidence generation so controls still map to telemetry even as policies, deployment schedules, and infrastructure versions evolve.
To move from theory to systems accountability, governance needs case anchors.
Entity: Intel
What happened: Intel demonstrated a fully integrated optical compute interconnect (OCI) chiplet co-packaged with an Intel CPU and running live data, with the first OCI implementation supporting up to 4 Tbps bidirectional data transfer. (Intel press release)
Timeline: The press release describes the demonstration associated with OFC 2024 and provides the implementation details. (Intel press release)
Governance implication: When optical interconnect becomes part of the compute platform, incident investigation requires telemetry that covers the interconnect boundary. Otherwise, “governance” cannot reconstruct what infrastructure state existed when a deployment gate fired.
Entity: OpenTelemetry
What happened: OpenTelemetry publishes specification docs for GenAI semantic conventions, providing a standardized telemetry vocabulary intended to improve traceability and analysis across AI workflows. (OpenTelemetry GenAI semantic conventions)
Timeline: The docs are live and maintained as part of the OpenTelemetry project; they represent an ongoing shift from ad-hoc logging to standard, structured instrumentation. (OpenTelemetry docs)
Governance implication: Without standardized telemetry semantics, evidence pipelines become bespoke. With standardized telemetry semantics, enterprise risk teams can verify controls consistently across clusters, models, and deployments—especially during incident accountability.
These are not “governance failures” in themselves; rather, they define the infrastructure and telemetry prerequisites for governance that can stand up to scrutiny.
Governance teams need hard targets. The numbers below are the kind you should convert into control parameters (retention, coverage, correlation time, and verification intervals).
Up to 4 Tbps bidirectional transfer in Intel’s first OCI implementation (year: 2024)
This figure defines the “scale” at which infrastructure-level telemetry and evidence correlation must operate. (Intel press release)
NIST AI RMF 1.0 is published as a formal AI risk management framework (version 1.0) intended for voluntary use (year: 2023)
Governance strategies should map control receipts to the framework’s lifecycle intent. (NIST AI RMF 1.0 page)
ISO/IEC 42001:2023 requires monitoring/measurement and internal audit with documented evidence of results (year: 2023)
This is the system-level basis for “continuous evidence,” not periodic paperwork. (ISO/IEC 42001 download)
ICO guidance includes a legal trigger: the Data (Use and Access) Act on 19 June 2025 (year: 2025)
Governance evidence pipelines must remain valid through legal changes affecting dataset usage/access. (ICO guidance page)
OpenTelemetry GenAI semantic conventions standardize telemetry shape for AI observability (year: ongoing / maintained; documented in current spec)
For governance design, this informs how you define “control verifiers” in a consistent taxonomy. (OpenTelemetry GenAI semantic conventions)
The expert direction across standards and guidance is consistent: governance works when it becomes part of execution fabric. NIST frames AI RMF as a way to incorporate trustworthiness considerations into AI system design, development, use, and evaluation, rather than treating trust as external messaging. (NIST AI RMF 1.0 page)
OECD also distinguishes transparency and accountability as complementary concepts, emphasizing that accountability depends on monitoring and ongoing risk management rather than one-time disclosure. (OECD: Governing with Artificial Intelligence)
Meanwhile, OpenTelemetry’s approach to semantic conventions indicates where “audit evidence” can be made more portable: if telemetry follows a standard vocabulary, evidence pipelines can be audited across organizational boundaries and system changes—an essential property when optical interconnects and cluster infrastructures evolve faster than governance processes.
A workable governance strategy looks like this:
Define the governance control points
Standardize telemetry semantics
Treat evidence pipelines as production systems
Make incident accountability re-runnable
This is exactly where end-to-end systems governance beats “paper compliance.” Without correlated telemetry and controls, the incident becomes a black box—and black boxes cannot satisfy audit evidence requirements.
AI governance is entering an evidence era. The most defensible strategies will not merely produce documentation; they will produce audit-grade, control-linked telemetry across the AI stack—especially at the infrastructure boundaries where failures originate.
The UK government, through the ICO and relevant assurance stakeholders, should require procurement and deployment contracts for AI cluster infrastructure to include auditability-by-design clauses—specifically, contractual commitments to provide telemetry coverage and evidence correlation across (1) interconnect health signals, (2) cluster scheduling decisions, and (3) deployment gate decisions. This aligns with the ICO’s emphasis on comprehensive audit trails and dataset access logging for AI governance and accountability. (ICO: Governance and accountability in AI)
By Q4 2027, enterprises deploying AI cluster infrastructure that uses high-throughput interconnect technologies (including optical interconnect approaches like Intel’s OCI architecture) will be expected—by their own internal risk functions and by external assurance processes—to demonstrate end-to-end correlation between infrastructure-state telemetry and model deployment gate outcomes as part of audit evidence packaging.
The practical basis for this forecast is not just “direction of travel,” but the mechanics of audit scrutiny: assurance teams will ask for (a) evidence completeness (were the required signals produced for the specific decision?), (b) evidence integrity (can the stored references be re-joined to the decision artifacts?), and (c) evidence timeliness (could the system have changed between the telemetry snapshot and the gate decision?). These questions map directly onto lifecycle guidance from NIST AI RMF 1.0, system-evidence expectations in ISO/IEC 42001:2023, and regulator emphasis on traceable audit trails and access governance in the ICO guidance. (NIST AI RMF 1.0 page, ISO/IEC 42001 download, ICO guidance page)
Start instrumenting now by running a “receipts audit” before the next procurement cycle: pick one representative training or inference pipeline, define the control points at optics/network admission, scheduler admission, and deployment gate approval, and then test whether you can produce a re-runnable incident narrative using machine-checkable joins (decision IDs → telemetry references → model artifact hashes). If you cannot answer that in a week, you will struggle under incident pressure later—when correlation windows tighten, systems fail over, and the boundary telemetry you need may no longer be available.
In other words: governance can’t be “solved” at the model layer. It must be engineered as a control-plane that continuously produces evidence—right up to the moment a model is allowed to run.
Physical infrastructure projects increasingly rely on AI decisions. That changes what “proof” must look like: investigators should demand traceable evidence packaging, not checklists.
IMDA’s Model AI Governance Framework for Agentic AI reframes governance as deployment controls and audit evidence—pushing pilots to prove operational restraint, not just write documentation.
Enterprises should redesign AI governance so risk tiering, model auditing, and AI incident response produce auditable proof of control, not shifting compliance theater.