Propuesta técnica y económica:
Piloto de tutor conversacional con IA
Dos propuestas propias, construidas sobre datos reales de coste y uso ya medidos en producción — no estimaciones de PowerPoint.
Supuestos de partida
Las cifras de esta propuesta parten de los siguientes supuestos, sujetos a ajuste conforme se concreten los detalles finales del piloto.
- Volumen mensual: 100M tokens / 7.200 min de voz se interpretan como el consumo de un mes de piloto en marcha, no el total acumulado.
- Duración del piloto: se presupuesta a 3 meses; el coste recurrente mensual queda siempre desglosado aparte para recalcular si la duración real es otra.
- Infraestructura (Google Cloud): Cloud Run para nuestra lógica (voz + RAG + orquestación, expuesta como servicio al que su lado puede conectarse como un agente más), Firebase Hosting para la capa de presentación, y una VM en Compute Engine solo cuando hay avatar (el vídeo en tiempo real necesita puertos UDP crudos que Cloud Run no permite). Más Cloud SQL para la base de conocimiento.
- Tarifa de desarrollo: 450–600 €/día, rango de consultoría técnica senior aplicado al cálculo de puesta en marcha y mantenimiento.
- Precios de terceros: los costes de IA conversacional (tokens) y avatar en vídeo (minutos) parten de la tarifa de mercado vigente en la fecha de esta propuesta. Si esas tarifas cambian de forma sustancial —al alza o a la baja—, el presupuesto se revisa en consecuencia.
Por qué nosotros
Ya construido, ya probado
No partimos de cero: el pipeline de voz, el RAG y el puente con el avatar llevan semanas corriendo con tráfico real y datos de coste/latencia medidos, no proyectados.
Capa de negocio, no solo tutor
El tutor responde con el conocimiento real del cliente (RAG), no con conocimiento genérico del modelo — eso es lo que convierte un chatbot en una herramienta útil para el negocio.
Avatar activable/desactivable de fábrica
Pasar de vídeo a solo audio en nuestro sistema es una única variable de entorno, ya construida y probada — no una reingeniería posterior.
Coste transparente y auditable
Cada euro de IA conversacional y avatar en vídeo sale de la consola de consumo en tiempo real, no de una factura que se descubre a fin de mes.
Más allá del piloto
Un piloto se juzga por lo que resuelve en tres meses. Pero conviene montarlo sobre una base que no haya que tirar el día que deje de ser piloto y pase a ser la herramienta que el equipo usa cada semana. Esta ya lo está.
Misma casa, sin fricción
Toda la infraestructura vive en Google Cloud, igual que la del cliente. No hay datos cruzando de una nube a otra ni un proveedor externo que auditar desde cero.
Lógica de negocio agéntica
El comportamiento del tutor vive en un entorno agéntico que se reconfigura en caliente. Añadir un caso de uso es una conversación con nosotros, no un ciclo de desarrollo y despliegue.
Consola de consumo en tiempo real
Cada sesión, cada minuto de voz y cada llamada al avatar queda registrado al instante en una consola propia — el mismo dato que usamos para calcular estos precios.
Nuestra base de coste real
Medido en producción esta misma semana, sobre el propio pipeline de voz + RAG + avatar — no una proyección teórica.
Dos propuestas: equivalente y diferenciada
Dos formas de abordar el piloto: una versión de referencia sin avatar, y una versión completa con avatar en vídeo y toda la capa de negocio.
Propuesta A · Equivalente
Tutor por voz, sin avatar
| Concepto | Total |
|---|---|
| Puesta en marcha | 5.850,00 € |
| Infraestructura (3 meses) | 150,00 € |
| IA conversacional (3 meses) | 337,83 € |
| Mantenimiento (3 meses) | 2.700,00 € |
Propuesta B · Diferenciada
Tutor + avatar en vídeo
| Concepto | Total |
|---|---|
| Puesta en marcha | 12.000,00 € |
| Infraestructura (3 meses) | 300,00 € |
| IA conversacional (3 meses) | 337,83 € |
| Avatar en vídeo (3 meses) | 2.075,70 € |
| Mantenimiento (3 meses) | 4.500,00 € |
* Precios sin IVA incluido. Estimaciones basadas en supuestos de volumen — ver «Supuestos de partida».
Cómo escala a más comerciales
La puesta en marcha y el mantenimiento no cambian con el número de comerciales — no hay licencia por asiento, el servicio escala solo. Lo que sí crece es el uso, y con él el coste variable. Estimado sobre una consulta media de 15 min por día laborable y comercial (300 min/mes/persona):
15 comerciales
≈ 4.500 min/mes estimados
| IA conversacional / mes | 70 € |
| Avatar en vídeo / mes | 432 € |
Sin avatar: ≈ 70 €/mes.
30 comerciales
≈ 9.000 min/mes estimados
| IA conversacional / mes | 141 € |
| Avatar en vídeo / mes | 865 € |
Sin avatar: ≈ 141 €/mes.
50 comerciales
≈ 15.000 min/mes estimados
| IA conversacional / mes | 235 € |
| Avatar en vídeo / mes | 1.443 € |
Sin avatar: ≈ 235 €/mes.
Esto son estimaciones de partida, no una cifra cerrada. Cuántos comerciales caben realmente en cada presupuesto solo se confirma con datos de campo reales durante el piloto — el patrón de uso por persona y cuántas llamadas de avatar coinciden a la vez. Los tres escenarios de arriba sirven para negociar el alcance, no para fijarlo antes de tener ese dato.
No incluye puesta en marcha ni mantenimiento, que no varían con el número de comerciales (ver «Supuestos de partida»). El volumen de referencia del concurso (7.200 min/mes) cae entre el escenario de 15 y el de 30 — más cerca de 30. Pero el consumo real no es lineal por persona: ese mismo volumen agregado podría corresponder igual de bien a 30 comerciales con uso medio que a 50 con uso más ligero o irregular. Lo que de verdad dimensiona la infraestructura no es el total de minutos al mes, sino cuántas llamadas de avatar coinciden a la vez — ver «Retos a resolver».
Potencial real
Nada de esto entra en el alcance ni en el precio del piloto. Se enumera porque la arquitectura ya lo admite sin rehacer nada — y porque es aquí donde el proyecto deja de ser un tutor y empieza a ser una herramienta de negocio.
App nativa iOS y Android
El mismo agente en el bolsillo del equipo de campo, sin depender de un navegador ni de una sesión que se pierde al cambiar de pantalla.
El CRM alimenta al tutor
Conectado a los datos de negocio en tiempo real, el tutor sabe qué negocio se está visitando, su histórico y sus incidencias antes de que nadie se lo cuente.
El tutor alimenta al CRM
Cada visita vuelve al CRM ya estructurada — retrospectiva de la conversación, estado del negocio, fotos, incidencias — capturada en el momento.
Geoposicionamiento del local
Cada visita queda anclada a la ubicación real del comercio, capturada automáticamente. Con eso el CRM puede mapear visitas, rutas y cobertura por zona.
Panel de analítica agregada
Con cientos de visitas, un panel muestra patrones — qué se pregunta más, dónde se atasca el negocio, qué zonas piden refuerzo.
Modo de baja conectividad
La app graba y guarda localmente si el negocio visitado no tiene buena cobertura, y sincroniza en cuanto la recupera.
Retos a resolver
Ningún despliegue de campo real está libre de fricciones. Estos son los que identificamos hoy, con la solución que aplicaríamos en cada caso.
Autenticación sin dispositivo corporativo
En caso de que el equipo comercial use su propio móvil en vez de uno gestionado por la empresa, no habría MDM que garantizara quién hay al otro lado de la app.
Cómo lo resolvemos: autenticación por SSO corporativo — Sign in with Google, restringido al dominio del cliente — en vez de gestión de dispositivo. La identidad vive en la cuenta de Google Workspace, no en el teléfono: dar de baja a alguien revoca el acceso al instante.
Datos de la visita en un dispositivo no gestionado
Audio, fotos y transcripciones conviven en un móvil personal sobre el que la empresa no tiene control total.
Cómo lo resolvemos: el dispositivo se trata como no confiable — los datos se cifran y se suben en cuanto hay conexión, y el acceso dentro de la app depende de la sesión, no del sistema operativo del teléfono.
Cobertura variable en campo
El avatar en vídeo pesa más que el audio; una visita en una zona con mala cobertura puede degradar la llamada.
Cómo lo resolvemos: degradación automática a solo audio si la red no sostiene vídeo, en vez de cortar la llamada — la misma flexibilidad que el sistema ya tiene para activar o desactivar el avatar de fábrica.
Dimensionamiento de la máquina de avatar
El coste de infraestructura estimado asume una concurrencia moderada. No es el total de minutos al mes lo que dimensiona la máquina que sostiene el avatar en vídeo, sino cuántas llamadas coinciden en el mismo instante — y ese número todavía no está medido con tráfico real.
Cómo lo resolvemos: la máquina retransmite vídeo, no lo procesa, así que el límite real es ancho de banda y red, no cómputo pesado. Se valida con carga real al arrancar el piloto, y si el pico de concurrencia crece, se resuelve subiendo el tamaño de la máquina o añadiendo una segunda — un ajuste de configuración, no una reingeniería.
Los tiempos de espera dependen del proveedor, no de dónde alojemos la lógica
Lo que se percibe como "espera" es sobre todo tiempo de generación — el modelo componiendo texto y voz, y el proveedor de avatar renderizando el vídeo — no tiempo de red hacia nuestro propio servidor. Mover nuestra infraestructura a otra nube no reduce esa parte de forma sustancial: ya hoy la latencia de red hacia OpenAI y hacia el proveedor de avatar es de un puñado de milisegundos, muy por debajo del tiempo real de generación.
Cómo lo abordamos: optimizamos lo que sí está en nuestra mano — sintetizar por frases en cuanto están listas en vez de esperar a la respuesta completa, y afinar la configuración de modelo y voz con los datos reales del piloto (ver «Después del piloto») — en vez de prometer una mejora de infraestructura que no la habría.
Después del piloto
Tres meses de uso real dan algo que ninguna propuesta puede tener el primer día: datos propios. Con ese volumen de conversaciones se puede ajustar el margen de seguridad a la volatilidad real observada — no a una hipótesis —, afinar qué configuración de modelo y de voz rinde mejor para este caso de uso concreto, y recalcular el presupuesto recurrente sobre cifras medidas en vez de estimadas.
Anexo técnico disponible aparte: cómo están montados hoy el RAG y la lógica de negocio →