Nvidia lleva a Les Karpas al escenario de TechCrunch Disrupt 2026 para explicar por qué la robótica todavía no tuvo su momento ChatGPT. El anuncio de la charla no adelanta el argumento: dice que la industria sigue esperando su salto a la vida cotidiana y que Karpas tiene una respuesta. Lo aclaro de entrada porque cambia cómo hay que leer todo lo que sigue: hoy no existe una tesis publicada, existe la promesa de una tesis.
Por qué importa
La señal no está en lo que Karpas vaya a decir, sino en quién lo dice. Nvidia vende el cómputo sobre el que se entrena buena parte de esta industria. Que alguien de adentro encuadre el problema como pendiente, en público y en el escenario más visible del año, es admitir que el cuello de botella no está en la capa que ellos venden. Si faltaran GPUs, el título del panel sería otro.
Y acá va mi lectura. El "momento ChatGPT" nunca fue un salto de capacidad: fue un salto de empaquetado. El transformer ya existía, los modelos grandes ya existían, y lo que cambió fue que cualquiera pudo usarlos sin entender nada de lo que había abajo. Ese truco funcionó porque el costo de una respuesta equivocada era cero: la leías, te reías y escribías el prompt de nuevo. En robótica esa gratuidad del error no existe. Un brazo que interpreta mal una instrucción no genera una respuesta rara, rompe algo. Por eso no alcanza con envolver mejor la capacidad: el envoltorio no es el problema.
Qué cambia en la práctica
Casi ninguno de nosotros va a escribir firmware para un robot. Pero el mismo salto conceptual aparece cada vez que conectás un modelo a algo que actúa en lugar de responder: un agente que ejecuta un deploy, que emite una nota de crédito, que manda correos a clientes, que modifica un ticket en producción. Ahí dejás de tener un chat y empezás a tener un actuador, con todas las consecuencias.
| Dimensión | Modelo que responde | Modelo que actúa |
|---|---|---|
| Costo del error | Reintentar y seguir | Efecto persistente afuera del sistema |
| Rollback | Trivial: descartás el texto | Requiere compensación explícita |
| Evaluación | Se juzga la salida | Se juzga la consecuencia |
| Datos | Abundantes y ya digitalizados | Hay que generarlos interactuando |
| Iteración | Barata y paralelizable | Limitada por el mundo físico o por el riesgo |
De ahí salen tres decisiones de arquitectura que sostengo hace rato y que este anuncio refuerza. Primero: separá la capa que decide de la capa que ejecuta. El modelo propone una acción estructurada, otro componente la valida contra reglas duras y recién después se ejecuta. Segundo: toda acción irreversible necesita contrato explícito, idempotencia y una compensación escrita antes de habilitarla, no después del primer incidente. Tercero: logueá la intención junto con la acción. Cuando algo salga mal vas a necesitar saber qué creía el modelo que estaba haciendo, no solo qué terminó ejecutando.
Si tu producto todavía está en la etapa de demo que funciona en la notebook, el panel de prototipo a producción de esa misma edición —con gente de Foxglove, MBRYONICS y Bedrock Robotics— apunta exactamente a ese pasaje. Es el tramo donde se mueren la mayoría de estas ideas.
Cuándo NO usarlo
Primero, lo obvio y lo que nadie dice: esto es el anuncio de una charla de conferencia. No trae benchmarks, ni arquitectura, ni fechas, ni una definición de qué contaría como el salto. Tomar esto como evidencia técnica es un error. Es una señal de agenda, y las señales de agenda sirven para ordenar hacia dónde mirás, no para justificar una migración.
Segundo: no rearmes tu stack esperando un salto que nadie demostró. Si tu roadmap depende de que la robótica se vuelva commodity en los próximos doce meses, no tenés un roadmap, tenés una apuesta. Que haya capital de riesgo mirando el rubro confirma interés, no madurez técnica.
Tercero, y es donde veo más gente equivocándose: el patrón "agente que decide y ejecuta solo" es una mala idea cuando el dominio tiene reglas duras y poca ambigüedad. Si las condiciones se pueden enumerar, una máquina de estados con transiciones explícitas le gana a un modelo en costo, en latencia, en testeo y en auditoría. Reservá el modelo para donde realmente hay ambigüedad lingüística o perceptual. Y si tu proveedor no te da trazabilidad de qué se ejecutó y por qué, conviene esperar: sin eso no vas a poder explicar un incidente ante un cliente, y esa conversación es cara.
Qué haría hoy
Agendaría la charla y la leería cuando salga el contenido real, sin sacar conclusiones antes. Mientras tanto, invertiría en la capa aburrida: contratos de acción tipados, idempotencia, compensaciones y logs de intención. Esa capa te sirve igual si el momento ChatGPT de la robótica llega el año que viene o no llega nunca, porque es la misma que necesitás para cualquier agente que toque producción. El salto, si ocurre, va a premiar a quien ya tenga los rieles puestos.