DEV Community: Gonzalo Terrones

Medir si un LLM nombra a tu empresa: por qué una captura no sirve como métrica

Gonzalo Terrones — Tue, 04 Aug 2026 23:40:44 +0000

Cada vez más gente arranca la búsqueda de un proveedor preguntándole a un modelo en vez de a un buscador. Y no pide diez opciones para comparar: pide una recomendación y recibe dos o tres nombres. Si tu empresa no está ahí, no quedaste octava. No estás en la respuesta.

La pregunta que sigue es obvia: cuánto tarda en cambiar eso. Pero antes hay un problema más aburrido y más importante, que es cómo se mide. Lo escribo porque es la parte que casi nunca se cuenta y es donde se rompen los informes.

Una captura de pantalla no es una medición

Es el error más común y el más difícil de discutir, porque la captura parece prueba.

La respuesta de una app conversacional depende del historial de la cuenta, de la sesión, del ruteo interno del proveedor, de si esa consulta activó búsqueda web o no, y de la región desde donde se pregunta. Dos personas preguntando lo mismo el mismo día reciben respuestas distintas. La misma persona preguntando dos veces también.

O sea: la salida no es determinista y el instrumento no es estable. Una captura te dice qué pasó una vez, en un contexto que no podés reconstruir. Como métrica de seguimiento no sirve para nada.

Lo que sí sirve es una serie: la misma consulta, literal, contra el mismo motor, con el mismo criterio de clasificación, repetida en el tiempo. El valor absoluto de un punto importa poco. Lo que importa es la diferencia entre puntos.

Fijar el texto de la consulta, no la etiqueta

Este es un bug de proceso que da resultados verosímiles y falsos.

Si guardás en la planilla una etiqueta como "consulta de chatbot" en vez del texto exacto que preguntaste, dentro de dos meses nadie se acuerda del wording. Y el wording cambia el resultado: preguntar "quién hace X en Argentina" y "mejores empresas de X en Argentina" devuelven listas distintas.

Cuando el texto se corre entre rondas, la serie deja de ser comparable, pero el gráfico sigue dibujándose igual de lindo. Guardá el string literal, versionado. Si tenés que cambiar una consulta, empezá una serie nueva en vez de contaminar la vieja.

Dos instrumentos que parecen uno

Preguntarle a un modelo con búsqueda web activada y preguntarle sin ella son dos mediciones distintas, y se contradicen entre sí. La misma consulta puede dar mención con uno y ausencia con el otro.

No es un error del modelo: son dos cosas diferentes. Uno te dice qué encuentra ahora; el otro, qué quedó incorporado. Mezclarlos en una misma serie produce oscilaciones que después se explican como "volatilidad del algoritmo" cuando en realidad es el instrumento cambiando de mano.

Cada punto de la serie tiene que registrar con qué se midió.

Tres estados, no un porcentaje

El otro lugar donde se maquillan los números es la clasificación. Conviene tener estados discretos:

Ausente — no aparece.
Mencionada — el modelo la nombra en el cuerpo de la respuesta, pero no cita el sitio. Sabe que existe; no está leyendo la fuente. Es un estado frágil: puede consolidarse o desaparecer en la ronda siguiente.
Citada — el dominio aparece en el bloque de fuentes. Sostiene lo que el modelo dice y además manda tráfico.

Colapsar los tres en un único "índice de visibilidad" produce una mejora que en la práctica no siempre existe: pasar de ausente a mencionada infla el número sin que nada estructural haya cambiado.

Un detalle de implementación si automatizás la clasificación: buscar el nombre de la marca por substring da falsos positivos cuando la marca es corta o queda pegada a otra palabra, y falsos negativos con acentos y normalización Unicode. Vale la pena armar un set de casos borde antes de confiar en el clasificador.

Y ahora sí, cuánto tarda

Con esas condiciones, lo que se ve repetido:

Las consultas de marca —"qué es tal empresa"— se mueven primero. Las de categoría —"mejores empresas de tal cosa en tal país"— bastante después. Y las de intención de compra —"a quién le contrato tal cosa"— son las últimas, y son justo las que traen clientes.

Tiene sentido si pensás qué necesita el modelo en cada caso. Para contestar qué hace tu empresa alcanza con haber encontrado información confiable sobre vos. Para ponerte en una lista de tres tiene que compararte con todo tu rubro y decidir que merecés el lugar.

El primer movimiento suele aparecer cerca de la cuarta semana. Antes de eso el trabajo está hecho pero todavía no se ve, que no es lo mismo que no estar funcionando. Ahí es donde la mayoría cambia de estrategia, justo cuando la anterior estaba por dar resultado.

Lo que se aprende midiendo

Que el sitio propio puede no ser la fuente. Es perfectamente posible que el modelo describa a tu empresa con tu texto y cite un directorio de terceros en vez de tu dominio. La descripción viajó; la atribución no.

Y que el reconocimiento no implica pertenencia. Un modelo puede describirte bien cuando lo nombrás, y no incluirte cuando le preguntás por la categoría. Son dos preguntas distintas y hay que correr las dos.

Nada de esto se resuelve con un truco. Se resuelve midiendo en condiciones repetibles el tiempo suficiente como para saber qué mover.

Escribo sobre automatización con IA aplicada a empresas. La versión original de esta nota está en varka.tech.

Por qué fracasan los proyectos de IA en las empresas (spoiler: no es la tecnología)

Gonzalo Terrones — Mon, 27 Jul 2026 20:15:59 +0000

Los proyectos de inteligencia artificial casi nunca fracasan por la tecnología. Fracasan en el último paso: el de incorporarla al trabajo de la gente.

Lo escribo después de una conversación con Mayra Regueira, Consultora Estratégica en Innovación & Negocios, que trabaja el lado humano de las organizaciones. Yo vengo del lado técnico — armo automatizaciones y agentes de IA — y ella me puso nombre a algo que veo seguido pero no había ordenado: el punto de quiebre no está en el modelo, ni en la integración, ni en el presupuesto. Está en el día después de la entrega.

El proyecto funciona y aun así no arranca

La secuencia es siempre parecida. Se define el proceso, se arma la automatización, se conecta con los sistemas que la empresa ya tiene, se prueba. La demo sale bien. Todos aplauden.

Y ahí empieza el problema de verdad, porque la herramienta entra en un equipo que tiene rutinas, jerarquías y una idea bastante clara de para qué está cada uno. La IA le toca eso a todos al mismo tiempo, y nadie preparó la conversación.

Una tecnología que funciona pero que nadie usa no es un problema técnico. Es un problema de trabajo no hecho.

Las tres preguntas que nadie prepara

Cuando el sistema queda andando, aparecen tres preguntas que rara vez están contestadas de antemano:

1. ¿Qué hace ahora la persona que antes hacía esa tarea?
Si alguien dedicaba dos horas diarias a cargar datos y esas dos horas ya no existen, esa persona necesita saber en qué las va a usar. Si no se lo dicen, la respuesta que se arma sola en su cabeza es "me están por echar". Y una persona que piensa eso no colabora con la implementación: la sabotea, aunque sea sin querer.

2. ¿Cómo cambia el trabajo del equipo cuando una parte la resuelve la IA?
No es solo la tarea que desaparece. Cambian los tiempos, cambia quién revisa qué, cambia de quién es la responsabilidad cuando algo sale mal. Un equipo que no tiene eso definido vuelve al método viejo a la primera duda, porque el método viejo tiene reglas conocidas.

3. ¿Quién se lo explica a la gente?
Esta es la que más me quedó de la charla con Mayra. Y la respuesta incómoda es que no le toca al proveedor de tecnología.

El rol del líder es la parte que no se puede tercerizar

Yo puedo dejar un flujo andando perfecto. Puedo documentarlo, capacitar, dejar el soporte abierto. Lo que no puedo hacer desde afuera es decirle a un equipo para qué está cada uno ahora.

Eso le toca al líder del grupo. Es quien tiene que reposicionar a su gente y redefinir las actividades de cada uno en la nueva dinámica entre personas e IA: qué queda del lado humano, qué pasa a la máquina, y sobre todo qué cosas nuevas ahora se pueden hacer con el tiempo que se liberó.

Es un trabajo de conducción, no de sistemas. Y es el que más se saltea, porque no aparece en ningún presupuesto ni en ningún cronograma de implementación.

Cuando ese trabajo no se hace pasa siempre lo mismo: la herramienta queda instalada, se usa dos semanas, y al mes el equipo volvió a la planilla de antes. El proyecto figura como entregado y nadie lo está usando.

Qué se puede hacer, en concreto

Nada de esto es abstracto. Son cuatro cosas bastante prácticas:

→ Contestar la pregunta del puesto antes de arrancar, no después. Antes de la primera línea de código, que cada persona afectada sepa qué va a estar haciendo cuando el sistema esté andando. Si la respuesta honesta es "todavía no lo sabemos", eso también hay que decirlo, pero decirlo.

→ Que el líder del equipo esté en el proyecto desde el principio. No como aprobador del presupuesto: como parte del diseño. Es quien conoce las rutinas reales, que casi nunca son las del manual.

→ Empezar por un proceso que le moleste al equipo, no al gerente. La adopción es mucho más fácil cuando lo primero que automatizás es la tarea que todos odian. Se gana confianza antes de tocar algo sensible.

→ Medir uso, no entrega. El indicador no es "el sistema está en producción". Es cuánta gente lo usó esta semana. Si ese número baja, hay una conversación pendiente con el equipo, no un bug.

Y una que digo siempre desde el lado técnico: no automatices un proceso que está roto. Primero ordenalo. Si no, automatizás el caos y lo hacés más rápido.

La parte que la industria vende poco

El mercado de la IA vende capacidades: modelos, agentes, integraciones. Es lo que se muestra fácil en una demo. La parte que casi nadie factura — y que decide si el proyecto sirvió para algo — es el acompañamiento del equipo que va a convivir con eso.

Por eso me pareció que valía la pena escribirlo. Yo puedo garantizar que la tecnología funcione. Que la empresa la use es una responsabilidad compartida, y la mitad de esa responsabilidad no es técnica.

Si estás por meter IA en tu empresa, hacete la pregunta antes de firmar nada: ¿ya sabés qué va a estar haciendo tu gente el día después de que esto funcione?

La conversación que originó este artículo fue con Mayra Regueira, Consultora Estratégica en Innovación & Negocios, que trabaja justamente el lado humano de estos procesos. Yo escribo sobre automatización con IA para empresas desde Varka, una consultora de IA enfocada en la trastienda operativa de los negocios. Si estás evaluando automatizar algo y querés una opinión sin humo, escribime.

Automatizar una distribuidora con IA en Argentina: los procesos reales y el stack que uso

Gonzalo Terrones — Mon, 20 Jul 2026 21:35:20 +0000

Trabajé más de 20 años en una distribuidora antes de dedicarme a la inteligencia artificial. Cuando alguien me pregunta "¿la IA sirve para una distribuidora?", la respuesta corta es: es de los rubros donde más se nota, porque el cuello de botella casi nunca es vender — es la montaña de tarea administrativa detrás de cada venta.

Esta es una guía concreta de qué se puede automatizar hoy, en 2026, en una pyme argentina real, y con qué stack lo armo.

El stack, en una línea

Nada exótico ni caro:

n8n (self-hosted) como orquestador de los flujos.
Un LLM (Claude / GPT) para las partes que requieren interpretar texto o archivos con formato variable.
Conexión por API a lo que el negocio ya usa: WhatsApp, el sistema de gestión, ARCA/AFIP, Google Sheets/DB.

El costo de la IA por operación suele ser de centavos. Lo que se paga es el armado y el mantenimiento, no un ERP de seis cifras.

1. Actualización de listas de precios (el clásico que a todos les duele)

El proveedor manda la lista nueva en un PDF o Excel con formato distinto cada vez, y alguien carga cientos de artículos a mano. Horas, con errores, y cuando terminás ya llegó otra lista.

El flujo:

Archivo del proveedor (PDF/Excel)
        |
        v
  Parser + LLM  ->  normaliza {codigo, descripcion, precio}
        |             (aunque cambie el formato de origen)
        v
  Validacion (codigo existe? variacion de precio razonable?)
        |
        v
  Update al sistema de gestion via API

La clave es usar el LLM solo para la parte difícil (interpretar un layout que cambia), no para hacer la matemática. Media jornada pasa a minutos. Es probablemente el proceso con mejor retorno, y casi nadie lo ofrece porque no es tan "vistoso" como un chatbot.

2. Pedidos por WhatsApp que se cargan solos

Tus clientes ya piden por WhatsApp; el problema es que una persona transcribe cada pedido al sistema. Un agente de IA lee el mensaje ("mandame 10 cajas de X y 5 de Y"), lo estructura, valida contra stock y lo deja listo para confirmar. El vendedor deja de ser transcriptor y vuelve a vender.

Técnicamente es una tool call: el mensaje libre entra, el modelo devuelve un objeto de pedido tipado (items[], cantidades, cliente), y ese objeto se valida antes de tocar el sistema.

3. Remitos y facturación automáticos

Al confirmar un pedido, el comprobante se genera solo: valida datos del cliente, emite la factura electrónica contra ARCA/AFIP, la manda por mail y WhatsApp, y actualiza el sistema contable. Sin copiar datos de una pantalla a otra.

4. Conciliación de stock

La eterna diferencia entre "lo que dice el sistema" y "lo que hay en el depósito". Un flujo que cruza entradas, salidas y ajustes, y avisa cuando algo no cuadra — antes de quedarte sin mercadería o comprar de más.

Dos consejos de ingeniería antes de automatizar nada

No automatices un proceso que está roto. Si tu carga de precios es un caos, primero ordenala. Automatizar el caos solo lo hace más rápido. La IA multiplica lo que ya tenés, para bien o para mal.
Validá siempre la salida del LLM antes de escribir en un sistema real. El modelo interpreta; tu código decide. Un precio con una variación del 400% o un código inexistente no deberían llegar nunca a producción sin un check determinístico en el medio.

Por dónde empezar

No intentes automatizar todo de una. Elegí el proceso que más horas te come por semana —en una distribuidora casi siempre es la carga de precios o la de pedidos— y arrancá por ahí. Medí cuántas horas te devuelve. Con ese primer resultado, el resto se justifica solo.

Escribo sobre automatización con IA para pymes argentinas desde Varka, una consultora enfocada en la trastienda operativa de los negocios (precios, stock, remitos, atención). Si tenés una distribuidora y querés ver qué se puede automatizar en tu caso, escribime — el diagnóstico inicial no cuesta nada.