La IA convierte el desarrollo en revisión. ¿Quién aprueba?

El seis por ciento de los desarrolladores se sienten notablemente aliviados por la IA. El 67 por ciento describe días más intensos con mayor producción. El dividendo no ha desaparecido. Se ha trasladado a un trabajo que no está previsto en ninguna planificación: verificar. Nadie ha decidido quién es responsable de ello.

RelacionadoLa IA no sustituye puestos de trabajo, sustituye perfiles profesionales: qué significa esto para la contratación de ejecutivos  /  IA local: gobernanza antes de la compra de hardware

Allí donde se decide el uso de la IA, las preguntas son: ¿Qué ahorramos? ¿Cómo ganamos productividad? El despliegue está pagado, las licencias están en curso, la rentabilidad está prometida. Alguna vez alguien quiere verla.

En junio de 2026, la Asociación de Software Python preguntó en la comunidad PyCon-DE. Han respondido 383 desarrolladores de software, científicos de datos e ingenieros de IA. En ninguna de las más de 1.000 respuestas alguien informa de una reducción concreta de puestos de trabajo debido a la IA. Cuando se informan vacantes de personal, casi un tercio nombra precisamente el desarrollo de software clásico. El dividendo existe, pues. Sin embargo, en el equipo llega como una expectativa. No surge capacidad libre a partir de ello.

El trabajo no desaparece. Cambia de carácter.

El 96 por ciento utiliza herramientas de inteligencia artificial al menos varias veces al día. Se delega lo que se puede delegar: código nuevo (76 por ciento), investigación (44 por ciento), refactoring (35 por ciento). La lista opuesta es interesante. Al preguntar sobre las tareas que han surgido recientemente, el 68 por ciento menciona la verificación y curación de la salida de la inteligencia artificial. El conocimiento del dominio, el diseño del sistema y la comunicación de requisitos ganan valor. Es decir, exactamente las habilidades cuya calidad requiere un juicio humano.

La sustitución tiene lugar, pero a nivel de actividad en lugar de a nivel de puesto. De la producción se pasa a la verificación. Y la verificación no es una tarea rutinaria: cuesta tiempo, requiere juicio y conlleva responsabilidad. No se puede hojear el código, las líneas de acción se conectan solo en el último capítulo.

Debido a que el trabajo de verificación no está en ningún plan, no se ve ni se presupuesta. El 16 por ciento se siente abrumado al final de un día de inteligencia artificial, en las corporaciones uno de cada cinco. La planificación de Velocity no conoce ninguna posición para este trabajo. Y debido a que no tiene un propietario, la responsabilidad por sus errores recae en el último en la cadena: en la persona que hace clic en «Merge».

Cuanto mayor es la casa, menor es el dividendo

Se podría asumir que este es un problema de organizaciones pequeñas y no estructuradas. Es lo contrario. A medida que aumenta el tamaño, el trabajo de verificación aumenta del 64 por ciento en organizaciones con menos de 50 empleados al 76 por ciento en organizaciones con más de 5.000. La incertidumbre sobre la responsabilidad crece con él y es el mayor obstáculo mencionado en las corporaciones, antes que la calidad de los datos, los sistemas heredados y la seguridad. La ganancia de automatización, por otro lado, no crece con el tamaño: en casas pequeñas, un tercio más automatiza más de la mitad de las tareas rutinarias que en las corporaciones.

Así pues, las grandes casas obtienen un dividendo menor con una mayor carga de verificación. El tamaño tampoco protege contra la responsabilidad. Alrededor de siete de cada diez encuestados en organizaciones con más de 5.000 empleados dicen que la responsabilidad por un error causado por la inteligencia artificial no está explícitamente regulada y recae фактически en el desarrollador que ha tomado el código. En casas con menos de 50 empleados es lo mismo. Cumplimiento, revisión de corporaciones, consejo de empresa: en este punto no cambian nada. Un marco documentado con obligación de revisión, aprobación nominal y pista de auditoría lo tienen en las corporaciones el 14 por ciento. Otro 9 por ciento ni siquiera sabe si existe.

La misma máquina escribe el código y proporciona la señal de calidad

Alrededor de uno de cada seis participantes ha descrito además un incidente concreto. Los informes muestran un patrón costoso: La señal de prueba en sí proviene de la máquina.

Un senior en una empresa de energía revisa una solicitud de extracción de IA y queda impresionado por un método de prueba elegante. Al leerlo por segunda vez, las pruebas no tienen sentido, aunque se ejecutan correctamente. En una empresa de logística, el agente reescribe la prueba que falla tantas veces hasta que pasa. El error solo se detecta durante el despliegue y la búsqueda de la causa lleva días. En el sector farmacéutico, después de medio año de desarrollo guiado por IA, se encuentran 23.000 líneas de documentación generada que nadie ha leído. Todas las pruebas están en verde. Comprueban los requisitos generados por IA frente al código generado por IA. Los tres informes provienen de organizaciones con más de 500 empleados.

„Sucede a menudo al generar código que las versiones de paquetes simplemente se inventan. Si se confía ciegamente en ello, se cae rápidamente en un torbellino de alucinaciones y depuración en el lugar equivocado.“
– Respuesta de texto libre de la encuesta, junio de 2026

La alucinación, es decir, una salida plausible pero completamente inventada del modelo, no es un error de principiante. Afecta a desarrolladores senior en corporaciones. Y los afecta donde las organizaciones creen estar seguras: el 90% revisa la salida de IA mediante revisión manual, el 76% ejecuta pruebas. Solo el 30% tiene una evaluación formal, es decir, un conjunto de pruebas versionado que permite medir si un sistema resuelve una tarea de manera fiable. El 14% se fía principalmente de su instinto. Mientras tanto, la confianza en la salida ha aumentado al 58%.

Cuatro niveles actúan de manera plausible. Nadie decide.

Como principal cuello de botella, los encuestados mencionan la falta de claridad en las responsabilidades (40 por ciento), seguida de la seguridad, la protección de datos y el Reglamento de IA de la UE (36 por ciento). Esto es notable porque nadie se comporta de manera incorrecta. Cada nivel actúa de acuerdo con su perspectiva de manera comprensible. Sin embargo, la decisión sigue siendo un vacío.

Cada nivel puede asumir legítimamente que otro es responsable

Estas cuatro preguntas abiertas forman juntas la brecha de firmas. Es el espacio entre los niveles. Ninguno de ellos hace algo incorrecto. Solo el desarrollador que adopta el código generado no puede señalar a otro nivel. Si solo puede cerrar una de las cuatro preguntas, cierre la segunda. Es la única que se decide todos los días en su casa, aunque de manera inconsciente.

Cuánto costará esto se muestra en el informe más duro de la encuesta. En una pequeña casa de software, las lagunas de seguridad masivas del uso intensivo de IA solo se detectan después de que el empleado en cuestión abandonó la empresa. Resultado: nuevo desarrollo completo. Si el conocimiento de control y la responsabilidad de aprobación dependen de una persona, esa persona abandona la casa con parte de la capacidad de control. El daño permanece.

El plazo ha cambiado. La responsabilidad no.

Una parte significativa de la presión regulatoria acaba de disminuir. A finales de junio de 2026, el Consejo de la UE confirmó definitivamente el Digital Omnibus: las obligaciones para los sistemas de alto riesgo según el Anexo III se posponen 16 meses hasta el 2 de diciembre de 2027, y para la IA en productos regulados hasta el 2 de agosto de 2028. El Anexo III se refiere a la IA que decide sobre créditos, solicitudes o infraestructura crítica. Los requisitos sustantivos permanecen sin cambios.

Muchos leen esto como un aviso de tranquilidad. Yo lo leo de manera diferente. Para parte de las obligaciones de alto riesgo, el reloj regulatorio funciona más lento. El reloj operativo sigue funcionando sin cambios. El error que un agente escribe en su producción la próxima semana no espera a Bruselas. La responsabilidad operativa surge con la aprobación. Y las aprobaciones tienen lugar diariamente en su casa, en un 90 por ciento en la revisión manual de una sola persona, cuyo nombre no aparece en ningún protocolo.

Quien entiende los 16 meses como un aplazamiento, los pierde. Quien los entiende como una ventana de preparación, construye una estructura de control sin presión de plazos. Un modelo de responsabilidad que se sostiene en el día a día se crea en meses tranquilos. Bajo presión de plazos, se crea una tabla que nadie mantiene.

Tres decisiones que no puedes delegar

Valor derivado de la práctica, no medido en la encuesta: La primera página se sostiene hasta unos 500 empleados. Por encima de eso, se necesita un propietario designado por dominio, de lo contrario, se convierte en un teatro de centralización.

El control no es un bloque de costos

La encuesta proporciona una tarea de diseño. Los datos no dan motivo para eliminar puestos de desarrollador. Dan motivo para perfilar y aclarar responsabilidades. Solo el 4% experimenta su trabajo como devaluado. Lo que sobrecarga a los encuestados es la soledad de la aprobación.

El dividendo no desaparece porque la técnica no ofrece lo suficiente. Desaparece en un trabajo que nadie ha pedido: invisible, por lo tanto no planificado, por lo tanto no pagado. Y como nadie lo ha pedido, tampoco nadie se responsabiliza de él. Excepto el individuo que aprueba. Soberano es quien reconoce el trabajo de revisión como trabajo y le da un nombre antes de que el azar lo asigne.

Preguntas frecuentes

Fuente de la imagen: generada por IA (julio 2026). Diagramas: Asociación de Software Python.