Probamos estas herramientas en proyectos reales con clientes. No en demos. No en pruebas piloto de laboratorio.
Hay una pregunta que nos hace casi todo cliente antes de arrancar un proyecto: “¿Qué herramienta de IA me conviene usar?”
Es una pregunta razonable pero está mal formulada. La herramienta correcta depende del proceso que querés mejorar, del equipo que lo va a operar, de si los datos están en la nube o tienen que quedarse en tu servidor, y de si el presupuesto permite pagar por API o necesitás algo que corra localmente sin costos variables. Elegir la herramienta antes de responder esas preguntas es comprar sin diagnóstico.
Dicho eso: después de implementar IA en procesos de distribución, gestión comercial y auditoría con clientes en Argentina, hay herramientas que siguieron apareciendo en los proyectos porque funcionan, y hay otras que descartamos después de probarlas. Este artículo documenta eso. No es una lista de las “mejores herramientas de IA del mercado”. Es lo que usamos nosotros, con qué criterio, y qué aprendimos en el proceso.
El criterio que usamos para evaluar una herramienta
Antes de entrar a la lista, vale la pena ser explícito sobre el filtro que aplicamos. No evaluamos herramientas por sus features, por su interfaz, ni por cuántas veces las mencionaron en Product Hunt. Las evaluamos por tres preguntas concretas.
¿Funciona en producción con datos reales? Muchas herramientas se ven bien en demo y se rompen cuando aparece un caso borde. Un documento mal escaneado, una consulta en lunfardo, un formato de fecha argentino, un PDF con tablas complejas. Los datos de producción tienen ruido que los datos de demo no tienen.
¿El cliente puede operarla sin depender de nosotros? Si una herramienta requiere que un desarrollador intervenga cada vez que cambia algo menor, no es una solución: es una deuda de mantenimiento perpetua. Buscamos herramientas que el equipo del cliente pueda ajustar con capacitación mínima.
¿El costo tiene sentido para el volumen de una PyME argentina? Pagar en dólares por API calls que se escalan a cientos de miles de solicitudes mensuales puede ser viable para una empresa en EEUU. Para una PyME argentina con operaciones acotadas, ese modelo de costo puede ser prohibitivo o impredecible. El contexto económico local importa y mucho.
Las que quedaron
n8n: Automatización de flujos
Qué hace: Conecta sistemas distintos y automatiza flujos de trabajo sin código, o con código cuando hace falta.
Por qué la usamos: Es la herramienta de automatización con la que construimos más flujos para clientes. Conecta el CRM con WhatsApp, el formulario web con el sistema de gestión, la bandeja de correos con el pipeline de ventas. Tiene nodos nativos para modelos de lenguaje (OpenAI, Anthropic, modelos locales vía Ollama), lo que permite incorporar IA en el medio de un flujo sin salir del entorno.
Lo que nos gusta en particular: Se puede hostear en un servidor propio, que es lo que hacemos siempre. Eso significa que el cliente no depende de que n8n.cloud exista mañana, y los datos de sus automatizaciones no salen del entorno controlado. Para clientes en sectores donde la confidencialidad importa (salud, finanzas, industria), eso no es opcional.
Cuándo no la usamos: Cuando el flujo que hay que automatizar tiene lógica de negocio muy compleja que cambia seguido. Ahí construimos la lógica en el backend del sistema y usamos n8n solo para la integración de superficie.
Ollama: modelos de lenguaje locales
Qué hace: Corre modelos de lenguaje grandes directamente en el servidor del cliente, sin enviar datos a ninguna API externa.
Por qué la usamos: En proyectos donde los datos son sensibles, no hay alternativa viable. La legislación argentina de protección de datos (Ley 25.326 y Ley 26.529 para el sector salud) establece restricciones claras sobre qué información puede enviarse a servidores externos, especialmente datos de pacientes o información comercial confidencial. Con Ollama, el modelo vive en el servidor del cliente y los datos no salen de ahí.
Qué modelos corren bien: Qwen, en sus variantes de 7B y 14B parámetros, es el que mejor rendimiento nos dio en tareas de extracción de información de documentos en español. Para hardware ARM64 (que es más accesible en costo), los modelos cuantizados funcionan bien para la mayoría de las tareas de procesamiento de texto que aparecen en PyMEs.
La limitación real: Ollama en hardware modesto tiene velocidad de inferencia más lenta que una API en la nube. Para tareas en tiempo real (responder una consulta de WhatsApp en menos de dos segundos) eso puede ser un problema. Para tareas de procesamiento por lotes (leer cien facturas de la noche o clasificar los correos del día) la velocidad no importa tanto.
Surya: OCR para documentos en español
Qué hace: Modelo de OCR (reconocimiento óptico de caracteres) optimizado para documentos con múltiples idiomas, incluyendo español, y con buena performance en documentos con tablas y layouts complejos.
Por qué lo usamos: La mayoría de los OCR genéricos tienen rendimiento aceptable en documentos simples y se deterioran rápido cuando el documento tiene tablas, columnas múltiples, sellos, marcas de agua o calidad de escaneo mediocre. Eso describe el 80% de la documentación real que manejan las empresas argentinas: facturas de proveedores, remitos, historias clínicas, liquidaciones.
Cómo lo combinamos: Surya extrae el texto, OpenCV preprocesa la imagen antes de pasársela (corrección de perspectiva, limpieza de ruido, ajuste de contraste), y un modelo de lenguaje local vía Ollama interpreta los campos extraídos y los estructura en el formato que necesita el sistema de gestión. Ese pipeline es el que implementamos en un cliente para procesar auditorías localmente, sin que un solo documento salga del servidor.
Lo que no hace bien: Documentos manuscritos en cursiva con calidad de escaneo muy baja. Ahí el rendimiento cae de forma significativa y hay que establecer un flujo de revisión manual para los casos que el modelo no puede procesar con confianza suficiente.
Fireworks AI y Groq Cloud: inferencia en la nube sin el precio de OpenAI
Qué hacen: Plataformas de inferencia que sirven modelos open source (Llama, Qwen, Mistral, entre otros) vía API, con latencia muy baja y costo por token significativamente menor que las APIs de los grandes laboratorios.
Por qué las usamos: Cuando el caso de uso necesita velocidad de respuesta cercana al tiempo real y los datos no son sensibles, la alternativa no es necesariamente OpenAI o Anthropic. Groq en particular tiene una velocidad de inferencia notablemente superior gracias a su hardware LPU, lo que lo hace útil para flujos donde la respuesta tiene que llegar en menos de un segundo, por ejemplo, el chatbot de WhatsApp de un distribuidor que necesita responder consultas de stock antes de que el cliente cuelgue.
Fireworks AI tiene un catálogo de modelos más amplio y mayor flexibilidad para elegir el modelo según el trade-off entre costo, velocidad y calidad para cada tarea específica. No estás casado con un modelo, lo que permite optimizar el costo por caso de uso.
La ventaja real frente a OpenAI para PyMEs argentinas: El costo por token es considerablemente más bajo, y los modelos open source que corren en estas plataformas son suficientemente buenos para la mayoría de las tareas de procesamiento de texto que aparecen en contextos PyME. No todo requiere el modelo más caro del mercado.
La limitación: Al igual que cualquier API en la nube, los datos salen del servidor. Para casos donde eso no es viable, el camino es Ollama local. Para el resto, Groq o Fireworks dan una relación precio-rendimiento mejor que las alternativas más conocidas.
EfficientNet: visión por computadora en producción
Qué hace: Arquitectura de red neuronal convolucional para clasificación y reconocimiento de imágenes, optimizada para correr eficientemente en hardware con recursos limitados sin sacrificar precisión.
Por qué la usamos: En el sistema de gestión que construimos para un distribuidor de autopartes, hay un problema concreto: identificar piezas a partir de fotografías tomadas en el depósito, con iluminación variable y sin fondo controlado. Entrenar un modelo de clasificación sobre el catálogo de productos del cliente con EfficientNet dio resultados usables en producción con un dataset de tamaño razonable, no hacen falta millones de imágenes para que funcione bien en un dominio acotado.
Por qué EfficientNet y no otra arquitectura: La familia EfficientNet escala bien en el trade-off entre precisión y costo computacional. Para correr inferencia en un servidor que también está haciendo otras cosas, no en hardware dedicado exclusivamente a ML, eso importa. También tiene buenos resultados con transfer learning desde pesos preentrenados en ImageNet, lo que reduce la cantidad de imágenes propias que necesitás para ajustar el modelo a tu dominio específico.
Lo que aprendimos: La calidad del dataset de entrenamiento importa más que la elección de arquitectura. Imágenes mal etiquetadas, con variación de ángulo no representada o tomadas en condiciones muy distintas a las de producción deterioran el rendimiento más que cualquier decisión técnica sobre el modelo. Construir el proceso de recolección y etiquetado de imágenes correctamente desde el principio ahorra meses de reentrenamiento después.
Meilisearch con embeddings: búsqueda híbrida sobre catálogos
Qué hace: Motor de búsqueda open source que combina búsqueda textual clásica (por términos exactos y aproximados) con búsqueda semántica por embeddings vectoriales, permitiendo encontrar resultados relevantes aunque la consulta no use las palabras exactas del catálogo.
Por qué lo usamos: Los catálogos de productos de distribuidores tienen un problema de vocabulario: el cliente llama a una pieza de una forma, el catálogo la tiene indexada de otra, y la búsqueda textual exacta no encuentra nada. “Burrito de dirección", “cruceta", “junta homocinética”, distintos nombres para cosas relacionadas o idénticas según el origen de la nomenclatura. La búsqueda semántica por embeddings encuentra resultados relevantes aunque los términos no coincidan, porque trabaja sobre el significado de la consulta, no sobre los caracteres.
Cómo lo implementamos: Meilisearch se hostea en el servidor del cliente junto con el resto del sistema. Los embeddings se generan con un modelo liviano que también corre localmente, sin depender de una API externa para cada búsqueda. El resultado es una búsqueda que combina la velocidad y precisión de Meilisearch para coincidencias exactas con la tolerancia semántica de los embeddings para consultas ambiguas o con vocabulario diferente al del catálogo.
Por qué no Elasticsearch o Algolia: Elasticsearch tiene una complejidad operativa alta para un equipo pequeño que necesita mantenerlo. Algolia es excelente pero el modelo de costo por búsqueda no cierra para volúmenes medianos pagando en dólares. Meilisearch self-hosted da el 90% de la funcionalidad que necesitamos con costo operativo cercano a cero una vez instalado.
Las que no usamos
Zapier
Cara para lo que ofrece comparada con n8n self-hosted. Para una PyME argentina que quiere automatización sostenible, el modelo de costo de Zapier no cierra. La migración a n8n tiene una curva de aprendizaje inicial pero el ahorro en el largo plazo es significativo.
Chatbots genéricos “con IA” de plataformas de terceros
Los vimos en demostraciones. Todos prometen lo mismo: responden preguntas, atienden clientes, reducen la carga del equipo. El problema es que casi ninguno tiene integración real con el sistema de gestión del cliente. Un chatbot que no puede consultar el stock en tiempo real, ver el estado de un pedido o actualizar un registro no resuelve nada operativo. Es una capa cosmética sobre un proceso que sigue siendo manual.
Make (ex Integromat)
Lo probamos como alternativa a n8n. Tiene una interfaz más pulida, pero el modelo de costo por operación y la imposibilidad de self-hosting lo descartan para la mayoría de los clientes con los que trabajamos. Para casos donde self-hosting no es una opción y el volumen es bajo, puede tener sentido. No es nuestro caso habitual.
Herramientas de “BI con IA” que son dashboards con nombre cambiado
Hay un segmento completo del mercado que vende visualización de datos como inteligencia artificial. No lo es. Un dashboard más elaborado no predice ni aprende nada. No está mal tener buenas herramientas de visualización, pero no confundas eso con un sistema que genera inteligencia accionable sobre tus datos.
Lo que aprendimos del proceso
La decisión de qué herramienta usar nunca debería preceder al diagnóstico del proceso. Eso suena obvio pero no lo es: la mayoría de las consultas que recibimos empiezan con “quiero implementar ChatGPT" o “quiero un chatbot", no con “tengo este proceso que consume tantas horas y quiero ver si tiene solución tecnológica”.
La herramienta es el último paso, no el primero. El primer paso es entender qué proceso tiene el problema, cuánto cuesta ese problema hoy en tiempo y errores, si hay datos disponibles para entrenar o alimentar una solución, y si el resultado va a poder medirse. Sin eso, cualquier herramienta parece una solución y ninguna lo es del todo.
También aprendimos que el factor más determinante del éxito de una implementación no es la herramienta elegida. Es la calidad del diagnóstico previo y la claridad de los requisitos de integración. Un sistema bien integrado con una herramienta modesta supera siempre a un sistema mal integrado con la mejor herramienta del mercado.
Si estás evaluando incorporar alguna de estas herramientas a tu operación, el punto de partida no es elegir cuál. Es mapear el proceso que querés mejorar con suficiente detalle como para saber qué tiene que hacer la herramienta en concreto. Eso es exactamente lo que trabajamos en el Sprint de Arquitectura antes de proponer cualquier solución técnica.
¿Tenés un proceso en mente y querés saber si tiene solución con alguna de estas herramientas? Contanos el caso.