Vibecoding y Seguridad: Lo que los líderes deben saber sobre equipos que crean con IA
Desigualdad de conocimiento sobre IA: Los líderes enfrentan desafíos cuando los miembros del equipo los superan en el uso de herramientas y capacidades de IA.
Vibecoding explicado: Trabajadores no técnicos crean herramientas funcionales mediante indicaciones, cerrando brechas en la ejecución de ideas.
Preocupaciones de seguridad: Las herramientas de vibecoding no gestionadas potencialmente exponen datos sensibles, especialmente vulnerabilidades de información personal identificable (PII).
Implicaciones de costos: El uso no optimizado de herramientas de IA puede desembocar en gastos inesperados y riesgos financieros.
Problemas de escalabilidad: Las herramientas de vibecoding exitosas requieren supervisión profesional para asegurar escalabilidad y fiabilidad.
Seamos honestos: todos estamos en diferentes etapas en lo que respecta a la IA. Y para los líderes, esto puede ser inquietante: más que nunca, los subordinados directos están superando a sus gerentes en conocimiento y habilidades con IA, avanzando rápido y, a menudo, rompiendo cosas.
Mientras muchas organizaciones fomentan la exploración abierta de herramientas de IA, el vibecoding —la siguiente fase de habilitación de IA para muchos empleados no técnicos— es una aventura que conlleva distintos grados de riesgo, dependiendo de lo que se está construyendo, para quién se está construyendo y qué datos se almacenan y utilizan.
Esto se está volviendo especialmente común en los equipos de gestión de proyectos y operaciones, donde construir herramientas propias suele ser la respuesta obvia a necesidades de procesos —y con agentes de codificación con IA, nunca fue tan fácil dar luz verde.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Para ayudarnos a entender qué debemos tener en cuenta cuando los equipos comienzan a construir, invité a Tim Fisher, vicepresidente de IA de DPM, para que nos cuente su perspectiva. Este artículo es para cualquiera que haya recibido el mensaje "Jefe, ¡mire esto tan genial que construí con Claude!" — esperamos que sea de ayuda.
Primero, ¿qué es el vibecoding? ¿Y por qué realmente es valioso?
A efectos de este artículo, vibecoding significa programar a través de indicaciones, en particular por alguien que no es técnico. Esto se diferencia de un desarrollador de software utilizando una herramienta como GitHub Copilot, donde la persona aún aporta un conocimiento técnico significativo al trabajo. Hablamos del CFO, el coordinador de operaciones, el gerente de proyecto que nunca ha escrito una línea de código y ahora lanza herramientas funcionales usando únicamente indicaciones en lenguaje natural.
Y la primera opinión de Fisher podría sorprenderte: realmente le entusiasma. “Me encanta la idea de que personas que no saben programar puedan tener ahora una manera de sacar eso que quieren de su cabeza y ponerlo en una forma que todos puedan ver, experimentar y usar”, comenta. “Es una nueva forma de comunicar que antes no existía.” Lo plantea menos como una capacidad técnica y más como un nuevo medio de comunicación—uno que cierra la brecha entre la visión y la ejecución para quienes siempre han tenido ideas pero carecían del vocabulario técnico para expresarlas.
Vibecoding es una forma de comunicar que antes no existía.
“Es un poco parecido a los desafíos que la gente experimenta al trabajar con equipos de diseño”, explica Fisher. “No puedo dibujar ni siquiera un monigote. Así que, cuando quiero comunicar algo visual a alguien, me alegra mucho que existan ahora herramientas que me permitan explicar con muchas palabras elaboradas —que es lo que se me da bien— y obtener algo al final que otra persona que sí sabe de diseño diga: ‘Ah, ya sé lo que quieres’.”
Para los líderes, este replanteamiento importa. El impulso de frenarlo por completo pasa por alto lo que aquí es realmente útil: el vibecoding puede acelerar la alineación, hacer surgir ideas más rápido y dar a los miembros no técnicos del equipo una nueva forma de aportar. La cuestión no es si permitirlo o no. Es si entiendes qué sucede después de que la herramienta se ha construido.
Hasta dónde llega el valor — y dónde empieza el riesgo
Fisher es cuidadoso al separar la fase de "comunicación" del vibecoding de lo que suele venir después —y ahí es donde cambia su tono. “Creo que el valor de esto probablemente termina ahí la mayoría de las veces”, comenta. “Es una forma mucho mejor de comunicar ideas y dirección. Pero lo que vemos es que pueden pasar cosas después que van más allá de ‘Eh, mira, te he comunicado una idea, ahora hablamos el mismo idioma’. Y ahí es donde da miedo.”
El problema no es el uso de las indicaciones. Es el despliegue. Es el momento en que un prototipo se convierte en una herramienta que personas reales usan, que almacena datos reales, que se ejecuta en infraestructuras reales —y la persona que lo construyó aún no sabe lo que sucede bajo el capó.
Las vulnerabilidades de seguridad que los líderes deben conocer
PII y manejo de datos
El riesgo más intuitivo para la mayoría de los líderes estará relacionado con la información personal identificable (PII). Fisher utiliza un ejemplo concreto para ilustrar dónde está el límite: “Creo que ese límite de complejidad estaría justo antes de la incorporación de datos de empleados o clientes en un sistema que luego proporciona esos datos a otras personas. Es ahí cuando te enfrentas a los problemas de PII.”
Creo que el límite de complejidad estaría justo antes de la incorporación de datos de empleados o clientes en un sistema que regurgita esos datos a otras personas.
El riesgo aumenta según la sensibilidad de los datos y la audiencia que puede acceder a ellos; y en los equipos de operaciones y gestión de proyectos, esos datos a menudo incluyen información de clientes, registros de empleados, datos de compensación o detalles de contacto que conllevan una verdadera exposición legal.
Costos Descontrolados y Uso de Tokens
Un riesgo que toma por sorpresa a muchos líderes no tiene nada que ver con los datos y sí con el dinero. Fisher describe una situación más común de lo que la gente se imagina: "Supongamos que alguien accidentalmente dirige a un agente codificador en la dirección equivocada, lo que resulta en la creación de un bucle que se ejecuta constantemente, acumulando una tarifa costosa. Y, antes de que te des cuenta, un proyecto que debería costar $5,000 termina costando $50,000 porque no sabían lo que pasaba por debajo del capó y asumieron que el codificador agente detectaría eso."
Los constructores no técnicos también son menos propensos a optimizar el uso de tokens en general, lo que significa que los costos pueden acumularse de manera silenciosa y rápida. Sin visibilidad sobre la infraestructura en la que funcionan sus herramientas, tus compañeros de equipo pueden no darse cuenta de que hay un problema hasta que llega la factura.
Claves API y Seguridad de la Información
Aquí es donde Fisher profundiza en el terreno que desvela a los equipos de seguridad durante la noche. El escenario que describe es un ejemplo clásico de lo que puede salir mal cuando alguien sabe lo suficiente para ser peligroso: "Un error común es cuando alguien sabe lo suficiente para saber y decir que necesita una clave API para lograr algo. Proporcionan la clave en un prompt y no se guarda en un lugar seguro; simplemente se deja en un archivo o se escribe directamente en el script. Luego, alguien publica el código en GitHub, quizá se olvida de hacerlo privado, y ahora esa clave API puede ser abusada por cualquiera que quiera hacer algo nefasto como acumular una factura de $100K en tokens.”
Es fácil leer ese escenario y pensar que requiere una larga cadena de errores. Fisher rechaza ese instinto: "Parece que hay una larga cadena de cosas poco probables, pero no es nada improbable. De hecho, es extraordinariamente común, especialmente entre personas no técnicas."
Quizás el riesgo más alarmante que plantea Fisher es uno en el que incluso desarrolladores experimentados han caído. "He escuchado historias de terror sobre desarrolladores experimentados que sueltan toda la base de código de una empresa en un agente codificador y modifican algo, y luego toda la base de código se expone a otra empresa completamente dentro de los márgenes legales." Si los desarrolladores experimentados pueden cometer este error, el perfil de riesgo para un empleado no técnico que construye rápidamente y sin supervisión es considerablemente mayor.
More Articles
- Cómo 5 Consultores de Gestión de Proyectos Evalúan la Preparación de un Equipo para el Cambio con IA
- La IA en la gestión de riesgos de proyectos: aplicaciones clave, herramientas y un marco de adopción paso a paso
- La IA en la Gestión de Riesgos: Guía Ejecutiva de Oportunidades, Desafíos y Casos de Uso
El Problema de la Escalabilidad — Qué Ocurre Cuando Realmente Funciona
Una de las conversaciones más complicadas para los líderes es qué hacer cuando una herramienta creada "al vuelo" realmente resuelve un problema y la gente empieza a depender de ella. El caso de éxito puede convertirse silenciosamente en una carga. Fisher es claro sobre el problema estructural: "En términos generales, todos los proyectos improvisados no son escalables, principalmente porque no se le solicita al agente que considere la escalabilidad. Es probable que los no desarrolladores ni siquiera pidan cosas como el manejo de errores. Si no entiendes los lugares donde ocurren errores, no sabes lo suficiente como para asegurarte de que el agente los detecte y los gestione adecuadamente."
En términos generales, todos los proyectos con código de ambiente no son escalables, principalmente porque no se le pide al agente que considere la escalabilidad.
La brecha de responsabilidad se vuelve más visible bajo presión. "Lo que suele pasar es que alguien hace un código de ambiente, funciona, pero ¿esa persona será soporte técnico 24/7 para este producto?" Para los líderes de entrega y operaciones, este es el momento en que una herramienta interna bien intencionada se convierte en un riesgo organizacional, porque cuanto más equipos dependan de ella, más probable es que falle o requiera soporte técnico constante.
La recomendación de Fisher para las herramientas que ganan tracción es una transferencia limpia: "Si construyes algo de lo que la gente depende, debe pasar a ser más que un proyecto de código de ambiente; tiene que ser adoptado por personas que se dedican a esto profesionalmente y saben cosas que ni siquiera sabes que deberías preguntar".
Qué pueden hacer los líderes: barreras prácticas
Nada de esto significa que la respuesta sea una prohibición tajante. Fisher es consistente en este punto: el valor del código de ambiente para personas no técnicas es real, pero tiene su espacio específico. "El valor de estas herramientas para quienes no programan es poder acortar cosas como la alineación en torno a una idea y superar la fase de '¿esto va a funcionar?'", dice. La fase de prototipo, la fase de comunicación, la fase de "¿realmente vale la pena construir esto?", ahí es donde destaca el código de ambiente y donde el riesgo aún es manejable.
Para los líderes, el manual práctico se vería así: fomentar el código de ambiente como herramienta de prototipado y comunicación, y establecer un umbral claro en el que una herramienta sea revisada por alguien con experiencia técnica antes de que se use de manera más amplia. Tener estas conversaciones con tu equipo — para que comprendan los riesgos y conozcan sus opciones — es lo que separa una cultura de exploración inteligente de IA de una que simplemente avanza rápido esperando lo mejor.
El objetivo no es ser el líder que dice no. Es ser el líder que se asegura de que el equipo sepa en qué se está metiendo; así, cuando alguien realmente construya algo grande, pueda llegar lejos.
¿Quieres más ideas como estas? Regístrate gratis en DPM para escuchar a más expertos como estos.