Programar con un asistente de IA dejó de ser una rareza. Muchos escribimos código con Claude, ChatGPT, Copilot o Cursor todos los días, y eso agregó un canal nuevo por el que sale información: cada vez que pegas código en un prompt, ese código sale de tu máquina hacia un servicio de un tercero. Es exactamente el mismo tipo de fuga que vimos con los logs en la parte 4, solo que ahora la abres tú al pegar.
Esta es la serie de fundamentos de seguridad, y este cierre trata un tema que hace dos años no existía en esta lista.
El modelo mental correcto
La regla que lo simplifica todo: el asistente de IA es un tercero, sea cual sea. No importa lo útil que sea ni lo integrado que esté en tu editor. En el momento en que un servicio en la nube procesa tu texto, ese texto salió de tu control y viajó a una infraestructura que no administras.
Eso no significa no usar IA. Significa tratar el prompt como lo que es: un canal por el que la información sale de tu máquina. La pregunta antes de pegar algo no es “¿esto ayuda al asistente a entenderme?”, sino “¿me importa que esto salga de mi computadora?”.
Lo que nunca va al prompt
Hay una lista corta que no debe pegarse en un asistente, esté en la nube o no:
- Secretos y credenciales. Claves de API, tokens, contraseñas, claves privadas. Un secreto pegado en un chat es un secreto filtrado, con el agravante de que ya no controlas dónde queda registrado.
- El contenido de tu
.envo de tus archivos de configuración con valores reales. Es el descuido más común: pegas un archivo entero para que la IA lo revise, sin darte cuenta de que lleva las claves dentro. - Certificados y perfiles de aprovisionamiento. Tu certificado de firma y tus claves de distribución son la identidad de tu app. No tienen ninguna razón para estar en un prompt.
- Datos personales de usuarios reales. Correos, nombres, ubicaciones, cualquier registro de producción. Si pegas un JSON de respuesta para depurar, revisa que no traiga datos de una persona real.
Si un secreto llegó a tocar un prompt, trátalo como comprometido y rótalo, igual que si hubiera tocado el historial de git. Borrar el mensaje no deshace que ya se transmitió.
Cómo compartir código sin filtrar
La mayoría de las veces no necesitas pegar el secreto para que el asistente te ayude. Necesitas la estructura, no el valor. Antes de pegar, redacta:
// En vez de esto:
let apiKey = "sk_live_9f2a8c...b41"
let baseURL = "https://api.cliente-real.com"
// Pega esto:
let apiKey = "<API_KEY>"
let baseURL = "https://api.example.com"La IA razona igual de bien con un marcador que con el valor real, porque lo que le importa es la forma del código, no el contenido del secreto. El mismo principio aplica a los datos: si necesitas ayuda con un parser, arma un ejemplo mínimo con datos inventados en lugar de pegar la respuesta real de tu servidor.
Cuando reportes un error, ten el mismo cuidado con lo que copias. Un stack trace o un log pegado directo puede llevar un token o una ruta con información sensible, justo lo que vimos en la parte 4. Léelo antes de pegarlo.
Saber a dónde van tus datos
No todos los asistentes tratan tus datos igual, y la diferencia importa.
Un asistente en la nube procesa tu texto en servidores remotos. Lo que pasa después depende de la configuración y del plan: los niveles empresariales suelen ofrecer retención cero o limitada y la garantía de que tu contenido no se usa para entrenar modelos, mientras que los planes de consumidor pueden tener políticas distintas. No lo asumas: revisa los ajustes de uso de datos y retención de cada herramienta que uses, y actívalos donde corresponda.
Para código de verdad sensible, existe la opción de no mandar nada a la nube. Modelos locales corriendo con Ollama o LM Studio en tu propio Mac con Apple Silicon procesan todo en el dispositivo; nada sale de tu máquina. Rinden menos que los modelos grandes de la nube, pero para trabajar sobre código con restricciones fuertes de confidencialidad, esa diferencia se compensa con que los datos no viajan.
Si trabajas en un entorno regulado o bajo un acuerdo de confidencialidad, esto deja de ser preferencia y pasa a ser obligación: puede que cierto código o ciertos datos simplemente no puedan salir de tu infraestructura. Conoce esa línea antes de pegar.
No confíes a ciegas en el código generado
Hay un segundo riesgo, menos obvio que la fuga: el código que la IA te devuelve puede tener problemas de seguridad. Un asistente puede sugerirte con toda naturalidad una clave hardcodeada, criptografía débil, una excepción de ATS que abre el tráfico en claro, o una consulta a base de datos vulnerable a inyección. No lo hace por malicia; genera lo más probable, y en internet hay mucho código inseguro.
Todo lo que vimos en esta serie es tu lista de verificación para revisar código generado. Si el asistente te propone guardar un token, ¿lo manda al Keychain o a UserDefaults? Si te arma una llamada de red, ¿respeta TLS o desactiva la validación “para que funcione”? El código generado se revisa con el mismo ojo crítico que el de cualquier otra fuente, con más razón cuando toca seguridad.
Un caso concreto y creciente: las dependencias inventadas. A veces la IA sugiere un paquete que suena real pero no existe, o que existe pero no es el que crees. Antes de agregar una dependencia que te recomendó un asistente, verifica que sea real, oficial y mantenida. Instalar a ciegas lo que sugiere un prompt es una vía de entrada para código malicioso.
Los asistentes que leen tu repo
Las herramientas agénticas integradas en el editor, como Cursor o los asistentes que trabajan sobre todo el proyecto, agregan un matiz: pueden enviar más contexto del que crees. No solo el archivo abierto, a veces fragmentos de todo el repositorio. Vale la pena saber qué archivos entran en ese contexto y mantener fuera de su alcance lo que no debe salir, con la misma disciplina de .gitignore que usas para no filtrar secretos a git.
Y como estas herramientas también leen contenido externo (documentación, issues, dependencias), heredan el riesgo de que ese contenido lleve instrucciones ocultas dirigidas al asistente. No es paranoia teórica: es la razón para revisar lo que un agente propone antes de dejarlo actuar sobre tu proyecto, en lugar de aceptar cambios en automático.
Lo que llevamos
- El asistente de IA es un tercero; pegar algo en un prompt es sacarlo de tu máquina.
- Nunca compartas secretos, credenciales, certificados ni datos de usuarios reales; si un secreto tocó un prompt, rótalo.
- Comparte la estructura, no el valor: redacta con marcadores y usa datos inventados para los ejemplos.
- Conoce a dónde van tus datos, activa retención cero y sin entrenamiento donde puedas, y usa modelos locales para lo confidencial.
- Revisa el código generado con esta misma serie como checklist, y verifica toda dependencia que te sugieran.
Cierre del bloque de fundamentos
Con esto cierra la primera línea de la serie. Un dev iOS que tiene resueltos estos cinco temas (dónde guardar secretos, cómo cifrar archivos, qué hacer con las claves de API, cómo no filtrar por los logs, y cómo trabajar con IA sin abrir fugas) ya cubre la mayoría de los errores de seguridad que aparecen en una auditoría básica.
Los fundamentos son la base, no el techo. Las siguientes líneas de la serie entran en autenticación e identidad (biometría, passkeys, manejo de tokens), seguridad de red (TLS, certificate pinning, App Attest), privacidad y cumplimiento (privacy manifests, required reason APIs), y hardening (Secure Enclave, CryptoKit). Cada una sobre el mismo principio: proteger al usuario sin depender de que nadie mire.
Fuentes: Security (Apple) · Ollama · LM Studio