Por dónde empezar con inteligencia artificial en una empresa mediana

Casi todas las conversaciones sobre inteligencia artificial en empresas medianas empiezan por el lado equivocado. Alguien vio una herramienta, un competidor anunció que «ya usa IA», o el consejo preguntó qué estamos haciendo al respecto. La conversación arranca desde la tecnología y busca dónde aplicarla.

Ese orden produce casi siempre el mismo resultado: un proyecto piloto que impresiona en la demostración, que nadie usa a los tres meses, y una conclusión colectiva de que «la IA todavía no está madura para nuestro sector».

El orden que funciona es el inverso, y es bastante menos emocionante. Empieza por un proceso aburrido que consume horas, y solo después pregunta si hay alguna forma de que una máquina haga parte de ese trabajo.

Qué es y qué no es, en términos prácticos

Sin entrar en definiciones técnicas, para decidir hace falta distinguir tres cosas que se venden bajo la misma etiqueta.

Automatización de reglas. Si pasa A, haz B. No es inteligencia artificial, es programación de toda la vida, y resuelve una porción enorme de los problemas por los que las empresas creen necesitar IA. Es más barata, más predecible y más fácil de mantener. Cuando alguien te vende IA para algo que se resuelve con una regla, te está vendiendo complejidad.

Modelos que predicen o clasifican. Aprenden de datos históricos para estimar algo: qué cliente va a cancelar, cuánto se va a vender el mes que viene, si esta pieza tiene un defecto. Necesitan datos históricos suficientes y de calidad razonable. Cuando existen, funcionan muy bien.

Modelos de lenguaje. Los que leen, escriben, resumen y responden. Son los que popularizaron el tema y los que más rápido se pueden poner a trabajar, porque no requieren entrenar nada: se usan tal cual. Su terreno natural es todo lo que hoy hace una persona leyendo o escribiendo texto.

La mayor parte del valor accesible para una empresa mediana mexicana hoy está en la primera y la tercera categoría. La segunda exige una madurez de datos que muchas todavía no tienen.

Cómo elegir el primer proceso

Este es el punto que decide el resultado del proyecto, y se puede resolver con una hoja y una reunión de dos horas.

Haz una lista de procesos que cumplan estas cuatro condiciones:

Se repite mucho. Decenas o cientos de veces al mes. Un proceso que ocurre tres veces al año no justifica el esfuerzo aunque sea tedioso.

Consume horas de personas. Y horas identificables: alguien puede decir «esto me lleva media mañana cada día».

Tiene reglas relativamente claras. No hace falta que sean perfectas, pero sí que un empleado nuevo pueda aprenderlo en una semana. Un proceso donde cada caso depende del criterio de una persona con quince años de experiencia es mal candidato para empezar.

El error tiene costo tolerable. En el primer proyecto conviene que una equivocación se pueda corregir sin consecuencias graves. Automatizar el cálculo de nómina o el control de calidad de un componente crítico no es por donde se empieza.

Los candidatos típicos en una empresa mediana mexicana suelen ser: clasificar y responder correos entrantes de un buzón genérico, extraer datos de facturas o remisiones que llegan en PDF, redactar primeras versiones de documentos repetitivos —cotizaciones, contratos estándar, fichas—, resumir llamadas o reuniones, dar respuesta de primer nivel a preguntas frecuentes de clientes o de personal interno.

Ninguno de esos suena impresionante. Todos devuelven horas desde la primera semana.

Lo que de verdad cuesta

Hay una distribución de costos que sorprende a casi todos y que conviene anticipar: la tecnología es la parte barata.

Ordenar los datos. Si el proceso depende de información que vive en tres sistemas, dos hojas de cálculo y la cabeza de una persona, el primer trabajo es consolidarla. Esto suele ser la mitad del esfuerzo del proyecto y es invisible para quien lo aprueba.

Cambiar la forma de trabajar. Una herramienta que nadie usa no produce nada. La adopción exige explicar, entrenar, acompañar y ajustar durante semanas. Es la parte que más proyectos hunde y la que menos aparece en las cotizaciones.

Mantener. Los procesos cambian, los datos cambian, los modelos se degradan. Un proyecto de IA no se entrega y se olvida; necesita alguien que lo revise periódicamente.

La tecnología en sí. El costo de las herramientas y del consumo de modelos, que para los volúmenes de una empresa mediana suele ser sorprendentemente modesto comparado con lo anterior.

Cuando una propuesta dedica el noventa por ciento del texto a la tecnología y no menciona datos ni adopción, está describiendo el diez por ciento del trabajo.

Cómo se ve un primer proyecto bien planteado

Un ejemplo de estructura, sin nombres ni cifras inventadas, con la forma que sí funciona:

Semanas 1 y 2 — Entender y medir. Observar el proceso tal como es hoy. Cuántas veces ocurre, cuánto tarda, quién lo hace, dónde falla, qué excepciones existen. Y —esto es lo crítico— dejar registrado el número de partida. Sin la línea base, en tres meses nadie va a poder decir si mejoró.

Semanas 3 y 4 — Construir lo mínimo. No la versión completa: la que resuelve el caso más común y deja las excepciones a la persona. Un sistema que atiende bien el setenta por ciento de los casos y pasa el resto a un humano vale más que uno que intenta el cien por ciento y falla de forma impredecible.

Semanas 5 a 8 — Operar en paralelo. La máquina y la persona hacen lo mismo, y se comparan resultados. Es la fase que casi nadie quiere pagar y la que evita los desastres. Aquí se descubren las excepciones que nadie mencionó.

Semana 9 en adelante — Ceder el control gradualmente. Primero los casos claros, después los demás. Con un mecanismo simple para que cualquiera pueda señalar un error.

Es un proyecto de dos o tres meses con resultado medible. No es una transformación digital. Y precisamente por eso funciona: es lo bastante pequeño como para terminarlo.

Quién debe estar en la mesa

La composición del equipo del primer proyecto predice su resultado mejor que el presupuesto.

Quien ejecuta el proceso hoy. Es la persona más importante de la mesa y la que más veces se omite. Conoce las excepciones que no están documentadas, sabe por qué el procedimiento oficial no se sigue, y si no participa desde el principio, va a tener razones para que el proyecto no funcione.

Alguien de sistemas. No necesariamente para construir, sino para responder dónde viven los datos y qué se puede conectar con qué. Su ausencia produce proyectos que descubren en la semana seis que el sistema de facturación no tiene forma de comunicarse con nada.

Alguien con autoridad para cambiar el proceso. Porque casi siempre hay que cambiarlo. Si el equipo solo puede automatizar el proceso tal como está, va a automatizar también sus defectos.

Un responsable con tiempo asignado. No un patrocinador que aprueba y desaparece: alguien con horas en su semana para esto. Los proyectos sin dueño operativo mueren en cuanto aparece una urgencia, y siempre aparece.

Lo que no hace falta es un especialista en inteligencia artificial dentro de la empresa. Para un primer proyecto, el conocimiento técnico se contrata; lo que no se puede contratar es el conocimiento del proceso.

Preguntas para hacerle a un proveedor

Si vas a contratar ayuda externa, seis preguntas separan bastante bien:

«¿Qué proceso me recomiendas empezar y por qué ese?» Un proveedor que responde antes de haber entendido tu operación está vendiendo lo que sabe hacer, no lo que necesitas.

«¿Cómo vamos a medir si funcionó, y cuál es el número de hoy?» Si no pregunta por la línea base, no piensa medir.

«¿Qué pasa cuando el sistema no esté seguro de la respuesta?» La respuesta correcta describe un umbral y una derivación a persona. Si la respuesta es que el sistema siempre responde, hay un problema de diseño.

«¿Dónde se procesan mis datos y qué hace el proveedor de tecnología con ellos?» Debe poder responderlo con precisión.

«¿Dónde quedan las reglas y los datos si terminamos la relación?» La respuesta correcta es que quedan contigo, en formato exportable.

«¿Cuánto de este presupuesto es tecnología y cuánto es trabajo humano?» Si la respuesta es que casi todo es tecnología, el proyecto está mal dimensionado: la parte de ordenar datos y acompañar la adopción no puede costar poco porque es la que más trabajo lleva.

Los cinco errores que más se repiten

Empezar por la herramienta. Comprar una plataforma y después buscar en qué usarla. Es el camino más rápido hacia una licencia que se renueva por inercia.

Elegir el proceso más complejo para demostrar poder. El primer proyecto tiene una función política además de operativa: generar confianza. Un éxito pequeño y visible desbloquea el segundo proyecto; un fracaso ambicioso cierra el tema por dos años.

No medir antes. Sin línea base, el resultado se discute con impresiones. Y en las discusiones por impresiones gana quien tenía dudas desde el principio.

Excluir a quien hace el trabajo. El proyecto se diseña con dirección y sistemas, y a la persona que ejecuta el proceso se le presenta el resultado. Esa persona conoce las veinte excepciones que nadie documentó y, si no participó, no tiene ninguna razón para ayudar a que funcione.

Tratar la salida del modelo como verdad. Los modelos de lenguaje producen respuestas plausibles, que no es lo mismo que correctas. Cualquier proceso donde el error tenga consecuencias necesita revisión humana, y el diseño tiene que contemplarla desde el principio en vez de descubrirla después.

Lo que hay que resolver antes de conectar nada

Tres cuestiones que en México se pasan por alto y que traen consecuencias.

Qué datos salen de la empresa. Muchas herramientas procesan la información en servidores de terceros fuera del país. Si el proceso maneja datos personales de clientes o de empleados, eso entra en el ámbito de la Ley Federal de Protección de Datos Personales y hay que revisarlo. No es un impedimento —hay formas de hacerlo bien— pero es una conversación que se tiene antes, no después.

Quién responde si la máquina se equivoca. Si el sistema clasifica mal una solicitud o redacta mal una cotización, ¿quién asume el error frente al cliente? Definirlo por adelantado evita discusiones incómodas.

Qué pasa si el proveedor desaparece o sube el precio. Construir un proceso crítico sobre una herramienta de un proveedor único es asumir un riesgo. Conviene saber cuánto costaría cambiar.

Ninguna de las tres exige una respuesta perfecta. Exigen una respuesta consciente.

Cómo saber si funcionó

Cuatro medidas, en orden de honestidad decreciente:

Horas devueltas. Cuántas horas de persona al mes dejó de consumir el proceso. Es el número más difícil de discutir.

Tiempo de ciclo. Cuánto tardaba antes y cuánto tarda ahora. Especialmente relevante cuando la lentitud costaba clientes.

Tasa de error. Comparada con la línea base humana, que casi nunca es cero. Un sistema con 4% de error que sustituye a un proceso manual con 7% es una mejora, aunque el 4% se note más porque es de la máquina.

Adopción. Qué porcentaje de los casos pasa efectivamente por el sistema. Un proyecto técnicamente exitoso con 20% de adopción es un fracaso disfrazado.

Y una advertencia sobre el retorno de inversión. Calcularlo con precisión en el primer proyecto es difícil y suele producir números que nadie cree. Es más útil medir las horas devueltas y dejar que la dirección haga la aritmética con su propio costo por hora.

Tres casos frecuentes, con su forma real

Para aterrizarlo, así se ven tres proyectos típicos en empresas medianas de la región, sin cifras inventadas pero con la estructura que suelen tener.

El buzón de contacto que nadie alcanza a atender. Llegan solicitudes mezcladas: cotizaciones, soporte, facturas, currículums, publicidad. Alguien las revisa una vez al día y reenvía. El proyecto consiste en clasificar automáticamente, extraer los datos relevantes, crear el registro en el CRM y notificar a quien corresponde. Lo difícil no es la clasificación: es acordar las categorías y qué hacer con lo ambiguo.

La captura de documentos que llegan en PDF. Facturas de proveedores, remisiones, certificados. Alguien los abre y teclea los datos en el sistema. El proyecto extrae los campos y los deja listos para validación. Lo difícil no es leer el PDF: es que los proveedores mandan veinte formatos distintos y algunos escaneados torcidos, y hay que decidir qué hacer cuando la confianza es baja.

Las preguntas internas repetidas. Personal preguntando por políticas, procedimientos, prestaciones. El proyecto conecta un asistente a los documentos internos. Lo difícil no es el asistente: es que los documentos internos están desactualizados, se contradicen entre sí, o directamente no existen y la respuesta vive en la cabeza de alguien de administración.

El patrón se repite en los tres: la tecnología es la parte resuelta y el trabajo está en ordenar lo que había debajo. Por eso el primer proyecto de una empresa casi siempre tarda más de lo previsto y por eso el segundo va mucho más rápido.

Lo que sigue después del primero

Si el primer proyecto funciona, la tentación es escalar de golpe. Suele ser mejor hacer dos o tres proyectos pequeños más, en procesos distintos y con áreas distintas.

Hay una razón práctica: cada proyecto enseña algo sobre la empresa —dónde están los datos, quién se resiste, qué tan buenas son las reglas escritas— y ese aprendizaje vale más que la eficiencia ganada. Después de tres proyectos, una empresa sabe si tiene capacidad interna para sostener esto o si necesita ayuda permanente.

Y hay una razón organizativa: tres áreas distintas con una experiencia positiva construyen mucho más apoyo interno que un solo departamento con un sistema muy sofisticado.

La transformación de verdad —la que cambia cómo opera la empresa— no llega por un proyecto grande. Llega por la acumulación de proyectos pequeños que funcionaron, y por la confianza que eso genera para intentar el siguiente.