Si trabajás en un banco, una fintech, una empresa de salud o un organismo público, seguramente ya conocés la regla: no se pega código propietario en ChatGPT, Claude ni Copilot, ni siquiera para preguntar "¿esto es seguro?". La regla tiene buenos motivos. Pero también significa que los equipos que más tienen para perder con una vulnerabilidad son los que quedan afuera de la revisión de código con IA. Una IA self-hosted para seguridad de código es la forma de cerrar esa brecha sin romper la regla.
En esta guía vemos por qué existe la restricción, cuáles son los riesgos reales, qué opciones hay para desplegar una IA privada, qué evaluar en un proveedor y por qué un log auditable y a prueba de manipulación de cada llamada a la IA es la pieza que convierte un "confiá en nosotros" en una prueba.
Por qué los equipos regulados no pueden pegar código en herramientas de IA públicas
El código fuente no es solo texto. Tiene el diseño de tu modelo de autorización, los nombres de servicios internos, esquemas de base de datos, a veces fixtures de test con datos que parecen de clientes reales y, demasiado seguido, credenciales. Para una empresa regulada además es propiedad intelectual y, muchas veces, información alcanzada por confidencialidad contractual o legal.
Cuando un dev pega un archivo en un asistente de IA genérico, pasan varias cosas que la empresa no controla:
- El código cruza el perímetro hacia un tercero que el equipo de seguridad puede no haber evaluado.
- Puede quedar retenido. Según el producto y el plan, los prompts se pueden guardar para monitoreo de abuso, debugging o funciones de historial.
- Puede usarse para entrenar. Las versiones para consumidores de algunos asistentes usan las conversaciones para mejorar los modelos salvo que el usuario lo desactive. Los planes empresariales y de API en general no lo hacen por defecto, pero eso es una cláusula de contrato que tenés que verificar, no algo para suponer.
- No queda ningún registro de tu lado. Después no podés probar qué se mandó, quién lo mandó ni a qué modelo.
Por eso muchas organizaciones reguladas bloquean estas herramientas en el proxy, o las permiten solo con un contrato empresarial aprobado. Y por eso la "IA en la sombra", devs usando cuentas personales igual, es una preocupación real.
Los riesgos concretos: retención, entrenamiento y compliance
Retención de datos
Aunque un proveedor prometa no entrenar con tus datos, puede guardar los inputs durante un período para seguridad y monitoreo de abuso. Existen acuerdos de retención cero para algunos clientes empresariales de API, pero se negocian, no vienen por defecto. Para código con secretos o datos de clientes, "guardado un tiempo en servidores de otro" ya es un incidente esperando que alguien lo clasifique.
Entrenamiento y memorización
La preocupación no es que mañana un modelo le recite tu repositorio a un desconocido. Es que, una vez que los datos entran a un pipeline de entrenamiento, perdés la capacidad de garantizar dónde terminan y no los podés borrar con certeza. Para secretos comerciales, esa pérdida de control es el problema.
Marcos de compliance
- GDPR: si el código, los logs o los fixtures tienen datos personales, mandarlos a un proveedor de IA lo convierte en encargado del tratamiento. Necesitás un acuerdo de procesamiento de datos, una base legal y, si los datos salen de la UE, un mecanismo de transferencia válido.
- HIPAA: el código fuente en sí no suele ser información de salud protegida, pero los datos de test, logs y dumps de base que viven en un repo sí pueden serlo. Compartir PHI con un proveedor exige un business associate agreement.
- SOC 2: los auditores van a preguntar cómo gestionás proveedores que tocan datos sensibles y cómo controlás y registrás los accesos. Una herramienta de IA sin evaluar y sin logs es un hallazgo.
- Secreto bancario y regulación financiera: en muchas jurisdicciones los bancos tienen deberes legales de confidencialidad sobre la información de sus clientes y reglas estrictas de tercerización para cualquier tercero que la procese. Los equipos de seguridad suelen considerar el código del core bancario dentro de ese alcance.
- Gobierno y defensa: las reglas de residencia y clasificación de datos muchas veces directamente prohíben el procesamiento en servicios extranjeros o multi-tenant.
Opciones para desplegar una IA privada para revisar código
"IA self-hosted" abarca varias arquitecturas, cada una con sus trade-offs:
| Opción | Dónde corre el modelo | A favor | En contra |
|---|---|---|---|
| LLM local on-prem | Tu propio data center o tus GPUs | Control máximo, funciona air-gapped | Hardware caro, operás y actualizás el modelo vos |
| LLM en tu VPC | Un despliegue dedicado en tu cuenta cloud | El código no sale de tu perímetro cloud, encaja con tus controles | Igual gestionás GPUs, escalado y calidad del modelo |
| Modelo propio del proveedor con inferencia efímera | El modelo del proveedor sobre infraestructura dedicada y de vida corta | Sin carga operativa, sin un proveedor de IA de terceros en el camino | Dependés de los controles del proveedor, así que necesitás pruebas |
| API de terceros con retención cero | Un proveedor de modelos frontier bajo acuerdo de no retención | Modelos generales muy potentes | El código igual sale a otra empresa; depende del contrato |
| Asistente de chat público | Servicio compartido para consumidores | Cómodo | En general no es aceptable para código regulado |
La inferencia efímera merece una mirada más de cerca. La idea es simple: se crea un entorno aislado para un escaneo, el modelo analiza el código ahí, se devuelven los resultados y el entorno se destruye. No persiste nada entre clientes y no hay un almacén de prompts de larga vida que se pueda filtrar después.
Qué evaluar antes de que una IA toque tu código
- ¿Dónde corre exactamente el modelo? ¿Tu hardware, tu cuenta cloud, la infraestructura dedicada del proveedor o una API compartida de terceros? Pedí la respuesta por escrito, incluida la región.
- ¿Qué modelo, y de quién? ¿Es un modelo propio del proveedor o un wrapper sobre OpenAI, Anthropic o Google? Un wrapper puede estar bien para muchas empresas, pero lo tenés que saber.
- ¿Qué se retiene y por cuánto tiempo? Código fuente, prompts, respuestas del modelo, hallazgos, logs. Cada uno puede tener una política distinta.
- ¿Se usa algo para entrenar? El default y el mecanismo para desactivarlo tienen que estar explícitos.
- ¿Hay un registro de auditoría de cada llamada a la IA? ¿Podés ver qué modelo procesó qué archivos, cuándo y para qué? ¿Se puede alterar el log sin que se note?
- ¿Qué tan bueno es el modelo en seguridad? La privacidad no sirve de nada si los hallazgos son ruido. Pedí resultados sobre un repo que conozcas bien y mirá los falsos positivos y si cada hallazgo apunta a un archivo y una línea concretos.
- ¿Qué pasa cuando se usa un modelo externo? Algunas funciones, como generar un fix, pueden usar un modelo frontier. Eso tiene que ser opt-in, explícito y quedar registrado.
Cómo un modelo de seguridad self-hosted analiza código sin que salga de la infraestructura controlada
Un modelo de seguridad self-hosted hace más o menos lo mismo que un revisor, pero dentro de un perímetro sobre el que podés razonar:
- Trae el repositorio con acceso de solo lectura y acotado, a un entorno aislado.
- Arma contexto: rutas, handlers, modelos de datos, manifiestos de dependencias, workflows de CI, infraestructura como código.
- Razona sobre caminos de ataque: sigue el input no confiable entre archivos, verifica que cada operación sensible tenga su chequeo de autorización, busca inyecciones, deserialización insegura, secretos y malas configuraciones. Es el mismo razonamiento que hace útil la revisión de código con IA, y complementa el análisis estático de código clásico; en SAST vs DAST vemos cómo encajan las capas.
- Valida y prioriza los hallazgos por explotabilidad, no por coincidencias de patrones.
- Registra cada llamada al modelo en un log de auditoría y después destruye el entorno.
La propiedad clave es que ningún paso del análisis requiere mandar el código a un proveedor de IA genérico de terceros. Eso es lo que hace que un escáner de vulnerabilidades con IA sea usable en entornos donde los asistentes públicos están prohibidos.
El log de auditoría es la prueba
"No mandamos tu código a ningún lado" es una afirmación. Un log de auditoría auditable y a prueba de manipulación es evidencia. La técnica estándar es una cadena de hashes: cada entrada del log incluye un hash criptográfico de la anterior, así el log forma una cadena que no se puede editar en el medio sin romper todos los eslabones posteriores.
{
"seq": 1042,
"timestamp": "2026-09-23T14:02:11Z",
"scan_id": "scn_8f3a",
"purpose": "vulnerability_analysis",
"model": "self-hosted-security-model",
"provider": "self-hosted",
"input_sha256": "9c1e...a7",
"output_sha256": "44b0...1d",
"prev_hash": "e3d9...52",
"entry_hash": "sha256(prev_hash + canonical_json(entry))"
}Con un log así podés responder las preguntas que te va a hacer un auditor o el equipo de seguridad de un cliente:
- ¿Qué modelo procesó nuestro código? Cada llamada indica el modelo y el proveedor.
- ¿Lo vio alguna IA de terceros? Filtrás por proveedor. Si se usó un modelo externo, hay una entrada para eso, con el consentimiento que lo autorizó.
- ¿Se alteró el log? Recalculás la cadena. Una sola entrada editada o borrada rompe todos los hashes que siguen.
- ¿Qué se mandó exactamente? Los hashes de inputs y outputs te permiten verificar contenido sin que el log guarde el código.
Verificarlo es barato. Cualquiera puede recalcular la cadena:
prev = GENESIS
for entry in log:
expected = sha256(prev + canonical_json(entry.without_hash))
assert entry.prev_hash == prev
assert entry.entry_hash == expected
prev = entry.entry_hashPara garantías más fuertes, anclá cada tanto el último hash en un lugar que el proveedor no pueda reescribir, por ejemplo exportándolo a tu propio storage o a tu SIEM.
Cómo lo encara Nurbak
Como ejemplo concreto: Nurbak se conecta a GitHub y escanea un repositorio con su propio modelo de IA self-hosted que corre sobre infraestructura efímera, así que el análisis no manda tu código a OpenAI ni a Anthropic. Cada llamada a la IA queda registrada en un registro de auditoría auditable y encadenado por hashes. El escaneo reporta vulnerabilidades explotables con archivo y línea, cruza las dependencias contra CVEs conocidos, marca malas configuraciones de GitHub Actions, Docker, Terraform y Kubernetes y secretos en el historial de git, y te da un score de seguridad de 0 a 100 con explicaciones en lenguaje claro.
Hay un solo punto donde participa un modelo externo, y es opt-in: Nurbak puede abrir un pull request con el fix y un test de regresión de seguridad, y ese fix se genera con Claude solo después de que el usuario da su consentimiento explícito. Ese consentimiento y la llamada quedan en el mismo registro de auditoría, así que queda asentado exactamente cuándo el código salió del perímetro self-hosted y por qué. El escaneo gratis te muestra completos los 3 hallazgos más importantes; los planes pagos arrancan en USD 79 por mes. Podés ver cómo funciona en la página del escáner de vulnerabilidades con IA.
Una política práctica para la IA en tu pipeline de código
- Clasificá los repositorios. No todos son igual de sensibles. Un SDK público y el core bancario merecen reglas distintas.
- Por defecto, análisis self-hosted para los repos sensibles; modelos externos solo por funcionalidad y con consentimiento explícito.
- Exigí un registro de auditoría de cada llamada a la IA, de cualquier proveedor, y exportalo a tus propios sistemas.
- Escaneá secretos primero. Una key en el historial de git es un problema sin importar qué modelo la lea.
- Mantené a las personas en el circuito. Los hallazgos y los fixes de la IA pasan por la revisión normal de pull requests, como cualquier otro cambio.
- Revisá la política a medida que cambian los modelos y los contratos. Lo que hoy es cierto sobre la retención de un proveedor puede no serlo el año que viene.
Esto encaja naturalmente en un programa de DevSecOps: los mismos gates en los pull requests, ahora con un revisor de IA que sí tenés permitido usar. Los hallazgos se mapean bien a categorías como las del OWASP Top 10 2025, y para lo que la IA no puede juzgar sigue estando el pentesting.
En resumen
Los equipos regulados tienen razón en no pegar código en asistentes de IA públicos. La respuesta no es renunciar a la revisión de seguridad con IA, sino llevar el modelo al código: on-prem, en tu VPC o en el modelo propio de un proveedor corriendo sobre infraestructura efímera, sin una IA de terceros en el camino por defecto. Y después exigí pruebas, no promesas: un log a prueba de manipulación de cada llamada a la IA, incluidas las pocas, con consentimiento, que sí usan un modelo externo. Si un proveedor no te puede mostrar ese log, asumí que tu código va a algún lugar que no podés ver.