En corto
- Si el proceso no está definido ni para una persona, un modelo no lo va a definir por ti: lo hará inconsistente y más rápido.
- Con poco volumen no amortizas el coste de construir, probar y vigilar el sistema. Sale más barato seguir a mano.
- Si la respuesta tiene que ser exacta siempre (impuestos, nóminas, stock, conciliaciones), va con reglas y código determinista, no con un modelo.
- Si los datos están duplicados, dispersos o mal escritos, no tienes un proyecto de IA: tienes un proyecto de datos.
- Si lo que quieres preguntar ya está en una tabla, lo que necesitas es un informe, no un modelo.
- Donde sí compensa: documentación dispersa, clasificación de documentos, extracción de datos de facturas y albaranes, y primer filtro de atención.
Casi todo lo que se vende como IA no necesita IA
Hay una avalancha de gente vendiendo inteligencia artificial que nunca ha mantenido un sistema en producción. La demo funciona, la factura llega, y meses después nadie usa aquello. No siempre es mala fe. Muchas veces la pregunta de partida está mal planteada. La pregunta no es dónde meto IA. La pregunta es qué tarea concreta se hace hoy a mano, cuántas veces al mes, y qué pasa exactamente cuando sale mal.
Un modelo de lenguaje es una máquina de producir respuestas verosímiles a partir de texto. Esa es su naturaleza, no un defecto que se arregle con más presupuesto. Es potentísimo cuando la entrada es desordenada y el error tiene remedio barato. Es un desastre cuando la entrada ya está estructurada y el error se paga en dinero o en una inspección.
Escribimos esto porque decir que no a tiempo ahorra más que cualquier implantación. Un desarrollador que solo dice que sí no te está asesorando, te está facturando.
Si el proceso no está definido ni para una persona, un modelo no lo va a arreglar
Automatizar es poner un criterio por escrito y hacer que se ejecute solo. Si el criterio no existe, no hay nada que automatizar. Y ahí la IA no ayuda: rellena el hueco con lo que le parece razonable, con una seguridad aparente que no te avisa de nada.
La prueba es barata y la puedes hacer esta semana. Coge diez casos reales de la tarea, dáselos por separado a dos personas de la empresa y compara lo que hacen. Si no coinciden, no tienes un problema de tecnología. Tienes un proceso sin definir, y ese es el proyecto de verdad.
Hay una señal muy fiable: cuando preguntas por qué se hace así y la respuesta es depende, o lo lleva Marisa. Eso no es documentación, es una persona sosteniendo el criterio en su cabeza. Escríbelo primero. Muchas veces, al escribirlo, descubres que la tarea se resuelve con tres reglas y un formulario.
- Escribe la tarea en una frase: qué entra, qué sale, quién lo revisa.
- Enumera las excepciones reales, no las teóricas. Las excepciones son el proceso.
- Si dos personas competentes no dan el mismo resultado, define antes de automatizar.
- Si al escribirlo caben tres reglas, implementa las tres reglas y ahórrate el modelo.
¿Cuánto volumen hace falta para que la IA compense?
El cálculo es aritmética simple y casi nadie lo hace. Por un lado, minutos que ahorras por caso multiplicado por casos al mes. Por otro, lo que cuesta construirlo, probarlo con casos reales, integrarlo con lo que ya tienes, vigilarlo cuando falle y volver a ajustarlo cuando cambie el formato de entrada. Pon tus números, no los míos.
Hay una trampa en el primer término. La IA no elimina la revisión, la desplaza. Si el resultado importa, alguien lo comprueba, y comprobar también cuesta tiempo. El ahorro real es el tiempo de hacerlo menos el tiempo de revisarlo, no el tiempo completo. En tareas cortas, revisar puede costar casi lo mismo que hacerlo.
Con volumen bajo pasa algo peor que no amortizar. Nunca acumulas suficientes casos para saber si el sistema funciona. Vas a estar decidiendo sobre impresiones durante meses. Si la tarea se hace cuatro veces al mes, hazla a mano y dedica el esfuerzo a lo que se repite cien veces al día.
Cuando la respuesta tiene que ser exacta siempre, no pongas un modelo
Hay cálculos donde aproximado significa mal. Una liquidación de impuestos especiales, una nómina, un recuento de stock, una conciliación bancaria, un albarán que tiene que cuadrar con la factura. En todo eso no quieres una respuesta plausible: quieres la respuesta, reproducible, auditable y explicable ante quien la pida.
Eso se resuelve con código determinista. Reglas, tipos aplicables, tablas maestras, tests que se ejecutan solos y fallan si alguien toca algo. Si mañana te preguntan por qué salió esa cifra, puedes enseñar la regla y el dato de entrada. Con un modelo generativo, la explicación es una reconstrucción a posteriori, y eso no vale como justificación.
En el software que mantengo para impuestos especiales, como SILICIE VapeTax, la liquidación no se le pregunta a nadie: se calcula con reglas y se valida contra los maestros. Donde un modelo sí puede aportar es alrededor: leer el PDF que te manda el proveedor, proponer a qué referencia corresponde una descripción escrita a mano. Y siempre con la misma arquitectura de seguridad: el modelo propone, el código decide y rechaza lo que no existe en la base de datos.
Datos sucios o dispersos: eso no es un proyecto de IA, es un proyecto de datos
El mismo cliente dado de alta tres veces con tres grafías. Referencias que en el ERP se llaman de una forma y en el Excel de compras de otra. Documentos repartidos entre un correo, una carpeta compartida y el escritorio de alguien. Ese es el estado de partida habitual, y no lo arregla ningún modelo.
Lo que ocurre si lo metes igualmente es peor que no tener respuesta: obtienes una respuesta segura construida sobre datos parciales. Nadie la cuestiona porque está bien redactada. Ahí es donde se toman decisiones malas con confianza alta.
La parte aburrida es la que genera el valor. Una fuente única por entidad, identificadores estables, deduplicación, un sitio donde vivan los documentos y una forma de saber cuál es la versión buena. Cuando eso está hecho, muchas veces la necesidad de IA se reduce a la mitad, porque el problema real era que no encontrabas nada.
Y desconfía del piloto que va perfecto. Las demos se hacen con datos elegidos. Pide que la prueba se haga con tus casos feos: el escaneo torcido, el proveedor que cambió el formato, el albarán con anotaciones a bolígrafo.
Lo que me pides no es IA, es una consulta a la base de datos
Cuánto he vendido este mes por cliente. Qué pedidos llevan más de una semana sin salir. Qué referencias están por debajo del mínimo. Nada de eso necesita un modelo. Son consultas sobre datos que ya tienes estructurados, y la respuesta correcta se calcula, no se genera.
Un informe bien hecho es instantáneo, exacto, repetible y no cuesta nada por ejecución. Poner una capa de lenguaje natural por encima añade un punto de fallo silencioso: si traduce mal tu pregunta a una consulta, te devuelve un número creíble y equivocado, y no tienes forma fácil de notarlo.
La regla que uso para separar los dos mundos es sencilla. Si la respuesta ya existe como dato en una tabla, hazlo con un informe o una integración. Si la respuesta está enterrada en texto libre, correos, contratos, manuales o PDFs escaneados, entonces el modelo empieza a ganarse el sitio.
¿En qué casos sí merece la pena meter IA?
Los casos buenos comparten cuatro rasgos: entrada desordenada, volumen alto, error con remedio barato, y una persona o una regla que valida el resultado antes de que tenga consecuencias. Si falta alguno de los cuatro, revisa el planteamiento.
- Documentación dispersa. Manuales, procedimientos, correos y contratos donde nadie encuentra nada. Un buscador que responde citando el documento y la página, para que puedas comprobarlo. Sin cita, no sirve.
- Clasificación de documentos. Que cada cosa que entra se etiquete y vaya a su sitio. Aquí el error es barato: se corrige moviendo el documento, y esa corrección sirve para mejorar el criterio.
- Extracción de datos de facturas y albaranes. Convertir un PDF en campos, cotejarlos contra el pedido y avisar solo de lo que no cuadra. La revisión se concentra en las excepciones en vez de en todo.
- Primer filtro de atención. Responder lo repetitivo, recoger los datos del caso y pasar a una persona lo que no encaje. Con una condición: que el traspaso a humano sea fácil y visible, no un laberinto.
Cómo decidir en una tarde si tu caso aguanta IA
Este es el protocolo que aplico antes de escribir una línea de código. No necesitas contratar a nadie para hacerlo.
Si no consigues reunir el conjunto de casos del punto dos, ya tienes la respuesta: el proyecto todavía no existe. Y si el proveedor no quiere que la decisión dependa de esa prueba, es que la prueba le va a salir mal.
- Escribe la tarea en una frase, con qué entra y qué sale. Si no cabe en una frase, son varias tareas.
- Reúne casos reales pasados, incluidos los raros y los mal escaneados. Sin curar.
- Que una persona los resuelva y guarde su respuesta. Eso es tu referencia para comparar y tu medida de cuánto se tarda hoy.
- Define qué cuesta un error, quién lo detecta y en cuánto tiempo. Si nadie lo detecta, no automatices.
- Prueba contra esos casos antes de integrar nada. Compara con la referencia, caso por caso.
- Decide con ese resultado, no con la demo del comercial. Y deja escrito cómo vas a seguir midiendo cuando esté en marcha.
Preguntas frecuentes
¿Merece la pena la inteligencia artificial en una empresa pequeña?+
Depende de si tienes una tarea con volumen alto, entrada desordenada y errores baratos de corregir. Si la tienes, sí puede compensar aunque la empresa sea pequeña. Si lo que hay son tareas variadas, de pocas repeticiones al mes y con criterios que solo están en la cabeza de una persona, no. En ese escenario el dinero rinde más ordenando datos, montando informes decentes o integrando sistemas que hoy se copian a mano.
¿Por qué un modelo de IA se inventa cosas y cómo se evita?+
Porque su trabajo es producir la continuación más plausible de un texto, no verificar hechos. Cuando no tiene el dato, genera algo que encaja en la forma esperada. No se elimina del todo, se acota. Se le da la fuente concreta sobre la que responder, se le exige citar de dónde sale cada afirmación, y se valida la salida contra la base de datos rechazando lo que no exista. En resumen: el modelo propone y el código decide.
¿Necesito tener los datos ordenados antes de meter IA?+
Sí, y es la parte que más se salta. Si el mismo cliente está dado de alta tres veces, las referencias se escriben de formas distintas en cada sistema y los documentos están repartidos entre correos y carpetas, cualquier respuesta automática se construirá sobre información parcial. Lo peor es que sonará convincente. Antes de nada: una fuente única por entidad, identificadores estables, deduplicación y un sitio donde vivan los documentos con una versión buena identificable.
¿Es mejor un chatbot o mejorar el buscador de mi web?+
Si la información que buscan tus clientes ya está publicada y bien estructurada, un buscador rápido y una página de preguntas frecuentes suelen resolver más y fallan menos. Un asistente conversacional gana cuando la información está dispersa en muchos documentos y la gente no sabe cómo se llama lo que busca. En ese caso, exige que responda citando el documento de origen y que pasar a una persona sea fácil y esté siempre visible.
¿Cómo sé si me están vendiendo humo en un proyecto de IA?+
Pide tres cosas. Una: que la prueba se haga con tus datos reales, incluidos los casos feos, y no con ejemplos elegidos. Dos: qué pasa cuando el sistema se equivoca, quién lo detecta y en cuánto tiempo. Tres: cómo se va a medir el resultado frente a hacerlo como se hace hoy. Si las respuestas son genéricas, o si nadie del equipo puede explicar qué ocurre cuando la entrada cambia de formato, ahí no hay producción, hay presentación.
¿Puedo usar IA para calcular impuestos o hacer nóminas?+
Para el cálculo en sí, no. Esas cifras tienen que ser exactas, reproducibles y explicables ante quien las revise, y eso se consigue con reglas y código determinista con pruebas automáticas, no con un modelo que produce respuestas probables. Donde sí puede ayudar la IA es alrededor del cálculo: leer documentos que llegan en formatos distintos, proponer a qué concepto corresponde cada línea o detectar anomalías. La cifra final siempre la calcula el código y se valida contra los datos maestros.
Cuéntanos la tarea, no la tecnología
Si estás valorando meter inteligencia artificial en algún punto de la empresa, descríbenos la tarea concreta: qué entra, qué sale, cuántas veces al mes y qué pasa cuando sale mal. Te diremos si compensa, si se resuelve con reglas y una integración, o si lo que hace falta es ordenar los datos primero. Antes un no razonado que un piloto que nadie va a usar.
Plantéame tu caso