Por qué el acceso a la IA, y no su capacidad, es el verdadero riesgo de dependencia para usted
Este artículo analiza incidentes recientes de control de exportaciones relacionados con Claude y GPT-5.6 para argumentar que el acceso a los modelos de IA es una variable volátil independiente de la capacidad bruta.
¿Qué es lo que realmente diferencia alquilar inteligencia de poseerla?
Durante aproximadamente tres años, la industria se centró por completo en la métrica equivocada.
Se libraron intensos debates sobre puntos de referencia, capacidad de razonamiento, tasas de alucinaciones y tamaño de la ventana de contexto: todos indicadores de qué tan inteligentes eran estos sistemas.
Pero la pregunta que es más importante hoy es otra: ¿quién tiene el control para apagar esa inteligencia?
El 12 de junio de 2026, el gobierno de Estados Unidos impuso restricciones a la exportación de dos de los modelos más recientes de Anthropic, Claude Fable 5 y Claude Mythos 5.
La orden exigía a Anthropic bloquear el acceso para ciudadanos extranjeros, independientemente de si se encontraban físicamente dentro o fuera de los Estados Unidos.
Anthropic afirmó que no contaba con un método fiable para confirmar la nacionalidad en tiempo real.
Frente a esa situación, la empresa tomó una medida drástica: desactivó ambos modelos para todos los ciudadanos extranjeros, incluidas las personas que formaban parte de su plantilla.
Pasaron dieciocho días antes de que el gobierno retirara las restricciones. Fable 5 volvió a estar disponible en todo el mundo el 1 de julio, mientras que Mythos 5 fue reactivado para un grupo específico de organizaciones estadounidenses una vez que obtuvo la aprobación gubernamental el 26 de junio.
OpenAI siguió casi exactamente el mismo camino, pero partiendo desde el lado opuesto.
El 26 de junio, OpenAI lanzó GPT-5.6; sin embargo, a petición del gobierno, inicialmente limitó su disponibilidad a un pequeño grupo de socios previamente seleccionados cuyas identidades ya habían sido reveladas a los funcionarios. OpenAI dejó claro públicamente que no quería que este tipo de lanzamiento mediado por el gobierno se convirtiera en una práctica habitual en el futuro.
Para el 9 de julio, GPT-5.6 estuvo disponible para todos.
Considere lo que esta secuencia revela en realidad.
Nada fue incautado, eliminado ni dañado por un código defectuoso.
Aun así, durante un tiempo, algunos de los sistemas de IA comerciales más avanzados existentes estuvieron técnicamente operativos, pero inaccesibles para los propios usuarios que los necesitaban.
Todo este episodio añade otra capa al debate en curso sobre el ritmo del desarrollo de la IA: ya no se trata solo de cuán rápido deberíamos avanzar en sus capacidades, sino también de cómo se debe planificar cuidadosamente su implementación y acceso.
La verdadera lección no es que el acceso esté desapareciendo. Es que el acceso funciona como una variable independiente, desacoplada de las capacidades en sí, guiada por su propia lógica, que avanza según su propio cronograma y puede cambiar de dirección más rápido de lo que cualquier organización puede reaccionar.
Esa es una realidad mucho más perturbadora que la de una ventana que se cierra lentamente, porque uno puede planificar teniendo en cuenta una ventana que se reduce. No se puede planificar ante un interruptor que se activa administrativamente, en direcciones impredecibles, a escala de días.
Así que aquí está la pregunta importante: si el modelo en el que confías desapareciera de la noche a la mañana, ¿sobreviviría tu trabajo?
La propiedad no es un archivo descargable
Cuando las personas perciben dependencia, su reacción instintiva es ir a adquirir algo.
Obtienen los pesos abiertos, los almacenan en un disco duro y suponen que pueden estar tranquilos. Pero poseer un conjunto de parámetros solo cubre una pequeña parte de lo que exige la verdadera independencia, y confundir ambas cosas genera un tipo específico de falsa seguridad: el equivalente en inteligencia artificial a comprar un generador de respaldo sin verificar siquiera si se enciende.
Un agente funcional que realiza un trabajo significativo es en realidad una estructura compuesta por al menos cinco componentes: los propios pesos del modelo, el motor de inferencia que los ejecuta, el contexto acumulado del proyecto, las herramientas a las que puede acceder y el conjunto de evaluación que indica si un sustituto realmente cumple con su función.
El archivo del modelo descargado es solo una parte de esa estructura.
La verdadera independencia requiere el derecho legal para operar el modelo, un entorno de ejecución de inferencias que se pueda reconstruir únicamente a partir de la documentación, un estado del proyecto que se pueda exportar libremente, permisos para las herramientas bajo el control de la aplicación y no del proveedor, además de pruebas de que un sistema sustituto puede realmente completar la tarea.
Solo la dimensión legal ya es más complicada de lo que parece a primera vista.
“Open weights” y “open source” no son términos intercambiables: la definición de la Iniciativa Open Source exige mucho más que simplemente poder descargar los parámetros, y una licencia permisiva en el tiempo de ejecución no cubre automáticamente todos los modelos que se ejecutan a través de ella.
Es necesario leer realmente la licencia específica que rige cada recurso y guardar una copia archivada junto a dicho recurso.
La propiedad de los datos se encuentra en un eje completamente separado. Según los términos comerciales de Anthropic, los clientes conservan los derechos sobre todo lo que envían, poseen la propiedad de los resultados generados entre ambas partes, y a Anthropic le está prohibido entrenar modelos con el contenido de los clientes a través de esos servicios en particular. El simple hecho de enviar su contenido a un proveedor no implica la transferencia de la propiedad hacia él. Si ese contenido se mantiene posteriormente es otra cuestión distinta, y la respuesta depende del producto, contrato y configuración específicos en juego, no de lo que haya leído alguna vez en algún lugar.
Nada de esto constituye un argumento en contra del uso de modelos alojados.
Simplemente es un recordatorio de que la frase “nosotros somos dueños de nuestra IA” implica cinco o seis condiciones separadas que deben cumplirse todas, y la mayoría de los equipos nunca se molestan en verificar ninguna de ellas.
La aritmética de la autosuficiencia
Calcular cuánto almacenamiento necesita un modelo es la parte sencilla de la ecuación: toma el número de parámetros, múdalo por la cantidad de bits utilizados por cada parámetro y divídelo entre ocho.
Un modelo de ochocientos millones de parámetros con precisión de dieciséis bits necesita aproximadamente dieciséis gigabytes; si se reduce a precisión de cuatro bits, esa cantidad disminuye a unos cuatro gigabytes. Un modelo de setecientos millones de parámetros consume alrededor de ciento cuarenta gigabytes con dieciséis bits, o unos treinta y cinco con cuatro bits.
Por lo general, aquí es donde la gente deja de pensar en los requisitos de hardware, y también resulta ser el cálculo que aciertan con más frecuencia.
Los verdaderos errores aparecen más adelante en el proceso.
La caché KV, la estructura que almacena el estado de atención a lo largo de una conversación, se expande a medida que las ventanas de contexto se alargan, y vuelve a escalar con cada solicitud simultánea que se procesa.
Las arquitecturas de mezcla de expertos añaden su propio problema: dado que cada token solo activa un subconjunto de la red, el cálculo real por token sigue siendo bajo, pero cada experto, ya sea activo o no, debe permanecer almacenado en la memoria en algún lugar.
Saber cuántos parámetros se activan te indica el costo de procesamiento por token. No te dice nada sobre cuánto espacio ocupa el modelo.
Transferir partes del modelo a otro lugar no elimina el problema de almacenamiento, solo lo traslada; ahora además debes pagar una penalización por transferencia de datos que antes no existía.
Un modelo que se carga con éxito en la memoria aún no demuestra que pueda realmente atender la demanda de tráfico.
La velocidad de procesamiento del prompt, la velocidad de generación y el tiempo total para completar una tarea son tres métricas separadas, y ser rápido al ingresar un prompt no dice nada sobre cuán rápido se generará una respuesta larga.
La carga de trabajo que realmente importa es la exigente: documentos grandes, múltiples usuarios concurrentes y llamadas a herramientas que se repiten continuamente.
Probar con un único prompt corto oculta exactamente ese tipo de retrasos en la cola y competencia por la memoria que hacen que la inferencia local sea problemática cuando varias personas la comparten.
Lo que une a estos errores es un patrón: cada uno toma una cifra fácil de citar y la confunde con el factor limitante real.
Ejecuta tus propios pruebas de rendimiento en el hardware que ya posees, o alquila tiempo con la configuración exacta que estás evaluando antes de tomar una decisión.
Comprar capacidad antes de haber identificado dónde se encuentra el verdadero cuello de botella es una buena forma de asegurarse de que ese cuello de botella siga existiendo.
Una instrucción no es un permiso
El malentendido más importante en el diseño de agentes casi no tiene nada que ver con el modelo que se esté utilizando.
Cuando un modelo genera una llamada a una herramienta, eso es solo una solicitud, nada más.
Algún mecanismo separado debe decidir si dicha solicitud se lleva a cabo realmente.
Es sorprendentemente fácil terminar creando un sistema en el que ese mecanismo separado es, funcionalmente, simplemente el modelo confiando en sí mismo, reforzado por una instrucción amable en alguna parte de la prompt que le pide que se mantenga dentro de los límites.
Eso es una preferencia, no un límite real, y las preferencias son exactamente lo que explotan los ataques de inyección de prompts.
Cualquier cosa que su agente obtenga de fuentes externas se considera entrada no confiable.
Un archivo README puede contener instrucciones dirigidas a tu agente. Lo mismo ocurre con un comentario incrustado en el código fuente, el cuerpo de una entrada en un sistema de seguimiento de problemas o una página web ordinaria.
La solución no radica en instrucciones más inteligentes, sino en un modelo de permisos más estricto: restringir el acceso a un conjunto aprobado de rutas en lugar de a todo el sistema de archivos, limitar el tamaño de los archivos, controlar qué se puede escribir, ejecutar pruebas en un entorno temporal, mantener las credenciales de despliegue fuera del alcance del proceso de trabajo y exigir que un humano revise cualquier parche antes de enviarlo a producción.
Ejecutar la inferencia localmente y restringir los permisos de las herramientas son dos problemas diferentes, y es tentador asumir que resolver uno resuelve también el otro.
Alojar los pesos por uno mismo determina dónde se encuentran físicamente los datos y si el sistema depende de que otra empresa permanezca conectada. Esto no tiene ninguna influencia en las acciones que realmente se permite realizar al agente.
Los equipos que confunden estos dos aspectos terminan con un modelo completamente autoalojado que aún puede causar daños irrestrictos en su propia base de código.
A escala de todo un equipo, la misma lógica sugiere colocar una pasarela autenticada delante del punto de extremo de inferencia, establecer presupuestos de uso por usuario y definir una política explícita para cada flujo de trabajo: ejecutarlo localmente, permitir un modelo alojado autorizado o redirigirlo a un humano para su revisión.
Guarde puntos de control antes de intentar nuevamente los pasos fallidos, y diseñe cualquier herramienta que genere efectos secundarios de manera idempotente, para que un intento de recuperación no repita silenciosamente una acción que ya se ha realizado.
Por qué la fiabilidad actúa en tu contra
Imagina que cada paso en un flujo de trabajo basado en agentes tiene una probabilidad independiente del 95 % de tener éxito. Si conectas diez pasos así, la tasa general de éxito se sitúa alrededor del 60 %: 0,95 elevado a la décima potencia da aproximadamente 0,599.
Si aumentas ese número a veinte pasos, la tasa baja a unos 36 %.
Los pasos en el mundo real no son realmente independientes, así que considéralo más bien una ilustración que un punto de referencia medido. Aun así, demuestra algo que ninguna calidad del modelo puede revertir: la fiabilidad de cada paso no se suma, sino que se multiplica, y lo hace de forma exponencial a medida que aumenta la longitud de la cadena.
Si elevas la fiabilidad por paso del 95 % al 98 %, una secuencia de diez pasos pasa de un 60 % de éxito a un 82 %. Pero si añades diez pasos más a un proceso con una fiabilidad del 95 %, anulas incluso ese aumento total.
Esto cambia lo que realmente se debería esperar de un modelo local pequeño. Su verdadera función no es ser brillante, sino ser fiable en un flujo de trabajo breve, de alcance limitado, fácil de inspeccionar y al que sea sencillo recuperarse si algo falla.
Y lo más importante, la cantidad de pasos en ese flujo de trabajo no está determinada por los pesos del modelo. Es una decisión de diseño que se toma al construir la aplicación.
Reducir la secuencia de pasos, verificar los resultados intermedios y establecer puntos de control para que el proceso continúe en caso de fallo en lugar de reiniciarse desde cero suele brindar más fiabilidad que utilizar un modelo más grande.
Esa es también la razón por la cual la evaluación no puede ser vaga o basada únicamente en anécdotas.
Saque cincuenta tareas de su lista de pendientes real, cada una con un resultado esperado registrado en un lugar al que el agente no pueda acceder ni modificar.
Controla la corrección, si las llamadas a las herramientas fueron válidas, el tiempo de latencia, cuántas reintentos se necesitaron y cuánto tiempo dedicó un humano a solucionar los problemas posteriormente; todo esto se mide con tamaños de contexto y niveles de concurrencia realistas, evaluándose según los umbrales que estableciste antes de poder determinar qué modelo es el mejor.
Hay una distinción que merece su propia columna en tus datos de telemetría: un modelo al que no se puede acceder y un modelo que da una respuesta incorrecta representan fallos fundamentalmente diferentes.
El primero es un problema de enrutamiento y recuperación. El segundo es un problema de calidad.
Si los combinas en un único número de tasa de éxito, perderás exactamente la información que te indica si la solución real consiste en más capacidad, un modelo mejor o una tarea más pequeña y con menos requisitos.
Lo que realmente estás comprando
La única comparación que vale la pena hacer es el costo por tarea aceptada.
Comparar los precios de los tokens implica comparar cosas que no son similares; en cambio, comparar los trabajos aceptados implica comparar cosas que sí lo son. En el caso local, sus costos incluyen la depreciación del hardware, la energía eléctrica, el mantenimiento, el tiempo de inactividad y el esfuerzo necesario para las revisiones. En el caso de la solución alojada, los costos son los tokens, las intentonas repetidas y el esfuerzo de revisión.
Ejecute la misma combinación de tareas bajo el mismo umbral de aceptación en ambos escenarios; cualquier cosa menos que eso convierte la comparación en una farsa.
Los cálculos arrojan los resultados que uno esperaría.
Supongamos que la infraestructura local le cuesta seiscientos dólares al mes en costos fijos, donde cada tarea aceptada cuesta dos centavos localmente frente a veinte centavos mediante una API alojada. El punto de equilibrio se alcanza alrededor de 3,333 tareas aceptadas por mes.
Estas cifras son ilustrativas, no medidas, pero el patrón subyacente se mantiene igual: ejecutar inferencias localmente implica un costo fijo que solo se compensa una vez que se supera un umbral de volumen, y genera pérdidas por debajo de él.
La mayoría de los equipos quedarán por debajo de ese umbral.
Aquí es donde el argumento real a favor de la IA local difiere drásticamente del discurso de marketing.
Cuando no se alcanza el punto de equilibrio, la inferencia local no es la opción más económica, y afirmar lo contrario hace que la decisión sea indefendible en cuanto alguien revise realmente las cifras.
Lo que realmente se está adquiriendo es la opción de seguir operando, incluso si cambian las condiciones de acceso, bajo términos que uno mismo controla.
El precio de las opciones se determina en función de la volatilidad, no de los resultados promedio esperados.
Si las interrupciones recientes han demostrado algo, es que esta volatilidad es real, que proviene de decisiones administrativas y no técnicas, y que llega sin previo aviso.
Ese es un motivo legítimo para invertir dinero.
Pero es una razón diferente a la que se suele dar, y merece ser defendida por sus propios méritos en lugar de disfrazarse como una medida para ahorrar costos.
La prueba que realmente dice algo
Nada de esto depende de creer que las leyes de escalamiento seguirán vigentes, de que realmente se esté cerrando algún período de acceso, o de si la AGI finalmente cabrá o no en una cantidad determinada de VRAM.
Eso son predicciones, y el riesgo de dependencia no requiere que sean ciertas.
Todo lo que se requiere es reconocer que un sistema del cual dependes puede dejar de funcionar por razones que no tienen nada que ver con su rendimiento o con tu comportamiento. Eso ha sido cierto en las redes eléctricas, los cables submarinos y las redes de pago, y ahora es claramente aplicable también a los modelos de IA más avanzados.
La respuesta práctica no es nada emocionante. En su mayor parte implica adquirir habilidades que actualmente das por sentadas, o supones que alguien más ya se ha encargado de ellas.
Prueba esto: reconstruye completamente tu entorno a partir de las notas y copias de seguridad que hayas guardado, luego entrega esas mismas notas a otro ingeniero y observa cómo intenta realizar la misma reconstrucción de forma independiente. Ese único ejercicio te enseñará más sobre cuán autosuficiente eres en realidad que cualquier cantidad de conversaciones fluidas con un modelo que esté disponible hoy. El hecho de que el modelo esté disponible ahora no demuestra nada sobre el futuro, y la única prueba real de resiliencia es si tu configuración puede funcionar sin él.
Lecturas relacionadas
- ReAct explicado: cómo los agentes de IA combinan el razonamiento con acciones del mundo real — Aprende cómo el marco ReAct integra el razonamiento y el uso de herramientas para potenciar a los agentes de IA, y cómo difiere de los modelos Chain-of-Thought, RL y de razonamiento.