Copilot lo escribió, pero ¿de quién es la propiedad? La brecha de gobernanza que los equipos de ingeniería pueden pasar por alto

Un ingeniero abre Copilot para ayudar a redactar código para el sitio de un cliente. En segundos, recibe código que antes habría llevado mucho más tiempo escribir manualmente. Para muchos desarrolladores web y empresas que optimizan sus sitios, es normal preguntarse: ¿es ese código fiable? ¿Es seguro? ¿Debe revisarse antes de implementarlo? Todas estas preguntas se engloban en una sola consulta: ¿Quién será responsable del código asistido por IA? Y, lo más importante, ¿quién se queda con la ganancia de productividad?

Si la IA permite que un equipo de ingeniería complete más trabajo en el mismo tiempo, todos pueden beneficiarse más de ese valor económico. Esto podría traducirse en que el desarrollador ahorre tiempo, el empleador obtenga más valor de las horas ahorradas, o el cliente reciba lo que pagó con tiempo de sobra. Independientemente de cómo beneficie el tiempo ahorrado, lo que sigue siendo prioritario es cómo se gobierna y se valora el trabajo.

La IA y la codificación se están volviendo inevitables

Las herramientas de codificación con IA están ganando rápidamente tracción y avanzando en el desarrollo convencional. Según la 2025 Stack Overflow Developer Survey, el 84% de los encuestados estaban usando o planeaban usar herramientas de IA en su proceso de desarrollo.

Aunque la incorporación de IA en los flujos de trabajo de los desarrolladores web se está volviendo más común, todavía existe incertidumbre sobre su fiabilidad. La misma encuesta encontró que el 46% no tenía plena confianza en la exactitud de los resultados de la IA, y aproximadamente el 66% citó soluciones de IA que estaban “casi correctas, pero no del todo” como fuente de frustración.

El debate sobre la codificación con IA que está tomando forma se centra más en su fiabilidad que en si ese código genera más valor y quién es responsable de garantizarlo.

La IA está rompiendo la relación entre horas y resultados

La compensación por desarrollo de software siempre se basó en la suposición de que la producción de ingeniería estaba estrechamente vinculada al esfuerzo de ingeniería. Sin embargo, la IA generativa ahora complica esa ecuación.

Un experimento controlado con 95 desarrolladores encontró que los participantes con acceso a GitHub Copilot completaron una tarea específica de servidor HTTP en JavaScript un 55,8% más rápido que los que no tenían acceso.

Esto muestra que la IA puede acelerar el desarrollo, potencialmente sin sacrificar la calidad. Pero estos datos solo son válidos porque el experimento siguió una tarea de programación muy específica. Aunque la tarea se completó más rápido, no significa que Copilot haga que una organización de ingeniería sea un 55,8% más productiva.

Otro estudio de investigación ejemplifica esta idea. Un ensayo con 96 ingenieros de software de Google a tiempo completo encontró que los desarrolladores que usaron IA completaron una tarea de nivel empresarial en aproximadamente 96 minutos, en comparación con 114 minutos para quienes no la usaron. La estimación ajustada de los investigadores sugería aproximadamente una reducción del 21% en el tiempo de finalización. Sin embargo, el estudio no analizó la calidad del código generado por IA, ni abordó cuestiones de equidad respecto a la dependencia de la tecnología.

También hay evidencia de que la IA ralentiza el tiempo de codificación. Un estudio aleatorio de METR involucró a 16 desarrolladores experimentados de código abierto que trabajaron en 246 problemas reales en repositorios que conocían bien. Utilizando herramientas disponibles a principios de 2025, incluidas Claude Sonnet 3.5 y 3.7, así como Cursor Pro, tardaron aproximadamente un 19% más en completar sus tareas, aunque muchos asumían que estas herramientas ahorrarían tiempo.

En conjunto, estos estudios contradicen la expectativa de que la IA permite a los desarrolladores trabajar más rápido. En cambio, está haciendo que el tiempo y el valor del desarrollador sean menos predecibles para las empresas que ofrecen trabajo web y para los clientes que lo reciben.

El problema de precios del que nadie habla

Tiempo y Material (T&M) es un modelo común en el desarrollo web para la adquisición de software, ya que aborda un problema recurrente de la industria: un proyecto en evolución.

Con este modelo, en lugar de requerir que cada característica o tarea esté definida antes de que comience el desarrollo, los clientes pueden pagar por el tiempo de ingeniería a medida que el proyecto avanza y cambia.

Sin embargo, la IA está creando obstáculos en ese modelo probado. Con la compensación vinculada directamente a las horas de ingeniería, un tiempo de desarrollo más eficiente puede traducirse en menos horas facturables para los clientes. Si la IA brinda los mismos resultados en menos tiempo, la tecnología puede crear valor para los clientes, pero la reducción de horas facturables implica menos ingresos para los proveedores.

La solución no es alentar a los desarrolladores a trabajar más despacio. El modelo T&M ahora enfrenta un problema estructural en cómo se diseñan los precios y los incentivos. Utilizar tarifas horarias para determinar el valor puede ser limitante. Un comprador puede saber exactamente cuánto cuesta cada hora de ingeniería y, sin embargo, seguir sin tener claridad sobre la inversión total necesaria para lograr el resultado deseado.

A medida que la IA cambia la productividad de la ingeniería, la pregunta puede pasar de:

“¿Cuánto cuesta una hora de desarrollador?” → “¿Qué ocurre con el valor cuando se requieren menos horas de desarrollador?”

Los hallazgos de METR complican esta cuestión. Si los desarrolladores creen que pueden ahorrar tiempo cuando, en realidad, tardan más, ni la adopción de IA ni la productividad percibida son suficientes para demostrar valor financiero. Por eso las organizaciones necesitan una gobernanza que pueda medir lo que realmente ocurrió.

La brecha de gobernanza tiene cuatro propietarios

Discutir la gobernanza en torno al desarrollo asistido por IA debe ir más allá de las políticas que regulan qué herramientas pueden usar los desarrolladores.

Existen al menos cuatro tipos de propiedad que las organizaciones de ingeniería deberían definir.

1. ¿Quién es el propietario del código?

La IA puede generar una implementación, pero no puede ser una excusa para un desarrollo sin rendición de cuentas. Alguien sigue siendo responsable de revisar, probar y aprobar el código hasta que llegue a producción.

2. ¿Quién es el propietario del riesgo?

El código más rápido solo es valioso si no causa problemas en otro lugar. Un estudio empírico del código generado por IA identificó debilidades de seguridad en el 29,5% de los fragmentos de Python examinados y en el 24,2% de los fragmentos de JavaScript. La investigación también identificó debilidades que abarcan 43 categorías del Common Weakness Enumeration.

Sin embargo, el estudio encontró que alimentar las advertencias de análisis estático de vuelta a Copilot Chat podría corregir hasta el 55,5% de los problemas de seguridad identificados. La investigación muestra cómo la IA puede crear y resolver problemas de codificación, pero las organizaciones necesitan procesos para determinar cómo validar sus resultados.

NIST’s SP 800-218A refleja este principio al ampliar su Marco de Desarrollo Seguro de Software con buenas prácticas que abordan la IA generativa y los modelos de base de uso dual.

3. ¿Quién es el propietario de la ganancia de productividad?

Los acuerdos comerciales desde el principio son esenciales para determinar quién debe recibir las ganancias de eficiencia. La IA puede ayudar a los clientes a gastar menos, permitir a los equipos entregar más software, o no proporcionar ningún beneficio financiero al final del proyecto.

Lo que sigue siendo igual es la necesidad de procesos transparentes y la entrega de trabajo de calidad, acordado.

4. ¿Quién es el propietario de la priorización?

La IA puede hacer que la generación de funcionalidades sea más barata y rápida, pero no puede decidir si esas funcionalidades son necesarias.

De hecho, aumentar la capacidad de desarrollo puede hacer que la priorización sea más importante. Cuando los equipos pueden construir y experimentar más rápido, alguien aún necesita determinar qué resultados justifican el presupuesto disponible y qué ideas deben ser descartadas.

La gobernanza de IA se está convirtiendo en una cuestión financiera

Estas preguntas hacen que la gobernanza de IA sea cada vez más relevante. Imagine dos socios de desarrollo que cobran tarifas horarias similares.

Uno ha integrado la IA en un proceso de ingeniería sólido y logra el resultado requerido considerablemente más rápido, mientras que el otro tarda más. Comparar solo sus tarifas horarias no le dice mucho al comprador sobre los procesos que llevarán a cabo.

Los compradores deberán evaluar:

• Inversión total esperada
• Responsabilidad por sobrecostos
• Controles de calidad sobre el trabajo generado por IA
• Cómo se comparten las ganancias de eficiencia

T&M puede seguir siendo útil para ambas partes si aceptan conscientemente la incertidumbre en los servicios. Los acuerdos de precio fijo también pueden funcionar cuando los requisitos y entregables son estables.

Pero la IA también hace que valga la pena examinar estructuras alternativas. Un enfoque es establecer un límite financiero máximo manteniendo el alcance flexible. Entonces, las funcionalidades pueden priorizarse según el valor comercial dentro de ese modelo.

Si la ingeniería se vuelve más eficiente, las ganancias pueden traducirse en capacidad de producto adicional en lugar de tiempo facturable adicional. Los incentivos comerciales deberían fomentar el mismo resultado que los incentivos de ingeniería, creando software más útil de la manera más eficiente posible.

La misma conversación sobre IA

Los líderes de ingeniería deben comprender cómo los incentivos comerciales influyen en la entrega. Los equipos de finanzas y adquisiciones necesitan visibilidad suficiente sobre la ingeniería asistida por IA para evaluar si la eficiencia declarada está proporcionando valor medible.

Eso significa que una gobernanza de IA madura no puede detenerse en listas de modelos aprobados, controles de seguridad, políticas de datos o requisitos de revisión de código. Necesita abordar la rendición de cuentas, el riesgo financiero, la priorización y la propiedad de las ganancias de productividad.

Pero hay una segunda cuestión de propiedad que podría tener un impacto mucho mayor en los presupuestos tecnológicos: ¿Quién es el propietario del valor creado o perdido cuando la IA cambia la rapidez con la que se construye el software?

Las organizaciones que determinen si una ingeniería más rápida realmente produce mejores productos, controlan la inversión y logran resultados comerciales medibles serán las que puedan mantenerse por delante de la competencia.

Si su equipo de desarrollo adoptara IA mañana, ¿le diría su modelo de gobernanza y comercial actual si la entrega se ha vuelto más valiosa?