Vibecoding y Seguridad: Lo que los líderes deben saber sobre equipos creando con IA
Desigualdad en conocimiento de IA: Los líderes enfrentan desafíos cuando los miembros del equipo los superan en herramientas y capacidades de IA.
Vibecoding explicado: Trabajadores sin perfil técnico crean herramientas funcionales mediante prompts, acortando la distancia entre la idea y la ejecución.
Preocupaciones de seguridad: Las herramientas de vibecoding no gestionadas suponen riesgos de manejo y exposición de datos, con especial foco en vulnerabilidades de PII.
Implicaciones de costos: El uso no optimizado de herramientas de IA puede generar gastos inesperados y riesgos financieros.
Problemas de escalabilidad: Las herramientas de vibecoding exitosas requieren supervisión profesional para garantizar su escalabilidad y fiabilidad.
Seamos honestos: todos estamos en diferentes niveles cuando se trata de IA. Y para los líderes, esto puede ser inquietante: más que nunca, los subordinados directos están superando a sus gerentes en conocimientos y habilitación de IA, avanzando rápido y, a menudo, rompiendo cosas.
Si bien muchas organizaciones están fomentando la exploración abierta de herramientas de IA, el vibecoding — la próxima fase de habilitación de IA para muchos empleados no técnicos — es una aventura que viene acompañada de distintos grados de riesgo, dependiendo de lo que estés construyendo, para quién lo estés construyendo y qué datos se están almacenando y utilizando.
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 las necesidades de proceso — y con agentes de programación de IA, nunca ha sido más 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 a qué debemos prestar atención cuando los equipos empiezan a construir, recurrí a Tim Fisher, VP de IA en DPM, para que nos lo explique. Este artículo es para cualquiera que haya recibido el “Jefe, ¡mira esto tan genial que construí con Claude!” — esperamos que sea útil.
Primero, ¿Qué Es el Vibecoding? ¿Y Por Qué Es Realmente Valioso?
Para los fines de este artículo, vibecoding significa programar a través de instrucciones y solicitudes — específicamente por alguien que no es técnico. Esto es distinto a un desarrollador de software que utiliza una herramienta como GitHub Copilot, donde la persona aún aporta conocimientos técnicos significativos al trabajo. Hablamos del director financiero, el coordinador de operaciones, el gestor de proyectos que nunca ha escrito una línea de código y ahora crea herramientas funcionales usando solo instrucciones en lenguaje natural.
Y la opinión inicial de Fisher puede sorprenderte: está genuinamente entusiasmado con esto. “Me encanta la idea de que personas que no saben programar puedan ahora tener una forma de sacar lo que quieren de su cabeza y llevarlo a una forma que todos puedan ver, probar y usar”, dice. “Es una forma de comunicar que no existía antes." Lo plantea menos como una capacidad técnica y más como un nuevo medio de comunicación — uno que cierra la brecha entre visión y ejecución para personas que siempre han tenido ideas pero carecían del vocabulario técnico para expresarlas.
Vibecoding es una forma de comunicar que no existía antes.
“Es un poco como los desafíos que la gente experimenta al trabajar con equipos de diseño”, explica Fisher. “No sé dibujar ni un garabato. Así que, cuando quiero comunicarle algo visual a alguien, estoy feliz de que ahora existan herramientas que me permiten explicar algo con muchas palabras bien pensadas —que es algo en lo que sí soy bueno— y recibir al final algo que otra persona, que sí sabe de diseño, pueda ver y decir: ‘Oh, ahora sé lo que quieres lograr’”.
Para los líderes, este cambio de perspectiva importa. La tendencia a detenerlo por completo ignora lo que realmente es útil aquí: el vibecoding puede acelerar la alineación, hacer aflorar ideas más rápido y ofrecer a los miembros no técnicos del equipo una nueva forma de contribuir. La pregunta no es si permitirlo. Es si comprendes qué sucede después de que se construye la herramienta.
Dónde Termina el Valor — Y Empieza el Riesgo
Fisher es cuidadoso al separar la fase de "comunicación" del vibecoding de lo que suele suceder después — y ahí es donde cambia su tono. “Creo que el valor probablemente termina ahí la mayoría de las veces”, dice. “Es una manera mucho mejor de comunicar ideas y dirección. Pero lo que encontramos es que algunas cosas pueden pasar después y convertirse en algo más que ‘Oye, he comunicado una idea, ahora compartimos un lenguaje’. Y ahí es donde se pone aterrador.”
El problema no es dar instrucciones. Es la implementación. Es el momento en que un prototipo se convierte en una herramienta que usan personas reales, que almacena datos reales, que funciona de fondo sobre infraestructura real — y la persona que lo creó aún no sabe lo que pasa "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 será en torno a la información de identificación personal (PII). Fisher utiliza un ejemplo concreto para ilustrar dónde está el límite: “Creo que el límite de la complejidad estaría justo antes de la ingesta de datos de empleados o clientes en un sistema que luego regurgita esos datos a otras personas. Ahí es cuando surgen los problemas de PII.”
Creo que el límite de la 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 el público 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 riesgos legales reales.
Costos descontrolados y uso de tokens
Un riesgo que sorprende a muchos líderes no tiene nada que ver con los datos y todo que ver con el dinero. Fisher describe un escenario que es más común de lo que la mayoría imagina: "Supongamos que alguien accidentalmente dirige a un programador agente en la dirección equivocada, lo que resulta en que éste cree un bucle que se ejecuta todo el tiempo, acumulando constantemente un coste caro. Y, antes de darse cuenta, un proyecto que debería costar $5,000 termina costando $50,000 porque no sabían lo que estaba pasando por debajo y asumieron que el programador agente lo detectaría."
Los constructores no técnicos también suelen ser menos propensos a optimizar el uso de tokens en general, lo que significa que los costes pueden acumularse silenciosa y rápidamente. Sin visibilidad en la infraestructura en la que se ejecutan sus herramientas, los miembros de tu 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 entra en el terreno que desvela a los equipos de seguridad por las noches. El escenario que describe es un ejemplo clásico de lo que sucede cuando alguien sabe lo justo para ser peligroso: "Un error común es cuando alguien sabe lo suficiente como para saber y explicar que necesita una clave API para hacer que algo suceda. Proporciona la clave en un prompt, y no se guarda en una ubicación segura — simplemente se descarta en un archivo o se escribe directamente en el script. Luego alguien sube el código a GitHub, quizá se olvida de ponerlo en privado, y ahora esa clave API puede ser utilizada de manera indebida por cualquiera dispuesto a hacer algo malicioso como acumular una factura de $100K en tokens.”
Es fácil leer ese escenario y pensar que requiere una larga cadena de errores. Fisher rebate ese instinto: "Parece que hay toda una serie de cosas poco probables que tienen que suceder, pero no es nada improbable. De hecho, es extraordinariamente habitual, especialmente entre personas no técnicas.”
Quizá el riesgo más alarmante que menciona Fisher es uno en el que incluso desarrolladores experimentados han caído. "He escuchado historias de terror sobre desarrolladores experimentados que cargan toda la base de código de un negocio en un programador agente y ajustan algo, y luego toda la base de código termina expuesta a otra empresa completamente dentro de los límites de la ley." 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é pasa cuando realmente funciona
Una de las conversaciones más complicadas para los líderes es qué hacer cuando una herramienta "vibecoded" realmente resuelve un problema y la gente comienza a depender de ella. El caso de éxito puede pasar desapercibido y convertirse en una responsabilidad. Fisher es claro sobre el problema estructural: "En términos generales, todos los proyectos "vibecoded" no son escalables, principalmente porque no le estás pidiendo al agente que considere la escalabilidad. Lo más probable es que los no desarrolladores ni siquiera pidan cosas como manejo de errores. Si no entiendes los lugares donde pueden ocurrir errores, no sabes lo suficiente como para asegurarte de que el agente los detecte y los maneje adecuadamente."
En términos generales, todos los proyectos con código ‘vibe’ 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 'vibe', y luego éste 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 el que una herramienta interna hecha con buena intención se convierte en un riesgo organizacional — porque cuanto más dependen los equipos de ella, más probable es que falle o necesite soporte técnico constante.
La recomendación de Fisher para las herramientas que ganan tracción es una transición limpia: "Si construyes algo en lo que la gente confía, tiene que transformarse en algo más que un proyecto con código 'vibe'; debe ser absorbido por personas que hacen esto profesionalmente y saben cosas que tú ni siquiera sabes que debes preguntar".
Qué pueden hacer los líderes — Límites prácticos
Nada de esto significa que la respuesta sea una prohibición total. Fisher es consistente en este punto: el valor del 'vibecoding' para personas no técnicas es real, pero tiene un espacio específico. "El valor de estas herramientas para quienes no son programadores es poder acortar caminos 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 el 'vibecoding' brilla, y donde el riesgo todavía es manejable.
Para los líderes, la guía práctica luce algo así: fomentar el 'vibecoding' como herramienta de prototipo y de comunicación, y establecer un umbral claro en el que una herramienta sea revisada por alguien con experiencia técnica antes de ponerla en uso generalizado. 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 la IA de una que solamente avanza rápido esperando lo mejor.
El objetivo no es ser el líder que dice que no. Es ser el líder que se asegura de que el equipo sepa en qué se está metiendo — para que cuando alguien construya algo grandioso, realmente pueda llegar a algún lado.
¿Quieres más ideas como estas? Regístrate para obtener una cuenta gratuita de DPM y conoce a más expertos como estos.