De Riesgo a Responsabilidad: Ahmad Shadid Sobre la Creación de Flujos de Trabajo de Desarrollo Asistido por IA Seguros

En Resumen

“El codificado de Vibe” se está proliferando, pero los expertos advierten que las herramientas tradicionales plantean riesgos de seguridad y confidencialidad para el código empresarial, destacando la necesidad de soluciones encriptadas y respaldadas por hardware de “IA confidencial”.

En los últimos meses, el “codificado de Vibe”—un flujo de trabajo centrado en IA donde los desarrolladores aprovechan grandes modelos de lenguaje (LLMs) y herramientas agenticas para generar y perfeccionar software—ha ganado tracción. Al mismo tiempo, múltiples informes de la industria han destacado que, si bien el código generado por IA ofrece rapidez y conveniencia, a menudo introduce riesgos graves de seguridad y cadena de suministro.

La investigación de Veracode encontró que casi la mitad del código producido por LLMs contiene vulnerabilidades críticas, con modelos de IA que frecuentemente generan implementaciones inseguras y pasan por alto problemas como fallos de inyección o autenticación débil, a menos que se les indique explícitamente. Un estudio académico reciente también señaló que las “habilidades” modulares de IA en sistemas basados en agentes pueden tener vulnerabilidades que podrían permitir escalada de privilegios o exponer las cadenas de suministro de software.

Más allá de las salidas inseguras, existe un riesgo sistémico de confidencialidad que a menudo se pasa por alto. Los asistentes de codificación de IA actuales procesan código interno sensible y propiedad intelectual en entornos compartidos en la nube, donde los proveedores u operadores pueden acceder a los datos durante la inferencia. Esto genera preocupaciones sobre la exposición a escala del código de producción propietario, lo cual es un problema considerable para desarrolladores individuales y grandes empresas.

¿Qué sucede con el código empresarial sensible en los asistentes de codificación de IA y por qué es arriesgado?

La mayoría de las herramientas de codificación actuales solo pueden proteger los datos hasta cierto punto. El código empresarial suele estar encriptado mientras se envía a los servidores del proveedor, generalmente mediante TLS. Pero una vez que el código llega a esos servidores, se descifra en la memoria para que el modelo pueda leerlo y procesarlo. En ese momento, detalles sensibles como lógica propietaria, APIs internas y detalles de seguridad se presentan en texto plano en el sistema. Y ahí radica el riesgo.

El código puede pasar por registros internos, memoria temporal o sistemas de depuración que son difíciles de ver o auditar por los clientes mientras está descifrado. Incluso si un proveedor garantiza que no se guardan datos, la exposición aún ocurre durante el procesamiento, y esa ventana corta es suficiente para crear puntos ciegos. Para las empresas, esto crea un riesgo potencial que expone código sensible a un uso indebido sin control propietario.

¿Por qué crees que las herramientas de codificación de IA mainstream son fundamentalmente inseguras para el desarrollo empresarial?

La mayoría de las herramientas de IA de codificación más populares no están diseñadas para modelos de riesgo empresarial; solo optimizan la velocidad y conveniencia porque están entrenadas en gran medida en repositorios públicos que contienen vulnerabilidades conocidas, patrones obsoletos y configuraciones inseguras. Como resultado, el código que producen suele presentar vulnerabilidades a menos que pase por una revisión y corrección exhaustivas.

Más importante aún, estas herramientas operan sin estructuras de gobernanza formal, por lo que no aplican realmente estándares internos de seguridad en las primeras fases, y esto crea una desconexión entre cómo se programa el software y cómo se audita o protege posteriormente. Esto eventualmente hace que los equipos se acostumbren a trabajar con salidas que apenas entienden, mientras la seguridad se retrasa silenciosamente. Esta combinación de falta de transparencia e implicaciones técnicas hace casi imposible el soporte estándar para organizaciones que operan en dominios donde la seguridad es prioritaria.

Si los proveedores no almacenan ni entrenan con el código del cliente, ¿por qué no es suficiente eso y qué garantías técnicas se necesitan?

Asegurar la política es muy diferente de las garantías técnicas. Los datos del usuario todavía se descifran y procesan durante el cálculo, incluso cuando los proveedores aseguran que no habrá retención. Los registros temporales durante procesos de depuración aún pueden crear caminos de filtración que las políticas no pueden prevenir ni demostrar para garantizar la seguridad. Desde una perspectiva de riesgo, confiar sin verificación no es suficiente.

Las empresas deberían centrarse más en promesas que puedan establecerse a nivel de infraestructura. Esto incluye entornos de computación confidencial donde el código no solo esté encriptado durante la transferencia, sino también mientras se usa. Un ejemplo muy bueno es el entorno de ejecución confiable respaldado por hardware, que crea un entorno encriptado donde incluso el operador de infraestructura no puede acceder al código sensible. El modelo procesa los datos en este entorno seguro, y la attestación remota permite a las empresas verificar criptográficamente que estas medidas de seguridad están activas.

Estos mecanismos deberían ser un requisito básico, porque convierten la privacidad en una propiedad medible y no solo en una promesa.

¿Ejecutar IA en local o en una nube privada resuelve completamente los riesgos de confidencialidad?

Ejecutar IA en una nube privada ayuda a reducir algunos riesgos, pero no resuelve el problema. Los datos siguen siendo muy visibles y vulnerables cuando se procesan, a menos que se implementen protecciones adicionales. En consecuencia, el acceso interno, una configuración deficiente y el movimiento dentro de la red aún pueden provocar filtraciones.

El comportamiento del modelo es otra preocupación. Aunque los sistemas privados registran entradas o almacenan datos para pruebas, sin un aislamiento fuerte, estos riesgos permanecen. Los equipos de negocio aún necesitan procesamiento encriptado. Implementar control de acceso basado en hardware y establecer límites claros en el uso de datos son esenciales para proteger los datos de forma segura. De lo contrario, solo se evita el riesgo, pero no se resuelve.

¿Qué significa realmente “IA confidencial” para las herramientas de codificación?

La IA confidencial se refiere a sistemas que gestionan la seguridad de los datos durante el cálculo. Permite que los datos se procesen en un enclave aislado, como entornos de ejecución confiables respaldados por hardware, pero en texto claro para que el modelo pueda trabajar con ellos. La aplicación de la encriptación en el hardware garantiza que sea inaccesible para el operador de la plataforma, el sistema operativo anfitrión o cualquier parte externa, además de ofrecer una privacidad criptográficamente verificable, sin afectar la capacidad funcional de la IA.

Esto cambia completamente el modelo de confianza para las plataformas de codificación, ya que permite a los desarrolladores usar IA sin enviar lógica propietaria a sistemas compartidos o públicos. El proceso también mejora la responsabilidad clara porque los límites de acceso se construyen mediante hardware en lugar de políticas. Algunas tecnologías van más allá combinando cálculo encriptado con seguimiento histórico, para que las salidas puedan verificarse sin revelar las entradas.

Aunque el término suena abstracto, la implicación es simple: la asistencia de IA ya no requiere que las empresas sacrifiquen confidencialidad por efectividad.

¿Cuáles son las compensaciones o limitaciones de usar IA confidencial en la actualidad?

La mayor compensación hoy en día es la velocidad. Los sistemas de IA aislados en entornos de ejecución confiables pueden experimentar algunos retrasos en comparación con estructuras no protegidas, simplemente por la encriptación de memoria a nivel de hardware y la verificación de attestación. La buena noticia es que el hardware más nuevo está cerrando esta brecha con el tiempo.

Además, se requiere más trabajo de configuración y planificación adecuada, ya que los sistemas deben operar en entornos más restringidos. También hay que considerar el costo. La IA confidencial a menudo necesita hardware especial — chips especializados como NVIDIA H100 y H200, por ejemplo — y herramientas, lo que puede aumentar los gastos iniciales. Pero los costos deben equilibrarse con el daño potencial que podría derivarse de filtraciones de código o incumplimientos regulatorios.

La IA confidencial aún no es un requisito universal del sistema, por lo que los equipos deberían usarla donde la privacidad y la responsabilidad sean más importantes. Muchos de estos límites se resolverán.

¿Esperas que los reguladores o estándares pronto exijan que las herramientas de IA mantengan todos los datos encriptados durante el procesamiento?

Los marcos regulatorios como la Ley de IA de la UE y el Marco de Gestión de Riesgos de IA del NIST de EE. UU. ya enfatizan fuertemente la gestión de riesgos, la protección de datos y la responsabilidad para sistemas de IA de alto impacto. A medida que estos marcos se desarrollen, los sistemas que exponen datos sensibles por diseño serán cada vez más difíciles de justificar bajo las expectativas de gobernanza establecidas.

Los grupos de estándares también están sentando las bases estableciendo reglas más claras sobre cómo la IA debe manejar los datos durante su uso. Estas reglas pueden implementarse a diferentes velocidades en distintas regiones. Sin embargo, las empresas deben esperar mayor presión sobre los sistemas que procesan datos en texto plano. De esta forma, la IA confidencial tiene menos que ver con adivinar el futuro y más con alinearse con la dirección que ya toman las regulaciones.

¿Cómo se ve actualmente la “codificación responsable de Vibe” para desarrolladores y líderes de TI?

La codificación responsable de Vibe simplemente consiste en ser responsables de cada línea de código, desde revisar las sugerencias de IA hasta validar las implicaciones de seguridad, así como considerar cada caso límite en cada programa. Para las organizaciones, esto requiere una definición clara de políticas sobre la aprobación de herramientas específicas y caminos seguros para código sensible, asegurando que los equipos entiendan tanto las fortalezas como los límites de la asistencia de IA.

Para los reguladores y líderes de la industria, la tarea consiste en diseñar reglas claras que permitan a los equipos identificar fácilmente qué herramientas están permitidas y dónde pueden usarse. Los datos sensibles solo deben ingresarse en sistemas que cumplan con requisitos de privacidad y cumplimiento, además de capacitar a los operadores y usuarios para entender el poder de la IA y sus limitaciones. La IA ahorra esfuerzo y tiempo cuando se usa bien, pero también conlleva riesgos costosos si se usa de manera imprudente.

De cara al futuro, ¿cómo visualizas la evolución de los asistentes de codificación de IA en cuanto a seguridad?

Las herramientas de codificación de IA evolucionarán de ser meramente recomendaciones a verificar el código a medida que se escribe, asegurando que cumpla con reglas, bibliotecas autorizadas y restricciones de seguridad en tiempo real.

La seguridad, en la medida en que importa, también se integrará más profundamente en cómo funcionan estas herramientas, mediante el diseño de ejecución encriptada y registros claros de decisiones como funciones normales. Con el tiempo, esto transformará a los asistentes de IA de riesgos en herramientas de apoyo para un desarrollo seguro. Los mejores sistemas serán aquellos que combinen velocidad con control. Y la confianza se determinará por cómo funcionan las herramientas, no solo por la promesa de los creadores.