Hay algo que me preocupa más que una IA equivocándose.
Una empresa donde nadie se hace cargo cuando eso pasa.
Cuando conversamos sobre automatizar más, acelerar procesos, sumar agentes, reducir tareas manuales todo tiene sentido y esta bien.
Pero cuando la IA empieza a meterse en decisiones reales, no siempre tenemos claro ¿de quién es la responsabilidad?
Antes, aunque el proceso fuera imperfecto, más o menos sabíamos dónde mirar.
Había una persona, un equipo, un jefe, un área.
Ahora el flujo cambia:
- alguien diseña el prompt
- alguien conecta el sistema
- alguien aprueba el proceso
- alguien usa el resultado
- alguien recibe el impacto
- alguien tiene que explicar el error
Y si eso no está claro, la empresa empieza a crear zonas grises.
No por falta de tecnología.
Por falta de diseño organizacional.
Por eso creo que adoptar IA no es solo elegir herramientas o casos de uso.
También es sentarse a definir quién valida, quién audita, quién responde y quién corrige cuando algo no sale como se esperaba.
Antes de automatizar el próximo proceso, la pregunta debería ser simple: ¿está claro quién se hace cargo si la IA se equivoca?
Automatizar código no eliminó el cuello de botella.
Lo movió de lugar. Hoy puedo generar una función, un test, una migración o una integración mucho más rápido que antes.
Pero después empieza la parte difícil.
Leer.
Entender.
Validar.
Detectar lo que “parece correcto” pero no lo es.
La IA sube el throughput, sí. Pero también aumenta la cantidad de decisiones técnicas que alguien tiene que revisar.
Hay una presión nueva sobre los perfiles senior:
- revisar código que no escribieron
- entender contexto que el modelo no siempre tiene
- detectar riesgos silenciosos
- validar arquitectura, no solo sintaxis
- decidir qué se mergea y qué no
- sostener calidad cuando todo se acelera
El problema ya no es solo producir más código.
Es tener suficiente criterio para absorberlo.
Porque una cosa es que la IA escriba rápido.
Otra muy distinta es que el sistema quede mantenible, seguro y coherente seis meses después.
El nuevo valor senior no está en tipear más rápido, sino en revisar mejor.
Creo que esta etapa va a cambiar bastante cómo medimos productividad en desarrollo.
No alcanza con contar historias cerradas, líneas generadas o velocidad del equipo.
También hay que mirar cuánta carga estamos trasladando a revisión, QA y arquitectura.
¿En sus equipos la IA está reduciendo trabajo o moviendo la presión hacia quienes tienen que validar?
Tokens, latencia y decisiones: el precio real de un agente.
Hay una confusión bastante común con los agentes de IA.
Se habla mucho de qué pueden resolver.
Pero bastante menos de cuánto cuesta que tomen una decisión.
Porque un agente no “ejecuta” una tarea como un script tradicional.
Antes de responder, puede consultar contexto, llamar herramientas, validar datos, volver a intentar, pedir más información, comparar alternativas y recién ahí actuar.
El costo real se compone de:
tokens consumidos en cada ciclo
latencia acumulada por cada paso
dependencias entre modelos, APIs y datos
trazabilidad de por qué decidió algo
límites para cortar loops innecesarios
criterios para escalar a una persona
El problema de usar agentes, es tratarlos como si fueran gratis, instantáneos y siempre confiables.
La eficiencia no está solo en automatizar más pasos, sino en diseñar mejores ciclos de decisión.
Por eso, antes de escalar un agente, hay una pregunta bastante concreta que deberíamos responder:
¿cuánto cuesta llevar una decisión desde el primer intento hasta una respuesta confiable?
No solo medir si la tarea se completó. También hay que mirar:
¿Cuántos tokens consume por ciclo?
¿Cuántas llamadas hace a modelos, APIs o herramientas?
¿Cuánta latencia agrega antes de entregar valor?
¿Cuántos reintentos necesita para llegar a una respuesta aceptable?
¿Cuánto cuesta auditar o corregir cuando falla?
Porque en producción, el costo de un agente no es solo el precio del modelo.
Es la suma de cada decisión, cada validación, cada espera y cada error que el sistema necesita absorber.
Para hacerlo práctico, el primer paso es simple: medir el ciclo completo, no solo la ejecución.
Definir un costo máximo por decisión, registrar tokens, llamadas, reintentos y tiempo total, y poner límites claros antes de que el agente siga intentando.
Porque sin medir el presupuesto por ciclo, la automatización parece eficiente… hasta que escala.
Automatizar una tarea, a veces, es empezar a quemar presupuesto.
Automatizar una tarea parece, muchas veces, una decisión obvia.
Si algo se repite, lo automatizamos.
Si consume tiempo, le ponemos IA.
Si depende de una persona, creamos un flujo.
Pero hay un problema menos visible: algunas automatizaciones no ahorran presupuesto.
Lo queman 🔥
Y casi siempre es por el diseño del ciclo:
Un agente que reintenta demasiado.
Un proceso que llama modelos grandes para decisiones chicas.
Un flujo que no sabe cuándo detenerse.
Una validación humana mal ubicada.
Una búsqueda que trae contexto de más.
Una cadena de prompts que crece sin control.
Hay una disciplina que vamos a tener que tomar más en serio: loop engineering.
No alcanza con automatizar la tarea.
Hay que diseñar el circuito completo:
Cuándo empieza
Qué información necesita
Cuántas veces puede intentar
Qué modelo usa en cada paso
Cuándo escala a una persona
Cómo se mide costo, latencia y error
La automatización mal diseñada crea consumo invisible.
Y en producción, lo invisible tarde o temprano aparece en tres lugares:
Presupuesto
Performance
Confianza
“Automatizar no es sacar humanos del proceso. Es diseñar mejor dónde interviene cada decisión.”
¿Qué están midiendo cuando automatizan: tiempo ahorrado o costo real del ciclo?
La gestión empresarial también se entrena.
Me quedó dando vueltas este concepto, hablando de resiliencia, equipo y momentos difíciles en una charla con Magui Aicega, capitana de Las Leonas y una de las máximas referentes de la Generación Dorada del hockey.
En el deporte de alto rendimiento hay algo que las empresas a veces olvidamos:
"Un equipo no se ordena solo por talento, se ordena por claridad de rol".
Se puede plantear desde un lugar muy simple pero muy potente: cada persona tiene que saber qué parte del juego le toca sostener.
No todo el mundo define.
No todo el mundo empuja.
No todo el mundo contiene.
No todo el mundo ejecuta bajo presión.
Pero todos tienen una responsabilidad concreta.
En una empresa pasa lo mismo.
Cuando hay incertidumbre, crecimiento, crisis o presión por resultados, se vuelve clave que cada persona tenga claridad sobre:
qué decisiones le corresponden
qué espera el equipo de su rol
dónde debe pedir ayuda
qué no puede dejar caer
cómo impacta su tarea en el resultado colectivo
La resiliencia no es aguantar por aguantar.
Es tener un sistema que permite seguir funcionando cuando aparece la dificultad.
Un equipo fuerte no es el que no se rompe nunca.
Es el que sabe cómo reorganizarse sin perder el propósito.
¿Qué tan claro está hoy, en tu empresa, qué tiene que sostener cada persona cuando el partido se complica?
La automatización no elimina trabajo ⚠️
Lo cambia de lugar.
Esa idea me parece clave para entender lo que viene con agentes de IA en empresas.
Es un error pensar en el objetivo de “sacar personas del proceso”.
En la práctica, cada automatización seria necesita alguien que la diseñe, la observe, la corrija y la mejore.
No se trata de una empresa sin humanos.
Se trata de una empresa donde los humanos dejan de ejecutar ciertas tareas y pasan a operar sistemas más complejos.
Antes de pensar en sacar personas me preguntaría:
¿Quién define qué puede hacer un agente?
¿Quién revisa cuando toma una decisión?
¿Quién audita el uso de datos?
¿Quién corrige cuando el resultado parece correcto, pero no lo es?
¿Quién decide cuándo apagarlo?
La IA puede multiplicar capacidad.
Pero también multiplica superficie de error.
Automatizar sin responsabilidad asignada no es eficiencia.
Es deuda operativa disfrazada de innovación.
Por eso creo que la discusión esta relacionada a cuales son los nuevos roles.
Perfiles capaces de unir tecnología, operación, riesgos, procesos y gobierno.
No para frenar la IA.
Para hacer que funcione en serio dentro de una organización real.
Cuando pensamos en cuantos agentes podemos sumar.
Nos preguntamos ¿quién se hace cargo del sistema cuando esos agentes empiecen a trabajar?
Durante años vendimos y compramos tecnología como si el recurso principal fuera el tiempo.
Horas disponibles. Equipos asignados. Capacidad mensual. Dedicación.
Pero medir capacidad no siempre explica impacto.
Porque una empresa no necesita “más horas”.
Necesita que algo cambie en su operación:
- vender con menos fricción
- reducir errores repetidos
- acelerar decisiones
- bajar costos ocultos
- mejorar tiempos de respuesta
- hacer más predecible un proceso crítico
Tiempo contra valor:
> El tiempo es fácil de medir.
> El valor, no tanto.
Pero que algo sea más difícil de medir no significa que sea menos importante.
El problema no es pagar horas.
El problema es confundir actividad con avance del negocio.
Esto también cambia la relación entre cliente y proveedor.
Si el foco está solo en horas, se discute capacidad.
Si el foco está en valor, se discuten prioridades, riesgos, impacto y métricas.
Y esa conversación es más incómoda, pero mucho más útil.
No se trata de eliminar el tiempo como variable.
Se trata de que deje de ser la unidad principal para decidir si una inversión tecnológica tuvo sentido.
La pregunta que deberíamos hacernos antes de comprar o vender servicios es: ¿Estamos comprando esfuerzo o estamos comprando transformación real del negocio?
Aprender a trabajar con agentes puede terminar siendo tan básico como aprender a usar una planilla, escribir un buen mail o entender un tablero de gestión.
Pero todavía lo estamos mirando como una habilidad “tech”.
Me parece que ese encuadre queda chico.
Porque un agente no es solo una herramienta que responde.
Es una pieza que empieza a ejecutar partes de un proceso.
Entonces tenemos que saber preguntarnos:
- qué tarea puede tomar
- con qué datos trabaja
- quién valida su salida
- cuándo debe frenar
- cómo se audita lo que hizo
- qué pasa si se equivoca
- cuánto cuesta cada ciclo de trabajo
No se trata de “saber prompts”.
Se trata de aprender a delegar trabajo en sistemas que operan con cierto grado de autonomía.
La nueva alfabetización profesional no será usar IA.
Será saber trabajar con ella sin perder criterio.
Esto va a impactar en perfiles técnicos, funcionales, comerciales, operativos y de liderazgo.
En muchas empresas la diferencia no va a estar entre quienes usan agentes y quienes no.
Va a estar entre quienes los incorporan como asistentes sueltos... y quienes aprenden a integrarlos en procesos reales, con control, contexto y responsabilidad.
¿Qué habilidades creés que deberían enseñarse ya para trabajar bien con agentes?
El mercado tech está cambiando la definición de "talento diferencial".
Crecer profesionalmente parecía tener dos caminos bastante claros:
- profundizar cada vez más en lo técnico
- o moverse hacia lo funcional / negocio.
Pero la transformación con IA está creando un tercer espacio.
Y me parece que ahí va a estar una parte enorme del valor profesional en los próximos años.
No alcanza con saber programar.
Tampoco alcanza con entender procesos.
Ni con hablar de estrategia en abstracto.
Lo que empieza a importar es la capacidad de integrar:
- tecnología y operación
- datos y decisiones
- automatización y riesgos
- eficiencia y costos reales
- velocidad y responsabilidad
- innovación y gobierno
Las empresas no necesitan solamente más herramientas.
Necesitan personas capaces de entender qué pasa cuando una herramienta entra en un proceso real, toca datos sensibles, cambia una decisión, reduce una tarea, aumenta una dependencia o crea un nuevo riesgo.
Aparece un perfil distinto.
Menos encerrado en una especialidad.
Más capaz de conectar áreas, traducir problemas y diseñar sistemas que funcionen en producción.
El talento que más va a valer no será el que sepa más de una cosa, sino el que conecte mejor varias.
Para quienes estamos en tecnología, la pregunta de carrera deja de ser solo “qué stack aprendo”.
También empieza a ser:
¿Qué problemas soy capaz de entender de punta a punta?
Los layoffs no siempre hablan de eficiencia.
A veces muestran que muchas empresas crecieron con un diseño organizacional pensado para otro momento del mercado.
Cuando había capital de sobra, crecimiento acelerado y presión por expandir, ciertos roles tenían sentido.
- roles para coordinar más reuniones.
- roles para sostener procesos internos muy pesados.
- roles para conectar capas que quizás nunca debieron estar tan separadas.
- roles para administrar complejidad que la propia organización había creado.
Pero cuando cambia el contexto, aparece la pregunta:
¿ese rol generaba impacto estructural o solo hacía funcionar una arquitectura organizacional demasiado costosa?
No lo digo desde una mirada fría sobre las personas.
Al contrario.
El problema muchas veces no está en el talento.
Está en cómo se diseñó el sistema alrededor de ese talento.
Hoy las empresas necesitan perfiles capaces de unir cosas que antes vivían separadas:
- tecnología y operación
- automatización y criterio humano
- datos y decisiones
- eficiencia y responsabilidad
- producto, procesos y gobierno
La reducción de roles no debería leerse solo como ajuste.
También puede ser una señal de rediseño.
El mercado no está eliminando solamente puestos.
Está cuestionando la forma en que organizamos el trabajo.
La pregunta para los líderes no es solo qué roles sobran.
Es qué capacidades nuevas todavía no existen en el organigrama.
La automatización está entrando en las empresas más rápido que la capacidad de decidir qué automatizar.
Ese desfasaje me parece clave, porque hoy muchas organizaciones están midiendo la IA por cantidad de tareas eliminadas, horas ahorradas o procesos acelerados.
Todo eso importa.
Pero no alcanza.
La pregunta más relevante no es cuántas cosas puede hacer la IA por nosotros.
Es qué decisiones estamos mejorando con esa capacidad nueva.
- qué datos usamos para decidir
- qué criterios dejamos explícitos
- qué decisiones pueden delegarse
- cuáles requieren validación humana
- cómo auditamos el resultado
- qué pasa cuando el sistema se equivoca
Automatizar sin mejorar la decisión puede acelerar un problema.
Puede escalar un criterio pobre.
Puede reducir costos hoy y aumentar riesgo mañana.
La ventaja es solo en tener más agentes, más flujos o más herramientas conectadas.
Es diseñar mejor el sistema donde esas herramientas operan.
Quizás el próximo salto de productividad no esté en automatizar más tareas.
Sino en revisar con más seriedad qué decisiones sostienen nuestro negocio.
El organigrama de las empresas empieza a cambiar, pero no siempre se ve en PowerPoint.
Porque algunas tareas ya no las hace una persona sola, ni un sistema tradicional, sino una combinación entre personas y agentes de IA.
Un agente puede analizar, ejecutar, sugerir, comparar, escribir código, revisar información o disparar procesos.
Pero la responsabilidad sigue siendo humana.
Y eso obliga a rediseñar varias cosas:
- quién define el objetivo
- quién valida el resultado
- quién audita las decisiones
- quién corrige cuando algo falla
- quién mide el costo real de automatizar
- quién decide cuándo frenar
Porque sumar agentes no es solo incorporar tecnología. Es modificar la forma en que se distribuye el trabajo, la confianza y el control dentro de una organización.
El futuro del trabajo no va a ser persona o IA. Va a ser un diseño de colaboración.
Y ese diseño no puede quedar librado a la improvisación.
Si un agente empieza a participar de procesos críticos, necesita contexto, permisos, límites, trazabilidad y una persona responsable del sistema completo.
Entonces el nuevo organigrama no se dibuja solo con cargos y reportes. También debería empezar a mostrar flujos... qué personas toman decisiones, qué agentes ejecutan partes del proceso, qué sistemas aportan contexto y en qué puntos aparece la validación humana.
¿Tiene sentido que sigamos dibujando organigramas solo con personas, cuando parte del trabajo ya empieza a ser ejecutado por agentes?
La productividad con IA se está midiendo mal.
Estamos mirando cuánto más rápido se escribe código, se arma una propuesta o se responde un ticket.
Importa... pero en una empresa, velocidad no es lo mismo que delivery.
Las conversaciones sobre IA se quedan siempre en la capa visible: horas ahorradas, tareas automatizadas, etc.
Pero que sucede cuando esa velocidad genera más trabajo en validación?
- Más retrabajo
- Más deuda técnica
- Más decisiones sin contexto
- Más piezas sueltas difíciles de operar
La pregunta no debería ser solo:
¿Cuánto más rápido producimos?
¿Cuántas tareas automatizamos?
¿Cuántas personas usan IA?
También deberíamos medir:
- Cuánto llega realmente a producción
- Cuánto vuelve por errores o ambigüedad
- Cuánto baja el ciclo completo de entrega
- Cuánto mejora la calidad de decisión
- Cuánto riesgo operativo estamos incorporando
Es una opinión personal por supuesto... pero la productividad real no está en hacer más cosas en menos tiempo.
Porque una empresa no compite por generar código más rápido.
Compite por entregar mejor.
¿Qué métrica de productividad con IA te parece que hoy estamos mirando mal?
Las mejores herramientas internas no son las que tienen más funcionalidades.
Son las que entienden cómo trabaja realmente una empresa.
Muchas compañías intentan adaptar sus procesos a herramientas genéricas, cuando quizás el verdadero salto está en construir herramientas que se adapten a su forma de operar.
Un ejemplo simple: si un equipo ya tiene una cultura de revisión en documentos, tablas, comentarios y decisiones compartidas, no necesariamente necesita “otra plataforma”.
Quizás necesita llevar esa dinámica un paso más adelante:
- comentar directamente sobre un prototipo
- resumir feedback con IA
- convertir observaciones en acciones
- enviar correcciones al flujo de desarrollo
- mantener trazabilidad sin cambiar el hábito del equipo
La IA no solo permite automatizar tareas.
Permite diseñar herramientas internas que evolucionan con la cultura de trabajo.
La ventaja no está en usar la misma herramienta que todos.
Está en convertir tu forma de trabajar en software.
Porque ya no hablamos solo de eficiencia.
Hablamos de conocimiento operativo convertido en sistema.
Y para muchas empresas medianas y grandes, ahí puede haber una ventaja enorme: menos fricción, menos pérdida de contexto y procesos que no dependen tanto de recordar “cómo se hacen las cosas”.
En FK {tech} nos dedicamos justamente a eso: transformar procesos propios, cultura operativa y conocimiento interno en software útil, integrado y escalable.
Porque muchas veces la próxima ventaja competitiva no está en comprar otra herramienta.
Está en construir la que tu empresa realmente necesita.
La IA no está cambiando solamente los trabajos.
Está cambiando algo más profundo: las habilidades que esos trabajos necesitan para seguir existiendo.
A veces la discusión se queda en una pregunta demasiado simple:
¿Qué puestos va a reemplazar la IA?
Pero en la práctica, lo que veo es más interesante.
El nombre del rol puede seguir igual.
Lo que cambia es la forma de ejecutarlo.
Un técnico no deja de ser técnico.
Pero empieza a diagnosticar de otra manera... con datos, modelos predictivos y alertas inteligentes.
Un médico no deja de ser médico.
Pero toma decisiones con más información, más contexto y más velocidad.
Un operador no desaparece necesariamente.
Pero pasa de ejecutar tareas repetitivas a supervisar sistemas, interpretar señales y resolver excepciones.
Hay una verdadera transformación:
- menos tareas rutinarias
- más criterio para decidir
- más capacidad de interpretar tecnología
- más responsabilidad sobre procesos automatizados
- más necesidad de aprender continuamente
El riesgo para las empresas no es solo quedarse atrás en tecnología.
Es quedarse atrás en capacidades humanas.
Porque una organización puede comprar herramientas de IA.
Lo difícil es preparar a su gente para trabajar distinto.
La ventaja es reemplazar personas más rápido.
Es ayudar a las personas correctas a evolucionar antes.
La semana pasada estuve en China junto a 80 empresarios de diferentes industrias para mirar de cerca cómo algunas compañías están aplicando tecnología, innovación e inteligencia artificial en contextos reales.
Fue una experiencia muy potente, no solo por lo que vimos, sino por las conversaciones que se generaron alrededor de eso.
Gracias Vistage Argentina por abrirme el espacio para compartir, desde la mirada de la tecnología aplicada, algunas impresiones de este viaje.
Fui esperando encontrar respuestas en la tecnología misma. Pero regrese con una idea distinta a la que esperaba.
Me impactó cómo algunas empresas logran convertir la tecnología en sistema, en operación y en decisión estratégica.
Porque una cosa es tener herramientas.
Otra muy distinta es integrarlas con claridad.
Lo que vi me dejó varios aprendizajes:
- La ventaja no siempre está en inventar más, sino en aplicar mejor.
- Innovar no es sumar tecnología, es rediseñar cómo funciona una empresa.
- El valor muchas veces no está en una pieza aislada, sino en cómo se coordina todo el sistema.
- Pivotar no siempre es abandonar algo... a veces es entender mejor dónde se movió el valor.
- La IA puede escalar procesos, pero el criterio humano sigue siendo el filtro más difícil de reemplazar.
La tecnología impresiona.
Pero lo que realmente transforma es la decisión de reorganizar la empresa alrededor de una oportunidad.
Ese fue, para mí, el gran aprendizaje del viaje.
Gracias a Vistage Argentina y a Innovation Experience por permitirnos vivir, pensar y compartir esta experiencia junto a una comunidad de líderes que también busca entender cómo se construye el futuro desde el presente.
3nod se encuentra en un lugar que muchas empresas todavía no terminan de entender: no solo ejecutar, sino co-crear.
Y esto, bien hecho, cambia completamente el tipo de relación con el cliente.
Antes, el modelo era claro:
el cliente piensa, define… y un proveedor ejecuta.
Ahora ese esquema empieza a romperse.
Porque en contextos de alta incertidumbre (IA, nuevos productos, modelos digitales), el cliente muchas veces no sabe exactamente qué construir.
Entonces aparece el valor real de enfoques como el de 3nod.
Lo interesante no es que “también hacen I+D”.
Lo importante es cómo se posicionan en el sistema de decisión del cliente.
Esta es la diferencia entre “decir que hacés I+D” y realmente operar de esa forma.
No es sumar una etapa. Es cambiar la lógica de cómo se construyen los productos.
Si 3nod logra estructurar bien ese modelo (procesos, métricas, contratos, expectativas), tiene una ventaja fuerte:
deja de ser reemplazable como proveedor.
Miramos a empresas como Tencent como “casos lejanos”. Demasiado grandes. Demasiado distintas.
Pero si uno baja el análisis a lo esencial, la evolución es mucho más aplicable de lo que parece.
Tencent no empezó como un gigante. Empezó resolviendo algo simple: comunicación.
Después sucedió algo interesante.
No creció solo agregando productos.
Fue construyendo capas.
Primero usuarios.
Después engagement.
Después infraestructura.
Y recién ahí, monetización a escala.
Muchas pymes intentan capturar valor demasiado pronto, sin haber consolidado las capas anteriores.
En el caso de Tencent, el orden importó:
- Primero: una base de usuarios activa y recurrente
- Luego: productos que aumentan el tiempo dentro del ecosistema
- Después: integración de servicios (pagos, gaming, contenido)
- Finalmente: modelos de negocio que capturan ese flujo
> La escala no viene de lo que vendés. Viene de lo que lográs sostener.
El aprendizaje no es “convertirse en Tencent”.
Es entender que crecer no es sumar líneas de negocio.
Es diseñar una secuencia que se pueda sostener en el tiempo.
Durante años, en tecnología, pivotar se veía como una señal de que algo no funcionó.
Pero en realidad no pivotar a tiempo es el verdadero riesgo.
HIGH GREAT no nació para hacer shows de drones.
Su core era tecnología UAV: navegación, coordinación, control autónomo.
Pero encontró algo más valioso:
no vender drones… sino orquestarlos.
Pasó de producto a sistema.
De hardware a experiencia coordinada.
Lo interesante no es el show. Es lo que hay debajo:
- Algoritmos de coordinación multi-agente en tiempo real
- Sistemas de posicionamiento y sincronización masiva
- Tolerancia a fallos en enjambres (si uno cae, el sistema sigue)
- Simulación previa para validar comportamientos complejos
- Control central + autonomía distribuida
Eso no es entretenimiento. Es infraestructura aplicada.
Pivotar bien no es cambiar de idea. Es entender mejor dónde está el valor real.
El riesgo de no hacerlo a tiempo es más concreto de lo que parece:
- Seguir optimizando algo que el mercado ya commoditizó
- Quedarse en el “producto” cuando el valor migró
- Llegar tarde a donde los márgenes todavía existen
Muchos equipos hoy están construyendo “features con IA”.
Pocos están preguntándose si deberían rediseñar el modelo completo.
Baidu Apollo cambió lo que entendía como definición de innovación.
No es la tecnología.
Es el nivel de ambición con el que se decide usarla.
Porque nada de lo que vi es “mágico” en sí mismo: sensores, modelos, mapas, simulación… todo existe hace años.
La diferencia es otra: alguien decidió llevarlo hasta las últimas consecuencias.
Y eso redefine innovación.
- No es tener acceso a IA, es diseñar un sistema que dependa de ella
- No es probar un caso, es sostenerlo en entornos reales
- No es optimizar un proceso, es reemplazar una forma completa de hacer las cosas
- No es sumar features, es cambiar el rol de las personas en el sistema
Innovar no es adoptar tecnología. Es animarse a rediseñar la realidad donde esa tecnología vive.
Lo difícil no es construir el primer prototipo.
Es aceptar todo lo que tenés que romper para que eso funcione de verdad.
Estás innovando… o solo modernizando lo que ya tenes?