Physical AI Factory Deployment: An RFP and 90-Day PoC Playbook

When planning a physical AI factory deployment, the first thing to buy is not “autonomy.” Buy one bounded job: the workpiece and starting conditions, permitted actions, stop conditions, quality decision and recovery path. Then require evidence that the system performs that job safely and repeatably. A polished AI-robot demonstration is not production acceptance. If data rights, model updates, exception handling and accountable owners remain undefined, deployment is not complete.

This guide is written for the buyer side of Thai and ASEAN factories. It explains how to structure a physical AI RFP, validation plan, acceptance gates, data and change governance, and a 90-day proof of concept. The focus is not another deep dive into robot simulation, vision, mobile manipulation or AI welding. It is the owner’s framework above those technologies: how to convert a promising capability into a task that can be contracted, tested, accepted and operated.

Do not treat physical AI deployment as the purchase of an AI model

Physical AI interprets input from cameras, force sensors and other sources, selects a policy, moves a robot or machine, and leaves a result on a real workpiece or environment. Unlike many information-only AI applications, an error does not remain on a screen. It may stop equipment, create a defect, damage tooling, expose a person to a hazard or send a problem downstream.

The buyer should therefore separate the system into at least five layers:

1. INPUT — workpieces, instructions, camera images, force, position and machine state
2. PERCEPTION — estimates of objects, poses, defects and process state
3. POLICY — rules or learned policies that select an action
4. MOTION — robot path, speed, gripping, welding conditions or other physical action
5. SAFETY — independent safeguards and operating procedures that stop hazardous behavior

The critical point is that SAFETY does not become unnecessary because the AI is capable. Model-performance testing and industrial-robot safety are different validation tracks. ISO 10218-1:2025 addresses safety requirements for industrial robots and significant hazards under intended use and reasonably foreseeable misuse. Each project still needs qualified review of applicable law, ISO 10218-2 and other relevant standards, Thai requirements and equipment-manufacturer instructions.

Contract a bounded task, not a promise of autonomy

Phrases such as “flexible across variants,” “adapts autonomously” and “requires no expert” are useful as a technology vision. They are not testable RFP requirements. Buyer and supplier can read them and imagine different definitions of success.

Instead of asking for “autonomous bin picking,” define a task envelope:

• permitted part numbers, materials, surface states, dimensions and deformation;
• bin type, presentation, overlap, maximum fill level and foreign-object handling;
• lighting, reflection, dust, temperature, vibration and camera-contamination ranges;
• normal-cycle start and completion conditions;
• detection of missed grasp, unrecognized state, double pick and dropped part;
• retry limit and transitions to slow retreat, quarantine or operator call;
• quality data and lot or serial linkage passed downstream;
• state from which the cell may resume after human intervention; and
• parameters that operators may change versus changes that require reapproval.

The PoC must prove success inside this envelope and safe refusal, stopping or escalation outside it. In production, a clearly declared operating and rejection envelope is more valuable than an untestable claim of universality.

Separate production KPIs from evidence KPIs

Cycle time, yield and downtime are necessary but insufficient. If no one can explain why results changed after an update, quality assurance and continuous improvement will stall. Use two KPI families.

Targets must come from the factory’s process capability, quality plan and risk assessment. Any durations, counts or rates in this article are explicitly proposed acceptance criteria for discussion, not industry norms or guaranteed values.

Twelve items to lock down first in a physical AI RFP

Place buyer-owned requirements before product names. For each item below, specify not only the question but also the required answer and evidence format.

1. Business outcome and process scope

State in one sentence what should decrease or increase and whose work will change. Replace “deploy AI” with wording such as: “At Process A, handle product family B from presentation and pose recognition through gripping and fixture loading; quarantine exceptions and notify the line leader.”

2. Task envelope

Tabulate included variants, machines, speed, environment, upstream and downstream states, and exclusions. This is the main defense against a later argument that a condition “was not expected.”

3. Authority boundary

Specify whether the AI only recommends or may execute, and which parameters it may alter. For welding, separate current, voltage, speed and path. For handling, separate route, speed and gripping force. Authority should be assigned per variable that can change a physical outcome.

4. Safety boundary

Diagram responsibility for the safety PLC, protective devices, speed monitoring, emergency stop, restart, manual mode and maintenance work. Do not treat an AI process stop as equivalent to a safety stop. Safeguards require their own verification.

5. Inputs, outputs and time synchronization

Define signals among cameras, sensors, PLCs, robots, MES, QMS, edge devices and cloud services: unit, refresh cycle, missing-data behavior and clock source. If logs cannot be joined later, root-cause analysis will be weak.

6. Data rights and use limitations

Separate ownership and license rights for images, drawings, recipes, paths, annotations, synthetic data, model weights and evaluation results. Require answers on cross-customer training, cross-border transfer, retention, proof of deletion and subprocessors.

7. Separation of training and evaluation data

Separate training, tuning, validation and final acceptance sets. Prevent the same sample from being used to learn and to declare a pass. For every dataset, retain source, acquisition condition, label owner, correction history and applicable version.

8. Edge and cloud failure behavior

For network delay, cloud loss, GPU fault, full storage, clock drift and expired certificate, define the transition to continued operation, degraded mode or stop. A state diagram is better than “high availability.”

9. Acceptance test

Include nominal cases and boundary cases: unfamiliar input, blocked sensor, lighting change, network interruption, restart and incorrect instruction. The buyer-approved test register, not the supplier’s demonstration script, should be the authoritative record.

10. Change control

List the model, prompt, policy, robot program, camera location, fixture, lighting, firmware, library and cloud-service changes that may affect behavior. Define retest scope and approver for each class.

11. Support and capability transfer

Ask for Thai on-site response, remote-access controls, night and holiday coverage, spares, log collection, procedures in required languages, training and the conditions under which the factory can operate independently.

12. Exit and migration

Define the data, configuration, model, evaluation asset, log and document formats delivered at termination. Confirm that the cell can stop safely and enter an agreed manual or degraded mode if the cloud service ends. Lock-in is not only a price issue; it may become a recovery risk.

Link SIM, SYNTHETIC and REAL evidence in one register

ABB and NVIDIA describe a digital-first loop among digital twins, task-specific synthetic data, AI validation and real-world feedback. NVIDIA’s Physical AI Data Factory Blueprint similarly describes curation, augmentation and evaluation of real and synthetic data. The buyer lesson is not simply “collect more data.” Every piece of evidence must show which real condition it represents and which configuration it qualified.

At minimum, the evidence register should contain:

• scenario ID and business meaning;
• SIM, SYNTHETIC or REAL classification;
• source data, generation settings, transformation and label version;
• workpiece, fixture, camera, lighting, robot and control-software version;
• model, policy, prompt and threshold version;
• expected result, actual result, decision and deviation reason;
• event record when a safeguard operates; and
• executor, reviewer and approver.

Even highly realistic simulation does not automatically eliminate real-cell acceptance. Reflection, wear, cable behavior, oil, dust, lens contamination, operator intervention and upstream variation belong in plant testing. Virtual results must still be versioned as contractual acceptance evidence. For another buyer-side example of converting machine-to-machine responsibility into acceptance specifications, see our guide to conveyor-top AMR integration and a 90-day PoC. Physical AI likewise needs explicit ownership of signals, workpieces, exceptions and recovery at every equipment boundary.

Seven acceptance gates for robot-AI validation

Do not wait for one final demonstration. Close seven gates in sequence. Work may continue experimentally, but production approval should not be granted while a required gate is open.

G1 TASK — Is the job boundary closed?

Confirm included and excluded conditions, start and finish, normal and abnormal states, and transfer to a person. Use the same task definition in the commercial proposal and acceptance register.

G2 DATA — Is the evidence reproducible?

Trace source, rights, labels, version, split, retention, deletion and access. Version the settings used to generate synthetic data. Do not improve a pass rate by silently removing unfamiliar cases from evaluation.

G3 EDGE — Does it run on time at the machine?

Measure worst-case latency and jitter as well as averages, plus startup time, temperature, memory and network dependency. Verify that the robot does not execute a stale instruction when the cloud response is delayed.

G4 STOP — Does it stop before the situation becomes hazardous?

Test entry, sensor conflict, position offset, failed grasp, lost communication and AI-process failure. Confirm transition to the defined safe state on the real cell. Keep AI confidence thresholds conceptually separate from safety functions.

G5 RECOVERY — Can the cell return correctly after stopping?

Exercise restart, workpiece removal, homing, work-in-process disposition, MES reconciliation, retry and human-intervention recording. A cell that stops safely but requires a specialist for every recovery is not production-ready.

G6 DRIFT — Can the operation detect change?

Monitor lighting, part lot, surface, fixture wear, camera and upstream-process variation. Decide whether change is detected through input distribution, task performance or exception frequency. Define quarantine and review before any automatic retraining.

G7 OWNER — Is there an accountable decision maker?

Build a RACI for quality, production, maintenance, EHS, IT/OT, procurement and the supplier. Name who authorizes stop release, version update, exception disposition, retraining and rollback. “The AI team” is not an accountable owner.

Acceptance-record template

Change governance must cover more than model updates

Physical-AI behavior is not determined by the model alone. Camera angle, lighting, lens, fixture, robot calibration, part surface, preprocessing, threshold, prompt, PLC logic, communications library, GPU driver and cloud API can all alter a result. “The model did not change” is not a sufficient no-change assessment.

Maintain a single configuration register and classify changes in four levels:

1. Record only — wording or presentation with no effect on motion or quality
2. Limited retest — monitoring, log conversion or nonsafety communication with bounded impact
3. Regression test — camera, light, fixture, model, threshold or robot path affecting perception or action
4. New risk assessment — safeguards, cell layout, speed, payload, operator access or intended-use boundary

Each ticket should include reason, old and new versions, impact hypothesis, required tests, rollback, approver, effective time and affected line. A regional rollout still needs site-specific acceptance when site conditions differ, even if the model name is identical.

Automated learning is not automated approval

A pipeline may collect data and produce a candidate model automatically. Promotion to production must remain a governed decision: collect data, train in an isolated environment, test against a fixed evaluation set, assess impact, approve, deploy narrowly, monitor, then expand. An unrecorded model change in production makes cause analysis and rollback difficult.

NIST’s concept note for an AI Risk Management Framework profile in critical infrastructure says that AI across IT, OT and ICS in high-stakes environments depends on trustworthy systems and a repeatable full-lifecycle approach. It does not certify any specific product. It does, however, support a practical RFP principle: operators should communicate actionable trustworthiness requirements across internal teams, developers and the supply chain.

A 90-day PoC that creates a production decision, not a demo

The deliverable of a 90-day PoC is not a video. It is enough evidence to choose one of four paths: proceed, narrow scope, perform additional validation or stop. The schedule below is a proposal and should be adjusted for plant access, shutdown windows, part availability, safety review and procurement.

Days 1–15 — Freeze the task and risk frame

• observe the work and review standard work, downtime and defect history;
• approve the task envelope and exclusions;
• establish baseline KPIs and measurement methods;
• confirm data rights, retention, cross-border transfer and remote support;
• approve the RACI including the safety owner; and
• create test-scenario and configuration registers.

The exit is not “the supplier can bring equipment.” It is “the buyer can sign what a pass means.”

Days 16–35 — Build the evidence baseline

• collect representative and boundary conditions from real workpieces;
• map SIM, SYNTHETIC and REAL evidence;
• freeze data splits and the final-acceptance holdout;
• join logs, clock, video and workpiece identity;
• run initial nominal and abnormal tests; and
• review cybersecurity, identity, patching and backup.

Prioritize a reproducible evaluation system before maximizing performance.

Days 36–65 — Test the boundary and failures

• vary lighting, pose, surface, lot and speed at agreed boundaries;
• inject sensor obstruction, communication loss, delay, restart and storage fault;
• test missed grasp, double pick, wrong workpiece and defect quarantine;
• exercise safety stop, protective stop, manual intervention and recovery;
• test drift monitoring and alerts on paper and on the cell; and
• submit one real change request, retest and roll back.

FANUC’s announcement of its AI Welding Agent provides a concrete chain from drawing interpretation to welding conditions, robot motion, execution or operator fine-tuning. Terms such as “zero setup” and “zero teaching” are FANUC product claims. In a buyer’s acceptance plan, drawing revision, material, joint, welding source, parameter approval, test coupon, appearance or strength result and operator intervention should remain distinct evidence objects. See our implementation analysis of the AI Welding Agent and robot deployment.

Days 66–90 — Observe production-like operation and hand over

• observe agreed variants, shifts and operators continuously;
• classify every exception, stop, rework and human intervention;
• conduct joint acceptance by quality, production, maintenance and safety;
• verify training, work instructions, spares and escalation contacts;
• restore from backup and roll back to an approved prior version; and
• submit open issues, residual risks and production conditions for management decision.

How to write numerical criteria correctly

A PoC needs numbers, but it should not start from an unsupported “99%.” Use wording such as the following and obtain quality, safety and production approval. These are example proposed acceptance criteria, not general benchmarks:

• “Proposed criterion: the final acceptance set includes normal cases for each in-scope variant and at least three executions of every agreed boundary scenario.”
• “Proposed criterion: zero severe safety event and zero undetected defect escape during the agreed acceptance observation window.”
• “Proposed criterion: after a communications loss, the cell does not resume automatically; it reconciles state and requires an authorized operator confirmation.”
• “Proposed criterion: for a named configuration, the same evaluation set can be rerun and the cell can return to the previous approved version within the agreed recovery time.”

The factory must set counts, observation window and tolerance using task hazard, detection capability, takt, lot size and customer requirements.

Additional conditions for Thai and ASEAN factories

Treat multilingual operation as more than UI translation

Thai, English and Japanese may coexist with Myanmar or Khmer on the same floor. Align the terms used in alarms, recovery steps, training, exception classification and approval screens. If translated procedures drift by version, the same alarm may trigger different actions.

Separate remote support from local authority

Overseas remote support can be valuable. Define connection approval, time limits, command logging, screen recording, file export and emergency disconnection. Avoid an arrangement where a supplier changes a production model or parameter remotely without a plant-owned record.

Do not assume permanent connectivity

If a cloud connection is lost, the cell must move to a safe stop or an agreed degraded mode. Separate the dependencies of inference, logging, authentication and licensing. Test plant connectivity, regional outages, certificate renewal and clock synchronization.

Regional rollout means reacceptance, not copying

Do not copy a Thai success case directly to Vietnam, Indonesia or Malaysia. Lighting, suppliers, standard work, shifts, temperature, humidity, connectivity, privacy review and maintenance capacity may differ. Reuse assets, but reapprove the local task envelope and seven gates.

A scorecard for comparing suppliers

Price and demo accuracy do not expose operating cost or stoppage risk. Separate mandatory requirements from scored advantages.

Major-vendor announcements are useful indicators of technical direction. ABB describes a loop connecting RobotStudio, NVIDIA Omniverse, simulation, synthetic data and real-world feedback, and it publishes accuracy, setup, cost and time-to-market figures. Those figures are ABB claims or ABB analysis, not a guarantee for another factory. Caterpillar and FieldAI describe autonomous inspection, digital twins, situational awareness and operational optimization as early applications; the benefits should likewise be read as statements by the parties.

The handover package required for production

After a PoC passes, do not accept only the equipment. Require editable, maintainable delivery of at least:

• approved task envelope and risk assessment;
• cell architecture, network, I/O and state-transition diagrams;
• data dictionary, dataset register, labeling procedure and rights register;
• model card, evaluation results, known limitations and exclusions;
• robot, PLC, camera, edge and cloud configuration register;
• acceptance register, logs, video, deviations and corrective actions;
• safeguard verification and applicable compliance records;
• startup, stop, recovery, cleaning, calibration, backup and rollback procedures;
• alert classification, escalation contacts and support SLA;
• training records, competency criteria, change form and retest matrix;
• agreed source, configuration, key, license and bill-of-material handover; and
• residual risks, interim controls, owners and due dates.

If these records are missing, a technically successful PoC has still not completed operational transfer.

Frequently asked questions

What is physical AI?

It is a system that perceives the physical environment through sensors, uses AI to select an action, and produces a physical result through a robot or machine. In a factory, perception performance must be governed together with action authority, safeguards, quality outcome, recovery and change history.

Which process should be selected first for physical AI deployment?

Choose a process with a clear boundary, detectable and containable failures, and measurable current KPIs. It may still include human judgment if the system’s recommendation and the point of human approval can be bounded.

Is accuracy enough when validating AI robots in manufacturing?

No. Test latency, rejection of unfamiliar input, stopping, recovery, data lineage, configuration version, drift, cybersecurity and operator competence. Final quality and safety belong to the entire process, not the model alone.

How should ROI be written into a physical AI RFP?

Include more than license cost: machine modification, sensor and edge compute, data preparation, safeguards, integration, training, support, relearning, downtime, audit work and exit migration. This article does not invent costs. Measure current loss and required work for the candidate process before building the business case.

Can production deployment be completed in 90 days?

Ninety days can be a useful PoC window for a production decision, but it cannot guarantee production launch for every cell. Safety design, compliance review, equipment lead time, customer approval and part availability may require more time. The objective is to make the next decision with evidence at day 90.

What if the supplier recommends automatic updates?

Learning and candidate creation may be automated, but production promotion must follow change control. Require evaluation, approval, limited deployment, monitoring and rollback, with a record of who changed what and when.

Conclusion: buy boundaries, evidence and change control

A physical AI factory deployment should not purchase an abstract promise of autonomy. It should contract a bounded task, an evidence chain linking SIM, SYNTHETIC and REAL, seven acceptance gates, stopping and recovery, data rights, controlled change and accountable owners. A 90-day PoC is not a period for producing an impressive demo; it is a period for giving the factory the evidence and operating system needed to decide whether production should proceed.

If you are defining a candidate process, physical AI RFP or PoC acceptance sheet for a Thai or ASEAN factory, contact TOMAS TECH. We can begin before product selection, with task scoping and a small validation boundary that respects existing equipment.

Sources

• ABB Robotics and NVIDIA white paper defines transformative impact of physical AI on manufacturing
• ABB Robotics Partners with NVIDIA to Deliver Industrial-Grade Physical AI at Scale
• FANUC Accelerates Physical AI in Arc Welding with the New AI Welding Agent
• Google Cloud: Inside the agentic factory
• Caterpillar and FieldAI Advance AI-Powered Industrial Innovation
• NIST: Concept Note — AI RMF Profile on Trustworthy AI in Critical Infrastructure
• ISO 10218-1:2025 — Robotics — Safety requirements — Part 1: Industrial robots
• NVIDIA Physical AI Data Factory Blueprint

*This article reflects public information available on September 16, 2026. Vendor statements on performance, benefits and availability are their claims, not TOMAS TECH results or guarantees. Every deployment should verify applicable laws, standards, customer requirements and local safety and information-governance obligations.*