Physical Intelligence anuncia una beta de API para robots

Physical Intelligence anunció el 13 de octubre de 2026 la beta de su API para subir datos, ajustar modelos en infraestructura gestionada y ejecutar inferencia alojada. Para evaluar su alcance, separa el servicio de entrenamiento, la respuesta del modelo y la operación física que decide si una acción se ejecuta.

Entrenar e inferir responden preguntas distintas

El ajuste fino utiliza ejemplos de una tarea para adaptar un modelo. La inferencia aplica lo aprendido a una observación nueva. El primero modifica el comportamiento del modelo; la segunda obtiene una respuesta sin volver a entrenarlo por defecto. Son momentos distintos y exigen registros diferentes.

En robótica aparece otra capa: el controlador recibe o interpreta una propuesta, comprueba límites y decide si puede llegar al equipo físico. Una API de modelo no es por sí sola un controlador completo. Aclara si el proyecto cubre entrenamiento, inferencia, sensores, herramientas o control de movimiento.

Esta separación ayuda a localizar fallos. Una mala acción puede venir del modelo, del dato de entrada o de la integración. El registro de una prueba debe indicar qué ocurrió y cuándo intervino el sistema o una persona.

Las demostraciones abren un ciclo, no lo cierran

El proveedor describe recoger demostraciones, entrenar, probar en el robot y usar fallos para decidir qué datos reunir después.

Una demostración registra cómo realizar una tarea en una situación observada. Puede mostrar el inicio, la acción y el resultado esperado, pero una colección de éxitos no explica qué hacer ante una obstrucción o un objeto desplazado. El equipo decide qué variaciones representan su operación y cuáles exigen una respuesta segura distinta.

Define la tarea con un resultado que otra persona pueda revisar. Registra el contexto necesario para repetir el intento: preparación de la estación, objeto, herramienta, condición inicial, resultado e intervención humana. El esquema depende del sistema evaluado; aquí no se prescribe un formato de API.

Reserva ejemplos para evaluación y no los uses luego para ajustar el modelo. Esa separación no demuestra que funcionará en todos los turnos, pero sí permite preguntar si la adaptación resolvió casos que no se emplearon durante el entrenamiento.

Qué muestran los casos publicados

Según la empresa, Actor opera comercialmente un cargador de ruedas autónomo para cargar material en un camión sin operador a bordo. También muestra a Axol, de Almond, desbarbando espaciadores de su montaje con un modelo obtenido tras cuatro días de iteración con la API.

Los casos de una demostración ayudan a formular preguntas. Para estimar repetibilidad en otra operación hacen falta condiciones, intentos, fallos e intervenciones observados en esa instalación.

Una muestra no sustituye una medición con criterios acordados. La decisión requiere una prueba propia, con la tarea y las condiciones de la instalación.

Medir la tarea sin atribuir todo al modelo

Antes de ejecutar, define qué cuenta como resultado aceptable, qué eventos obligan a intervenir y qué condiciones quedan fuera del piloto. Usa el mismo criterio para el sistema nuevo y el proceso actual. Conserva cada intento para saber cuánto apoyo humano requirió y dónde surgió el trabajo adicional.

El porcentaje de tareas completadas no explica por sí solo la calidad. Añade registros de reintentos, piezas rechazadas, tiempo de revisión y acciones correctivas. Anota el motivo de cada intervención: una corrección rutinaria no equivale a una parada de seguridad.

Observación	Pregunta que ayuda a responder
Resultado aceptado según criterio	¿Llegó a un estado utilizable? No anticipa cómo rendirá en otras condiciones.
Intervención humana y motivo	¿Cuánto apoyo necesitó y en qué momento?
Reintentos y piezas rechazadas	¿Qué coste operativo tuvo una ejecución incompleta?
Paradas y condición del equipo	¿Qué obliga a detener la prueba y quién puede hacerlo?

Compara intentos equivalentes y conserva el registro, no solo el mejor video. Cuando sea seguro, usa el proceso vigente como referencia. La prueba debe permitir que el nuevo método no supere esa referencia.

Escenario ficticio: una pieza llega mal posicionada

El anuncio también menciona una pieza que quedó mal posicionada.

Escenario hipotético inspirado en ese reto: imagina una estación de ensamblaje que debe tomar esa pieza. El equipo define qué desviaciones admite el piloto, qué estados requieren detenerse y quién confirma el criterio de aceptación.

Luego organiza intentos comparables con el proceso vigente y con el sistema evaluado. Registra la posición inicial, el resultado, los reintentos, las correcciones humanas y cualquier parada. Reserva casos para la evaluación y no los reutilices para ajustar el modelo.

Etapa del piloto	Qué documentar
Preparación	Objetivo, aceptación, límites y responsable de detener.
Datos	Condición inicial, demostración, resultado e intervención.
Ejecución	Proceso probado, resultado por intento, reintentos y paradas.
Revisión	Diferencias frente al proceso actual y decisión siguiente.

Si los fallos se concentran en una condición, el equipo puede reunir ejemplos de ella o revisar la estación. Si aumentan las intervenciones, puede pausar y revisar la integración. El piloto debe producir esas respuestas; aquí no se presupone un resultado.

La conectividad entra en el diseño de la prueba

La empresa reporta problemas de conectividad en algunos despliegues con inferencia alojada.

La comunicación entre la estación y un servicio alojado forma parte de la operación que se prueba. Un corte puede confundirse con lentitud del modelo si el registro no separa eventos. Anota cuándo no llega respuesta, cuándo llega tarde y qué estado presenta el equipo mientras espera.

Antes de añadir una decisión remota a una tarea física, acuerda qué ocurre si se pierde la conexión, quién lo ve y cuándo hace falta revisión humana. Comprueba el comportamiento real con quienes implementan la integración. No presupongas que el equipo puede continuar sin conexión ni que una respuesta recuperada sea segura para cada tarea.

Clasifica los incidentes como comunicación, salida no válida, límite del controlador, herramienta o condición de la tarea. Así el equipo puede decidir qué revisar sin atribuir todo al modelo.

Preguntas antes de participar en una beta

Antes de reservar tiempo, confirma directamente con el proveedor si tu caso puede participar y qué requisitos aplican.

• Tarea: ¿hay una operación acotada y repetible?
• Datos: ¿quién reúne y revisa ejemplos e información sensible?
• Integración: ¿quién convierte una salida en acción controlada?
• Evaluación: ¿qué referencia, criterio de éxito y regla de parada se usarán?
• Operación: ¿quién acompaña el piloto y revisa incidentes?

Estima la preparación de datos, las pruebas físicas, la integración y el mantenimiento; son partes del trabajo que el piloto debe dejar visibles.

Convertir el anuncio en una decisión pequeña

La pregunta práctica es si la adaptación ayuda a estudiar una tarea difícil de configurar. Un piloto acotado fija objetivo, referencia, registros, condiciones de parada y responsable. Al terminar, el equipo debe explicar qué cambió, qué quedó pendiente y si vale la pena repetir.

La evidencia para otra operación debe construirse en su propia tarea e instalación. Para una capa distinta de la robótica, la nota sobre Agility Robotics y la batería de Digit 5 aporta contexto sobre infraestructura que acompaña a un robot.

Aquí no se ha invocado la API ni se presentan resultados independientes. Si quieres aprender y conversar sobre cómo evaluar herramientas de IA en tu trabajo, visita Comunidad IA.

Fuente primaria: Physical Intelligence.