A robot runs its perception model correctly on the bench. Once the wheels accelerate, the camera disappears, inference latency jumps, or the Jetson reboots. The failure lands in the software team’s queue because that is where the symptoms are visible. Yet a new model, a ROS 2 QoS change, or a longer watchdog timeout cannot repair a collapsing supply rail.

To diagnose this class of failure, measure voltage at the consuming device while recording motor current, compute load and reset events. Separate sustained power demand from short load steps, and test braking as well as acceleration. A supply’s wattage rating alone does not establish whether the robot’s compute and sensor rails remain usable through those events.

The central engineering question is: can the electrical system preserve the operating conditions assumed by the AI and control software, including when several loads change together? The useful deliverable is a power-domain map with measured limits and a reproducible fault test, not just a larger battery.

An AI service can process a thousand cases while the people responsible for its exceptions are still reviewing the first dozen. Model latency looks excellent. The workflow is getting slower.

Consider a support operation where an AI workflow proposes account adjustments. Most cases follow an approved, narrow automation path. Ambiguous evidence and higher-impact actions require human decisions. A change in incoming documents raises the exception rate from 5% to 8%. Nothing crashes, yet the same traffic now demands substantially more reviewer time. Scaling inference makes the problem worse.

Human review capacity must constrain how much work an AI workflow starts. Estimate the review minutes each case class creates, account for sampling and rework, and admit work against the capacity of qualified reviewers. When that capacity runs out, defer or reduce intake through a defined service path. Approval requirements remain in force.

A robot copilot is allowed to read diagnostics and propose a docking task. The architecture diagram puts a command validator between the copilot and motion. Then someone gives both processes the same ROS 2 security credentials, or composes their nodes into one context. The diagram still shows a boundary. The deployed system may let the copilot publish directly to the controller.

ROS 2 security enclaves make that boundary enforceable at the middleware layer only when the credentials, process layout and permissions agree. Assign narrowly scoped identities to separate trust boundaries, generate permissions for the resolved communication graph, protect each identity’s private key, and test prohibited paths with the production deployment configuration.

The useful design question is specific: if the AI-facing process is compromised, which ROS interfaces can it actually use? A list of node names cannot answer it. An enclave-to-interface map, checked against the running system, can.

A document disappears from the company knowledge base. Its vector records are deleted. The assistant still answers questions using a summary saved yesterday.

There is no contradiction: the deletion reached one store, while the application served another. A RAG system can turn one source into chunks, embeddings, cached responses, conversation summaries, evaluation fixtures and diagnostic traces. Each copy has its own lifetime.

Reliable RAG deletion needs two coordinated operations: stop serving the affected information, then remove or isolate its recorded derivatives. That requires stable source identity, dependency tracking, a serving barrier that works while storage converges, and evidence that an old ingestion job or backup cannot bring the content back.

A camera frame arrives ten milliseconds after exposure, yet the perception node reports that it is eighty milliseconds old. The team reduces queue depth, moves inference onto the GPU, and tunes the executor. None of those changes fixes a seventy-millisecond difference between the camera computer’s clock and the consumer’s clock.

The opposite failure is harder to notice: an old observation appears fresh because the publisher’s clock is ahead. An age check can pass while the robot acts on a world that no longer exists.

In ROS 2, a trustworthy timestamp needs an acquisition meaning, an identified clock domain, a conversion into the consumer’s time base, and a bound on conversion error. Use those properties for sensor alignment and freshness. Use a local monotonic clock for elapsed hardware timeouts. After a device restart or time discontinuity, invalidate the affected mapping and dependent state before admitting observations again.

Consider a procurement assistant that extracts invoice lines and prepares an ERP update. Its primary model times out. The gateway switches to another model, receives valid JSON, and reports success. Yet the replacement may have processed the invoice in a different geography, omitted a credit line, or generated a second update for a transaction already submitted.

A successful HTTP response says very little about whether that recovery was acceptable.

Enterprise model failover needs two decisions: which deployment is eligible to receive this request, and which workflow step can safely resume? Approve fallback routes against the data and task requirements before an outage. During recovery, restart only from an explicit checkpoint, keep action authorization outside the model, and stop or queue work when no eligible route remains.

Most enterprise AI agent failures do not start with the model choosing a tool.

They start with a weak contract around what that tool means. A function schema says send_email(to, subject, body). It does not say who is allowed to send, whether the recipient is external, what approval state is required, whether the operation is idempotent, how retries behave, what evidence must be logged, what happens on partial failure, or how the action is reversed.

That missing contract is where a helpful assistant becomes an uncontrolled production actor.

A robot operator copilot should make the human faster at understanding the machine. It should not quietly become the machine’s commander.

That distinction sounds simple until the copilot can read diagnostics, inspect maps, summarize camera events, propose recovery actions, call ROS 2 tools, open maintenance tickets, and ask the robot to dock, pause, resume, retry, or change mode. At that point the design question is no longer “can the model help the operator?” It is:

Which layer is allowed to advise, which layer is allowed to approve, and which layer is allowed to command the robot?

Enterprise AI permissions do not fail only at launch. They drift after launch.

The support agent gets a temporary CRM write scope for a pilot. The HR assistant inherits a broader document collection during migration. A service account remains active after a workflow is retired. A connector adds a new destructive action under an existing integration. Nobody sees the problem because the original security review was treated as a project milestone, not as a recurring control.

An access review for enterprise AI agents is the recurring process that proves each agent still needs each data source, tool action, delegated scope, memory store, model route, and approval bypass it can use. The review should not ask, “does this app still exist?” It should ask, “is this exact authority still justified by current business use, current evidence, current risk, and a named owner?”

An AI-enabled robot should not ask “what can I do next?” until the system has answered a quieter question:

Can the robot trust the state it is about to act on?

That question belongs between perception and authority. It is not enough for the camera node to publish, the LiDAR to spin, the estimator to output a pose, and the planner to return a path. A robot can have all of those things and still be acting on stale localization, overconfident covariance, a half-dead obstacle layer, a drifting transform, or a perception model that is uncertain in exactly the part of the scene that matters.