Dentro del colapso: seis lecciones aprendidas de la desaparición de una startup de robótica

Los robots humanoides de código abierto K-Bot. | Crédito: K-Scale Labs

Nota del editor: Rui Xu es el antiguo director de operaciones de K-Scale Labs, una startup con sede en San Francisco que intentó construir robots humanoides de bajo coste. La empresa cerró a finales de 2025 y recientemente ha convertido su propiedad intelectual en código abierto. Xu publicó este artículo por primera vez en LinkedIn. Se ha reimpreso con su permiso.

Durante un año, ocupé el cargo de director de operaciones en una startup de robótica respaldada por Y Combinator con el ambicioso objetivo de crear robots humanoides asequibles. A mis cuarenta años, aporté quince años de experiencia en hardware adquirida en el lanzamiento de productos en Intel, Xiaomi, Lenovo, Amazon y ByteDance para dirigir la cadena de suministro y las operaciones de productos.

Al final, la empresa no tuvo éxito. No conseguimos asegurar nuestra financiación de la Serie A y, a finales de 2025, todo había terminado.

Ya he compartido anteriormente los aspectos más destacados: los hackatones, la energía propia de un garaje, el momento en que nuestro robot dio sus primeros pasos. Ahora quiero detallar las lecciones reales que aprendimos. Algunas son dificultades comunes a todo el sector; otras fueron errores que cometimos activamente.

1. El chovinismo de los modelos grandes hará daño a alguien

Existe la creencia generalizada de que los modelos de IA se han vuelto tan avanzados que el hardware puede permitirse ser simplista. ¿Sensores? El modelo interpretará todo a partir de la visión. ¿Límites de seguridad? La red de políticas aprenderá a evitarlos.

A esto lo denomino «chovinismo de los modelos grandes». Influyó sutilmente en innumerables decisiones de nuestra startup. Para ser claros, no fue un descuido de una sola persona, sino que la mayoría de nosotros lo suscribimos en cierta medida. Las capacidades de la IA eran realmente impresionantes, lo que hacía que fuera fácil que ese entusiasmo eclipsara los principios fundamentales del hardware.

Un debate que todavía me persigue se refería a la incorporación de topes finales en las articulaciones del robot. Los topes finales, interruptores de límite mecánicos, son barreras físicas básicas que evitan que una articulación se autodestruya. Es la redundancia de seguridad más fundamental.

El contraargumento era que la política de la IA debía aprender los límites de la articulación de forma natural y que los topes finales añadían un coste y un peso innecesarios.

Cualquiera con experiencia en hardware sabe que este razonamiento es erróneo. Los topes existen porque el software puede fallar y fallará. Los modelos fallan. Las políticas se encuentran con casos extremos imprevistos. Cuando un modelo de lenguaje alucina, se obtiene una respuesta sin sentido. Cuando un actuador, debido a una única inferencia defectuosa, supera su límite mecánico a pleno rendimiento, se obtiene una máquina averiada o, lo que es peor, una lesión.

El modelo puede ser correcto el 99,99 % de las veces. El tope final es para el 0,01 %. En el mundo físico, ese 0,01 % es la única estadística que realmente importa. Incluso Tesla, con todos sus objetivos de autonomía, sigue instalando frenos en sus coches.

2. Las analogías simplificadas en exceso sirven para recaudar fondos, no para construir

Todas las presentaciones de robótica tienen una: «Estamos haciendo por los robots lo que Tesla hizo por los vehículos eléctricos» o «Este es el momento iPhone para la IA incorporada». Nuestra analogía favorita era la del hoverboard. La narrativa era que los robots humanoides seguirían la misma curva de costes que los patinetes autoequilibrados: desde una novedad cara, pasando por la producción en masa en Shenzhen, hasta convertirse en un hardware barato y omnipresente.

El motor de un hoverboard solo tiene que girar. Sin embargo, los actuadores de un robot humanoide deben ser extraordinariamente precisos, potentes, dinámicos, duraderos y consistentes de una unidad a otra. Un solo actuador ligeramente fuera de especificación puede hacer que el robot camine incorrectamente o se caiga. Las analogías con los hoverboards, los teléfonos inteligentes o cualquier otro dispositivo de consumo no proporcionan ninguna orientación útil para construir un humanoide.

Sin embargo, «será como un hoverboard» es una historia que los inversores de capital riesgo entienden. Promete una reducción inevitable de los costes, la destreza de la fabricación china y una escala de miles de millones de unidades. Cada hora dedicada a debatir estas analogías era una hora que no se dedicaba a resolver los retos técnicos reales.

Las analogías son algoritmos de compresión. Simplifican la complejidad descartando información. Eso está bien para una presentación. En las decisiones de ingeniería, la información descartada es a menudo la que conduce al fracaso.

3. La cadena de suministro de hardware no es una tarea sencilla

Algunos fundadores orientados al software ven la gestión de la cadena de suministro como una mera tarea: contratar a alguien que hable chino, enviarlo a una fábrica y darlo por hecho. Este concepto erróneo es un error común para las startups de hardware.

Cuando me incorporé, no existía ninguna infraestructura de cadena de suministro: ni relaciones con fabricantes, ni condiciones de pago, ni procesos de control de calidad, ni canal logístico. Crearla implicaba coordinar el montaje, los componentes, los actuadores y múltiples fabricantes chinos contratados para la fabricación. Cada uno requería negociaciones separadas sobre precios, estándares de calidad, cantidades mínimas de pedido y calendarios de producción, todo ello en diferentes divisas, zonas horarias y culturas empresariales con supuestos fundamentalmente diferentes sobre la negociación de acuerdos.

No se trata simplemente de «hablar con los proveedores». La fabricación no es un servicio que se compra, sino una capacidad básica que hay que desarrollar. La relación con el fabricante por contrato determina si los actuadores llegan dentro de los márgenes de tolerancia o si tienen una desviación de 2 mm, y si el coste unitario es de 800 o 2400 dólares. Si las operaciones de hardware de una empresa se pueden resumir en una sola frase, es que no tiene una estrategia de hardware, sino una esperanza.

4. El hardware «básico» no existe en la robótica

Una idea particularmente peligrosa que circula es que el hardware de los robots se convertirá en un «producto básico», ensamblado a partir de piezas disponibles en el mercado por fabricantes chinos, al igual que los teléfonos inteligentes, y que el valor real residirá únicamente en la capa de software de IA.

Esta no es la realidad actual, ni mucho menos. No existe una lista de materiales estándar para un robot humanoide. No hay actuadores disponibles en el mercado que funcionen simplemente para la locomoción bípeda. Todos los equipos que construyen robots con patas hoy en día diseñan hardware personalizado.

Cuando una empresa se cree la narrativa de que «el hardware es un producto básico», se producen daños reales. Los equipos que construyen el producto físico suelen recibir menos voz y reconocimiento del que merecen sus contribuciones. El poder organizativo se desplaza hacia la función que se considera estratégicamente «defendible», independientemente de quién esté realizando el trabajo más difícil.

He observado un patrón recurrente que denomino «la experiencia de Schrödinger». Cuando surge un problema de hardware, las mismas personas dejan de ser de repente «expertos en hardware» y afirman no tener ni idea. Sin embargo, cuando el equipo de ingeniería afirma que un rediseño llevará cuatro meses, insisten en que debe hacerse en cuatro semanas. No se pueden tener las dos cosas, y los ingenieros que realizan el trabajo real lo ven claramente.

Nuestros ingenieros construyeron un robot que caminaba. Esa fue la hazaña de ingeniería más difícil que logró la empresa.

5. Las malas decisiones en I+D matan más rápido que la mala suerte en una carrera

El campo de la robótica es una carrera. Hay capital disponible, el talento está llegando a raudales y el mercado está atento. Pero una carrera premia la velocidad, y la velocidad no es solo esfuerzo, es el resultado de tomar decisiones correctas rápidamente.

El mayor error que presencié fue quedarse estancado en la locomoción. Se consumieron meses mientras el robot seguía sin poder caminar correctamente. Mientras tanto, se cerró la ventana de recaudación de fondos y los competidores lanzaron impresionantes demostraciones. No se trató únicamente de un fallo del liderazgo; todo el equipo, incluido yo mismo, subestimó la complejidad y el plazo del problema. Nuestro GitHub estaba lleno de repositorios, lo que desde fuera parecía un avance. Desde dentro, era movimiento sin convergencia. Los repositorios no se envían. Las demostraciones se envían. Los productos se envían.

El problema más profundo era la calidad de las decisiones. Las decisiones impulsivas pueden ser tan fatales como las lentas. Comprometerse plenamente con la dirección equivocada no ahorra tiempo, sino que duplica el coste, ya que luego hay que deshacer el trabajo.

La velocidad de I+D no se mide por los repositorios, los compromisos o las horas registradas. Se mide por la rapidez con la que se converge en una solución que realmente funciona.

6. Cuanto más te apresuras, más te quedas atrás

Los plazos de nuestros proyectos se convirtieron en una broma interna. El robot siempre iba a caminar «la semana que viene». Todas las semanas.

Cuando esa cultura se afianza, la gente empieza a tomar atajos para cumplir con plazos imposibles. Los ingenieros utilizan herramientas de codificación de IA sin una revisión adecuada. Los sensores se integran sin una calibración completa. Entonces, la demostración falla, una vez más, y el plazo se reinicia a «la semana que viene».

Esto encarna el proverbio chino «欲速则不达» (yù sù zé bù dá): literalmente, «desea la velocidad, no llegas». Cuando los plazos poco realistas se convierten en la norma, el equipo no avanza más rápido. Simplemente se saltan los pasos esenciales que hacen que las cosas funcionen. Cada paso que se salta acaba provocando un fallo que cuesta más tiempo del que se ha ahorrado con el atajo.

El daño va más allá de la ingeniería. Cuando haces promesas a tu fabricante por contrato basadas en plazos fantásticos, rompes esa relación tan importante. Un fabricante necesita previsiones realistas para planificar su producción. Una mentalidad caótica de «moverte rápido y romper cosas» puede funcionar en el software, pero falla por completo cuando una fábrica asigna líneas de producción basándose en compromisos que no puedes cumplir.

Una nota personal

Podría haber sido un mejor director de operaciones. Debería haber sido más asertivo antes sobre los problemas organizativos, cuando aún se podían solucionar. Debería haber insistido más en plazos realistas en lugar de dejarlos pasar. Esa responsabilidad es mía. Pero he aprendido dónde están esos límites y llevaré ese conocimiento adelante.

Estuve allí durante todo el proceso, desde el primer hackatón hasta el último correo electrónico a un proveedor.

A cualquier joven ingeniero de una startup: confía en tu instinto en lo que respecta a la física. Si los cálculos indican que una junta fallará, documéntalo. Presenta tu caso formalmente. No dejes que la presión por actuar con rapidez te intimide y te haga ignorar lo que sabes que es cierto. Tu reputación profesional se basa en lo que realmente entregas, no en lo que prometes.

Si estas seis lecciones ayudan a alguien, ya sea al fundador de una empresa de hardware, a un profesional de la cadena de suministro o a un padre de cuarenta años que está pensando en emprender una carrera en una startup, entonces habrá valido la pena escribir esto.

Sigo creyendo en la IA incorporada. Simplemente creo que merece un hardware diseñado con la misma seriedad que el software que lo controla.

Acerca del autor

Rui Xu es un veterano de la industria del hardware con sede en Silicon Valley. Anteriormente fue director de operaciones de K-Scale Labs, una startup de robótica respaldada por Y Combinator y centrada en robots humanoides asequibles. Antes de eso, pasó 18 años comercializando productos de hardware de consumo en Intel, Xiaomi, Lenovo, Amazon y ByteDance, incluidos Xiaomi Mi Box, Lenovo Smart Display y Amazon Fire TV. Escribe sobre robótica, hardware y la realidad de la fabricación de productos físicos en ruixu.us.