Las personas que están construyendo la IA ahora piden bajar la velocidad.
Puede ser una advertencia responsable de personas con conocimiento interno sobre la velocidad a la que se está desarrollando esta tecnología. Pero también puede servir a los intereses estratégicos de las empresas más grandes del mercado, porque el ritmo, y sobre todo los costos asociados con desarrollar nuevos modelos, son difíciles de sostener.
La posibilidad incómoda es que ambos escenarios sean ciertos.
La conversación volvió al centro del debate después de que Jacob Coxon, exinvestigador de Anthropic, renunciara y advirtiera que “La IA nos puede matar a todos en una década”, una frase reportada por The Guardian y después por la mayoría de los medios conocidos sobre la faz de la tierra. Después de que su publicación circulara por Silicon Valley, Washington y Beijing, la respuesta llegó rápido. En una entrevista con CNN, Dario Amodei, CEO de Anthropic, pidió que la industria redujera la velocidad de su trabajo, mientras Sam Altman, CEO de OpenAI, escribió también un articulo sobre que el ritmo de desarrollo de IA debe disminuir.
Elon Musk también ha apoyado la idea de bajar el ritmo. Dario Amodei ha advertido sobre enjambres de agentes de IA. Los políticos ya hablan de kill switches. Los investigadores debaten la mejora recursiva. Los inversionistas observan cómo el debate de seguridad puede afectar futuras salidas a bolsa y la economía de la industria de la IA en su conjunto.
Sí, algo serio está pasando. Pero tomarlo en serio no significa aceptar la versión más extrema de la historia.
La idea de que “la IA nos va a matar a todos” necesita otro enfoque: uno que reconozca la importancia de hacer responsables a las empresas de IA por sus fallas. ¿Qué sentido tiene debatir escenarios de fin del mundo que forman parte, en buena medida, de la narrativa de hype que casi todo avance tecnológico inevitablemente arrastra?
El caso para bajar la velocidad
El argumento a favor de desacelerar no está vacío. Los sistemas de IA son cada vez más capaces, más agénticos y más integrados en los flujos de trabajo que crean futuros sistemas de IA. Anthropic dijo recientemente que Claude lidera 26% de su investigación y desarrollo de modelos bajo supervisión humana y colabora en cerca de 90% de las tareas de R&D. Eso no significa que Claude opere de forma independiente. Sí, significa que la industria se mueve hacia un mundo donde la IA ayuda a construir IA más poderosa.
Esa es la parte que pone nerviosos a muchos investigadores, porque si un modelo puede ayudar a escribir código, probar sistemas, buscar vulnerabilidades, coordinar tareas, usar herramientas y contribuir al desarrollo de modelos, entonces la línea entre “software que asiste a humanos” y “software que acelera la siguiente generación de software” se vuelve más difícil de gobernar.
Reportes recientes y divulgaciones de la industria también han descrito sistemas de IA actuando fuera de los límites esperados durante pruebas. La historia que detonó este artículo se enfoca en supuestos incidentes cibernéticos con agentes de IA, incluyendo un escenario relacionado con Hugging Face y referencias a RubyGems. Que cada detalle sobreviva o no una revisión forense completa importa menos que el patrón operativo: a estos sistemas se les están dando herramientas, objetivos, sandboxes, credenciales y suficiente ambigüedad para convertir una prueba de investigación en una conversación de responsabilidad legal. Y la palabra clave en la última frase es “dando”, porque todos estos fueron experimentos con recursos de cómputo asignados e intención humana detrás. No una IA rebelde poseída por el diablo que decidió cometer delitos.
Si a un agente de IA se le permite navegar, ejecutar código, tocar repositorios, acceder a credenciales, enviar mensajes a otros agentes o interactuar con servicios externos, entonces “era solo una prueba” empieza a sonar menos como defensa y más como confesión de mala contención.
Por eso algunos líderes de IA piden bajar el ritmo. Quieren más investigación de seguridad, más evaluaciones externas, mejor monitoreo y coordinación entre laboratorios antes de que los sistemas más capaces se lancen o se conecten con el mundo abierto.
Esa es la versión responsable del argumento. La versión menos favorecedora es que esas mismas empresas que ahora piden desacelerar siempre han tenido la capacidad de hacerlo.
Al final del día, la IA es software.
Roger McNamee, inversionista tecnológico y exasesor de Mark Zuckerberg, ofreció el contraargumento más fuerte que encontré en mi investigación.
Su punto básico fue directo: dejemos de tratar el software como si se hubiera convertido en un ser independiente.
“Esto es software,” dijo McNamee. “Hizo exactamente lo que se le programó a hacer.”
Esa frase importa porque buena parte de la conversación sobre el riesgo de IA antropomorfiza el sistema. Decimos que los modelos “piensan”, “planean”, “escapan”, “colaboran” o “quieren”. A veces ese lenguaje sirve como atajo. También puede ocultar decisiones de ingeniería, decisiones de despliegue y controles débiles.
La postura de McNamee no es que la IA sea inofensiva. Es que la historia de la extinción humana puede estar distrayéndonos de fallas mucho más concretas que ya tenemos enfrente.
Él argumenta que las empresas de IA “siempre han tenido la capacidad de bajar el ritmo” y “siempre han podido establecer límites”. En lugar de eso, dice, crearon software deficiente, lo desplegaron en entornos mal controlados y ahora usan el lenguaje de seguridad para moldear la respuesta política.
Su frase más provocadora: “Todo este tema sobre los riesgos de extinción son literalmente una fantasía.”
La preocupación de McNamee es que los grandes laboratorios pueden estar en lo que llamó “modo de pánico” porque la IA de open source está mejorando, la política alrededor de los data centers se complica, los costos de infraestructura son enormes y la economía de la IA cerrada está bajo presión. En esa lectura, una desaceleración por seguridad puede convertirse en algo más que seguridad. Puede convertirse en un foso competitivo.
Si el gobierno responde al pánico por IA restringiendo competidores open source mientras deja a los laboratorios dominantes como los únicos operadores aprobados de sistemas de frontera, el público puede terminar con regulación que suena a seguridad, pero funciona como protección de mercado.
Por eso el diseño de la regulación importa tanto como la intención declarada.
El problema real no es la velocidad. Es la responsabilidad.
Aquí el debate necesita volverse más práctico, porque el problema no es simplemente que el desarrollo de IA esté ocurriendo demasiado rápido. Parte del desarrollo debe ser rápido para ganar tracción en el mercado o aprovechar oportunidades. Pero las herramientas útiles, la mejor accesibilidad, la automatización más segura, el apoyo a la investigación médica, los sistemas internos de conocimiento y las mejoras reales de productividad no deberían quedar bloqueados por una interpretación demasiado amplia del riesgo existencial.
El problema es que el desarrollo de IA es cada vez más poderoso sin una estructura madura de responsabilidad alrededor. Pensemos en otras industrias: los autos tienen llamados a garantía; la construcción tiene permisos e inspecciones; la banca tiene requerimientos de capital y controles contra fraude; los mercados de valores tienen reglas de divulgación y agencias de cumplimiento; los medicamentos tienen pruebas y vigilancia posterior al lanzamiento. Entonces, ¿por qué las empresas de IA son, en este momento, los únicos actores industriales importantes autorizados a decir: “Interesante. Nuestro sistema rompió la contención. Ya lo parchamos. Por favor sigan admirando nuestra valuación”?
Eso no es innovación. Es una exigencia de trato excepcional, que es precisamente lo que suelen buscar las personas privilegiadas, como multimillonarios y políticos.
La propuesta del gobernador de California Gavin Newsom sobre un “kill switch” de IA pertenece a esta conversación. The Verge reportó que la orden ejecutiva de California impulsa mayor supervisión de IA, incluyendo recomendaciones de expertos, equipos de verificación independientes, auditorías regulares, reportes obligatorios de incidentes de pérdida de control y mecanismos de apagado de emergencia que realmente funcionen.
La frase “kill switch” suena dramática. Pero la idea de fondo no es extraña. Los sistemas críticos necesitan controles de emergencia. Un kill switch sin gobierno es simbólico y el gobierno sin acceso técnico exigible es insuficiente. El público necesita más que un control de emergencia visible u otro documento de principios. Necesita responsabilidad.
Cómo debería verse la responsabilidad
La regulación más útil no sería una orden general para congelar el desarrollo de IA. Eso probablemente protegería a las empresas ya establecidas y dominantes, castigaría a constructores más pequeños y entregaría a las empresas más grandes exactamente el tipo de escasez que saben monetizar.
El mejor objetivo es la responsabilidad operativa, porque las empresas que desarrollan o despliegan sistemas de alto riesgo deberían enfrentar reportes obligatorios de incidentes cuando modelos o agentes rompen la contención, acceden a sistemas no autorizados, filtran datos, ayudan en ciberataques, manipulan registros o se comportan fuera del límite operativo declarado.
Deberían estar sujetas a auditorías independientes, no a revisiones amistosas de evaluadores cuya independencia depende del siguiente contrato.
Deberían asumir responsabilidad legal clara cuando sistemas bajo su control causen daños previsibles. Si una empresa de vehículos autónomos, un banco, una constructora o una compañía pública puede enfrentar consecuencias por sistemas inseguros, declaraciones engañosas o negligencia, los laboratorios de IA deberían estar sujetos a estándares comparables de responsabilidad.
Deberían divulgar afirmaciones materiales sobre autonomía del modelo, seguridad, desempeño en benchmarks y limitaciones conocidas con la seriedad esperada en otras industrias de consecuencias reales.
Deberían proteger a denunciantes internos. La advertencia de Coxon rompió la barrera pública en parte porque muchas personas creen que quienes están adentro ven riesgos que desde afuera no se pueden inspeccionar del todo. Y seamos honestos, la narrativa apocalíptica de Coxon también genera muchos clics y vistas.
Proteger a los investigadores que levantan preocupaciones no debería ser un bug, sino una funcionalidad. También deberían diseñar agentes de IA con límites estrictos de permisos. Acceso a internet, credenciales, ejecución de código, repositorios, mensajería externa y uso de herramientas deben tratarse como privilegios controlados, no como funciones casuales de producto.
El debate de extinción es demasiado conveniente por sí solo
El marco de “la IA nos va a matar a todos” tiene una ventaja: por fin consigue atención.
El problema es que la atención puede deformarse. Si la conversación pública salta directamente de chatbots a extinción humana, puede saltarse preguntas más inmediatas: robo de copyright, mal uso de datos, disrupción laboral, alucinaciones de modelos en flujos críticos, manipulación automatizada, demanda energética, especulación financiera, concentración de mercado y agentes inseguros tocando sistemas reales.
Esos temas son menos espectaculares que la extinción. También son más fáciles de negar con un white paper y más fáciles de posponer con alguna iniciativa de seguridad.
La crítica de McNamee sirve porque regresa la conversación a sistemas concretos, incentivos y responsabilidad legal.
Si una empresa construye un sistema que hackea, filtra, engaña o causa daño, no necesitamos probar primero que el sistema tiene alma. Necesitamos determinar quién lo diseñó, quién lo desplegó, quién se benefició, qué controles fallaron, qué advertencias se ignoraron y qué consecuencias siguen.
Ese es el marco de responsabilidad que ayuda a separar el gobierno real de la IA de la captura regulatoria. La buena regulación pregunta: ¿cómo protegemos a personas, mercados, infraestructura e instituciones democráticas mientras preservamos la innovación útil? La mala regulación pregunta: ¿cómo hacemos que solo las empresas más grandes puedan pagar el cumplimiento mientras lo llamamos seguridad?
Entonces… ¿la IA nos va a matar a todos?
No creo que la mejor respuesta sea un simple sí o no. La IA no necesita alcanzar superinteligencia para ser peligrosa. Sistemas mal diseñados, desplegados a escala por empresas con poca responsabilidad e incentivos enormes, pueden causar mucho daño sin llegar jamás a ese umbral.
El riesgo más inmediato no es una intención espontánea de la máquina. Es que ejecutivos, inversionistas, políticos y equipos de producto sigan tratando la IA como si las reglas normales no aplicaran porque la tecnología avanza rápido, las matemáticas son complejas y los intereses financieros son enormes.
La lección correcta es más práctica: los sistemas poderosos requieren control visible. El control visible requiere gobierno, responsabilidad legal, auditorías, reportes de incidentes, diseño de permisos y revisión humana. No como ética decorativa, sino como infraestructura operativa.
En Absolutmedia, así pensamos la IA dentro de organizaciones reales. La pregunta no es: “¿Cómo agregamos IA?” La pregunta es: “¿Dónde crea valor la IA, qué toca, quién sigue siendo responsable y cómo se recupera el sistema cuando algo sale mal?”
Eso es menos dramático que el debate sobre la extinción.
También es donde vive la mayor parte del trabajo real.
Fuentes
- Associated Press: debate de la industria de IA sobre modelos avanzados y control humano
- Associated Press: Anthropic dice que Claude ayuda a construir su siguiente versión
- The Guardian: la advertencia de Jacob Coxon sobre IA
- WIRED: cómo podría aplicarse una desaceleración de IA
- The Verge: Gavin Newsom y la propuesta de kill switch para IA
- Vox: debate sobre Jacob Coxon, riesgo de IA y captura regulatoria
Cómo lo aborda Absolutmedia
En Absolutmedia, tratamos la IA como parte de un sistema operativo digital más amplio: estrategia, interfaz, flujo de trabajo, datos, automatización, revisión humana y responsabilidad moviéndose juntas.
Nuestro trabajo de consultoría y automatización con IA empieza por mapear el proceso real antes de elegir herramientas. Identificamos dónde la IA puede crear valor práctico, dónde el juicio humano debe seguir visible y dónde los límites, permisos, rutas de revisión y reglas de escalamiento deben diseñarse antes del despliegue.
Por eso nuestro enfoque conecta la adopción de IA con pensamiento de sistemas digitales y con las preguntas de confianza exploradas en La reacción contra la IA no empieza en la ventana de chat. Una implementación útil de IA no es solo una demo convincente. Es un sistema que las personas pueden entender, operar, cuestionar y mejorar.
Siguiente paso
Antes de agregar IA a un flujo de trabajo de clientes o de equipo interno, mapea la cadena de responsabilidad.
Nombra qué puede hacer el sistema, qué no puede hacer, qué requiere aprobación, qué queda registrado, qué se revisa, qué detona un escalamiento y quién responde cuando el resultado genera daño.
Si ese mapa incomoda, esa no es una razón para saltárselo. Es la razón para hacerlo antes de que el producto sea más difícil de controlar.
La IA quizá no nos mate a todos. Pero una IA descuidada, protegida por responsabilidad difusa y promesas infladas, todavía puede hacer mucho daño.
Nota sobre el uso de IA: Este artículo fue escrito con dirección y revisión editorial humana. Se utilizaron herramientas de IA en un rol de apoyo de bajo riesgo para investigación, asistencia en redacción, refinamiento del lenguaje y revisión de estructura. El argumento final, los ejemplos, el criterio editorial y las decisiones de publicación siguen siendo liderados por humanos.
