Todo esto ya era posible antes. Ese es el punto. Lo que cambió es cuántos pasos hay entre querer algo y conseguirlo.
Antes y después: cinco pasos frente a una sola frase.
1. Convierte una nueva lista de precios en una nueva versión
Tu proveedor envía una lista de precios actualizada. Es un archivo CSV. Tu tabla de productos todavía contiene los valores anteriores.
Antes: Abre el archivo. Abre la regla. Determina qué filas deben actualizarse. Edítalas una por una o expórtalas a Excel, realiza los ajustes y vuelve a importarlas. Asegúrate de que nada más haya cambiado.
Ahora: Sube el archivo y dile al asistente qué debe hacer.
Aquí está la nueva lista de precios de nuestro proveedor. Crea una nueva versión de la tabla de consulta Product Prices con estos valores. Mantén intacta la versión actual y muéstrame qué filas cambiaron.
Crea una nueva versión de la regla a partir de una lista de precios del proveedor sin modificar la versión activa.
El asistente lee la tabla actual, relaciona los nuevos valores con las filas correctas y crea una nueva versión. No modifica la versión que está en uso. Tú la revisas primero.
Busca SKU-4410-GOLD en la nueva versión. ¿Cuánto paga un cliente Gold por 12 unidades?
Pídele al asistente un valor de la nueva versión de la regla y verifica el resultado en el chat.
Ves el resultado en el mismo chat, justo al lado de los datos que acabas de incorporar.
2. Crea una tabla a partir de una descripción
Antes: Convierte la política en columnas. Define las entradas y las salidas. Crea la tabla. Añade filas. En la fila nueve, te das cuenta de que después de todo necesitas una columna calculada.
Ahora:
Crea una tabla de decisiones para aplicar un descuento según el total del pedido y el estado del cliente. Los clientes Gold obtienen un 15 % para pedidos superiores a 500; los demás, un 10 % para pedidos superiores a 1000.
Convierte una política escrita en lenguaje natural en una tabla de decisiones estructurada.
El Asistente de IA devuelve una tabla lista para revisar. Las entradas y salidas están definidas, las columnas tienen sus tipos configurados y las filas están completas.
Esto utiliza el mismo motor que impulsa la creación de reglas en el editor. MCP solo cambia la forma de acceder a él.
3. Genera casos de prueba que realmente prueben algo
Antes: Recorre las condiciones de cada fila. Escribe las entradas manualmente. El resultado suele cubrir la lógica que ya entiendes, no los vacíos que pasaste por alto.
Ahora:
Genera 10 casos de prueba para la regla de puntuación crediticia, versión 3. Incluye valores límite y al menos una entrada que no coincida con ninguna fila.
Esa última parte es clave. Las entradas que no coinciden con ninguna fila revelan vacíos de cobertura. Esos son los casos que rara vez se escriben manualmente.
Esto es lo más importante. El asistente solo propone las entradas. No completa los resultados esperados. Cuando guardas el conjunto, DecisionRules resuelve la regla utilizando esa versión exacta para establecer las salidas. Si la IA escribiera ambas partes, la prueba no tendría sentido. Por eso no puede escribir la respuesta.
Genera casos de prueba significativos y ejecútalos como un conjunto reutilizable de pruebas de regresión.
Los resultados se devuelven para cada caso. El conjunto permanece en la pestaña Pruebas para la próxima vez. Así las pruebas de regresión siguen siendo útiles. Y ahora no tienes que escribir las entradas manualmente.
4. Pregúntale a la tabla por qué, no solo qué
Un cliente afirma que se le cobró un precio incorrecto. La tabla de precios tiene cuarenta filas, tres condiciones que se superponen y una columna de cálculo añadida hace meses. La regla se evalúa correctamente, pero el problema está en la lógica.
Antes: Abre la regla. Vuelve a crear la entrada en Test Bench. Ejecútala. Recorre la evaluación paso a paso.
Ahora:
Resuelve la regla de precios con este pedido y dime qué fila coincidió y por qué.
Obtienes la fila coincidente, las condiciones que se cumplieron o fallaron y cómo se calculó el valor final. Después preguntas lo que realmente ayuda:
¿Qué otras filas podrían haber coincidido con este pedido y por qué no fueron seleccionadas?
Sin el asistente, dedicarías al menos veinte minutos a investigar el caso: reconstruir las entradas, desplazarte por las filas y seguir la lógica paso a paso. El modo de depuración ayuda y acelera el proceso al mostrar las evaluaciones a nivel de celda. Aun así, cada comprobación es manual. Ahora, para obtener respuestas sobre la lógica, basta con formular la pregunta.
La misma capacidad permite generar resúmenes de reglas en el editor y resulta especialmente útil con esa regla que nadie recuerda haber creado.
5. Descubre qué implica un cambio de versión antes de publicar
Antes: Abre la vista de comparación. Revisa las diferencias entre las versiones. Lo que la vista no puede decirte es qué significan esos cambios para un pedido real o quién se verá afectado.
Compara versiones de reglas para ver qué umbrales cambiaron y cómo afectan a pedidos reales.
Ahora:
Compara las versiones 3 y 4 de la tabla de precios. ¿Qué cambió y qué implica para un pedido de 400?
Las diferencias se presentan de forma clara, junto con su impacto. El umbral pasó de 500 a 400, por lo que un pedido de 400 ahora recibe un descuento que antes no obtenía. Se desactivó una fila. Ahora hay un nuevo nivel por encima del nivel máximo anterior.
Después viene la comprobación crítica antes de publicar:
¿Cómo se llama esta regla y a qué versiones están vinculados quienes la utilizan?
Quienes están vinculados a la versión 3 no cambian. Los configurados para usar la versión más reciente recibirán la actualización cuando publiques. Saber cuál utiliza cada uno requiere una sola frase.
6. Crea la regla a partir del ticket que la solicitó
Antes: Un analista de negocio escribe la nueva política de descuentos en un ticket. Alguien la lee. Abre DecisionRules. La convierte en una tabla. Después vuelve al ticket y añade una nota indicando que está terminada.
Ahora: Ambas herramientas están conectadas al mismo asistente.
Acaba de llegar el ticket DRU-4730. Actualiza la tabla de tasas de interés según lo que solicita.
Convierte un ticket en una actualización de regla probada sin salir del flujo de trabajo.
El asistente lee el requisito tal como lo escribió el negocio, actualiza la regla, ejecuta los casos y cierra el ciclo en el mismo lugar donde comenzó la solicitud.
Lo que diferencia este caso de los otros cinco es que DecisionRules no es la única herramienta de la conversación. El mismo patrón funciona con una hoja de cálculo en lugar de un ticket, con una base de datos como fuente de datos de referencia o con un canal de Slack como lugar donde se anuncia el resultado. Tus reglas dejan de ser una isla que solo se abre en su propia pestaña.
Qué significa todo esto
Nada de esto es nuevo desde el punto de vista funcional. Cada acción utiliza una función que ya existe en DecisionRules. El asistente recurre a las mismas herramientas que utilizarías tú.
Lo que MCP elimina es la distancia. La regla, la IA y la persona están ahora en un mismo lugar. El ciclo desde la idea hasta la comprobación se completa en segundos, no en minutos.
Ivan Peresta trabaja en DecisionRules, donde su función abarca análisis de producto, servicios profesionales y soporte al cliente. Participa en todo el ciclo de vida de las funcionalidades del producto, desde el diseño inicial y la reflexión sobre UX hasta las pruebas prácticas, la documentación y la entrega orientada al cliente. Su trabajo cierra la brecha entre el desarrollo del producto y las personas que realmente lo utilizan, ya sea ayudando a un cliente a diseñar su sistema de reglas o asegurándose de que una nueva función se lance con guías claras y ejemplos funcionales.
