Lo m\u00e1s importante en resumen<\/p>\n
- \n
- Situaci\u00f3n:<\/strong> El trabajo de desarrollo se ha convertido en trabajo de verificaci\u00f3n. El 68 por ciento menciona la curaci\u00f3n de la producci\u00f3n de IA como nueva tarea. No est\u00e1 presupuestada en ninguna parte.<\/li>\n
- Palanca:<\/strong> La aprobaci\u00f3n. Se lleva a cabo diariamente en su casa, de forma inconsciente, por la persona que hace clic en \u00abMerge\u00bb.<\/li>\n
- Consecuencia:<\/strong> Sin responsabilidad designada, en la pr\u00e1ctica el \u00faltimo en la cadena es responsable. En cada tama\u00f1o de organizaci\u00f3n, alrededor de siete de cada diez encuestados dicen esto.<\/li>\n<\/ul>\n<\/div>\n
Relacionado<\/span>La IA no sustituye puestos de trabajo, sustituye perfiles profesionales: qu\u00e9 significa esto para la contrataci\u00f3n de ejecutivos<\/a> \/<\/span> IA local: gobernanza antes de la compra de hardware<\/a><\/p>\n
All\u00ed donde se decide el uso de la IA, las preguntas son: \u00bfQu\u00e9 ahorramos? \u00bfC\u00f3mo ganamos productividad? El despliegue est\u00e1 pagado, las licencias est\u00e1n en curso, la rentabilidad est\u00e1 prometida. Alguna vez alguien quiere verla.<\/p>\n
En junio de 2026, la Asociaci\u00f3n de Software Python pregunt\u00f3 en la comunidad PyCon-DE. Han respondido 383 desarrolladores de software, cient\u00edficos de datos e ingenieros de IA. En ninguna de las m\u00e1s de 1.000 respuestas alguien informa de una reducci\u00f3n 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\u00e1sico. El dividendo existe, pues. Sin embargo, en el equipo llega como una expectativa. No surge capacidad libre a partir de ello.<\/p>\n
El trabajo no desaparece. Cambia de car\u00e1cter.<\/h2>\n
El 96 por ciento utiliza herramientas de inteligencia artificial al menos varias veces al d\u00eda. Se delega lo que se puede delegar: c\u00f3digo nuevo (76 por ciento), investigaci\u00f3n (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\u00f3n y curaci\u00f3n de la salida de la inteligencia artificial. El conocimiento del dominio, el dise\u00f1o del sistema y la comunicaci\u00f3n de requisitos ganan valor. Es decir, exactamente las habilidades cuya calidad requiere un juicio humano.<\/p>\n
La sustituci\u00f3n tiene lugar, pero a nivel de actividad en lugar de a nivel de puesto. De la producci\u00f3n se pasa a la verificaci\u00f3n. Y la verificaci\u00f3n no es una tarea rutinaria: cuesta tiempo, requiere juicio y conlleva responsabilidad. No se puede hojear el c\u00f3digo, las l\u00edneas de acci\u00f3n se conectan solo en el \u00faltimo cap\u00edtulo.<\/p>\n
\nUn ejemplo num\u00e9rico<\/p>\n
1,8 millones de euros.<\/strong> Este ser\u00eda el potencial de automatizaci\u00f3n calculado para 100 desarrolladores con un costo total de 120.000 euros, si la mitad del d\u00eda es rutinario y el 30 por ciento de eso se automatiza. Esto equivale a 15 equivalentes de tiempo completo. Estos dos supuestos no provienen de la encuesta. Son la raz\u00f3n para medir en lugar de estimar en casa.<\/span><\/p>\n<\/div>\n
Debido a que el trabajo de verificaci\u00f3n no est\u00e1 en ning\u00fan plan, no se ve ni se presupuesta. El 16 por ciento se siente abrumado al final de un d\u00eda de inteligencia artificial, en las corporaciones uno de cada cinco. La planificaci\u00f3n de Velocity no conoce ninguna posici\u00f3n para este trabajo. Y debido a que no tiene un propietario, la responsabilidad por sus errores recae en el \u00faltimo en la cadena: en la persona que hace clic en \u00abMerge\u00bb.<\/p>\n
Cuanto mayor es la casa, menor es el dividendo<\/h2>\n
Se podr\u00eda asumir que este es un problema de organizaciones peque\u00f1as y no estructuradas. Es lo contrario. A medida que aumenta el tama\u00f1o, el trabajo de verificaci\u00f3n aumenta del 64 por ciento en organizaciones con menos de 50 empleados al 76 por ciento en organizaciones con m\u00e1s de 5.000. La incertidumbre sobre la responsabilidad crece con \u00e9l y es el mayor obst\u00e1culo mencionado en las corporaciones, antes que la calidad de los datos, los sistemas heredados y la seguridad. La ganancia de automatizaci\u00f3n, por otro lado, no crece con el tama\u00f1o: en casas peque\u00f1as, un tercio m\u00e1s automatiza m\u00e1s de la mitad de las tareas rutinarias que en las corporaciones.<\/p>\n
![\"Gr\u00e1fico](\"https:\/\/www.digital-chiefs.de\/wp-content\/uploads\/2026\/07\/pysv-2026-organisationsgroesse-luecke.png\")
La carga de verificaci\u00f3n aumenta con el tama\u00f1o, no la ganancia. Fuente: Encuesta de la Asociaci\u00f3n de Software Python, junio de 2026.<\/figcaption><\/figure>\n As\u00ed pues, las grandes casas obtienen un dividendo menor con una mayor carga de verificaci\u00f3n. El tama\u00f1o tampoco protege contra la responsabilidad. Alrededor de siete de cada diez encuestados en organizaciones con m\u00e1s de 5.000 empleados dicen que la responsabilidad por un error causado por la inteligencia artificial no est\u00e1 expl\u00edcitamente regulada y recae \u0444\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438 en el desarrollador que ha tomado el c\u00f3digo. En casas con menos de 50 empleados es lo mismo. Cumplimiento, revisi\u00f3n de corporaciones, consejo de empresa: en este punto no cambian nada. Un marco documentado con obligaci\u00f3n de revisi\u00f3n, aprobaci\u00f3n nominal y pista de auditor\u00eda lo tienen en las corporaciones el 14 por ciento. Otro 9 por ciento ni siquiera sabe si existe.<\/p>\n
![\"Gr\u00e1fico](\"https:\/\/www.digital-chiefs.de\/wp-content\/uploads\/2026\/07\/pysv-2026-haftungsfrage-offen-v2.png\")
La cuesti\u00f3n de la responsabilidad est\u00e1 abierta en cada clase de tama\u00f1o. Fuente: Encuesta de la Asociaci\u00f3n de Software Python, junio de 2026.<\/figcaption><\/figure>\n La misma m\u00e1quina escribe el c\u00f3digo y proporciona la se\u00f1al de calidad<\/h2>\n
Alrededor de uno de cada seis participantes ha descrito adem\u00e1s un incidente concreto. Los informes muestran un patr\u00f3n costoso: La se\u00f1al de prueba en s\u00ed proviene de la m\u00e1quina.<\/p>\n
Un senior en una empresa de energ\u00eda revisa una solicitud de extracci\u00f3n de IA y queda impresionado por un m\u00e9todo de prueba elegante. Al leerlo por segunda vez, las pruebas no tienen sentido, aunque se ejecutan correctamente. En una empresa de log\u00edstica, el agente reescribe la prueba que falla tantas veces hasta que pasa. El error solo se detecta durante el despliegue y la b\u00fasqueda de la causa lleva d\u00edas. En el sector farmac\u00e9utico, despu\u00e9s de medio a\u00f1o de desarrollo guiado por IA, se encuentran 23.000 l\u00edneas de documentaci\u00f3n generada que nadie ha le\u00eddo. Todas las pruebas est\u00e1n en verde. Comprueban los requisitos generados por IA frente al c\u00f3digo generado por IA. Los tres informes provienen de organizaciones con m\u00e1s de 500 empleados.<\/p>\n
\u201eSucede a menudo al generar c\u00f3digo que las versiones de paquetes simplemente se inventan. Si se conf\u00eda ciegamente en ello, se cae r\u00e1pidamente en un torbellino de alucinaciones y depuraci\u00f3n en el lugar equivocado.\u201c
\n\u2013 Respuesta de texto libre de la encuesta, junio de 2026<\/cite><\/p><\/blockquote>\nLa alucinaci\u00f3n, 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\u00f3n manual, el 76% ejecuta pruebas. Solo el 30% tiene una evaluaci\u00f3n formal, es decir, un conjunto de pruebas versionado que permite medir si un sistema resuelve una tarea de manera fiable. El 14% se f\u00eda principalmente de su instinto. Mientras tanto, la confianza en la salida ha aumentado al 58%.<\/p>\n
![\"Gr\u00e1fico](\"https:\/\/www.digital-chiefs.de\/wp-content\/uploads\/2026\/07\/pysv-2026-vertrauen-kontrolle.png\")
La revisi\u00f3n manual soporta la carga, la evaluaci\u00f3n formal sigue siendo la excepci\u00f3n. Fuente: Encuesta de la Asociaci\u00f3n de Software Python, junio de 2026.<\/figcaption><\/figure>\n Cuatro niveles act\u00faan de manera plausible. Nadie decide.<\/h2>\n
Como principal cuello de botella, los encuestados mencionan la falta de claridad en las responsabilidades (40 por ciento), seguida de la seguridad, la protecci\u00f3n 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\u00faa de acuerdo con su perspectiva de manera comprensible. Sin embargo, la decisi\u00f3n sigue siendo un vac\u00edo.<\/p>\n
\n\n\n
\n \nNivel y su expectativa<\/th>\n La decisi\u00f3n que deber\u00eda tomar<\/th>\n<\/tr>\n<\/thead>\n \n La direcci\u00f3n<\/strong> espera velocidad y el rendimiento prometido del despliegue.<\/td>\n \u00bfCu\u00e1nto trabajo de verificaci\u00f3n vale la pena la velocidad? \u00bfEn qu\u00e9 presupuesto se encuentra?<\/td>\n<\/tr>\n \n Ingenier\u00eda<\/strong> proporciona velocidad, verifica seg\u00fan su mejor conocimiento y asume \uc0ac\uc2e4\uc0c1 la aprobaci\u00f3n.<\/td>\n \u00bfQu\u00e9 aprobaci\u00f3n puede otorgar una sola persona? \u00bfA partir de d\u00f3nde se necesita una segunda firma?<\/td>\n<\/tr>\n \n Seguridad y Cumplimiento<\/strong> verifican sistemas que se crean m\u00e1s r\u00e1pido que cualquier lista de aprobaciones.<\/td>\n \u00bfCu\u00e1l es el objeto de control: la herramienta, el modelo o el caso de uso?<\/td>\n<\/tr>\n \n \u00c1rea especializado<\/strong> utiliza los resultados sin ser responsable de su generaci\u00f3n.<\/td>\n \u00bfQui\u00e9n define qu\u00e9 significa \u00abcorrecto\u00bb? \u00bfDe qui\u00e9n es el conjunto de pruebas que lo demuestra?<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Cada nivel puede asumir leg\u00edtimamente que otro es responsable<\/p>\n
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\u00f3digo generado no puede se\u00f1alar a otro nivel. Si solo puede cerrar una de las cuatro preguntas, cierre la segunda. Es la \u00fanica que se decide todos los d\u00edas en su casa, aunque de manera inconsciente.<\/p>\n
Cu\u00e1nto costar\u00e1 esto se muestra en el informe m\u00e1s duro de la encuesta. En una peque\u00f1a casa de software, las lagunas de seguridad masivas del uso intensivo de IA solo se detectan despu\u00e9s de que el empleado en cuesti\u00f3n abandon\u00f3 la empresa. Resultado: nuevo desarrollo completo. Si el conocimiento de control y la responsabilidad de aprobaci\u00f3n dependen de una persona, esa persona abandona la casa con parte de la capacidad de control. El da\u00f1o permanece.<\/p>\n
El plazo ha cambiado. La responsabilidad no.<\/h2>\n
Una parte significativa de la presi\u00f3n regulatoria acaba de disminuir. A finales de junio de 2026, el Consejo de la UE confirm\u00f3 definitivamente el Digital Omnibus: las obligaciones para los sistemas de alto riesgo seg\u00fan 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\u00e9ditos, solicitudes o infraestructura cr\u00edtica. Los requisitos sustantivos permanecen sin cambios.<\/p>\n
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\u00e1s lento. El reloj operativo sigue funcionando sin cambios. El error que un agente escribe en su producci\u00f3n la pr\u00f3xima semana no espera a Bruselas. La responsabilidad operativa surge con la aprobaci\u00f3n. Y las aprobaciones tienen lugar diariamente en su casa, en un 90 por ciento en la revisi\u00f3n manual de una sola persona, cuyo nombre no aparece en ning\u00fan protocolo.<\/p>\n
Quien entiende los 16 meses como un aplazamiento, los pierde. Quien los entiende como una ventana de preparaci\u00f3n, construye una estructura de control sin presi\u00f3n de plazos. Un modelo de responsabilidad que se sostiene en el d\u00eda a d\u00eda se crea en meses tranquilos. Bajo presi\u00f3n de plazos, se crea una tabla que nadie mantiene.<\/p>\n
Tres decisiones que no puedes delegar<\/h2>\n
\nQu\u00e9 hay que resolver en los pr\u00f3ximos dos trimestres<\/div>\n\n\nMedir<\/div>\nDurante dos sprints, registrar cu\u00e1nto tiempo se dedica realmente a revisar y seleccionar la salida de la IA. Comparar el n\u00famero con el ejemplo de c\u00e1lculo anterior. De lo contrario, cualquier discusi\u00f3n sobre el rendimiento es una afirmaci\u00f3n contra otra.<\/div>\n<\/div>\n\nAsignar<\/div>\nUn modelo de responsabilidad, una p\u00e1gina con nombres: qui\u00e9n aprueba, qui\u00e9n se responsabiliza en caso de error, qu\u00e9 se documenta. Los roles no son suficientes. Pero una aprobaci\u00f3n con dos ojos por commit es un overhead que no aporta nada. La segunda firma debe estar donde un error afecta a los datos de producci\u00f3n o a las interfaces de cliente.<\/div>\n<\/div>\n\nTransferir<\/div>\nEl 90% de revisi\u00f3n manual con un 30% de evaluaci\u00f3n formal es un cuello de botella anunciado. Empezar poco a poco: 20 a 50 casos documentados de la propia historia de errores, en propiedad del \u00e1rea de negocio en lugar del equipo de herramientas. La \u00fanica inversi\u00f3n que gana valor con cada cambio de modelo.<\/div>\n<\/div>\n<\/div>\n<\/div>\nValor derivado de la pr\u00e1ctica, no medido en la encuesta: La primera p\u00e1gina 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\u00f3n.<\/p>\n
El control no es un bloque de costos<\/h2>\n
La encuesta proporciona una tarea de dise\u00f1o. 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\u00f3n.<\/p>\n
El dividendo no desaparece porque la t\u00e9cnica 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 \u00e9l. Excepto el individuo que aprueba. Soberano es quien reconoce el trabajo de revisi\u00f3n como trabajo y le da un nombre antes de que el azar lo asigne.<\/p>\n
\nSobre la encuesta<\/p>\n
En junio de 2026, la Asociaci\u00f3n de Software Python entrevist\u00f3 a 383 desarrolladores de software, cient\u00edficos de datos e ingenieros de IA de la comunidad PyCon-DE sobre la IA en el trabajo diario, los perfiles de tareas, la gobernanza y la carga de trabajo. La participaci\u00f3n fue voluntaria, la muestra es auto seleccionada y predominantemente de nivel senior; cuatro de cada cinco respuestas proceden de Alemania. Los porcentajes se refieren a la pregunta respectiva y pueden sumar m\u00e1s del 100% en el caso de varias respuestas. Los resultados individuales son p\u00fablicamente visibles.<\/a><\/p>\n<\/div>\n
Preguntas frecuentes<\/h2>\n
\n\u00bfEs la brecha de firmas un tema de cumplimiento?<\/summary>\n
Surge antes. El cumplimiento verifica lo que se le presenta. La aprobaci\u00f3n de una fusi\u00f3n generada por IA nunca se le presentar\u00e1, porque no est\u00e1 en ning\u00fan proceso. Por lo tanto, la revisi\u00f3n corporativa y el consejo de empresa no cambian nada en este punto.<\/p>\n<\/details>\n
\nTenemos un documento de gobernanza de herramientas de IA. \u00bfEs suficiente?<\/summary>\n
Eso regula principalmente la adquisici\u00f3n. La encuesta muestra la brecha detr\u00e1s: en el caso de pilas abiertas y agentes auto-construidos, el 46% de los desarrolladores en grandes empresas sigue decidiendo por s\u00ed mismo sobre el uso. Un cat\u00e1logo de herramientas no es una regla de aprobaci\u00f3n.<\/p>\n<\/details>\n
\n\u00bfSignifica m\u00e1s trabajo de verificaci\u00f3n que podemos recortar desarrolladores?<\/summary>\n
Los datos dicen lo contrario. En m\u00e1s de 1.000 respuestas, nadie informa sobre recortes concretos de personal debido a la IA. Alrededor de un tercio de las brechas de personal reportadas afecta el desarrollo de software cl\u00e1sico. Lo que cambia es el perfil: el conocimiento del dominio y el dise\u00f1o del sistema ganan, la producci\u00f3n pura de c\u00f3digo pierde.<\/p>\n<\/details>\n
\n\u00bfNos da el Digital Omnibus 16 meses de margen?<\/summary>\n
Reguladoramente para parte de las obligaciones de alto riesgo, s\u00ed, pero operacionalmente no. Los requisitos sustantivos permanecen sin cambios. La responsabilidad por un error en la producci\u00f3n surge con la aprobaci\u00f3n.<\/p>\n<\/details>\n
\n\u00bfCon qu\u00e9 se empieza cuando falta el presupuesto para un programa?<\/summary>\n
Con dos sprints de medici\u00f3n. Mientras nadie sepa cu\u00e1nto tiempo realmente se invierte en trabajo de verificaci\u00f3n, cualquier discusi\u00f3n sobre el presupuesto es una afirmaci\u00f3n contra otra. La medici\u00f3n no cuesta nada excepto atenci\u00f3n.<\/p>\n<\/details>\n
\nAlexander C. S. Hendorf<\/strong> es presidente de la Asociaci\u00f3n de Software Python e. V. y co-iniciador de la PyCon DE. Ha trabajado durante m\u00e1s de dos d\u00e9cadas en la intersecci\u00f3n de Data Science, IA y desarrollo organizacional y es una voz de confianza en Digital Chiefs.<\/p>\n<\/div>\n
- Palanca:<\/strong> La aprobaci\u00f3n. Se lleva a cabo diariamente en su casa, de forma inconsciente, por la persona que hace clic en \u00abMerge\u00bb.<\/li>\n