Dónde conviene usar IA en tu empresa (y dónde no)

La respuesta corta: la IA conviene cuando la tarea es repetitiva, tiene volumen, tolera un error revisable y los datos ya existen. Si falta alguna de esas cuatro condiciones, casi siempre hay una solución más barata y más confiable: una regla, un formulario, una integración entre dos sistemas que hoy no se hablan, o directamente arreglar el proceso antes de automatizarlo.

La mayoría de las consultas que recibimos sobre IA empiezan al revés: "queremos un chatbot". Un chatbot es una interfaz, no un problema. La diferencia entre un proyecto que se paga solo en seis meses y uno que termina apagado a los tres está casi siempre en la elección del problema, no en la del modelo.

¿Cómo saber si un problema es para IA?Enlace a esta sección#

Cuatro preguntas. Si alguna da que no, conviene parar antes de escribir una línea de código.

¿Es repetitivo? La IA no resuelve un caso: resuelve una forma de caso, muchas veces. Si cada instancia es distinta y exige criterio nuevo, lo que tienes no es una tarea automatizable, es un trabajo.

¿Hay volumen? Este es el filtro que más proyectos debería frenar y casi nunca se aplica. Si el proceso ocurre veinte veces por mes, el mejor sistema disponible es una persona dedicándole veinte minutos. Recién con cientos o miles de repeticiones mensuales el ahorro justifica la construcción, la evaluación y el mantenimiento.

¿Tolera un error revisable? La pregunta no es si tolera errores —todo sistema los tiene—, sino si el error se puede detectar antes de que haga daño. Una clasificación equivocada se corrige moviendo un ticket de fila. Un cálculo equivocado que nadie verifica se descubre cuando llega el reclamo.

¿Los datos ya existen y están accesibles? Si la información que el modelo necesita está en la cabeza de tres personas o en un sistema que no expone una API, el proyecto no es de IA todavía: es de datos.

Los cuatro patrones que sí paganEnlace a esta sección#

Casi todo lo que vemos funcionar en producción cae en uno de estos cuatro. No es una lista de lo que la tecnología puede hacer, sino de lo que cierra en números.

Extraer datos estructurados de documentosEnlace a esta sección#

Facturas de proveedores, remitos, órdenes de compra, pólizas, contratos: cualquier cosa que llega en PDF y que alguien copia a mano a un sistema.

Una distribuidora recibe facturas de sesenta proveedores en quince formatos distintos, y nadie va a lograr que los sesenta emitan igual. El modelo lee el documento y devuelve un JSON con los campos que importan —emisor, número, fecha, ítems, totales— y ese JSON se valida contra un esquema antes de tocar el ERP.

Lo que hace que esto funcione no es el modelo: es la validación. Sumar los ítems y compararlos con el total declarado atrapa la mayoría de los errores de lectura sin que intervenga una persona; lo que no cierra va a una cola de revisión. Ese chequeo determinista sobre la salida del modelo es la diferencia entre una demo y algo que se puede dejar corriendo.

Clasificar y derivarEnlace a esta sección#

Tickets de soporte, correos a una casilla general, reclamos, postulaciones. Un info@ que recibe trescientos mails por día mezclando ventas, soporte, facturación y spam es un caso de manual: hay volumen, es repetitivo y el error es barato, porque cambiar un mail de categoría cuesta un clic.

Una advertencia sobre la medición: la referencia no es el azar, es lo que ya tienes. Si tus reglas por palabras clave aciertan el 80% de las veces, el modelo tiene que superar ese 80% de forma consistente para justificar el cambio. Muchas veces lo hace; a veces la respuesta honesta es que las reglas alcanzan.

Búsqueda semántica sobre conocimiento internoEnlace a esta sección#

Manuales, procedimientos, documentación de producto, historial de tickets. El caso típico: alguien de soporte que sabe que la respuesta existe pero no dónde, y termina preguntándole al que tiene más antigüedad.

Lo que conviene construir acá no es un asistente que "sabe todo", sino un buscador que devuelve el párrafo relevante con el enlace a la fuente. Esa diferencia parece cosmética y no lo es: cuando el sistema cita, la persona verifica en dos segundos y el error se vuelve barato. Cuando afirma sin citar, nadie verifica nada.

Redactar borradores que después edita una personaEnlace a esta sección#

Primeras versiones de respuestas a clientes, descripciones de producto, resúmenes de reuniones. El ahorro real no está en escribir: está en no arrancar de una hoja en blanco. Un borrador decente que alguien corrige en tres minutos reemplaza quince minutos de redacción desde cero.

La condición es literal: alguien lo edita. Si el texto sale con tu firma y nadie lo lee antes, esto ya dejó de ser este patrón.

Dónde la IA no pagaEnlace a esta sección#

Esta es la parte que casi nadie escribe, y es la que más dinero ahorra.

Decisiones que necesitan un responsable. Aprobar un crédito, rechazar una cobertura, desvincular a alguien, definir un diagnóstico. El problema no es técnico, es de responsabilidad: cuando algo sale mal, alguien tiene que explicar por qué se decidió así, y "lo dijo el modelo" no sirve ante un cliente, un auditor o un juez. El modelo puede ordenar la información y sugerir; la decisión sigue teniendo nombre y apellido.

Volumen insuficiente para amortizar la construcción. Un flujo de extracción hecho en serio —con manejo de excepciones, evaluación y monitoreo— rara vez baja de varias semanas de trabajo. Si la tarea le ocupa dos horas por semana a una persona, el número no cierra, y no cierra por bastante: multiplica las horas anuales por el costo de la hora y compáralo con el presupuesto. Si el resultado no es obvio, es que no.

Errores caros que no se pueden verificar. El riesgo no es que el modelo se equivoque; es que se equivoque y no te enteres. Liquidaciones, cálculos regulatorios, cualquier salida que nadie puede contrastar sin rehacer el trabajo. Si verificar cuesta lo mismo que producir, no ahorraste nada: sumaste un componente más que puede fallar.

Procesos rotos. Si hoy nadie sabe con certeza quién aprueba qué, automatizar no lo arregla: lo hace más rápido y más difícil de auditar. Un proceso confuso automatizado es un proceso confuso con una capa de software encima y un responsable menos.

"Human in the loop" es una decisión de diseño, no una aclaraciónEnlace a esta sección#

Es la frase más repetida del rubro y la menos especificada. Poner a una persona a revisar no es una salvedad para el contrato: es una parte del sistema, y se diseña como tal.

• Qué se revisa y qué no. Lo habitual es un umbral: por encima de cierta confianza se aprueba solo, por debajo va a una cola. Ese umbral se calibra con datos reales, no se elige por intuición.
• Con qué interfaz. Si revisar implica abrir tres pantallas y comparar a ojo, no va a ocurrir. La pantalla de revisión suele ser la parte más importante del producto.
• Qué pasa con lo rechazado. Si la corrección no vuelve al sistema —como caso de prueba, como ejemplo, como ajuste—, el sistema no mejora nunca.

Si la revisión termina siendo alguien que mira una grilla y aprieta "aceptar todo", ya no hay revisión: hay una firma. Y una firma no baja el riesgo, lo traslada.

Los costos que casi nadie presupuestaEnlace a esta sección#

El desarrollo es la parte visible. Estas cuatro aparecen después.

El costo por token a volumen. Una prueba con cincuenta documentos cuesta centavos y no dice nada sobre la economía del sistema. Ocho mil documentos por mes es una línea fija del presupuesto operativo, y esa multiplicación se hace antes de construir.

La evaluación. Un conjunto de casos con la respuesta correcta escrita a mano —del orden de cien a trescientos— es lo que permite responder "¿este cambio mejoró algo?". Sin eso, cada ajuste al prompt es una opinión validada contra tres ejemplos que alguien tenía a mano. Es la parte que más se saltea y la que más cara sale.

El monitoreo y la deriva. Lo que entra cambia: un proveedor nuevo con otro formato, una campaña que trae consultas distintas. La calidad no se cae de golpe, se degrada en silencio. Si nadie mira una métrica, el primero en enterarse es un cliente.

El mantenimiento cuando cambia el modelo. Los proveedores dan de baja versiones y publican otras. Un prompt afinado contra un modelo no se comporta igual contra el siguiente, y la migración deja de ser opcional cuando la versión que usas ya no está. Presupuesta la operación del primer año como una línea propia, no como un redondeo del desarrollo.

Privacidad: qué sale de tu infraestructura y qué noEnlace a esta sección#

Es la primera pregunta que hace un cliente serio, y "está todo en la nube, es seguro" no es una respuesta. Las que importan son cuatro:

1. Qué datos salen. Muchas veces no hace falta enviar el documento entero: alcanza con la parte que el modelo necesita, sin nombres, sin números de cuenta, sin identificadores. Anonimizar antes de enviar es la medida más barata y la que menos se aplica.
2. A dónde van y bajo qué contrato. Qué proveedor los procesa, en qué región, cuánto tiempo los retiene y si se usan para entrenar. Eso se verifica en los términos que firmas, no en el blog del proveedor.
3. Qué queda registrado. Los logs son datos: si guardas cada consulta y cada respuesta para depurar, ese registro es tan sensible como el original y suele quedar fuera de la política de retención.
4. Qué pasa si no puede salir nada. Hay datos que por regulación o por contrato no pueden dejar tu infraestructura. Se puede correr un modelo abierto en tu propio servidor, pero digámoslo con honestidad: obtienes menos capacidad por peso invertido y más trabajo de infraestructura encima. A veces es la única opción válida, y entonces se planifica con ese costo a la vista.

Por dónde empezaríamosEnlace a esta sección#

Elige una tarea que pase el test de las cuatro preguntas. Mide cuánto cuesta hoy en horas por mes: el número real, no el que recuerdas. Construye lo más chico que la resuelva de punta a punta para un subconjunto acotado, con su validación y su pantalla de revisión. Vuelve a medir: si el ahorro está, escalas con evidencia; si no está, cortaste temprano y barato.

Así encaramos los proyectos de IA aplicada: presupuesto cerrado por fase y entregas frecuentes, para que la decisión de seguir o parar se tome con algo funcionando adelante y no con una promesa.

Si tienes una tarea en mente y no sabes de qué lado del test cae, escríbenos y la miramos. Si la respuesta es que no conviene, te lo vamos a decir.