Qué es el vibe coding y por qué tu empresa ya lo usa
El término lo popularizó el investigador Andrej Karpathy a principios de 2025 para describir una práctica que ya era habitual antes de que tuviera nombre: pedirle a una IA que genere código funcional sin que nadie con criterio técnico lo revise. El resultado funciona. Se ve bien. Y en muchos casos lleva dentro vulnerabilidades que no saltan a la vista.
Hoy cualquier persona de tu equipo puede pedirle a Claude, Cursor o ChatGPT que monte una herramienta interna en una tarde. Eso no es malo en sí mismo. Lo que sí es un problema es asumir que, porque funciona, es seguro.
Si tienes personas en tu equipo que crean herramientas o scripts con IA —y casi todas las empresas las tienen ya— este artículo es para ti.
El dato que nadie quiere ver: 91,5% con fallos de seguridad
No es una estimación ni una opinión de agorero. Sale de auditar más de 200 aplicaciones reales construidas con asistencia de IA sin supervisión técnica posterior. El 91,5% arrastraba al menos un fallo de seguridad. No errores menores: vulnerabilidades reales que un atacante motivado podría explotar.
Los datos del sector confirman la tendencia. El laboratorio de seguridad de Georgia Tech registró 74 vulnerabilidades CVE en marzo de 2025 atribuidas directamente a código generado por IA. Por su parte, Veracode —tras analizar millones de escaneos— concluye que solo el 55% del código que producen estos modelos supera un test de seguridad básico.
Dicho de otra forma: si tu equipo ha creado cinco herramientas con IA en los últimos meses, la probabilidad de que al menos cuatro de ellas tengan un fallo de seguridad activo es altísima.
Qué tipo de fallos aparecen y por qué son tan frecuentes
Los modelos de lenguaje aprenden de código existente, incluido código con malas prácticas. Cuando generan algo nuevo, replican patrones sin entender el contexto de seguridad de tu empresa. Los fallos más habituales no son exóticos:
- Inyecciones SQL en herramientas que consultan bases de datos internas
- Credenciales y contraseñas escritas directamente en el código (hardcoded secrets)
- Rutas de archivos o endpoints sin autenticación
- Validación de inputs insuficiente que permite entradas maliciosas
Estos fallos no aparecen porque la IA sea descuidada. Aparecen porque nadie le indicó cuáles son los estándares de seguridad de tu entorno, y porque el modelo prioriza que el código funcione sobre que sea robusto frente a un atacante.
Además, existe un problema de visibilidad. Cuando un empleado crea una herramienta en una tarde y la usa el equipo durante semanas, ese código vive fuera de cualquier proceso de revisión. Es el shadow IT de la era de la IA: activos que nadie inventarió, que nadie revisa y que tienen acceso a datos reales de tu empresa.
Lo que el criterio humano cambia
Prohibir el uso de IA para crear herramientas internas sería un error. Llegas tarde y perderías la ventaja de productividad real que aporta. Pero hay una diferencia enorme entre permitir vibe coding sin más y darle a ese código el mismo tratamiento que darías a cualquier código de alguien que empieza.
Para entender mejor cómo controlar el código generado por IA en tu empresa —y en qué puntos del proceso interviene el criterio humano—, el principio es siempre el mismo: quien despliega responde.
Eso significa tres cosas concretas:
- Revisión antes de usar. No un audit exhaustivo: una lectura de diez minutos buscando los cuatro patrones de fallo más comunes.
- Pruebas con datos reales. La IA prueba con datos ficticios. Tu entorno tiene datos reales. La diferencia importa.
- Alguien que responda. Si la herramienta accede a datos de clientes o a sistemas críticos, tiene que haber una persona responsable, no solo el modelo que la generó.
Cómo introducir supervisión sin frenar a tu equipo
La gobernanza de IA en una empresa pequeña no requiere un departamento de seguridad ni un proceso burocrático. Requiere definir tres cosas antes de que el código generado por IA llegue a producción.
Primero, un inventario mínimo: qué herramientas creadas con IA están en uso, quién las creó y a qué datos acceden. Sin este inventario, no puedes priorizar qué revisar.
Segundo, una regla de acceso: cualquier herramienta generada por IA que acceda a datos de clientes, sistemas financieros o información sensible pasa por una revisión antes de desplegarse. Una sola persona con criterio técnico básico es suficiente para la mayoría de los casos.
Tercero, un responsable por herramienta. Si algo falla, tiene que haber alguien que lo sepa antes de que lo descubra un cliente o un auditor. Las señales de que una herramienta de IA está fuera de control son detectables si alguien las busca; el problema es que por defecto nadie lo hace.
Implementar este proceso no requiere semanas. En nuestra experiencia trabajando con pymes, auditar lo que tu agente de IA hace cada día es perfectamente alcanzable con los recursos que ya tienes.
La automatización de procesos con IA genera valor real cuando va acompañada de criterio. Sin él, genera valor y riesgo al mismo tiempo, y el riesgo suele aparecer después.
El 91,5% es un número incómodo. Pero es recuperable. La IA no va a generar código perfecto por sí sola: eso no es lo que hace. Lo que hace es multiplicar la velocidad de tu equipo. El criterio para que esa velocidad no se convierta en riesgo lo pones tú.