¿Qué ocurre cuando la IA lee una especificación de requisitos? Un informe desde la ingeniería ferroviaria

Introducción

¿Qué ocurre realmente cuando se entrega a un sistema de IA un pliego de requisitos con 800 requisitos técnicos y se le dice: „Evalúalo“? La respuesta no es ni la visión de ciencia ficción de una máquina de propuestas totalmente automatizada ni la variante cínica de „nada útil“. La realidad se encuentra entre ambas y es más matizada de lo que sugieren la mayoría de las promesas de marketing de los proveedores de IA.

Este artículo describe, paso a paso, qué sucede realmente cuando un sistema de IA procesa un pliego de requisitos real de tecnología ferroviaria. Se basa en la experiencia con documentos de licitación reales, incluidos los puntos en los que la tecnología funciona y aquellos en los que falla.

La pregunta no es académica. Según el Informe Loopio 2025 sobre tendencias y benchmarks de respuestas a RFP , el 68 % de los equipos de propuestas de todos los sectores ya utiliza IA generativa, el doble que el 34 % de 2023. La industria ferroviaria aún está al principio, aunque plataformas especializadas como Tendric se dirigen precisamente a este caso de uso. Sin embargo, el taller anual NLP4RE (Natural Language Processing for Requirements Engineering) demuestra que la automatización del análisis de requisitos mediante PLN ya ha dejado de ser un nicho.

¿Qué ve la IA cuando abre un pliego de requisitos?

Para un sistema de IA, un pliego de requisitos es ante todo un documento: un archivo Excel con 8 hojas de cálculo (LH1 a LH8), miles de filas y una docena de columnas. O un PDF. O, idealmente, un conjunto de datos estructurado en formato ReqIF (Requirements Interchange Format), el estándar OMG para el intercambio de requisitos entre herramientas, originado en la industria automotriz y utilizado cada vez más también en la tecnología ferroviaria.

Antes de que pueda realizarse cualquier procesamiento de contenido, el sistema debe resolver tres tareas básicas:

1. Reconocimiento de estructura: ¿Qué filas son requisitos, cuáles son encabezados de sección y cuáles son filas vacías o comentarios? En la guía VDB para la gestión de requisitos , la asociación de la industria ferroviaria alemana recomienda una estructura uniforme de atributos para los pliegos de requisitos. Sin embargo, en la práctica la realidad se desvía considerablemente de ello.
2. Extracción de campos: ¿Dónde están el ID del requisito, el texto, el carácter vinculante (obligatorio/deseable/opcional) y la referencia normativa? El estándar internacional ISO/IEC/IEEE 29148:2018 define qué atributos debería tener un requisito, pero los compradores de la industria ferroviaria rara vez siguen explícitamente este estándar.
3. Limpieza: celdas combinadas, saltos de línea en mitad del texto, caracteres especiales Unicode (‰ frente a %), distintos formatos de fecha y formatos de celda semánticamente relevantes (colores, negrita) que se pierden en una exportación de texto simple.

Este preprocesamiento parece trivial, pero no lo es. Cada comprador estructura su pliego de requisitos de manera distinta. El orden de las columnas varía, los encabezados de sección aparecen en la misma columna que los textos de requisitos y algunos compradores utilizan colores o formatos como información semántica que se pierde durante la importación. El campo de investigación de análisis de documentos describe precisamente este problema: los documentos son „visually rich text data“. Su significado no procede solo del texto, sino también del diseño, la fuente, la estructura de las tablas y los elementos visuales.

Fase 1: extracción de requisitos

La extracción de requisitos individuales del documento en bruto es el primer paso y el más crítico. Los errores en esta fase se propagan por todos los pasos posteriores de procesamiento. Una extracción errónea no puede compensarse ni con una buena clasificación ni con un buen enrutamiento.

La extracción abarca varios subpasos, cada uno con sus propios desafíos:

• Reconocimiento de ID: el formato típico X.35.YYYY.ZZ se identifica mediante reconocimiento de patrones. La tasa de acierto es alta siempre que el comprador utilice un esquema de ID coherente. Se complica con formatos divergentes: algunos compradores usan ID jerárquicos (3.2.1.4), otros numeración correlativa (REQ-0412) y otros renuncian por completo a ID formales y trabajan con números de fila.
• Reconocimiento de obligatoriedad:„debe“, „debería“, „puede“, „se ha de“, „tiene que“ se reconocen como indicadores de obligatoriedad. Esto sigue la distinción, establecida en la sistemática de INCOSE , entre formulaciones imperativas y opcionales. Resulta difícil con formulaciones dependientes del contexto como „debería, en la medida de lo posible“ (¿es „debería“ o „puede“?). O con construcciones pasivas: „Se presupone el cumplimiento de la norma“ no contiene un „debe“ explícito, pero es claramente obligatorio.
• Extracción de referencias normativas:identificación de estándares como „DIN EN 45545-2:2020+A1:2023“, incluidos el número de versión y las enmiendas. También aquí la tasa de acierto es alta con grafías estandarizadas. Pero los compradores escriben a veces „según la norma de protección contra incendios“ sin un número de norma concreto. O remiten a la „versión vigente“ de una norma, que puede ser distinta al cerrar el contrato que al presentar la oferta.
• Límites contextuales de los requisitos:¿dónde termina un requisito y dónde empieza el siguiente? En documentos de texto libre, un solo párrafo contiene a veces varios requisitos implícitos: „El vehículo debe poder circular por la clase de línea D4 y, al mismo tiempo, cumplir los valores límite de ruido conforme a TSI Noise.“ Técnicamente son dos requisitos independientes (carga por eje y ruido), empaquetados en una frase.

Fase 2: propuestas de clasificación

Tras la extracción, entra en juego el contenido: cada requisito se contrasta con la base de conocimiento interna. En la práctica, hoy suele resolverse mediante una arquitectura RAG (Retrieval-Augmented Generation): el sistema busca en fichas técnicas de producto, especificaciones del fabricante y registros de normas los pasajes más relevantes, los entrega junto con el requisito a un modelo de lenguaje y recibe una propuesta de clasificación: OK, OKB, NOK, OKM o R.

¿Por qué RAG? En lugar de dejar que un modelo de lenguaje general „responda libremente“ (lo que provoca alucinaciones), el modelo se limita a documentos fuente concretos. Solo puede acceder a información realmente presente en la base de conocimiento y debe respaldar su respuesta con referencias a las fuentes. Esto reduce las alucinaciones. No las elimina.

La calidad de estas propuestas varía mucho según el tipo de requisito:

Tasa de acierto estimada de la clasificación inicial por IA según el tipo de requisito (valoración cualitativa basada en experiencia práctica, no debe entenderse como benchmark). La investigación actual sobre clasificación automática de requisitos mediante PLN muestra patrones similares: puntuaciones F1 de 0,73–0,84 según el enfoque metodológico (Nature Scientific Reports, 2024).

Dónde funciona bien

Los requisitos paramétricos son el punto fuerte: „Velocidad máxima de al menos 100 km/h“ se contrasta con la ficha técnica del producto (nuestro valor: 100 km/h), se aplica la lógica de comparación (≥ 100 → cumplido) y el resultado es un „OK“ justificado con referencia a la fuente. Funciona porque el tipo de requisito es inequívocamente cuantitativo, la operación de comparación es clara (≥, ≤, =) y los datos fuente son legibles por máquina.

El contraste también funciona igual de bien con requisitos normativos cuando el registro interno de normas está mantenido: la IA reconoce la referencia normativa en el texto del requisito, busca el estado de cumplimiento en el registro y entrega la clasificación junto con el número de certificado.

Dónde se vuelve difícil

Los requisitos cualitativos y las formulaciones novedosas son el punto débil. Si un requisito dice „El licitador debe presentar un concepto de mantenimiento que cubra el ciclo de vida del vehículo durante 30 años“, la IA puede:

• Reconocer que se trata de mantenimiento (correcto)
• Asignar el área de subsistema „mantenimiento“ (correcto)
• Establecer la relación con RAMS, es decir, que el requisito afecta a la dimensión de mantenibilidad en el sentido de EN 50126 (RAMS) (correcto)
• Pero no evaluar si la empresa dispone de ese concepto o puede elaborarlo (depende de conocimiento interno que rara vez está completamente documentado)

En esos casos, „R“ (consulta necesaria) es la clasificación más honesta. Un buen sistema de IA debería proponer precisamente eso, en lugar de alucinar un „OK“ sin fundamento. La investigación sobre alucinaciones de LLM muestra el problema: los modelos de lenguaje „aprenden a adivinar con confianza en lugar de expresar incertidumbre calibrada“. En la clasificación de requisitos esto es peligroso, porque un „OK“ erróneo tiene consecuencias contractuales directas.

Fuente: CONTACT Software, Del tren lento a la gestión de requisitos. Esta cita es de 2014. Desde entonces, la densidad de requisitos ha seguido aumentando. Las licitaciones actuales de vehículos incluyen regularmente entre 1.500 y 3.000 requisitos en todos los pliegos parciales.

Fase 3: reconocer y vincular normas

El reconocimiento automático de normas aporta en la práctica el mayor ahorro de tiempo. Un pliego de requisitos típico para un vehículo ferroviario hace referencia, directa e indirectamente, a un número de normas de tres cifras. El ecosistema normativo de la tecnología ferroviaria se define a nivel europeo por la ERA (European Union Agency for Railways) mediante las Especificaciones Técnicas de Interoperabilidad (ETI) y se convierte en normas europeas armonizadas por CEN/CENELEC .

Para un proveedor, esto significa que si un pliego de requisitos exige „EN 45545-2“ (protección contra incendios), no solo debe conocer el estado de esta norma, sino también:

• La correspondiente ETI SRT (Safety in Railway Tunnels), que define el marco regulatorio
• Los métodos de ensayo de EN 45545-1 (requisitos generales)
• Las clasificaciones de materiales según EN 45545-2 (comportamiento ante el fuego)
• Certificaciones específicas del producto y su periodo de validez

La IA puede hacer visibles estas conexiones en cuatro pasos:

El Comité de Normalización DIN de Infraestructura y Vehículos Ferroviarios (FSF) coordina la elaboración y aplicación nacional de las normas ferroviarias. El panorama normativo resultante abarca alrededor de 50–60 estándares relevantes para vehículos ferroviarios. Como catálogo estructurado es manejable una vez que se ha registrado y mantenido. El problema es su dinámica: las normas se revisan, se publican enmiendas, se actualizan las ETI. Solo en 2025, la ERA publicó varias especificaciones ETI actualizadas , entre ellas la nueva ETI Telematics, que entra en vigor el 2 de marzo de 2026 y define por primera vez requisitos de calidad de datos y ciberseguridad para el transporte ferroviario.

Fase 4: propuestas de enrutamiento a expertos

Basándose en la temática reconocida y en las referencias normativas, la IA puede proponer qué departamento especializado debería encargarse de cada requisito. Según el Informe Loopio 2025 de tendencias de respuestas a RFP , el 48 % de los equipos de propuestas de todos los sectores informa de dificultades para colaborar con expertos técnicos. El enrutamiento automatizado puede al menos compensarlo parcialmente.

En la industria ferroviaria, el problema de enrutamiento es pronunciado. Un pliego de requisitos para un vehículo ferroviario principal abarca entre 10 y 15 subsistemas distintos, desde la caja del vehículo hasta la tracción y el freno, pasando por la información al pasajero y la documentación de mantenimiento. Los expertos responsables trabajan en distintos departamentos, a veces en sedes diferentes. Sin un enrutamiento estructurado, el responsable de ofertas dedica una parte importante de su tiempo a asignar manualmente los requisitos a las personas adecuadas.

Cómo funciona técnicamente la IA: RAG y búsqueda basada en embeddings

Para quienes tienen un perfil técnico, merece la pena mirar bajo el capó. El principio básico de los sistemas de IA modernos para el tratamiento de pliegos de requisitos se basa en una arquitectura Retrieval-Augmented Generation (RAG), que combina dos componentes:

1. Retrieval (búsqueda):el requisito se convierte en un vector numérico (embedding) y se contrasta con una base de datos vectorial de la base de conocimiento interna. El resultado son los 5–10 pasajes de texto más relevantes de fichas técnicas de productos, registros de normas y ofertas anteriores.
2. Generation (evaluación): un Large Language Model (LLM) recibe el requisito junto con los documentos fuente encontrados y genera una propuesta de clasificación con justificación y referencia a las fuentes.

La ventaja frente a un LLM „desnudo“: el sistema solo puede acceder a información que realmente existe en la base de conocimiento. Si no se encuentra una fuente relevante, el sistema debería proponer honestamente „R“ (consulta) en lugar de alucinar una respuesta plausible pero no demostrable.

Dónde encuentra límites la IA

Una mirada honesta a los límites es más importante que cualquier mensaje de éxito. Los sistemas de IA para el tratamiento de pliegos de requisitos se enfrentan hoy a cinco límites sistemáticos:

1. Conocimiento implícito

El conocimiento más valioso de una empresa a menudo no está documentado. Si un ingeniero experimentado sabe que un requisito concreto provocó la exclusión en una licitación anterior y por ello formula una respuesta estratégica, la IA no tiene acceso a esa información. Solo ve los documentos que se ponen a su disposición. Este „Tacit Knowledge“ desempeña un papel importante en la industria ferroviaria porque la comunidad es manejable. Los responsables de ofertas experimentados conocen las preferencias y criterios de evaluación de compradores concretos gracias a años de colaboración.

2. Evaluación estratégica

Clasificar un requisito como NOK es a veces una decisión estratégica, no puramente técnica. Los responsables de ofertas experimentados formulan deliberadamente consultas para „suavizar“ requisitos, por ejemplo preguntando al comprador por qué un requisito es más estricto que la norma subyacente. O aprovechan la oportunidad para proponer una alternativa más innovadora que convenza al comprador. Este tipo de comunicación estratégica está fuera de las capacidades de la IA.

3. Calidad de los documentos

La calidad de los resultados de la IA depende directamente de la calidad de los documentos internos. Las fichas técnicas de producto obsoletas, los registros de normas incompletos o las especificaciones del fabricante contradictorias conducen a propuestas de clasificación erróneas. El principio „Garbage in, garbage out“ se aplica sin reservas. Lo paradójico: las empresas que mantienen bien su documentación serían las que menos „necesitarían“ apoyo de IA. Y las que más lo necesitarían tienen la peor base de datos.

4. Falta de contexto de negociación

Un pliego de requisitos no es un documento estático. Es el punto de partida de una negociación. La segunda revisión contendrá requisitos diferentes de la primera, basándose en los comentarios de todos los licitadores. La IA puede procesar la versión actual, pero no puede anticipar qué requisitos es probable que el comprador flexibilice. Ese instinto lo desarrollan los responsables de ofertas experimentados a través de años de colaboración con compradores específicos.

5. El riesgo de alucinación

Incluso con una arquitectura RAG existe el riesgo de que el modelo de lenguaje establezca relaciones que no existen. O de que interprete los documentos fuente de modo que parezcan cumplir el requisito, aunque al analizarlos detenidamente existan diferencias esenciales. Un survey actual sobre alucinaciones de LLM describe el problema: los modelos de lenguaje están optimizados para generar respuestas plausibles, no para expresar incertidumbre calibrada. En un proceso de oferta en el que cada clasificación implica un compromiso contractual, este es un riesgo real.

Qué cambia: el flujo de trabajo con y sin IA

Según el Informe Loopio 2025 de tendencias de respuestas a RFP , el 68 % de los equipos de propuestas de todos los sectores ya utiliza IA generativa (el doble que el 34 % de 2023). El 65 % utiliza software RFP especializado (frente al 48 % del año anterior), y la tasa media de éxito es del 45 %. La industria ferroviaria, tradicionalmente más cauta en la gestión digital de requisitos, aún está al principio. Según Bidara , la tasa de reutilización de contenido entre sectores es del 66 %. La mayoría de las empresas ferroviarias no aprovecha este potencial por carecer de una base de conocimiento consultable. Plataformas como Tendric abordan este punto al construir una base de conocimiento transversal a proyectos y hacerla consultable.

Conclusión

¿Qué ocurre cuando una IA lee un pliego de requisitos? Realiza el trabajo rutinario: extracción, estructuración, contraste de parámetros y reconocimiento de normas. Más rápido y de forma más completa que un proceso manual. Para el 70–80 % de los requisitos proporciona una propuesta inicial utilizable con referencia a la fuente. Para el 20–30 % restante, los requisitos estratégicos, cualitativos y novedosos, marca correctamente su incertidumbre y deriva el caso al experto humano.

Eso no es un fracaso; ese es el objetivo. La IA da al experto técnico la libertad de concentrarse en los requisitos en los que su juicio realmente marca la diferencia, en lugar de pasar horas buscando en fichas técnicas de producto. El grupo de trabajo de INCOSE para AI Systems lo denomina „AI for SE“: IA para apoyar procesos de ingeniería de sistemas.

La siguiente tarea no son modelos mejores. Son registros de normas mantenidos, fichas técnicas de producto actualizadas y archivos consultables de ofertas anteriores. Herramientas como Tendric abordan precisamente este punto: crean la base de datos estructurada sobre la que la clasificación asistida por IA puede funcionar de forma fiable.