Tenemos ya las tres herramientas simbólicas del módulo: la lógica de 06-01 para representar conocimiento, el sistema experto de 06-02 para decidir con reglas y las redes bayesianas de 06-03 para decidir con incertidumbre. Esta lección las saca del laboratorio de NovaMarket y las sitúa en el mundo: dónde se han usado y se usan los sistemas basados en reglas y conocimiento, qué conocimiento codifican, por qué en cada caso se eligen reglas y no aprendizaje automático (explicabilidad, normativa, pocos datos) y dónde están sus límites. Recorreremos la medicina, las finanzas, la industria, la agricultura, el derecho y la administración, la educación y el comercio electrónico, y veremos en qué se han convertido hoy los sistemas expertos: motores de reglas de negocio, tablas de decisión DMN, grafos de conocimiento y, sobre todo, la combinación con el ML y los LLM que anunciamos al cerrar 05-05: el enfoque neurosimbólico. En código construiremos una tabla de decisión para el enrutamiento de tickets de atención al cliente de NovaMarket y un ejemplo neurosimbólico ejecutable en el que un modelo estima la probabilidad de defecto y el motor de reglas de 06-02 decide, con la banda de revisión humana de 02-04, si se acepta la garantía automáticamente o pasa a una persona. Es importante porque es el modo en que las reglas sobreviven y prosperan en la IA actual: no compitiendo con las redes, sino gobernándolas.

1. Panorama: dónde viven los sistemas basados en reglas
2. Medicina: de MYCIN a las alertas clínicas
3. Finanzas: scoring, cumplimiento normativo y reglas de negocio
4. Industria y mantenimiento: diagnóstico y configuración
5. Agricultura, derecho y administración, educación
6. Atención al cliente y comercio electrónico: el caso de NovaMarket
7. Tabla resumen: sector, sistema, conocimiento y por qué reglas
8. Los sistemas expertos hoy: BRMS, DMN, grafos de conocimiento
9. Neurosimbólico: reglas y modelos juntos
10. Código: tabla de decisión DMN para el enrutamiento de tickets
11. Código: un ejemplo neurosimbólico ejecutable
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

Tras el invierno de finales de los 80 (01-01), la palabra "sistema experto" cayó en desuso, pero la tecnología no: se rebautizó como motor de reglas de negocio, sistema de apoyo a la decisión o automatización de decisiones, y se integró en el software corporativo. Hoy hay reglas explícitas detrás de casi cada decisión repetitiva con consecuencias regulatorias: si un banco te concede una tarjeta, si una receta dispara una alerta, si una declaración de impuestos se acepta, si tu ticket de soporte va a un equipo u otro. La razón es la misma en todos los sectores y ya la conoces del módulo: cuando la decisión la define una norma o una política, debe justificarse caso a caso, hay pocos datos o los casos límite importan, las reglas escritas ganan al modelo aprendido, o al menos lo acompañan. Recorramos los sectores con esa lente: qué conocimiento se codifica, por qué reglas y qué límites tienen.

• MYCIN (06-02) nunca llegó a la clínica, pero sus herederos sí: los sistemas de apoyo a la decisión clínica (CDSS) integrados en la historia clínica electrónica. El más extendido: las alertas de interacción de fármacos y de dosis: reglas del tipo "SI el paciente toma anticoagulante A Y se prescribe antiinflamatorio B ENTONCES alerta de riesgo de sangrado", con miles de pares de fármacos, contraindicaciones por alergia, ajustes por función renal, y protocolos clínicos (guías de práctica) codificados como árboles de decisión.
• Conocimiento codificado: farmacología, guías clínicas, criterios diagnósticos; lo escriben comités de expertos y lo actualizan con la evidencia.
• Por qué reglas: la responsabilidad legal exige poder decir por qué saltó (o no) una alerta; las guías clínicas ya son reglas; los eventos graves son raros (pocos datos para aprenderlos); la regulación de dispositivos médicos exige validación y trazabilidad.
• Límites: fatiga de alertas (demasiadas alertas irrelevantes que el médico acaba ignorando: el problema de la precisión de 04-05 en versión humana), mantenimiento de la base al ritmo de la evidencia, y la incapacidad de las reglas para el diagnóstico por imagen o la predicción de riesgo, donde el ML de los módulos 4 y 5 domina. La combinación típica: un modelo estima el riesgo de sepsis, una regla decide cuándo y a quién avisar.

• Scoring por reglas y políticas de crédito: "SI ingresos < X O antigüedad laboral < 6 meses ENTONCES denegar"; hoy conviven con modelos de riesgo, pero las reglas de política (edad mínima, listas de morosos, límites regulatorios) van antes y después del modelo.
• Cumplimiento normativo (compliance) y antiblanqueo (AML): reglas de detección de operaciones sospechosas exigidas por la normativa (importes fraccionados justo bajo el umbral de declaración, países de riesgo, patrones de ingreso en efectivo), reglas de conocimiento del cliente (KYC) y de sanciones. Se codifican literalmente de la ley y de las circulares del regulador.
• Motores de reglas de negocio para tarificación de seguros, liquidación de comisiones, elegibilidad de productos, gestión de siniestros sencillos.
• Por qué reglas: la ley es una regla y el regulador pregunta "¿por qué se marcó esta operación?"; el derecho a explicación de decisiones de crédito (RGPD, 02-04) exige motivos legibles; el fraude cambia y las reglas se editan en horas sin reentrenar.
• Límites: los defraudadores aprenden las reglas y las bordean; muchas falsas alarmas; miles de reglas acumuladas con interacciones que nadie recuerda (el mal de XCON). Por eso los sistemas modernos combinan reglas duras (normativa) con modelos (patrones sutiles) y con la banda de revisión de analistas.

• Configuración: XCON (06-02) configuraba ordenadores; sus descendientes son los configuradores de producto (un coche con sus opciones compatibles, una máquina industrial, una tarifa de telecomunicaciones), donde las reglas expresan restricciones "esta tarjeta necesita esa fuente de alimentación", un problema de satisfacción de restricciones (03-02) más que de aprendizaje.
• Diagnóstico de fallos: árboles de decisión escritos por ingenieros para averías de turbinas, locomotoras, líneas de producción; los manuales de servicio son sistemas expertos en papel. Con sensores, se combinan con detección de anomalías (04-02) que dispara el árbol de diagnóstico.
• Control de procesos: control difuso (06-03) en hornos, cementeras, climatización.
• Por qué reglas: el conocimiento está en la cabeza de ingenieros que se jubilan (conservación del conocimiento); los fallos graves son escasos; en seguridad industrial hay que poder certificar el comportamiento.
• Límites: cobertura incompleta de fallos nuevos; los árboles se quedan obsoletos con cada revisión del equipo.

• Agricultura: sistemas de asesoramiento de riego, fertilización y tratamiento de plagas ("SI humedad del suelo < X Y previsión sin lluvia ENTONCES regar N litros"), y de diagnóstico de enfermedades de cultivos por síntomas visibles. Codifican agronomía y normativa de uso de fitosanitarios; hoy la parte de percepción (fotos de hojas) la hace una CNN (05-04) y la parte de recomendación siguen siendo reglas.
• Derecho y administración: elegibilidad para ayudas y prestaciones, cálculo de impuestos, tramitación de licencias: la ley se codifica en reglas y tablas (los propios formularios de la administración son árboles de decisión). Los asistentes de tributación son sistemas expertos gigantes que se actualizan con cada ley de presupuestos. Es el terreno donde la exigencia de explicación y de igualdad de trato es máxima y donde una decisión automatizada errónea tiene más consecuencias (02-04): las reglas permiten auditar y recurrir; un modelo aprendido de expedientes pasados heredaría los sesgos de esos expedientes. Como en las devoluciones, la normativa la fija y revisa un profesional legal; el sistema la aplica.
• Educación: los tutores inteligentes (desde los años 80) modelan el conocimiento de la materia y las reglas de producción que un estudiante aplica al resolver un problema (por ejemplo, de álgebra), comparan sus pasos con las reglas correctas y las erróneas conocidas, y adaptan las pistas. Codifican pedagogía y errores típicos; hoy se combinan con modelos de conocimiento del estudiante y con LLM para el diálogo.

Aquí NovaMarket se reconoce por completo:

• Motores de reglas de promociones: "3x2 en cápsulas", "envío gratis a partir de 49 €", "cupón no acumulable con rebajas", exclusiones por categoría; miles de tiendas los ejecutan en cada carrito. Es lógica pura, con conflictos entre promociones que se resuelven por prioridad, exactamente como en 06-02.
• Políticas de devolución y garantía: el sistema experto del caso 8 que construimos.
• Enrutamiento de tickets: qué equipo, con qué prioridad y con qué acciones automáticas atiende cada incidencia, en función del tipo, el importe, el cliente y el canal (código de la sección 10).
• Prevención de fraude: reglas duras (más de N pedidos a la misma dirección con tarjetas distintas) delante y detrás del modelo de riesgo del caso 3.
• Asistentes: el chatbot del caso 7 con RAG (05-05) responde preguntas; pero decidir una devolución la delega en el motor de reglas, porque un LLM no puede garantizar que aplica la política.
• Por qué reglas: la política es de la empresa y cambia con el marketing y con la ley; cada decisión hacia el cliente debe poder explicarse; los casos límite (higiene abierto, garantía ampliada) son pocos y no se aprenden bien.
• Límites: el diagnóstico de causas (caso 9) no cabe en reglas nítidas y necesita la red de 06-03; la lectura de reseñas y fotos necesita las redes del módulo 5.

• BRMS (Business Rules Management Systems): motores de reglas con editor para usuarios de negocio, versionado, pruebas y despliegue: Drools (Java, código abierto), IBM ODM, FICO Blaze, entre otros. Son EMYCIN con traje corporativo: separan las reglas (propiedad de negocio, editables por Diego) del código (propiedad de TI), con Rete para eficiencia y salience para prioridades.
• DMN (Decision Model and Notation, estándar OMG): notación gráfica para modelar decisiones, cuya pieza central es la tabla de decisión: filas = reglas, columnas = entradas y salidas, y una política de acierto (hit policy) que dice qué hacer si varias filas casan: UNIQUE (solo puede casar una), FIRST (la primera en orden), PRIORITY (la de mayor prioridad de salida), COLLECT (todas, para acumular acciones o sumar). Es la resolución de conflictos de 06-02 estandarizada y legible por un auditor. La programaremos en la sección 10.
• Grafos de conocimiento: la lógica de primer orden de 06-01 a escala: entidades y relaciones (NovaClean —es_un→ aspirador —categoría→ hogar, NovaClean —compatible_con→ bolsa B-12) con consultas y razonamiento (ontologías, inferencia de tipos). Google, Wikidata, los catálogos de productos y las bases de fármacos son grafos de conocimiento; para NovaMarket, un grafo de productos y compatibilidades daría respuestas exactas ("¿qué bolsas van con mi aspirador?") que un LLM alucinaría.
• Motores de flujo y RPA que ejecutan reglas dentro de procesos de negocio; y las hojas de cálculo, el sistema experto más usado del mundo, con sus SI(...) anidados sin traza ni pruebas: justo lo que un BRMS arregla.

02-02 anunció la tendencia neurosimbólica y 05-05 la dejó pendiente. Ahora podemos ser concretos. Las redes perciben y estiman; las reglas representan, deciden y garantizan. Tres patrones de combinación, todos aplicables en NovaMarket:

Y el más importante en la práctica es el primero, porque resuelve el dilema de 05-05: aprovechar la percepción y las probabilidades de los modelos sin renunciar a la explicabilidad y al control que exige el AI Act. La decisión final es una regla legible; el modelo es un sensor más, con su incertidumbre convertida en una banda de revisión humana. También hay investigación de integración más profunda (redes que aprenden reglas lógicas, razonamiento diferenciable, LLM que llaman a demostradores) que queda fuera de este curso; 08-03 la menciona entre las tendencias.

Cada incidencia que entra en atención al cliente de NovaMarket debe ir a un equipo con una prioridad, y a veces desencadenar acciones automáticas. Lo modelamos como dos tablas de decisión: la de enrutado, con política "primera fila que casa" (FIRST: las filas van de más específica a más general, con una fila final por defecto), y la de acciones, con política "todas las que casan" (COLLECT: varias acciones pueden acumularse). Cada celda de entrada puede ser un valor, un conjunto de valores, una condición (función) o "cualquiera".

Salida:

Explicación:

• casa es el emparejador de celdas: cuatro tipos de celda cubren la mayoría de las tablas DMN reales (cualquiera, condición, conjunto, valor). evaluar_tabla recorre las filas en orden y aplica la política: con "primera" se detiene en la primera coincidencia; con "todas" las acumula.
• La tabla de enrutado con FIRST exige que las filas estén ordenadas de específica a general: el ticket T-9001 (no llega, 450 €, VIP) casa con las filas 1, 2, 3 y 8, como muestra la evaluación con "todas", y gana la 1 por orden. Ese es el punto delicado de FIRST: el orden es la prioridad, y una fila insertada en el sitio equivocado cambia decisiones silenciosamente. Por eso DMN ofrece también UNIQUE (que obliga a que solo case una fila y detecta solapamientos en tiempo de diseño) y PRIORITY.
• La tabla de acciones con COLLECT es el uso natural de "todas las que encajan": T-9001 acumula cupón (VIP), llamada (importe > 300) y traza con el transportista (no llega); T-9002 ninguna.
• T-9004 muestra la fila por defecto: un tipo de incidencia que no está previsto va a atención con prioridad baja en lugar de quedarse sin ruta (el "ninguna regla aplicable" de 06-02, resuelto por diseño).

Diego puede leer y editar estas dos tablas en una hoja de cálculo; TI puede versionarlas y probarlas con una batería de tickets, como los casos A-E de 06-02. Eso es un BRMS en miniatura.

Cerramos el módulo con el patrón "modelo → reglas". Un cliente solicita devolución alegando (o no) un defecto. Un modelo (aquí una regresión logística ya entrenada, simulada con pesos fijos: en producción sería modelo.predict_proba de 04-04 o el MLP de 05-03, alimentado con el texto de la solicitud, la foto y el historial del producto) estima p_defectuoso. Esa probabilidad entra como un hecho más en el motor de reglas de 06-02, junto con tres reglas nuevas que aplican la banda de revisión humana de 02-04 (UMBRAL = 0,40, BANDA = 0,20) y una cuarta que impide denegar automáticamente una garantía cuando el cliente alega defecto y el modelo lo descarta.

Copiamos de 06-02 solo lo imprescindible (Regla y un MotorInferencia compacto sin la interfaz de preguntas):

Salida:

Explicación:

• p_defectuoso es la parte subsimbólica: una suma ponderada de características (si el texto menciona "no funciona", si menciona un arañazo, la tasa histórica de defectos del producto, los días transcurridos, si hay foto) pasada por la sigmoide, la neurona de 05-01. Sus pesos son opacos por naturaleza; no intentamos explicarlos: los tratamos como un sensor que devuelve una probabilidad.
• Las reglas N1-N3 convierten esa probabilidad en hechos simbólicos con la banda de 02-04: ≥ 0,60 se acepta como defecto, entre 0,40 y 0,60 va a revisión humana, < 0,40 se descarta. Tienen la máxima prioridad para que se evalúen antes que la política. N4 es una salvaguarda del RGPD/AI Act: si el cliente alega defecto y el modelo lo descarta, no denegamos automáticamente; una persona confirma. Sin N4, S-103 iría a R8 y se denegaría por un cálculo opaco, exactamente lo que 02-04 prohíbe.
• Después actúan las reglas de la política de 06-02 (R1, R2, R4, R8), sin cambios: la explicación final es la cadena "N1 (el modelo lo estima con 0,715) → R1 (garantía legal, envío gratuito)", legible por el cliente y por el auditor, y en la que el modelo aparece con su número y sus umbrales.
• Los cuatro casos cubren las salidas: garantía automática (S-101), zona gris (S-102), alegación descartada por el modelo → persona (S-103) y desistimiento ordinario donde el modelo simplemente confirma que no hay defecto (S-104). Cambiar los umbrales o las reglas no exige tocar el modelo; reentrenar el modelo no exige tocar las reglas. Esa separación es el valor del enfoque neurosimbólico.

• Elegir ML "porque es IA". Si la decisión la define una norma o una política, escribe la regla; el modelo, si acaso, estima los hechos inciertos que la regla necesita.
• Elegir reglas para lo que no sabe escribir nadie. Reconocer una foto o predecir la demanda no cabe en reglas: módulos 4 y 5.
• Tablas FIRST con filas en orden descuidado. El orden es la prioridad. Prueba con "todas" para ver los solapamientos, o usa UNIQUE cuando las filas deban ser excluyentes.
• Reglas sin dueño ni pruebas. Cada tabla o base de reglas necesita propietario (Diego), versionado y una batería de casos que se ejecute en cada cambio.
• Dejar que el LLM decida. Que redacte, resuma, extraiga y proponga; que la decisión con efectos sobre el cliente la tome una regla o una persona, y que una regla valide lo que el LLM dice.
• Umbrales del modelo escondidos en el código. Los umbrales son política (cuánto riesgo se acepta): déjalos en reglas explícitas y visibles como UMBRAL y BANDA, no enterrados en una función.
• Olvidar la banda de revisión humana. El modelo se equivoca; la banda es donde su incertidumbre se convierte en trabajo humano en lugar de en un error hacia el cliente.

Ejercicio 1. Añade a TABLA_ENRUTADO una regla nueva que Diego pide: los tickets de producto_defectuoso con importe superior a 500 € deben ir a garantias_senior con prioridad alta. ¿En qué posición debe ir la fila para que la política "primera" funcione? Comprueba con un ticket de 700 € y otro de 80 € y explica qué pasaría si la pusieras al final.

Ejercicio 2. Ejecuta el ejemplo neurosimbólico con la solicitud S-105: auriculares NovaSound, alega_defecto=False, 30 días, usado, con etiqueta, y las mismas características del modelo que S-103. ¿Qué decide el sistema y por qué es distinto de S-103? Después cambia BANDA a 0,40 y vuelve a ejecutar los cuatro casos originales: ¿qué solicitudes cambian de decisión? ¿Qué coste y qué beneficio tiene ampliar la banda?

Ejercicio 3. Para el asistente del caso 7 (LLM con RAG, 05-05), diseña sin código tres reglas de validación de la salida del modelo antes de mostrarla al cliente (patrón "reglas → LLM" de la sección 9): qué comprueba cada una, qué hace si falla y de qué módulo del curso viene la necesidad. Después indica una tarea en la que usarías el patrón "LLM → conocimiento" para el sistema de devoluciones y qué control humano pondrías.

Solución 1. La fila (("producto_defectuoso", lambda x: x > 500, CUALQUIERA), {"equipo": "garantias_senior", "prioridad": "alta"}) debe ir antes de la fila general de producto_defectuoso (la actual fila 4), porque es más específica; colocada al final nunca se alcanzaría con la política "primera": la fila 4 casa antes y el ticket de 700 € iría a garantias/media. Con la fila en su sitio, el de 700 € va a garantias_senior/alta y el de 80 € a garantias/media. Es el mismo principio que la especificidad de 06-02, solo que en DMN FIRST lo aplicas tú con el orden.

Solución 2. S-105 obtiene p_defectuoso = 0,029 (mismas características que S-103), N3 fija defectuoso = False, y como el cliente no alega defecto N4 no se aplica; con 30 días y sin defecto, R8 deniega: "fuera de plazo y sin defecto", la regla de Diego, ahora con el respaldo del modelo. Es distinto de S-103 porque allí el cliente alegaba defecto y denegar automáticamente contra su alegación exige una persona. Con BANDA = 0,40 la zona gris pasa a ser [0,40, 0,80): S-101 (0,715) deja de ir a garantía automática y pasa a revisión humana; S-102 sigue en revisión; S-103 y S-104 no cambian. Beneficio: menos garantías aceptadas por error del modelo; coste: más trabajo humano y más espera para clientes con defectos claros. El ancho de la banda es una decisión de negocio que se toma con la matriz de costes de 04-05, no un parámetro técnico.

Solución 3. Ejemplos de reglas de validación: (1) "SI la respuesta contiene una cifra de días o de euros Y esa cifra no aparece en los fragmentos recuperados ENTONCES sustituir por la respuesta genérica con enlace a la política y registrar" (alucinaciones, 05-05); (2) "SI la respuesta contiene un compromiso de reembolso o de aceptación de garantía ENTONCES eliminarlo y derivar la decisión al motor de reglas de 06-02" (el LLM no decide, 02-04); (3) "SI la respuesta contiene datos personales que no son del cliente autenticado (otro nombre, otro número de pedido) ENTONCES bloquear y alertar" (RGPD, 02-03). Patrón "LLM → conocimiento": pedir al LLM que lea la política de devoluciones vigente y la normativa aplicable y proponga un borrador de reglas SI ... ENTONCES con su justificación y ejemplos; control humano: Diego valida cada regla, un profesional legal revisa las que dependen de la normativa, y la batería de casos A-E (y los nuevos) se ejecuta antes de activar cualquier regla propuesta.

En esta lección hemos visto que los sistemas basados en reglas y conocimiento no son una reliquia de los 80 sino la capa de decisión de la mayoría de los sistemas de negocio: alertas de fármacos y protocolos en medicina, scoring por políticas y antiblanqueo en finanzas, configuradores y árboles de diagnóstico en industria, asesores agrícolas, elegibilidad y tributación en la administración, tutores inteligentes y, en el comercio electrónico de NovaMarket, promociones, devoluciones, enrutamiento de tickets y antifraude; en todos ellos, reglas porque la norma manda, la explicación se exige, los datos escasean o los casos límite importan, y con los límites de mantenimiento, cobertura e incertidumbre que ya conocíamos. Hemos situado sus formas actuales (BRMS como Drools, tablas de decisión DMN con sus políticas de acierto, grafos de conocimiento) y hemos concretado el enfoque neurosimbólico en tres patrones: el modelo alimenta a la regla, la regla gobierna al LLM, y el LLM ayuda a construir el conocimiento. En código, la tabla de decisión ha enrutado los tickets de NovaMarket con FIRST y COLLECT, y el ejemplo neurosimbólico ha convertido la p_defectuoso de un modelo en un hecho del motor de 06-02, decidiendo garantía automática, revisión humana o desistimiento con la banda de 02-04 y una traza que cita al modelo y a la regla.

Con esto cerramos el módulo 6 y, con él, el recorrido conceptual por las dos mitades de la IA. Sabes ya representar conocimiento con lógica y encadenar reglas (06-01), construir un sistema experto con prioridades, explicación e interfaz (06-02), razonar con probabilidad y redes bayesianas y decidir por utilidad esperada (06-03) y combinar reglas con modelos donde cada uno rinde mejor (06-04). Marta y Diego tienen ahora las reglas del caso 8, la red de diagnóstico del caso 9 y el criterio para saber qué parte de cada problema va a las reglas, qué parte al ML y qué parte a una persona. Fíjate en cómo lo hemos hecho: todo el módulo en Python puro, con diccionarios, listas, itertools y fractions, mientras que en los módulos 4 y 5 usamos scikit-learn y PyTorch, y hemos ido citando de pasada Prolog, CLIPS, Drools, experta o pgmpy sin instalarlos. Es hora de ordenar ese ecosistema: qué lenguajes se usan en IA y por qué Python domina, qué aportan NumPy, pandas y Matplotlib, qué librerías hay para cada tarea de las que hemos visto y en qué entornos se trabaja. Es el módulo 7, Herramientas y Lenguajes de Programación en IA, que empieza en 07-01 comparando Python con Prolog, Lisp, R, Julia y los lenguajes de producción.