This canvas covers how models for heavy-industry physical AI (construction, mining and earth-moving autonomy) are tracked, approved, shipped to machines, watched and retired, and how the governance around them works. It is the system of record that ties canvases 1–4 and 7 together. It is canvas 5 of 9 and follows a research-area exploration framework, with the Emerging (11–12) and Applied (13) modules added. Claims about the future are labeled as such; numbers carry a source or are marked as estimates.
| Boundary | Owned here | Owned elsewhere |
|---|---|---|
| Lineage | Model lineage: run → checkpoint → registered version → deployed artifact | Dataset lineage (canvas 1); joining both in the reference architecture (canvas 9) |
| Evaluation | Recording gate results and enforcing "no promotion without a pass" | Designing and running the gates (canvas 4) |
| Deployment | Release workflow, OTA delivery to machines, staged rollout, rollback | Optimizing and serving the model (canvas 7) |
| Monitoring | Model-quality monitoring: drift, performance, field feedback | Platform observability, SLOs and cost (canvas 8) |
| Governance | Model inventory, risk tiers, approvals, documentation, audit | Safety case content (canvas 4); legal interpretation (qualified counsel) |
Definition. Model lifecycle management (MLOps) is the set of practices and systems that carry a model from a training run to a governed, deployed and monitored asset, and finally to retirement. Governance adds the rules on top: who may approve, what must be documented, what is audited. A model registry is the core: each registered version links back to the run, data and code that produced it (MLflow).
Physical AI changes the deployment end. Models ship over the air (OTA) to machines with intermittent connectivity, inside packages that must be signed, verified, installed atomically and rolled back if needed (Promwad).
The top row decides whether a model may ship; the bottom row ships it to machines, watches it and takes it back when needed. Every stage writes to the same lineage and audit trail.
Key sub-domains
| Sub-domain | Core question | Typical artifacts |
|---|---|---|
| Experiment tracking | What exactly happened in each run? | Run records: code commit, container, data version, config, metrics |
| Model registry | Which versions exist, and what state is each in? | Registered versions; stages or aliases (candidate, approved, deployed, retired) |
| Model lineage | Can a deployed model be traced to its data and code? | Lineage graph from dataset to machine |
| Release workflow | Who approves, based on what evidence? | Approval records, gate results (canvas 4), change tickets |
| Packaging and signing | Is the artifact on the machine the one that was approved? | Signed packages, SBOMs, model BOMs, hashes |
| Fleet deployment (OTA) | How do models reach machines safely? | Cohorts, canary plans, dual-slot installs, rollback |
| Model monitoring | Is the model still performing in the field? | Drift metrics, field KPIs, intervention rates |
| Governance and inventory | Which AI systems are in operation, at what risk tier, under which rules? | AI inventory, risk classification, model cards, audits |
| Retirement | When and how is a model removed? | Deprecation plans, archive policy |
Debate. Buy a unified platform (e.g. Databricks with Unity Catalog) or assemble open components (MLflow, Kubeflow, Argo, a lineage service)? Unified platforms give governance quickly; assembled stacks avoid lock-in and may fit edge deployment better. Hybrid setups are common in industrial settings (author's observation, not a measured share).
MLOps grew from the discovery that ML systems accrue hidden debt, through a wave of platforms, to today's mix of registry-centered governance and fleet-scale edge deployment.
| Year | Milestone | Why it matters here |
|---|---|---|
| 2026 | EU Digital Omnibus on AI (Regulation (EU) 2026/1744) in force 27 July: machinery removed from the AI Act's direct high-risk regime | AI requirements for machinery are expected to come through the Machinery Regulation instead |
| 2026 | Edge MLOps tooling matures: atomic OTA with rollback and cohort targeting for Jetson (Edge AI and Vision Alliance); Red Hat FlightCtl for edge GPU fleets | Fleet deployment becomes a product category |
| 2026 | A mining OEM reports commissioning its 1,000th autonomous ultra-class haul truck and describes a software-defined vehicle strategy in which machines improve over the life of the asset (Komatsu; company statement) | Autonomy fleets at this scale make software lifecycle a core operating concern |
| 2025 | MLflow 3: logged models and deployment jobs, governed by Unity Catalog (Databricks) | Registry becomes the hub for lineage and approvals |
| 2023 | ISO/IEC 42001 (AI management systems); NIST AI RMF 1.0 | First certifiable AI governance standard |
| 2022–2024 | LLMOps; EU AI Act adopted (2024) | Governance of foundation models; legal duties for AI |
| 2019 | Model Cards (Mitchell et al.); Datasheets for Datasets | Standard model documentation |
| 2018–2020 | MLflow (2018), Kubeflow, TFX, SageMaker; feature stores | First MLOps platforms |
| 2015 | Sculley et al., Hidden Technical Debt in ML Systems | ML systems need engineering discipline beyond the model |
| 2021 | UNECE R156 software-update management rules for road vehicles, in force from 22 January 2021 (EUR-Lex) | Regulated, signed software updates to vehicles; reference practice for machinery |
Paradigm shifts
From model files to registered, governed assets. Every version has an owner, lineage and approval state.
From cloud endpoints to fleets. For physical AI, "deploy" means a staged OTA rollout to machines, not an API swap. An industry blog reports that Waymo runs weekly model updates with staged canary cohorts (Metavert; secondary source).
From voluntary to regulated governance. AI inventories, risk tiers and documentation are becoming legal duties.
From one model to model systems. A single OTA package can carry perception, planning and monitoring models, each with its own provenance and rollback dependencies.
Cloud MLOps is largely solved with standard tools. The open problems for physical AI sit at the edges: shipping model systems to thousands of intermittently connected machines, monitoring them with little bandwidth, and proving provenance end to end.
Dominant frameworks
Registry-centered lifecycle. A central registry with lineage, access control and audit; MLflow with Unity Catalog is a common pattern (Databricks). Typical setups use separate dev, staging and prod catalogs (Marvelous MLOps).
Automotive-style OTA for models. Signed artifacts, secure transport, verification before install, atomic installation with rollback (Promwad). Runtime patterns: dual-slot storage, canary cohorts (for example 5% of vehicles first), monitoring after activation, automatic rollback (Promwad).
AI bill of materials (AIBOM). Machine-readable inventory of models, datasets and software; CycloneDX ML-BOM and SPDX 3.0 AI profiles are the two formats, and one practitioner source describes the format question as mostly settled (Tian Pan).
Management-system governance. ISO/IEC 42001 gives roles, risk processes and lifecycle controls; it is voluntary and not a substitute for legal conformity (TCSA).
Key research questions
| Question | State of evidence |
|---|---|
| How can model quality be monitored on machines with little bandwidth? | Tiered telemetry: summaries always, samples on triggers, full logs rarely (Red Hat) |
| Where should drift be detected: on the machine or centrally? | Central aggregation can miss drift in small subsets of devices; on-device checks help (US patent 12688110) |
| How is a model system versioned, not just a model? | Package-level versions with per-model provenance; dependency-aware rollback (practice proposal; little published evidence) |
| What lineage is enough for audit? | Run + data + code + evaluation + approval + deployment; AIBOMs still lack AI-specific assurance fields (AIRS, arXiv 2511.12668) |
| How should models that learn after deployment be governed? | Open; most regulated products freeze models between releases |
Challenges for heavy equipment
Connectivity. Mines and remote sites may have hours or days without upload capacity (general characterization; varies by site).
Long product lives. Machines commonly run for many years, often a decade or more (estimate); models must be supported across many hardware generations.
Model supply chain. Open checkpoints from public hubs and vendors bring licence and tampering risk.
Dealer and customer roles. Updates may need customer consent and service windows.
Retrofit autonomy. Autonomy kits fitted to existing machines (as in some construction autonomy products) add a second software owner on a machine whose base software is controlled by someone else.
Debates
Weekly model updates (AV practice) vs quarterly, heavily validated releases (machinery practice).
Central platform team owns deployment vs product teams own their models end to end.
Governance as gatekeeping vs governance as automated paved road.
MLOps is shaped by platform vendors and open-source projects more than by academia; governance by standards bodies and regulators.
| Cluster | Who | Contribution to this canvas |
|---|---|---|
| Registry and tracking platforms | Databricks (MLflow, Unity Catalog); Weights & Biases; Google Vertex AI; AWS SageMaker; Azure ML | Registries, lineage, approvals |
| Open-source MLOps | MLflow, Kubeflow, KServe, Argo, DVC/lakeFS, OpenLineage, Feast | Components for an assembled stack |
| NVIDIA stack | NGC registry, NVIDIA AI Enterprise, Fleet Command, OSMO | Model packaging and edge deployment in the NVIDIA ecosystem |
| Edge fleet management | Peridio / Avocado OS (Jetson), Red Hat FlightCtl and OpenShift AI, Mender, AWS IoT Greengrass, Azure IoT Edge, Foundries.io | OTA, rollback, cohort targeting on edge devices |
| Supply chain and AIBOM | OWASP (CycloneDX, AIBOM initiative), Linux Foundation (SPDX), Sigstore and OpenSSF model signing | Provenance and signing standards |
| Governance standards and regulators | ISO/IEC JTC 1/SC 42 (42001, 23894); NIST (AI RMF); European Commission (AI Act, Machinery Regulation delegated acts); UNECE (R156 software updates) | Rules and frameworks |
| Research | Sculley et al. (Google, ML technical debt); Mitchell, Gebru (model cards, datasheets); CMU SEI (ML engineering) | Foundations of ML engineering practice |
Inside heavy-equipment OEMs and autonomy developers (public evidence).
Mining haulage at fleet scale. Komatsu states it has commissioned its 1,000th autonomous ultra-class haul truck, at a customer mine in Nevada, and describes a software-defined vehicle strategy built on a unified vehicle and autonomy platform in which machines keep improving "over the life of the asset" (Komatsu newsroom; company statements). The release does not describe how updates are delivered, so the mechanism is not public in that source.
Retrofit construction autonomy. Bedrock Robotics says its system, added to existing excavators as a sensor and compute package, is running without onboard operators on several U.S. sites after a year of supervised testing; the machines stop when sensors detect a person or object nearby, and operate autonomously only in approved conditions (Construction Dive; company claims, not independently verified there). Built Robotics likewise sells autonomy that converts conventional excavators into near-autonomous machines (CRE Tech).
Automotive and robotaxi practice as the reference. Waymo-style staged canary rollouts (secondary source above) and UNECE R156 software-update management are the practices heavy-industry teams most often borrow from.
Implication, labeled as inference. Public material from these actors describes autonomy deployments and safety behavior, but little about registries, lineage or rollback. The lifecycle layer is largely undisclosed, so claims about industry practice here rest on automotive and edge-MLOps analogues.
Debate. Who owns the AI inventory and risk classification: IT governance, product safety, or legal? In practice it needs all three, with one accountable owner.
Methods group by lifecycle stage. Defaults are mature; the frontier is edge-specific.
| Stage | Default method | Frontier |
|---|---|---|
| Track | Log every run: code commit, container digest, dataset IDs, config, seed, metrics | Automatic capture from orchestrator, no manual logging |
| Register | Register versions with signatures; aliases for candidate, approved, deployed; enforced model signatures (Marvelous MLOps) | Registry enforces policy (no evidence, no promotion) |
| Approve | Risk-tiered approval: light for internal tools, full board for safety functions | Policy-as-code approvals tied to canvas 4 evidence |
| Package | Container or engine file + config + AIBOM; signed (Sigstore or hardware-backed CA) (Petronella) | Attestation graphs linking every artifact |
| Deploy to fleet | Atomic, image-based OTA; phased cohorts; air-gapped delivery where needed (Peridio) | Delta updates for large models over weak links |
| Monitor | On-machine summaries (confidence, OOD rate, latency); field KPIs; intervention rates; sampled uploads | On-device drift detection with central root-cause analysis (Nazar, arXiv 2305.07772) |
| Respond | Automatic rollback on anomaly; incident review | Component-level rollback inside a model system |
| Retire | Deprecation notice; archive with lineage; delete per retention policy | Automated end-of-support across hardware generations |
Governance methods
AI inventory with owner, purpose, risk tier, deployment footprint.
Model cards and dataset cards for every registered version.
Change control: what changed, why, who approved, which evidence.
Periodic review of deployed models: performance, incidents, licence status.
Analysis techniques
Lineage queries: which machines run a model trained on a given dataset?
Release health: rollback rate, time to detect regression.
Fleet version census: which model versions run where.
The registry is the system of record every other canvas writes to or reads from.
| Connects to | What crosses the boundary | Contract to define |
|---|---|---|
| Canvas 1: data flywheel | Dataset IDs and hashes; field-monitoring triggers back into mining | Shared lineage IDs (OpenLineage); monitoring alerts become data requests |
| Canvas 2: simulation | Simulator and asset versions used in training and evaluation | Simulator version recorded per model |
| Canvas 3: training | Run manifests and checkpoints | Registry rejects checkpoints without complete manifests |
| Canvas 4: evaluation | Gate results and safety-case evidence | No promotion without a stored, passed gate |
| Canvas 6: GPU infrastructure | Training and evaluation jobs triggered by the release pipeline | Pipeline service accounts and quotas |
| Canvas 7: inference | Optimized engines as registered artifacts | Engine built from a registered model; both versions linked |
| Canvas 8: observability | Model-quality metrics alongside platform metrics | Shared metric names and dashboards |
| Canvas 9: reference architecture | Lifecycle as a platform standard across an organization | One registry, one AIBOM format, one release process |
Outside fields
Automotive and machinery software-update practice: UNECE R156 software-update management, secure boot, functional safety for updates.
Cybersecurity: signing, supply-chain security, vulnerability management (CVE tracking for model runtimes).
Law and compliance: licences, customer contracts, EU Data Act (customer access to machine data), product liability.
Quality management: ISO 9001-style change control; ISO/IEC 42001 integrates with existing management systems.
The lifecycle is moving from human-run processes to automated, policy-driven pipelines that produce audit evidence as a by-product. The trends below are directions, not predictions with dates.
Emerging trends
Governance as code. Approval rules, risk tiers and required evidence encoded and enforced by the registry and CI.
Attested supply chains. Every model, dataset and container signed and linked in an attestation graph (Petronella).
AIBOM by default. Generated from instrumentation, not written by hand; one practitioner source reports procurement and regulators already ask for it (Tian Pan).
Model-system releases. Versioning and rollback of bundles (perception + planner + monitor) as one unit with internal dependencies.
Edge-native monitoring. Drift detection on the machine, with only summaries and trigger samples uploaded.
Sector-specific AI rules. For machinery, AI requirements are set to move into the Machinery Regulation via delegated acts rather than the AI Act (EUROGIP).
Software-defined heavy equipment. OEM statements point to machines that change through software over their service life (Komatsu), which raises the importance of every item above.
Research gaps in heavy-industry physical AI
| Gap | Why it is open | Opportunity |
|---|---|---|
| Monitoring under very low bandwidth | Most edge MLOps assumes regular connectivity | Budgeted telemetry designs for mines and remote sites |
| Lifecycle over long machine lives | MLOps practice assumes short product cycles | Support policies across compute-hardware generations; model end-of-life rules |
| Customer-consented updates | Consumer OTA assumes manufacturer control | Update workflows integrated with dealers and customer fleet managers |
| Retrofit autonomy lifecycle | Autonomy kits on third-party machines split ownership of software and safety evidence | Interface contracts for updates and evidence between kit maker and machine maker |
| Evidence reuse across regulations | Machinery Regulation, ISO 17757, ISO 42001 and customer audits ask for overlapping evidence | One evidence store mapped to each regime |
Potential breakthroughs
Any deployed model on any machine traceable to its data, code, evaluation and approval in one query.
Safe, automated frequent updates for non-safety models, with safety models on a slower, gated track.
Tools and platforms, by layer
| Layer | Open source / standards | Commercial / vendor |
|---|---|---|
| Tracking and registry | MLflow 3 (OSS), Kubeflow Model Registry, Aim | Databricks Unity Catalog, Weights & Biases, Vertex AI, SageMaker |
| Pipelines and CI/CD | Argo Workflows and CD, Tekton, GitHub Actions, Kubeflow Pipelines | Azure DevOps, GitLab |
| Lineage | OpenLineage, Marquez, DataHub | Unity Catalog lineage, Collibra |
| Packaging and signing | OCI artifacts, Sigstore / cosign, OpenSSF model signing | NGC private registry |
| AIBOM | CycloneDX 1.6 ML-BOM (ECMA-424), SPDX 3.0 AI profile | — |
| Edge fleet deployment | Mender, FlightCtl, K3s / KubeEdge | Peridio, AWS IoT Greengrass, Azure IoT Edge, NVIDIA Fleet Command |
| Monitoring | Evidently, Prometheus / Grafana, TrustyAI | Arize, Fiddler, WhyLabs |
| Governance | ISO/IEC 42001 templates; NIST AI RMF playbook | Credo AI, IBM watsonx.governance, OneTrust |
Standards
ISO/IEC 42001 (AI management system); ISO/IEC 23894 (AI risk management); NIST AI RMF 1.0.
UNECE R155/R156 (cybersecurity and software updates for vehicles) as reference practice.
EU Machinery Regulation 2023/1230 and its coming AI delegated acts; EU AI Act as amended by Regulation (EU) 2026/1744.
Conferences and journals
MLSys; USENIX OpML; Data + AI Summit; KubeCon (MLOps tracks).
ACM FAccT and AIES for governance; IEEE Software for ML engineering.
Funding sources
Public: NIST (AI standards); EU Horizon (trustworthy AI).
Private: venture funding for autonomy developers (for example, Bedrock Robotics reports a $600 million Series C, per Automate; company-reported); OEM and operator R&D budgets (amounts not public at this granularity).
MLOps literature is mostly practitioner writing and standards; a few papers define the field.
Recent influential works (2023–2026)
| Year | Work | One-line takeaway |
|---|---|---|
| 2026 | Regulation (EU) 2026/1744 (Digital Omnibus on AI) | Machinery leaves the AI Act's direct scope; requirements to arrive via Machinery Regulation delegated acts (DLA Piper) |
| 2026 | Red Hat, MLOps for edge AI series | Tiered telemetry and feedback loops for edge fleets (Red Hat) |
| 2025 | Nathanson et al., AIRS framework | AIBOMs need verifiable security-assurance fields beyond SPDX 3.0 and CycloneDX 1.6 |
| 2025 | MLflow 3 | Logged models and deployment jobs; registry as governance hub |
| 2023 | ISO/IEC 42001 | Certifiable AI management system |
| 2023 | Hutchinson et al. / Shankar et al., operationalizing ML interview studies | What production ML teams actually do |
| 2023 | Nazar: Monitoring and Adapting ML Models on Mobile Devices | On-device drift detection plus cloud root-cause analysis |
Seminal works
| Year | Work | Contribution |
|---|---|---|
| 2015 | Sculley et al., Hidden Technical Debt in ML Systems | ML-specific engineering debt |
| 2017 | Breck et al., The ML Test Score | Checklist for production readiness |
| 2019 | Mitchell et al., Model Cards for Model Reporting | Standard model documentation |
| 2021 | Gebru et al., Datasheets for Datasets | Standard dataset documentation |
| 2020 | Paleyes et al., Challenges in Deploying ML: a survey | Deployment failure modes |
| 2022 | Kreuzberger et al., MLOps: Overview, Definition, and Architecture | Reference definition and architecture |
Gap in the literature: the author found almost nothing published on lifecycle management for learned models on long-lived heavy machinery fleets (absence in a limited search, not proof of absence).
Heavy-industry model portfolios need at least two release tracks: a fast track for models that do not touch machine safety, and a gated track for those that do. The table is a field-level proposal, not a description of any organization.
| Application area | Release track | Deployment target | Lifecycle notes |
|---|---|---|---|
| Person and obstacle detection (construction and mining) | Gated (safety) | On-machine edge compute | Full lineage; staged OTA; rollback tested every release |
| Construction autonomy policies (excavation, dozing, grading) | Gated (safety) | On-machine compute | Bundled with planner and monitors; component-level rollback; for retrofit kits, evidence interfaces with the machine maker |
| Mining haulage autonomy | Gated (safety) | On-truck compute plus site fleet-management system | Site-by-site staged rollout; customer-approved change windows |
| In-cab and operator assistance (voice or vision assistants) | Fast, with content-safety gates | On-machine and cloud | Frequent updates; hallucination and safety monitoring; no covert operator monitoring |
| Predictive maintenance | Fast | Cloud | Drift monitoring on telemetry; retrain on schedule |
| Jobsite digital twins and planning | Fast | Cloud | Linked to site data products and simulator versions (canvas 2) |
Industry connections
Equipment OEMs and autonomy developers: existing telematics, remote updates and fleet-management systems are the natural delivery channels where they exist.
NVIDIA: NGC, Fleet Command and NVIDIA AI Enterprise for packaging and edge management.
Dealers and site operators: service windows, customer consent and on-site rollback support.
Auditors and notified bodies: evidence for Machinery Regulation conformity and ISO/IEC 42001 certification where pursued.
Future applications (labeled as possibilities): customer-visible model versions and release notes per machine; automated compliance reports per market.
Technology integration
One registry across cloud and edge. Cloud models and on-machine engines share one inventory and lineage graph.
OTA on existing channels. Where a machine already receives remote software updates, model packages can ride that channel with model-specific checks (signature, runtime compatibility, dual-slot install).
Telemetry budget. Each machine has a monitoring budget: always-on summaries, trigger-based samples, rare full uploads.
Security. Signed artifacts, secure boot on Jetson, CVE tracking for model runtimes and containers (Edge AI and Vision Alliance).
Ethical considerations
Silent changes. Customers and operators should know when a model that affects machine behavior changes; release notes per machine.
Operator monitoring. Field monitoring of model performance must not turn into covert monitoring of operators.
Accountability. Every deployed model has a named owner who answers for it.
Third-party models. Using open checkpoints carries licence, bias and tampering risks that must be recorded in the AIBOM.
Regulatory requirements
| Rule | Status (as of November 2026) | What it means for the lifecycle |
|---|---|---|
| EU AI Act as amended by Regulation (EU) 2026/1744 | In force 27 July 2026 (Cooley) | Machinery removed from direct AI Act high-risk scope; stand-alone high-risk dates moved to 2 December 2027, embedded to 2 August 2028 (ISMS.online) |
| EU Machinery Regulation 2023/1230 | Applies 20 January 2027 | Commission to add AI Act high-risk requirements (risk management, data governance, logging, post-market monitoring) into its Annex III by delegated act (euaiact.com); timing of that act still open |
| ISO/IEC 42001 | Voluntary, certifiable | A governance base that maps onto both regimes, but not a substitute for conformity (Holistic AI) |
| EU Data Act | Applies from September 2025 | Customers' right to access machine data affects monitoring and data reuse |
| UNECE R155/R156 | For road vehicles; R156 in force from 22 January 2021 (EUR-Lex); reference practice | Software-update management system as a model for OTA governance |
Implication: a lifecycle designed to produce the evidence the Machinery Regulation's coming AI requirements are expected to ask for (risk management, data governance, logging, post-market monitoring) is better placed even before the delegated act is final. Worker groups have criticized the carve-out (Social Europe), so expect scrutiny.
Build in four phases. Start with an inventory and one registry; automate approvals and fleet rollout once the records exist.
Phases are sequenced, not dated. Phase 1 is highlighted because governance can't apply to models nobody has listed.
Required resources
Teams: MLOps platform engineers; edge and embedded engineers for OTA; a governance lead with legal and safety partners; product model owners.
Infrastructure: registry and tracking service; CI/CD with signing; artifact store; edge deployment service integrated with the machine update channel; monitoring pipeline.
Partners: compute-platform vendors, dealers or site integrators, assessors.
Risk assessment (likelihood and impact are the author's qualitative estimates)
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Bad model reaches many machines | Medium | High | Staged cohorts; automatic rollback; gated track for safety models |
| Lineage gaps found during an audit or incident | Medium | High | Registry blocks versions without complete manifests and evidence |
| Parallel shadow MLOps stacks in product teams | High | Medium | Paved road that is faster than workarounds; central inventory mandate |
| OTA fails at remote sites | Medium | Medium | Dual-slot install; resume-able, delta downloads; dealer-assisted updates |
| Regulation changes under the program | High | Medium | Evidence store mapped to requirements, not to one law |
| Compromised third-party model | Low | High | Signature and hash checks; AIBOM; scanning before registration |
Success metrics
| Metric | What it shows |
|---|---|
| Deployed models fully traceable to data, code, evaluation and approval (%) | Governance completeness |
| Time from approved model to fleet-wide deployment (days) | Delivery speed |
| Releases rolled back (%) and time to rollback (hours) | Release safety |
| Time to detect a field regression (hours) | Monitoring effectiveness |
| Machines on a supported model version (%) | Fleet hygiene |
| AI systems in the inventory with a risk tier and owner (%) | Inventory coverage |
Set targets after phase 1 baselines.
Open questions for practitioners
Unified platform (Databricks / Unity Catalog) or assembled open stack for the registry?
Can model packages use a machine's existing remote-update channel, and what changes are needed?
Which models go on the gated safety track, and who decides?
Is ISO/IEC 42001 certification worth pursuing for a given product line?
What telemetry budget per machine is acceptable to customers?
Who owns the AI inventory and risk classification?
For retrofit autonomy kits, who owns update approval and safety evidence: the kit maker or the machine maker?
Follow-up prompts (from the research-area framework)
Elaborate on a registry data model linking datasets, runs, models, engines, evaluations and deployments.
Provide detailed methods for staged OTA rollout of a person-detection model to a mixed-connectivity fleet.
Analyze what the coming Machinery Regulation AI delegated act may require from the lifecycle.
Suggest a telemetry design for drift detection under a fixed daily upload budget.
MLflow Model Registry (MLflow); MLflow 3 on Databricks; Models in Unity Catalog (Databricks)
Lessons learned from migrating models to Unity Catalog (Marvelous MLOps)
Managing AI model versions on deployed hardware and OTA for ML models in cars (Promwad)
Jetson provisioning with Avocado OS (Edge AI and Vision Alliance); Peridio
MLOps for automotive AI (Metavert)
MLOps for edge AI: keeping models accurate over time (Red Hat)
AI Bill of Materials (Petronella); AIBOM when procurement asks (Tian Pan); AIRS framework
Digital Omnibus on AI (Cooley); DLA Piper analysis; What the Omnibus changes for the Machinery Regulation (EUROGIP); Sectoral amendments (euaiact.com); Social Europe commentary
EU AI Act deadline delayed (ISMS.online); ISO 42001 vs EU AI Act (TCSA); Holistic AI
Komatsu commissions 1,000th autonomous ultra-class haul truck (Komatsu newsroom); Bedrock Robotics fully autonomous excavators (Construction Dive); Built Robotics autonomous machinery (CRE Tech); Bedrock Robotics Series C (Automate)
UN Regulation No. 156, software update management (EUR-Lex 2021/388)