Machine learning en empresas: qué resuelve de verdad y qué exigirle a quien te lo vende

El machine learning en empresas lleva diez años vendiéndose como magia y aplicándose como Excel con más pasos. La confusión es entendible: bajo la misma etiqueta caben un modelo que decide a qué cliente llamas mañana y una demo que clasifica fotos de gatos. Este artículo va de lo primero, escrito para quien tiene que decidir si un proyecto merece la pena sin saber —ni necesitar saber— qué es un gradiente.

La idea de fondo cabe en una frase: un modelo de machine learning aprende un patrón a partir de tu historial y lo aplica a casos nuevos. Nada más. Todo lo que importa —si funciona, si se puede usar, si compensa— sale de tres preguntas mucho más aburridas: qué datos tienes, qué decisión vas a cambiar y quién responde cuando se equivoque.

¿Qué es machine learning y en qué se diferencia de automatizar con reglas?

Una regla la escribes tú: «si el pedido supera 5.000 €, pasa a aprobación». Es explícita, la entiende cualquiera y se audita en un minuto. Un modelo no se escribe, se entrena: le das miles de casos pasados con su resultado conocido y él deduce qué combinación de señales anticipa ese resultado.

Cuándo gana cada uno:

• Reglas cuando el criterio es conocido, estable y tiene pocas variables. Nunca metas un modelo donde una regla clara hace el trabajo: es más caro, más frágil y más difícil de explicar.
• Machine learning cuando el criterio existe pero nadie sabe escribirlo, hay muchas variables interactuando y tienes historial suficiente. El ejemplo clásico: «este cliente huele a que se va». Un comercial veterano lo intuye; ponerlo en veinte reglas no sale.

Y una tercera vía que se olvida: el híbrido, que es lo que acaba en producción casi siempre. El modelo puntúa, las reglas de negocio ponen los límites duros (nunca ofertar por debajo de coste, nunca saltarse un cliente en litigio) y una persona decide en la franja gris. Funciona mejor que cualquiera de los dos por separado, y es infinitamente más fácil de defender ante dirección.

Si no sabes qué harías distinto mañana con la predicción en la mano, no tienes un proyecto de machine learning. Tienes curiosidad, que es legítima y mucho más barata de satisfacer.

¿Qué casos de machine learning funcionan de verdad en una empresa mediana?

Hay tres familias que se repiten porque tienen datos disponibles y una decisión clara detrás. El resto suele ser variación de estas.

Scoring: ordenar una lista. Probabilidad de que un lead compre, de que un cliente se dé de baja, de que una factura se pague tarde, de que un candidato encaje. El valor no está en acertar caso a caso, sino en cambiar el orden en que tu equipo dedica su tiempo limitado. Si tu comercial llama a 30 empresas de una lista de 400, subir la concentración de compradores en esas 30 vale dinero aunque el modelo falle a menudo.

Previsión: anticipar una cantidad. Demanda por producto y almacén, carga de trabajo por semana, consumo, cobros. Aquí el listón lo pone lo que ya haces: si tu previsión actual la hace una persona con criterio y su margen de error es del 12 %, el modelo tiene que bajar de ahí de forma sostenida para justificarse. Sale más veces de lo que parece, porque la persona no puede repetir el ejercicio para 4.000 referencias cada semana.

Detección de anomalías: encontrar lo raro. Fraude, errores contables, fallos de máquina, consumos fuera de patrón. Es la familia con mejor relación esfuerzo/retorno cuando el coste de un caso escapado es alto. Cuidado con un detalle: si los casos raros son de verdad raros (uno entre mil), la métrica de «acierto» engaña —un modelo que diga siempre «normal» acierta el 99,9 %— y hay que mirar cuántos casos reales detecta y cuántas falsas alarmas genera por cada uno.

Ejemplos concretos de lo que hemos visto encajar bien, por tipo de negocio:

| Situación | Familia | Decisión que cambia | |---|---|---| | Cartera de 3.000 clientes B2B recurrentes | Scoring de baja | A quién llama el equipo de cuentas esta semana | | Distribución con 5.000 referencias | Previsión de demanda | Cuánto se pide a proveedor y qué stock se mueve | | Servicio con picos estacionales | Previsión de carga | Cuánta gente se planifica por turno | | Producción con máquinas instrumentadas | Anomalías | Cuándo se para a mantener en vez de esperar la avería | | Volumen alto de facturas de proveedor | Anomalías | Qué documento se revisa a mano antes de pagar |

¿Qué datos hacen falta antes de entrenar nada?

Esta es la sección que menos gusta y más proyectos salva. Un modelo aprende del pasado, así que necesitas que el pasado esté registrado y sea comparable al presente.

Lo mínimo para que la conversación sea seria:

• Histórico con resultado conocido. No basta con tener datos: necesitas saber cómo acabó cada caso. Para predecir bajas hace falta saber quién se fue y cuándo; si tu CRM marca «cliente inactivo» sin fecha, no tienes etiqueta y no hay modelo.
• Volumen razonable de casos positivos. La cifra útil no es «cuántas filas», es cuántos ejemplos del evento raro tienes. Con 40 bajas históricas no se entrena un scoring de churn por mucho que tengas 3.000 clientes.
• Profundidad temporal suficiente para el ciclo. Si tu negocio es estacional, un año de datos te da una sola ocurrencia de cada temporada. Dos o tres años cambian la conversación.
• Estabilidad de definiciones. Si hace ocho meses cambiaste el catálogo, el plan de cuentas o la forma de tipificar incidencias, el histórico anterior habla otro idioma. Se puede mapear, pero hay que saberlo antes de prometer plazos.
• Disponibilidad en el momento de decidir. El error más frecuente y más caro: entrenar con una variable que en producción no existe todavía cuando hay que predecir. Si usas «importe facturado del mes» para predecir algo que decides el día 3, estás haciendo trampas sin querer, y el modelo se desploma al salir a real.

Si al leer esto piensas que tu casa no está en orden, la secuencia correcta no es cancelar: es empezar por estrategia de datos y por definir quién manda sobre cada dato, que es de lo que va el gobierno del dato. El trabajo de fontanería que sostiene todo esto lo cuenta bien la disciplina de la ingeniería de datos, y es donde se va el grueso del esfuerzo real de cualquier proyecto.

¿Cómo se sabe si un modelo es bueno sin entender de matemáticas?

No hace falta interpretar una curva ROC. Hacen falta cuatro preguntas y no aceptar respuestas vagas.

1. ¿Comparado con qué? Todo modelo debe compararse con la alternativa barata, no con el azar. Si tu previsión actual es «lo mismo que el año pasado más un 5 %», ese es el listón. Un proveedor que presenta un 87 % de acierto sin decirte qué acierta el método tonto te está ocultando la mitad de la información.

2. ¿Con qué datos se ha medido? El modelo tiene que evaluarse sobre casos que no vio al entrenar, y en previsión, sobre un periodo posterior al de entrenamiento. Medir sobre los mismos datos con los que aprendió es como corregir un examen con las respuestas delante: sale un 98 % que no significa nada.

3. ¿Qué error duele más? Casi nunca son simétricos. En detección de fraude, dejar pasar un caso cuesta miles de euros y una falsa alarma cuesta cinco minutos de revisión: el umbral se pone tirando a paranoico. En un scoring comercial, saturar a un cliente bueno con llamadas puede costar más que ignorar a uno malo. Ese equilibrio es una decisión de negocio, no técnica, y tiene que tomarla alguien de negocio.

4. ¿Aguanta el paso del tiempo? Los modelos se degradan porque el mundo cambia: entra un competidor, sube un precio, cambia la mezcla de clientes. Hay que medir el rendimiento en producción mes a mes y tener definido cuándo se reentrena y quién lo mira.

Una regla práctica para reuniones: pide siempre ver el resultado en forma de decisión, no de porcentaje. «De las 100 cuentas que el modelo marcó como riesgo alto el trimestre pasado, ¿cuántas se dieron de baja?» es una pregunta que se responde con la realidad delante y que desarma cualquier presentación de humo.

¿Qué exigirle a un proveedor de machine learning?

El machine learning en empresas se compra mal porque se compra por demo. Estas son las condiciones que ponemos —y que te recomendamos poner— antes de firmar:

| Exigencia | Por qué importa | Señal de alarma | |---|---|---| | Prueba con tus datos | Una demo con datos ajenos no dice nada de tu caso | «Te enseño el resultado con un dataset de ejemplo» | | Línea base declarada | Sin comparación, cualquier número parece bueno | No saben decirte qué acierta el método actual | | Métrica ligada a negocio | El acierto técnico no paga facturas | Solo hablan de precisión, nunca de euros u horas | | Explicabilidad del caso individual | Alguien tendrá que justificar una decisión | «El modelo es una caja negra, funciona y ya» | | Plan de reentrenamiento | Todos los modelos se degradan | No está en el presupuesto ni en el contrato | | Propiedad del modelo y de los datos | Es tu histórico y tu ventaja competitiva | Cláusulas de reutilización de tus datos poco claras | | Integración en la herramienta real | Un modelo fuera del flujo no lo usa nadie | El entregable es un informe o un cuaderno de código |

Ese último punto es el que más proyectos mata. Un scoring que vive en un fichero que alguien tiene que abrir no se usa a las tres semanas; el mismo scoring como una columna ordenable dentro del CRM que el equipo ya abre cada mañana, sí. La diferencia entre las dos cosas es integración, y es donde se decide el retorno. Lo tratamos a fondo en por qué fracasan los pilotos de IA.

Añade una condición más, poco habitual y muy sana: el derecho a parar. Que el contrato contemple un punto de decisión tras el piloto, con criterios de éxito escritos antes de empezar, y la opción de no continuar sin penalización. Un proveedor honesto no tiene problema con eso; uno que sí lo tiene te está diciendo algo.

¿Cuánto cuesta y en qué plazos se ve algo?

Cifras genéricas de coste sirven de poco porque el rango real depende de lo desordenados que estén los datos, no del algoritmo. Pero la estructura del gasto se reparte de forma bastante estable, y conviene conocerla para no llevarse sorpresas:

• Preparación de datos: la mayor parte. Acceso, limpieza, unificación de maestros, construcción del histórico. Si alguien te presupuesta un proyecto donde esto es una línea menor, o tus datos son excepcionalmente buenos, o el presupuesto está mal.
• Modelado: menos de lo que la gente cree. Con datos ordenados, obtener un primer modelo defendible es cuestión de días, no de meses. La sofisticación algorítmica rara vez es el cuello de botella en un caso de empresa.
• Integración y puesta en producción: más de lo que la gente cree. Conectar con el CRM o el ERP, dejarlo corriendo en un horario fiable, gestionar errores, permisos y trazabilidad.
• Mantenimiento: existe siempre. Monitorización, reentrenamiento, ajuste de umbrales. Presupuéstalo anual desde el principio.

En plazos, un primer caso razonable en una empresa mediana se mide en semanas para el piloto y en meses para tenerlo integrado y en uso. Y una advertencia sobre el orden: el segundo caso de uso siempre sale mucho más barato que el primero, porque la mitad del coste inicial fue construir el camino —accesos, limpieza, integración— que ya está hecho. Por eso conviene elegir el primero pensando en qué infraestructura deja instalada, no solo en su retorno aislado.

¿Qué riesgos legales y de gobierno hay que cubrir?

Un modelo que puntúa personas —clientes, candidatos, empleados— no es un ejercicio técnico neutro. Lo mínimo antes de salir a producción:

• Base legal y datos personales. Si entrenas con datos de personas identificables, aplica el marco completo de protección de datos: finalidad, minimización, plazos de conservación. Lo detallamos en consultoría RGPD e IA, y cuando se puede trabajar con datos tratados, en anonimización de datos.
• Decisiones automatizadas sobre personas. Si el modelo decide sin intervención humana y afecta significativamente a alguien, hay obligaciones adicionales de información y de derecho a intervención humana. La salida práctica casi siempre es la misma: que el modelo proponga y una persona decida.
• Sesgo heredado del histórico. El modelo replica lo que había. Si históricamente se atendía peor a un segmento, el modelo lo aprende y lo consolida con apariencia de objetividad. Se controla midiendo el rendimiento por segmentos, no solo el global.
• Trazabilidad. Guardar qué versión del modelo produjo cada predicción, con qué datos de entrada y quién actuó en consecuencia. Sin eso no se puede explicar una decisión seis meses después ni corregir un fallo sistemático.

Nada de esto es burocracia defensiva: es lo que permite que el proyecto sobreviva a la primera reclamación de un cliente o a la primera pregunta incómoda del comité.

Preguntas frecuentes

¿Cuántos datos necesito para aplicar machine learning en mi empresa?

Depende más del evento que quieres predecir que del tamaño total. La pregunta correcta no es cuántas filas tienes, sino cuántos ejemplos del caso a predecir hay en el histórico y si están bien etiquetados. Como orden de magnitud práctico, con menos de unos cientos de ocurrencias del evento conviene empezar por reglas o análisis descriptivo y volver al modelo cuando el histórico crezca.

¿Es lo mismo machine learning que inteligencia artificial generativa?

No. El machine learning clásico predice o clasifica a partir de tu histórico —una probabilidad, una cantidad, una categoría— y se evalúa contra resultados reales. La IA generativa produce texto o imágenes y se evalúa de otra manera, con otros riesgos. Los dos caben en la misma empresa y muchas veces en el mismo flujo, pero resuelven problemas distintos; lo desarrollamos en IA generativa en la empresa.

¿Necesito contratar un equipo de científicos de datos?

Para el primer caso, casi nunca. Tiene más sentido apoyarse en alguien externo que monte el caso completo y deje la infraestructura funcionando, y evaluar la incorporación interna cuando haya dos o tres modelos vivos que mantener. Lo que sí necesitas desde el día uno es una persona interna que conozca el negocio y responda de los criterios.

¿Cómo sé si un modelo ha dejado de funcionar?

Por deterioro de la métrica en producción, no por sensación. Se define desde el principio un indicador ligado al negocio, se mide cada mes sobre casos reales y se fija un umbral que dispara revisión. Si nadie está mirando ese número, el modelo lleva meses fallando y todavía no os habéis enterado.

Si tienes un caso en la cabeza y no sabes si tus datos aguantan un modelo o todavía toca ordenar antes, eso es exactamente lo que sale de la auditoría: casos ordenados por esfuerzo y retorno, con el estado real de tu histórico como punto de partida y un veredicto claro sobre qué es viable este año. Si prefieres contrastarlo en media hora antes de mover nada, hablemos.