Vibe coding en la empresa: siete reglas que marcan la diferencia

Una política de vibe coding no necesita veinte páginas. Necesita siete decisiones: quién responde del código, qué requiere aprobación, qué datos pueden salir de la empresa, cómo se incorporan paquetes de terceros, qué se prueba, qué se documenta y quién decide en caso de duda. Todo lo demás no se lee.

Por qué prohibir las herramientas de IA no funciona

Porque no pone fin al uso, sino que lo vuelve invisible. En la Stack Overflow Developer Survey 2025, el 84 % de los encuestados afirmó usar herramientas de IA o planear hacerlo, frente al 76 % del año anterior. Una prohibición que choca con una práctica tan extendida la traslada a la cuenta privada y le quita justo la visibilidad que necesitaría para dirigirla.

Por eso la pregunta productiva no es si se usa IA, sino bajo qué condiciones el resultado puede entrar en su producto.

¿Qué reglas necesita una política de vibe coding?

1. El código pertenece a una persona

Cada cambio tiene una persona responsable con nombre y apellidos, con independencia de quién o qué lo haya escrito. Esa persona debe poder explicar el cambio. «Eso lo hizo la IA» no es una justificación admisible en una revisión.

2. Las áreas críticas requieren aprobación

Establezca la lista una vez y modifíquela pocas veces. Han demostrado su utilidad: autenticación y permisos, procesos de pago, esquema de base de datos y migraciones, despliegue, nuevas dependencias, tratamiento de datos personales. Los cambios en estas áreas requieren un plan antes de la implementación y una revisión después.

3. Las nuevas dependencias son decisiones, no efectos secundarios

Cada paquete que añade una herramienta de IA se comunica y se evalúa: ¿existe realmente?, ¿quién lo mantiene?, ¿qué licencia tiene?, ¿qué vulnerabilidades conocidas presenta? El OWASP Top 10:2025 incluye por primera vez los fallos de la cadena de suministro como categoría propia, en el tercer puesto, y con razón: los modelos inventan a veces nombres de paquetes, y esos nombres pueden ser registrados por atacantes.

4. Los datos salen de la empresa solo de forma consciente

Aclare una vez y por escrito qué herramientas pueden transmitir qué contenidos: código fuente sí o no, configuración, extractos de registros, contenido de bases de datos. Para los datos personales rige de todos modos el régimen de protección de datos ya existente; una herramienta sin encargo de tratamiento aclarado no es una zona gris, sino un punto pendiente.

5. Las pruebas forman parte del cambio, no del trabajo atrasado

Un cambio sin una prueba que falle ante una regresión está inacabado. Esto es más importante con código de IA que con código escrito a mano: el código escrito a mano lleva consigo la comprensión de su autor; el generado, no. Más detalles en el artículo sobre la cobertura de pruebas en código de IA.

6. La evidencia forma parte de la finalización

«Terminado» significa: ejecución de pruebas en verde, diff leído, controles superados, cada punto acreditado y no afirmado. Una versión viable en la práctica figura en el artículo sobre la Definition of Done en el desarrollo asistido por IA.

7. En caso de duda decide una persona, y una persona concreta

Designe el rol que decide cuando una regla no encaja. Sin un rol designado, en caso de duda decide la presión del tiempo.

¿Cómo aplico estas reglas sin frenar al equipo?

Vinculándolas al proceso y no a la atención. Una política en la intranet se lee una vez. Un control integrado en el flujo de trabajo actúa en cada cambio.

• Verificable automáticamente: formato, análisis estático, ejecución de pruebas, revisión de dependencias y licencias, secretos en el código fuente. Pertenece al pipeline, no a una lista de comprobación; véase Quality Gates en el pipeline de CI/CD.
• Verificable solo por personas: ¿es correcta la lógica de negocio? ¿Encaja la solución en la arquitectura? ¿Se ha resuelto el problema real? Para ello hace falta una revisión con un encargo claro; véase Code review para código generado por IA.

El error más frecuente es mezclar ambas cosas: las personas revisan el formato mientras la lógica de negocio se cuela sin revisar.

¿Cuánto cuesta no tener reglas?

El precio no aparece en el proyecto en el que se origina, sino en el siguiente. El análisis de GitClear muestra para 2026 el nivel más alto jamás medido de bloques de código duplicados, con un refactoring casi desaparecido: se copia más y apenas se ordena.

Cuánto cuesta esto en concreto y con qué cuatro indicadores puede medirlo en su propio proyecto se explica en el artículo sobre la deuda técnica del código de IA.

Preguntas frecuentes sobre la política de IA

¿Qué extensión debe tener una política de vibe coding?

Una página. Lo que sea más largo no se consultará en caso de duda. Los detalles pertenecen a las herramientas que la hacen cumplir, no al documento que la describe.

¿Se aplica la política también a proveedores externos?

Debería aplicarse, y por vía contractual. Los externos entregan código a su producto; las cuestiones de responsabilidad de la nueva Directiva europea sobre responsabilidad por productos defectuosos se le plantean a usted con independencia de qué teclado haya intervenido.

¿Debemos indicar que el código se ha creado con IA?

Según el estado actual, no existe una obligación legal general de señalar el código fuente generado por IA en su propio producto. Aun así, la trazabilidad interna es recomendable: en caso de fallo, es la base de cualquier análisis de causas. Con independencia de ello, tenga en cuenta las obligaciones de transparencia del Reglamento de IA (AI Act) de la UE para los sistemas de IA que ponga a disposición de sus usuarios.

¿Cómo se empieza si hasta ahora no hay nada regulado?

Con la regla dos. La lista de áreas que requieren aprobación se escribe en una tarde y cubre la mayor parte del riesgo.

Las reglas que dependen de la disciplina aguantan exactamente hasta el primer viernes por la tarde urgente. Code Guardian traduce los puntos críticos de esta lista (despliegue, migración, dependencia, juicio sobre datos) en gates que se sitúan delante del paso en lugar de en un documento aparte.

Fuentes

• Stack Overflow Developer Survey 2025, sección «AI».
• OWASP Top 10:2025, categoría A03 «Software Supply Chain Failures».
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research.
• Directiva (UE) 2024/2853 sobre responsabilidad por los daños causados por productos defectuosos.

Fecha: 27 de julio de 2026. Información general, no constituye asesoramiento jurídico. Para la elaboración de políticas internas y contratos, debería recabar una revisión jurídica.