En un monocultivo, una única especie o tipo domina un sistema, excluyendo a todas las demás. Este término nació en la agricultura: cuando un campo se planta enteramente con una sola cosecha. Puede ser eficiente y fácil de gestionar, pero un solo brote de enfermedad, plaga o cambio ambiental puede arruinar todo el rendimiento. Diversas variedades aportan vulnerabilidades distintas y, por lo tanto, un campo de cultivos variados puede contener el daño de forma natural. Un monocultivo no tiene esa defensa.

Esa misma condición de monocultivo está now ocurriendo en el desarrollo de software. Muchas organizaciones que utilizan herramientas de IA para la codificación confían en un único modelo de IA para generar código y para revisarlo. En el papel, esto parece eficiente; en la práctica, crea un bucle cerrado donde el revisor no puede detectar aquello a lo que el generador es ciego.

Las fallas de seguridad quedan a menudo ocultas en las revisiones y las decisiones arquitectónicas subóptimas no se cuestionan porque el sistema de revisión comparte las mismas suposiciones que el sistema que produjo el código.

Cuando surgen problemas, los ingenieros revisan commits recientes, fallos en despliegues y cambios de configuración. Se supone que un único ecosistema de IA puede revisar objetivamente su propia salida, pero esa premisa rara vez se cuestiona.

La solución en la agricultura ante un monocultivo es introducir variedades de cultivo diferentes con vulnerabilidades distintas, de modo que ninguna amenaza única pueda devastar todo el campo. Lo mismo ocurre con el monocultivo de IA en la codificación: las organizaciones deben incorporar herramientas de IA que sean realmente independientes de los sistemas que evalúan.

Separación de funciones

Entonces, ¿por qué no puede la misma IA revisar su propio trabajo?

Pedir a un asistente de codificación que revise su propio trabajo es como pedir a un humano que corrija su propia escritura. El humano puede detectar errores tipográficos y gramaticales, pero a menudo no detecta inconsistencias lógicas o argumentos que no sostienen. Esto se debe a que el escritor humano suele leer subconscientemente lo que quiso escribir, no lo que está realmente en la página. Un modelo que revisa su salida hace lo mismo: evalúa la salida contra los mismos patrones y objetivos que la produjeron inicialmente.

Del mismo modo, un modelo de IA entrenado con los mismos datos y optimizado para las mismas señales que el modelo que escribió el código tendrá los mismos sesgos. Detectará lo que es capaz de detectar y pasará por alto lo que el modelo generador pasó por alto.

La experiencia en finanzas resolvió este principio de separación de funciones. Si la persona que inicia una transacción también la aprueba, se abren puertas a transacciones fraudulentas o erróneas. La aprobación solo funciona si el aprobador es independiente de la persona que inició la transacción.

De igual manera, las organizaciones deben introducir una herramienta de revisión dedicada que opere de forma independiente del sistema que generó el código. Elegir un proveedor distinto no resuelve automáticamente el problema si los modelos subyacentes comparten los mismos datos de entrenamiento o las mismas suposiciones arquitectónicas.

La independencia auténtica requiere datos de entrenamiento diferentes y señales distintas; la herramienta debe estar diseñada específicamente para escrutinio, no para completar.

Defensa en profundidad.

Defensa en profundidad

Una herramienta de revisión dedicada es un punto de partida sólido, pero la separación de funciones por sí sola no basta. El mismo principio que aconseja no depender de una única IA para todo también se aplica dentro de la propia función de revisión.

La revisión de código no es una tarea única. Encontrar errores, hacer cumplir estándares, evaluar riesgos y entender cómo un cambio encaja en el sistema más amplio son diferentes formas de razonamiento, incluso cuando aparecen en la misma solicitud de extracción (pull request).

Pedir a un único agente que maneje todas esas tareas a la vez fuerza compensaciones entre profundidad, velocidad y cobertura. En otras palabras, algunas cosas recibirán menos atención de la que requieren.

Así como una arquitectura de seguridad madura aplica controles independientes en capas para que lo que una falla sea detectado por otra, una arquitectura de revisión madura asigna responsabilidades distintas a sistemas optimizados para cada tarea.

En la práctica, eso podría significar un primer agente enfocado específicamente en vulnerabilidades de seguridad, otro que aplique estándares arquitectónicos y convención de codificación, un tercero que evalúe el radio de explosión (blast radius) de un cambio, y un revisor humano que tome la decisión final sobre cualquier elemento de alto riesgo.

Cada capa plantea preguntas distintas y opera con señales diferentes. El objetivo es asegurar que ningún punto ciego, incluidos aquellos compartidos por una monocultura de IA, permita que un problema pase sin ser cuestionado.

El rol cambiante de la ingeniería de plataformas

A medida que IA genera una mayor proporción de código en producción, las organizaciones necesitarán designar una propiedad clara sobre qué IA hace qué, y garantizar que la función de revisión no se colapse en la función de generación por motivos de eficiencia. Esa responsabilidad recaerá cada vez más en los equipos de ingeniería de plataformas.

Tradicionalmente, ese rol buscaba hacer a los desarrolladores más productivos mediante herramientas simplificadas, mantenimiento de infraestructura y reducción de fricciones. Ese trabajo no ha desaparecido, pero conforme los desarrolladores se mueven de escribir código ellos mismos a dirigir agentes que lo escriben para ellos, los ingenieros de plataformas deberán gobernar los sistemas que generan código, no solo mantenerlos.

Eso implica poseer los estándares que siguen esos agentes y garantizar visibilidad de lo que realmente sucede a través del código. Más importante aún, significa tratar la generación de código y la revisión de código como funciones distintas que requieren capacidades diferentes, y resistir la presión organizacional de consolidarlas en una única plataforma por ser más fácil de gestionar.

Memoria organizacional

A medida que IA maneja más de la escritura y revisión, el conocimiento institucional acumulado se pierde. ¿Por qué se tomó aquella decisión arquitectónica hace dos años? ¿Qué partes del código afectan a otras de formas no evidentes? ¿Qué falló antes y por qué? Las herramientas de IA para codificar no llevan ese contexto. Miran la tarea presente, la completan y continúan.

Este tipo de conocimiento institucional solía residir en las cabezas de los ingenieros que escribían y revisaban el código. A medida que la IA asume más de ese trabajo, debe capturarse en lugares como estándares documentados y decisiones de revisión registradas, o simplemente desaparece. Cuando las organizaciones incorporan ese tipo de memoria en su proceso de desarrollo, sus sistemas se vuelven más inteligentes sobre su base de código con el tiempo.

Eso implica una función de revisión que no solo señale problemas de forma aislada, sino que aprenda los estándares de la organización, recuerde decisiones pasadas y entienda cómo las diferentes partes del código se conectan y dependen entre sí.

Anticipar el riesgo de monocultivo

El riesgo de monocultivo de IA es aquello que sucede cuando nadie pregunta si el sistema que revisa el código es realmente independiente del sistema que lo escribió.

El CEO de Microsoft, Satya Nadella, sostuvo recientemente que la verdadera oportunidad de la IA no está en elegir el mejor modelo, sino en construir un ciclo de aprendizaje donde el conocimiento humano y la capacidad de IA se potencian mutuamente, y que una empresa debería poder intercambiar un modelo general sin perder la experiencia integrada en sus propios sistemas.

Eso solo es posible si la gobernanza se desarrolla al mismo ritmo que la capacidad de generación.

Las organizaciones que adopten ese enfoque temprano estarán en una posición mucho mejor que las que esperen a que algo se rompa.

Este artículo fue preparado como parte de TechRadar Pro Perspectives, nuestro canal para presentar las mentes más brillantes de la industria tecnológica actual.

from Latest from TechRadar https://ift.tt/0BfMczH
via IFTTT IA