💻 computer science

From Requirements to Production: Governing AI-Assisted Software Delivery through a Canonical Requirements Model

Este artículo presenta un estudio de ciencia del diseño que introduce un marco de gobernanza para la entrega de software asistida por IA que utiliza un modelo de requisitos canónico, un bucle de construcción y revisión de doble proveedor y documentación ejecutable para lograr una alta trazabilidad y cumplimiento a través de dos sistemas de producción independientes, al tiempo que redefine el rol del analista de negocio.

Autores originales: Mohamed Zahran

Publicado 2026-07-21

📖 7 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Mohamed Zahran

Artículo original bajo licencia CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Las Nuevas Reglas del Camino para los Constructores de Robots

Imagine que es un arquitecto maestro que ha pasado años dibujando planos para cuadrillas de construcción humanas. Sabe que si deja un pequeño hueco en los planos —como olvidar especificar el color de la puerta principal—, un constructor humano capacitado simplemente le preguntará: "Oiga, ¿de qué color la quiere?" o adivinará basándose en el estilo del vecindario. Ellos llenan los vacíos con su propio sentido común y experiencia. Así es como ha funcionado el desarrollo de software durante décadas: un humano escribe los requisitos y un equipo humano construye el software, llenando los detalles faltantes sobre la marcha.

Pero ahora, imagine que contrata a una flota de constructores robóticos súper rápidos y súper inteligentes. Estos robots son increíbles; pueden colocar ladrillos y cablear circuitos en segundos. Sin embargo, tienen un gran defecto: son literalistas. No tienen sentido común, no suponen y, ciertamente, no hacen preguntas. Si le dice a un robot "construye una puerta" pero no especifica el color, podría pintarla de verde neón porque ese es el color más lógico en su base de datos, o podría detenerse y colapsar porque no sabe qué hacer. En el mundo del software, este es el desafío del desarrollo asistido por IA. Los "requisitos" (las instrucciones) que funcionaban perfectamente para los humanos ahora son peligrosos para los robots porque los robots no pueden llenar los vacíos. Si las instrucciones no son perfectas, los robots construyen lo incorrecto, y sucede tan rápido que el error ya está en el producto final antes de que alguien lo note. Este documento explora cómo reescribir las reglas del camino para que estos constructores robóticos puedan ser confiables para construir software seguro y funcional sin necesidad de que un humano les lleve de la mano cada segundo.

De "Tal vez" a "Debe": Una Nueva Forma de Construir con IA

El documento, escrito por Mohamed Zahran, aborda un gran problema: los agentes de codificación de IA son rápidos, pero son peligrosos si las instrucciones no son perfectas. El autor argumenta que la vieja forma de escribir requisitos —documentos diseñados para equipos humanos que pueden "leer entre líneas"— está rota cuando el constructor es una máquina. Si un humano lee una instrucción incompleta, usa su cerebro para corregirla. Si un robot lee una instrucción incompleta, simplemente supone, y esa suposición a menudo se convierte en un error o un agujero de seguridad.

Para solucionar esto, el autor no solo escribió una nueva teoría; de hecho, construyó dos sistemas de software reales y funcionales utilizando un nuevo método que diseñó. Piense en ello como un chef que, en lugar de solo escribir un libro de cocina, realmente cocinó dos comidas complejas diferentes en una cocina de alto estrés para demostrar que su nueva receta funciona.

La Idea Central: La "Única Fuente de Verdad"
La solución del autor es un "Marco de Entrega Gobernado y Listo para la IA" (Governed AI-Ready Delivery Framework). El mayor cambio es alejarse de los documentos sueltos (como archivos de Word) que pueden volverse desordenados y tener versiones diferentes de lo mismo. En su lugar, creó un Modelo de Requisitos Canónico.

La Analogía: Imagine un plano digital maestro que vive en una bóveda segura. Este plano es la única versión verdadera del plan.
La Magia: A partir de este único plano maestro, el sistema genera automáticamente dos "vistas" diferentes:
1. La Vista Humana: Un documento agradable y legible para que el Analista de Negocios y los gerentes den su aprobación.
2. La Vista del Robot: Un paquete de instrucciones estricto y legible por máquinas para los agentes de codificación de IA.
Por qué importa: Debido a que ambas vistas provienen del mismo plano maestro, nunca pueden distanciarse. El humano no puede aprobar un plan que el robot no esté siguiendo realmente. Es como tener una única fuente de verdad que actualiza a todos instantáneamente.

La Regla de los "Cuatro Ojos" para Robots
El documento introduce un ingenioso control de seguridad llamado Separación de Funciones, pero para robots.

La Configuración: El autor utilizó dos herramientas de codificación de IA diferentes de dos empresas (proveedores) distintas.
El Proceso:** Una IA (Proveedor A) fue el "Constructor". Escribió el código basado en las instrucciones. Una IA completamente diferente (Proveedor B) fue el "Inspector". Revisó el código para buscar errores, agujeros de seguridad y si coincidía con el plan.
El Resultado: Esto evitó que la IA construyera una casa y luego se diera a sí misma una calificación de aprobación. La IA "Inspector" detectó cosas que la IA "Constructor" pasó por alto, tal como lo haría un equipo humano.

Los Hallazgos: Velocidad Sin Caos
El autor probó este marco en dos proyectos muy diferentes:

Caso 1: Una plataforma de salvaguarda para 170 organizaciones nacionales (un proyecto grande, complejo y de movimiento lento).
Caso 2: Un espacio de trabajo de análisis multi-inquilino para analistas de negocios (un proyecto más rápido y pequeño con reglas de seguridad adicionales para tarjetas de crédito).

Los resultados fueron impresionantes. El marco permitió que la IA trabajara increíblemente rápido manteniendo el control:

Trazabilidad: El sistema rastreó de dónde provenía cada pieza de código. En el Caso 1, el 94.9% de los requisitos estaban perfectamente vinculados al código y a las pruebas; en el Caso 2, fue el 97.8%.
Sin Ediciones No Autorizadas: En ambos casos, la tasa de cambios no autorizados fue de 0.00%. El sistema era tan estricto que nadie (ni ningún robot) pudo cambiar el código secretamente sin que el sistema lo supiera.
Menos Errores: La "tasa de escape de defectos" (errores que llegaron al producto final) fue del 9.1% en el primer caso y del 4.7% en el segundo. El segundo caso fue incluso mejor que el promedio de la industria considerado "mejor en su clase".
Velocidad: El marco no ralentizó las cosas. De hecho, el segundo proyecto se entregó en solo 31 días naturales (con solo 12 días de construcción activos), lo cual es increíblemente rápido para ese nivel de complejidad.

Lo Que el Autor Dice Que No Es la Respuesta
El documento es muy claro sobre lo que no funciona. Argumenta contra la idea de que simplemente puedes darle a una IA un prompt vago y dejar que ella resuelva el resto. También advierte que añadir IA a un proyecto solo porque está de "moda" es una mala idea; a veces, un simple cambio de proceso es mejor que usar IA en absoluto. El autor enfatiza que la IA no puede reemplazar el juicio humano, la claridad de negocio o la necesidad de que un humano apruebe el resultado final.

¿Qué tan Seguros Estamos?
El autor es cuidadoso de no afirmar que esto es una solución mágica que resolverá todo para siempre. El estudio se basa en dos casos específicos entregados por la misma persona (el autor). Aunque los resultados son muy sólidos y consistentes a través de dos tipos de proyectos muy diferentes, el autor admite que, debido a que él fue el único realizando el trabajo, no podemos estar 100% seguros de que esto funcionaría exactamente igual para un equipo de personas diferentes sin más pruebas. También descubrieron que, si bien el sistema era excelente para detectar errores obvios, a veces pasaba por alto "fallos silenciosos" (errores que no aparecen de inmediato), lo que significa que los humanos aún necesitan realizar una revisión profunda ocasionalmente.

La Gran Conclusión
El documento concluye que el rol del Analista de Negocios está cambiando. Ya no son solo escritores de documentos para otros humanos. Se están convirtiendo en los arquitectos de sistemas de control. Su trabajo es diseñar el "marco de entrega gobernado"—las reglas, los controles y el plano maestro—que permite que la IA construya software de manera segura. El futuro no se trata de humanos contra IA; se trata de humanos diseñando las instrucciones perfectas para que la IA pueda hacer el trabajo pesado sin romper nada. Como dice el autor: "En la era de la IA, el Analista de Negocios ya no se define solo por lo que escribe, sino por lo que permite que otros —humanos e IA— entreguen".

Resumen Técnico: Gobernanza de la Entrega de Software Asistida por IA mediante un Modelo de Requisitos Canónico

1. Planteamiento del Problema

El artículo identifica una desconexión fundamental entre la ingeniería de requisitos tradicional y la entrega de software asistida por IA. Los Analistas de Negocio (BA) han producido históricamente artefactos (por ejemplo, Documentos de Requisitos de Negocio, historias de usuario) diseñados para equipos de entrega humanos. Estos documentos dependen del "conocimiento tácito", el juicio de dominio y la conversación para llenar las brechas de especificación. Cuando el ejecutor cambia de un desarrollador humano calificado a un agente de codificación autónomo de IA, este contrato implícito se rompe. Los agentes de IA no infieren detalles faltantes; proceden basándose en la "interpretación más plausible", convirtiendo las especificaciones incompletas en fuentes de defectos.

Además, el artículo sostiene que el enfoque actual de la industria en la velocidad conduce a menudo a la peligrosa suposición de que la estructuración de los análisis de negocio es innecesaria. La evidencia sugiere que, sin una definición de problemas rigurosa y una gobernanza adecuada, los proyectos de IA sufren altas tasas de fracaso debido a un ajuste deficiente del flujo de trabajo, insuficiencia de datos y una débil propiedad. El problema central es la falta de un marco de gobernanza que permita a los agentes de IA ejecutar requisitos de manera confiable mientras preservan la responsabilidad humana, la trazabilidad y la separación de funciones.

2. Metodología

El estudio emplea un enfoque de Investigación de la Ciencia del Diseño (DSR). La contribución es un artefacto operativo con un propósito —un marco de entrega gobernado— construido, aplicado y refinado durante la entrega de dos sistemas independientes en producción real.

Entorno de Investigación: Dos casos distintos entregados por un único operador (el autor):
- Caso 1: Una plataforma de evaluación de salvaguarda multilingüe para 170 organizaciones nacionales (cumplimiento de GDPR/OWASP). Entregada en 17 semanas (~320 horas).
- Caso 2: Un producto SaaS de espacio de trabajo de análisis multi-inquilino para analistas de negocio (cumplimiento de GDPR + PCI DSS SAQ A). Entregado en 31 días naturales (~165 horas).
Fuentes de Datos: El estudio analizó el historial completo de control de versiones, los artefactos de gobernanza (paquetes de módulos, prompts de agentes, listas de verificación de revisión) y el código fuente de ambos sistemas.
Estrategia de Evaluación: El marco fue evaluado frente a seis medidas operativas computadas a partir de los registros de entrega. El estudio reconoce las limitaciones metodológicas, incluyendo la falta de controles previos al marco emparejados y el sesgo de un solo operador, enmarcando los resultados como demostraciones de viabilidad en lugar de afirmaciones causales estadísticamente generalizables.

3. El Artefacto Diseñado: Un Marco de Entrega Listo para IA y Gobernado

La contribución central es un marco que reingenieriza los requisitos de ayudas de comunicación a instrumentos de control ejecutables. Se basa en tres elementos diseñados:

A. El Modelo de Requisitos Canónico

El marco reemplaza los documentos dispares con un único modelo canónico versionado, $M(m, v)$ , para cualquier módulo $m$ en la línea base $v$ . Este modelo contiene:

R: Requisitos y criterios de aceptación.
D: Decisiones de arquitectura y diseño.
C: Restricciones (de negocio, técnicas, de seguridad, de accesibilidad).
T: Casos de prueba y evidencia de validación.
P: Proveniencia y relaciones de trazabilidad.
A: Estado de aprobación y responsables de la decisión.
H: Historial de versiones y cambios.

Proyecciones Controladas: Los documentos legibles por humanos (Paquetes de Aseguramiento) y los archivos legibles por máquinas (Paquetes de Agente) no son fuentes de verdad separadas. Son generados como proyecciones controladas, $O(i, m, v)$ , a partir del modelo canónico único utilizando perfiles de exportación específicos. Esto asegura que el documento que un stakeholder firma y el código que un agente ejecuta sean demostrablemente consistentes.

B. Separación de Funciones mediante el Bucle de Doble Proveedor

Para aplicar el principio de "cuatro ojos" a los agentes autónomos, el marco impone un bucle de construcción y revisión de doble proveedor:

Agente de Construcción (Build Agent): Un proveedor de IA (por ejemplo, el Proveedor A) tiene asignado generar el código y los artefactos de implementación.
Agente de Revisión (Review Agent): Un segundo proveedor de IA independiente (por ejemplo, el Proveedor B) realiza la revisión independiente, la validación de seguridad y la detección de defectos.
Puerta de Control Humana (Human Gate): Los humanos responsables firman en cada puerta. El agente de revisión no aprueba la producción; proporciona evidencia para los responsables de la toma de decisiones.

C. La Documentación como una Superficie de Control Ejecutable

Los requisitos se reingenierizan para ser explícitos, testeables y trazables. El marco incluye artefactos específicos tales como:

Paquete de Gobernanza de Construcción de IA: Define límites, acciones prohibidas y reglas de validación para el agente de construcción.
Prompt/Contrato del Revisor Independiente: Un contrato gobernado para que el agente de revisión valide contra la línea base aprobada.
Manifiesto del Paquete: Un registro legible por máquina que vincula los archivos generados con su línea base de origen, asegurando la proveniencia y detectando la deriva.

Control de Cambios: Si un requisito cambia, la propuesta regresa al modelo canónico. Tras su aprobación, se crea una nueva línea base ( $v+1$ ), y todos los productos afectados (humanos y de máquina) se regeneran simultáneamente. Esto evita la "deriva de especificación" donde los documentos humanos y las instrucciones de los agentes divergen.

4. Resultados

El marco fue evaluado a través de los dos casos utilizando seis medidas operativas. Los resultados demuestran consistencia a través de diferentes dominios, escalas y ritmos de entrega:

Medida	Caso 1 (Plataforma de Salvaguarda)	Caso 2 (SaaS de Espacio de Trabajo de Análisis)
Cobertura de Trazabilidad	94.9% (185/195 requisitos)	97.8% (496/507 requisitos)
Divergencia de Salida	0.5 divergencias sustantivas por línea base	0.0 divergencias sustantivas por línea base
Cumplimiento de Línea Base	99.2% de actividades contra la línea base actual	99.7% de actividades contra la línea base actual
Tasa de Edición No Autorizada	0.00% (0/924 salidas)	0.00% (0/343 salidas)
Tasa de Escapes de Defectos	9.1% (31/341 defectos)	4.7% (8/169 defectos)
Propagación de Cambios	Mediana 16 min	Mediana 0 min (commit único)

Trazabilidad: Se logró una alta cobertura; la única brecha sistemática fue el vínculo de pruebas automatizadas para funciones menores de la interfaz de usuario.
Consistencia: El enfoque de "proyección controlada" resultó en una divergencia casi nula entre los artefactos humanos y los de los agentes.
Gobernanza: La imposición estructural del flujo (por ejemplo, descartar cambios locales no confirmados) logró una tasa de edición no autorizada del 0.00%.
Defectos: Las tasas de escape de defectos estuvieron dentro o ligeramente por encima de los rangos líderes de la industria. Sin embargo, el estudio señaló que los defectos de mayor duración fueron "fallos silenciosos" (controles ausentes sin errores visibles) que el bucle interno rápido pasó por alto, surgiendo solo durante revisiones deliberadas de todo el repositorio.

5. Significación y Reivindicaciones

El artículo afirma proporcionar una arquitectura de gobernanza para la entrega asistida por IA y una redefinición correspondiente del rol del Analista de Negocio (BA).

Redefinición del BA: El BA ya no se define únicamente por lo que escribe, sino por lo que habilita que otros (humanos e IA) entreguen. El rol pasa de la autoría de especificaciones para colegas a la autoría de instrumentos de control para ejecutores de máquinas y la gobernanza del flujo de entrega de IA.
Viabilidad de Velocidad + Control: El estudio demuestra que añadir una gobernanza rigurosa (separación de funciones, trazabilidad, control de línea base) no anula la ventaja de velocidad de la IA. En el Caso 2, el marco entregó el doble de módulos en un cuarto del tiempo del Caso 1, manteniendo una mayor conformidad y cero ediciones no autorizadas.
Fuente Única de Verdad: El artículo valida que un único modelo canónico puede servir tanto para la aseguración humana como para la ejecución de máquinas sin crear fuentes de verdad divergentes, siempre que los resultados se generen como proyecciones controladas.

Modestia de las Reivindicaciones:
El artículo establece explícitamente que estos resultados son demostraciones de viabilidad de un estudio de dos casos realizado por un único operador. No pretende una generalización estadística. Los autores reconocen que la evaluación carece de controles previos al marco emparejados y que la métrica de "escape de defectos" depende del juicio del propio autor. La principal contribución es el diseño de un método que hace que la entrega asistida por IA sea gobernable, segura y trazable, desplazando la carga de la claridad del intérprete humano al artefacto de requisito estructurado.