El mercado de implementación de IA en Argentina creció rápido en los últimos dos años. Hay consultores independientes, agencias de software reconvertidas, startups de IA y empresas internacionales que aterrizaron en el mercado local. El problema es que casi todos dicen lo mismo: "implementamos agentes de IA para tu empresa".
La diferencia entre un proveedor que entrega y uno que no se nota después de firmar el contrato, no antes. Este artículo existe para darte las herramientas que permiten filtrar antes: siete preguntas concretas, con la respuesta que buscás y las señales de alerta que debés identificar. Al final, te explicamos cómo evaluamos nosotros mismos en cada criterio —porque creemos que la transparencia es la única forma honesta de presentarse.
"El costo real de elegir mal un proveedor de IA no es solo el dinero. Es el tiempo perdido, el equipo quemado y la oportunidad que no se aprovechó mientras el proyecto fallaba." — Martín Vélez, Founder @ RavenCoreX
Pregunta 1: ¿Tienen productos propios en producción o solo son consultores?
Esta es la pregunta que más diferencia a los proveedores con experiencia real de los que tienen conocimiento teórico. Una empresa que construyó sus propios productos de IA —con usuarios reales, bugs en producción, ciclos de mejora y métricas de uso— entiende los problemas de implementación porque ya los resolvió para sí misma.
La diferencia no es filosófica: es práctica. Cuando un agente falla a las 2AM porque la API del CRM cambió su formato de respuesta, alguien tiene que saber cómo detectarlo, diagnosticarlo y corregirlo. Ese conocimiento no viene de leer documentación; viene de haberlo vivido.
¿Por qué importa esta pregunta? Un consultor puede diseñar un buen plan de implementación. Pero solo alguien que opera sistemas de IA en producción sabe qué sale mal en la práctica y cómo prevenirlo desde el diseño.
Qué respuesta buscás: "Tenemos X productos en producción con Y usuarios activos. Podés verlos en [URL]." No un deck, no un demo controlado. Algo en producción, accesible, usado por personas reales.
Red flag: El proveedor describe proyectos en pasado remoto sin poder mostrar resultados actuales, o habla de "proyectos internos de investigación" sin usuarios externos.
RavenCoreX en este criterio: Tenemos cuatro productos en producción: NotarIA (App Store, transcripción de reuniones con IA), CoreWApp (SaaS de WhatsApp Business con CRM), DataMetricX (analytics para e-commerce) y LKMind (IA sobre Looker/BigQuery). Son accesibles, tienen usuarios reales y son el laboratorio donde desarrollamos las capacidades que después aplicamos en proyectos de clientes.
Pregunta 2: ¿Pueden mostrar métricas reales de proyectos anteriores?
Cualquier proveedor puede decir "mejoramos la eficiencia operativa" o "redujimos costos significativamente". Lo que diferencia es la capacidad de decir números concretos: "automatizamos el 68% de los tickets de soporte, redujimos el tiempo de respuesta de 4 horas a 90 segundos, y el equipo de atención al cliente pasó de 6 a 4 personas por decisión propia, no por reducción forzada".
¿Por qué importa esta pregunta? Los números concretos indican que el proveedor midió sus implementaciones. Si no midieron, o no pueden mostrar métricas, hay dos posibilidades: no saben si funcionó, o saben que los números no son buenos.
Qué respuesta buscás: Rangos verificables con contexto. "En proyectos de atención al cliente, típicamente logramos entre 60% y 80% de automatización en los primeros 90 días." Aceptable. "Mejoramos la eficiencia" sin número no lo es.
Red flag: Solo testimonios cualitativos sin métricas, o métricas que no pueden asociar a un tipo de proyecto concreto. También sospechoso: métricas demasiado perfectas (100% de automatización, 0% de errores) sin contexto de cómo se midió.
RavenCoreX en este criterio: Publicamos rangos conservadores basados en proyectos reales: 60-80% de tickets automatizados en atención al cliente, reducción del 30-60% en costos de BigQuery en proyectos de Data Analytics, reportes que tomaban 6-8 horas generados en minutos. Los rangos son amplios porque el resultado depende del estado inicial; los extremos son verificables.
Pregunta 3: ¿Con qué stack tecnológico trabajan?
El stack del proveedor debe ser compatible con tu infraestructura actual o con la que tenés planeada. Esto no es un detalle técnico menor: una empresa que implementa tu agente en una plataforma que no conocés —o que no se integra bien con tus sistemas actuales— te crea una dependencia que puede costarte caro cuando necesités cambiar o escalar.
¿Por qué importa esta pregunta? Si ya usás AWS y el proveedor solo trabaja en GCP, hay fricción desde el día uno. Si usás MercadoPago y el proveedor nunca integró con su API, el proyecto va a tener surpresas. El stack tiene que estar al servicio del problema del cliente, no del proveedor.
Qué respuesta buscás: "Trabajamos principalmente en GCP y AWS, y elegimos en función de tu infraestructura actual. En tu caso, con lo que describís, haríamos X por Y razón." Flexibilidad justificada, no rigidez.
Red flag: El proveedor recomienda su plataforma preferida sin preguntar qué usás vos. O dice "usamos nuestra propia plataforma propietaria" sin explicar las implicancias de esa dependencia.
RavenCoreX en este criterio: Trabajamos principalmente en Google Cloud Platform (GCP) y tenemos experiencia profunda en AWS. La elección del stack siempre empieza por entender qué usa el cliente. Si ya tenés infraestructura en un cloud específico, trabajamos sobre eso. No vendemos preferencias tecnológicas.
Pregunta 4: ¿Cuánto tiempo tarda la primera implementación?
Un MVP funcional —un agente que resuelve el caso de uso principal, aunque sea con funcionalidades reducidas— debería estar disponible en menos de 90 días para cualquier proyecto de complejidad razonable. Si un proveedor dice que la primera versión tarda más, o no puede dar un timeline claro, es una señal de alerta importante.
¿Por qué importa esta pregunta? Las implementaciones largas sin entregas intermedias acumulan riesgo. Los requisitos cambian, el contexto del negocio evoluciona, las prioridades se mueven. Un proyecto de seis meses que entrega todo al final tiene altísima probabilidad de no entregar lo que el cliente necesita —porque lo que necesitaba en el mes uno ya no es lo mismo que en el mes seis.
Qué respuesta buscás: Un timeline con hitos intermedios: "En las primeras dos semanas hacemos el discovery y el diseño, en las semanas tres a seis construimos el MVP, en la semana siete está en staging para pruebas, en la semana ocho o nueve en producción." Claridad de proceso.
Red flag: "Depende de muchos factores" sin dar rangos. O un timeline mayor a 90 días para el primer entregable funcional. O "primero necesitamos hacer un estudio de seis semanas antes de saber cuánto tarda".
RavenCoreX en este criterio: Un agente básico o intermedio: MVP en 3 a 6 semanas, versión estable en 8 a 10 semanas. Un sistema multi-agente: MVP en 6 a 10 semanas, versión completa en 3 a 4 meses. Siempre con hitos intermedios, staging antes de producción, y revisión con el cliente en cada etapa.
Pregunta 5: ¿Cómo es el modelo de precios?
Hay tres modelos de contratación en el mercado: precio fijo por proyecto (SOW), retainer mensual o tiempo y materiales. Ninguno es inherentemente mejor; el problema es cuando no están bien documentados o cuando el proveedor no puede explicar con claridad cuál aplica y por qué.
SOW por proyecto: el modelo más transparente para el cliente. Sabés exactamente qué comprás, a qué precio, con qué criterios de aceptación. El riesgo es para el proveedor si subestima el scope; por eso los buenos proveedores hacen un discovery antes de cotizar.
Retainer mensual: conveniente cuando necesitás evolución continua, mantenimiento proactivo o una capacidad técnica que no tenés internamente. El riesgo es pagar sin claridad de lo que se entrega cada mes.
Tiempo y materiales: el modelo de mayor riesgo para el cliente porque el costo final es incierto. Solo tiene sentido en proyectos exploratorios donde el scope no puede definirse de antemano.
¿Por qué importa esta pregunta? El modelo de precios define cómo se distribuye el riesgo entre el proveedor y el cliente. Un proveedor que no puede explicar su modelo con claridad, o que mezcla modelos sin justificación, va a generar fricción cuando lleguen las facturas.
Qué respuesta buscás: Claridad sobre qué modelo aplica y por qué. "Para este tipo de proyecto usamos SOW porque el scope está bien definido. El discovery es gratuito; después te presentamos el SOW con precio fijo." Eso es profesional.
Red flag: Cotizaciones sin scope definido. "Te doy un precio y después vemos qué entra." O retainers sin definición de lo que se entrega mensualmente.
RavenCoreX en este criterio: Usamos SOW por proyecto para implementaciones (precio fijo, scope definido, criterios de aceptación claros). La discovery call es gratuita. El SOW lo presentamos después de entender el contexto, con precio, timeline y deliverables. No cotizamos sin discovery porque no sabemos lo que no sabemos hasta preguntar.
Pregunta 6: ¿Entienden el contexto argentino?
Implementar un agente de IA para una empresa argentina tiene particularidades que un proveedor sin experiencia en el mercado local puede subestimar. No es solo el idioma: es conocer las integraciones con sistemas locales, las regulaciones vigentes y las expectativas del usuario argentino en diferentes canales.
Las particularidades más relevantes:
- Facturación electrónica: los procesos de facturación necesitan integrarse con ARCA (ex-AFIP) o con ERPs locales que ya manejan esa integración. Un proveedor sin experiencia en esto puede diseñar un agente que funciona perfecto en el sandbox pero tiene problemas en producción con los certificados digitales.
- Medios de pago: MercadoPago, Modo, transferencias bancarias y pagos QR son parte del flujo de muchas empresas argentinas. Un agente de ventas o cobranzas que no contempla estos medios de pago locales está incompleto.
- WhatsApp como canal principal: en Argentina, WhatsApp es el canal de atención al cliente preferido para empresas B2C y cada vez más para B2B. Un proveedor sin experiencia en WhatsApp Business API, o sin conocimiento de las políticas de mensajería de Meta, puede entregarte algo que funciona en demo pero que viola las políticas y genera bloqueos en producción.
- Expectativas de informalidad vs formalidad: el tono de comunicación con clientes argentinos varía significativamente según la industria y el canal. Un agente con tono excesivamente formal puede percibirse como distante; uno demasiado informal puede dañar la imagen de marca.
Qué respuesta buscás: Evidencia de proyectos con empresas argentinas donde estas particularidades fueron relevantes. No es necesario que el proveedor sea local; sí es necesario que haya resuelto problemas locales.
Red flag: "No es un problema, los agentes de IA funcionan igual en cualquier país." Esa respuesta indica que el proveedor nunca enfrentó los problemas de integración local.
RavenCoreX en este criterio: Trabajamos con empresas argentinas con integraciones a MercadoPago, ARCA, WhatsApp Business API y ERPs locales. Conocemos las particularidades del mercado porque son parte de los proyectos que resolvemos. El equipo está en Miami pero los proyectos incluyen contexto local desde el diseño.
Pregunta 7: ¿Tienen soporte post-implementación?
Un agente de IA en producción puede fallar. No es pesimismo: es la realidad de cualquier sistema de software. La API de un servicio externo cambia su formato de respuesta. El volumen de consultas se triplica en un evento de ventas. Una actualización del modelo de lenguaje cambia el comportamiento esperado. Algo va a pasar. La pregunta es quién lo resuelve y en cuánto tiempo.
¿Por qué importa esta pregunta? Un agente sin soporte es como comprar un auto sin garantía. Mientras funciona, bien. Cuando falla, el problema es tuyo. Y los problemas en un agente de atención al cliente a las 2AM del domingo afectan tu negocio directamente.
Qué respuesta buscás: Un modelo de soporte con SLA definido: "Para incidentes críticos (agente caído), respondemos en menos de 2 horas. Para bugs no críticos, en 24 horas hábiles. Para cambios de lógica, los gestionamos dentro del ciclo mensual." Con canales de contacto claros y un proceso de escalado definido.
Red flag: "Una vez que lanzamos, te pasamos el código y te encargás vos." O un modelo de soporte vago sin SLA, sin canal de contacto definido, o donde el soporte depende de la disponibilidad de una persona específica y no de un equipo.
RavenCoreX en este criterio: Los proyectos incluyen soporte post-lanzamiento con SLA definido en el contrato. Incidentes críticos: respuesta en 2 horas. El monitoreo de los agentes en producción es proactivo, no reactivo: tenemos alertas configuradas antes de que el cliente reporte un problema.
Tabla resumen: lo que buscás vs las red flags
| Pregunta | Respuesta que buscás | Red flag |
|---|---|---|
| Productos propios en producción | URL accesible, usuarios reales, métricas de uso | Solo demos controlados o proyectos internos sin usuarios |
| Métricas verificables | Rangos concretos con contexto de industria y caso de uso | Solo testimonios cualitativos; métricas perfectas sin contexto |
| Stack tecnológico | Flexibilidad justificada según tu infraestructura actual | Plataforma propietaria sin explicar implicancias de dependencia |
| Tiempo de primera implementación | MVP funcional en menos de 90 días, con hitos intermedios | Timeline de 6+ meses sin entregas intermedias |
| Modelo de precios | SOW con scope claro, precio fijo y criterios de aceptación | Cotización sin scope definido; retainer sin deliverables claros |
| Contexto argentino | Evidencia de proyectos con integraciones locales (ARCA, MercadoPago, WhatsApp) | "Los agentes funcionan igual en cualquier país" sin haber integrado sistemas locales |
| Soporte post-implementación | SLA definido, canal de contacto claro, monitoreo proactivo | "Te pasamos el código y te encargás vos" después del lanzamiento |
Preguntas frecuentes sobre cómo elegir un proveedor de IA en Argentina
¿Cómo sé si una empresa de IA tiene experiencia real o solo conocimiento teórico?
La señal más clara es si tienen productos propios en producción con usuarios reales, o si pueden mostrar métricas verificables de proyectos anteriores con rangos concretos. Una empresa que solo habla de IA pero no ha construido nada que otros usen tiene conocimiento teórico, no experiencia operacional.
¿Qué preguntas hacerle a una empresa de IA antes de contratar?
Las 7 más importantes: ¿Tienen productos propios en producción? ¿Pueden mostrar métricas reales? ¿Con qué stack trabajan? ¿Cuánto tarda la primera implementación? ¿Cómo es el modelo de precios? ¿Entienden el contexto argentino? ¿Tienen soporte post-implementación? Si alguna queda sin respuesta concreta, es señal de alerta.
¿Cuánto debería tardar la primera implementación de IA?
Un MVP funcional debería estar disponible en menos de 90 días para cualquier caso de uso de complejidad razonable. Si un proveedor dice que la primera versión tarda más, o no puede dar un timeline claro, es una red flag significativa.
¿Es mejor contratar una empresa de IA local o internacional?
Para procesos que requieren conocimiento del contexto local —integraciones con ARCA, MercadoPago, facturación electrónica argentina— un proveedor con experiencia en el mercado local tiene ventaja. Para casos de uso más genéricos, la ubicación importa menos que la experiencia técnica y el modelo de soporte.
¿Cómo evalúo el modelo de precios de un proveedor de IA?
Hay tres modelos: precio fijo por proyecto (SOW), retainer mensual o tiempo y materiales. El más transparente es el SOW: sabés exactamente qué comprás y a qué precio. El retainer es conveniente para evolución continua. Tiempo y materiales es el de mayor riesgo para el cliente porque el costo final es incierto.
¿Qué stack tecnológico debo pedirle a un proveedor de IA?
El stack del proveedor debe ser compatible con tu infraestructura actual. Si ya usás GCP, AWS o Azure, trabajar con un proveedor que conozca bien ese cloud reduce la fricción. Pedí que justifiquen la elección tecnológica en función de tu caso, no que te vendan su preferencia.
¿Cómo negociar el contrato con un proveedor de IA?
Los puntos clave: ownership del código y los modelos (deben ser tuyos), SLA de soporte con tiempos de respuesta definidos, cláusula de handoff (documentación para que otro proveedor pueda tomar el proyecto), y mecanismo de escalado de precio si el scope cambia. Un buen proveedor no tiene problema con ninguno de estos puntos.
¿Qué es un SOW y por qué importa en un proyecto de IA?
Un SOW (Statement of Work) define exactamente qué se va a construir, en qué plazo, con qué criterios de aceptación y a qué precio. En proyectos de IA es especialmente importante porque el scope puede expandirse rápidamente. Un SOW bien escrito protege a ambas partes: al cliente de scope creep, y al proveedor de pedidos fuera de lo acordado.
¿Listo para hablar? Primero hacemos preguntas, después hacemos propuestas.
En RavenCoreX no vendemos en la primera reunión. La discovery call existe para entender tu proceso, tu contexto y tu objetivo. Si vemos que un agente de IA tiene sentido para tu caso, te lo decimos con números. Si no lo vemos, también te lo decimos —y te explicamos por qué.
La primera conversación es gratuita, sin compromiso y sin pitch. Dura entre 15 y 30 minutos. El output es una evaluación honesta de si tiene sentido avanzar y en qué dirección.
