AI, Robotics
and Product Engineering

Most enterprise incident response playbooks assume the system is deterministic enough to replay like normal software.

AI breaks that assumption. The same user request can produce different model output after a model update, context change, retrieval change, prompt edit, tool schema change, memory mutation, policy update, or temperature setting. If the AI system can call tools, write records, retrieve confidential data, or trigger workflows, incident response has to capture the full decision chain, not only the final bad output.

An enterprise AI agent is only as safe as the tools it can reach.

A model that writes a summary is one risk class. A model that can query customer records, open tickets, update CRM fields, trigger payments, modify IAM groups, deploy code, or send emails is a different system. At that point, the AI application is no longer “just chat.” It is an execution surface connected to enterprise authority.

A Jetson is not a small cloud server bolted to a robot.

It is an edge computer inside a cyber-physical system. That difference matters. The device shares a power budget with cameras, radios, sensors, actuators, storage, and cooling. It sees real latency, real thermal limits, real network loss, and real consequences when software makes a bad timing assumption.

Human-in-the-loop is not a checkbox that makes an AI workflow safe.

It is an architecture pattern.

If the human reviewer receives a vague AI recommendation, no source evidence, no risk tier, no policy context, no rollback path, and no audit trail, the review step is just theater. The system has inserted a person into the workflow without giving that person the authority, information, or interface needed to make a responsible decision.

Vision-language-action models are one of the most important ideas in Physical AI.

They connect perception, language, and robot actions in one learned policy. That is a real step forward. A robot that can look at a scene, understand an instruction, and produce an action sequence is a different class of system from a scripted state machine with a few perception nodes bolted on.

But a VLA model is not a safety architecture.

Retrieval-augmented generation does not make an enterprise AI assistant trustworthy by itself.

It only gives the model more context.

If that context comes from stale policies, duplicated SharePoint folders, unowned PDFs, over-permissive vector indexes, missing retention rules, or documents that lost their access-control metadata during chunking, RAG can make the answer look more authoritative while making the control problem worse.

An enterprise AI agent is not dangerous because it can write fluent text.

It becomes dangerous when fluent text is connected to identity, internal data, tools, workflows, approvals, tickets, code repositories, CRM records, ERP actions, email, files, or infrastructure APIs.

That is why AI agent security should start with a threat model, not with a better system prompt. A system prompt can describe intended behavior. A threat model defines what can go wrong when users, retrieved content, model output, tool results, plugins, permissions, and business systems interact under real enterprise pressure.

AI governance fails when it is treated as a policy document that lives outside the system.

In a real enterprise, AI governance has to become architecture. It needs identities, permission boundaries, ownership records, audit trails, source authority, approval paths, incident hooks, and runtime controls that are close enough to the AI system to matter.

If an AI assistant can read documents, call tools, summarize customer data, trigger workflows, or propose decisions, then “who is allowed to do what, with which data, under whose responsibility?” is not a compliance question only. It is a production architecture question.

A robot timing budget is not a spreadsheet you fill in after the system is built.

It is the contract that decides whether a sensor measurement is still fresh enough to influence motion, whether a ROS 2 callback is late enough to invalidate a command, whether a controller output should be admitted to hardware, and whether the microcontroller should keep executing or fall back to a safer local behavior.

Without that contract, teams usually debug timing by vibes: “the robot feels laggy”, “the planner sometimes hesitates”, “the controller is probably fine”, “the camera is only 30 Hz”, or “the Jetson should be fast enough.”

Sensor fusion drift is rarely caused by “the filter being bad.”

In real robots, drift usually comes from a broken contract somewhere around time, frames, calibration, covariance, motion assumptions, or sensor trust. The EKF, UKF, factor graph, or localization stack is often just the first place where the lie becomes visible.

That is why debugging drift by randomly tuning noise values is a trap. It can make a short demo look better while hiding the physical fault that will return on a longer run, a different floor, a faster turn, or a warmer IMU.