¿Cómo extraigo las reglas de negocio de mi sistema antiguo con IA?

Las reglas de negocio de su sistema antiguo se extraen en 3 pasos: la IA lee el código y redacta cada regla como una frase clara vinculada a la línea de la que procede; el responsable del proceso la revisa y la confirma o la corrige; y usted la compara con lo que el sistema hace realmente en facturas reales. Una herramienta como AWS Transform para mainframe redacta las reglas como requisitos revisables, y en el anuncio de Thought Machine con Amazon del 29 de septiembre de 2026 la extracción pasa por 4 etapas que terminan con una aprobación humana. No escriba código nuevo hasta que las reglas estén confirmadas.

En la parte 3 salió con un inventario y una decisión provisional para cada sistema. Los sistemas que decidió reconstruir o convertir son los que necesitan primero este paso.

Por qué las reglas de negocio son lo más valioso de su sistema antiguo

Una regla de negocio es la forma en que su empresa calcula o decide algo: cómo se calcula el descuento de un cliente mayorista, cuándo se añade un recargo por demora, quién aprueba una orden de compra por encima de cierto límite, cómo se redondea el importe de una cuota. Estas reglas se acumularon durante años de cambios, y muchas nunca se escribieron en ningún documento.

• En el código: condiciones y cálculos que un programador escribió hace años a petición de un responsable que ya dejó la empresa.
• En la base de datos: tablas de precios, tasas y límites que alguien modifica a mano sin saber qué depende de ellos.
• En la cabeza de las personas: las excepciones que el contable resuelve a mano porque el sistema no lo hace.
• En hojas de cálculo: fórmulas que cubren lo que le falta al sistema, como explicamos en qué hoja es el sistema.

Si reconstruye el sistema sin estas reglas, construirá un sistema nuevo que calcula de otra manera, y solo lo descubrirá cuando un cliente reclame una factura. Lo que debe migrar son las reglas; el lenguaje de programación antiguo es solo el recipiente.

Cómo lee la IA el código y redacta las reglas

Extraer reglas era un trabajo manual largo: un programador leía el código línea a línea y anotaba lo que entendía. Las herramientas actuales leen todo el código, siguen de dónde viene cada cifra y adónde va, y redactan lo que encuentran en lenguaje claro. Un ejemplo: Amazon afirma en la página de AWS Transform para mainframe que el servicio extrae cada regla de negocio del código fuente y la vincula a su origen, y después genera requisitos listos para el desarrollo que su equipo puede revisar, cada uno rastreable hasta el código del que procede. Esa es la descripción que Amazon hace de su servicio, no un resultado garantizado.

El formato en que se redacta una regla importa. Un formato conocido es EARS, el Easy Approach to Requirements Syntax, desarrollado por Alistair Mavin y sus colegas en Rolls-Royce y publicado por primera vez en 2009. La idea es que cada regla se escribe en un orden fijo: el estado, luego el desencadenante y luego lo que debe hacer el sistema. Tiene 5 patrones básicos; estos son ejemplos empresariales ilustrativos:

El valor de este formato es que el responsable del proceso puede leerlo y juzgarlo sin saber programar. Una frase por regla, y responde sí, no o incompleta.

Un ejemplo de la banca: la intención de negocio, no la traducción línea a línea

El ejemplo reciente más claro viene de la banca, donde las reglas de intereses, comisiones y amortización llevan décadas viviendo en código COBOL en mainframes. COBOL es un lenguaje de programación antiguo que todavía mueve muchos sistemas de banca y seguros. En su anuncio del 29 de septiembre de 2026, Thought Machine, una empresa de tecnología bancaria, dijo que trabaja con Amazon en un proceso que no traduce el código línea a línea, sino que extrae la intención de negocio pura. Según el anuncio, el proceso tiene 4 etapas:

1. Extracción: AWS Transform lee las aplicaciones heredadas y extrae la lógica de negocio en especificaciones redactadas en EARS.
2. Consolidación: cientos de variantes redundantes del mismo producto se fusionan en especificaciones modernas y ligeras.
3. Síntesis: agentes de IA generan los productos financieros y sus pruebas en Python.
4. Validación: revisión humana en la que los equipos de ingeniería y de riesgos del banco tienen autoridad explícita de aprobación.

Fíjese en las dos lecciones: la consolidación muestra que un sistema antiguo lleva muchas copias de la misma regla, y la última etapa es totalmente humana. Son afirmaciones de las dos empresas sobre su proceso, y su ejemplo es un banco, pero el método sirve para cualquier empresa: extraer, fusionar los duplicados y luego construir, sin aprobar nada antes de que firme el responsable de la decisión.

Por qué el responsable del proceso debe confirmar cada regla

La IA lee lo que hace el código, no lo que quiere la empresa. La distancia entre ambas cosas es donde se producen los errores de modernización:

• Código muerto: puede extraer una regla de una parte que no se usa desde hace años, y hacer que parezca una regla viva.
• Un error antiguo convertido en costumbre: el sistema redondea un importe de forma incorrecta y el personal lo corrige a mano. La regla extraída trasladará el error salvo que alguien diga que es un error.
• Una regla fuera del código: la excepción que el contable resuelve a mano nunca aparecerá en la extracción.
• Reglas contradictorias: dos versiones del cálculo del descuento en dos lugares distintos. Cuál es la correcta es una decisión de negocio, no técnica.

Por eso, asigne a cada regla un responsable de negocio que la firme: el director comercial para las reglas de descuento, el director financiero para los recargos y las aprobaciones. Las reglas confirmadas se convierten en la base del pliego de requisitos del nuevo sistema, y explicamos cómo redactarlo en nuestra guía para redactar requisitos de software. Tenga en cuenta que el código y las bases de datos pueden contener datos de clientes o empleados, así que cualquier herramienta que los lea fuera del Reino necesita la revisión que vimos en la parte 3, junto con las orientaciones de la Autoridad Saudí de Datos e Inteligencia Artificial (SDAIA).

La visión de Origami

Cuando modernizamos un sistema antiguo, tratamos sus reglas de negocio como lo más importante que hay que trasladar, no su código. Usamos herramientas de IA para leer el código y redactar las reglas como frases claras a una velocidad que antes no era posible, pero no damos ninguna regla por definitiva hasta que el responsable del proceso la ha leído y firmado.

Después probamos cada regla confirmada con datos reales del sistema antiguo antes de construir el nuevo a su alrededor, para que el nuevo sistema calcule como la empresa espera y no como una herramienta supone. Si quiere ver cómo trabajamos, consulte nuestros servicios.

El ejercicio de esta semana: una regla, tres facturas

No hace falta esperar a una herramienta para empezar. Elija una regla que genere debate a menudo, como un descuento o un recargo por demora, y siga estos pasos:

1. Pida al responsable del proceso que escriba la regla en una frase, con la forma: Cuando..., el sistema deberá...
2. Saque del sistema 3 facturas reales en las que se aplicó la regla: una normal, una en el límite y una con excepción.
3. Calcule cada factura a mano con la frase escrita y compare el resultado con lo que produjo el sistema.

Si las tres coinciden, la regla está documentada. Si una difiere, ha encontrado una regla oculta o un error antiguo, y eso es exactamente lo que necesita saber antes de cualquier modernización.

En la próxima parte

Ya tiene reglas confirmadas para su sistema. Ahora llega la gran decisión: ¿traslada el sistema tal cual, convierte su código a una plataforma moderna, lo reconstruye en torno a las reglas que extrajo o lo sustituye por un producto estándar y conserva solo los datos? En la parte 5 comparamos estos caminos en una tabla: cuándo encaja cada uno, qué conserva, qué arriesga y quién debe participar.

Fuentes

• AWS Transform para mainframe: página oficial — extracción de reglas de negocio vinculadas al código original, requisitos revisables y pruebas de equivalencia.
• Thought Machine y AWS: anuncio del 29 de septiembre de 2026 — las cuatro etapas: extracción en EARS, consolidación, síntesis y validación humana.
• EARS: la guía oficial de Alistair Mavin — el formato, sus cinco patrones y su primera publicación en 2009.
• SDAIA: protección de datos personales.