14. Emerging Trends and Future Directions

Introduction and Context

The Internet of Things (IoT) has evolved from a network of identifiable devices into a distributed computational environment in which sensors, communication systems, cloud platforms, artificial intelligence, and human organisations interact continuously. Earlier IoT analytics architectures generally transmitted data from devices to centralised platforms for storage and analysis. That model remains important, but it is increasingly inadequate when decisions must be made within milliseconds, data cannot leave its source, connectivity is intermittent, or the cost of transmitting enormous data volumes is unacceptable.

The next phase of IoT analytics is therefore characterised by intelligence moving closer to the physical world, collaboration among multiple data owners, learning systems that adapt after deployment, and communication networks designed for highly diverse requirements. At the same time, IoT systems are becoming more autonomous and more deeply integrated into critical infrastructure. These developments create opportunities in healthcare, manufacturing, agriculture, transport, energy, logistics, and public administration, but they also raise questions concerning safety, privacy, accountability, energy consumption, interoperability, and employment.

This chapter examines the principal directions shaping IoT analytics: TinyML and edge intelligence, federated and continual learning, generative AI, autonomous systems, 5G and 6G, semantic interoperability, blockchain-enabled trust, and sustainable IoT. The discussion treats these technologies not as isolated innovations but as interacting parts of an emerging socio-technical system. The central issue is not simply whether a technology is technically possible. It is whether it can be deployed responsibly, economically, securely, and at a scale appropriate to the application.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the role of TinyML, edge analytics, federated learning, and continual learning in future IoT architectures.

2. Evaluate the opportunities and risks of generative AI and autonomous systems in physical environments.

3. Analyse how 5G and prospective 6G capabilities influence IoT analytics.

4. Explain semantic interoperability and blockchain-enabled trust in multi-organisational IoT ecosystems.

5. Assess the environmental, ethical, governance, and workforce implications of emerging IoT technologies.

6. Design a reasoned innovation and risk-management strategy for a future IoT application.

From Cloud-Centred IoT to Distributed Intelligence

A useful way to understand future IoT is to distinguish four locations of computation: the device, the edge gateway, the network edge, and the cloud. Device-level processing provides the lowest latency and strongest local privacy, but devices have limited memory, energy, and processing capacity. Edge gateways aggregate information from several devices and can perform more complex analysis. Network-edge platforms provide scalable computation close to users and machines. Cloud platforms remain valuable for large-scale model training, historical analysis, fleet management, and cross-site optimisation.

The emerging architecture is consequently heterogeneous rather than exclusively centralised or decentralised. A vibration sensor may detect a possible fault locally; an edge server may compare the signal with a machine-specific model; a cloud platform may retrain a fleet-wide model; and a human engineer may approve a maintenance action. Analytics becomes a pipeline of decisions distributed across technological and organisational boundaries.

A key design principle is proportionality. Data should be processed at the location that best balances latency, accuracy, energy, privacy, cost, and governance. Sending every raw measurement to the cloud is often wasteful. Conversely, placing a complex model on a constrained sensor may produce unreliable results or excessive energy use. Architects therefore increasingly use hierarchical analytics, event-triggered communication, model compression, and adaptive workload allocation.

TinyML: Intelligence Under Severe Constraints

TinyML refers to the execution of machine-learning inference on very small, low-power devices such as microcontrollers and embedded sensors. These devices may have only limited memory and computational capability, and may operate for months or years on batteries. TinyML is not simply “small AI”; it requires models, data pipelines, hardware, and software to be designed together.

A typical TinyML workflow begins with sensor selection and signal conditioning. Data are collected, labelled, and transformed into compact features or representations. A model is trained, quantised, pruned, and converted into an embedded format. It is then tested under realistic conditions, including sensor drift, temperature changes, noisy signals, and battery constraints. The device usually performs inference locally and transmits only an event, score, or compressed summary.

Common optimisation techniques include quantisation, which represents parameters with fewer bits; pruning, which removes low-value connections; knowledge distillation, in which a smaller model learns from a larger teacher model; and windowing, which analyses only relevant segments of a continuous signal. A successful TinyML system must be evaluated not only by accuracy but also by memory footprint, inference latency, energy per inference, false-alarm rate, and resilience to changing conditions.

Applications include detecting abnormal motor vibration, recognising machinery sounds, identifying crop disease from low-resolution images, monitoring breathing patterns, and detecting structural stress. Local inference can reduce bandwidth and protect sensitive data. However, TinyML models may be less accurate than cloud models, difficult to update, vulnerable to physical tampering, and biased when training data do not represent field conditions. Model compression can also remove information unevenly, harming minority or unusual cases.

Federated and Continual Learning

Federated learning enables multiple devices or organisations to train a shared model without directly pooling their raw data. In a common arrangement, a coordinator sends a model to participating devices, each device performs local training, and the coordinator aggregates model updates. The updated model is redistributed for another round. Variants include cross-device federated learning, involving many relatively unreliable devices, and cross-silo federated learning, involving a smaller number of organisations such as hospitals or factories.

Federated learning improves data governance but does not automatically guarantee privacy. Model updates can reveal information, participants can send malicious updates, and the coordinator may infer characteristics of local datasets. Differential privacy, secure aggregation, encryption, access controls, and robust aggregation can reduce these risks. There are also practical problems: devices may have unequal data quality, intermittent connectivity, different hardware, and non-identically distributed data. A model trained on urban traffic data may perform poorly for a rural participant even when the global average appears satisfactory.

Continual learning addresses the fact that IoT environments change. Sensors age, machines are replaced, user behaviour evolves, and seasonal conditions alter data distributions. A static model may experience concept drift or data drift. Continual-learning systems update their knowledge incrementally while attempting to retain important previous knowledge. Replay buffers, regularisation, dynamic architectures, and drift-detection methods are commonly used.

The central difficulty is catastrophic forgetting: learning new patterns can reduce performance on earlier patterns. A production system therefore requires policies specifying when a model may update, which data may be retained, how changes are validated, and when human approval is necessary. Model versioning, rollback mechanisms, shadow deployment, and performance monitoring are essential. In safety-critical settings, continual learning should usually be constrained rather than allowed to alter behaviour without supervision.

Generative AI in IoT Analytics

Generative AI can produce text, code, images, synthetic sensor data, summaries, and proposed actions. In IoT, large language models and multimodal models may provide natural-language interfaces to operational data, generate maintenance reports, assist engineers in querying complex systems, or create synthetic examples of rare failures. Generative models can also help translate between device protocols and generate software for data transformation.

A manufacturing analyst, for example, might ask why a production line experienced repeated stoppages. An AI assistant could combine time-series data, maintenance logs, environmental readings, and standard operating procedures to produce a ranked set of hypotheses. Such a system is valuable when it supports, rather than replaces, engineering judgement. Retrieval-augmented generation, in which responses are grounded in approved enterprise documents and live data, can reduce unsupported responses. Tool-use controls can restrict the model to authorised actions.

Generative AI introduces distinctive risks. A model may hallucinate an explanation, misinterpret a sensor anomaly, expose confidential information, or generate unsafe control instructions. Synthetic data may reproduce the biases or unrealistic correlations of its source data. Prompt injection is especially significant when a model reads untrusted device messages or maintenance documents. Consequently, generative AI should be separated from direct actuation unless strong validation, access control, simulation, and human authorisation are present.

A useful governance pattern distinguishes three modes: advisory systems that only explain or recommend; supervised operational systems that execute predefined actions after approval; and autonomous systems that act within formally specified safety boundaries. Most industrial and public-sector deployments should begin in the first mode and progress only after evidence demonstrates reliability.

Autonomous and Cyber-Physical Systems

An autonomous IoT system senses its environment, forms an internal representation, selects actions, and observes the consequences. Examples include warehouse robots, autonomous vehicles, adaptive energy systems, precision irrigation, and intelligent buildings. These are cyber-physical systems because computational decisions influence physical processes, and physical outcomes affect later computation.

Autonomy can be analysed as a loop: perception, state estimation, planning, action, and feedback. Analytics supports each stage. Perception transforms sensor signals into objects or events; state estimation combines uncertain observations; planning evaluates possible actions; control executes decisions; and feedback tests whether the action achieved its objective. Failures can arise at any stage, including sensor failure, inaccurate models, delayed communication, poor planning, or unexpected interaction with humans.

The appropriate level of autonomy depends on consequence, reversibility, and observability. An automated irrigation adjustment is generally more reversible than an emergency braking decision. Systems should therefore define operational design domains, fail-safe states, fallback sensors, geofencing, confidence thresholds, and escalation procedures. Human oversight must be meaningful: a nominal approval button is inadequate if the operator lacks time, information, or authority to intervene.

5G, 6G, and the Communications Substrate

5G supports IoT through enhanced mobile broadband, ultra-reliable low-latency communication, and massive machine-type communication. Network slicing can allocate logically separated resources to applications with different performance and security requirements. Multi-access edge computing places computation near the radio network, reducing latency for applications such as industrial inspection, augmented reality, and connected transport.

The benefits of 5G are not automatic. Coverage, spectrum availability, subscription cost, device power consumption, handover behaviour, and cybersecurity must be considered. A low nominal latency does not guarantee low end-to-end latency if data processing or control logic remains remote. Engineers should measure the complete path from sensing to action.

Research into 6G explores integrated sensing and communication, more intelligent networks, advanced positioning, distributed AI, non-terrestrial networks, and higher-frequency communications. These capabilities may support highly precise localisation and pervasive machine coordination. Nevertheless, 6G remains a research and standardisation area rather than a universally available operational platform. Claims about future performance should therefore be treated as scenarios, not established deployment facts.

Semantic Interoperability: From Data Exchange to Shared Meaning

Technical interoperability allows systems to connect; syntactic interoperability allows them to exchange data in agreed formats; semantic interoperability allows them to interpret data consistently. IoT analytics requires the third level. A value labelled “temperature” is not sufficient unless systems also know the unit, measurement location, timestamp, calibration status, and meaning of the observation.

Ontologies, knowledge graphs, metadata standards, digital twins, and common vocabularies support semantic interoperability. An ontology represents concepts and relationships in a domain, such as the relationship among a machine, its component, a sensor, a measurement, and a maintenance event. Knowledge graphs connect these concepts across data sources and make contextual queries possible.

Semantic interoperability improves analytics across vendors and organisational boundaries, but it requires governance. Participants must agree on definitions, identifiers, versioning, provenance, and responsibility for maintaining shared models. Poorly designed ontologies can be too rigid for innovation or too vague to support reliable inference. Interoperability should therefore be treated as an institutional capability, not merely a software feature.

Blockchain-Enabled Trust and Its Boundaries

Blockchain and distributed-ledger technologies can provide a tamper-evident record of transactions among parties that do not fully trust one another. In IoT, a ledger may record device registration, data provenance, maintenance events, software updates, or access permissions. Smart contracts can automate agreed rules, such as releasing payment after a verified delivery condition.

The ledger does not automatically prove that a sensor measurement is true. It can preserve a submitted record, but a compromised sensor may submit false data. Trust therefore requires secure hardware, device identity, calibration, attestation, audit procedures, and governance in addition to ledger technology. Privacy is another concern: immutable records may conflict with data minimisation and rights to correction or deletion.

Blockchain is most appropriate when several organisations need a shared, auditable record and no single party should control it completely. It is often unnecessary for a trusted internal system. Energy consumption, transaction throughput, latency, key management, and legal responsibility must be assessed before adoption. Permissioned ledgers may be more suitable than open public networks for industrial IoT.

Sustainable IoT and Responsible Innovation

IoT can support sustainability by reducing waste, optimising energy use, enabling predictive maintenance, improving transport efficiency, and monitoring environmental conditions. Yet IoT also consumes energy and materials through devices, networks, data centres, batteries, and electronic waste. The correct question is not whether IoT is inherently green, but whether its complete life-cycle impact is positive for a defined service.

Sustainable design includes low-power communication, energy harvesting where appropriate, durable hardware, repairability, modular upgrades, efficient models, local processing, renewable-energy procurement, and responsible end-of-life recovery. Designers should measure embodied carbon, operational energy, battery replacement, data-transfer volume, and device lifespan. A highly accurate AI model that requires frequent battery replacement may be less sustainable than a simpler model with slightly lower accuracy.

Responsible innovation also includes social sustainability. Systems should be accessible, understandable, and non-discriminatory. Worker monitoring, smart-city surveillance, and health sensing can create benefits but may also produce coercion or unequal treatment. Privacy impact assessments, algorithmic impact assessments, stakeholder consultation, and transparent procurement are therefore important components of sustainable IoT.

An Integrated Evaluation Framework

Technology selection should follow a structured evaluation rather than enthusiasm for novelty. A practical framework examines six dimensions:

• Value: What measurable operational, social, or environmental problem is addressed?
• Feasibility: Can the required data, connectivity, skills, hardware, and maintenance be provided?
• Trustworthiness: Are privacy, security, safety, fairness, explainability, and accountability adequate?
• Adaptability: Can the system cope with drift, changing users, new devices, and evolving regulations?
• Sustainability: What are the life-cycle energy, material, and social impacts?
• Governance: Who owns the data, approves model changes, responds to failure, and bears liability?

These dimensions should be translated into measurable criteria. Examples include detection precision, end-to-end latency, energy per event, model update frequency, percentage of interoperable devices, recovery time after compromise, and carbon emissions per delivered service. Multi-criteria decision analysis can make trade-offs explicit, although numerical scoring should not disguise uncertainty or ethical disagreement.

Illustrative Case Study: Federated Predictive Maintenance in a Distributed Factory Network

Background

Consider an illustrative consortium of five manufacturing plants operated by the same industrial group. Each plant uses similar motors but has different production schedules, environmental conditions, and maintenance histories. The company wishes to predict bearing failures several days in advance.

Situation and Problem

A central cloud model performs adequately at two plants but poorly at the others. Raw vibration data cannot be freely pooled because of contractual restrictions and concerns about revealing production information. Continuous transmission is expensive, and some sensors have limited connectivity. The company also needs to demonstrate that automated recommendations do not create unsafe maintenance actions.

Analysis

The data are non-identically distributed: a plant operating in a humid environment generates different signals from a plant with highly variable loads. A single global model may therefore hide local weaknesses. The system also faces concept drift because motors are replaced and operating regimes change. Privacy protection must address both raw data and model updates.

Approach

The consortium deploys a hierarchical architecture. TinyML models perform initial vibration-event detection on sensors. Plant-edge servers extract features and train local models. A federated coordinator aggregates protected updates using secure aggregation and evaluates performance separately for each plant. Differential privacy is applied where the risk of inference is high, with an explicit assessment of its effect on accuracy.

Continual-learning policies allow local models to adapt only after drift detection and validation against a holdout set. A model registry records versions, training periods, data assumptions, and approval status. Recommendations are advisory: a maintenance engineer must confirm the work order. A knowledge graph links each prediction to the motor, sensor, operating condition, and maintenance history, improving interpretability.

Outcome

The approach reduces raw-data movement and provides better local adaptation than an unmodified global model. However, it requires investment in edge infrastructure, monitoring, federated coordination, and staff training. Performance is reported by plant and by operating condition rather than only as a single average score. When one plant experiences unusual sensor behaviour, the system suspends local updates and falls back to the previously approved model.

Learning Points

The case demonstrates that emerging technologies must be combined with governance. TinyML reduces communication, federated learning protects data sharing, continual learning addresses drift, semantic metadata supports interpretation, and human approval limits operational risk. None of these technologies independently solves the entire problem.

Challenges, Ethics, and Workforce Implications

Future IoT systems face attack surfaces at the device, firmware, network, model, application, and organisational levels. Common weaknesses include default credentials, insecure update mechanisms, exposed APIs, poisoned training data, model theft, and inadequate asset inventories. Security should be designed throughout the life cycle, with secure boot, signed updates, least privilege, segmentation, vulnerability management, incident response, and recovery testing.

Regulatory obligations vary by jurisdiction and sector, but organisations should expect increasing requirements for privacy, cybersecurity, product safety, AI accountability, data governance, and environmental reporting. Auditability requires records of data provenance, model versions, decisions, interventions, and incidents. Responsibility cannot be transferred to an algorithm or a cloud provider without contractual and operational clarity.

The workforce will not simply disappear; its composition will change. IoT professionals need competence in statistics, machine learning, embedded systems, networking, cybersecurity, domain engineering, data governance, and communication with stakeholders. New roles include edge-AI engineer, data steward, model-risk specialist, digital-twin architect, IoT security analyst, and AI assurance professional. Reskilling should combine technical training with safety, ethics, regulatory understanding, and practical judgement.

Best Practices for Future-Ready IoT Analytics

1. Begin with a clearly defined operational or social problem rather than a fashionable technology.

2. Use an architecture that assigns each computation to the most appropriate device, edge, or cloud layer.

3. Measure accuracy together with latency, energy, privacy risk, reliability, and maintenance cost.

4. Treat model updates as controlled changes requiring testing, versioning, rollback, and ownership.

5. Use semantic metadata and common identifiers from the beginning of a project.

6. Apply privacy-preserving learning only after analysing its actual threat model and utility trade-offs.

7. Keep autonomous actions within explicit safety boundaries and provide credible fallback modes.

8. Conduct life-cycle and stakeholder impact assessments before large-scale deployment.

9. Design for interoperability, repair, secure updates, and eventual decommissioning.

10. Develop workforce capability alongside technical infrastructure.

Research Directions

Important research questions remain open. These include reliable learning with highly non-identical distributed data; formal verification of adaptive and generative models; energy-aware model training; privacy guarantees that remain useful in small datasets; semantic standards that can evolve without fragmenting; and methods for measuring the social and environmental value of IoT. Research is also needed on human-autonomy collaboration, adversarial resilience, quantum-resistant device security, and the governance of cross-border sensor data.

A mature research agenda should combine laboratory evaluation with longitudinal field studies. IoT models often behave differently after months of deployment because hardware, users, environments, and incentives change. Evidence must therefore include operational reliability, maintenance burden, equity impacts, and failure recovery—not merely benchmark accuracy.

Chapter Summary

Future IoT analytics is moving toward distributed, adaptive, context-aware, and increasingly autonomous systems. TinyML places inference on constrained devices, reducing latency and communication but creating severe resource and update challenges. Federated learning supports collaborative modelling without centralising raw data, while continual learning addresses drift and changing environments; both require strong privacy, security, and model-governance controls. Generative AI can improve explanation, data synthesis, and operational assistance, but hallucination and unsafe actuation demand grounding and human oversight.

5G and emerging 6G networks provide important communication and edge-computing capabilities, although performance depends on the complete system. Semantic interoperability gives shared meaning to data, and blockchain may support provenance and accountability where multiple parties require a common record. Sustainable IoT evaluates energy, materials, carbon, repairability, and social consequences across the life cycle. Ultimately, future-ready IoT requires multidisciplinary skills, measurable governance, responsible autonomy, and decisions based on value and trust rather than novelty alone.

Key Terms

TinyML: Machine-learning inference performed on highly constrained embedded devices.

Edge analytics: Processing and analysis performed near the location where IoT data are generated.

Federated learning: Collaborative model training in which raw data remain at participating sites.

Continual learning: Incremental adaptation of a model to new data while attempting to retain previous knowledge.

Concept drift: Change over time in the relationship between inputs and the outcome being predicted.

Catastrophic forgetting: Loss of previously learned performance after a model learns new information.

Generative AI: AI that produces new content, predictions, code, or representations from learned patterns.

Autonomous system: A system that senses, decides, and acts with limited direct human intervention.

Cyber-physical system: A system in which computational processes interact continuously with physical processes.

Network slicing: Logical partitioning of network resources for applications with different requirements.

6G: A prospective generation of communication systems involving advanced connectivity, sensing, positioning, and distributed intelligence.

Semantic interoperability: The ability of systems to exchange data and interpret its meaning consistently.

Ontology: A formal representation of concepts and relationships in a domain.

Knowledge graph: A graph-based representation linking entities, attributes, and relationships.

Blockchain: A distributed ledger that records transactions in a tamper-evident manner.

Differential privacy: A mathematical approach that limits disclosure about an individual in statistical outputs.

Model drift: Degradation or change in model behaviour as data or operating conditions evolve.

Digital twin: A digital representation of a physical object or process that is updated with operational data.

Life-cycle assessment: Evaluation of environmental impacts across the stages of a product or service.

Human-in-the-loop: A design in which a person reviews, approves, or supervises an automated decision.

Review Questions

Short Answer Questions

1. What problem does TinyML address in conventional cloud-centred IoT architectures?

2. Distinguish federated learning from centralised machine-learning training.

3. What is catastrophic forgetting in continual learning?

4. Why does a blockchain record not guarantee that an IoT measurement is truthful?

5. Define semantic interoperability and explain why units alone are insufficient.

Long Answer Questions

1. Explain the design and evaluation requirements of a TinyML system for industrial monitoring.

2. Discuss the benefits, privacy risks, and governance requirements of federated learning in IoT.

3. Analyse the opportunities and risks of generative AI in operational and industrial IoT.

4. Explain how 5G, edge computing, and prospective 6G capabilities may reshape IoT analytics.

5. Discuss sustainable IoT as a life-cycle and socio-technical issue rather than simply an energy-efficiency problem.

Analytical / Application Questions

1. A hospital wants to use wearable devices from several departments to predict patient deterioration without transferring raw data. Propose an architecture and identify its privacy, model-drift, and human-oversight controls.

2. A smart-city authority proposes blockchain for every sensor reading. Using the trust and governance principles in this chapter, evaluate whether this is justified and recommend alternatives where appropriate.

3. Design an evaluation framework for an autonomous warehouse system. Specify the technical, safety, semantic, sustainability, and workforce criteria that should be assessed before deployment.

22. Multiple Choice Questions with Answers

Question 1

Which feature most directly distinguishes TinyML from ordinary cloud-based IoT analytics?

A. It requires all raw sensor data to be stored centrally.

B. It performs inference on highly constrained embedded devices.

C. It eliminates the need for model validation.

D. It can operate only with 5G connectivity.

Correct Answer: B. It performs inference on highly constrained embedded devices.

Question 2

In federated learning, why might a high global accuracy score be misleading?

A. All participating devices necessarily have identical data.

B. The model cannot be evaluated at individual sites.

C. Non-identical local data may produce poor performance for particular participants.

D. Federated models never use aggregation.

Correct Answer: C. Non-identical local data may produce poor performance for particular participants.

Question 3

Which control is most appropriate when a continually learning IoT model begins adapting to unusual sensor behaviour?

A. Allow unrestricted updates without recording versions.

B. Delete all historical training data.

C. Suspend updates, validate the new model, and retain a rollback option.

D. Increase the model's autonomy immediately.

Correct Answer: C. Suspend updates, validate the new model, and retain a rollback option.

Question 4

A generative AI assistant recommends a machine shutdown based on a maintenance log. What is the safest initial deployment approach?

A. Permit immediate shutdown for every recommendation.

B. Use the assistant only for advisory output grounded in approved data and reviewed by an engineer.

C. Ignore the underlying sensor data.

D. Remove access controls to improve flexibility.

Correct Answer: B. Use the assistant only for advisory output grounded in approved data and reviewed by an engineer.

Question 5

Which statement best describes semantic interoperability?

A. Devices use the same physical connector.

B. Systems exchange data using any available format.

C. Systems interpret exchanged data consistently, including its context and meaning.

D. All data are moved to one cloud platform.

Correct Answer: C. Systems interpret exchanged data consistently, including its context and meaning.

Question 6

What limitation of blockchain is illustrated by a compromised sensor submitting false data?

A. A ledger cannot preserve records once written.

B. A tamper-evident record does not verify the truth of the original input.

C. Blockchain automatically corrects sensor measurements.

D. Blockchain prevents device identity management.

Correct Answer: B. A tamper-evident record does not verify the truth of the original input.

Question 7

Which metric is especially important when comparing two IoT analytics models for battery-powered sensors?

A. Number of pages in the model documentation only.

B. Energy consumed per inference together with predictive performance.

C. Size of the cloud provider's marketing team.

D. Number of unrelated devices in the network.

Correct Answer: B. Energy consumed per inference together with predictive performance.

Question 8

Why is end-to-end latency more informative than radio latency in an autonomous IoT application?

A. Decision time also includes processing, networking, and actuation delays.

B. Radio latency is always greater than end-to-end latency.

C. End-to-end latency measures only battery life.

D. Autonomous systems do not use communication networks.

Correct Answer: A. Decision time also includes processing, networking, and actuation delays.

Question 9

Which action best supports sustainable IoT design?

A. Maximise data transmission regardless of its value.

B. Replace devices frequently to obtain minor model improvements.

C. Consider energy, materials, repairability, and end-of-life impacts across the life cycle.

D. Use the largest available model in every device.

Correct Answer: C. Consider energy, materials, repairability, and end-of-life impacts across the life cycle.

Question 10

In the illustrative predictive-maintenance case, why were recommendations kept advisory?

A. The system had no sensors.

B. Human approval reduced the risk of unsafe automated maintenance actions.

C. Federated learning cannot produce predictions.

D. Semantic metadata prevented engineers from reading results.

Correct Answer: B. Human approval reduced the risk of unsafe automated maintenance actions.