Casos de éxito
Más de 20 empresas ya confían en nuestro software.
Cada uno de estos proyectos resuelve un problema distinto, pero todos comparten la misma idea: la inteligencia no vive en la pantalla, vive en un motor propio que decide, se puede auditar y se puede reemplazar sin romper el producto.
- Proyectos
- Más de 20 proyectos en producción
- Rubros
- Finanzas, comercio, sector público, salud, agro
- Modalidad
- Desarrollo propio, de la arquitectura a la operación
- Núcleo común
- IA aplicada sobre datos de la operación
Qué construimos
Proyectos finalizados
Filtrá por familia para ver los proyectos de un frente en particular. Tocá cualquier proyecto para ver su ficha completa: qué resuelve el producto y cuál es la parte técnicamente difícil, que suele ser la que decide si un proyecto así sale bien o se muere a mitad de camino.
No hay proyectos en esa familia.
¿Tu problema se parece a alguno?
Construimos productos, no demostraciones.
Ninguno de estos proyectos arrancó de una idea de software: arrancó de una decisión que alguien tomaba a mano todos los días y que se podía tomar mejor con datos. Si en tu operación hay una de esas, contanos de qué se trata.
IA empresarial
Kognia
Un sistema operativo de agentes para adentro de la empresa: capacidades registradas en un solo lugar, un enrutador que decide quién resuelve cada pedido y permisos heredados del directorio corporativo.
- Tipo
- Plataforma interna multiárea
- Dominio
- Operación y conocimiento corporativo
- Despliegue
- Nube privada u on-premise
- Núcleo técnico
- Registro de capacidades y orquestador jerárquico
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
En la mayoría de las empresas la IA entra por veinte puertas distintas. Un área contrata un asistente, otra arma su propio bot, una tercera pega llamadas a un modelo adentro de una planilla. A los seis meses hay diez herramientas que no se hablan, ninguna sabe quién es el que pregunta, y nadie puede decir qué datos vio cada una.
El problema de fondo no es el modelo: es el gobierno. Quién puede preguntar qué, con qué datos se responde, qué acciones puede ejecutar un agente sin que las apruebe una persona, y cómo se reconstruye después lo que pasó. Kognia existe para que eso esté resuelto una vez, en un lugar, en vez de veinte veces mal.
Cómo funciona
Registro de capacidades
Cada área publica lo que su sistema sabe hacer: consultar saldos, emitir un remito, abrir un ticket, buscar en el repositorio legal. Cada capacidad declara qué datos toca, qué permisos exige y si su efecto se puede deshacer.
Enrutador de pedidos
Cuando alguien pregunta algo, el orquestador descompone el pedido, elige qué agentes intervienen y en qué orden, y les da un presupuesto de cómputo. Si el plan incluye una acción irreversible, se frena y pide aprobación humana.
Memoria con permisos
El índice de conocimiento guarda, junto a cada fragmento, quién puede leerlo. La búsqueda filtra por la identidad de quien pregunta antes de recuperar, no después: un dato que no te corresponde nunca entra en el contexto.
Decisión de arquitectura
La orquestación está separada de los agentes, y los agentes de las herramientas. Un agente no sabe cómo se conecta al ERP: pide una capacidad por su nombre y el registro resuelve la conexión, el permiso y el reintento. Eso permite cambiar de proveedor de modelo, o reemplazar la integración de un sistema entero, sin tocar la lógica de ningún agente. Cada ejecución queda guardada como un árbol de llamadas con sus entradas, sus salidas y su costo, así que una respuesta de hace tres meses se puede reconstruir tal como se produjo.
Stack
Orquestación
- Registro de capacidades propio
- Planificador jerárquico
- Presupuesto de cómputo por tarea
- Cola de aprobaciones humanas
Modelos
- Claude para razonar y planificar
- Embeddings para recuperación
- Enrutado por costo y complejidad
Datos
- PostgreSQL con pgvector
- Filtrado por identidad al recuperar
- Conectores a ERP, CRM y repositorios
Gobierno
- Identidad federada (SSO)
- Traza de auditoría por llamada
- Límites de uso por área
- Evaluación continua de respuestas
Sistemas de decisión
Arbitrium
Un motor que recibe el estado de un cliente y devuelve una sola acción recomendada, con su justificación y su impacto esperado.
- Tipo
- Motor de decisión embebible
- Dominio
- Contacto y tratamiento de clientes
- Despliegue
- API en nube o dentro de la red del cliente
- Núcleo técnico
- Políticas versionadas sobre bandits contextuales
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
Las empresas acumulan modelos que predicen: probabilidad de compra, de baja, de mora. Pero un número no es una decisión. Entre «este cliente tiene 62% de probabilidad de darse de baja» y «llamalo el martes ofreciéndole el plan B» hay un salto que casi siempre termina resolviendo una reunión mensual y una planilla de reglas que nadie se anima a tocar.
Ahí se pierde el valor. Las reglas envejecen, nadie mide si la acción sirvió, y cuando alguien propone cambiar el criterio no hay forma de saber qué va a pasar salvo probándolo con clientes reales. Arbitrium convierte ese salto en una pieza de software: una política explícita, versionada, medida y reversible.
Cómo funciona
Catálogo de acciones
Cada acción posible se declara con su costo, su capacidad disponible —cuántas llamadas entran en un día— y sus restricciones: a quién no se le puede ofrecer, cuántas veces por mes, qué requiere aprobación.
Política aprendida
Sobre el histórico, el motor aprende qué acción funciona mejor para cada tipo de caso, y sigue aprendiendo en producción reservando una fracción del tráfico para explorar alternativas. No optimiza la predicción: optimiza el resultado.
Explicación y control
Cada recomendación viene con las señales que más pesaron y el resultado esperado. Las reglas duras del negocio viven fuera del modelo, en un archivo que el área puede leer y cambiar sin pedirle nada a sistemas.
Decisión de arquitectura
La política es un artefacto versionado, como el código: se despliega, se mide y se revierte. Cada versión guarda con qué datos se entrenó y qué resultados obtuvo, y dos versiones pueden convivir repartiéndose el tráfico mientras se comparan. Cuando una anda peor, volver atrás es un cambio de puntero y no un redespliegue, porque la anterior sigue cargada.
Stack
Decisión
- Bandits contextuales
- Restricciones declarativas
- Catálogo de acciones versionado
Modelos
- Gradient boosting para estimar
- Calibración por segmento
- Reentrenamiento programado
Servicio
- API con respuesta bajo 100 ms
- Caché de rasgos
- Registro de cada decisión servida
Medición
- Experimentos A/B continuos
- Backtesting contra histórico
- Tablero de impacto por política
Simuladores
Réplica
Un gemelo digital de la operación donde se prueban escenarios antes de ejecutarlos, y cada corrida devuelve un rango de resultados en vez de un número único.
- Tipo
- Simulador de operación
- Dominio
- Planificación y análisis de riesgo
- Despliegue
- Nube
- Núcleo técnico
- Eventos discretos y Monte Carlo calibrado
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
Las decisiones grandes —abrir un depósito, cambiar la política de stock, tomar un crédito para financiar la campaña— se toman con una planilla que proyecta una línea. La planilla no sabe de colas, ni de variabilidad, ni de lo que pasa cuando dos cosas salen mal la misma semana.
El resultado es que el plan funciona en el papel y falla en la realidad por razones que nadie modeló: el proveedor que demora, el pico que satura la capacidad, la correlación entre dos variables que se miraban por separado. Réplica pone esa variabilidad adentro del modelo, que es donde tiene que estar.
Cómo funciona
Gemelo calibrado
La operación se modela como un sistema de recursos, colas y eventos: pedidos que llegan, capacidad que se ocupa, tiempos que varían. Los parámetros no se inventan: se estiman del histórico real de la empresa.
Escenarios
Sobre ese gemelo se corren miles de repeticiones cambiando lo que se quiera probar. La salida no es un número sino una distribución: el caso típico, el malo y el muy malo, cada uno con su probabilidad.
Qué movió la aguja
Un análisis de sensibilidad ordena las variables por cuánto explican la diferencia entre escenarios, para saber dónde conviene invertir en reducir incertidumbre y dónde no vale la pena.
Decisión de arquitectura
El gemelo se revalida solo. Cada semana compara lo que simuló contra lo que efectivamente pasó y, si la desviación supera el margen, avisa en vez de seguir entregando resultados lindos y falsos. Esa es la diferencia entre un simulador que se usa durante años y uno que se abandona a los tres meses.
Stack
Simulación
- Eventos discretos
- Monte Carlo
- Muestreo por importancia para colas largas
Cómputo
- Corridas paralelas
- Resultados cacheados por escenario
- Semilla fija para reproducir
Calibración
- Ajuste de distribuciones sobre histórico
- Backtesting semanal
- Alerta de deriva
Interfaz
- Editor de escenarios
- Comparador lado a lado
- Exportación a planilla
Investigación
Indicio
Ingesta un corpus completo de documentos, extrae entidades y vínculos, y redacta el informe con cada afirmación enlazada a su fuente exacta.
- Tipo
- Plataforma de análisis documental
- Dominio
- Investigación, compliance y due diligence
- Despliegue
- Nube privada u on-premise
- Núcleo técnico
- Grafo de conocimiento con resolución de entidades
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
Una investigación seria arranca con una caja de material: expedientes, correos, actas, extractos, planillas. Leer eso lleva semanas y, aun leyéndolo todo, la conexión que importa suele estar entre dos documentos que nadie miró juntos.
Las herramientas de búsqueda no ayudan, porque buscan palabras y no personas. «Juan P. Gómez», «Gómez, J.», «JP Gómez» y un CUIT suelto son la misma persona, y ninguna búsqueda de texto lo sabe. Indicio resuelve primero quién es quién, y recién después deja preguntar.
Cómo funciona
Ingesta y normalización
Entra cualquier formato: PDF escaneado, correo, planilla, audio transcripto. Todo queda guardado con su texto, su origen y su página, para que después se pueda citar.
Entidades y vínculos
Se extraen personas, empresas, cuentas, domicilios, fechas y montos, y se unifican las variantes de escritura en una sola entidad. Sobre eso se arma el grafo: quién aparece con quién, en qué documento y con qué rol.
Informe citado
Las preguntas se responden sobre el grafo y el corpus, y cada afirmación del informe lleva el enlace al documento y a la página. Si no hay fuente verificable, no se afirma.
Decisión de arquitectura
La resolución de entidades es el corazón del sistema y es probabilística: cada fusión de dos nombres en una sola entidad guarda su puntaje y su motivo, y el analista puede deshacerla. Un sistema que fusiona en silencio es peligroso en una investigación; uno que muestra por qué fusionó es una herramienta.
Stack
Ingesta
- OCR con reconocimiento de layout
- Normalización de formatos
- Deduplicación de documentos
Extracción
- Reconocimiento de entidades
- Resolución difusa con puntaje
- Extracción de relaciones
Grafo
- Base de grafos
- Consultas por camino y vecindad
- Detección de comunidades
Informe
- Generación con cita obligatoria
- Anexo de fuentes
- Control de versiones del informe
Automatización
Telar
Orquesta procesos que cruzan varios sistemas con garantías reales: reintenta sin duplicar y deshace lo ya hecho cuando un paso falla.
- Tipo
- Motor de procesos
- Dominio
- Integración entre sistemas
- Despliegue
- Nube o dentro de la red del cliente
- Núcleo técnico
- Ejecución durable con compensación
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
Un proceso administrativo típico toca cuatro sistemas: se carga en el ERP, se avisa por correo, se actualiza el CRM y alguien aprueba. Cuando se automatiza con scripts sueltos, funciona hasta el día que el tercer paso falla. Ahí quedan dos sistemas actualizados y dos no, y alguien tiene que arreglarlo a mano sin saber bien qué llegó a pasar.
Ese es el problema difícil de la automatización: no conectar sistemas, sino sostener la consistencia cuando algo se corta en el medio. Ninguno de esos sistemas comparte una transacción con los otros, así que la consistencia hay que construirla.
Cómo funciona
Flujos declarados
El proceso se define como una secuencia de pasos con sus condiciones, sus esperas y sus aprobaciones humanas. Se lee como el procedimiento que ya existía en papel, no como código.
Ejecución durable
El estado se guarda después de cada paso. Si el proceso se cae, se reanuda donde estaba; si un paso se reintenta, la clave de operación evita que se ejecute dos veces.
Compensación
Cada paso puede declarar cómo se deshace. Cuando el proceso falla más adelante, el motor ejecuta las compensaciones en orden inverso hasta dejar todo como estaba antes de empezar.
Decisión de arquitectura
El motor no confía en que las integraciones sean confiables: asume que van a fallar. Toda llamada externa es idempotente por clave, tiene tiempo límite y política de reintento con espera creciente, y todo efecto tiene su reverso declarado. Eso convierte «el proceso se cortó» de una emergencia en un evento previsto.
Stack
Motor
- Estado persistido por paso
- Idempotencia por clave de operación
- Sagas con compensación
Integraciones
- Conectores REST y SOAP
- Lectura de casillas de correo
- Colas de mensajes y archivos por SFTP
Operación
- Reintento con espera creciente
- Cola de casos trabados
- Alertas por proceso
Visibilidad
- Traza paso a paso
- Tiempos por etapa
- Tablero de cuellos de botella
Finanzas
Solvenz
Proyecta el flujo de caja con bandas de confianza, estima cuándo va a caer cada caso en mora y propaga shocks desde el cliente hasta el estado de resultados.
- Tipo
- Motor de riesgo financiero
- Dominio
- Cartera crediticia y tesorería
- Despliegue
- Nube privada
- Núcleo técnico
- Modelos de tiempo hasta evento y simulador de estrés
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
La proyección de caja de la mayoría de las empresas es una línea: lo que se espera cobrar, mes a mes, suponiendo que todo sale como siempre. No dice cuánto puede desviarse ni qué pasa si se desvía, que es justamente lo que hay que saber para decidir.
Y la mora se mira como un semáforo: al día, 30, 60, 90. Ese semáforo dice dónde está el caso hoy, no hacia dónde va. Dos clientes con la misma mora pueden tener destinos completamente distintos, y tratarlos igual cuesta plata de los dos lados.
Cómo funciona
Scoring con horizonte
En vez de «¿va a caer?», el modelo responde «¿cuándo?». Las curvas de supervivencia dan la probabilidad de caer a 30, 60 y 90 días, que es lo que permite anticipar en lugar de reaccionar.
Caja con bandas
La proyección combina lo comprometido, lo estimado y la variabilidad histórica de cada segmento. Devuelve un rango con su probabilidad, no una promesa de un solo número.
Pruebas de estrés
Se define el shock —la mora sube tres puntos, un sector se cae, la tasa cambia— y el motor lo propaga desde cada cliente hasta el resultado consolidado.
Decisión de arquitectura
Cada estimación es explicable por variable: no alcanza con dar un puntaje si el comité de crédito no puede ver por qué. Los modelos devuelven la contribución de cada factor a cada caso, y esa contribución viaja junto al número a todas las pantallas y a todos los informes, para que la discusión sea sobre el criterio y no sobre si hay que creerle a la máquina.
Stack
Modelos
- Supervivencia (Cox y árboles sobre tiempo hasta evento)
- Calibración por segmento
- Explicabilidad por variable
Simulación
- Propagación de shocks
- Escenarios guardados
- Comparación contra el plan
Datos
- Cartera desde el core
- Histórico de pagos
- Datos externos de comportamiento
Entrega
- Tablero de tesorería
- Informes para comité
- API para el core bancario
Cobranzas
CollectIQ
Ordena la gestión diaria de la cartera por recupero esperado en lugar de por antigüedad de la deuda.
- Tipo
- Plataforma SaaS multiorganización
- Dominio
- Cobranzas y recupero de cartera
- Despliegue
- Nube, con marca propia por organización
- Núcleo técnico
- React · Supabase · Motor de decisión propio
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
En la mayoría de las operaciones la cartera se ordena por monto o por días de mora, y a quién contactar queda librado a la experiencia de cada gestor. Se invierte el mismo esfuerzo en casos que iban a pagar solos y en casos irrecuperables, mientras los que dependían de una gestión oportuna se enfrían.
La pregunta de todos los días no es a quién le debe más, sino a quién conviene llamar hoy. Responderla bien exige estimar tres cosas a la vez: si va a pagar, cuándo, y cuánto cuesta conseguirlo.
Cómo funciona
Motor de decisión
Probabilidad de pago por tramos, recupero esperado neto del costo de gestión, score de riesgo, probabilidad de contacto efectivo y prioridad. Siete interfaces que toda pantalla consulta y ninguna calcula por su cuenta.
Simulación de estrategias
Un gemelo de la cartera permite probar cambios antes de aplicarlos: otro criterio de contacto, una refinanciación por segmento, un objetivo distinto para el mes. Incluye pronóstico y backtesting.
Copiloto con evidencia
Preguntas en lenguaje natural sobre la cartera real, respondidas con un panel que muestra de dónde salió cada número, para que la recomendación se pueda auditar en vez de creerle.
Decisión de arquitectura
Toda la lógica de cálculo vive en una capa desacoplada de la interfaz, detrás de un contrato estable. Ningún componente tiene fórmulas adentro: cuando una pantalla necesita una probabilidad, se la pide al motor. Hoy las estimaciones son fórmulas de referencia documentadas y con pruebas; el día que haya volumen para entrenar, se reemplaza la implementación y la plataforma no se entera.
Stack
Interfaz
- React 19 con Vite
- Recharts para visualización
- Sistema de componentes propio
- Vitest para pruebas
Datos
- Supabase sobre PostgreSQL
- Edge Functions en Deno
- Tareas programadas con pg-cron
- Ingesta de Excel y CSV
Inteligencia
- Claude para el copiloto
- Motor de decisión propio
- Registro e interfaz de modelos
- Backtesting sobre histórico
Operación
- Despliegue continuo
- Claves de API por organización
- Control de acceso por datos
Fintech
Umbral
El camino completo desde que alguien quiere abrir una cuenta hasta que opera, con decisión de riesgo en menos de un segundo.
- Tipo
- Infraestructura de onboarding
- Dominio
- Servicios financieros regulados
- Despliegue
- Nube con residencia de datos configurable
- Núcleo técnico
- Motor de reglas con modo sombra
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
El onboarding es donde una fintech pierde a la mitad de la gente que quiso ser cliente. Cada paso que se agrega para reducir fraude agrega abandono, y cada paso que se saca para reducir abandono agrega fraude. Es un balance que hay que medir, no intuir.
El problema es que las reglas de riesgo suelen estar escritas en el código, y cambiarlas requiere un despliegue y un acto de fe. Nadie sabe qué va a pasar hasta que ya pasó, así que en la práctica nadie las toca y quedan congeladas años.
Cómo funciona
Verificación de identidad
Documento, prueba de vida, comparación biométrica y validación contra padrones y listas restrictivas. Lo que se puede resolver solo, se resuelve solo.
Decisión de riesgo
Un motor de reglas combinable por producto evalúa señales del dispositivo, del comportamiento y del historial, y decide aprobar, rechazar o derivar a revisión en menos de un segundo.
Bandeja de revisión
El caso dudoso llega a un analista con todo armado: los documentos, las señales que lo marcaron y los casos parecidos que ya se resolvieron antes.
Decisión de arquitectura
El modo sombra es lo que hace que el sistema se pueda mejorar. Una regla nueva se activa «en sombra»: corre contra el tráfico real, registra qué habría decidido, pero no decide. Después de unos días se compara contra lo que efectivamente pasó y recién ahí se activa de verdad. Cambiar la política de riesgo deja de ser una apuesta.
Stack
Identidad
- Lectura de documento
- Prueba de vida
- Comparación biométrica
- Padrones y listas restrictivas
Decisión
- Motor de reglas versionado
- Modo sombra
- Señales de dispositivo y comportamiento
Servicio
- Respuesta bajo un segundo
- Colas para lo asíncrono
- Reintentos ante caída de proveedor
Cumplimiento
- Traza completa por caso
- Retención configurable
- Informes para el regulador
Auditoría
Veritas
Audita el cien por ciento de las operaciones aprendiendo el comportamiento normal de cada proceso y marcando lo que se sale del patrón.
- Tipo
- Plataforma de auditoría continua
- Dominio
- Control interno y prevención de fraude
- Despliegue
- Dentro de la red del cliente
- Núcleo técnico
- Detección no supervisada y reglas forenses
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
La auditoría tradicional mira una muestra, y la mira después de que pasó. Si el fraude está en el 2% que nadie revisó, se descubre el año que viene o no se descubre nunca.
Además, el fraude que importa casi nunca es una operación rara aislada: es un patrón. Facturas cortadas sistemáticamente por debajo del límite de autorización, un proveedor que comparte datos bancarios con un empleado, aprobaciones que siempre ocurren fuera de horario. Eso solo se ve mirando todo junto.
Cómo funciona
Perfil de normalidad
El sistema aprende, por proceso y por usuario, qué es normal: montos, horarios, frecuencias, quién aprueba a quién. No hay que configurarle umbrales a mano.
Reglas forenses
Junto al modelo corren reglas duras que codifican los esquemas conocidos: fraccionamiento de compras, proveedores duplicados, coincidencia de cuentas bancarias, autorización sobre lo propio.
Segregación de funciones
Se analiza el grafo de permisos real del ERP, no el organigrama declarado, para encontrar quién puede cerrar un circuito completo sin que intervenga nadie más.
Decisión de arquitectura
Los hallazgos se priorizan por riesgo económico y por confianza, y cada uno se abre para ver exactamente qué operaciones lo componen. Un sistema de detección que inunda de alertas se apaga a la semana: el trabajo fino está en que lo que llega al auditor sea poco y sea bueno.
Stack
Detección
- Isolation forest y autoencoders
- Reglas forenses parametrizables
- Análisis del grafo de permisos
Datos
- Lectura del ERP en solo lectura
- Maestros de proveedores y empleados
- Histórico de aprobaciones
Flujo
- Cola de hallazgos priorizada
- Estado y descargo por caso
- Cierre con evidencia
Operación
- Corridas programadas
- Alertas por severidad
- Informe periódico para el comité
E-commerce
Mercurio
Una capa comercial sobre la tienda que entiende lo que la persona busca, recomienda mirando stock y margen, y decide cuánto descuento merece cada carrito abandonado.
- Tipo
- Capa de inteligencia comercial
- Dominio
- Comercio electrónico
- Despliegue
- Nube, sobre la tienda existente
- Núcleo técnico
- Búsqueda semántica y modelo de elasticidad
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
El buscador de la mayoría de las tiendas falla justo cuando más importa: cuando la persona escribe como habla y no como está cargado el catálogo. «Zapatillas para correr en tierra» no encuentra nada si el producto dice «calzado trail running».
Y la recuperación de carritos suele ser un cupón fijo para todo el mundo. A la mitad se le regala margen que igual iba a comprar, y a la otra mitad el cupón no le alcanza para decidirse. Es plata que se pierde en las dos direcciones al mismo tiempo.
Cómo funciona
Búsqueda que entiende
El catálogo se indexa por significado, no por palabras. La consulta se interpreta, se filtra por lo que hay en stock y se ordena combinando relevancia, disponibilidad y margen.
Vendedor conversacional
Un agente atiende dudas con los datos reales del producto, arma combinaciones y no ofrece lo que no puede entregar, porque consulta el stock antes de recomendar.
Recuperación con criterio
Para cada carrito abandonado se estima la probabilidad de compra sin intervención y la sensibilidad al precio. De ahí sale si conviene contactar, por qué canal y con qué incentivo mínimo.
Decisión de arquitectura
El reordenamiento por margen es el punto delicado: si se exagera, la tienda empieza a recomendar lo que le conviene y no lo que sirve, y el cliente lo nota enseguida. Por eso el peso del margen está acotado por política y se mide contra la conversión, de modo que optimizar el corto plazo no pueda romper el largo.
Stack
Búsqueda
- Embeddings del catálogo
- Filtros por stock y atributos
- Reordenamiento por margen acotado
Conversación
- Agente con datos del catálogo
- Integración con stock y precios
Precio
- Elasticidad por segmento
- Descuento mínimo efectivo
- Tope por política comercial
Integración
- Shopify, VTEX, WooCommerce o API propia
- Eventos de navegación
- Sincronización de stock
Ventas
Brújula
Ordena el pipeline por probabilidad real de cierre, avisa qué oportunidades se enfrían y arma el pronóstico como un rango de escenarios.
- Tipo
- Capa de inteligencia sobre el CRM
- Dominio
- Ventas de ciclo largo
- Despliegue
- Nube
- Núcleo técnico
- Modelo de cierre calibrado y forecast jerárquico
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
El pronóstico de ventas de casi todas las empresas es la suma de lo que cada vendedor cree. Esa suma tiene un sesgo conocido y sistemático: optimista a principio de trimestre, pesimista sobre el final, y siempre con las mismas oportunidades que «cierran el mes que viene» desde hace cinco meses.
El costo no es solo el pronóstico errado. Es que el equipo dedica el tiempo a las oportunidades equivocadas, porque la única señal disponible es la etapa que el vendedor cargó a mano.
Cómo funciona
Scoring de cierre
El modelo aprende de los negocios ganados y perdidos qué señales predijeron de verdad el resultado: ritmo de actividad, cantidad de interlocutores, tiempo en cada etapa, tamaño relativo.
Detección de enfriamiento
Una oportunidad que era buena y dejó de tener movimiento se marca antes de perderse, con el motivo detectado y la acción sugerida para reactivarla.
Pronóstico con rango
El forecast se arma por segmento y se consolida hacia arriba, de modo que vendedor, equipo y compañía no puedan contradecirse. Devuelve escenario conservador, esperado y optimista.
Decisión de arquitectura
El modelo se calibra por segmento y por ciclo de venta. Un negocio de treinta días y uno de nueve meses no se parecen en nada, y un modelo único los promedia mal a los dos. Además la calibración se revisa cada trimestre contra lo efectivamente cerrado: un scoring que no se recalibra se degrada solo y en silencio.
Stack
Modelos
- Clasificación de cierre
- Calibración por segmento
- Supervivencia para tiempo hasta cierre
Pronóstico
- Agregación jerárquica coherente
- Intervalos por escenario
- Comparación contra objetivo
Integración
- Salesforce, HubSpot, Pipedrive o CRM propio
- Actividad de correo y calendario
Asistencia
- Redacción de propuestas
- Resumen de cuenta
- Próximos pasos sugeridos
Hilo
Un agente que atiende en WhatsApp de punta a punta, cotiza con datos reales del sistema y deriva a una persona cuando el caso lo excede.
- Tipo
- Plataforma de atención conversacional
- Dominio
- Atención y venta por mensajería
- Despliegue
- Nube
- Núcleo técnico
- Máquina de estados sobre memoria de largo plazo
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
Los bots de WhatsApp fracasan por dos motivos opuestos. Los de menú son tan rígidos que la gente escribe «hola, quiero hablar con una persona» en el segundo mensaje. Los puramente generativos son tan libres que prometen precios que no existen y plazos que nadie puede cumplir.
Lo que hace falta está en el medio: libertad para entender cualquier cosa que le escriban, y disciplina para que toda afirmación sobre precio, stock o plazo salga del sistema y no del modelo.
Cómo funciona
Conversación con estado
El agente sabe en qué punto del proceso está cada conversación —consultando, cotizando, cerrando, agendando— y puede volver atrás cuando el cliente cambia de tema, sin perder lo ya recolectado.
Herramientas conectadas
Cotizar, consultar stock, reservar un turno o generar el pedido son llamadas al ERP. El modelo decide cuándo usarlas; los datos siempre salen del sistema.
Derivación limpia
Cuando la confianza baja, el caso es sensible o el cliente lo pide, la conversación pasa a una persona con el resumen ya escrito y el historial completo a la vista.
Decisión de arquitectura
La memoria de largo plazo es lo que separa un bot de un agente. Una conversación de WhatsApp puede retomarse tres días después con un «che, y al final?», y el sistema tiene que saber de qué está hablando. Cada conversación guarda su estado, sus datos recolectados y un resumen que se actualiza solo, así el contexto no depende de releer cien mensajes cada vez.
Stack
Canal
- WhatsApp Business API
- Plantillas aprobadas
- Ventana de 24 horas gestionada
Agente
- Claude con herramientas
- Máquina de estados conversacional
- Umbral de confianza para derivar
Memoria
- Estado por conversación
- Resumen incremental
- Historial consultable
Integración
- ERP para precios y stock
- Agenda y CRM
- Pasarela de pago
Call centers
Tímpano
Asiste al operador durante la llamada, deja la gestión cargada al terminar y audita el cien por ciento de las conversaciones contra la grilla de calidad.
- Tipo
- Capa de asistencia y calidad
- Dominio
- Centros de contacto
- Despliegue
- Nube o dentro de la red
- Núcleo técnico
- Transcripción en streaming y evaluador calibrado
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
Un operador nuevo tarda meses en ser bueno, y lo que lo frena no es la actitud sino la cantidad de cosas que tiene que saber al mismo tiempo: dónde está el dato, qué puede ofrecer, qué no puede decir. Mientras busca, el cliente espera.
Del otro lado, la calidad se mide escuchando cinco llamadas por mes por operador. Con esa muestra no se detecta un problema sistemático hasta que ya costó caro, y la devolución al operador llega tarde y sin contexto.
Cómo funciona
Copiloto en vivo
La llamada se transcribe mientras ocurre. El sistema reconoce de qué se está hablando y muestra el dato, el guion sugerido o la advertencia de cumplimiento, sin que el operador busque nada.
Cierre automático
Al cortar, el resumen, la tipificación y la gestión quedan cargados. El operador revisa y confirma en vez de escribir, que es donde se va el tiempo entre llamada y llamada.
Calidad sobre el total
Cada conversación se evalúa contra la grilla real del equipo: saludo, identificación, escucha, cumplimiento, cierre. Los desvíos se agrupan por causa, no se listan por llamada suelta.
Decisión de arquitectura
El evaluador se calibra contra las auditorías humanas históricas del propio equipo. Si puntúa con un criterio propio, los supervisores dejan de creerle en dos semanas. Se mide la concordancia con el auditor humano y se ajusta hasta que coincidan; recién ahí se escala al total de las llamadas.
Stack
Audio
- Transcripción en streaming
- Separación de hablantes
- Latencia por debajo del segundo
Asistencia
- Recuperación sobre la base de conocimiento
- Detección de intención
- Alertas de cumplimiento
Calidad
- Evaluador calibrado contra auditoría humana
- Agrupamiento por causa
- Tablero por operador y equipo
Integración
- Telefonía y grabador
- CRM para la gestión
- Base de conocimiento
Business Intelligence
Mirador
Detecta el desvío, lo descompone por dimensión hasta encontrar dónde se originó y lo explica en castellano, mostrando la consulta que ejecutó.
- Tipo
- Capa analítica sobre el almacén de datos
- Dominio
- Reporting y análisis de negocio
- Despliegue
- Nube
- Núcleo técnico
- Causa raíz dimensional sobre capa semántica
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
Un tablero muestra que las ventas cayeron 8%. Ahí empieza el trabajo real, y lo hace una persona: filtrar por región, por producto, por canal, por semana, hasta encontrar de dónde salió la caída. Eso lleva medio día y lo repite todos los meses la misma gente.
La otra mitad del problema es que los números no cierran entre áreas. Comercial y finanzas dicen «ingresos» y miden cosas distintas, porque cada tablero tiene su propia definición escondida adentro de una consulta que nadie revisa.
Cómo funciona
Causa raíz automática
Cuando una métrica se desvía, el sistema la descompone por todas sus dimensiones y busca la combinación que más explica la diferencia. Devuelve «la caída está en el canal mayorista de la región centro, semana 3», no un gráfico más.
Preguntas en castellano
Se pregunta en lenguaje natural y el sistema traduce a una consulta sobre el modelo de datos. Muestra la consulta que ejecutó, así el resultado se puede verificar y no hay que creerle.
Narrativa del período
Cada tablero puede generar el texto que resume qué pasó, qué cambió respecto del período anterior y qué merece atención esta semana.
Decisión de arquitectura
La capa semántica es lo que impide que el modelo invente. Las métricas, sus dimensiones y sus reglas de cálculo están definidas en un solo lugar, y el traductor de lenguaje natural solo puede componer sobre lo que existe ahí. No puede inventar una métrica que no está definida, y «ingresos» significa lo mismo en toda la empresa.
Stack
Datos
- BigQuery, Snowflake o PostgreSQL
- Modelado dimensional
- Actualización incremental
Semántica
- Definición única de métricas
- Linaje de datos
- Control de acceso por fila
Análisis
- Descomposición dimensional
- Detección de desvíos
- Comparación contra plan
Interfaz
- Tableros propios
- Pregunta en lenguaje natural
- Exportación y suscripciones
Documentos
Códice
Convierte documentos en datos estructurados, ubicando cada campo en su página y mandando a revisión humana solo lo que no queda claro.
- Tipo
- Plataforma de procesamiento documental
- Dominio
- Back office, finanzas, legal y seguros
- Despliegue
- Nube o dentro de la red
- Núcleo técnico
- Visión de layout con confianza por campo
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
La carga manual de documentos es el cuello de botella silencioso de casi toda operación administrativa. Alguien lee una factura y tipea seis campos en un sistema, cientos de veces por día, con la tasa de error que eso implica.
Los lectores automáticos existen hace años y sin embargo se sigue cargando a mano, porque fallan justo con los documentos reales: escaneados torcidos, con un sello encima del número, con el proveedor que cambió el formato sin avisarle a nadie.
Cómo funciona
Lectura del documento real
Se detecta la estructura visual —bloques, tablas, encabezados— y se lee sobre eso, no sobre un texto plano. Funciona con escaneos, fotos de teléfono y PDF nativos.
Extracción ubicada
Cada campo extraído guarda las coordenadas de dónde salió, así todo dato se puede señalar sobre la imagen original. Eso es lo que hace auditable la carga.
Revisión donde hace falta
Cada campo trae su confianza. Los que superan el umbral pasan solos; los que no, van a una cola de revisión con el recorte de la imagen al lado del valor propuesto.
Decisión de arquitectura
El umbral de confianza se fija por campo y por tipo de documento, no global. Equivocar el número de factura y equivocar el domicilio no cuestan lo mismo, así que no tienen por qué exigir la misma certeza. Ajustar esos umbrales es la palanca que decide cuánto se automatiza y cuánto se revisa, y queda en manos del cliente.
Stack
Visión
- Segmentación de layout
- OCR sobre bloques
- Enderezado y limpieza de escaneos
Extracción
- Modelos por tipo de documento
- Coordenadas por campo
- Validación cruzada de totales
Flujo
- Cola de revisión
- Atajos de teclado para el revisor
- Aprendizaje de las correcciones
Salida
- API y webhooks
- Carga directa al ERP
- Exportación a planilla
Legal
Cláusula
Compara un contrato contra el manual de criterios de la empresa, marca las desviaciones sobre el texto y propone la redacción alternativa.
- Tipo
- Asistente de revisión contractual
- Dominio
- Legal corporativo
- Despliegue
- Nube privada
- Núcleo técnico
- Comparación semántica contra playbook versionado
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
Un equipo legal chico revisa contratos que llegan más rápido de lo que se pueden leer. La presión es siempre la misma: el área comercial quiere firmar hoy, y el riesgo de dejar pasar una cláusula se descubre dos años después, cuando ya no se puede hacer nada.
Además el criterio vive en la cabeza de las personas. Cuando se va alguien del equipo, se va también el estándar de qué se acepta y qué no, y cada revisión empieza a depender de quién la hizo.
Cómo funciona
Segmentación por cláusula
El contrato se parte en cláusulas reconociendo su tipo: confidencialidad, responsabilidad, rescisión, propiedad intelectual, penalidades, ley aplicable.
Comparación contra criterio
Cada cláusula se compara con lo que la empresa definió como aceptable. Se marcan las faltantes, las desviadas y las redactadas en contra, graduadas por nivel de riesgo.
Redacción propuesta
Para cada hallazgo se ofrece la alternativa de la biblioteca aprobada, lista para pegar o para llevar a la negociación con el fundamento a mano.
Decisión de arquitectura
El manual de criterios está versionado y cada revisión guarda con qué versión se hizo. Eso importa más de lo que parece: cuando dentro de dos años alguien pregunte por qué se aceptó esa cláusula, la respuesta es «porque en marzo de 2026 la política decía esto», y está el documento que lo prueba.
Stack
Comprensión
- Segmentación por cláusula
- Clasificación por tipo
- Comparación semántica
Criterio
- Playbook versionado
- Graduación de riesgo
- Biblioteca de cláusulas aprobadas
Trabajo
- Marcado sobre el texto original
- Exportación con control de cambios
- Historial por contrato
Integración
- Repositorio documental
- Firma electrónica
- Flujo de aprobación
Municipios
Ágora
Toma el reclamo del vecino por cualquier canal, lo ubica, lo clasifica, lo agrupa con los repetidos y lo mueve por el circuito administrativo.
- Tipo
- Plataforma de gestión municipal
- Dominio
- Gobierno local
- Despliegue
- Nube o infraestructura del municipio
- Núcleo técnico
- Clasificación y geocodificación sobre motor de expedientes
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
Un municipio recibe el mismo reclamo por cinco canales distintos y lo carga cinco veces, o no lo carga. El vecino que avisó del bache no se entera de nada hasta que alguien pasa a arreglarlo, si es que pasa.
Puertas adentro, el expediente se mueve en papel o en un sistema que no controla plazos. Nadie sabe cuánto tarda cada área ni dónde se traba, así que tampoco se puede mejorar: no hay número que discutir.
Cómo funciona
Entrada unificada
WhatsApp, web, teléfono y mostrador entran al mismo lugar. El texto libre se clasifica por tipo de reclamo y se geocodifica, incluso cuando la dirección viene escrita como la dice la gente y no como figura en el catastro.
Agrupación de repetidos
Reclamos del mismo problema, en el mismo lugar y período, se unen en un solo caso. Diez vecinos que avisan del mismo bache generan un expediente, no diez.
Expediente con plazos
El caso avanza por el circuito administrativo con sus pases, sus firmas y sus vencimientos. Al cerrarse, el vecino recibe el aviso por el mismo canal donde reclamó.
Decisión de arquitectura
La deduplicación en espacio y tiempo es lo que hace utilizable al sistema. Sin eso la bandeja se llena de duplicados y el equipo vuelve a la planilla en un mes. El criterio de agrupamiento es configurable por tipo de reclamo: un bache y un corte de luz no tienen el mismo radio ni la misma ventana de tiempo.
Stack
Entrada
- WhatsApp Business API
- Formulario web y mostrador
- Teléfono con transcripción
Inteligencia
- Clasificación de texto libre
- Geocodificación tolerante
- Agrupamiento espacio-temporal
Expedientes
- Circuito configurable
- Firma digital
- Control de vencimientos y pases
Transparencia
- Mapa público de reclamos
- Aviso al vecino
- Tablero de tiempos por área
Administración
Ventanilla
Asigna turnos por duración real, anticipa el ausentismo para sobre-asignar con criterio y persigue sola la documentación que falta.
- Tipo
- Plataforma administrativa
- Dominio
- Salud, educación y administración pública
- Despliegue
- Nube
- Núcleo técnico
- Optimización con restricciones y modelo de ausentismo
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
La agenda de casi toda organización que atiende gente está armada sobre una grilla fija: turnos de veinte minutos, todos iguales. Pero las prácticas no duran todas lo mismo, así que la mitad del día se atrasa y la otra mitad tiene huecos que nadie usa.
Y después está el ausentismo. Si no se sobre-asigna, se pierde capacidad todos los días; si se sobre-asigna parejo, se llena la sala de espera. La decisión correcta depende de la franja, del tipo de práctica y del perfil de la persona, y nadie tiene tiempo de calcular eso a mano.
Cómo funciona
Agenda optimizada
Los turnos se asignan respetando las restricciones reales: qué profesional, qué sala, qué equipamiento, y cuánto dura de verdad esa práctica según el histórico.
Sobre-turno con criterio
Un modelo estima la probabilidad de ausencia por franja y por perfil, y ajusta el sobre-turno para llenar la agenda sin generar espera.
Documentación al día
El sistema sabe qué documento falta para cada trámite y lo pide solo, por el canal donde la persona efectivamente responde. El trámite deja de frenarse esperando un adjunto.
Decisión de arquitectura
La duración de cada práctica no se declara: se mide. El sistema aprende del histórico cuánto tarda de verdad cada tipo de atención con cada profesional, y esa duración real es la que entra en la optimización. Ahí está la diferencia entre una agenda que funciona y una que se atrasa todos los días desde las diez de la mañana.
Stack
Optimización
- Programación con restricciones
- Recursos, salas y equipamiento
- Duración aprendida del histórico
Modelos
- Probabilidad de ausencia por franja
- Perfil de la persona
- Ajuste dinámico del sobre-turno
Documentos
- Checklist por trámite
- Recordatorios por WhatsApp y correo
- Carga desde el teléfono
Integración
- Historia clínica o sistema de gestión
- Facturación
- Calendario de profesionales
Agro
Surco
Cruza el estado satelital de los lotes con la cuenta corriente del productor para evaluar crédito y anticipar la capacidad de pago de la campaña.
- Tipo
- Plataforma de análisis agro-financiero
- Dominio
- Cooperativas, acopios y financiamiento agropecuario
- Despliegue
- Nube
- Núcleo técnico
- Índices satelitales por lote y modelo de riesgo
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
Quien financia al productor —la cooperativa, el acopio, el banco— decide con el balance del año pasado y con la relación personal. Los dos son información vieja o subjetiva frente a una actividad donde el resultado se define por lo que está pasando en el lote esta campaña.
Y el riesgo climático se trata como un imponderable: se sabe que existe, no se mide, y aparece en la conversación recién cuando ya hubo una seca y la cartera está en problemas.
Cómo funciona
Seguimiento satelital
Cada lote se sigue con imágenes periódicas. Los índices de vegetación arman la curva de la campaña y se comparan contra el histórico del propio lote y contra el de la zona.
Estimación de rinde
De esa curva, más el clima y el tipo de cultivo, sale una estimación de rinde con su rango, que se actualiza a medida que la campaña avanza.
Riesgo y capacidad de pago
El rinde estimado, el precio del commodity y la deuda vigente arman la proyección de qué va a poder pagar cada productor y en qué momento del año.
Decisión de arquitectura
El modelo de crédito toma el dato satelital como una variable más, no como un oráculo. Un índice de vegetación bajo puede ser seca, puede ser una siembra tardía o puede ser una nube mal filtrada. Por eso la señal entra junto con el clima de la zona, el histórico del lote y el comportamiento de pago, y el peso de cada fuente está medido y no supuesto.
Stack
Satelital
- Imágenes Sentinel y Landsat
- Índices de vegetación por lote
- Filtrado de nubes
Geo
- Lotes georreferenciados
- Cruce con catastro
- Series históricas por zona
Modelos
- Estimación de rinde con rango
- Riesgo climático
- Scoring crediticio agro
Integración
- Sistema de la cooperativa o acopio
- Cuenta corriente del productor
- Precios de mercado
RRHH
Cantera
Lee los CV entendiendo trayectorias, los ordena contra lo que el puesto necesita y explica por qué ubicó a cada candidato donde lo ubicó.
- Tipo
- Plataforma de selección y desarrollo
- Dominio
- Recursos humanos
- Despliegue
- Nube
- Núcleo técnico
- Matching por competencias con auditoría de sesgo
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
Una búsqueda mediana recibe doscientos CV y se revisan treinta. Los filtros por palabra clave descartan gente buena porque escribió «análisis de datos» donde el aviso decía «data analytics», y dejan pasar gente que puso las palabras correctas sin haber hecho nunca el trabajo.
Y cuando se automatiza el filtrado aparece un problema más serio: el modelo aprende del histórico de contrataciones, y si ese histórico tiene sesgo, lo reproduce y lo escala. Automatizar sin medir eso es empeorar el problema con más velocidad.
Cómo funciona
Lectura de trayectoria
El CV se entiende como una historia: qué hizo, por cuánto tiempo, con qué responsabilidad creciente. No se buscan palabras, se identifican competencias con la evidencia que las respalda.
Orden explicado
Los candidatos se ordenan contra los requisitos reales del puesto, y cada posición viene con qué cumple, qué no, y de dónde salió esa conclusión dentro del CV.
Acompañamiento del proceso
Guía de entrevista con lo que falta indagar de ese candidato en particular, evaluación estructurada y plan de onboarding para quien finalmente entra.
Decisión de arquitectura
El sistema ordena y justifica, nunca descarta solo. La decisión de bajar a alguien de la lista es siempre de una persona, y hay una razón de diseño detrás: es lo que permite auditar. Sobre cada búsqueda corre un análisis que compara la composición de los rankings contra la del universo de postulantes y avisa cuando se desvía.
Stack
Comprensión
- Lectura de CV en cualquier formato
- Competencias con evidencia
- Normalización de títulos y empresas
Matching
- Requisitos estructurados del puesto
- Puntaje explicado por competencia
- Comparación contra el equipo actual
Equidad
- Auditoría de sesgo por búsqueda
- Campos sensibles excluidos del modelo
- Registro de decisiones humanas
Proceso
- Guía de entrevista
- Evaluación estructurada
- Plan de onboarding
Educación
Preceptor
Detecta qué concepto previo le falta al estudiante cuando se traba y le da el ejercicio de ese hueco, no el siguiente de la lista.
- Tipo
- Plataforma educativa adaptativa
- Dominio
- Educación media, superior y capacitación corporativa
- Despliegue
- Nube
- Núcleo técnico
- Modelo de conocimiento sobre grafo de prerrequisitos
Vista del producto
Vista ilustrativa con datos de ejemplo.
El problema
Cuando un estudiante se traba con un tema, el problema casi nunca está en ese tema. Está tres pasos atrás, en algo que quedó flojo y que nadie detectó porque la clase siguió avanzando igual.
Un docente con treinta alumnos no puede rastrear eso caso por caso. Y las plataformas que prometen «aprendizaje personalizado» en general solo cambian el orden de los ejercicios, sin tener ningún modelo real de qué sabe cada uno.
Cómo funciona
Modelo del estudiante
Por cada concepto se estima el grado de dominio y cómo se va olvidando con el tiempo. Ese modelo se actualiza con cada respuesta, no con cada evaluación.
El ejercicio que corresponde
Cuando alguien falla, el grafo de prerrequisitos permite retroceder hasta el concepto flojo que lo explica y trabajar ahí. Después se vuelve al tema original.
Corrección y devolución
Las producciones abiertas se corrigen contra la rúbrica con devolución escrita, y el docente ve el mapa del curso: qué temas quedaron flojos y en cuántos alumnos.
Decisión de arquitectura
El grafo de prerrequisitos es contenido, no código: lo arma y lo mantiene el equipo pedagógico, no el equipo técnico. Esa separación es la que permite que la misma plataforma sirva para matemática de secundaria y para capacitación de cumplimiento normativo sin reescribir nada.
Stack
Modelo
- Trazado de conocimiento por concepto
- Curva de olvido
- Estimación bayesiana del dominio
Contenido
- Grafo de prerrequisitos editable
- Banco de ejercicios etiquetado
- Rúbricas por consigna
Corrección
- Evaluación de respuestas abiertas
- Devolución escrita
- Revisión docente
Analítica
- Mapa de dominio por curso
- Alertas de rezago
- Informes para dirección