Si le pides a un agente de código que arregle un bug de autenticación, desde tu punto de vista pasará muy poca cosa. Escribes una frase, esperas unos segundos y recibes una respuesta.
La petición que recibe el modelo puede tener un aspecto muy distinto.
Antes de la inferencia, el agente puede leer la implementación de la autenticación y varios archivos relacionados, inspeccionar un log de errores, recuperar información de paquetes e incluir partes relevantes de su conversación anterior. Junto a todo eso puede ir un system prompt, instrucciones añadidas por tu organización y resultados devueltos por herramientas que el agente ya ha usado.
Cuando el modelo se ejecuta, la frase que escribiste puede ser la parte menos interesante de la petición.
Esto no es exclusivo de los agentes de código. Un asistente de soporte hace lo mismo: combina una pregunta con el historial del cliente y la documentación interna. Un sistema de conocimiento recupera fragmentos de documentos de la empresa. Un agente consulta una API interna y usa el resultado como contexto para su siguiente decisión.
Todo esto es útil. De hecho, en gran medida es el objetivo, y es por lo que los LLM nos dan tan buenos resultados.
Una IA útil necesita contexto. Puede tenerlo a mano, en tus documentos, o tener que salir a buscarlo fuera.
¿Qué pasa, entonces, con ese contexto cuando el modelo ya ha reunido toda la información pero necesita pensar? ¿A dónde va?
Imagina tu agente de código corriendo en tu portátil. El repositorio está ahí. Los logs que ha inspeccionado están ahí. La empresa controla ese entorno.
Entonces el agente reúne todo lo que considera relevante y envía una petición de inferencia a un modelo externo.
En algún punto entre esos dos sistemas ha cambiado algo importante. Información gobernada por tu infraestructura ahora se está procesando dentro de una infraestructura gobernada, al menos en parte, por otro.
Esa línea, de la que casi nunca somos conscientes, importa.
Es el límite de confianza.
El límite de confianza que no ves
Los límites de confianza no son nuevos. Las empresas los cruzan constantemente cuando suben código a GitHub, meten información de clientes en Salesforce, despliegan infraestructura en AWS o cobran a través de Stripe. El software moderno se construye sobre la delegación, y usar infraestructura operada por otra empresa no es en sí mismo un fallo de seguridad.
Lo que importa es entender qué has delegado y en qué condiciones.
La IA hace que eso sea más difícil de ver porque el límite suele quedar escondido detrás de una aplicación.
Cuando alguien sube un archivo directamente a un servicio externo, el movimiento de la información es evidente. Cuando un agente lee doce archivos de forma autónoma, selecciona fragmentos de cuatro de ellos, los combina con resultados de herramientas y envía el contexto resultante a un modelo, lo es mucho menos. Y lo hace de una forma tan sencilla y sin fricción que a veces ni te lo planteas.
La interfaz puede permanecer por completo dentro de tu producto mientras el contexto completo cruza varios límites de infraestructura por detrás.
Esta distinción importa porque el prompt visible no es necesariamente el límite de los datos.
El límite real rodea el contexto de inferencia completo.
Sigue el contexto como si fueran migas de pan
Una forma útil de entender un sistema de IA es, por tanto, dejar de mirar la caja de chat y seguir el contexto.
¿Dónde empieza?
¿Qué puede recuperar la aplicación?
¿Qué selecciona?
¿Qué se reúne antes de la inferencia?
¿Qué cruza a otro entorno?
¿Y qué se queda allí después?
Piensa en un agente de soporte interno. El empleado puede preguntar:
¿Por qué este cliente no puede renovar su suscripción?
Para responder, el sistema podría recuperar los datos de la cuenta del cliente, su estado de facturación, conversaciones de soporte anteriores y documentación interna antes de llamar a un modelo.
El usuario solo envía una frase.
La petición de inferencia contiene una pequeña representación de la empresa alrededor de esa frase.
Así es como funcionan cada vez más las aplicaciones de IA. El contexto se reúne dinámicamente a partir de los sistemas que las rodean, lo que significa que la superficie de datos de IA de una empresa ya no se limita a la información que los empleados deciden compartir de forma consciente.
La determina, en parte, la arquitectura.
Qué pasa al otro lado: no entrenar, Zero Data Retention e inferencia privada
Entender qué cruza el límite es solo la mitad del problema. ¿Qué pasa una vez lo ha cruzado?
Tu prompt con todo el contexto llega al modelo. El modelo responde. Y ahora, ¿qué pasa con todos esos datos que se han enviado a otra infraestructura?
Aquí es donde hay que separar varias garantías que a menudo se tratan como intercambiables.
- Los datos no se usan para entrenar modelos. Eso responde a una pregunta importante sobre el entrenamiento, pero no te dice si una petición se retiene temporalmente, si el contenido entra en sistemas operativos o en qué circunstancias puede acceder a él el personal. [1]
- Zero Data Retention es distinto. Cambia lo que persiste después del procesamiento, según el producto y la configuración concretos. Normalmente sigue existiendo algún registro mínimo por seguridad, pero es la garantía que más reduce lo que queda de tu petición al otro lado. [2]
- Inferencia privada. La inferencia dedicada o controlada por el cliente cambia otra parte de la arquitectura: dónde se procesa, quién opera la infraestructura y qué controles siguen bajo la autoridad del cliente. Junto a Zero Data Retention, es la combinación que mantiene tu información dentro de un perímetro que tú eliges. Es la arquitectura con la que está diseñada la plataforma de Helmcode .
No entrenar, Zero Data Retention e inferencia controlada por el cliente describen partes distintas del límite de confianza.
Por eso etiquetas como "IA empresarial" o "IA privada" son menos útiles que entender la arquitectura que hay detrás. La garantía adecuada depende de la carga de trabajo.
Empieza por la carga de trabajo
Los equipos empiezan de forma natural preguntándose qué modelo rinde mejor. Para un experimento, normalmente basta.
Pero cuando un sistema de IA empieza a trabajar con información de la empresa, hay una pregunta que conviene responder antes de mirar el leaderboard:
¿Qué va a poder ver este sistema, y hasta dónde estamos dispuestos a dejar que llegue esa información?
Un asistente de contenido público y un agente con acceso a código fuente sin publicar no deberían heredar necesariamente la misma decisión de infraestructura solo porque ambos necesitan un LLM.
Define primero el límite aceptable. Después, dentro de ese límite, elige el mejor modelo para el trabajo.
Capacidad, latencia y coste siguen siendo importantes. Simplemente operan dentro de unas restricciones que la empresa ha elegido de forma deliberada.
A medida que los agentes acceden a más herramientas, repositorios, bases de datos y sistemas internos, esta distinción será más importante. La pregunta que se hacen las empresas ahora mismo es qué parte de mi información llega al modelo cuando lo llamo.
Esa pregunta ya no se responde leyendo el prompt. Se responde mirando la arquitectura.
Para ampliar: Soberanía de la IA: ¿quién controla la inteligencia de tu empresa? recoge la otra mitad de esta conversación. Dónde se ejecuta tu inteligencia, qué estás delegando exactamente y cómo conservar la capacidad de decidir de otra manera cuando importe.
Notas
Las llamadas [1] y [2] del texto corresponden a estas fuentes, consultadas el 17 de septiembre de 2026.
[1] OpenAI indica que los datos enviados a su API no se utilizan para entrenar ni mejorar sus modelos salvo que el cliente opte explícitamente por compartirlos, y que los logs de detección de abuso se generan para todo uso de la API y se conservan hasta 30 días, salvo que la ley exija más: Your data, OpenAI API .
[2] Anthropic ofrece retención cero de datos para la Claude API y declara que el contenido de la conversación no se retiene por defecto, pero la cobertura se define funcionalidad a funcionalidad: las que almacenan trabajos, ficheros o estado de contenedor quedan fuera del acuerdo para esos datos concretos: API and data retention .
