💻 computer science

From Business Problems to AI Solutions: Where Does Transformation Support Fail

Este artículo identifica la falta de apoyo sistemático para traducir problemas empresariales en soluciones de aprendizaje automático como el "Problema de Traducción Analítica" (ATP) y propone cinco recomendaciones de investigación para abordar esta brecha mediante una revisión narrativa de 18 enfoques existentes.

Autores originales: Abir Trabelsi, Imen Benzarti, Hafedh Mili, Darine Ameyed

Publicado 2026-04-22

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Abir Trabelsi, Imen Benzarti, Hafedh Mili, Darine Ameyed

Artículo original bajo licencia CC BY 4.0 (http://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

¡Claro que sí! Imagina que este artículo es como un manual de diagnóstico para un mecánico de coches muy especial, pero en lugar de coches, se trata de Inteligencia Artificial (IA).

Aquí tienes la explicación de la investigación, traducida a un lenguaje sencillo y con analogías creativas:

🚗 El Problema: El "Traductor" que no existe

Imagina que eres el dueño de una empresa (el Cliente). Llegas a un taller de IA y dices:

"Quiero que mis clientes no se vayan a la competencia. ¡Quiero reducir el 'churn' (la fuga de clientes)!"

El dueño del taller (el Científico de Datos) asiente, pero por dentro está pensando: "¿Cómo hago eso? ¿Debo predecir quién se va? ¿Debo agrupar a los clientes por comportamiento? ¿O debo buscar anomalías en sus pagos?".

El problema que detectan los autores es que no hay un manual ni un traductor que convierta tu deseo de "no perder clientes" en una receta técnica exacta para la computadora.

La realidad actual: Los científicos de datos tienen que adivinar, usar su intuición o probar cosas al azar. A veces construyen un coche deportivo increíble (un modelo técnico perfecto) que, lamentablemente, no sirve para ir a la playa (no resuelve el problema de negocio).
La consecuencia: Muchos proyectos de IA fallan porque el equipo técnico y el dueño del negocio hablan idiomas diferentes y no tienen un diccionario común.

🔍 La Investigación: ¿Dónde está el manual?

Los autores (Abir, Imen, Hafedh y Darine) decidieron investigar 18 métodos diferentes que la gente ha intentado usar para solucionar esto. Se imaginaron como detectives buscando en tres grandes bibliotecas:

Ingeniería de Requisitos: (Los que escriben las reglas del juego).
Gestión de Proyectos de Datos: (Los que organizan el cronograma).
Automatización: (Los que intentan que las máquinas elijan por nosotros).

Lo que descubrieron fue decepcionante:
Aunque todos estos métodos dicen "sí, podemos hacerlo", en realidad nadie tiene un paso a paso claro para la parte más importante: traducir el problema de negocio a la tarea de la máquina.

Es como si todos los manuales de cocina te dijeran: "Primero, compra ingredientes. Luego, cocina. Finalmente, sirve el plato". Pero ninguno te dice cómo convertir "quiero una cena romántica" en "necesito salmón a la plancha con salsa de maracuyá". Te dejan a ti decidir qué cocinar.

🧩 El "Problema de Traducción Analítica" (ATP)

Los autores le pusieron un nombre a este hueco gigante: El Problema de Traducción Analítica (ATP).

Imagina que el proceso de crear una IA es un puente:

Izquierda: El mundo de los negocios (Objetivos, dinero, reglas, clientes).
Derecha: El mundo de la tecnología (Algoritmos, datos, matemáticas).
El hueco en medio: Es donde debería estar el puente, pero está roto.

Actualmente, los métodos existentes son buenos para:

Definir qué datos necesitamos (los ingredientes).
Decidir cómo monitorear el coche una vez que circula (mantenimiento).
Pero fallan estrepitosamente en el centro: decidir qué tipo de "motor" (algoritmo) necesitamos para el viaje que queremos hacer.

💡 Las 5 Soluciones Propuestas (El Nuevo Manual)

Como no existe el manual, los autores proponen crear uno nuevo con 5 reglas de oro para futuros sistemas:

Explora varias rutas (R1):
- Analogía: Si quieres ir a París, no elijas solo el tren. Mira también el avión, el coche y el barco.
- Explicación: Un problema de negocio puede tener varias soluciones técnicas. No te cases con la primera idea. Compara diferentes formas de plantear el problema antes de decidir.
Reglas de traducción claras (R2):
- Analogía: Un diccionario que diga: "Si la pregunta es '¿Cuánto?', la respuesta es 'Regresión'. Si es '¿Qué grupo?', la respuesta es 'Agrupamiento'".
- Explicación: Necesitamos reglas que conecten la pregunta del negocio directamente con el tipo de tarea matemática, sin tener que adivinar.
Filtros de restricciones (R3):
- Analogía: Si tu coche debe ser rápido y silencioso, no puedes elegir un motor de tractor ruidoso, aunque sea potente.
- Explicación: Las reglas del negocio (como "debe ser rápido" o "debe ser justo") deben eliminar automáticamente las opciones técnicas que no cumplen, antes de empezar a programar.
Rastreo con probabilidades (R4):
- Analogía: En lugar de decir "Este coche llegará a París", decir "Hay un 85% de probabilidad de que llegue, pero podría tardar 2 horas más".
- Explicación: La IA nunca es 100% segura. Debemos poder rastrear cómo una decisión técnica afecta al objetivo de negocio, sabiendo que hay un margen de error.
Señales de "Vuelta Atrás" (R5):
- Analogía: Si al conducir te das cuenta de que el camino está cortado por un río, no sigas conduciendo hacia el agua. Vuelve al mapa y elige otra ruta.
- Explicación: A veces, al explorar los datos, te das cuenta de que tu idea inicial era imposible. El sistema debe decirte: "Oye, los datos no sirven para esto, vuelve a la etapa 1 y cambia la estrategia".

🏁 Conclusión

El mensaje final es simple: Dejar que los expertos de IA "adivinen" cómo resolver problemas de negocio ya no es suficiente.

Necesitamos pasar de la intuición (que es como conducir con los ojos vendados) a la metodología (tener un GPS y un mapa). Los autores no han inventado el GPS todavía, pero han dibujado el plano exacto de dónde está el hueco y cómo debería construirse para que, en el futuro, convertir un "quiero vender más" en un "algoritmo de recomendación" sea tan fácil como seguir las instrucciones de un manual de cocina.

Resumen Técnico

1. El Problema: La Brecha de Traducción Analítica (ATP)

El artículo identifica un problema crítico en el ciclo de vida de los proyectos de Inteligencia Artificial (IA): la traducción de problemas de negocio (BP) a especificaciones de soluciones de aprendizaje automático (MLS).

Contexto: Los proyectos de IA fallan a tasas estimadas dos veces superiores a las de los proyectos de TI convencionales. Una causa raíz recurrente es la desalineación entre lo que los interesados (stakeholders) intentan resolver (ej. "reducir la rotación de clientes") y la formulación técnica entregada a los equipos de ciencia de datos.
La Brecha: Actualmente, este paso de traducción "aguas arriba" es mayoritariamente ad hoc, depende de la intuición individual y carece de soporte metodológico sistemático.
Definición del Problema: Los autores definen este vacío como el Problema de Traducción Analítica (ATP, por sus siglas en inglés). Se caracteriza por la ausencia de mapeos explícitos, trazables y operativos entre las caracterizaciones del negocio (objetivos, decisiones, restricciones) y las formulaciones estadísticas/algorítmicas (tareas de ML, paradigmas, métricas). A diferencia de la Ingeniería de Requisitos (RE) tradicional, que refina objetivos a requisitos técnicos con correspondencia semántica, la traducción BP→MLS requiere una derivación cross-domain (transdisciplinaria) sin correspondencia semántica directa.

2. Metodología

Los autores realizaron una revisión narrativa estructurada de la literatura para analizar cómo las metodologías existentes apoyan esta transformación.

Corpus: Se seleccionaron 18 enfoques que abarcan tres dominios: Ingeniería de Requisitos para IA (RE4AI), Gestión de Proyectos de Ciencia de Datos y Enfoques de Automatización.
Proceso de Selección: Se buscaron en 5 bases de datos digitales (IEEE, ACM, Springer, etc.). De 129 artículos iniciales, se filtraron hasta 18 que proponían un enfoque concreto de transformación BP→AI, con detalles metodológicos suficientes y validación.
Marco de Análisis:
- Taxonomía: Se organizaron los 18 enfoques en 4 familias según su orientación metodológica.
- Evaluación de Cobertura: Se compararon los enfoques contra un marco de 7 etapas de transformación (S1-S7), desde la definición del problema hasta la implementación.
- Criterios: Se evaluó la cobertura de cada etapa como Fuerte (guía explícita), Parcial (mencionado pero no operacionalizado) o Mínima (ausente).
- Fiabilidad: Se utilizó un coeficiente Kappa de Cohen ponderado ( $\kappa = 0.83$ ) para validar la consistencia entre los autores en la clasificación.

3. Contribuciones Clave

A. Taxonomía de Enfoques (Familias)
El estudio organiza la literatura dispersa en cuatro familias:

Ingeniería de Requisitos para IA (RE4AI): Se centran en especificar requisitos y catalogar preocupaciones de IA (ej. GR4ML, RE4HCAI). Limitación: Suelen carecer de mecanismos de transformación de negocio a técnico.
Ingeniería de Requisitos Centrada en Datos: Priorizan los requisitos de datos como puente (ej. AMDiRE). Limitación: A menudo asumen la tarea de ML previamente definida.
Procesos de Gestión de Proyectos: Modelos de ciclo de vida como CRISP-DM o variantes (CRISP-ML). Limitación: Definen cuándo ocurren las actividades, pero no cómo ejecutar la decisión de formulación de la tarea.
Enfoques Orientados a la Automatización: Herramientas de AutoML y MLOps (ej. SmartML). Limitación: Asumen que la formulación del problema ya está completa y solo optimizan la selección de algoritmos dentro de una tarea fija.

B. Análisis Comparativo de Cobertura
El análisis revela una discontinuidad crítica en las etapas S2-S3:

S1 (Enmarcado del Problema) y S4-S7 (Especificación de Datos/Despliegue): Tienen cobertura moderada a fuerte en varias familias.
S2 (Formulación de Decisiones/Preguntas) y S3 (Selección de Tarea/Paradigma de ML): Presentan la mayor deficiencia.
- Hallazgo 1: Ninguno de los 18 enfoques proporciona una guía fuerte para la selección de la tarea de ML (S3). Solo 4 ofrecen soporte parcial.
- Hallazgo 2: La transición de objetivos de negocio a tareas técnicas (ej. ¿es esto clasificación, regresión o clustering?) depende casi exclusivamente de la intuición del practicante.

C. Definición del Problema de Traducción Analítica (ATP)
Los autores formalizan el ATP como la función faltante $f_{ATP}$ que debe mapear:

Entradas: Objetivos Estratégicos (O), Restricciones (C), Disponibilidad de Datos (D), Requisitos del Usuario (R).
Salidas: Paradigma de ML (P), Tipo de Tarea (T), Restricciones Algorítmicas (A), Criterios de Evaluación (E).
Estado actual: Las herramientas modelan las entradas y salidas por separado, pero no proveen la función de traducción.

4. Resultados y Recomendaciones de Investigación (R1-R5)

Basado en las brechas identificadas, el artículo propone cinco recomendaciones para futuros marcos de trabajo:

R1: Soportar la Exploración de Múltiples Formulaciones: En lugar de buscar una sola solución, los marcos deben permitir explorar formulaciones paralelas (ej. clasificación vs. regresión) con criterios de comparación estructurados (coste, viabilidad de datos, alineación).
R2: Proveer Guía de Derivación de Tareas: Establecer reglas explícitas que vinculen el tipo de pregunta de negocio con el tipo de tarea de ML (ej. "¿Qué grupo existe?" $\rightarrow$ Clustering) y filtros basados en datos (ej. "Sin etiquetas" $\rightarrow$ Excluir supervisado).
R3: Habilitar el Filtrado por Restricciones-Algoritmo: Crear matrices de compatibilidad que descarten familias de algoritmos que violen restricciones no funcionales (latencia, equidad, explicabilidad) antes de la selección detallada, en lugar de verificarlo a posteriori.
R4: Implementar Trazabilidad Probabilística: Dado que los modelos de ML tienen incertidumbre, la trazabilidad debe incluir rangos de rendimiento esperados y niveles de confianza, conectando las métricas técnicas con el impacto en los objetivos de negocio.
R5: Definir Vías de Revisión Desencadenadas por Datos: Establecer condiciones explícitas bajo las cuales los hallazgos de los datos (ej. desbalanceo extremo, baja calidad de etiquetas) obliguen a revisar decisiones aguas arriba (objetivos o formulación de tareas), evitando que los equipos persistan en formulaciones inviables.

5. Significado e Implicaciones

Para la Ingeniería de Requisitos (RE): El trabajo posiciona la transformación BP→MLS como un problema de refinamiento de requisitos distinto y transversal. Sugiere que los conceptos de RE (descomposición de objetivos, trazabilidad) son aplicables pero deben adaptarse para manejar la derivación entre dominios semánticamente desconectados.
Para la Práctica: Los profesionales deben tratar la formulación de tareas de ML como una actividad explícita de requisitos, no como una decisión implícita de ciencia de datos. Se recomienda usar las categorías de artefactos del estudio como una lista de verificación para evitar puntos ciegos.
Para el Futuro: La formalización del ATP es un prerrequisito para desarrollar herramientas de IA generativa o asistentes que puedan ayudar realmente en esta fase de traducción, pasando de la intuición del practicante a mecanismos de refinamiento trazables y principistas.

En conclusión, el artículo demuestra que, aunque existen muchas metodologías para gestionar proyectos de IA, ninguna ofrece un soporte sistemático para el paso más crítico: decidir qué tarea de aprendizaje automático resolver un problema de negocio específico.