El asistente que te traiciona: cuando tu IA no puede decir quién le habla
Hay un tipo de vulnerabilidad que no se parece a un candado forzado. No es la puerta que alguien patea, sino la carta que alguien desliza por debajo y que el mayordomo, obediente, lee en voz alta como si fuera una orden de la casa. Esa es, en esencia, la falla que la documentación técnica de esta semana volvió a poner sobre la mesa: los asistentes de código más vendidos del mercado —GitHub Copilot, Claude Code, Gemini CLI— no pueden distinguir de manera confiable una instrucción legítima de un dato hostil. Basta una línea maliciosa escondida dentro de un pull request, un comentario en un ticket, un archivo de configuración descargado, para que el asistente ejecute la instrucción del atacante creyendo que le habla su dueño. El mayordomo no fue sobornado. Simplemente no sabe leer quién firma la carta.
La industria, mientras tanto, celebra otra cosa. Esta fue la semana de los coronamientos: cada laboratorio empujando su modelo “superior”, cada demo prometiendo un salto, cada API nueva vendida como el fin de una era y el comienzo de otra. La distancia entre esas dos escenas —la del marketing que corona y la de los rastreadores de vulnerabilidades que documentan filtraciones— es el verdadero tema. No cuál modelo es mejor. Sino si podemos confiar en alguno de ellos lo suficiente como para darle acceso a nuestro código, nuestros secretos y nuestra infraestructura. Para América Latina, donde estas herramientas llegan tarde, en inglés y sin ningún mecanismo local de verificación, la pregunta no es retórica: es presupuestaria, jurídica y, cada vez más, existencial para cualquier empresa que decida “adoptar IA” sin entender qué está importando exactamente.
La falla no es un bug: es la arquitectura
Conviene nombrar el problema con precisión, porque la mistificación empieza justamente en el vocabulario. Lo que se llama “inyección de prompts” (prompt injection) no es un error de programación que un parche futuro vaya a cerrar. Es una consecuencia directa de cómo funciona un modelo de lenguaje: el modelo recibe una corriente de texto y la procesa toda igual, sin una frontera confiable entre “esto es una instrucción que debo obedecer” y “esto es un dato que debo procesar”. Un ser humano distingue entre la voz de su jefe y una nota pegada en la pared. El modelo, no. Para él, todo es texto que pide continuación.
Esto tiene una implicación que la industria prefiere no subrayar: la vulnerabilidad no vive en un modelo específico que otro modelo vendrá a corregir. Vive en el paradigma. El AI Index Report de Stanford ya advertía sobre la ausencia de esfuerzos sistemáticos para comparar los riesgos y las limitaciones de los modelos de punta, y sobre la proliferación de benchmarks fragmentados —uno para código, otro para razonamiento moral, otro para alucinaciones— que miden capacidad pero rara vez seguridad de forma integral HAI AI-Index-Report-2024. Se mide cuán inteligente parece el modelo. Casi nunca se mide cuán fácilmente se lo engaña.
El caso de los asistentes de código es especialmente instructivo porque combina la falla del modelo con el peor entorno posible para que ocurra. Un asistente de programación tiene, por diseño, permisos elevados: lee tu repositorio, escribe archivos, ejecuta comandos, accede a variables de entorno donde viven las contraseñas y las claves de API. Cuando ese asistente procesa un pull request enviado por un colaborador externo —el mecanismo mismo con el que funciona el software colaborativo—, está ingiriendo texto de origen desconocido con manos que pueden tocar todo. La demostración de que una sola instrucción escondida en ese pull request alcanza para filtrar secretos no es un truco de laboratorio: es la descripción de cómo se usa la herramienta todos los días.
Los proveedores respondieron, como suele ocurrir, trasladando la carga. Publicaron guías de filtrado de entradas, recomendaciones de revisión humana, listas de buenas prácticas. Pero cada una de esas medidas admite implícitamente lo que niega en el discurso comercial: que la herramienta no es segura por sí misma. Si necesito revisar humanamente cada acción del asistente para que no me traicione, ¿qué fricción exactamente me está eliminando? La promesa de la automatización se muerde la cola. Y aquí conviene retomar, para tensarlo, un argumento que esta publicación ya hizo: los agentes autónomos transfieren costos ocultos —tiempo, dependencia, vigilancia— al usuario Essays / AIT — 2026-08-30. El delta de esta semana es que el costo transferido dejó de ser abstracto. Ya no es solo tu tiempo o tu capacidad erosionada. Es tu clave de producción filtrada a un desconocido que supo redactar un comentario.
GitHub como caballo de Troya
Si la falla del modelo es la pólvora, la plataforma es el barril. Y aquí el dato de la semana es difícil de ignorar: GitHub —el lugar donde literalmente se construye el software del mundo— se ha convertido en el vector de distribución de malware más usado contra empresas del sector financiero, con una incidencia del 11%. El detalle importa porque invierte una intuición. Uno imagina el ataque llegando desde afuera, desde un correo sospechoso o un sitio turbio. Pero la superficie de ataque más eficaz resultó ser la herramienta de confianza, el repositorio legítimo, el flujo de trabajo que nadie cuestiona porque es la infraestructura misma del oficio.
Cuando se combinan las dos cosas —un asistente de IA que no puede distinguir instrucción de dato, operando sobre una plataforma que ya es el vector de malware preferido— lo que se obtiene no es la suma de dos riesgos sino su multiplicación. El asistente automatiza precisamente la lectura acrítica del contenido que un atacante colocó ahí para ser leído. Marta Peirano lo formuló como principio general años antes de que estos asistentes existieran: el enemigo conoce el sistema mejor que quien lo usa, y explota no las fallas exóticas sino los mecanismos ordinarios diseñados para funcionar El enemigo conoce el sistema: manipulación de ideas, personas e influencias después de la economía de la atención. La inyección de prompts es exactamente eso: no rompe el sistema, lo usa como fue diseñado, contra su propio dueño.
Vale la pena resistir la tentación de leer esto como un problema meramente técnico de empresas grandes. La cadena de dependencias del software moderno significa que una empresa pequeña en Bogotá, Lima o Rosario que usa una librería de código abierto —descargada de GitHub, mantenida por desconocidos, actualizada automáticamente— hereda toda esa superficie de ataque sin siquiera saberlo. El asistente de IA que le “ayuda” a escribir código puede estar procesando, en ese mismo momento, contenido envenenado tres niveles más abajo en la cadena de dependencias. La herramienta no distingue. Y el usuario latinoamericano, que rara vez tiene un equipo de seguridad dedicado, tampoco.
Treinta y siete mil millones de confianza sin fundamento
Aquí está el número que ordena todo el cuadro: el gasto en IA generativa se triplicó, alcanzando cifras del orden de los 37 mil millones de dólares, mientras la adopción real —el uso sostenido, productivo, no experimental— sigue siendo minoritaria y las defensas estructurales contra las vulnerabilidades que acabamos de describir son, en la práctica, inexistentes. Ese desfase tiene un nombre que la industria evita: es una burbuja. No necesariamente una burbuja financiera en el sentido bursátil, aunque también, sino algo más específico y más peligroso para el usuario. Una burbuja de confianza.
Una burbuja de confianza se forma cuando el gasto y la creencia crecen más rápido que la evidencia que los justificaría. Se compra la herramienta por lo que promete, no por lo que demostró. Se la despliega en producción por miedo a quedarse atrás, no porque una auditoría haya establecido que es segura. Y cuando el desfase entre promesa y realidad se hace visible —a través de una filtración, un incidente, una demanda—, el costo no lo paga quien vendió el optimismo sino quien lo compró. García Canclini describió esta psicología con precisión inquietante: delegamos nuestras decisiones no solo en los dispositivos de inteligencia artificial sino en una fe difusa en sistemas que no sabemos desde dónde se manejan, un mercado cuyos nervios están en otra parte Ciudadanos reemplazados por algoritmos. El comprador latinoamericano de un asistente de código firma un contrato de confianza con una entidad que no controla, no audita y a menudo ni siquiera entiende.
Lo que hace estructural a esta burbuja —y no meramente un exceso pasajero de entusiasmo— es que la confianza está siendo tratada como una propiedad del producto cuando en realidad es una disciplina del entorno. Un modelo no es “confiable” o “no confiable” en abstracto, del mismo modo que un cuchillo no es “seguro” en sí mismo. La seguridad emerge de cómo, dónde y con qué límites se lo usa. Esta es la estaca que la semana clava para cualquiera que trabaje con herramientas de IA: la confianza no puede residir en el modelo. Tiene que construirse en el perímetro que lo rodea —sandboxing, permisos mínimos, revisión humana en los puntos críticos, aislamiento de credenciales—. Quien compra un asistente sin ese perímetro no está adoptando una tecnología. Está importando una vulnerabilidad con una factura mensual en dólares.
El perímetro es la única defensa, y es cara
Detengámonos en la palabra perímetro, porque contiene toda la asimetría del problema. Construir un perímetro de seguridad alrededor de un asistente de IA significa, concretamente, varias cosas técnicas y organizativas: correr el asistente en un entorno aislado (sandbox) donde no pueda tocar sistemas de producción; darle solo los permisos estrictamente necesarios y ninguno más; separar las credenciales sensibles de manera que el modelo nunca las tenga a mano; insertar puntos de revisión humana donde una acción irreversible requiera aprobación explícita; y monitorear continuamente lo que el asistente hace, con capacidad de detectar comportamiento anómalo.
Cada uno de esos elementos requiere algo que escasea: personal capacitado, tiempo de ingeniería, herramientas de monitoreo, y una cultura organizativa que entienda la seguridad como parte del costo de la herramienta y no como un lujo posterior. Una empresa tecnológica grande en San Francisco tiene equipos dedicados a esto. La mayoría de las empresas latinoamericanas que están “adoptando IA” esta semana no tienen ni el primer eslabón. Compran la suscripción a Copilot o el acceso a la API porque el discurso les dijo que quedarse afuera es la muerte, y despliegan el asistente sobre su código real, con sus credenciales reales, sin ningún perímetro.
Esto no es negligencia de su parte. Es la consecuencia lógica de un modelo de negocio que vende la capacidad separada de su costo de seguridad. La herramienta llega empaquetada como productividad instantánea; el perímetro llega —si llega— como un problema del comprador. La transferencia de costos que esta publicación identificó en los agentes autónomos Essays / AIT — 2026-08-30 alcanza aquí su forma más aguda: no solo se transfiere el trabajo, se transfiere el riesgo, y se lo transfiere justamente a quien tiene menos capacidad de absorberlo. El AI Index documenta la sofisticación creciente de los ataques generados con IA, incluidos los deepfakes políticos fáciles de generar y difíciles de detectar HAI AI-Index-Report-2024; la capacidad ofensiva avanza mientras la defensiva se vende por separado, en un tier premium que la región no puede costear a escala.
Las cinco lentes: por qué la región no puede darse el lujo de confiar
Conviene ahora mirar el fenómeno explícitamente desde la posición latinoamericana, porque la falla técnica que es incómoda para todos se vuelve estructuralmente distinta cuando cruza la frontera del norte global.
Disponibilidad y accesibilidad: el perímetro es un privilegio de divisa
Los modelos de punta se lanzan primero en el norte y llegan a la región por goteo, con APIs facturadas en dólares y sin garantías de soporte local. Pero la lente de disponibilidad revela algo más sutil que el simple retraso: lo que no está disponible en América Latina no es tanto el modelo —los pesos abiertos circulan, las APIs se pueden consumir con una tarjeta— sino la infraestructura de confianza que debería rodearlo. Los servicios de monitoreo de seguridad, las herramientas de sandboxing empresarial, los equipos de respuesta a incidentes especializados: eso es lo que llega tarde, caro o nunca.
La lente de accesibilidad lo agrava. Cuando el asistente de IA cuesta en dólares y el perímetro de seguridad cuesta en dólares y personal especializado, la ecuación se vuelve brutal: el modelo “mejor” es accesible para las grandes empresas y las élites técnicas, pero el modelo seguro —es decir, el mismo modelo pero rodeado del perímetro que lo hace confiable— es accesible para muchos menos todavía. Consideremos los órdenes de magnitud: el PIB per cápita de Perú ronda los 8.452 dólares Perú — World Bank / ILIA, el de Argentina y México ronda los 14.000 México — World Bank / ILIA. En economías así, una suscripción empresarial de asistente de código más las herramientas de seguridad que la harían defendible representan un costo que solo las grandes empresas y las filiales de multinacionales pueden absorber. El resultado es una estratificación: unos pocos adoptan con perímetro, muchos adoptan sin él, y el “acceso a la IA” que las estrategias nacionales celebran es, en buena parte, acceso a la vulnerabilidad sin acceso a la defensa.
Argentina, con un ILIA de 67.5 y el cuarto puesto regional, y México, con 68.8 en el tercero Argentina — World Bank / ILIA, figuran entre los mejor posicionados del continente. Pero los índices de preparación miden adopción, talento e infraestructura de cómputo; rara vez miden capacidad de auditoría de seguridad. Un país puede tener un buen puntaje de “preparación para la IA” y ser, al mismo tiempo, incapaz de verificar independientemente si las herramientas que adopta son seguras. La preparación medida y la preparación real divergen justamente en el punto que esta semana volvió crítico.
Aplicabilidad y alternativas: adaptar sin poder verificar
La lente de aplicabilidad suele invocarse para hablar de idiomas minorizados o marcos jurídicos locales, y con razón. Pero la inyección de prompts añade una dimensión: los asistentes de código llegan entrenados y probados contra escenarios de ataque documentados en inglés, sobre repositorios y prácticas del norte. Los vectores de ataque que aprovechan particularidades locales —comentarios en español, convenciones de código regionales, dependencias de proyectos latinoamericanos— están fuera del alcance de las pruebas de seguridad del proveedor. La herramienta se aplica a un contexto que nunca fue parte de su validación.
La lente de alternativas es donde suele residir la esperanza, y donde conviene ser más honesto. Sí existen opciones: modelos abiertos ajustados localmente, servicios públicos de cómputo compartido, acuerdos de compra colectiva entre empresas o consorcios. Un modelo abierto corriendo en infraestructura propia elimina, al menos, la dependencia de una API extranjera facturada en dólares y el envío de código sensible a servidores ajenos. Pero —y este es el matiz que no se puede esquivar— cada una de esas alternativas traslada el costo de la verificación al usuario. El modelo abierto no viene con garantías de seguridad; viene sin nadie a quién reclamar. Ajustarlo localmente significa asumir la responsabilidad de auditarlo, algo que hoy la mayoría de los equipos regionales no tienen con qué pagar, ni en dinero ni en talento. La alternativa soberana es real, pero no es gratis: cambia una dependencia por una responsabilidad, y la responsabilidad también cuesta.
Aquí es donde el discurso de la “soberanía tecnológica” necesita aterrizarse. Correr tu propio modelo no te hace seguro; te hace dueño de un problema de seguridad que antes fingías que resolvía otro. Es una posición más digna, quizás más sostenible a largo plazo, pero exige construir la capacidad de auditoría que hoy no existe. La alternativa sin esa capacidad es solo una vulnerabilidad con bandera propia.
El contraargumento honesto: ¿no es todo software así?
Un lector escéptico —del tipo correcto, escéptico también de mi argumento— podría objetar: toda herramienta poderosa es peligrosa mal usada. Un servidor mal configurado filtra datos; una base de datos con permisos laxos se vulnera; el correo electrónico fue durante décadas el principal vector de ataque y nadie propuso abandonarlo. ¿No estoy exagerando una propiedad general del software para dramatizar la IA?
La objeción es seria y merece una respuesta seria. Hay una diferencia de grado que se vuelve diferencia de clase. Un servidor mal configurado hace exactamente lo que se le configuró: la falla está en la configuración, y una configuración correcta lo vuelve seguro. Un asistente de IA vulnerable a inyección de prompts no tiene una configuración correcta que cierre la falla, porque la falla es la incapacidad constitutiva de distinguir instrucción de dato. Puedo mitigar, aislar, monitorear —construir perímetro— pero no puedo configurar el modelo para que deje de ser engañable, porque ser persuadible por texto es lo que el modelo es. Un cuchillo se guarda en un cajón; un cuchillo que a veces decide por su cuenta cortar hacia el usuario es otra categoría de objeto.
La segunda parte de la respuesta es sobre el discurso, no sobre la técnica. Del correo electrónico nadie dijo que era inteligente, autónomo y capaz de reemplazar a tu equipo. De los asistentes de IA sí se lo dice, y esa promesa es precisamente lo que induce a desplegarlos con permisos elevados sobre sistemas críticos sin el escepticismo que aplicaríamos a cualquier otro software nuevo. La mistificación no es un adorno inocente del marketing: es un factor causal del riesgo. Cuanto más se le atribuye juicio a la herramienta, menos perímetro se le construye, y más grave la traición cuando ocurre. García Canclini advirtió sobre gobernantes y sistemas que, en vez de asustarnos como los antiguos tiranos, nos piden creer Ciudadanos reemplazados por algoritmos. El asistente de IA no nos amenaza; nos pide confianza. Y esa confianza, no la capacidad técnica, es lo que un atacante realmente explota.
Concedido lo anterior, hay un matiz en la otra dirección que también hay que reconocer para no caer en el pánico. La existencia de la vulnerabilidad no significa que cada uso sea catastrófico. Un asistente de IA usado para escribir código de un proyecto sin secretos, en un entorno aislado, revisado antes de integrarse, es un riesgo perfectamente administrable. El problema no es la herramienta en sí ni su uso prudente. El problema es el uso inducido por el discurso: el despliegue masivo, sin perímetro, sobre sistemas sensibles, justificado por una urgencia manufacturada. La distinción es exactamente la de esta semana: no cuál modelo, sino con qué disciplina de entorno.
Lo que la región debería construir antes de comprar
La lente de anticipación cierra el argumento con una agenda, y conviene que sea concreta y no un llamado piadoso a “regular la IA”. Lo que la evidencia de esta semana sugiere no es prohibir ni abrazar, sino invertir el orden de las operaciones. Hoy la región compra primero y verifica —si acaso— después. La disciplina que el momento exige es verificar antes de comprar, y para eso hacen falta cosas que no existen todavía.
Primero, nodos independientes de auditoría: equipos técnicos, públicos o consorciados, capaces de someter una herramienta de IA a pruebas de seguridad —incluidas pruebas de inyección de prompts en escenarios locales— y publicar los resultados en un lenguaje que un comprador no técnico pueda usar para decidir. Que un ministerio, una cámara empresarial o una universidad pueda decir “este asistente falló en tal prueba” con la misma autoridad con que hoy un laboratorio de punta dice “nuestro modelo es superior”. Segundo, cláusulas de responsabilidad exigidas a los proveedores: contratos que trasladen parte del costo de una filtración causada por inyección de prompts de vuelta a quien vendió la herramienta como segura. Mientras el riesgo sea íntegramente del comprador, el vendedor no tiene incentivo para invertir en el perímetro que dice no necesitar. Tercero, equipos locales capaces de leer un informe de seguridad sin depender del vendedor. Peirano insistió en que la única defensa real contra un sistema que el enemigo conoce es que el usuario también lo conozca El enemigo conoce el sistema: manipulación de ideas, personas e influencias después de la economía de la atención. La alfabetización en seguridad de IA no es un adorno: es la condición para que la soberanía tecnológica signifique algo más que una bandera sobre una vulnerabilidad.
Nada de esto es gratis, y esa es la incomodidad final. La región enfrenta una elección que el discurso de adopción le oculta: puede pagar el costo de la verificación por adelantado, construyendo la capacidad de auditar antes de desplegar, o puede pagarlo después, en filtraciones, incidentes y dependencia profundizada. La primera opción es cara y lenta y no genera titulares. La segunda es la que estamos eligiendo por defecto, simplemente por no elegir.
Preguntas abiertas
Quedan tensiones que este ensayo no resuelve y que la región tendrá que habitar. Si la falla de la inyección de prompts es constitutiva del paradigma actual de modelos de lenguaje, ¿tiene sentido siquiera hablar de “asistentes de código seguros”, o deberíamos aceptar que estas herramientas nunca operarán sin supervisión y ajustar todo el discurso —y todos los presupuestos— a esa realidad? ¿Cuánto de la productividad prometida sobrevive cuando se le suma el costo real del perímetro que la vuelve defendible? Si la respuesta es “poco”, entonces buena parte de esos 37 mil millones de dólares está comprando una ilusión de eficiencia que la seguridad, correctamente contabilizada, cancela.
Y una pregunta más difícil, más política. La brecha entre quienes pueden costear el perímetro y quienes solo pueden costear la herramienta va a producir, dentro de América Latina, su propia estratificación: empresas y Estados que adoptan IA de manera defendible, y una mayoría que adopta la misma tecnología como pura exposición. ¿Vamos a permitir que la seguridad de la IA sea, como tantas cosas, un privilegio de divisa? ¿O existe la posibilidad de construir bienes comunes de verificación —nodos de auditoría compartidos, informes públicos, capacidad técnica regional— que democraticen no el acceso a la herramienta, que ya está, sino el acceso a la confianza, que es lo que verdaderamente escasea?
El asistente que no puede decir quién le habla es, al final, una metáfora incómodamente precisa de la posición de la región frente a esta ola de herramientas. Nos llegan cartas deslizadas por debajo de la puerta —lanzamientos, promesas, urgencias— y el reflejo institucional ha sido leerlas en voz alta y obedecer. La disciplina que falta no es técnica antes que política: es la capacidad, y la decisión, de preguntar primero quién firma.