Para valorar un robot humanoide en una empresa, define la tarea, el resultado aceptable y la ayuda humana permitida antes de pedir ofertas. T2 Professional P1, BUMI Standard y Go2 PRO responden a proyectos distintos. Compara el piloto con la alternativa que ya resuelve ese trabajo y calcula el coste por resultado aceptado, incluyendo preparación, supervisión y correcciones.
Empieza por describir el trabajo actual: quién lo hace, cuánto tarda, qué errores aparecen y qué cambios tolera el entorno. Esa descripción permite comparar un humanoide con automatización fija, un cuadrúpedo o una mejora del proceso antes de comprometer presupuesto.
Casos que pueden justificar estudio
| Caso | Por qué estudiar | Condición para avanzar |
|---|---|---|
| Investigación interna | Aprendizaje sobre locomoción, percepción o manipulación | Equipo técnico y edición con acceso de desarrollo |
| Inspección / movilidad | Entornos donde desplazamiento importa | Comparar cuadrúpedo y soluciones convencionales |
| Manipulación repetitiva | Potencial encaje con forma humana | Carga, ciclo, precisión y seguridad probados en entorno real |
| Demostración / formación | Valor educativo o de comunicación | No confundir demostración con productividad autónoma |
Qué pedir a T2 P1, BUMI Standard y Go2 PRO
Booster T2 Professional P1: configurar el proyecto de investigación
El T2 Professional P1 se ofrece con precio bajo consulta y sujeto a disponibilidad. Es importante pedir P1 por su nombre completo: la configuración tiene 31 grados de libertad y equipo de cálculo Jetson Thor T5000, pero no incorpora las pinzas de P2 ni las manos articuladas de P3. Un presupuesto que solo diga «T2 Pro» deja una diferencia importante sin resolver.
Para un proyecto de manipulación, identifica primero el objeto, el tipo de agarre y el movimiento. Si la demostración utiliza otra terminación del brazo, su resultado no describe el P1 ofertado. Separa también el equipo de cálculo de la aplicación: disponer de capacidad de procesamiento no significa recibir un proceso de trabajo programado. Pide qué software, interfaces y ejemplos se entregan y quién desarrollará lo que falta.
Un equipo de investigación puede valorar esta plataforma por su control y capacidad de ampliación; una empresa que necesita automatización lista para producir debe exigir una solución integrada y una aceptación ligada a su tarea. El precio de hardware por sí solo no permite comparar esos dos proyectos.
BUMI Standard: delimitar la demostración o formación
BUMI Standard tiene una referencia de 5.382,05 € a 21 de septiembre de 2026, sujeta a disponibilidad y a confirmación del precio vigente. Puede entrar en una selección para formación o demostraciones si la edición permite la actividad prevista. Define qué aprenderá el participante o qué secuencia se mostrará, cuánto dura y cuánta preparación necesita.
En una presentación comercial, comprueba también quién prepara el espacio, quién controla el robot y qué alternativa se utilizará si la demostración se interrumpe. No confundas una rutina de movimiento con un recepcionista autónomo ni con una herramienta de manipulación industrial. Para programación, exige que el acceso contratado permita el ejercicio, no solo que exista un SDK para la familia BUMI.
Go2 PRO: movilidad con un alcance distinto
La referencia de Go2 PRO es de 3.402,50 € a 21 de septiembre de 2026, sujeta a disponibilidad y actualización. Es un cuadrúpedo. Su interés está en la movilidad y la demostración de locomoción, pero PRO no ofrece el mismo acceso de desarrollo secundario que EDU. Una inspección que necesite sensores propios, registro de resultados o conexión con sistemas de empresa requiere revisar otra configuración e integración.
La guía de versiones Go2 ayuda a separar esas necesidades. Si la tarea consiste en mover material entre dos puntos fijos, compara además una solución de transporte diseñada para ese trabajo: tener patas o forma humana solo aporta valor cuando resuelve una limitación concreta del entorno.
Los enlaces comerciales pueden generar una comisión, sin coste extra para ti. La disponibilidad, el plazo y el coste de entrega en España deben quedar en la oferta; las cifras de referencia no son presupuestos de un proyecto completo.
Una ficha de alcance para pedir el mismo piloto a varios proveedores
La comparación falla si cada proveedor imagina una tarea distinta. Redacta una ficha de una página con el objeto o zona de trabajo, número de ciclos por jornada, horario, espacio disponible y resultado aceptable. Adjunta fotografías o planos del entorno solo si tienes derecho a compartirlos y elimina datos personales innecesarios. El proveedor debe poder responder si la configuración ofertada ejecuta la tarea, qué parte se programa y qué intervención humana queda.
| Campo | Respuesta que debe figurar en la propuesta | Por qué cambia la decisión |
|---|---|---|
| Equipo exacto | Fabricante, edición, manos o pinzas, sensores, batería, software y licencias | Una demostración de otra variante no valida la compra |
| Entorno | Suelo, pendientes, circulación de personas, conexiones y área excluida | Determina la evaluación de riesgos y la instalación |
| Datos e integración | Interfaces, registros, acceso remoto, conservación y responsable de la información | Puede añadir trabajo técnico y obligaciones de privacidad |
| Servicio | Entrega, puesta en marcha, formación, respuesta a incidencias, repuestos y transporte de reparación | Define las paradas y el coste operativo real |
Pide que se separen los servicios incluidos de los opcionales y que se identifique quién realizará la integración. Una oferta que incluye el robot pero deja sin asignar la programación o la seguridad del puesto no se puede comparar con otra llave en mano. La lista para solicitar presupuesto ayuda a convertir estas preguntas en un documento de compra.
Costes que el precio base no cubre
- Transporte, seguro, importación e impuestos.
- Manos, sensores, cálculo, baterías, repuestos y accesorios.
- Integración, software, formación, evaluación de riesgos y espacio.
- Supervisión humana, mantenimiento, paradas y soporte.
- Aceptación, seguro, privacidad, ciberseguridad y retirada.
Prueba de aceptación
Define antes del piloto la tarea, superficie, objetos, carga, duración, intervención humana permitida, paradas, incidentes y criterio de éxito. Registra también fallos e intentos repetidos. Una coreografía del vendedor no sustituye ese protocolo.
Ejemplo de piloto: medir el trabajo y la ayuda necesaria
Como ejemplo de evaluación, un equipo podría acordar 20 recorridos repetidos en una zona de demostración controlada, aprobada previamente por el responsable de seguridad. Cada recorrido termina en un punto definido y ejecuta una acción ya admitida por la configuración. Se mantienen el mismo suelo, distancia y condiciones para poder comparar los intentos. Este ejemplo organiza la medición; no certifica que un modelo sea adecuado para ese entorno.
| Resultado ilustrativo | Cálculo | Qué significa |
|---|---|---|
| 19 recorridos completados de 20 | 19 ÷ 20 = 95 % | Finalización, incluyendo los casos con ayuda |
| 16 completados sin ayuda de 20 | 16 ÷ 20 = 80 % | Trabajo completado sin intervención del operador |
| 3 completados tras intervención | 19 − 16 = 3 | La recuperación consume tiempo y personal |
| 1 recorrido no completado | 20 − 19 = 1 | Debe conservarse en el registro, no descartarse |
Acuerda el umbral de aceptación antes de empezar y registra duración, causa de cada intervención y tiempo de recuperación. Veinte intentos pueden descubrir problemas, pero no demuestran fiabilidad de producción a largo plazo. Un cambio de suelo, objetos o software exige comprobar de nuevo las condiciones que hayan cambiado. Los fallos de seguridad detienen el ensayo aunque el porcentaje de finalización sea alto.
Qué parte del trabajo queda fuera del piloto
Un ensayo puede dar buenos resultados y cubrir solo una pequeña parte del trabajo. Antes de convertir su porcentaje de éxito en una previsión de ahorro, cuenta cuántas tareas reales cumplen las condiciones del piloto. Separa las que encajan por objeto, recorrido y horario de las que necesitan otra herramienta, otra configuración o intervención humana desde el principio. La unidad de comparación debe ser una tarea entregada con la calidad acordada, no cada movimiento que hace el equipo.
Como ejemplo hipotético, imagina un puesto que recibe 100 tareas diarias. Solo 30 pertenecen al tipo admitido en la prueba y el sistema entrega 24 de ellas con el resultado exigido. La aceptación dentro de ese grupo es del 80 %, pero la cobertura del trabajo diario es del 24 %. Quedan 70 tareas fuera del alcance y seis que no han superado la prueba: 76 necesitan otra solución. Son dos medidas distintas. Ninguna de estas cifras describe el rendimiento de un modelo concreto.
Comprueba además cuándo llegan esas tareas. Resolver 24 a lo largo de una jornada no demuestra que puedan resolverse 24 dentro de la hora en que se necesitan. Anota la demanda por franja, el tiempo hasta entregar cada resultado y lo que ocurre cuando se acumulan solicitudes. Una tarea acabada después del plazo útil puede no servir al puesto aunque técnicamente haya terminado. Incluye la preparación, los cambios entre trabajos y las interrupciones observadas en esa comparación.
Conserva el proceso que atenderá el trabajo restante y calcula sus recursos. Si sigue siendo necesaria una persona para las excepciones, no presupuestes su jornada completa como ahorro. Revisa si el tiempo liberado se puede dedicar realmente a otra actividad y qué formación requiere. Esta separación permite pedir una segunda prueba sobre un problema concreto, por ejemplo las tareas excluidas más frecuentes, sin presentar una demostración limitada como automatización de todo el puesto.
Criterio económico
Compara el coste anual total con la alternativa más realista, no solo con mano de obra. Incluye integración, supervisión y riesgo de inmovilización. Si los campos críticos son desconocidos, el resultado debe seguir abierto.
Un presupuesto de proyecto y dos volúmenes de uso
Imagina un presupuesto de primer año con 12.000 € de equipo entregado, 4.000 € de integración, 1.500 € de formación y 2.500 € de soporte: 20.000 € en total. Son cantidades hipotéticas, no precios de T2, BUMI o Go2. Bajo esas mismas partidas, 2.000 tareas aceptadas darían 10 € por tarea; si solo se completan 500, serían 40 €.
Ese cálculo aún debe incorporar el tiempo de supervisión, la energía, consumibles y cualquier coste no incluido en la oferta. Mantén el mismo periodo y las mismas partidas al comparar alternativas. Un piloto puede aportar aprendizaje valioso sin resultar rentable como producción; conviene asignarle un objetivo y un presupuesto distintos para no presentar ese aprendizaje como ahorro operativo.
Medir el proceso actual con el mismo criterio
Antes de medir el robot, escribe qué se considera una tarea aceptada en el proceso actual. En un traslado, llegar al destino puede no bastar si el material llega dañado o queda mal colocado. En una inspección, recorrer la zona no equivale a entregar un registro que la persona responsable pueda utilizar. La comparación necesita el mismo resultado, la misma calidad y un periodo definido.
Separa el tiempo transcurrido del tiempo de trabajo humano. Una operación de diez minutos puede requerir atención durante los diez o solo durante una parte. Cuenta preparación, seguimiento, revisión y correcciones sin sumar dos veces una misma intervención. Registra también quién atendió el equipo y si podía realizar otra actividad durante la espera. Esa posibilidad debe comprobarse en la organización real del puesto; no nace automáticamente de que el robot se mueva solo.
Describe las condiciones de cada medición: tipo de tarea, configuración, carga de trabajo y cambios del entorno. Si el proceso habitual se observa en un turno difícil y el robot solo en una demostración preparada, los resultados no son equivalentes. Una primera prueba puede justificar otra evaluación, pero no una previsión anual de ahorro sin conocer el trabajo que queda fuera de ella.
Ejemplo: terminar una tarea no siempre significa aceptarla
Imagina un piloto con 100 intentos previstos. El robot termina 96, pero solo 88 cumplen el criterio de calidad a la primera. Los otros ocho requieren una corrección; seis quedan aceptados después y dos siguen sin cumplirlo. Los cuatro intentos que no terminaron también permanecen en el registro. El resultado final son 94 tareas aceptadas y seis sin aceptar. Estas cifras son un ejemplo de cálculo, no resultados de T2, BUMI o Go2.
| Resultado del ejemplo | Cantidad | Cómo se utiliza |
|---|---|---|
| Aceptadas a la primera | 88 | Resultados útiles sin corrección posterior |
| Terminadas con corrección pendiente | 8 | Seis se aceptan después; dos siguen sin aceptar |
| No terminadas | 4 | No se eliminan del registro ni se cuentan como aceptadas |
| Aceptadas al final | 88 + 6 = 94 | Denominador para el coste del resultado útil en este ejemplo |
Informar de 96 tareas terminadas y de 94 aceptadas responde a dos preguntas distintas. Conserva ambas cifras y el trabajo de corrección. Si varios intentos corresponden a la misma tarea repetida, registra esa relación para no contar dos veces un único resultado entregado. El criterio debe quedar fijado antes de la prueba y aplicarse igual a la alternativa con la que se compara.
Poner precio a la supervisión y las correcciones
Continuando el ejemplo hipotético, supón 20 minutos de preparación, dos minutos de atención humana por cada uno de los 100 intentos, cinco minutos para cada una de las ocho correcciones y cinco para atender cada uno de los cuatro intentos no terminados. Las partidas representan tiempos separados: la atención por intento no incluye esas correcciones ni recuperaciones. En total son 20 + 200 + 40 + 20 = 280 minutos de trabajo humano.
Con un coste supuesto de 25 € por hora, esos 280 minutos cuestan 116,67 €. Añade, para este periodo, 120 € de coste asignado de equipo e integración y 20 € de consumibles. El total es 256,67 €, equivalente a unos 2,73 € por cada una de las 94 tareas aceptadas. La asignación de 120 € también es imaginaria: en una decisión real tendría que explicarse el periodo de uso y qué gastos cubre.
Como alternativa igualmente hipotética, producir esas mismas 94 tareas aceptadas mediante el proceso actual requiere seis minutos de trabajo humano por tarea. Son 564 minutos, o 9,4 horas: 235 € con el mismo coste horario. Si consume otros 20 €, suma 255 €, aproximadamente 2,71 € por resultado. Aunque el piloto reduce el tiempo humano de este ejemplo, su coste calculado resulta algo mayor. Un menor tiempo de atención no demuestra por sí solo una compra rentable.
La comparación solo sirve bajo esas partidas y ese resultado. Añade a ambos lados energía, mantenimiento, espacio y cualquier coste que corresponda y no esté incluido; una partida desconocida no vale cero. Si la alternativa necesita también un equipo, incorpora su coste comparable. No mezcles la inversión completa de un año con el trabajo de un día ni sumes de nuevo un gasto ya incluido en la asignación del equipo.
Un presupuesto para aprender y otro para operar
Un piloto de investigación puede estar bien justificado aunque todavía no produzca ahorro. Su presupuesto debe comprar una respuesta útil para una decisión. Escribe qué incertidumbre se quiere resolver, qué evidencia se entregará y qué harás con cada resultado. Por ejemplo, comprobar si una configuración puede generar un registro utilizable bajo las condiciones del puesto permite decidir entre continuar con esa integración, cambiar de edición o descartar ese uso.
Limita también lo que incluye la investigación. Define las sesiones, el acceso al espacio, la preparación del personal y el trabajo de análisis dentro del alcance acordado. Establece un punto de revisión antes de autorizar más horas. Si el primer ensayo no produce el registro esperado, una nueva fase necesita una hipótesis sobre la causa y una forma de comprobarla. Repetir la misma demostración sin cambiar una condición identificada no responde a una pregunta nueva.
El presupuesto de operación responde a otra cuestión: qué cuesta mantener el resultado aceptado durante el uso previsto. Necesita demanda suficiente, responsables disponibles y un servicio definido. Un desarrollo realizado para aprender no se convierte automáticamente en una aplicación mantenida. Pide qué documentación, configuraciones y accesos quedarán disponibles para el uso ordinario, quién conservará las versiones y qué cambios exigirán volver a probar el sistema. Separa los gastos ya asumidos de los nuevos necesarios para operar.
Al cerrar cada fase, registra la decisión, sus motivos y el coste de la siguiente. Un resultado negativo puede evitar una compra mayor y tener valor como aprendizaje; no debe contabilizarse como ahorro de producción. Si el proyecto continúa solo para exhibición o formación, redefine ese objetivo y su presupuesto. Así puedes evaluar su utilidad con una medida apropiada, sin exigirle un retorno operativo que nunca se acordó ni prolongar indefinidamente un piloto sin decisión.
Qué cambiar antes de repetir el piloto
Al cerrar una prueba, separa una tarea que no encaja con el equipo de un problema que puede corregirse dentro del alcance contratado. Por ejemplo, una manipulación que necesita pinzas no se resuelve dando por incluidas las de T2 P2 en una oferta P1. En cambio, una incidencia de registro puede requerir aclarar el formato de entrega y quién hará la integración. La segunda prueba necesita una propuesta concreta, no solo la promesa de que «funcionará mejor».
Para cada punto pendiente, anota la observación, la causa aún por comprobar, el cambio propuesto, su coste y la evidencia que permitiría aceptarlo. Cambia una condición identificada y conserva la referencia del ensayo anterior. Si se modifican a la vez software, tarea y entorno, explica que se evalúa una combinación nueva y que la mejora no se puede atribuir a un único cambio.
Continúa cuando el siguiente ensayo responda a una incertidumbre importante y tenga alcance y presupuesto definidos. Redefine el proyecto si requiere otra edición, otro servicio o una tarea distinta. Si la necesidad ya se resuelve mejor con el proceso actual o con una automatización más sencilla, cerrar el piloto con esa conclusión también es una decisión útil. Comprar más unidades no corrige una dependencia que todavía no se ha resuelto en la primera.
Dos robots no duplican la capacidad del puesto
Antes de pedir una segunda unidad, identifica los recursos compartidos que han permitido funcionar a la primera: operador, espacio autorizado, estación de carga, equipo informático, preparación de objetos y atención del proveedor. Si ambos equipos dependen de una misma persona o zona, su capacidad conjunta puede estar limitada por ese recurso. La oferta de más hardware no demuestra que exista capacidad adicional para supervisarlo o preparar el trabajo.
Diseña una prueba de coincidencia con el responsable del centro. Observa qué ocurre cuando dos actividades necesitan atención a la vez, cómo se priorizan las solicitudes y qué queda en espera. Registra las intervenciones y los resultados aceptados en el mismo periodo. No presupongas que una persona puede atender simultáneamente ambos sistemas ni reduzcas la supervisión acordada para conseguir una cifra mejor. La organización del trabajo debe comprobarse dentro de las condiciones admitidas.
Si la segunda unidad va a otra sede, enumera las diferencias antes del traslado: suelo, objetos, circulación, conexiones, cuentas y personal disponible. Conserva la configuración aprobada como referencia y distingue lo que se reutiliza de lo que hay que adaptar. Pide un alcance separado para esa adaptación y una aceptación en el nuevo puesto. Una aplicación que funcionó en el primer espacio puede necesitar trabajo adicional; copiar su configuración no sustituye esa comprobación.
Compara finalmente el aumento observado de resultados útiles con el coste adicional de personal, integración y soporte. Mantén una alternativa para las tareas que no pueda atender el conjunto. La ampliación tiene sentido cuando resuelve una demanda identificada y deja responsables y recursos suficientes para sostenerla. Si el límite sigue estando en un puesto compartido, resolver ese cuello de botella puede ser más relevante que comprar otra unidad.
Cuatro puertas entre el piloto y la compra de más unidades
Función: el equipo completa el número de tareas acordado con la calidad exigida y con el límite previsto de asistencia. Registra intentos fallidos y cambios de configuración, no solo el mejor turno. Si el proceso cambia entre la prueba y el despliegue, repite la aceptación en la nueva condición.
Seguridad: el responsable del centro acepta el espacio, el modo de parada, la circulación de personas y el procedimiento ante avería. La evaluación debe abarcar la combinación real de robot, herramienta, software y puesto. Una demostración en la sede del fabricante no sustituye la evaluación en la instalación de la empresa.
Economía: calcula el coste por tarea aceptada con el tiempo de preparación, supervisión, mantenimiento, integración y paradas. Compara con automatización fija, equipos existentes o un cambio de proceso que entregue el mismo resultado. Si el beneficio solo aparece suponiendo autonomía no demostrada, la decisión sigue abierta.
Continuidad: identifica al propietario interno del sistema, manuales, accesos, repuestos y condiciones de respuesta del proveedor. Pide un plan de retirada o transferencia de datos si se acaba el piloto. Si el servicio depende de una sola persona sin sustitución, ese riesgo debe entrar en el presupuesto.
Las cuatro puertas pueden cerrarse en fechas distintas. Una prueba técnicamente exitosa puede requerir todavía trabajo de seguridad o un acuerdo de soporte; eso no es un fracaso del piloto, sino un resultado concreto para negociar antes de ampliar la compra. Deja un acta con la evidencia aceptada, los puntos pendientes y la persona que autoriza cada siguiente paso.
Después del piloto: responsable y soporte
Antes de ampliar el uso, entrega a la persona responsable la configuración aprobada, los accesos, los procedimientos y el registro de incidencias. Define quién autoriza actualizaciones y cómo se comprueba que la aplicación sigue funcionando después de un cambio. Si el conocimiento queda únicamente en el integrador que hizo la demostración, la empresa puede depender de él incluso para tareas ordinarias.
La oferta debe indicar quién recibe una incidencia, cuánto tarda en responder y qué solución existe mientras se repara el equipo. Respuesta y reparación no son el mismo plazo. Para BUMI, la referencia de garantía del fabricante es de 12 meses desde la recepción, con piezas de desgaste o protección sujetas a condiciones distintas; para T2, concreta la cobertura del paquete cotizado. El transporte de reparación, los repuestos y una unidad de sustitución deben figurar expresamente si forman parte del servicio.
Avanza cuando la tarea se repita con el nivel de ayuda previsto, el coste sea comparable y exista alguien responsable del uso diario. Si el piloto deja una dependencia crítica sin resolver, documenta qué falta y cuánto costaría resolverlo antes de comprar más unidades.
Preguntas frecuentes
¿Qué robot ofrece mejor retorno?
No puede responderse sin tarea, configuración, integración, disponibilidad y datos de operación comparables.
¿Un humanoide sustituye a una persona?
No lo asumimos. El análisis debe descomponer tareas, supervisión, seguridad y responsabilidades.
¿Conviene comprar o pilotar?
En hardware emergente, un piloto con aceptación definida puede reducir incertidumbre, siempre que contrato y datos queden claros.
¿Qué alternativa comparar?
Robótica convencional, cuadrúpedos, automatización fija, software o rediseño del proceso pueden encajar mejor.
Fuentes y actualización
Las especificaciones distinguen la configuración de hardware y el acceso de cada edición. La aplicación concreta, el servicio y la entrega se definen en el presupuesto y se comprueban durante el piloto.