The robots in Biel read from SAP before they move

SAP's post about its first Embodied AI Jam, published September 4, 2026, describes three days at the Swiss Smart Factory in Biel, Switzerland, in the last week of August. Customers, robot manufacturers, system integrators, and SAP's embodied AI experts put a robodog, drones, and humanoids to work. Inspection drones were connected to SAP Asset Performance Management, humanoids supported processes in SAP Digital Manufacturing, and Joule and SAP Business AI Platform supplied what the post calls business context. Each use case has a robot acting on a record that a person in a plant office typed in, and the post never asks whether that record was right.

Our sibling pieces cover the four questions that separate a robot demo from a process and what a warehouse robot needs from connected context. This one stays on the data itself. Physical automation raises the cost of a wrong record from a confused user to a scrapped part, and the record was wrong before anyone bought a drone.

Business context is a record with an owner

Business context for a drone means an equipment record, its functional location, the measuring points on it, and the open notifications against it. For a humanoid on a production line it means the production order, the operation, the component list, and the work center. Joule produces none of that. It reads it. A maintenance planner or a production engineer entered it, some of it years ago, and it has an owner only if someone decided it should.

The part of the jam we'd want to see filmed is the moment the drone was told which tanks were due, and which system answered. Lukasz Ostrowski, who heads the embodied AI initiative at SAP, says three days of focused time replaced weeks of scattered back-and-forth. Three days cannot compress the quality of the master data a customer brought with them.

The drone lands its finding on whatever the hierarchy says

Take asset inspection, which the post ties to SAP Asset Performance Management. A drone flies a tank farm, spots corrosion, and the result has to attach to one equipment record under one functional location so that a named planner sees a notification. Suppose two pumps were swapped between bays during a shutdown and the technician updated the paper tag but not the hierarchy.

The drone does not know that. It reports corrosion on the asset the hierarchy places in bay 3, the notification lands on the wrong pump, and the planner sends someone to inspect a healthy machine. The identifier side of this problem is covered in our field guide to durable business keys. The physical side is new, because the drone is the first consumer of that hierarchy that cannot look at the nameplate and shrug.

The humanoid picks what the component list says

Humanoids supporting processes in SAP Digital Manufacturing is the use case where stale context costs the most. A robot staging material for an operation takes its list from the production order, and that list came from the bill of material as it stood at release. If an engineering change swapped one bracket for another and the change is still sitting in an approval queue, a line operator notices the wrong box and asks. The post mentions humanoids picking and packing, and the humanoid picks the old bracket.

A wrong answer from a chat assistant costs a minute. A wrong pick costs a rework loop or a stopped line, and the investigation will find that the order was correct according to the system. Nobody on the line did anything wrong, and the defect traces back to a change request that a person forgot to release. That is a master data failure, and the robot only made it expensive.

Freshness matters more than coverage

The post does not say how the robots were connected to SAP. Our guess is that most of it went through SAP BTP. The question we'd add is how old the read is when the robot acts. A production order changed by hand at 10:05 is a different order from the one the robot fetched at 10:02, and a three-minute gap that nobody notices in a chat window moves a pallet on a floor.

So the design question on the SAP side is a freshness contract. Which fields the robot reads at the moment of action rather than at the start of the task, and what it does when that read fails. Our guide on small integration contracts argues for narrow, explicit reads with a named owner, and a robot is the strongest case for it we have seen.

Put a master data owner on the attendee list

The post says SAP Switzerland becomes a member of the Swiss Smart Factory as of January 2027 and plans more jams and shorter discovery formats. The attendee list it describes has customers, robot makers, integrators, and SAP's embodied AI experts, and not the person who owns the equipment master or the bill of material at the customer. That person rarely gets invited to anything with a robot in it. We made the case that clean core is a budget decision. Clean data is a separate budget, and the one the robot depends on.

Before your team books a slot in Biel, pick the business object the robot would read and ask its owner for last quarter's change log. Count how many of those changes were corrections rather than new records. That number tells you whether the robot inherits a record or a backlog, and it belongs on the first page of the brief, above the photo of the humanoid.