Cuando vas al supermercado y escoges un producto, en el envase pone de dónde viene. País de origen, condiciones de producción, si es ecológico o no. No ves el proceso, pero tienes información suficiente para decidir si confías en él. 

Ahora piensa en el software que adquieres para operar tu Data Center: el sistema DCiM que gestiona tu inventario físico; el BMS que controla el cooling accesos y seguridad; las herramientas de monitorización de las que depende tu operación cada día. 

¿Sabes cómo fue desarrollado? ¿Qué proceso de QA lleva detrás? ¿Alguien lo validó en condiciones adversas antes de llegar a ti? 

Probablemente no. Y hasta hace poco, tampoco importaba demasiado preguntarlo, lo que existía es una relación de confianza o cuanto menos no nos planteábamos cómo había sido el proceso de desarrollo en nuestro sector. 

Sin embargo, algo está cambiando. El desarrollo de software con IA y agentes es ya una realidad en muchos equipos. Mi compañero Sergio lo analizaba hace unos días con mucho criterio: la promesa de construir aplicaciones en horas, de que cualquiera puede generar código funcional sin escribir una sola línea manualmente, de que el rol del desarrollador queda transformado casi de un día para otro. Últimamente los conceptos y palabras raras que eran propietarios del entorno de desarrollo y producto digital, han llegado a nuestro vocabulario del día a día, y no sé si eso es bueno o es malo. 

El uso de agentes y de IA en la creación de productos digitales tiene en muchos contextos sentido. En aquellos casos más tipo testing, donde la velocidad tiene valor, en entornos académicos, donde el aprendizaje es la base, pero ¿y en las aplicaciones productivas? ¿Y más allá en las aplicaciones productivas de entornos de misión crítica como las comunicaciones, transporte de energía, navegación aérea o por supuesto los Data Centers? 

Hay una consecuencia de esta tendencia que casi nadie está mencionando: dentro de dos o tres años, una parte del software empresarial que está llegando al mercado habrá sido desarrollado con procesos radicalmente distintos a los de antes. Más rápidos, más automáticos, con equipos más pequeños, con testing más ligero. Y tú, como comprador, no tendrás forma de saberlo mirando la caja sin embargo, estarán presentes en entornos donde el software tome decisiones con impacto real. 

De forma habitual en B2B compramos software como si compráramos un producto terminado. Lo evaluamos por lo que hace, no por cómo fue construido. Y durante décadas, eso ha funcionado razonablemente bien porque los procesos de desarrollo tenían fricciones naturales que actuaban como filtro: los equipos eran grandes, los ciclos eran largos, las revisiones existían aunque fueran imperfectas, porque nada es perfecto, pero existía un gran control: nos importaba la seguridad, más que la velocidad. 

Y yo me pregunto, ¿cuanto tiempo más nos importará la seguridad que la velocidad?  

Y entonces ¿qué hacemos?

No tengo una respuesta definitiva. Pero sí tengo claro qué tipo de preguntas deberían poder responderse antes de firmar un contrato de software para un entorno crítico: 

 ¿Qué porcentaje del código ha sido revisado por personas con conocimiento del                     dominio, no solo del lenguaje? 

 ¿Cómo se ha probado el comportamiento en condiciones de fallo, no solo en el camino         feliz? 

 ¿Hay trazabilidad del proceso de desarrollo: quién decidió qué, cuándo y por qué?¿Está           documentado el código? 

 ¿Qué ocurre cuando algo falla en producción y cómo se puede intervenir? 

No soy desarrolladora ni siquiera me hallo cerca, y probablemente hay otras tantas preguntas mucho más interesantes para preguntarse, no sé si son estas o cuales, pero tengo claro que debemos comenzar a pensar en ellas.

La trazabilidad como diferenciador voluntario

No estoy a favor siempre de las regulaciones, pero sí lo estoy acerca de la transparencia, no es que tenga que venir necesariamente de un regulador (aunque el AI Act europeo ya empieza a apuntar en esa dirección para ciertos sistemas de alto riesgo), creo que la oportunidad más interesante es para los propios vendors, aquellos que de forma voluntaria pongan en manos del usuario sus sistemas de calidad. Sin ello no estoy tan convencida de que vayamos a dar un salto en la automatización de los procesos tan críticos como los que suceden en un Data Center. 

En un mercado donde todo el mundo va a poder decir que su software "tiene IA" y fue desarrollado "con las últimas tecnologías", la transparencia sobre el proceso puede convertirse en un argumento para transmitir confianza. No «qué hace nuestro producto», sino «así lo construimos y así lo validamos». 

Es lo mismo que pasó con la trazabilidad alimentaria. Nadie la exigía. Después hubo una crisis, el mercado la demandó, y quienes ya tenían el proceso documentado salieron ganando. Los que no, tuvieron que correr. 

La pregunta que me hago es si el sector del software empresarial va a esperar a la crisis para plantearse esto, o si alguien va a moverse antes. 

Reflexión final

No sé cómo debería llamarse esto. ¿Un sello? ¿Una declaración de proceso? ¿Una auditoría de desarrollo? Probablemente no es una sola cosa, sino una combinación que depende del sector y del nivel de criticidad. 

Lo que sí tengo claro es que comprar software para entornos críticos sin saber nada del proceso que hay detrás va a ser, cada vez más, un riesgo que alguien tendrá que asumir explícitamente. Y ese alguien normalmente no es el vendor. Es el que firma la compra. 

Así que la pregunta que os dejo es sencilla: ¿le preguntaríais a vuestro proveedor de software cómo fue desarrollado lo que os está vendiendo? ¿Y si la respuesta fuera "con agentes de IA en tres semanas", firmaríais igual? 

Porque yo, antes de responder, necesitaría saber bastante más.