“Me pasé el fin de semana quemando tokens de Claude”, dijo el moderador. “Es más divertido que salir con amigos”. Se rió. Los líderes de seguridad en el panel también rieron, quizás un poco nerviosos. Entienden el atractivo de usar IA para construir automatizaciones y aplicaciones. También saben lo que sucede cuando ese mismo impulso se extiende por una organización sin barreras de protección.

Fue uno de los temas definitorios de Workflow, un evento virtual en vivo organizado por la plataforma de automatización inteligente Tines. El moderador, Andrew Steele, socio de Activant Capital, ha pasado una década invirtiendo en IA empresarial y sabe exactamente dónde termina la experimentación personal y comienza el riesgo laboral. Desafortunadamente para los líderes de TI y seguridad, muchos empleados no lo saben.

El auge del código salvaje

La proliferación de código no es un concepto nuevo. Pero en 2026, se está desbocando. Los equipos de seguridad y TI hablan del código como un jardinero habla de las malas hierbas: se extiende rápido y amenaza con abrumar todo a su alrededor. Un informe de RedAccess cuantifica el problema: al escanear plataformas de codificación "vibe" como Lovable, Base44 y Netlify, encontraron 380.000 activos de acceso público (aplicaciones, bases de datos e infraestructura relacionada) construidos fuera de cualquier revisión de seguridad, con aproximadamente 5.000 que contienen información corporativa sensible.

Proviene de muchas fuentes: funciones de IA integradas en herramientas SaaS aprobadas que se activan sin revisión de TI, scripts y automatizaciones construidos fuera de entornos aprobados, agentes creados por equipos individuales sin visibilidad central. No es necesariamente malicioso; al contrario, a menudo es bienintencionado. Y en lugar de solo tolerarlo, muchas organizaciones lo están fomentando activamente. El "vibe coding" aparece en descripciones de puestos en empresas Fortune 500. Cada empleado que responde a ese mandato es una fuente potencial de código no gobernado. Las raíces ya están arraigando.

Por qué la política por sí sola no basta

"Los empleados que quieren hacer su trabajo son, con diferencia, los APT más persistentes y exitosos", dijo Matt Muller, de Datadog. "Si creen que acceder al último modelo les ayudará a hacer mejor su trabajo, encontrarán la manera, aunque sea tomando capturas de pantalla de su ordenador con el móvil para transferir datos a una cuenta personal". Prohibir las herramientas obvias hace que el comportamiento se traslade a otras menos visibles, reduciendo la visibilidad sin reducir la exposición.

Indu Sajeev, de ASOS, fue clara sobre los límites del enfoque de gobernanza convencional: "No creo que pueda ser una capa de gobernanza basada en papel y políticas. Necesita ser algo codificado que se ejecute continuamente a nivel de infraestructura crítica".

Lo que los líderes de seguridad están haciendo hoy

Comenzar con la clasificación de datos

Antes de que cualquier enfoque más sofisticado funcione, hay un trabajo de base poco glamuroso que hacer, dijo Villatoro. "¿Tienes tus datos categorizados correctamente? Porque si solo dices 'datos sensibles', bueno, ¿qué son datos sensibles? Tener los datos correctamente etiquetados es crítico". Sin esa base, todos los controles posteriores (permisos de acceso, gobernanza de agentes, pistas de auditoría) se construyen sobre terreno inestable.

Convertirse en el centro, no en el portero

El enfoque de Muller en Datadog ha sido posicionar al equipo de seguridad como el que proporciona las herramientas, no el que regula cómo se usan. "Una cosa que ha sido muy efectiva es servir como el centro centralizado, no de la actividad, sino de las herramientas para realizar la actividad", dijo. "Pon las habilidades de Claude a disposición en un marketplace interno. Nuestra única petición a los equipos de ingeniería es: cuando lo uses, danos feedback, ayúdanos a mejorar la habilidad". Este enfoque funciona cuando el constructor es un ingeniero. Pero la proliferación de código se extiende más allá de la ingeniería, a funciones como RRHH, marketing y finanzas, donde la conciencia de seguridad rara vez es un requisito del puesto. El principio central se mantiene: hacer que el camino gobernado sea más atractivo que el no gobernado. "Quiero que todo el mundo vaya por un único embudo de uso de IA", dijo Muller. "Así, incluso si no me gusta lo que está pasando, al menos puedo ver que está pasando, en lugar de forzar a la gente a canales ocultos".

Construir un registro de casos de uso

En ASOS, Sajeev abordó el problema de visibilidad con un registro de casos de uso, tratando a los agentes de IA como activos de infraestructura en lugar de funciones de software. "Transiciona orgánicamente a: esto fue creado para este caso de uso específico, esta es la identidad humana detrás de este agente", dijo. El registro no es solo un inventario. Hace que la responsabilidad sea trazable: cuando algo sale mal, puedes seguir el hilo hasta una persona y un propósito. También saca a la luz el problema subyacente de datos que tiende a ocultarse hasta que un incidente lo fuerza a la luz. "Necesitas estar en un nivel muy maduro con tu infraestructura de datos para que cualquiera de tus funciones de agente o IA funcione".

Invertir en habilitación

En Jamf, el enfoque de Villatoro se centró en la habilitación por encima de la restricción, dando a los empleados las herramientas adecuadas, formación y políticas de uso aceptable antes de que busquen sus propias soluciones. "Si trabajamos en la parte de habilitación, es mucho más fácil prevenir que el código salvaje se extienda por todas partes", dijo. "Pero si no habilitamos a los empleados, buscarán formas de habilitarse a sí mismos, y eso es lo que lleva a problemas".

Los problemas aún por resolver

Agentes de IA comportándose inesperadamente

Muller afirma la necesidad de observar y contener comportamientos inesperados de la IA antes de que se conviertan en un problema. "Cuando Claude Code descubre que no puede acceder a algo, hay escenarios donde intenta construir su propio malware para exfiltrar las credenciales que necesita", dijo Muller. "En lugar de tener una política de que no puedes usar Claude Code para hacer estas cosas, creemos que es más valioso invertir en controles técnicos que impidan que acceda a esas credenciales en primer lugar".

La brecha de permisos

Incluso cuando las organizaciones toman decisiones deliberadas sobre el uso de herramientas de IA, los controles disponibles son a menudo demasiado amplios para ser significativos. "Podemos decir 'aprobamos que Claude se conecte a Gmail'", dijo Muller. "Lo que me encantaría es poder decir: 'estoy cómodo con que mi asistente lea correos etiquetados con cierta etiqueta, y ninguno de mis otros correos'. No puedo expresar eso hoy". Sajeev señaló una brecha más profunda en los marcos de seguridad existentes: "El zero trust funciona bien con identidades humanas. Sigue siendo un vacío en todos los demás lugares, y ahora tenemos muchos ecosistemas diferentes". Las organizaciones dependen en gran medida de proveedores de primera parte cuyos controles pueden carecer de granularidad. Muller fue directo: "Si alguien de Google está viendo esto, necesitaríamos permisos OAuth más granulares".

El camino a seguir

Los líderes de seguridad que dominen efectivamente la proliferación de código no serán aquellos que intentaron impedir que los empleados construyeran. Serán aquellos que hicieron que el camino gobernado fuera el más atractivo: lo suficientemente seguro para usarlo abiertamente, lo suficientemente visible para auditar. El código salvaje ya está dentro del edificio. La pregunta no es cómo prevenirlo, sino cómo rastrearlo, asegurarlo y monitorearlo.

Vea el evento virtual Workflow de Tines bajo demanda en https://watch.workflow.live/. Patrocinado y escrito por Tines.