Google paga a los editores por las respuestas de IA
Benedikt Langer
4 min de lectura Google paga en el «AI contribution pilot» a unos 100 editores digitales según la ...
Leer artículo
7 min de lectura
La inteligencia artificial escribe en 2026 una parte cada vez mayor del código empresarial; las encuestas del sector hablan de hasta un 40 %. Si este código falla en producción o se abre una brecha de seguridad, comienza en el consejo de administración un incómodo juego: ¿quién fue realmente? La respuesta suele ser sorprendentemente difusa.
Lo más importante en resumen
- La cuota crece rápidamente: Una parte considerable del nuevo código se genera hoy con asistentes de IA. Con ello, también aumenta el número de errores que nadie escribió de forma consciente.
- La responsabilidad está sin aclarar: Si se pregunta quién responde por un error causado por la IA, las respuestas apuntan en tres direcciones: desarrollo, seguridad y proveedor. Justo ahí radica el problema.
- La gobernanza va por detrás: Casi todas las empresas prueban herramientas de codificación con IA y los primeros agentes, pero solo una minoría ha establecido reglas de control vinculantes. La velocidad gana a la supervisión.
- El CIO debe establecer puntos de control: Sin la obligación de revisión, una clara titularidad y una cadena de responsabilidad, el código de IA sigue siendo un riesgo con fecha de caducidad.
Relacionado:Cuatro obstáculos: por qué los proyectos de IA no logran pasar a operación regular / Cuando un modelo de IA desaparece de la noche a la mañana
Cuánto código escribe realmente la IA
Las cifras varían según la fuente, pero la tendencia es clara. Las encuestas del sector estiman que la cuota de IA en el código recién escrito para 2026 se sitúa en un valor cercano al 40 %, con una tendencia al alza. En muchos equipos de desarrollo, el asistente de IA ya no es un experimento, sino parte de la actividad diaria.
¿Qué es el código generado por IA? Se refiere al código fuente que un asistente de IA como Copilot, Cursor o una herramienta con agentes genera a partir de una instrucción, y que un humano asume, adapta o introduce sin cambios en la aplicación. La responsabilidad sobre el resultado sigue recaendo formalmente en la empresa, pero la autoría en detalle se vuelve difusa.
Junto con esta cuota, crece una segunda cifra de la que se habla con menos frecuencia. Las encuestas del sector del software indican que el código generado con apoyo de IA contiene notablemente más vulnerabilidades y, sin un control riguroso, hace que la deuda técnica aumente considerablemente. La velocidad genera volumen, y el volumen sin revisión genera riesgo.
Código de IA en la empresa, 2026
alrededor del 40 % del nuevo código se genera, según las encuestas del sector, con apoyo de IA.
una de cada cinco empresas informa, según las encuestas del sector, de un incidente grave atribuible a código generado por IA.
solo una minoría cuenta con un enfoque de gobernanza centralizado para herramientas de IA, aunque casi todas las prueban.
El vacío de responsabilidad: cuando nadie es responsable
El verdadero explosivo no está en la tasa de errores, sino en la responsabilidad. Si preguntamos en las empresas quién es responsable de un daño causado por código de IA, las respuestas se distribuyen entre tres grupos. El desarrollo remite al herramienta, la seguridad lo envía al desarrollo, y ambos miran al proveedor, cuyo contrato limita fuertemente la garantía.
Para un C-Level, este es un patrón conocido con un nuevo disfraz. Una responsabilidad que todos comparten, al final no la lleva nadie. Mientras no quede claro quién da el visto bueno a un commit de IA y se hace responsable de sus consecuencias, falta la cadena de responsabilidad. Queda una brecha, y en caso de daños, la cubre el consejo de administración, queriendo o no.
A esto se suma un problema práctico que los directores de TI experimentados conocen bien de cualquier sistema maduro. El código de IA suele ser más difícil de mantener que el escrito a mano, porque carece del entendimiento implícito que surge al escribirlo uno mismo. Cuando el prompt original se olvida y el desarrollador ya ha cambiado de trabajo, queda un fragmento de software que funciona hasta que deja de hacerlo.
Un escenario típico lo ilustra claramente. Un asistente de IA sugiere una función de biblioteca, un desarrollador la acepta bajo presión de tiempo, y el revisor la aprueba como código estándar. Weeks después, exactamente esta función crea una brecha, porque la IA recomendó una versión antigua y vulnerable. En el post-mortem, todos señalan a los demás, y el CIO explica al consejo de administración un incidente que nadie provocó conscientemente. Este patrón se repite mientras que la aprobación no tenga un rostro.
Lo que se pone en juego sin gobernanza
Sin reglas de control, tres riesgos se suman, cada uno manejable por separado, pero juntos resultan costosos. Una simple comparación muestra dónde radica la diferencia entre código de IA revisado y no revisado.
| Dimensión | Código de IA sin puerta de entrada | Código de IA con puerta de entrada |
|---|---|---|
| Seguridad | Más puntos débiles, descubiertos tarde | Escaneo y revisión antes del merge |
| Mantenibilidad | Deuda técnica crece silenciosamente | Documentación y pruebas obligatorias |
| Responsabilidad | Responsabilidad interna no clara | Propietario claro por commit |
La tabla parece sencilla, pero la diferencia no lo es. Una puerta de entrada exige una decisión organizativa, no una nueva herramienta. Muchos proyectos fracasan precisamente aquí, porque delegan el tema en la elección de herramientas, aunque sea una decisión de liderazgo.
Las puertas que un CIO debe establecer ahora
El camino fuera del vacío pasa por unas pocas reglas duras que se anclan en el proceso de desarrollo. Cuatro de ellas merecen atención inmediata.
- Revisión obligatoria para código de inteligencia artificial. Cada commit generado por IA pasa por la misma revisión humana que el código escrito a mano, más un escaneo automatizado de seguridad antes de la fusión.
- Un propietario por commit. Quien asume el código de IA, asume la responsabilidad. La aprobación lleva un nombre, no un logotipo de herramienta.
- Mantener la trazabilidad de la procedencia. ¿De qué asistente proviene cada parte y con qué instrucción? Esta pista determina en caso de daño cuántas horas en lugar de semanas se tarda en buscar el error.
- Aclarar la situación contractual con el proveedor. Antes de implementar una herramienta a gran escala, la área legal verifica lo que el proveedor garantiza. Las promesas suelen ser limitadas y deben leerse en cada caso individual.
Ninguno de estos cuatro puntos exige un presupuesto adicional, todos exigen una decisión. Precisamente aquí se separa la intención de la implementación. Una puerta que esté directamente en la pipeline de construcción tiene efecto. Una puerta que solo esté en una política que nadie lee, cuesta papel y nada más. Los líderes IT experimentados anclan la obligación técnicamente, para que también funcione a las tres de la madrugada, cuando la presión por el plazo es máxima y la tentación de acelerar es mayor.
Quién en la empresa asume la responsabilidad
Las reglas sin dueños no tienen efecto. Por eso, cada decisión de puerta debe tener una función que la haga efectiva. En la práctica, se ha demostrado útil una división delgada: una persona con responsabilidad general de IA a nivel de dirección, dueños designados por herramienta con responsabilidad de resultados, representantes de seguridad para la evaluación de riesgos y gerentes de ingeniería para la supervisión diaria.
Es importante que estas funciones estén presentes antes del próximo incidente, no después. Un consejero delegado que permita código de IA sin distribuir la responsabilidad pospone el problema solo al día del primer incidente grave. Las empresas que ahora establecen una cadena de responsabilidad se aseguran la capacidad de poder responsabilizar la IA en el código. Quien se niegue a ello pospone el problema solo al siguiente incidente.
Preguntas frecuentes
¿Quién es responsable si el código generado por IA causa un daño?
Legalmente, la responsabilidad recae en la empresa que implementa el código. A nivel interno, la competencia suele estar poco clara y se reparte entre desarrollo, Security y proveedores. Una cadena de responsabilidad clara con un Owner designado por cada Commit cierra esta brecha.
¿Cuánto código escribe la IA en las empresas?
Los estudios del sector estiman que la proporción de código generado con ayuda de la IA para 2026 alcanzará un valor cercano al 40 por ciento, con una tendencia al alza. En muchos equipos, el asistente de IA ya es una herramienta estándar.
¿Es el código de IA más inseguro que el escrito a mano?
Sin control, tendencialmente sí. Los estudios informan de más vulnerabilidades y de una deuda técnica que crece rápidamente. Con un Review obligatorio y un escaneo de seguridad antes de la integración, la diferencia se puede reducir significativamente.
¿Qué Gates necesita una empresa como mínimo?
Cuatro son centrales: un Review humano junto con un escaneo de seguridad automático antes de la integración, un responsable designado por cada aportación de código, un origen del código trazable y una situación contractual clara con el proveedor de la herramienta.
¿Quién debería ser responsable de la Gobernanza del código de IA?
Lo ideal es una persona con responsabilidad global de IA a nivel directivo, complementada con Tool-Owners con responsabilidad de resultados, Security para la evaluación de riesgos y Engineering-Managers para la supervisión diaria.
Más de la red de MBF Media
Fuente de la imagen: generada por IA (Juni 2026)
Traducido del original en alemán con inteligencia artificial. La versión alemana es la de referencia.