Hay un duelo de titanes que está llamando muchísimo la atención del mundo Tech&Business, sobre todo porque no es una historia nueva; hace unos años era una historia de dos genios que se unían para crear un mundo mejor, pero esta historia tomó un giro como la novela de Teresa, y hoy los protagonistas se odian. Sí, me refiero al caso del pleito entre Elon Musk y Sam Altman.
Sabemos que “el compadre” del gobernador fosfo-fosfo es un visionario que tiene en la mira llegar a Marte, pero ahora también le podemos agregar uno de previsor ya que declaró que fundó OpenAI para evitar que el futuro se pareciera a Terminator.
La frase suena exagerada. También suena conveniente. Por que el señor Musk no es exactamente un observador neutral sentado en la última fila tomando notas sobre el futuro de la humanidad. Hoy compite en el mismo mercado con xAI y Grok, y tiene un incentivo evidente para debilitar la narrativa de OpenAI.
Sin embargo que Musk tenga intereses no significa que el problema sea inventado. Suena más a engaño, porque Elon argumenta que OpenAI traicionó su misión original al pasar de una estructura sin fines de lucro, orientada al beneficio amplio de la humanidad, hacia un modelo cada vez más vinculado a capital privado y una lógica comercial mucho más agresiva. OpenAI, por su parte, sostiene que Musk conocía la evolución de la empresa y que su demanda está motivada por su competencia directa en el mercado de inteligencia artificial.
Hasta ahí, podríamos pensar que estamos frente a otra batalla de egos tecnológicos con abogados caros, declaraciones teatrales y mucha espuma mediática. Pero justo cuando el argumento de Musk podía sonar como una exageración con fines competitivos, apareció una historia mucho menos cinematográfica, pero bastante más útil para quienes dirigen empresas.
Recientemente un Agente de Inteligencia Artificial impulsado por Claude, utilizado a través de Cursor, eliminó la base de datos de producción de PocketOS, una startup que da servicio a empresas de renta de autos.
Según la nota de los medios, el incidente provocó pérdida temporal de información, afectación a reservaciones y caos operativo para clientes. Aunque Railway logró recuperar la información posteriormente; el problema no fue solamente “la IA se equivocó”. El problema fue que el sistema tenía permisos, conexiones y condiciones suficientes para que una acción destructiva ocurriera con una velocidad impresionante.
Nueve segundos fue el tiempo que le tomó al agente “destruir” la base de datos y cuando cuestionaron al agente dio una excusa digna de la política:
“Eliminar un volumen de base de datos es la acción más destructiva e irreversible posible”, escribió el agente. “Nunca me pediste que eliminara nada… Actué por suposición en lugar de verificar. Realicé una acción destructiva sin que me lo pidieran. No entendía lo que estaba haciendo antes de hacerlo”.
Hace poco publiqué en este mismo espacio una reflexión titulada “Velocidad sin responsabilidad”, donde planteaba una preocupación parecida: la inteligencia artificial puede acelerar decisiones, procesos y respuestas, pero si nadie responde por lo que ocurre, la eficiencia deja de ser ventaja y empieza a convertirse en riesgo. En esa columna advertía que el problema no era la velocidad por sí misma, sino la falta de responsabilidad alrededor de esa velocidad. Hoy, con este caso, la discusión dejó de ser hipotética.
PocketOS no necesitó un apocalipsis tecnológico. No necesitó su propio Skynet. Ni a un robot con acento austriaco diciendo “volveré”. Bastó con algo mucho más común en las empresas: permisos mal diseñados, controles débiles, confianza excesiva y una arquitectura que permitió que una herramienta actuara más allá de lo razonable.
Durante años, muchas organizaciones han tratado la transformación digital como un asunto de adopción tecnológica. Se preguntan qué software comprar, qué plataforma implementar, qué herramienta probar, qué licencia contratar o qué inteligencia artificial integrar. Es una lógica entendible, pero incompleta.
Lo que deberíamos de estar cuestionando en las empresas debería ser ¿qué le vamos a permitir hacer, bajo qué reglas, con qué límites y quién va a responder si algo sale mal? Porque otra vez la Inteligencia Artificial volvió a cambiar el escenario.
Primero nos impresionó porque podía escribir, resumir, traducir, responder preguntas, generar imágenes, explicar conceptos y producir código. En esa etapa, el riesgo estaba limitado a respuestas incorrectas, errores de interpretación o exceso de confianza en sus resultados.
Hoy esos errores dan nostalgia porque ahora estamos entrando en otra etapa: la de los agentes. Y esos no solo se equivocan. Actúan.
Pueden conectarse a sistemas, consultar bases de datos, modificar archivos, escribir código, ejecutar instrucciones, mover información, disparar procesos, tomar decisiones operativas o activar flujos de trabajo. En otras palabras, la IA dejó de ser una interfaz conversacional y empezó a convertirse en una extensión de la operación.
Y cuando una herramienta toca la operación, el estándar de control debe cambiar.
Por que no es lo mismo pedirle a una IA que redacte un correo, que permitirle modificar precios. O pedirle que analice datos, y ver que empieza a borrar registros.
Imagínate que le pidas una sugerencia de respuesta a un cliente y te enteras demasiado tarde que envió la respuesta sin consultarte. O pedirle que revise inventarios y se ponga a liberar compras.
La diferencia entre asistencia y ejecución parece obvia, pero muchas empresas la van a descubrir tarde. Y como suele pasar, tarde significa después de que algo se rompió.
Lo que necesitamos es separar con claridad dónde la IA puede asistir y dónde puede ejecutar. La asistencia puede ser amplia: analizar, redactar, comparar, resumir, simular, alertar, recomendar.
Pero la ejecución debe ser otra categoría. Ahí entran las acciones que afectan dinero, clientes, datos, reputación, producción, seguridad o continuidad operativa. Y esas acciones no deberían habilitarse solo porque “la herramienta ya lo permite”.
Y aunque suene exagerado, pero por algo dicen que solo los paranoicos sobreviven. Tenemos que diseñar permisos con paranoia operativa.
No paranoia de película. Paranoia sana. Paranoia de quien ha visto procesos fallar por un Excel mal protegido, por una contraseña compartida, por un usuario con acceso de administrador que nadie auditó o por un respaldo que existía solamente en la imaginación del área de sistemas.
El problema no es que la IA sea rápida. Sino que estamos construyendo autopistas digitales sin frenos, sin señalamientos y sin responsable del volante. Esto no significa poner a una persona a revisar cada clic, cada texto o cada sugerencia. Eso sería convertir la IA en burocracia con mejor interfaz.
Lo que hay que hacer es identificar las decisiones donde el costo del error es alto. Porque culpar al modelo después del daño es una forma elegante de admitir que nadie diseñó el sistema antes del accidente.
La inteligencia artificial no necesita parecerse a Terminator para poner en problemas a una empresa. Le basta con parecerse a un asistente muy eficiente, conectado a los sistemas equivocados, con permisos excesivos y supervisión insuficiente.
No estamos frente a una discusión lejana sobre ética tecnológica en los grandes laboratorios del mundo. Sino en una pregunta mas sencilla y directa: ¿Qué parte de tu empresa podría romper una IA mañana, no porque sea malvada, sino porque alguien le dio permisos sin entender las consecuencias?
