Cuándo no usar inteligencia artificial en una empresa

El cierre de mes que no cuadra y nadie sabe explicar por qué

Un director financiero me contó hace poco cómo su equipo empezó a usar un modelo de lenguaje para acelerar la conciliación entre el sistema contable y los reportes bancarios. Funcionó bien las primeras semanas: el modelo cruzaba montos, señalaba diferencias y redactaba el resumen para el cierre. Nadie cuestionaba el resultado porque sonaba coherente y llegaba rápido. El problema apareció en un cierre trimestral, cuando un desfase pequeño pero real no cuadraba con ningún movimiento registrado. Nadie del equipo podía explicar de dónde salió, porque nadie había revisado línea por línea lo que el modelo había “conciliado”: solo habían revisado que la explicación sonara razonable.

Esa escena no es un caso aislado ni un error de configuración. Es lo que pasa cuando se usa una herramienta diseñada para predecir el texto más probable en tareas que exigen un resultado exacto y verificable. El modelo no falló por estar mal entrenado: falló porque nunca debió estar ahí. Saber dónde no va la inteligencia artificial es la parte del criterio que ningún proveedor ofrece en la primera reunión, porque no factura, y es también la que evita que un proyecto termine costando más de lo que iba a ahorrar.

El criterio que nadie vende: saber decir dónde no va la IA

Todo el discurso comercial alrededor de la inteligencia artificial está construido sobre el “sí se puede”. Casi ningún proveedor abre una propuesta diciendo en qué parte de tu operación esta herramienta no sirve, porque ese diagnóstico no se cotiza. Y sin embargo, es el diagnóstico que más plata le ahorra a una empresa: identificar a tiempo dónde un modelo de lenguaje no es la respuesta evita meses de implementación, de parches y de reuniones explicando por qué el sistema “se equivocó”, cuando en realidad se le pidió algo para lo que no estaba hecho.

Esa definición agrupa cuatro condiciones distintas, y conviene separarlas porque cada una tiene una señal propia y una alternativa distinta. No es lo mismo un proceso que exige exactitud matemática que uno donde simplemente no hay volumen suficiente para justificar la inversión, y no es lo mismo una decisión con consecuencia legal que una donde nadie sabría decir qué resultado es “bueno”. Estos son los seis casos que reviso antes de aprobar cualquier proyecto de inteligencia artificial en una empresa:

• Cálculos exactos y conciliaciones: cualquier tarea donde el resultado tiene que ser el correcto, no el más probable.
• Decisiones con consecuencia legal sin revisión: contratos, despidos, reclamos, respuestas a un regulador, donde alguien tiene que responder por lo que se dijo.
• Procesos de bajo volumen: tareas que ocurren pocas veces al mes, donde mantener el sistema cuesta más que hacerlo a mano.
• Tareas sin criterio de correcto: cuando nadie en la empresa puede decir con precisión qué distingue una buena respuesta de una mala.
• Decisiones estratégicas únicas e irreversibles: las que no tienen precedente ni historial propio del que aprender.
• Procesos rotos que se disfrazan de proyectos de IA: cuando el problema real es que nadie ordenó el proceso antes de automatizarlo.

Cálculos exactos y conciliaciones: por qué un LLM no es una calculadora

Un modelo de lenguaje no ejecuta aritmética como una hoja de cálculo o un motor contable: predice la secuencia de texto más probable dada la pregunta. La mayoría de las veces esa predicción coincide con el cálculo correcto, sobre todo en operaciones simples, y esa coincidencia genera una confianza que no está garantizada. Cuando el cálculo se complica (montos con múltiples monedas, ajustes en cascada, conciliaciones con cientos de líneas) el modelo puede producir un número que suena exacto, con la misma seguridad con la que produce el número correcto. A eso se le llama una alucinación de IA: una respuesta construida con total coherencia de forma, sin que nadie la haya verificado contra la realidad.

El riesgo no es que el modelo se equivoque una vez, es que se equivoque con la misma confianza con la que acierta, así que nada en la respuesta avisa que hay que revisarla dos veces. En conciliaciones bancarias, cálculos de nómina, cierres contables o inventarios, ese tipo de error no se nota hasta que alguien lo busca activamente, y para entonces ya se tomaron decisiones sobre un número que nunca fue real.

Lo correcto acá es separar el cálculo de la conversación: el número lo produce un sistema determinista (el propio ERP, una hoja de cálculo con fórmulas, un script o una consulta directa a la base de datos), y el modelo de lenguaje, si participa, se limita a explicar el resultado en palabras simples o a redactar el resumen del cierre. La regla práctica es simple: si dos personas le dan la misma información al sistema y pueden recibir respuestas distintas, ese sistema no debería ser el que calcula, debería ser, cuando mucho, el que explica lo que otro sistema ya calculó.

Decisiones con consecuencia legal sin revisión humana

Hay decisiones donde el costo de un error no es una cifra torcida en un reporte, es una demanda, una multa o un despido mal ejecutado. Aprobar una cláusula contractual, redactar la respuesta a un reclamo, decidir a quién se le corta la relación laboral, contestarle a un regulador: en todos estos casos, un modelo de lenguaje puede producir un texto fluido, bien argumentado y completamente insostenible frente a la ley, porque no conoce la jurisprudencia local vigente, no tiene los hechos completos del caso, y no asume ninguna responsabilidad por lo que firma, porque no firma nada.

Marcos de gestión de riesgo como el del NIST clasifican explícitamente el nivel de supervisión humana que requiere cada tipo de decisión automatizada, y la regulación europea de IA sigue la misma lógica: a mayor riesgo para las personas, mayor exigencia de control humano antes de actuar. Ninguno de los dos marcos dice “no uses IA en lo legal”: dicen que en decisiones de alto riesgo la revisión humana no es opcional, es una condición para operar.

Qué usar en su lugar: un abogado o el área de cumplimiento como filtro final obligatorio, siempre, sin excepción de “por esta vez no hace falta”. El modelo puede ayudar a redactar un primer borrador o a resumir un expediente extenso, pero el criterio para limitar las respuestas de un LLM que representa a la empresa tiene que incluir, de entrada, que ninguna respuesta con consecuencia legal sale sin que una persona con la autoridad para responder por ella la revise antes de enviarse.

Procesos de bajo volumen: cuando automatizar cuesta más que hacerlo a mano

Automatizar con inteligencia artificial no es gratis después de la implementación: hay que mantener el prompt, monitorear que no se salga de tono, revisar sus respuestas cada cierto tiempo y actualizarlo cuando cambia el proceso que ejecuta. Si la tarea ocurre pocas veces al mes, ese costo de mantenimiento supera con facilidad lo que la automatización ahorra en tiempo. He visto equipos meterle meses de trabajo a un asistente para un proceso que ocurre cuatro o cinco veces al mes, cuando ese mismo tiempo alcanzaba para resolverlo a mano durante los próximos dos años.

El volumen no es un detalle menor, es la variable que determina si automatizar tiene sentido económico. Antes de construir cualquier solución conviene preguntar cuántas veces al mes se repite la tarea y cuánto cuesta hoy hacerla manualmente, porque esa cuenta, aunque sea aproximada, ya descarta la mitad de los proyectos que llegan con la etiqueta de “urgente”.

Para procesos de bajo volumen, lo que funciona es una plantilla clara, una checklist corta o, cuando mucho, una macro simple que reduzca el trabajo repetitivo sin la carga de mantener un modelo. Reserva los agentes de IA empresariales para procesos de volumen alto y estable, donde la inversión en mantenerlos se paga sola en pocos meses. Automatizar lo esporádico no es eficiencia, es complejidad que nadie pidió.

Tareas sin criterio de correcto: si nadie puede decir qué es un buen resultado

Para que un modelo de lenguaje sea útil en una tarea, alguien en la empresa tiene que poder mirar dos respuestas distintas y decir cuál es mejor, y por qué. Cuando esa definición no existe (decisiones de gusto, tono de marca sin lineamiento escrito, prioridades que cambian según quién esté a cargo ese día) no hay forma de saber si el modelo está funcionando bien o mal, porque no hay una vara contra la cual medirlo. Un sistema que nadie puede evaluar no es un sistema en producción, es una apuesta.

Este caso se confunde seguido con el de bajo volumen, pero es distinto: acá el problema no es cuántas veces ocurre la tarea, es que la empresa nunca se sentó a definir qué distingue un resultado correcto de uno incorrecto. Antes de pedirle a un modelo que redacte, clasifique o decida, hace falta poder evaluar un modelo de lenguaje contra un criterio explícito, y si ese criterio no existe todavía, ese es el primer proyecto, no el modelo.

Lo que corresponde acá es, primero, sentar a quien conoce el negocio a escribir la rúbrica: qué hace que una respuesta sea buena, qué la descalifica, con ejemplos concretos de ambas. Recién con esa rúbrica escrita tiene sentido evaluar si un modelo puede ejecutar la tarea. Sin ella, la decisión sigue siendo del criterio humano, y meterle un modelo encima solo agrega una capa de automatización sobre una ambigüedad que nadie resolvió.

Decisiones estratégicas únicas e irreversibles

Entrar a un país nuevo, comprar a un competidor, cambiar el modelo de negocio, elegir al socio equivocado: son decisiones que una empresa toma una vez, no cientos de veces, y de las que no existe un historial propio del que un modelo pueda aprender un patrón. Un modelo de lenguaje puede resumir información, comparar escenarios o exponer riesgos que alguien no había considerado, pero la decisión en sí depende de un juicio sobre el futuro que ningún patrón de datos garantiza, porque no hay datos de un futuro que todavía no pasó.

Estas decisiones siguen siendo del comité de dirección, con o sin inteligencia artificial de por medio. Lo que sí ayuda es usar el modelo como investigador rápido: que junte información dispersa, arme un resumen de opciones o redacte los escenarios para que la conversación entre personas empiece con más contexto y menos horas perdidas buscando datos. La responsabilidad de decidir, y de responder por esa decisión, sigue siendo humana porque no hay a quién más atribuírsela.

Cuando el problema es el proceso roto, no la falta de un modelo

El caso más caro de los seis, y el que más se repite, es este: una empresa compra inteligencia artificial para arreglar un proceso que ya estaba roto antes de que la IA llegara. Nadie tiene claro quién es dueño del proceso, la información llega de tres fuentes que no cuadran entre sí, o cada persona lo ejecuta a su manera según el día. Meterle un modelo de lenguaje encima de ese desorden no lo ordena, lo amplifica: ahora el caos se produce más rápido y con un tono de autoridad que antes no tenía.

Es la versión más literal de una idea que sostengo en cada proyecto: la inteligencia artificial no arregla una mala estrategia ni un mal proceso, los expone más rápido. Si antes tardabas semanas en notar que un proceso estaba desordenado, con un modelo mal aplicado lo notas el mismo día, solo que ya con el problema multiplicado y con menos margen para corregirlo a tiempo.

• Nadie puede nombrar quién es dueño del proceso: si la responsabilidad se reparte entre “el equipo”, todavía no hay proceso, hay un conjunto de tareas sueltas.
• Los datos de entrada cambian según quién los carga: si dos personas ejecutan el mismo paso de forma distinta, automatizarlo solo estandariza el desorden a mayor velocidad.
• El objetivo declarado es “que la IA lo resuelva”, sin que nadie describa el proceso paso a paso: eso no es un proyecto de IA, es evitar la conversación incómoda de ordenar la casa.

Antes de automatizar, mapea el proceso completo, asigna un dueño con nombre y apellido, y estandariza cómo entra la información. Recién con eso resuelto vale la pena revisar si conviene meter un modelo encima, y para entonces la mitad de los errores al implementar IA en una empresa que veo repetirse ya se evitaron solos, porque nacieron siempre del mismo origen: automatizar el desorden en vez de corregirlo primero.

El criterio de saber decir que no es el que sostiene todo lo demás

De los seis casos anteriores, el hilo común no es técnico, es de criterio: en cada uno, alguien tuvo que decidir no usar la herramienta de moda porque el problema real pedía otra cosa. Ese tipo de decisión no aparece en ningún caso de éxito que se publique en LinkedIn, porque no hay nada vistoso que mostrar, solo un proyecto que no se hizo, o que se hizo distinto de como se pidió originalmente.

Una empresa que avanza hacia ser empresa AI Native no se mide por cuántos procesos le metió un modelo de lenguaje, se mide por cuántas veces supo distinguir dónde sí y dónde no. Ese criterio no se automatiza ni se delega: se construye caso por caso, revisando el resultado real y no la promesa inicial. La pregunta que vale la pena hacerse antes de cualquier proyecto nuevo no es qué tan potente es el modelo disponible hoy, es si el problema que tienes enfrente es, de verdad, un problema que un modelo puede resolver.